编辑导语：一个需求从产生到落地的全过程是很复杂的，本文作者通过分享这篇文章跟大家分享一下：我们在需求落地的过程中，会经历哪些步骤、会遇到哪些困难、有哪些技巧可以保证这个过程的顺利，希望看后对你有所帮助。
一、产生需求，辨别真伪
需求的来源有很多，需求挖掘、用户研究、用户反馈、数据分析、竞品分析、公司内部（老板、运营人员、销售、客户等），需求总是各式各样的，总是披着假面具的，辨别真伪，是产品经理的必修课。
除了会辨别，也要懂得拒绝。关于如何拒绝需求，可以参考我的文章《真实案例分析——产品经理如何拒绝需求》
二、编写需求文档
这部分也也不多说，一份优秀的需求文档，应该包含什么内容，应该是什么结构，可以参考我写的《好的需求文档是什么样的结构》，我举了很多实例，分部分拆解，讲的还算详细。
三、需求评审会
产品经理编好了需求文档，视需求大小，决定是否需要开需求评审会。通常，当需求是全新业务、开发量较大、对原系统改动较大时，是必须开需求评审会的。
很多产品经理害怕开评审会，觉得自己写的需求被开发测试当着很多人的面指出不足，甚至吐槽，是一件很丢脸的事，面子上过不去。事实上，每个产品经理都会经历这个阶段，而是否有所成长，最关键也是这个阶段。
如果的确是你的方案不足，你的自尊心会促使你快马加鞭的学习，提升自己，会逼迫你在开会之前做好万全的准备。
如果你的方案没问题，面对开发测试老板的质疑，你要学会拆解他们的质疑。如何拆解，前提是你已经考虑过他们会针对这个方案提出什么质疑，以及已经思考过你的方案，与他们的方案对比，有哪些优势。
如果你一开始还没有具备这样的逻辑能力，那就听，摆正心态，耐心的听别人的质疑，但不要马上否定自己，你需要经过深入的思考，来自主判断。
没错，心态。这个部分我并不想过多强调产品经理的能力，方案写的多么好，口才有多么好，我想强调的是，好的心态，有多重要。我认为优秀的产品经理，必须有一项品质，那就是兼容并包。承认别人的优秀，承认自己的不足，但绝不自贬，而是想办法学习优秀的人。
相信我，这个品质会让人上瘾，不再因为别人质疑而觉得抬不起头，不会因为别人的优秀觉得自卑，不害怕别人嘲讽，你会觉得心胸开阔，可以容纳更多的事物。我尝试过一些办法，不去想，或者心里暗示自己要接受要认可，但都收效甚微。
后来，我终于找到了有效的办法，那就是开口夸赞。当你遇到了优秀的人，当你的评审会上有人提出了的确不错的方案，你要敢于开口赞许，“我觉得这个想法很好”，“我觉得他的方案比我的更好，我的方案还有xxxx这些不足的，他很牛”。
一方面，可以在团队中树立你客观、兼容并包、善于赞许他人的好形象；另一方面，你的心胸切切实实可以发生改变。
通常我们会先让开发、测试、设计都各自熟悉一遍需求文档，有个基本的了解，以及产生各自的问题，再开评审会。为保证评审会的效率，产品需要挑重要的部分讲解，而一些细节的逻辑细节问题，则不多赘述。
在评审会过程中，产品经理要学会把控进度，开发人员在评审会中容易陷入思考如何实现的旋涡，导致他们在会上可能会花时间讨论技术问题，产品要及时喊停，让会议回到正轨。
四、根据评审会结果修改需求文档
这个部分，产品经理除了修改文档，更重要的工作是反思，是什么原因，导致了方案的缺陷，归纳总结，分析是哪个步骤出现了问题，是自己的哪种能力不足。
五、确定需求文档，安排分工
每个公司可能都有自己用来管理员工任务的工具，我比较推荐teambition，分享下我目前用teambition管理项目的方式：
1.一条产品线，作为一个项目
以产品线为单位，一条产品线创建一个项目管理。
2.常用的功能插件
一个项目中，可以根据项目的需要，选择功能插件，我比较常用的几个是任务、概览、统计、缺陷、迭代、Wiki、版本管理。
1）任务
即管理成员工作任务的地方，以面板的形式存在，面板可以自定义，一个任务有认领人、参与人、时间等等。
2）概览
清晰记录项目的关键信息，支持字段配置，并且可以后期搜索和统计。适合短期的，有阶段性的项目。
3）统计
提供项目范围内不同成员任务、工时的计划总量和完成情况的可视化统计。可以看到一个项目中，各个成员的工作占比以及各自完成的任务数量。
统计项目中各个状态任务的数量，如已经完成了多少、延期的有多少。有助于产品经理把控项目的风险，以及团队的效率。
4）缺陷
这个功能主要由测试人员使用，用于记录缺陷的生命周期数据，可以对缺陷进行全方位记录与跟踪。
当测试中/项目上线后发现bug，由测试人员提起，并指派执行者，同时编辑缺陷的相关信息，开发人员修改后，由测试人员跟踪，及时更新缺陷的状态。
5）迭代
这个功能由产品经理使用，即规划该产品线的迭代计划。属于这个迭代的功能，参与人员创建后任务后，都关联到这个迭代。即可根据任务的完成进度，可见本次迭代的总体进度。
6）Wiki
建立Teambition项目与「Thoughts」知识库的对应关系，通过项目导航查看对应「Thoughts」知识库的Wiki文档，「Thoughts」是一款企业知识管理工具。通过创作和组织文档，知识得以沉淀，并在团队中高效流动，「Thoughts」是以知识库的形式存在的。
我们通常用「Thoughts」来编写团队文档，例如接口文档、或任务中需要特别的说明文档，「Thoughts」中的文档，是可以和任务关联的，即可作为补充材料的形式展示。除此之外，由于它“知识库”的特性，我们还用它来编辑用户端的，可对外发布访问。
7）版本管理
每一次发布版本后，在这里编辑本次版本的版本号、发布时间、发布内容等，方便溯源。
3.任务面板的设置，以及任务的流向
这里重点讲下第（1）点：任务。
任务，实际上是以“流”的形式在项目整个生命周期中运动的。
我们设置了这几个面板：需求、采纳池、设计中、开发中、未完成对接、测试中、代码评审、待发布、已上线。
以一个任务为例：
产品经理提出需求，在面板创建了一个任务；该需求经过讨论，普遍认可其意义，且已获得上级的资源支持，则产品经理将任务拉动到面板；期间，产品经理编写需求文档、开需求评审会；期间，设计师开始参与设计，由设计师在面板创建相应的设计任务（设计的任务完成后，由设计师将任务拉动到面板）；评审会后，安排分工，参与人员；前端、后端、测试分别在产品经理创建的任务下，添加子任务，并根据各自的工期，分别设定开始时间、截止时间；前端、后端开始开发后，各自将自己的子任务拉到面板，最先开始开发的，同时负责将父任务也拉动到面板；若前后端其中一个优先完成开发，但另一方未完成，即未对接，则已完成的一方将自己的子任务拉动到面板中，同时清除开始、截止时间；另一方也完成任务后，也将自己的任务拉到面板，同时负责将父任务也拉动到面板；这时，前后端需要在各自的任务中加上开始时间、截止时间，此时的时间代表的是对接的时间；对接完成后，前后端通知测试人员，同时清除各自子任务的时间；由测试人员将整个任务（包括子任务）拉动到面板，并在测试子任务中指定开始、截止时间（此时时间代表的是测试时间）；测试中出现bug，前后端再次对接，时间算在测试里；测试完成，开始评审代码，由测试人员，将整个任务（包括子任务）拉动到面板，同时清除测试时间；评审完成，由测试人员，将整个任务将整个任务（包括子任务）拉动到面板；发布后，由发布版本的技术人员，将将整个任务将整个任务（包括子任务）拉动到面板。以上就是一个任务，最普遍的流向轨迹，省去了很多异常情况（如一个需求若未被采纳，由产品经理将任务移到回收站等），产品经理可以根据自己公司的实际情况和习惯，与团队共同商议整个流程。
有几个点需要注意：
工时的评估，需要由技术主管审核，技术主管负责指导成员如何正确评估工时（没有技术主管可以指定两个技术负责人，一个前端一个后端）；延期的任务，每一次延期，要在任务中备注延期的原因，技术主管、产品经理要知道，且分析问题所在；要求成员在每天下班前，要更新所有任务的状态；成员要发日报；每周要由产品经理发周报，以产品线为单位，概述本周该产品线的进展和计划，同时公布本期延期的任务、涉及人员、逾期原因分析。可以向上级申请一些奖惩机制，如一个月任务未有延期记录，有奖励；产品经理要自行划分阶段，定时了解成员的工作，避免在开发与需求有偏差，在测试前，产品要过一遍功能，确保功能与需求一致，测试后，正式验收。
六、功能上线，监测数据，做下步迭代计划
功能上线后要留意关键指标的变化，做好功能反馈收集，为下一版本的迭代做计划。
七、复盘
项目复盘，必备技能。改天我们再详细展开。项目复盘是产品经理能力提升的“快车道”，将自己和团队在整个周期中的过程梳理一遍，提炼精华，暴露缺陷。会复盘的产品经理，与从不复盘的产品经理，注定逐渐拉开距离。
以上，和大家分享了需求从产生到落地的过程中，一些不成文的经验，冰山一角，欢迎补充，集大家之成，查缺补漏。
本文由
木木发布于人人都是产品经理。未经许可，禁止转载。题图来自Unsplash，基于CC0协议。