一个公式搞定产品延期上线

                                                产品延期上线该怎么办？本文作者结合自身经验，并用一个公式与你探讨此问题。

本人本职为一只产品汪，由于公司工作需要，一人目前身兼三职产品，运营及项目管理。其实对于双PM的岗位，大家应该见怪不怪了，如果不清楚，我在这边来解释一下：
（1）产品经理（Product Manager）
Product Manager的缩写，意指产品经理（产品经理人），又称品牌经理（Brand Manager）。是企业守门员、品牌塑造者、更是营销骨干。它既是一套完善的营销运作制度，更是博大精深的营销操作。产品经理根据用户需求，策划并设计对应产品功能，通过用户需求和反馈分析、数据分析、行业动态等途径，做出产品功能和运营层面调整的岗位。
（2）项目经理（Project Manager）
项目经理（Project Manager)是负责项目管理的专业人员，项目经理负责一个项目的计划，执行及结束关闭。目前，项目经理管理角色在多种行业中得到应用，尤其是在建筑、网络技术、通信、软件开发等行业发挥积极而重要的作用。

一般来说产品经理把PRD和原型图交付给技术之后，就由项目经理介入，来管理产品的开发周期，保证按时上线，但是有些公司会由于人员匹配或者其他问题，直接让产品经理兼任项目经理的角色，不过话说回来，把自己造的娃儿给生出来天经地义，义不容辞，所以承担项目经理的职责也在情理之中，但是每每遇到产品延期，无法按照计划准时上线，这对于整个产品线，甚至公司都是灾难性的，因为可能就是由于这一次延期失去了用户的口碑，由于这一次延期失去了市场的最佳窗口期，由于这一次的延期失去了投资人的信任导致资金链断裂。
为了避免以上事故发生，下面我就把我个人这两年多来的项目管理经验，简称“填坑心得”分享给大家，绝对【独家自创首发】的公式
项目任务量=开发时间*开发人数*工作效率
所以我们来看这个公式，如果我希望要保证项目不延期，那么我们可以从这4个维度去介入：
[ol]

增加开发时间

增加项目开发的人数

提高单位人员，单位时间内的工作效率

减少项目任务量
[/ol]
关于前置条件
对于一个靠谱的产品经理来说，一般交付了PRD和原型文档之后，在项目规定的期限内是不会去变更需求的，如果经常变更，那就说明你本身的产品工作没有做到位，思考不周全。项目的任务量是由产品决定的，所以在项目开始正式开发之前，一定要开一个比较完成的需求评审会，这个会议尽量喊上以下几组人员：
[ol]

运营人员，保证你给产品是符合市场预期的，同时他们也可以提前做好运营计划

开发人员，保证你想做的产品是在他们现有技术能力范围之内的，不然到时候想的好实现不了就又得回头来修改需求（尤其是后端的接口模块化，前端的交互动态效果）

测试人员，保证你产品上线后的可靠性，在全面理解完了你的产品方案之后，会出一份测试用例表，对功能，性能进行全方位的黑白盒测试
[/ol]
（PS：这边一般和UI设计师一起把高保真交互效果图出来之后再进行评审，所以该角色未出现）
这样做的好处是，能规避很多项目后续开发中的风险，产品评审通过之后，各方也就基本都定下来了，不会有太大改动，产品定，则技术方案定；技术方案定，则开发工作量定，人员类型人数定；前面的这些定完，按照招聘进来的常规岗位效率，则开发时间也定了。
全部定完之后，上线的最终时间也就出来了，但是有时一个产品的上线时间，其实不是由开发时长来决定的，它是由市场时机决定的，所以这时就需要项目经理来从中协调和管理了，在这个公式中，其中最大的一个X因素，就是【工作效率】，大部分产品上线延期，都是由于这个因素导致的。接下来我将根据爆发频度，对公式里面的这几个因子进行逐一分析
工作效率
我个人将工作效率中的问题分为两种，一种是个人本身的工作效率，还有一种是人与人之间的沟通效率。
（1）个人本身的工作效率，由自己的岗位技能，工作年限等所决定的，不是一朝一夕就能立马进行提升
解决方案：
组织技术研讨会，对于每次的技术难点问题，每个开发人员自己进行记录，每人每次仅限上会1个问题（为了防止“猴子效应”，也即都指望他人给你帮助，而自己不会动脑子去思考）在组内进行讨论，大家头脑风暴提出可行的解决方案，若扔无法解决，由该组的技术leader将问题记录并上报CTO进行解决，若CTO也无法解决，则会在我们私密的技术方案大牛会上采取悬赏任务的形式，请求外来高手帮忙解决。

（2）人与人之间的沟通效率，这个是可以完成通过团队间的高效协作来弥补掉的
解决方案：
半开放式项目组，将从前端组，后端组，测试组抽调出来的开发人员，匹配在一起进行集中式开发，由于每个人可能身上有80%的任务是开发本项目，还有20%的任务是去修复bug或者是做其他项目的优化等，所以可以分成两块独立的单位时间，比如早上9点到11点集中改bug，下午1点到晚上9点集中做新的项目，这样做的好处是提高了每个人80%的时间内的沟通效率，不用再办公室内到处穿梭，有什么事情可以当面直接喊话，同时发现他人开发有问题时，可以及早提醒，避免推翻重来，对于项目经理也可以一目了然，每天每个人的工作进度，对整体上线做到心中有数。

开发人数
如果遇到项目突然要求提前上线，则可能就会要求增加开发人数，但是这里最大的问题就是，往往一个项目做得快不快不是人数的问题，有些人进组之后也产生不了什么很大的效用，因为工作分的不细致，他无从写起。；又或者项目组里的成员突然要离职，则项目可能就会延期。
解决方案：
[ol]

产品技术同步模块化，产品在设计的时候，就注意模块和模块间的关联度和灵活性，让其结构化清晰，框架合理，技术leader在定技术方案时，前后端数据调用的方式方法，底层数据库表结构的设计都要和产品思维一致，这样便于后续开发人员理解和跟进。

拆分到不能再分，技术leader把每个开发组员的工作人员清单列出来，细到后端多少个接口，前端多少种交互效果等，只有这样每日工作才可量化，才知道每个技术人员加入之后，还有哪些事情可做。
[/ol]
开发时间
如果当你的效率和人员都已经优化到极值了，项目预计还是无法延期，那么就只能增加开发时间，说通俗一点讲，就是要求开发人员加班了。但是加班是把双刃剑，团队氛围好的时候，大家越干越有劲，都期盼这早日上线看到自己的工作成绩；团队氛围不好的时候，则抱怨贬损，离职率大幅上升。所以如何搞定团队的氛围成了我认为的关键因素

解放方案：
给出一套公平，公正，公开的人性化长效机制

人性化：
[ol]

弹性工作制（晚上如果加班很晚，第二天可以晚些来，但是保证项目期内每日12小时工作时间，同时不影响其他开发成员联调进度）

餐贴福利，提供各种水果蔬菜增强加班人员的营养③包加班路费，可以坐的士回家，公司报销④项目按时上线的团建活动，以及优秀个人公开表彰
[/ol]
公开：
每日早上会在公司系统上显示团队内个成员，每天工作实效，以及昨日完成内容及今天需要完成内容（每日走之前，会复查项目组任务清单）
公平：
[ol]

对于任务无法日清周结的开发成员，进行记点处罚，若在本周内能跟进补上进度，则取消扣点

对于提前完成开发任务同时还帮助小组其他人员开发的，进行加点奖励
[/ol]
公正：建立一套类似于游戏中打怪升级一样的经验成长体系，每次项目组完毕之后，就为每个人结算本次的项目点数，累计到自身的总体考核值上，到达指定额度即可完成升级，享受对应级别的工资和福利
项目工作量
如果以上三点都试过了，还是无法保证准时上线，那就只能使出双PM的终极杀招【砍需求】了，由于是产品组里面最了解项目进度的人，项目组里面最了解产品需求的人，所以产品经理这个时候就可以拿出自己的需求池，拿出自己产品功能模块框架图，来进行分级处理了。

解决方案：
对功能进行分级，按照以下4种类型，根据开发的性价比和最终上线时间，进行数量和种类上的取舍吧，有些可能就只能放到二期里面对产品进行迭代了。

[ol]

主流程功能

分支流程功能

异常流程功能

体验升级功能
[/ol]
此时你还需要安慰自己和运营的同胞【没有哪个产品是一上线就是完美，我们都是小步快跑，快速迭代的】（此处呵呵呵呵~~~~）
最后笔者只想大声喊一句，“什么时候能给我做出一个不延期、无bug、高性能、优体验的产品啊！”