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

下图为此系列内容的大纲：

今天我们说说第3部分，也是最关键的一部分——跟进项目开发。如果没有看过前两篇文章的同学， 请点击下面的传送门：

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

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

故事背景：

小明：某IT公司的一名产品新人。

老王：某IT公司的产品总监。

项目进度：产品开发阶段。

经过老王的细心指导与小明的不懈努力，终于在2周内确定了开发进度排期与项目的关键节点。虽然最后勉强算完成了阶段性工作。但对于刚做产品的新人来说，还是挺不错的。

看着一步一步成长起来的小明，老王决定，是时候再帮他一把了。

老王：翠兰（老王秘书），叫小明来趟办公室来。

翠花：好来!

5分钟后，小明走进老王办公室：王总，您找我？

老王：坐，今天找你，是想跟你聊聊最近工作的问题。

小明：王总，我最近没犯什么错误吧？

老王：别激动，没事，就是随便聊聊。

小明送了一口气，道：王总，最近我感觉工作重心明显有焦点了，知道该做什么，不该做什么了。做起事情来得心应手，这都是您教的好。我能有今天的进步，都归功与您的细心教导······（此处省略1000字）

老王：行了，行了。就知道拍马屁。有这功夫还不如给我买包烟来的实在。

小明一脸黑线~~~

老王：好了，说正事。前两周我观察了一下你的日常工作。还不错，能打70分。但是在沟通协调这块，你还是要注意一些，尽量放低一些姿态。让程序猿们在轻松的环境下表达自己的想法与见解，这个你还需要加强。

小明：嗯，虚心听从领导教诲。

老王无奈道：在整个产品开发过程中，主力军还是程序猿们。但是作为整个产品的负责人，我们也应该在里面做一些力所能及的事情，帮助项目顺利开发与上线，我把这些整理成了三个部分，今天我们就聊聊这个。

需求变更与需求再确认

老王：还记得之前让你去确定项开发顺序吗？

小明：嗯，记得。都已经完成了。

老王：好，那在接下来的阶段，我们就会用到这张开发顺序表。老张你知道吧，就是技术部门的主管，他跟我关系很好，我们周末经常一起喝酒聊天。我之前有问过他，在项目开发过程中最烦什么事？他对我说“最烦的就是产品改需求，本来好好的功能都做的差不多了。产品非要说产品需求有问题，要变更需求，甚至有时候要砍掉需求。多少次因为这个问题，哥连夜删代码，一次次的shift+delet，都是在割肉啊！”我对这句话印象很深。后来我反省为什么会出现这种问题的时候。总结出的答案就是因为需求未确认与修改需求不慎重导致的。至于要解决这个问题，有3种途径解决：

在开发之前，确认哪些需求需要变更，并提供变更方案

老张经常对我说的一句话“程序猿都是一群性格温顺的食草动物，如果你把他惹火了，那你肯定做了令他特别不能容忍的事”。而更改需求往往最容易惹恼这批温顺的程序猿们，且耽误了项目开发进度。当然，在开发阶段也不是不能改需求。而频繁改需求，本质上的原因是因为这个产品经理的能力不够，能力不够的话，我们就用努力来凑。所以项目开发之前，我们需求将需求再从头到尾梳理一遍。明确每个需求都能走通，且每个需求是具有实际价值的需求。这时候需要用到你整理关键节点表了，你只要这个顺序，在程序猿开发前，将修改的需求与开发确认一遍就可以了。但是在确认的时候，不要光口头沟通，要有落地的方案。

同时在修改需求的时候，需要在产品说明文档中同步进行修改，并记录好版本号，同时确认好程序猿手中拿到的版本就是最新的版本。

每次开发前需要进行需求再确认，明确自己要的与开发理解的是否一致

老王突然问道：小明，你喜欢吃米饭还是喜欢吃馒头啊？

小明：我们广东人喜欢吃米饭。

老王又问：那如果你让你女朋友做米饭吃，她给你端上了一碗粥，你是感觉？

小明：王总，我没女朋友~但是如果发生这种情况的话，我心里肯定是非常恼火的，让她再去做一份。

老王：嗯，产品经理与程序猿就好比你与你女朋友，如果你没有跟程序猿说清楚，你要吃“米饭”，那最后很大可能会给你端来一碗粥。这个时候你又让他重新做。既耽误了开发时间，又造成程序猿心态爆炸，严重耽误项目正常开展。

这个时候，我们就需要在开发之前，明确我们要的是什么。而在确认需求的时候，可以通过两个维度进行确定（或者说是再次强调）。第一种是用概括的语言，再次强调某个模块的主要作用，关键的功能。这个主要的目的是让程序猿的主要方向不走偏，不会出现要“米饭”却上了“馒头”的情况。第二个是把产品说明文档中描述不清楚的语言再重新组织，并提交给开发。这个也是需要在程序开发之前进行确定的。

小明：王总，那这个需求变更与需求再确认的时间，需要提前多少啊？

老王：这个不是固定的，通常提前一两天就可以了。

充分了解需求变更的成本，尽量降低修改（增加）需求的欲望

“我有个非常好的idea，放在这个版本最少能给我们增加20%用户，你看下这个版本就给做出来吧”。程序猿听到这种话的时候，通常脑里会有1w只马奔腾而过。确实，在开发过程中增加需求，会大大增加开发的时间成本，同时会打乱程序猿的开发节奏。在这个时候，克制住自己更改（增加）需求的欲望是非常关键的，除非按照原来的需求确实会造成严重影响，要不就尽量不去更改（增加）需求吧。

小明：那如果新增的需求确实很好，确实能带来很好的效果，这时候是不是可以放在这个版本中同步开发呢？

老王：那也不行，这种需求，统一放在下一个版本里面进行开发。这种增加需求的快感，会令你陷入新增需求的死循环中。那项目什么时候能上线啊？

小明：哦，明白了。

站立会与周例会

老王掏出了烟，点了一根（现在才点烟，是不是不符合老王的性格啊）：刚才说了那几点你记下来了吗？

小明：嗯，都记下来了。

老王：那我们继续往下说。上面说的那些方法，都是需要开会进行确定的，而在开发过程中，程序猿的时间又很宝贵，那在这个时候开会，我们就需要用到站立会与周例会这两种会议形式。

站立会，听表面的意思就是站着开会，实际也是差不多的。他是一种不局限于地点的开会形式，大家可以在电脑前开会，也可以凑在一个角落里“偷偷摸摸”的开会，甚至于你们一起去厕所开会也是可以的。这个会议主要是由项目经理主导，在上班前，每个成员用1到2分钟，简单介绍下昨天具体干了些什么，遇到了些什么问题，今天要处理什么。而作为产品经理的你，主要的任务就是记录，记录各程序猿们遇到的问题。至于发言，还是算了吧。

而周例会，一周通常会召开两次，一次是在周一上班前，大家聚在一起说明一下上周工作的完成情况、是否按时完成、没完成是因为什么原因、遇到了哪些问题、这个周的计划是什么。而做为产品经理的你，这个时候就需要将这个周需要开发的需求再强调一遍（这个不是必须要说的，可以根据功能重要程度的不同，选择是否需要再次强调）、需求变更的地方说明一下（可简答说明改了那些地方，细节的部分可会后对接）、同时做好记录（主要记录现阶段的程序猿开发遇到的问题）。

小明：王总，花时间记录这么多问题有什么用啊？好费时间啊

老王：这些问题大部分都是需要你去帮他们解决的，你以为开发阶段产品经理很轻松啊。

小明：啊，不会吧。

支持与协调

老王：有什么好惊讶的，就是一些支持、协调的工作，没什么难的。关键是要情商高且勤快。刚才跟你说的，产品经理在周例会与站立会的时候，大部分的工作是记录一些产品开发的问题，而这些问题，不是记录下来就不管了，都是需要你来提供支持并协调其他同事来解决问题的。下面就列举几个常见的问题，说说该怎么办：

需求不明确与需求不合理

关于需求的变更与确认，在整个项目开发阶段中都是一直存在的，不会因为项目评估的仔细，就可以避免。所以在这个阶段，开发找你确定需求的时候，不要有抵触心理，要细心的去讲解一些需求的逻辑，如果不是特别的逻辑问题，尽量不要修改bug。再重复一下之前多次说过的一句话：变更过的需求，一定要有切实可行的落地方案，并记录在PRD文档中。

其他项目突然插进来，影响开发进度

像我们这种小公司，大多数的程序猿都是身兼多个项目的，所以开发中，很容易碰到需要紧急处理的事情。这种情况就会导致项目延期。而要完全去避免这种情况的发生，也是不现实的。所以在遇到其他项目需求插进来的时候，一定要确定这个需求的优先级与严重程度。通常较紧急的bug需要立即处理，一些紧急的活动需求，也是需要安排进行的，优化类型的需求可以暂时放一下。当然插进来的工作耗费了多少时间你需要记录下来，可以作为后面项目延期的理由。

但是在执行的时候，可能就会遇到一些的问题。（1）例如其他产品的产品经理觉得这个需求比较紧急，而你认为也就那么回事。（2）项目经理觉得你过度插手他的日常管理工作。所以在处理这些问题上，就要考察我们的沟通协调能力。

小明：王总，那遇到这些问题，要咋办呢？

老王翻了个白眼：你就不会动动脑子想想？既然项目经理觉得你插手他们的日常工作，那你就提前跟他说一下这些问题是由他出面进行处理还是你进行处理？不过最好还是你亲手处理，因为项目经理对需求的分析能力还是没有产品在行，不过你就算了，新人还是多听听项目经理的建议吧。至于与其他产品经理确定需求是否紧急与重要的时候，可以参考之前提到过的需求四大类：核心功能（bug）、辅助功能（bug）、意淫需求、模棱两可的需求。在这个阶段，基本上只会处理核心功能（bug）。如果你跟其他产品经理无法达成一致意见的时候，可以来找我，老大我帮你出头。

小明：谢谢王总。

项目开发进度滞后，进度评估出现问题

每个人做事情的时候，都不是完美的，所以程序猿评估的项目周期，也不会说一定是准确无误的，总是会因为一个功能没有考虑清楚，而耽误了项目开发进度。这时候项目经理通常会要求程序猿们加班赶进度。但是作为产品经理，在这个阶段也需要出一份力。而我们会做的就是“砍需求”。

当产品延期的时候不超过1周，通常通过加班，能将项目进度追回来。这种情况下，最好是让程序员们加加班，将进度问题解决掉。但是有时进度延期太长，通过加班无法挽救项目的时间，这就需要我们忍痛砍掉一部分无关主流程的需求。保证项目按期上面，并且上线后，再尽快着手安排这些需求的开发。如果你这样做了，我相信程序员们会爱上你的。

还有一种严重的情况，就是通过砍需求也解决不了问题，遇到这种情况你就要尽快告诉我。我好去跟公司层面反应这个问题，看是否能将再进行一定的延期。至于你，就等着扣工资吧。

小明：这么严重？

老王：你以为闹着玩呢？

后端数据接口经常变动，影响前端开发

这个问题非常常见，通常在站立会与周例会的时候，都会提到这种问题。作为喜欢追求事物本质的产品经理，我们一定要发现这些问题的根本原因，这边我也总结了几个点，你好好听下：

（1）后端程序猿与前端程序猿对某一需求的理解不一致，导致需要频繁修改后端数据接口。

这种不一致，通常是这两种情况：

• 后端程序猿理解的需求有偏差，被前端发现，要求改接口；
• 前端对需求理解有偏差，并说服了将正确的接口改为错误的。

（2）后端程序猿本身能力就不足，写的代码经常出现漏洞。

（3）后端程序猿心态崩了，就是不想好好写。

小明：那遇到这些问题，都该怎么做？

老王翻了个白眼：这么简单的问题你自己去想想就好了，别总是让我给你出方案。如果这些问题你处理不好。就白白浪费了我交你的东西了。

人员变动（调离项目、离职、请假），导致项目延期

这个问题就比较严重了，如果人员变动是长期的。你需要找项目经理沟通，找寻项目的代替人。并评估耽误的项目时间，并提出延期。同时在新的程序猿进入项目之前，你还需要将项目的需求再重新对接一遍。

小明：······

程序猿积极性不足，情绪低落

程序猿们也是人，偶尔也会闹闹小情绪。所以在整个开发过程中，我们需要给他们最好的爱，最细致的关怀。

• 多请程序猿们吃吃饭，喝点小酒。程序猿普遍都是很单纯的，试着跟他们交朋友，不是很难。
• 程序猿加班的时候，试着买点喝的给他们，红牛可是他们的最爱。
• 当程序猿加班的时候，尽量不要按时下班，即使你没事情做，在公司看看电影也是可以的。主要是让他们感觉不是一个人在奋斗。你们是一个team。（当然，有家室需要照顾的除外）
• 给程序猿订餐，一起吃工作餐，一起聊美女。你要学会向照顾你女朋友一样照顾程序猿。

小明：我对我女朋友都没有这么好，这也太难了吧。

老王：你有女朋友吗？

小明：之前有啊。

老王：怪不得分手了

小明：······

老王：好了，今天就到这，老规矩，记得关门。

看着走远的小明，老王发出了一声叹息：这！就是一个！毫无保留的我！

小结

开发跟进阶段是产品事情最多的时候人，让自己忙起来，让程序猿静下来。

相关阅读

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

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

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

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

题图来自 Pexels，基于 CC0 协议