作为产品经理（PD）经常会被要求带项目，但项目落地的过程其实并不容易，本文会根据自己的经验和教训作总结供大家参考，先直接甩出观点吧：
如果PD的任务在某一个项目中很重：牵涉到一整个模块或者是一个全新的产品架构，需要做中长期规划，那PD不应该兼任PM的角色去带节奏；即使需要承担，也需要配备产品专员帮助分担产品化的工作量。
创业型互联网企业往往是产品和业务运营为导向，一般都会要求产品经理兼任项目管理的职责，作为主要负责人为产品的开发到上线作最终的负责；
但往往会遇到的问题是，运营/业务/开发往往不受PD的管控，而且互联网PD作为一个相对入门门槛较低的职位往往不具备对于项目的整体大局观及把控能力，承担不了一个把控的角色；
产品的思考模式属于艺术创作型思维，需要专注力并把需求吃透把产品做深，并且和UED及开发有频繁的沟通确保产品目标的一致，而项目管理却是一个把细小事务归类整理、和不同团队沟通任务进度和状态、以及理解每个阶段过程中不同团队遇到的问题，并需要和管理层和全体团队做统一回报以保持信息对称，这是两种非常不同的思维方式。
所以引申出了另外一个结论：
负责把控项目整体节奏的统筹者（项目经理）很难做细分者的角色，反之亦然；不是不能，而是很难！因为思维模式不同。
项目经理（PM）的角色是必需的吗？
必须！
这里的角色不是指人，而是这一部分工作，可单独可兼任。
为了搞清楚这个问题我们不妨看个案例。
第一阶段：不了解项目整体流程，产品出问题独自背锅
为了收入接了个乙方项目，此类项目的通病：上线时间固定、越往后需求变动越频繁、定制化、挤压开发和测试时间、项目成员职能混乱、反正一切乱七八糟项目的毛病都有。有一天晚上业务方提了一个紧急需求，明天早上之前要发短信给30000个用户通知领取装备，开发大部分不在，老版本产品遇到如此大量的短信发送瞬间嗝屁，因此PD秉着“做事为本，用户至上”的高尚品质私自拉开发，在开发老大首肯的情况下搞了临时方案通宵发送短信。
结果TNND乌龙了，短信发错了，造成了PR事件惊动了CEO还被业务告状了……
紧急修复之后，项目上线，业务负责人领奖，PD挨批，孤单失落无力吐槽；于是乎PD把整件事自我消化并归结为流程的问题并反思，缺少产品化流程、缺少测试环节、临时紧急需求没有向上汇报等等……
这是典型的产品对于互联网项目的整体流程不了解所造成的结果。
第二阶段：有流程，但无人统筹并推动项目，造成延期
反思之后经过几次讨论整理出了一套SOP，包括产品开发流程，RACI，包含详细的概念说明和步骤操作，并和所有的职能方进行沟通。
每个节点的职能职责及其交付物都定义的很清楚，并且运营/产品/开发/测试都有各自的负责人来背锅，项目中职能之间的关系平行无上下。
没有运营目标？不做！PRD评审没通过？不做！一切说说清楚了，文档化了再来找开发！开发评估出错了，又延期了，开发的锅不是产品的问题！项目的例会谁来起头？不知道，因为各个职能的负责人都有“自己认为要紧的工作”。
三个项目同时开展，没人牵头每天开会过状态，没人紧盯各职能的任务并跟进交付时间点，结果每个项目评估的时间点全部都delay，依旧是士气低落，依旧是互相抱怨，依旧是需求有变更，依旧是开发提测延期，每个职能的负责人依旧来回抱怨，甚至无力吐槽……
事情并没有变的更好，最后发觉：
在创业公司或者互联网企业，事情几乎不会是按计划地朝着完美的节奏进行，一定会有各种变数影响着YY出来的完美场景的；而项目落地期间，三个臭皮匠往往顶不上一位统筹大局的诸葛亮，必须要有带头大哥带节奏！
所以在初创企业这种追求快节奏快变化的环境下，主导项目带节奏的能力比起这个人到底是PD还是PM来的更为重要！
产品经理如何带项目？
写到这里，其实是PD还是PM已经不重要了，关键是要有跨职能甚至跨项目，统筹大局的这么一个角色。
TA的责任是什么？
任何锅都要和相应的职能一起背，业务逻辑没搞清楚？产品需求范围不停变更？开发进度落后？BUG过多？预判、跟踪并提早和管理层沟通，否则锅统统都要背！
如果这点无法达到，那么这个角色将不会对整体项目的全部环节有紧迫感，Ownership的激励作用将无法得到发挥！
TA的权利是什么？
在项目范围内，所有的职能对其都要有汇报的义务以便了解并把控项目整体进度。
项目成功了，节奏带好了，那么荣誉、成就感、威信、包括自身的能力将大大提升，可以让自己在事业上到达一个高度：一个有能力主管某些重要事件和项目的能力！
而这个角色需要具备几种能力：
1. 拥有制定产品开发流程的能力
首先一般可以把需求任务分为两种，日常/标准
日常需求类似超市中收银处的快速通道，专门为3件以下的购买者设置，这样无需为买了一两件商品而不得不在整车的队伍后面排队浪费时间，需求也是如此。
有的需求虽然很小，比如修改一个按钮，多加一个小功能等大大提高运营效率的需求，或者是紧急的需求，小改动但不做会造成大的影响的需求，可以走快速通道，让开发每周花20 ~ 30%的时间完成。
但是对于标准的需求，比如新的交易链路，新的模块，甚至是新的产品，则需要相对比较严谨的开发流程：
业务/需求分析（MRD）：
绝大部分的应用型IT项目都是把线下流程标准化和产品化的过程，所以需要产品经理和业务操作人员梳理出业务流程；
此阶段主要梳理的内容为：业务需求优先级、流程图；
为了更好理解业务需求可以把背景、痛点、问题等产生需求的原因文档化；
标准需求的分析必须要梳理出流程图！
作为互联网项目，产品经理必须要和业务、设计、开发、测试评审业务流程，且需要业务方以正式的方式（邮件）通过评审定稿业务需求，以进入产品设计阶段。
流程图的技巧会在后续的文章中单独分享。
产品功能设计（PRD）：
根据流程图中的步骤，定义出详细的功能与不同系统之间的接口字段；
PRD可以包含MRD便于理解需求，但是最主要的交付物为：线框图（Wireframe）+ 功能注释
PRD的作用是让需求方了解产品的雏形，让设计知道粗略的布局，让开发和测试清楚功能的细节并在可行性上达成一致。
PRD需要业务、设计、开发、测试一起评审并全员通过让产品目标达成一致，UED、后端开发和测试的排期需要全部给出！
UED设计 + 后端开发：
当PRD评审完成之后，UED可以针对界面开展交互与视觉的设计；
同时，在后端的开发同学理解了功能之后，可以开始搭建数据库与后台的架构，然后设计出接口并直接进入开发；
这个阶段产品经理需要和UED、前端开发的同学频繁沟通以确保产品的前端交互体验符合要求并且拥有可行性；前端开发需要给出排期。
设计稿的评审通过以后前端正式进入开发，此后全部为开发阶段，产品经理可以开始下一阶段的需求分析，设计师资源也可以释放；
前端开发：
从此全面进入开发阶段，前后端的同学会一起沟通接口信息，如果有调整需要重复产品化的流程并让信息在所有的职能之间正式同步；
项目的主导者需要让项目按时提测。
产品测试：
测试包含两部分，一块是测试同学的内部测试，一块是用户测试；
测试同学会根据PRD把所有的产品功能用专业的手段进行验证，甚至包括安全性的和压力测试等等在产品功能以外的内容，测试的同学会想办法把所有的BUG都测到并让开发修复；
用户测试一般也称为UAT（用户接受测试），是从产品的使用者的角度进行测试，一般由业务方和运营进行操作并验收，UAT阶段发现的BUG越少说明开发的质量越高；
测试通过了之后就是上线了，需要提前准备服务器，解析域名。
上线稳定：
项目上线之后的时间段是最让人担心的，因为线上环境与测试环境的不同可能会有无法预期的问题，需要开发人员随时待命等问题出现时立马修复。
2. 项目进度的把控能力
上面简单总结了一下产品化的标准流程，是一个框架，一个基准；在互联网初创公司的环境下事情往往不会朝着计划好的节奏进行，要把控项目以下的几点需要做到：
掌握项目及相关的任务状态：
其实就是朴实无华的TO-DO List，任务列表。类似的管理工具和方式有很多，Excel、Omnigraffle之类的任务管理工具等等，可以根据自己认为习惯的、高效的方式进行；
但不管是何种形式，都需要明显包含以下的内容：
- 项目名称，状态，上线时间，各个关键里程碑的时间节点及实际偏差；
- 所有任务的列表，负责人及完成时间
任务列表到底是给谁看？给你自己！
在任务列表清晰罗列的前提下，接下来就是第二种朴实无华的能力：
定期召开状态会议同步状态
是不是期望10天完成的任务，在5天的时候检查一次，在10天的时候检查第二次就全部完成了？别做梦了，如果是重要的任务必须每天过状态，让相关人员表达自己的想法，从而了解项目的真实情况。
因为一般的同学如果一切顺利还好，但是不顺利的话往往会噎着憋着不说，需要主动沟通。
任务的负责人、完成时间没搞清楚的，想办法搞清楚；搞清楚的，追着问状态，笔者也是一位十分怕开会的人，但是得想办法克服恐惧。
还有一点切记，会议是同步状态，不要针对某一样任务或者问题展开讨论，浪费所有不想管人员的时间，类似的工作可以在状态会议完成以后个别单独完成。
沟通的能力是重要的软技能，害怕沟通的唯一途径就是逼着自己去沟通，不对自己狠一点就突破不了。
总结
笔者根据实际经验简单归纳总结了一些从产品经理角度主导项目的经验和要点；另外想告诉大家，工作中更需要的是认真负责的态度和严谨的逻辑思维，至于是产品经理还是项目经理，其实并不重要，特别在初创企业，一人承担多个角色的情况是非常普遍的现象；
只有愿意承担责任，才可以树立属于自己的威望，提升别人偷不走的能力；
多谢各位抽空阅读，随着时间的推移文章还会继续做补充，希望可以帮助到大家。
