product
Posted By eva

撕一撕PRD


1369713061_753629

前言:

其实对PRD这种事情,已经看透了,然而,说起来居然还是一把鼻涕一把眼屎。其实全文概括起来只有一句话:工具是死的,人是活的;要避免撕逼,要么把工具按照严格的流程做到极致的使用;要么就以人为本,利用POSITIVE的态度来做及时的沟通。

注:
1. 看干货的,看第一季;

2. PO找共鸣,看前传部分;

3. 想解决问题的,看第二季;

“这里当然要XXXX啊!”

“你在PRD里有写吗?”

“我们在需求评审会沟通过啊。”

“你的文档里写了吗?”

“那你需求评审会上哪儿去了?”

以上的撕法,基本可以说是产品和开发之间的经典撕白。不撕,不成产品,各种SB段子已成为产品和开发之间的经典桥段。所谓故事出自民间,应该就是这个道理。

就这样,PRD被很多人,当成了对撕必备品。(真替PRD可怜,虽然最早我也把他拿来当手撕必备。)

第一季:PRD是什么?

其实PRD是什么?现在越来越多的产品经理已经意识到PRD的重要性。入行三年,不是一个成熟的产品,但是对PRD的地位和重要性,真想谈一谈。

  • PRD是自我思考和思路的整理。
    PRD本身不仅仅是是存档。当你开始写PRD之前,其实会做很多事情,比如:业务流程图,整体系统设计图,运营规则,原型图……blablablabla…
    在这个过程当中,PO会发现,一直在边写PRD,边改其他文档或原型。其实,这是一个整理思路的过程,使自己的逻辑更为严密,对各个系统细节和交互细节更为关注,考虑得更为周到,以免产品在开发过程中,有遗漏或因遗漏而引起的重复劳动力。因为,在产品设计过程中,有些问题不考虑,将造成许多设计的不成立,会面临从头来过的问题,或者就是代码被改得千疮百孔。
  • PRD是一种文档和知识的传承。
    在日企工作期间,有幸看到了先锋和索尼的软硬件设计文档。他们利用最万能和伟大的工具:xls表格,完成了几乎所有文档的写作。电子产品的交互设计,和一次次及时的修改记录,让你深感汗颜。我想,这就是为什么日本人工作到很晚的原因吧。但是,这样一来,每一次产品的更新,为什么更新,会让你非常清楚。在工作交接时,你可以看到前辈是如何思考,每一次修改是出自什么样的目的。
    作为电子产品,完备的功能设计文档,也十分有利于其他电子产品开发过程中的流用。可以免除很多不必要的麻烦以及产品功能设计的不一致。
  • PRD让需求的交付更有形,更具体,也更正式。
    在项目管理过程中,我们总说“可交付成果”。对于开发和测试来说,交付质量过关、可进行操作的系统功能和合规的代码,就是最强有力的可交付成果。但是对于产品来说,并没有最为直接的交付物,所以,把自己的想法和所作的考虑写下来,是最为合适的方式。
    在需求的评审过程中,由业务方和开发方进行验收,确认设计符合业务需要,并存在开发可行性时,设计稿完成交付,进入到开发过程中。

也许,PRD还有别的用处,于商业,更是合同的一部分,于项目,是评估工作量的重要依据,于测试和验收,是一份验收标准。

前传:PRD引发的血案?

可就是这样一份文档,引发了无数的血案,成为了众多PO的痛点。在PRD撕逼上,就算是南方小姑凉,都有胆单挑整个开发团队。(说的就是我。。。)

扯扯我手上的PRD:

  • 最早的时候,我在甲方公司工作,根本没有PRD…好咩(能拿到PRD的乙方公司,请让我看到你们洁白无瑕的牙齿)。因为自己公司的测试和甲方公司撕逼,拿不出切实的证据,于是,我开始编写合规的需求文档。但当时,主要以记录为主,商量好什么就写什么。纯撕逼工具。
  • 接着接着,乙方公司嫌弃我们总改需求(刚才脸红脖子粗的乙方公司,请让我再次看到你们上下一致的点头动作),于是,我们开始在开发前,完成需求文档的写作,并记录所有变更,以便于计费。(一切有用的工具,基本都是来源于战争)
  • 后来,我们自己组成了开发团队,于是,画图、约定、工期估算,几乎都是在一团和气中,在一张圆桌上,在一个小会议室中,完成的。我们会介绍业务想要的需求,开发会沉思,会讨论表设计,会确定前后台接口,接口完成日期。然后,在开发交付测试前一周左右(两周一个迭代),出完需求文档的编写。测试开始书写用例。(时间也不会那么精准)
  • 再后来,换了一个传说中,高大上的互联网交易平台企业(那叫一个酸爽)。封闭开发期间,PO白天傍晚不吃不喝不碎觉,万万不敢停工(开发停工,PO的鸭梨其实很大),一天三份需求:业务流程图、交互设计流程、必要的需求文档(虽然没有模式)。到最后,项目上线来不及了,直接只画原型图。开发高呼:我们不要文档,我们只看原型。
  • 然后,我进入到下一阶段,只有原型,把所有业务原则统统标注在原型上(用红色字体)。后果,当然是可想而知的,强烈撕逼,拍桌子、脸红脖子粗,那都不叫事儿,更要命的是,测试哭死了(测试的同学们,请让我听到你们的掌声。)
  • 吸取教训后,PO乖了,憋2个月出一份PRD文档,总共80页,附赠一份详细原型图,并追踪至UI图设计完成,前后需求评审共8次。这下,测试乐了,开发哭了。原因你懂的。(其实,我的内心也蛮崩溃的,当然,也有工作分工不明确,造成我无法把大部分时间放到PRD写作上的,但是2个月,其实,沟通到位的话,连开发都出来了。在现今要求快速试错的时代,真是很大的代价。)

第二季:是PRD问题,还是沟通问题?还是流程问题?还是意识问题?

究竟是PRD有问题,还是沟通有问题?

很多PO都有亲身体验,一说到PRD,都会觉得心好累,又或者已经过了被虐的阶段,已经麻木了。说起来,都是泪,从来出具详细的文档,开发会要求出具中高保原型;出具高保真原型,开发会要求出具详细文档;当两样都有时,开发会要求各种交互细节的描述;当交互细节描述了,开发会说你的文档写得不够专业,开发需要的PRD不是那样的。

综上,PO已经哭晕在厕所。因为,你从来没有做的足够好、足够对。

其实说回来,我们在整个撕逼过程中,除了关注谁显得更为专业、谁说出了自己的槽点外,是否有人真正关注过,槽点的上下文?

  • 标准的交付过程是否具备?
    标准的项目过程和交付过程,是否具备?我们只关注PRD本身,但是,究竟一个产品的交付,要有多少内容?交付的过程应该如何制定?一手交稿,一手交接,是不是有所规定?评审后,开发和测试的输出文档是否具备?是否完成评审?
    评审准备:
    产品技术评审,交付的文档是包括:业务流程图、产品PRD描述、原型;
    产品PRD要包括:1)产品概述及解决的问题;2)相关产品及描述;3)术语定义;4)产品角色及角色用例;5)相关产品及描述;6)产品功能结构及功能清单;7)按功能/页面进行描述;其中,包含后台运算逻辑、约束、交互设计;交互设计包括:操作、校验规则等等;8)非功能性需求;9)业务及接口列表;10)文档控制,包括:审阅状态、修改履历及风险;
    b. 评审过程中,
    是否给予了充分的尊重?
    评审前,PO是否和技术们沟通清楚实现方案了?是否提前提供了评审资料,以便于他人能有会前准备?
    评审前,技术和测试同学们是否认真阅读了需求和原型?
    有效利用会议,提高会议效率,是PRD评审和后续工作效率的关键点;
    c. 评审会后
    开发是否输出了技术设计文档?接口设计文档?是否更新了数据库结构文档?测试是否输出了测试计划?测试是否完成了测试用例的编写?相关的文档是否充分,且与PO及团队成员做了评审?
  • 沟通是否有效?
    越来越痛恨一些即时沟通软件。尤其是拉个群,一堆人在群里七嘴八舌,信息被不断遗漏,被不断不假思索的输出。同时,大家也越来越忽视集体会议的权威性和重要性,以及当面沟通的准确性:反正群聊随时可以沟通嘛!
  • ALL IN ALL
    在PRD的明确过程中,在“理解”之外,我们需要深思、注重和强调的,是流程的重要性和沟通的必要性。
    PO准备充分评审材料,会前与技术同事充分沟通可行性;
    b. 评审会前充分阅读,会中充分讨论,会下开发及测试以开发设计文档、接口文档及测试用例等文档做出充分反馈,以便于各方将认知保持在同一条线上;
    c. 需求沟通过程中,有节制得使用即时沟通工具,有必要时,充分得面对面沟通;要抱着评审后,不能修改需求的态度,去参与到评审会中;
    d. 手永远比脑慢一点。先设计,尽可能考虑周全,确认清楚,才开始工作;
    f. 充分沟通。天下没有一种语言能完整得表达自身的心理需求。越是合作久的团队,越是可以尽可能产出“必要的”文档,因为“默契”;越是新的团队,越是不要吝啬每一次沟通的机会。“文档”是一种沟通的工具,但口头沟通与解释将会让文字更具有色彩、更具有确切的含义,更有效率;
    g. 努力去了解对方,理解对方的真正用意,不要固步自封,站在自己的角度上,要求别人来按照自己的想法和表达习惯来做事。团队成员来自五湖四海,只有相互理解,才能逐渐形成自己团队内部的默契。站在自己的立场上,你将随着世界的变化,逐渐被抛弃。

产品的上线,是一项团队合作的结果。无论方法是什么、工具是什么,重要的是理解、约定、尊重与充分沟通。


View Comments
There are currently no comments.

跳至工具栏