研发的那些事42个PM的游戏

记得刚工作的那会儿，提到PM就是指Program Manager 或 Project Manager,是带领一群程序员去开发软件的家伙。而另一个PM产品经理(Product Manger)则多少不为人知。但是最近几年，随着几个互联网大佬的爆发，产品经理开始风生水起，PM的第一解释逐渐被其取代了。现在，整个IT行业，但凡做产品的，皆有产品经理的身影。

产品经理需要确保做正确的事情，开发的东东有高ROI，满足市场、客户的需求。项目经理则要保证正确的做事，能按期做出符合要求的东东。在绝大多数企业，这个过程就像是一个2人三方的游戏。

首先，作为神一样存在的BOSS宣布：一系列财务、市场指标和一些与长期战略有关的目标。还常常会提出要出XX产品（当然，BOSS的产品只是个商业概念），XXX时间必须发布，画下一条红线，越线则死，成功则生（赏）。下图，“神”画下了红线：

游戏开始，产品经理先登场，将BOSS的愿望图纸化，绘出血肉筋骨。一般需要从商业，市场和产品三个层次考虑，主要有：

1. 商业，需要遵从公司的总体商业目标，考虑具体的投资回报和产品的商业模式，并绘制一个产品的高层愿景。
2. 市场，需要根据公司总体业务，分析目标行业和客户，理解他们的业务，工作流程，发现问题（有什么新问题需要解决，以处理的问题解决的是否满意），确定机会。
3. 产品，确定产品针对的细分市场，目标客户。针对的市场机会要做的具体功能，及路线图、版本计划、运营规划等。

以上内容主要变成三分文档BRD、MRD和PRD（也有公司会根据需要合），作为立项时的需要双方遵守的契约。下图：立项及契约。

接着，产品经理开始推动立项过程，固定具体的产品范围要求项目经理对发布结果承诺哦。通常产品经理会在PRD中塞入尽可能多的功能，因为：

1. 要求多多益善是人类的弱点
2. 他们代表了客户，得为他们争取竟可能多的利益^_^
3. 尽可能多的写下来，当出问题时，可以转嫁责任给项目经理（研发团队），先求无过。（博弈论，人性的弱点，潜规则，天知道…）

过程中，项目经理则尽可能减少、简化功能，因为：

1. 实现太复杂，会影响发布
2. 少做是人类的弱点
3. 没有要求做，当客户愤怒时，可以转嫁责任给产品经理，先求无过。（$#@%$^…）

  

双方通过一轮轮的评审，不断在产品范围上拉锯，时间则在向红线不断逼近…下图，立项的时间在评审中不断游移：

终于，双方达成共识了（虽然实际很可能是双方都累了，无暇再考虑细节，就这么模糊的定了)。产品经理长舒一口气，他只需等待发布，其余交给项目经理了。

但是，从立项到发布，期间还有N长时间，似漫漫长夜，让人恐惧，因为将发布的东东，现在还是一堆纸 …后续都是技术活，产品经理有心也无力了。

立项结束，项目经理接过指挥权。熟练的将任务分解为分析、设计、编码和测试阶段，逐步明晰需求，细化设计然后实现，期间可能还会输出诸如SRS、HLD甚至LLD等文档，确认是否走在正确的路上。但是，通常会发现：

1. 产品需求模糊且广大，细化需求工作力量巨大，导致需求分析时间冗长。
2. 需求分析累了或用时太多，必须加快进度，不得不开始设计。
3. 然后因为需求模糊，导致设计时再需求和设计间来回摇摆，耗时同样冗长，还可能因为设计问题缩水、遗漏需求。
4. 因为时间原因，急忙开始编码，期间发现很多需求、设计问题，导致时间冗长，压缩了测试时间。
5. 因为发布日期临近，匆匆测试，急忙上市

终于，产品发布了，但是客户不满意，缺少重要甚至必须的功能，性能不佳等等，问题一堆。游戏终局常见情况是：

当然，神也是会发雷霆之怒的…