整理这篇内容是因为最近的一份工作中，加入的时候团队刚刚组建，工作中成为了团队的负责人（除了没有实权），后来就被迫承担了大部分的项目经理工作。

表面看锻炼了自己，有了话语权，但是产品经理同时兼任项目经理的最不好的情况是，*为了避免延期而做出砍功能的决策，但往往砍功能又会陷入另一种困境。为了打造最佳的产品体验，每一个功能都有对应的作用，如何决策又成为了一个难题。*在吕克•贝松的电影《Léon》中，马蒂尔问了这样一个问题：

「人生原本就是如此艰辛，还是只有童年如此？」「始终如此」

这就是我们做项目时候的写照，所有的项目都有风险，风险无法完全避免，我们需要预估风险，并且高效的解决风险带来的问题，才是正解。

先聊聊项目的开发周期问题：

本人非常信奉豌豆荚团队的产品和管理方法，以下就引用豌豆荚成员在项目管理上的一些流程，创业小团队和大公司的小产品团队都可以学习一下。

> 在时间周期上来说，我们归纳为 5 个关键步骤：选方向、定目标、控进度、带团队和排干扰。

1. 立项——定方向：

立项称为Project Brief。团队的产品经理会撰写一个1－2页的文档，然后和执行团队进行评审，如果评审通过，立项就成功了。文档一般包含会包含以下内容：

- 愿景：一句话表达清楚要做什么；

- 分析市场机会和趋势，决定当前策略；

- 确定目标用户的特征和核心需求；

- 现存的解决方案和各自的优劣势；

- 该项目对企业利益点；如果不做该项目，哪些竞争对手会做，对竞争对手的利益点；

- 需要哪些技术的支持和驱动，哪些技术是弱项；

- 人力需求；

- 项目的紧急程度，是否需要快速推进；

- 发布策略；

- 核心衡量指标，用来衡量成功的指标。

2. OKR 体系——定目标

- OKR代表你到底要去哪里，而不是你要去的地方具体在哪里。lzy：你要去的方向，而不是具体地点。

目标（Objectives）：发布有影响力的新功能，将 XXX 产品做成用户可以每日使用的产品。

关键成果（Key Results）：

日活跃用户量为XX；使用XX方式，提高XXX核心指标

- OKR必须可量化

- 目标必须一致，制定者和执行者目标一致、团队和个人的目标一致，OKR跟个人绩效没有关系，因为OKR 系统的结果和每个人并不直接挂钩。

- 通过月度会议Review

- 每季度有一个OKR 的 review，调整的原则是目标（Objectives）不变，只允许调整关键成果（Key Results）

3. 项目管理——控进度

- 整个公司所有人的 calender，包括会议、要做的事情、项目的时间节点都需要及时同步。

- 站立会议 (Daily Sync)：每天进行站立会议，一般控制在十分钟之内，每个人说明自己今天要做的工作，需要什么帮助，有谁可以帮忙。

- 每周总结，团队产品经理要做周报，汇报这周的工作、发布、取得效果以及数据。

- 数据系统统计全公司所有的产品数据和运营数据，数据能够用来验证产品的假设、方向等。

4. 人员管理——带团队

- Re-Organization& 换组

- One on One

- 个人 OKR 和 Performance 体系

5. 兴趣管理——排干扰

- 激发兴趣：产品设计师和工程师们 3-5 人组成一队，在连续48小时的时间里，充分展现工程团队的创意和想像力，完成一些比日常开发更 geek、更有趣的东西。

- 控制兴趣：PolishWeek，让公司慢下来，对已有产品的细节进行精细化的过程。在大量开发和新产品上线的过程中，我们会担心因为走得太快而对产品的细节关注不够。在连续3个工作周后，第4周通常是 PolishWeek。在 Polish Week 的这一周，豌豆荚内部不会进行新产品或新功能的开发，而主要是对现有的产品和服务进行打磨，解决一些细节问题和小 bug，譬如产品内一些字体的统一等等。平均每个 Polish Week 会解决产品中各种 Bug 大约 200 个。

许多人认为，最小化风险就能获得稳定的事业。但是相当讽刺的是，在一个千变万化的世界里，这会是你做的最具风险的事情之一

> 著名的项目管理书《人月神话》提出了一个有意思的问题：在项目中增加更多的人手能不能提高效率，从而在更短的时间内完成项目？100 等于25 乘以4，也等于50 乘以2，这是一种线性计算。但在项目中并非如此。100 人•日的工作量并不会因为开发人数增加一倍而变成50 人•日，很有可能还是100 人•日，甚至是超过100 人•日。

再聊聊有用的套路：

- 找到和每个人都共有的兴趣，跟每个人都有独立的话题可交流，这点非常重要，你既然不能在她的岗位有超过他的知识面，你需要在你俩共同兴趣上，告诉他你比他研究的更为深入，有助于你建立威信，这样比生拉硬套的客套话要有效很多。

- 双方私下聊天时，有意无意的聊聊工作中的困难，看看他们最近在吐槽哪些事情，还可以问问当时他们怼你时到底是出于什么原因。

- 记住自己是团队的润滑剂，每个部门间都会有矛盾，双方往往不能直接就事论事的沟通解决，这时需要你去做和事佬，告诉一方的困扰和需要你去帮助的地方，双方体谅对方。

- 个人会结合自己的喜好，例如出了新的游戏、科技产品、美食，都愿意和团队分享，带团队去吃新的，玩好玩的，加深大家的感情。

- 发现每个人的特点，一般的研发都会有自己的兴趣，有的人喜欢去抠一些底层的技术，他们原因把时间花费在深入研究上，解决你看不到的问题；有的人愿意研究动效，只要你模拟出来，他们就愿意用代码实现；有的人逻辑非常清晰，考虑问题非常全面，他们就更适合做一些逻辑性复杂的流程问题。有的设计爱做创意性的图片，有的设计非常细腻的抠常规界面，大家都有自己的偏好，要去发现并且利用大家的偏好，让每个人都到最好

- 可以和他们讨论他们岗位的专业问题，但是切忌不要越权，或者说你只要和他们的leader去讨论这些问题，例如代码的统一性，设计规范，测试的重点这些问题，否则可能会和他们的leader指定方向不一致，导致双方存在误会。

- 对于不愿意干或者效率低的同事，要勇敢的沟通，沟通无效的情况下再去和团队领导沟通，沟通时要做到旁敲侧击，对事不对人。

- 对于本团队需求来说，及时调整和修改还算比较敏捷，但对于外部业务来说，沟通的成本和修改的成本就大大提高了。

- 把一些基础问题扼杀在摇篮里，不要懒得沟通或者过分放心，因为对方即使很专业，但是也有疏漏的时候，为了避免大家出现问题，产品经理一开始就确认一些细节问题，并及时跟进体验，多与开发人员进行交流，避免灾难。

> -  Master 分支必须是可用的（比如某人提交了代码跑不起来，或者没有经过测试，给其他同事带来了阻碍，就会被要求请全团队喝咖啡）。其次加强单元测试和回归测试，确保每个迭代的研发质量是可控的，后面的测试主要是回归和校验，减轻相互重叠的压力问题。一个月的迭代跑顺了之后，再跑到两周、一周的节奏，整体来看，差不多用了半年的时间，豌豆荚就完全跑顺了这个流程，想快可以快，想慢也可以慢。

尾巴：大多数的管理规则都是限制了优秀的人，与其将有限时间去做所谓管理，不如找到合适的伙伴，合适的环境。只有和更优秀的人在一起，才对得起你的付出。