产品迭代过程中，产品经理负责控制相关产品的开发周期和进度，与其他部门协调沟通，最终确保新版本按时上线，这就要求产品经理具备项目管理的能力。今天，我们来谈谈项目管理。
本文的结构如下:
项目管理不仅在产品开发过程中进行。在管理一个项目的时候，开发前的需求沟通，项目的进度安排，开发过程中的跟进都是非常重要的。如果做到以上几点，版本按时上线就不难了。
第一，需求沟通
由于程没有经过需求筛选和需求分析的步骤，所以当产品经理决定一个新的功能时，他必须与程完整地沟通需求。在沟通需求时，我们可以根据项目背景和功能流程进行介绍。
1.项目背景介绍
在介绍项目背景的时候，要明确告诉程这个新功能的目标用户是谁，使用场景是什么，这个项目解决了用户的哪些需求。概括起来就是5w1h:谁、何时、何地、什么、如何、为什么。
为了生动、具体地讲述上述观点，我们用一个故事来解释程。假设这次增加了在线减肥课程的功能，我们可以这样描述:
“小明是一名26岁的白领。他每天到公司就是开会，敲键盘，赶项目。他是典型的脱发人群。小明每天下班都很晚，再加上地铁和走路时间，经常很晚才到家。长期的疲劳和缺乏锻炼使他体重增加。为了身体健康和找女朋友，小明决心减肥。但是，由于小明每天下班都很晚，回家的路很远，他没有全部的时间去健身房，在家也找不到合适的练习方式，这让小明很苦恼。而我们这次的新功能，就是帮助没有时间去健身房，也不知道怎么减肥的小明，实现他的瘦身目标。看:小明下班回家，只需要打开手机app，选择适合自己的减肥教程，然后按照教程进行训练。训练结束后，他还可以把系统生成的图片分享给朋友，供大家监督他减肥。所以我们这个功能不仅省了小明往返健身房的时间，也省了他私教的钱。是真正为用户服务的功能。”
用讲故事的方式来描述项目背景的好处是可以更好的把对方带入使用场景，从而感同身受用户的痛点。最后，在谈到新功能的好处时，可以稍微夸张一点，这样可以激发成的工作热情，让成觉得自己在做一件很有意义的事情。我们讲的最好的故事能让程感到“跃跃欲试”。
2.功能流程介绍
在介绍了项目的背景后，程对人有了一种认同感，然后介绍了功能流程。
功能介绍分为业务流程介绍和数据流程介绍。业务流程简介从用户的角度展示了用户如何使用它。根据用户的操作顺序，参照流程图进行说明。比如小明到家，打开APP，根据自己的需求选择相应的课程类别。选择类别后，出现属于该类别的课程列表，然后他选择具体的课程进行培训。训练结束后，系统会将生成的图片分享给用户。
如下图所示:
业务流程介绍可以简短，只要让程知道功能点和页面是什么就行了。
需要详细介绍的是数据流。毕竟，程每天都和数据打交道。引入时，要遵循逻辑，以数据流为主线引入，让程序员知道每一个数据来自哪里。比如，首先，相关的课程数据要存储在服务器中。当用户进入app选择一个课程类别时，前端向服务器请求课程类别数据并显示。这里，UML序列图用于显示:
在我们按照数据流解释它之后，程就能更清楚地知道他想做什么功能。至此，需求沟通基本完成。实际上，需求沟通属于需求评审中解释的内容。在需求评审之后，我们将开始准备项目进度。
二、项目进度安排
在安排项目之前，我们必须提前将原型和文档交给程。最好在需求评审前让程提前知道，这样可以尽快定义开发工作量。
1.清除工作量
在这个阶段，我们的主要任务是和项目经理沟通，确认项目何时可以排期。因为需求审核后需要给程一个缓冲期，程会利用这个缓冲期更仔细的了解需求，思考开发方法；缓冲期结束后，安排项目。缓冲期的时间应尽可能由项目经理决定。我们不需要过多的干预。程徐苑对需求研究得越透彻、越全面，后面的开发就越顺利。
经过这段缓冲期，基本上知道了程这个项目的工作量。这时，程经常向提出一些建议。最常见的情况如下:
程希望挑战需求；程希望能切断一些需求。鉴于第一点，我们必须耐心听取程修改需求的理由，千万不要认为需求分析是我们自己的职能。他们在插手提建议，很难做到事事都亲力亲为。有时候程的想法恰恰是你没想到的。遇到这种情况，不要急于给出答案。回去仔细把程给的方案和自己之前的方案对比一下，选一个最好的。如果您认为程给出的建议更好，则接受程的建议，更新文档并通知其他团队成员。
如果是第二点，那就要具体情况具体分析了。如果是不太重要的需求，可以放到下一个版本。如果是自己模棱两可的要求，直接砍掉就好了。但如果是核心需求，那就坚决不砍，绝不让步。核心需求是下一个版本最重要的部分，不能删减。
当工作量明确后，下一步就是确认开发顺序和开发时间。
2.确认开发顺序
这里需要确认的是先开发哪些功能模块，后开发哪些功能模块。这里要注意的是，只有有了开发序列，才能对项目进行调度。
在确定开发顺序的时候，还是要和项目经理充分沟通，明确本次开发中有溢出风险的模块，也就是说出现问题会严重影响其他模块甚至整个产品上线的地方。
以栗子为例:如果我这次做一个智能穿戴设备的APP，哪个模块最有溢出的风险？
不是登录或者数据显示，而是设备与手机蓝牙连接的模块:登录可以由第三方解决。如果由于工期原因无法完成数据展示，我们也可以截掉部分展示数据，保证按时上线。但是蓝牙设备的连接是不能被黑的，这是智能穿戴设备功能的基础。
所以蓝牙设备连接是有溢出风险的模块，所以在开发顺序上一定要放在前面，这样可以先测试蓝牙连接模块，这样可以在不影响其他功能的情况下提前解决问题。
3.确认开发时间
当开发顺序确定后，我们就可以根据开发顺序来确认各个模块的完成时间。用甘特图是个不错的选择。制作甘特图时，我们需要定义任务和职责。所以在表格中要写明任务，负责人，起止时间，避免后期扯皮。
在开发过程中，前端在选择框架和开发页面时不需要后端提供数据，后端在设计数据库和编写界面时不需要UI设计师裁剪图片。所以前端开发和后端开发可以齐头并进，如下图:后端水平直方图空缺失的部分留给他们调试接口和修复bug。
上面的甘特图只是一个例子。在实际工作中，可以把它分成各个模块，把核心的、高风险的模块突出给程看，开发过程跟进得更仔细。
如果项目有明确的截止日期，那么我们会根据截止日期倒推各个模块的完成时间。如果时间真的很短，就把需求砍掉。程会感激你的。
三。项目跟进
经过前期的工作，我们终于把事情推到了开发阶段，那么产品经理在开发过程中会很轻松吗？不，当然是我们对产品结果负责，当然还要跟进项目。
1.鳟鱼和桥
在项目跟进过程中，虽然我们没有敲码的话语权，但我们要时刻清楚地了解项目动态，充当成人沟通的桥梁。遇到问题要像特劳特一样协调相关人员沟通，提高团队的积极性和效率。
我们可以通过每日例会来实施动态项目。常务会听起来像是开会，但实际上我们并不需要拘泥于开会的地点和形式。我们可以在每天早上刚到公司的时候和程交流，也可以在午休后的工作岗位上交流，甚至可以在一起上厕所的时候交流。
会议的内容主要是我们昨天做了什么，今天要做什么，遇到了或者可能会遇到什么问题。然后要积极协调，帮助程序员解决问题。最好在程开发某个模块之前，跟他再确认一下需求，这样才能保证我们最终开发出来的是我们所想的。
在这个过程中，我们需要有主人翁意识，灵活、勤奋地推进项目。
2.异常情况的处理
虽然我们做好了充分的准备，但还是经常出现异常情况。可能的异常情况有:
程序员对需求的理解有偏差。
在项目开发过程中，这个问题经常发生，但这不能归咎于程。毕竟一份文件写的再详细，不同的人看的时候可能会有不同的理解。也有可能是我们的文档不够详细。
要解决这个问题，我们应该着眼于预防:
在程开发一个小模块之前，尤其是新出现的或者关键的模块，主动找程再次确认需求，然后向程说明需求，或者让程口述需求。让我们听听。最终目的是确认程已完全理解要求，并避免后续的变更和返工。
如果在开发过程中还存在对需求理解的问题，比如前端和后端对接口的理解不一样，如果这个时候不协调，那么这个问题就可能被搁置，以后再爆发。还有一种可能是理解错误的一方去说服另一方，导致后期返工修改，很伤人。
当我们发现双方在理解上有分歧时，一定要召集他们一起讨论，保证前端和后端都能正确理解需求后再开发。在项目开始之前，你必须向程表明，如果你对你的需求有任何分歧，你必须得到咨询和解决，而不是私下讨论。
需求发生了变化。
变化，不管是产品经理还是程，看到这个词都会感到头疼。
需求变化有三个主要原因:
产品经理自己考虑的不够全面，比如对异常情况的处理不够细腻等等。我们应该尽力避免这种情况。如果这个问题总是出现，那就说明我们的工作疏忽了，程就会对你产生不信任。如果因为这个原因需求有变化，去找程叔叔解释一下。回来后，充分反思自己，争取下次做得更好。老板要求改变需求。这种情况看似我们无能为力，其实有操作空。对于老板的要求，首先要仔细考虑利弊。如果我们仍然认为之前的计划是好的，我们应该给老板看证据。如果老板的计划更好，那我们就得巧妙地向程解释。你也可以用讲故事的方式向程解释改变需求的原因和必要性。是时候考验你和程的关系了。没事的时候记得跟程搞好关系。脑子里突然灵光一闪，觉得某个功能点有更好的方案。如果是这样的话，即使这个方案真的很好，即使能提高50%的转化率，我还是建议在下一个版本中进行优化。如果站在程的角度思考，“你定好了需求，我写了一半代码，突然你有了更好的想法，然后你让我把辛辛苦苦打出来的代码删掉。为什么？”人非圣贤，谁也不能保证自己的第一个方案是完美的。当有更好的想法时，我们不妨添加一个优化版本。反正版本上线后，还要收集用户反馈。把这个想法放在优化版不是更好吗？
项目进度延迟
当我们发现项目进度已经落后了，首先要分析原因，并根据原因找到解决办法。有几个可能的原因:
①团队沟通不畅。
如果前期做好预防，一般不会出现这个问题。但是如果这个问题真的发生了呢？此时就需要找到沟通不畅的当事人，问为什么，是成员不能正确理解对方的意思，还是不认可对方的观点？
如果沟通不畅的双方都没有办法正确理解对方的意思，那么这个时候，我们就要做双方的“翻译”，保证成员间理解的统一；如果你不同意对方的观点，那么这个时候，找项目经理或者开发主管讨论一下谁的解决方案更好。总而言之，我们必须确保团队成员对项目有统一的认识，所有人都朝着同一个目标前进。
②成能力不足。
我以前遇到过这种问题。程很难完成交给他的任务。这个时候，我们就要把技术大佬们叫上来，然后让程和描述一下他遇到了什么问题，这样大家就可以一起解决了。解决问题的方法我们就不介入了，做好团队之间的桥梁就好。
③成因生活苦闷，发展热情低落。
我们都是人，都是感情动物，生活中的事情难免会影响工作。这个时候就应该脱离同事，以朋友的身份，带程吃点小菜，喝点酒，聊聊人生，看看美女，买点零食给程暖暖身子。此时，像对待自己的女朋友一样温柔地对待程，帮助他走出低落的情绪，重新振作起来，开始工作，对团队和自己都有好处。
④对工期的预测过于乐观，项目进度安排有问题。
项目进度安排其实就是一个预估时间，谁也不能保证一定能按时完成。如果项目进度出现问题，一般项目经理都会让大家使出他的神奇本领:加班！!
当然，在这个时候，我们不能眼睁睁地看着程加班加点。我们可以发挥自己的价值:剁！需要！求你了。虽然心里很痛，但看着程日渐稀疏的头发，我还是咬着牙把需求掐断，找机会再加。
如果切不了，赶紧重新评估时间，向老板汇报，以免自己项目的延误影响整个产品线。
摘要
目前我个人对项目的理解也不过如此。最后，我会做一个总结。如果我想管理好项目，产品经理应该具备以下意识:
初级和次级意识
在一个项目中，一定要分清主次，知道哪些是主要的、核心的，哪些是要时刻关注的，哪些是可有可无的，可以删减的。
风险意识
在项目开始之前，我们需要知道哪些模块有溢出的风险或者不可控。比如你想做一个智能穿戴设备，如果不打通蓝牙模块，后面的检测心跳、记录步数等功能就没有意义。比如我们把一部分外包给其他公司，就是可控性低的情况。
因为我们自己公司通过加强沟通和加班可以解决的问题，外包项目可能解决不了，出现问题时双方沟通效率低于自己公司。如果外包部分直到项目结束才验收，此时出现问题可能会极大影响项目的按时上线。
对于高风险部分，要提前做好预案，在项目过程中多关注风险部分，把问题扼杀在萌芽状态。
时间意识
项目管理只不过是通过资源调动来实现目标。资源可以是人，也可以是时间，作为一种重要的资源，我们必须时刻关注时间。一旦失控，可能会引起连锁反应。
在时间控制上，不仅要做好项目时间管理，还要做好自己的时间管理，这样才能在项目中游刃有余地处理棘手的问题。
沟通意识
其实这篇文章里多次出现了交流。要想成为团队沟通的桥梁，就要站在对方的角度，用对方能理解的方式和他沟通，并用例子来说明。很多东西不一定能直接理解，举个例子大家就很容易理解了。
所有权
在项目的推进中，需要我们的产品经理和项目经理一起牵头。我们要把自己当成老大，在出现意外的时候，思考表面下的真正原因，然后去解决。
我的诀窍就是假设这个问题不是偶然的，然后在更高的层面上思考解决方案，这样以后就可以避免这类问题了。
经常问自己，“这是问题的真正原因吗？这个解决方案之后会发生吗？”努力成为团队中的“发动机”。
本文由@ Run Wild的氧气原创发布。大家都是产品经理，未经作者允许，禁止转载。
题目来自Unsplash，基于CC0协议。
