太多的产品新人，甚至于工作1两年的产品汪，在开发阶段往往出现很多对接问题，影响上线进度。在此，我将程序开发阶段总结为一下4个流程，并会用故事的形式，分流程介绍我们该如何与开发对接。因内容较多，且需要与实际工作结合进行考虑，所以建议大家收藏下来，慢慢看。

下图为此系列内容的大纲

（此系列内容的大纲）

今天我们聊聊第2部分，制定开发流程与关键节点。如果没有看过第1篇文章的，请点击下面的传送门：《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》

第二天，小明按照老王的吩咐，召集了技术部的同事们进行了项目评估会议，会议中，小明从项目背景介绍、功能流程介绍、关键目标确定三个方面，向程序猿们描述了接下来要开发的产品。会后，老王将小明叫到了会议室，习惯性的点了一根烟，深吸了一口说道：小明，还不错，该讲清楚的都讲清楚了，就是在讲的时候，需要再自信点。你要对自己的产品有自信，别人才会认可你的产品。您说是吧。

小明：嗯，都是王总教的好，以后我会记住的。对了王总，那接下来我该做什么呢？

老王：别急，这次叫你过来，就是跟你说接下来的事情的。开会前，你是不是把产品原型、产品说明文档、设计稿、交互稿都交给程序猿了？

小明：嗯，是的，都发给他们了。

老王：好，那接下来，你需要做的就是协调项目经理、程序猿们一起确定项目的工作量、开发顺序与关键节点。当然了，我们公司没有专职的项目经理，这个你可以直接找孙总。（孙总是公司的技术总监）

确定项目开发工作量

老王抽了口烟，继续说道：首先呢，你先去找项目经理沟通一下，看项目经理能否在近期（一周左右）对项目的开发量进行一个评估。至于这个评估时间，你不要卡的太死，给他们充足的时间去仔细研究。这个阶段是程序猿了解需求的时候，我们需要给他们充足的时间去研究需求，只有需求研究透了，才不会出那么多bug嘛。

老王：那在这个阶段，你可能会遇到下面这几种种情况：

1. 程序猿需要你帮忙解释需求。
2. 程序猿给产品提修改建议。
3. 程序猿要求砍掉部分需求。
4. 提交的PRD、设计稿、交互稿缺少部分内容。
5. 反馈回来的工作量评估表很粗糙。

小明：王总，上面这几种种情况，第4个我会处理，缺少的内容我回去找一下，看看是不是我提交的时候遗漏了，如果确实是没有做的话，到时候再从新做一下，补给他们就好了。那剩下的几个问题呢？通常我们都是怎么处理的？

老王：别急，让我慢慢跟你说。这第1个问题呢，是我们肯定会遇到且必须要做的事情。不过在做的时候，一定注意不能太急躁，不能一上来就说：需求里面说的很清楚啊，就是这这样···那样····。如果你这样做的话，程序猿肯定给你一个大大的白眼，心里想：我TM能看懂我还让你解释什么？这个时候正确的姿势应该是，从场景出发，解释用户在日常工作中是怎么使用这个功能的。如果是问到一些数据调用的问题，需要说明数据是在哪里产生的，这样程序猿们会清楚哪些数据是需要从新建立数据表，哪些是已经有现成的数据。当然了，如果你短期内也解释不清楚的话，就诚实的跟程序说，我先回去看看，等等给你答复。不要在自己不清楚的时候下结论。

老王：第2个问题呢，当程序猿给你提修改建议的时候，一定不要直接否定了，很多好的创意，都是程序猿想出来的。如果程序猿提出来的建议是你之前思考过的，你可以把你之前考虑的思路跟他沟通一下，如果能说服他最好，如果说不不了他，而且此功能对用户没有太大影响的话，可以适当的进行修改。那如果程序猿提出的建议是之前没有考虑过的，这时候你要仔细听一下程序猿是怎么说的，不要当场回复，回来再考虑一下，整理一下方案是否可行，再去沟通确认。这个时候记住一点，所有的建议，必须以方案的形式进行落地。这才有执行价值。

老王停顿了一下，看看若有所思的小明，缓缓道：那我们说说第3个问题，就是程序猿砍需求的情况。这个问题在每个项目的开发过程中，都是经常遇到的，而且还是产品经理与程序猿产生矛盾的集中点。所以在遇到这种情况之前，你首先需要弄清楚你的产品的核心功能（不可缺少的功能）是什么，辅助功能（存在会有更好的体验，没有也不影响正常使用）是什么、意淫需求（没有使用场景或者说使用场景不实际的需求）是什么，模棱两可的需求（这样也行，那样也行）。

当程序猿要求砍掉意淫需求与模棱两可的需求时，应果断砍掉。甚至于在他们没提出来之前，就应该砍掉这里面的部分需求。当提出要砍辅助功能的时候，我们就需要进行合理且善意的引导，尽量让程序员接受这个功能，可以通过场景进行引导，让程序猿觉得这是个有用的功能，能带来价值的功能。如果程序猿坚决要砍掉，我们就需要适当的做妥协，可以将这个功能放在最后开发，甚至于下一期来进行开发，尽量不要产生争执（这种功能体量普遍较小，开发周期比较快，最后开发与放在下个版本开发，对用户没有太大的影响）。至于核心功能，你需要死死的拽在手里，谁说都不能改，这个是原则上的问题。当然了，我让你改的时候，你还是要听话的。

小明：王总，我怎么感觉在这3个问题的处理方式上，都是在一直迁就着程序猿啊？

老王：这你就不懂了，这是套路。那我问你，在上面这3个问题的处理方式上，你核心功能有没有变动？

小明摇摇头道：没有。

老王：这就对嘛，我们做产品的目的，主要是看结果的，只要结果达到了，怎样都行。而在这个过程中，充分采纳程序猿的建议，一部分是有利于产品更好的发展，毕竟程序猿提出的部分建议，还是很有价值的；另一部分呢，就是让程序猿多参与到产品的规划建设中来，增加他们的主人翁精神（这个最好在规划阶段，就多跟技术进行沟通）。只有这样才能实现我昨天跟你说的，让程序猿踏上你的“贼船”。

小明想了一会，说道：王总，套路挺深啊，那您继续说，下面两个问题怎么解决？

老王：第4个问题，就是提交的PRD、设计稿、交互稿缺少部分内容的情况，这个你刚才也说了一个解决办法，这里我再给你补充一下，当项目比较紧急的时候，程序的开发与内容的补充可以同步进行。

老王：最后1个问题，反馈回来的工作量评估表很粗糙的问题。评估表内容粗糙，很大的问题在于你跟项目经理的沟通问题上。对于大多数程序猿来说，都不愿意去做写一份对后续开发没多大作用的评估表。这时，你需要跟项目经理提前沟通好，说明清楚要写一份详细的工作评估表重要性，让他协调程序猿来完成这项工作。这里我总结为两点，

第一点：评估表的详细程度，直接反应了程序猿对项目的了解程度。对于我们产品经理而言，我们不需要那么详细的评估表，我们需要的是让程序猿在写评估表的过程中，充分的了解产品需求，这样才能避免后续开发过程中不出现较大的问题。

第二点：详细的评估表也有利于项目经理对项目的管理与跟踪，对项目管理有非常重要的作用。

老王掐灭了手中的快烧尽的烟头，淡淡的说道：其实在这个阶段，归根接地就是一句话：尽可能的创造机会让程序猿们了解产品的需求，并赋予他们主人翁精神，而不是停留在表面。当工作量都已经评估好之后，我们就需要计算一下开发总时长了。在这个时候，我们需要结合公司的要求，如果公司要求必须在9月30号之前完成开发，而我们评估的时间只能在10月10号完成，那我们需要跟项目经理协调压缩项目时间。压缩项目时间可以通过增加项目成员与有效加班的方式进行处理。这个后面我有时间再跟你细讲。

确定开发顺序

老王：第一步已经跟你讲清楚了，接下来我们聊聊如何确定开发顺序。关于开发顺序，我们重点说一下两个顺序，1个是前端与后端的开发顺序；1个是功能模块的开发顺序。

老王：关于前端开发与后端开发，你能分的清吧。

小明：前端就是写页面的，后端就是写数据的，我可以这样理解吧？

老王：嗯，这样理解没毛病。从前端与后端的工作内容来看，在一些地方是没有依赖性的。例如：前端在没有数据的情况下，是可以写一些页面样式的。后端在没有前端的支持下，也是可以写一些数据接口的。那我们就可以理解为，前端与后端是可以同步进行开发的对吧。

小明：嗯。

老王：你过来看一下这张图，这是我整理的一份程序员开发顺序图。

注：具体项目的开发的开始时间可能不同，道理是一样的，前端开发与后端开发可以同步进行，但是需要保证前端在进行数据对接的时候，后端提供足够的可用数据。

小明：王总，后端开发为什么跟前端开发一起开始啊，我记得都是先切完图后端才开始开发的啊？还有就是后端开发后面有个空白的框，是什么东西啊？还有还有，就是最后那个测试，为什么跟开发一起啊，不是做完了才进行测试的吗？

老王：又着急了不是，年轻人，要稳重点。好好看图，每个横向的柱状图中，都包含了具体的开发流程，在前端进行切图、框架选取、交互开发的时候，是不需要后端提供数据的，只需要设计稿与交互稿就可以完成了。而后端开发的的过程中，数据库设计、框架选取、编写数据库接口只需要demo与PRD文档就可以解决，也不需要前端提供页面，所以这样看的话，不相干的工作是可以同时开始并进行的。

而后端开发的那个空白的框，是修改bug的时间。因为在开发过程中，前端开发中“对接数据库接口”这个过程，是需要后端“编写数据接口+功能实现”两部分做支撑的，换句话说，后端的工作进度必须领先于前端的开发进度。所以后端开发通常会提前完成，那剩下的这个时间就是用来进行bug修改与功能调试的。而关于产品测试的时间安排，就是接下来我要讲的第2部分，确定功能模块的开发顺序。

功能模块开发顺序，顾名思义就是描述先开发哪些功能模块，再开发哪些功能模块。这就跟我上次跟你说的那个讲解产品的顺序一样，要有一个先后顺序。忘记了你去翻一下上次的笔记《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》就知道了。确定这些开发顺序后，是方便我们再程序为开发完成就进入测试阶段，从而节省测试的时间。这下知道为什么测试阶段与开发阶段放在一起了吧。

明确关键节点

小明：嗯，这下清楚了。王总，您渴不渴，我去给你倒杯水。

老王：不用了，我想喝脉动，给我买一瓶脉动吧。

小明一脸鄙视，无奈地去楼下便利店给老王买了瓶脉动，并给自己买了瓶阿萨姆。

老王喝了一口脉动，缓缓地说：还有最后一个阶段了，那就是确定关键节点。这个阶段的主要目的是便于我们与项目经理对开发进度进行把控，这里呢，我们会用到两张表，这两张表分别是上面提到过的开发量评估表与功能模块开发顺序表。将这两张表组合在一起，就能确定我们项目的关键节点了。

而这张表中需要包含项目的开始时间与结束时间；每个模块的开始时间与截止时间（前端与后端是分开的，功能模块的完成时间以前端为准）；每个模块（功能）的负责人、完成情况与备注等信息。其中，功能模块的划分与开发顺序是由功能模块开发顺序表提供的。具体功能的负责人与时间，是由项目评估表提供的。有了这张表，就可以对项目开发过程进行有效的管理。你过来，我找个之前项目的表给你看下。

（此处的数据为模拟数据）

老王：能理解吗？

小明：嗯，大体清楚了，回去我再整理一下，如果还有疑问，我再咨询您。我走了，王总。

老王：嗯，走的时候帮我带上门。

老王看着渐渐走出办公室得小明，点了一根烟，缓缓地道：哎，天生就是个操心的命！

相关阅读

《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》

作者：李英杰，二一教育高级产品经理，主要负责题库类产品的规划与运营工作。

本文由 @李英杰 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议