大部分的互联网公司，是没有项目经理的，所以PM同时需要承担项目管理的角色，而项目延期似乎是个经常发生的事情，明明一个月的计划，结果一个半月了还没能上线，老大怒了过来问责，产品怪技术开发不给力，技术怪产品老改需求，班也加了，吵也吵了，各种扯皮，最后问题还是没解决，同事之间矛盾还加深了，下个项目还是该延期延期。
这个问题，看起来挺难解决，个人认为，主要原因还是在于需求负责人即PM缺乏项目管理的思维，没办法啊，作为需求发起人，这锅PM不背谁背呢？
但是，其实这个事情也没有那么难，下面我就分享一下自己的项目管理经验，总结起来为32个字：目标清晰、流程合理、需求明确、沟通充分、计划细致、行动到位、取舍有道、预案完备。
鉴于项目管理的复杂性，32个字有点多，不过也不算不精练，而且确实有用。
1、目标清晰
任何一个版本也好，需求也好，一定是有目标的，作为pm，不仅自己要明确目标，而且要把目标灌输给参与开发的每位同事，让他们明白在什么背景下为什么要开发这个功能，能说服开发尽量说服，尽量统一目标，目标统一后，团队会更容易形成合力。实际上或多或少会有些开发同事不理解，觉得这个需求没必要做，这也没关系，你至少说服了开发老大吧，让开发老大搞定这件事情。
2、流程合理
这个貌似没什么好说的，每个公司每个团队，由于业务模式和团队文化不一样，流程也会不一样，没有标准答案，但一定得有流程，不然就会乱。
3、需求明确
这个对PM有些要求，也很关键，需求明确包含两个方面，一是要有边界，那些功能点是这个版本做的，哪些是不做的，哪些会涉及到服务端、客户端、后台工具，都需要明确列出来，这有助于开发同事准确地评估工作量；二是逻辑清晰，可以没有非常细致的文档，但是围绕角色、场景、需求下的核心用户流程，逻辑分支，以及特殊情况下的处理方式，都需要明确定义，这个工作有助于你进一步理解需求，有问题及时修正，后续改需求的可能性就会减少很多。
4、沟通充分
沟通不等于说得天花乱坠，更不等于简单的告知，沟通的时候要明确语境，更要考虑别人是否已经理解，从而减少并尽量信息不对称，举个例子，曾经有一个同事暂时离开会议室的时候，我让他帮我把桌上的手机带过来，结果他给我拿过来我的iphone，实际上我想要的是我不常用的安卓手机（桌上有两个手机），我潜意识里是要拿安卓手机，但是我并没有表达出来，同事理解成我想要拿经常用的手机并没有错，这就是信息不对称。这里推荐一本书《沟通的艺术》。第二是要多沟通，尽量面对面沟通；第三是沟通完了要有结论，并尽量通过邮件发出来。
5、计划细致、行动到位
这两个放一起说，是因为好的计划和有力的行动是分不开的。计划细致，首先要将计划拆分到任务和模块，尽量细（可以按照原型、ui、前端、服务端、测试进一步细分），然后做一个计划表格，表格中得包含三个要素：事件、负责人、截止时间，即每一个任务落实到人，落实到时间，然后周知大家，让大家确认是否ok。
然后就是行动了，这时候pm要承担监工的角色了，根据计划里的时间节点，最好每天下班前和关键节点的同事聊聊，任务是否顺利，有没有碰到什么问题（有些开发同学碰到问题不喜欢和同事交流，一个人在哪吭哧吭哧搞，会浪费很多时间），有问题拉出来大家一块讨论，及早解决，pm不要是最后一个知道问题的，得有些预判，一旦到了时间截止点再发现就晚了，项目必然延期。
6、取舍有道、预案完备
项目眼看快要上线了，开发告诉你碰到了一个比较麻烦的问题，能解决，但是比较费时间，这时候pm得做出一些评估，问题是否会影响核心体验，如果不是，尽量舍弃，留到下一版优化，产品优化是个持续的事情，不要吊死在一颗树上，按时上线与时间赛跑才是王道（当然影响核心体验了还是要坚持的，哪怕项目延误）。
产品开发的过程中，要随时做好出状况的心理准备，这在产品开发中是很正常的，但是有预案就不会手忙脚乱，比如突然发现服务器不够用怎么办？因为开发评估工期问题，导致工期不够，是否可以砍掉一些需求？这些都是相对常见的问题，多经历几次就会明白。
下次，你的项目还会延期么？
