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

9 评论 29231 浏览 183 收藏 13 分钟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

没错,是都重要。

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

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

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

不合逻辑嘛。

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

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

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

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

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

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

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

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

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

并没有!

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

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

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

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

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

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

第五、敏捷才是硬道理

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

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

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

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

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

秋水共长天一色!

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

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

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

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

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

那就在发展中解决问题。

#专栏作家#

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

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

题图来自 Unsplash,基于CC0协议

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

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 有一个问题,如果先写PRD,里面涉及到的功能需求详细说明里面的原型图不是得先画出来,说明两个都得同步进行

    来自江苏 回复
  2. 知己呀,我就喜欢根据需求先画草图,真的是你巴拉巴拉写一大堆,方向错了,尿偏了,也不知道,客户、领导一样也是看到原型就知道是不是自己想要的东西了

    来自上海 回复
    1. 确实,在和客户(需求方)再次对需求的时候,最直接的就是把原型摆在他们面前,一看就知道是不是他们想要的东西。详细的功能描述、业务逻辑只要内部开发的时候能看明白使用就行了

      来自广东 回复
  3. 实战为王 写的不错

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

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

      来自广东 回复
    2. 哈哈,少开会

      来自四川 回复
  5. 模型里的六大条20小条一点都不敏捷啊

    来自广东 回复
    1. 我理解,这里列举的条目是为了培养和训练思维模式或者工作习惯而定制的框架,并不意味着所有的需求都要严格做满20小条,而是根据需求本身的规模、紧急程度做出选择、调整占比。

      来自浙江 回复