项目管教心得

产品通过定时迭代版本来新增和优化功能，一个产品、版本或功能都是一个个内部项目，如何在一个确定的有限的时间段内，准时高效地交付高质量产品，就显得格外重要。大部分的公司没有内部项目经理，产品经理算是研发团队中最懂管理的人，并且是产品 owner，所以责无旁贷的需要负责内部项目管理的职责。

如果一个产品经理没有项目管理的经验、也没有系统性学习过项目管理的知识，那么内部项目可能面临很大的失败风险。下面总结了几点项目管教心得！！！

避免定位不清晰，目标不统一

项目开始时基础共识没有达成，定位模糊不清；之后的设计、开发因此频繁改动变化；再加上所有人对准出标准目标要求不统一，这些不确定性足够让项目失败。开始一个新的版本迭代，或开发一个新功能，需要在项目开启的时就确定以下问题：

1. 功能价值：实现该功能改变了什么现状，解决了什么问题，能够带来什么价值。如果无法回答或不清晰，那么需要从新调研，甚至停止项目，因为不清楚价值，等于做了没有回报。
2. 功能定位：你做的一个什么样功能，比如基础功能， 魅力功能等。
3. 功能目标：项目结束后，实现哪些功能，这些功能的标准是什么。
4. 开发信息：该功能在哪个版本开发（当一个产品有多个版本时），该功能是内置还是插件等信息。
5. 项目时间：项目时间需要谨慎计算的，避免拍大腿决定。因为时间节点无达给出标准交付物，在某种意义上项目是失败的。时间需要相关人员进行评估，以及留出足够的缓冲时间。
6. 项目成员：项目成员一定要确定，且得到相关人的知晓，因为可以避免后期成员会流动变化，比如成员被拉去临时项目。
7. 项目负责人：确定项目负责人是谁，避免因角色不清晰，导致项目无人负责。或者说确定产品经理是不是项目的负责人。

当上述信息清晰确定后，就可以 Kickoff 了，将上述信息传达给相关人员，作为项目负责人一定要主动、频繁、大范围的传播，让每个人都了解，尽量降低项目的不确定性。

分期完成，避免停滞

产品经理喜欢在一个版本将功能做的尽善尽美，做出让人眼前一亮的功能。但大部分是大招没有憋出，反倒项目延期。产品经理需要遵循 MVP 原则，在项目的定位和目标的基础上，整合现有资源，将最大的价值打包交付，得到项目回报。所以在做需求时候，可以将需求分类分级，尽量在第一期实现基本型需求，而不要在魅力型需求停滞不前。否则项目结束了，却什么成果也没有。

避免成员变动

一个项目的成员不足，加班加点还是可以准时完成。但是如果一个项目成员频繁变动，那么这个项目失败的可能性就很大，主要是两方面原因：一是重复对接和沟通，需要告知新成员的工作内容及各种工作交接；第二是新成员不适合当前空缺或做不必要工作，比如整体代码架构不熟悉，甚至需要修复上一位遗留的 BUG。

项目计划及节点交付物

工作任务的评估难以量化，所以大部分项目成员都不仔细评估工作量，认为评估有什么用，只要准时完成就可以，最后完成不了又说时间不足。

项目前期需要认真评估各阶段所需的时间，并在总评估时长上留出 10% 缓冲时间，再作出详细的项目计划。比如我们经常会低估需求和设计工作量，但是一个正确的研发周期，需求设计和技术设计时间要占整个项目时长的 30% ，如果低于这个时间，那么前期设计工作做的肯定不充分，后期很有可能会频繁修改设计、接口等。

一个项目计划时间少则两周、多则几个月，所以不能最后统一交付，因为最后的交付的可能是一坨?，甚至连屎都交付不出来。所以需要指定项目时间节点，并制定每个节点的交付物，比如使用 TR1-TR7 的研发流程：

1. 需求：产品经理进行用户调研、竞品分析，输出需求列表，并让相关人员进行评估，确定项目内完成的需求。
2. 计划：需求可行性分析、人员安排、时间安排、形成任务书。
3. 系统设计：PRD、技术详细设计（API 、架构图）。
4. 研发：初版本的软件和交付文档，研发尽量分多个阶段进行验收，比如几个子功能一个 RC 版本。
5. 测试与版本迭代：测试进行功能测试，研发进行迭代开发。
6. 封板验证：测试进行回归测试，重要问题需进行评估是否修复。
7. 发布：正式版本软件和发布相关文档。

项目负责人需要每周对这些时间节点的交付物进行进度跟踪和更新，如果发现某个节点出现延期、或交付物质量不符，应该及时找人协助，也要对项目时间进行调整。

直面困难，抛出问题

项目中会遇到很多问题，不要装作看不见问题，也不要想着只凭借自己一己之力解决问题。项目是一个团队合作的结果，我们需要直面困难，专心去学习解决问题，如果项目成员无法解决，需要及时对外抛出问题，找更有能力的人解决，至少让相关人员知道目前的问题，而不是项目成员默默等待。问题和困难不会因为时间而消失，最终还是需要解决，及时抛出和专心解决才是王道。

评审和质量把控

设计被修改是正常的事情，比如交互、样式，或者部分 API。但如果按照设计稿一比一开发，但在功能开发完成后，说设计不对，需要修改。那么各个评审会的时候干嘛呢？我认为主要以下原因导致评审会没有提出问题：

1. 设计稿没有分享传播，可能是忘记、也可能是怕他人提出问题，仅在评审会过了一遍。评审会人员在简短的时间内只会查看主流程是否可行，不会对细节进行深究，所以不会提出更细节的问题。
2. 设计稿和真正使用体验不同，有的问题只有在真正使用后才会发现问题，尽量做到高保真且具备交互的设计
3. 交付物的输出标准不同，可能评审人员认为可通过，但是以老板的标准，可能就会被驳回。
4. 产品对问题没有考虑完善，害怕频繁修改设计稿被开发怼，忍受了一些已知的问题，但在最后交付时被全部暴露。

从需求——设计——开发整个过程，一定要正式认真开好每一个评审会。评审会的资料需要准备充分，考虑详细；在开会之前将资源进行分享，提前找相关人员 review，更要多找老板、或经验更丰富的同事把关；最后就是发现问题及时修改，不要敷衍过去。评审会过完，一定要确保所有问题都解决了，且通知到相关人员。

项目负责人、产品经理、开发人员在一定程度上会有知识盲区，会忽略一些问题。所以项目需要更多经验丰富的人员来把控产品质量，比如高级研发工程师或架构师把控架构、组件、API、高可用等问题；设计师把控界面样式、交互逻辑。如果考虑不周，轻度影响后期拼命修改设计，验证可行性，改架构；更严重的是这些问题在测试发布时都没有显露，在客户环境发现问题，出现事故。

准时验收

项目应该遵循各时间节点的交付物，准时进行验收。验收发现问题时，重新评估问题风险是否影响项目整体进度，如果有影响，需及时反馈和调整。永远不要在项目结束对外解释因为未知问题导致延期。比如某子功能完成后，产品经理需对功能进行验收，设计师需对界面布局样式和设计稿进行对比，测试进行功能测试。一定要避免所有问题在最后发现， 在最后提出。

后记

某个项目是在测试阶段发现很多问题，导致项目成员加班一周才解决，搞得大家身心疲惫。不只是加班累，更重要成员失去信心，对自己的付出产生了怀疑，一个好的产品怎么会后期大量修改呢？

另外一个项目是因为项目定位、目标不明确，又遇到无法解决的问题，结果在项目后期才暴露出来，导致项目长时间延误。

对于一个没有内部项目经理的公司，产品经理或者技术人员作为项目负责人时，真的太难了，因为他们不具备专业的项目管理知识，更没有评估项目风的经验，所以项目很容易失败。

总结： 平时需要多读专业书籍。