你会先写PRD，还是先画原型？

我们要在发展中解决问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

好了，那么需求设计和需求传递哪个重要？

没错，是都重要。

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

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

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

不合逻辑嘛。

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

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

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

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

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

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

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

第四、是正解，但不是最优解！

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

并没有！

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

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

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

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

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

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

第五、敏捷才是硬道理。

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

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

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

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

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

秋水共长天一色！

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

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

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

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

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

那就在发展中解决问题。