在产品迭代中，产品经理要负责相关产品开发周期和进度的把控，进行跨部门协调和沟通，最终保证新版本按时上线，这就需要产品经理具有项目管理能力。今天，我们就来聊一聊项目管理。

本文结构如下：

项目管理不单单是在产品开发过程中进行，在对一个项目进行管理时，开发前的需求传达，项目排期，以及开发中的跟进开发，都是非常重要的，做好以上几点，版本按时上线也就不难了。

一、需求传达

由于程序猿们没有经历需求筛选，需求分析等步骤，因此当产品经理决定上一个新功能时，一定要和程序猿们进行完整的需求传达。在需求传达时，我们可以按照项目背景以及功能流程进行介绍。

1. 项目背景介绍

在进行项目背景介绍时，我们要清楚的告知程序猿这个新功能所针对的目标用户是谁，使用场景是什么，以及这个项目解决了用户什么需求，总结下来就是5w1h：who、when、where、what、how、why（谁，在什么时候，在哪，解决什么问题，如何解决的，为什么去解决）。

为了形象而具体的讲述以上几点，我们用讲故事的方式为程序猿进行讲解，假设这次增加的是线上减肥课程的功能，我们可以这样来描述：

“小明是一个26岁的白领，每天到了公司就是开会、敲键盘、赶项目，典型的脱发人群。小明每天下班就已经不早了，再加上地铁和走路的时间，经常很晚才到家，长期劳累且缺乏锻炼的生活使他体重上涨，为了健康，也为了找女朋友，小明痛下决心要减肥。

但是由于小明每天下班晚，回家的路程又远，没有整块的时间去健身房，自己在家练吧又找不对方法，这使得小明非常苦恼。

而我们这次上的新功能呢，就是帮小明这种没有时间去健身房，也不知道该如何减肥的人完成瘦身目标。你看：小明下班到家后，只需要打开手机app，选择适合自己的减肥教程，然后跟着教程进行训练就好了，训练完后还可以将系统生成的图片进行分享，发送到朋友圈中让大家来监督他减肥。所以我们这个功能不仅帮小明节省了往返健身房的时间，还帮他免去了请私教的钱，是一个真真切切服务用户的功能。”

用讲故事的方式来描述项目背景的好处是，可以更好地把对方带入到使用场景之中，从而能感同身受的理解用户的痛点。最后在说新功能好处的时候，可以稍稍夸大一点，这样可以激发程序猿的工作热情，让程序猿觉得自己在做一件非常有意义的事。最好我们讲的故事能让程序猿产生“跃跃欲试”的心理。

2. 功能流程介绍

项目背景介绍完了，程序猿们对项目也有认同感了，接下来的就是功能流程介绍了。

功能流程介绍分为业务流程介绍和数据流程介绍，业务流程介绍是站在用户的角度上来展示用户是如何使用的，按照用户的操作顺序，对照流程图进行讲解。比如：小明到家后打开APP，根据自己的需要选择相应的课程类别，选择类别后出现属于该类别的课程列表，然后再选择具体的课程进行训练，训练结束后系统将生成的图片供用户分享。

如下图所示（已忽略所有异常情况）：

业务流程介绍可以简短一些，只要让程序猿了解功能点和页面都有哪些就可以了。

需要详细介绍的是数据流程，毕竟程序猿是天天跟数据打交道的，在介绍的时候要按照逻辑，以数据流为主线进行介绍，让程序员们知道每一个数据都是哪里来的。比如首先要在服务器存储相关的课程数据，在用户进入app选择课程类别时，前端向服务器索要有关课程类别的数据并进行展示，这里用UML序列图展示：

在我们在按照数据流讲解完之后，程序猿就能比较清楚的知道自己要做一个什么功能了。到这里，需求传达就已经基本完成了，其实需求传达属于需求评审中讲解的内容，需求评审结束后，我们就要着手准备项目排期了。

二、项目排期

在进行项目排期前，我们一定要提前把原型和文档等资料交给程序猿们，最好在需求评审之前就开始让程序猿们提前熟悉，这样可以尽快的明确开发工作量。

1. 明确工作量

在这个阶段我们的主要任务就是和项目经理进行沟通，确认什么时候可以进行项目排期。因为在需求评审后需要给程序猿们一段缓冲期，程序猿们会利用这段缓冲期更仔细的了解需求，并思考开发方法；缓冲期结束后再进行项目排期。缓冲期的时间尽量让项目经理来定，我们不要太多的干预，程序猿对需求研究的越透彻，思考的越全面，在后面的开发中才会越顺利。

在经过缓冲期后，程序猿们基本已经对项目的工作量了然于胸了，这时程序猿往往会提出一些建议，出现最多的情况有以下两种：

1. 程序猿希望对需求提出异议（比如页面交互，以及部分流程）；
2. 程序猿希望砍掉部分需求。

针对第一点，我们一定要耐心听完程序猿修改需求的理由，千万不要觉得需求分析是自己的职能，他们提建议是在多管闲事，想把一件事做到面面俱到是很难的，有时候程序猿提的点子正好是你没想到的地方。当出现这种情况时，不要着急给答复，回去将程序猿给出的方案和之前自己的方案仔细对比一下，选出一个最优的。如果你觉得程序猿给出的建议更好，那么就采纳程序猿的建议，同时更新文档并告知其他团队人员。

如果是第二点，那么就要分情况讨论了，如果是不那么重要的需求，可以放在下个版本，如果是自己本身也模棱两可的需求，那么直接砍掉就好了。但如果是核心需求，那么坚决不砍，绝不让步，核心需求是下个版本最重要的部分，是万万砍不得的。

当把工作量弄清楚以后，下一步就是确认开发顺序和开发时间。

2. 确认开发顺序

这里主要需要确认的就是先开发哪些功能模块，后开发哪些功能模块，这里注意，有了开发顺序才能进行项目排期。

在确认开发顺序的时候，我们仍然要和项目经理进行充分沟通，明确本次开发中有溢出风险的模块，也就是说出了问题会严重影响其他模块乃至整个产品上线的地方。

举个栗子：假如我这次做的是一个智能穿戴设备的APP，那么最有溢出风险的模块是哪个呢？

不是注册登录，也不是数据显示，而是设备与手机进行蓝牙连接的模块：注册登录我们可以用第三方登录来解决，如果数据展示因为工期问题做不完，我们也可以砍掉部分展示数据以保证按时上线。但蓝牙设备连接是不可能砍的，这是智能穿戴设备功能的基础。

所以说，蓝牙设备连接就是有溢出风险的模块，在开发顺序中一定要放在前面，这样我们就可以先对蓝牙连接模块进行测试，这样出现问题时可以提前解决，不会影响其他功能。

3. 确认开发时间

当确定好开发顺序后，我们就可以根据开发顺序来确认每个模块的完成时间了，用甘特图是一个不错的选择，制作甘特图的时候，我们需要定任务，确职责。所以在表中我们要写明任务，负责人，起止时间，以避免后期的扯皮。

而在开发过程中，前端在进行框架选取及页面开发的时候，是不需要后端提供数据的，在后端进行数据库设计以及编写接口的时候，也是不需要UI设计师切图的。因此前端开发和后端开发是可以并行的，如下图所示：后端的横向柱状图空缺的部分，是留给他们进行接口调试和bug修改的。

上图这张甘特图只是举例，在实际的工作中，可以按每个模块来划分，将核心的、高风险的模块向程序猿重点说明，在开发的过程中也要更细致的跟进。

如果项目有明确的截止时间，那么我们就根据截止时间来倒推每个模块的完成时间，如果时间实在不够，砍需求吧，程序猿们会感激你的。

三、项目跟进

经过前期的工作，我们终于把事情推进到开发阶段了，那么产品经理在开发过程中会很轻松么？当然不是，我们要对产品的结果负责，当然要对项目进行跟进。

1. 鳟鱼和桥梁

在项目跟进的过程中，我们虽然对敲代码没有发言权，但是我们要时刻清楚地知道项目动态，并作为程序猿们沟通的桥梁，遇到问题时要协调相关人员进行沟通，像鳟鱼一样提高团队的积极性和效率。

项目动态我们可以用每日站立会的方法来进行，站立会表面听起来是开会，但是实际上我们不需要拘泥于开会的地点和形式，我们可以在每天早晨刚到公司的时候和程序猿沟通，也可以午休后在工位上进行，甚至一起上厕所的时候也可以。

开会的内容主要是昨天都做了什么，今天要做什么，遇到或者可能会遇到哪些问题。然后我们要积极的去协调，来帮助程序员解决问题。最好在程序猿开发某个模块之前与他进行需求再确认，以确保最终开发出来的东西是我们心中所想的那样。

在这个过程中，需要我们自身有主人翁意识，灵活而又勤快的去推动项目的进行。

2. 异常情况处理

虽然做足了准备，但还是经常会有异常情况出现，可能出现的异常情况有：

（1）程序员对需求理解有偏差

在项目的开发过程中，经常会出现这个问题，但这不能怪程序猿，毕竟写的再详细的文档，不同的人看也可能会产生不同的理解，还有可能是我们的文档写的不够详细。

针对这个问题，我们应该把主要精力要放在预防上面：

在程序猿开发某一个小模块前，尤其是新出现的或者是重点模块，主动去找程序猿进行需求再确认，再和程序猿讲明需求，也可以让程序猿口述一下需求，我们来听。最终目的就是要确认程序猿已经完全理解了需求，避免后续的更改与返工。

如果在开发过程中仍然出现了对需求的理解问题，比如前端和后端对接口的理解不一，如果你此时不去协调，那么这个问题可能会被搁置，后期还是会爆发出来。还有可能是理解错误的一方将另一方说服，从而造成后期的返工和改动，这是很伤的。

当发现双方有理解上的偏差时，一定要把双方叫在一起讨论，确保前端和后端都能正确的理解需求，再进行开发。在项目开始前一定和程序猿讲明，对需求有任何分歧一定要找你，大家商议解决，而不要私下讨论。

（2）出现需求变更

需求变更，无论是产品经理还是程序猿，看到这个词都会觉得头疼。

出现需求变更的原因主要有三个：

1. 产品经理自己没有思考全面，比如对异常情况的处理不够细腻等等。我们应该尽量避免这种情况的发生，如果总出现这个问题，说明我们的工作是有疏忽的，程序猿也会对你产生不信任感。如果因为这个原因出现了需求变更，去找程序猿大爷说明吧，回来后对自己进行充分反思，并争取在下一次做得更好。
2. 老板要求改需求，这种情况我们看似无能为力，但实际上也是有操作空间的。对于老板的要求，我们首先要仔细的思考利弊，如果仍然觉得之前的方案好，拿出证据向老板说明。如果老板的方案更好，那么我们就要有技巧的向程序猿说明。同样可以利用讲故事的方式，向程序猿说明更改需求的原因与必要性。这时就是考验你和程序猿关系的时候了，没事的时候记得和程序猿们打好关系哦。
3. 自己脑袋中突然灵光一闪，觉得某个功能点有更好的方案。如果是这种情况，哪怕这个方案真的好，哪怕它能提升50%的转化率，我还是建议放在下个版本进行优化，如果我们站在程序猿的角度上想：“需求是你定的，我代码都写一半了，你突然有了更好的点子，然后就让我删除自己辛辛苦苦敲出来的代码，凭什么？”

人非圣贤，谁也不能保证自己第一个方案就是完美的，当有了更好的点子时，我们不妨再增加一个优化版本，反正版本上线后我们也要收集用户反馈，把这个点子放在优化版本里不是更好么？

（3）项目进度延期

当发现项目进度已经落后的时候，我们首先要分析原因，根据原因来寻找解决办法。可能的原因有以下几个：

①团队沟通不畅

如果前期做好了预防，一般是不会出现这个问题的。但真出现了这个问题怎么办呢？此时我们就需要找到沟通不畅的当事人，询问原因，是成员之间不能正确理解对方的意思呢，还是互相不认可对方的观点。

如果是沟通不畅的双方没有办法正确理解对方的意思，那此时我们要做双方的“翻译机”，确保成员之间理解统一；如果是互相不认可对方的观点，那么此时，抓上项目经理或开发主管，一起来商量谁的解决办法更好。总而言之，一定要确保团队成员对项目理解的统一，大家带着同一个目标前进。

②程序猿能力不够

之前也遇到过这种问题，程序猿小A难以完成分配给他任务，这时我们就要叫上技术的大佬，然后让程序猿小A去叙述他遇到了什么难题，让大家一起解决，解决问题的方法我们就不掺和了，做好团队之间的桥梁就好。

③程序猿因为生活上的事导致情绪低落，开发积极性低

我们都是人， 是有情感的动物，难免会因为生活上的的事情影响到工作，这时候，我们要从同事的身份中脱离出来，作为朋友，带着程序猿去吃点小菜，喝掉小酒，聊聊人生，看看美女，没事再给程序猿买点零食，送点温暖。此时对待程序猿要向对待自己女朋友一样温柔，帮他从情绪低谷中走出来，重新振作开始工作，这样无论是对于团队，还是对于他自己，都是有好处的。

④对工期预估过于乐观，项目排期出现了问题

项目排期，其实也是一个预估的时间，谁也不能保证一定可以准时完成，如果是项目排期出现了问题，一般项目经理会让大家用出神技：加班！！

当然此时我们也不能眼睁睁的看着程序猿们加班，我们可以发挥自己的价值：砍！需！求！虽然心很痛，但是看着程序猿们日益稀疏的头发，还是咬咬牙把需求砍掉吧，找机会再加。

如果砍无可砍，赶紧重新评估时间并向老大报告，避免因为自己项目的延期影响到整条产品线。

总结

目前我个人对项目的理解就是这些了，在最后做个总结，要想做好项目管理，产品经理要有以下几个意识：

（1）主次意识

在一个项目里，一定要分清主次，知道哪些是主要的、核心的，要时刻关注的，哪些是可有可无的，可以砍掉的。

（2）风险意识

在项目开始前，我们就要知道哪些模块是有溢出风险的，或者可控性不强的，比如想做智能穿戴设备，如果不打通蓝牙模块，后面的检测心跳，记录步数等各功能都是没有意义的。再比如我们把一部分外包给其他公司，这就属于可控性低的情况下。

因为我们自己公司可以通过加强沟通，加班等方式来解决的问题，可能外包项目就解决不了，出现问题时双方的沟通效率就是比自己公司内部低。如果到项目结尾才开始验收外包部分，此时出了问题很大可能会影响项目的按时上线。

对于高风险部分，我们应该提前做好预案，并在项目过程中对有风险的部分多加关注，将问题杀死在萌芽状态。

（3）时间意识

项目管理，无非就是通过资源的调动来达成目标。资源可以是人员，也可以是时间，而作为重要资源的时间，我们必须时刻关注，一旦失控可能会造成连锁反应。

在时间的管控上面，我们不仅要做好项目时间管理，同时也要做好自己的时间管理，这样我们才能在项目中游刃有余的去应对难题。

（4）沟通意识

其实沟通在本文已经出现很多次了，我们要做团队沟通的桥梁，就要站在对方的角度，用对方能理解的方式和他进行沟通，多用举例进行说明，很多事情直接说可能说不明白，举个例子大家就很容易懂了。

（5）主人翁意识

在项目推进中，是需要我们产品经理和项目经理一起牵头的，我们要把自己当成老板，出现意外时多向下想一步，思考一下表象下真正的原因，然后去解决。

我的诀窍就是：先假设这个问题不是偶然问题，然后站在更高层次去思考解决办法，这样就可以避免日后再发生此类问题。

经常问一问自己：“这是问题的真正原因么？这样去解决以后还会发生么？”要尽自己最大努力，去做好团队中的“发动机”。

作者：撒野的氧气，公众号：产品汪的成长路

本文由 @撒野的氧气 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。