你会先写PRD,还是先画原型?

4 评论 6945 浏览 42 收藏 13 分钟

编辑导读:一个老生常谈的问题:需求设计时,先写需求文档,还是先画原型?这几乎是每一个产品经理都需要经历的阶段。本文作者对此发表了自己的看法,与你分享。

道路很远,脚步更长;肩挑凡世,拳握初心。

我们要在发展中解决问题。大概是2020年初,我和公司领导拜访一国企的某处长,向他汇报我们的系统建设,他是我们的甲方,也是我们双方合作的主导者,那次给我留下了深刻的印象,也彻底改变了我对国企领导的幼稚偏见。

面对我们系统仍存在的不足,面对诸多利益的交错,面对前进与后退的选择,面对可能不良后果的影响,他一锤定音,说了上面那句话。

最终,我们并没有辜负他的信任,准时交付了产品,合作很成功,但当初过程时压力巨大,差点功亏一篑,多亏他几次力挽狂澜。

事实上,他也不仅仅是因为信任,我后来理解,更多的可能是来自经验的哲学,是在阅历和经验的积累上,对于解决问题的自信和掌控力。

时至今日,每当需求评审遇到左右为难的问题时,或者说团队建设存在什么冲突,我都会说:我们在发展中解决问题。(竞品分析 · 拿来主义)

这句话,我觉得不是妥协,更不是放弃,而是敏捷思维下的聚焦注意力,永远抓住主要矛盾,坚定地拥抱效率。

当下,敏捷思维大家都说烂了,但据镜同学鹰眼观察,真正用心体会和遵循的,属实并不多。

很多时候,我们都是人云亦云,然后匆匆行事,甚至来不及思考。

这两天,有不少产品同学加我微信,咨询我需求文档、原型设计的事儿,好在镜同学峡谷游走小十年了,原型从未挂机,需求说明文档更是家常便饭,始终坚定不移地走群众路线。

这不,前天有个新朋友问我一个老问题:需求设计时,先写需求文档,还是先画原型?

这是一个好问题,我很想谈谈我的想法。

第一、谈下我对需求说明文档、原型设计的理解

从落地的成果价值上来看,我认为原型设计的重要作用在于需求传递,是向上下游不同岗位评审产品需求的重要载体。

产品功能、交互设计、业务逻辑、页面元素等等,通过原型设计,可以最高效率的完成需求的传递,降低理解成本和失真率。

或者说,原型设计的重要功能是偏向对外的需求传递。

那么,回过头来说,需求文档呢,抛开便于追溯问责、撕逼时有依据这些段子不谈,我以为需求说明文档的价值其实可以体现在两部分:对外的需求传递和对内的需求指导。

对外的价值在于是需求理解时的依据,评审会毕竟不可能照顾很多细节,有很多业务规则、字段来源、输入输出,限制条件等需求功能点,需要在文档上体现,开发人员可以依据需求文档进行更加准确的设计,有了参照标准和设计图,才不至于有偏差。

对内的价值往往容易被忽略,其实,需求文档更是产品设计过程的重要效率工具,可以指导我们的需求设计,通过模板要求和流程方法,会引导你想的更深更细更全面。

如果你有过复制过某个产品设计的工作情况,你就会发现,一开始你就有一个完备的需求文档,那简直爽的不要不要的,需求设计简直就是百里开了透视挂。

第二、产品经理的首要任务是什么?

很多同学看到这个问题,心里肯定默念,产品设计嘛,你这不废话么,还当我是峡谷青铜么?

如果你的答案是产品设计,镜同学很遗憾的告诉你,你特么答对了。

但,你在工作中未必就是这样做的,就像前文说的,很多话我们都是听着听着就记下来了,但并没有理解。

产品设计其实可以拆解成两个工作包:需求设计和需求传递。

需求设计是从产品经理的专业视角来说,要完成产品功能的建筑,而需求传递则是从管理输出的方面考虑,要将设计好的产品功能,传递给他人,确保对方理解高效、准确。

好了,那么需求设计和需求传递哪个重要?

没错,是都重要。

哪个应该放在更高的优先级来做呢?

毫无疑问,你只有完成了需求设计,才有了做好需求传递的基础。

就像镜同学打野一样,我都没有六神装,怎么带领队友越塔强杀,逆风翻盘?

不合逻辑嘛。

第三、产品设计的灵魂是什么?

看了上述两点,聪明的同学已然明白:产品设计的工作首先是需求设计,而需求说明文档对于我们产品经理来说,有内部驱动作用,可以指导我们进行需求设计。

镜同学似乎看到课代表已经举手:先做需求说明文档!!!

没错,镜同学最初也是这么做的,甚至,一度也是这么作为部门要求的,我当时常说:先把需求文档写好,需求文档写好了,原型设计自然就出来了,原型设计做出来了,我们就可以和技术评审了。

但凡看过《盗梦空间》的同学都知道,层次感是个烧脑但很有价值的事情,那就让我们再深入一点,往前迈进一点:产品设计的灵魂是什么呢?

这次咱不给课代表抢答机会,直接说答案:效率。

是的,效率才是产品设计的关键所在,也可以说是产品设计的灵魂,高效、准确的定位业务需求,将需求翻译成可传递的成果,才是产品设计的王道。

第四、是正解,但不是最优解!

好了,我们重新梳理下:原型设计和需求说明文档,我们似乎应该先选择需求说明文档,因为需求说明文档从逻辑上来说,对我们产品设计有指导价值,但产品设计的灵魂是效率,那么需求说明文档作为高优先级,合乎法理,是否就能适应实情呢?

并没有!

举个不恰当的例子,需求说明文档就像是着正装,很正规,也很有价值,但是穿起来太麻烦,我就想去楼下吃个宵夜,大裤衩白背心一字拖,可能五分钟就能实现我的需求。

我再翻箱倒柜折腾一番,烤羊肉串的可能早就收摊了。

敏捷开发的真谛就在于各个环节都要效率优先,集成起来才有可能形成整体的效率同心环。

十年磨一剑,在当下的互联网时代,很难有生存力。(有情怀但又有资本干爹罩着的除外)

显然,需求说明文档并没有兼顾效率,因为写起来并不是那么容易,总是三易其稿,随时推到重来,常常没有灵感和思路。

这就是理论和现实的差距,也是我原先的误区,你以为需求说明文档就是盛装出席的少女,但打扮起来是真不容易。

第五、敏捷才是硬道理

历史的价值,往往就在于探索后积累起来的宝贵经验。

事实上,越来越多的需求,越来越短的工期,活活让一个新穷人愣是发育成了六神装,更关键的是,还掌握了快速发育的方法。

再拿到一个新需求,我们现在不会纠结先写文档还是先写原型,而是会先建立一个敏捷模型。

这个模型其实很简单,只是一系列思维的集成体,有业务分析、有竞品分析、有产品设计、有问题清单等等,产品需求设计依据这个模型去开展,在设计的过程中可以进行原型设计、可以逐步去完善需求说明文档。

镜同学以为,原型设计和需求文档哪个先写并不重要,重要的是要有发展的思维,敏捷的思维,懂得效率优先,而不是拘泥形式或者流程制度,有时候画一会儿原型,完善下文档,有时候,写个功能文档,再去优化下相关的原型设计,最后整合输出又怎么了嘛。

秋水共长天一色!

当然,每个人公司的环境不同,有些公司就是严格要求先写出完整的需求说明文档,然后再进行原型设计,镜同学原先也在误区里,也委屈了当时的小伙伴们。

就像脱离开剂量谈毒性没有意义,单纯的评估哪个好也不科学,很多事我们原本也无力改变,但是,我们可以改变自己,可以训练自己的敏捷设计思维,每一个需求设计对我们而言都是教导员。

适合自己的才是最优解,我们需要做的是,运用敏捷思维,找出适合自己的敏捷模型,高效地完成需求设计,这才是咱们产品经理的首要任务,其次,才是需求传递。

敏捷思维才是我们的初心,也是我们工作的出发点和落脚点。

如果有什么困难阻碍了敏捷的脚步,直接踢开它,如果发现暂时踢不开,又可能会耽误眼下工作,怎么办?

那就在发展中解决问题。

#专栏作家#

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 实战为王 写的不错

    回复
  2. 文笔不错,我来说一点我的敏捷心得:
    先抛出我的倾向:先出原型,原因是:
    1、原型比较具象,在需求调研和设计阶段,单从文字上,是无法挖掘出更多的使用场景,先出原型,一方面可以给到需求方比较具象的东西,可以在原型上开展更加深入的讨论,一方面可以拿着原型与开发团队进行讨论,提出产品经理对于待开发版本的设想,让开发提出相关意见,便于在设计阶段,能够充分吸收各方面的建议,不至于后续返工;
    2、原型的制作过程中,方便一边设计一边总结,对于原先调研的需求或者会议纪要,从另一个角度,另一个形式进行审查,从中也能想到更进一步的优化提案;
    3、对于部分简单需求,可以先出原型,让开发团队先进行静态页面开发,需求文档在开发的过程中再补,一定程度上实现了有效的敏捷;
    4、PRD是沟通工具,不是结论性的产物,类似会议纪要,沟通越多,越可能会修改,因此,从敏捷的角度出发,先画原型,后补文档,是比较高效的工作方法;
    以上是我的个人倾向,在发展中解决问题,楼主的很多总结相当到位

    回复
    1. 类似会议纪要,沟通越多,越可能会修改——不能更同意了

      回复
  3. 模型里的六大条20小条一点都不敏捷啊

    回复