研发的那些事4--2个PM的游戏
记得刚工作的那会儿提到PM就是指Program Manager 或 Project Manager,是带领一群程序员去开发软件的家伙。而另一个PM产品经理(Product Manger)则多少不为人知。但是最近几年随着几个互联网大佬的爆发产品经理开始风生水起PM的第一解释逐渐被其取代了。现在整个IT行业但凡做产品的皆有产品经理的身影。产品经理需要确保做正确的事情开发的东东有高ROI满足市场、客户的需求。项目经理则要保证正确的做事能按期做出符合要求的东东。在绝大多数企业这个过程就像是一个2人三方的游戏。首先作为神一样存在的BOSS宣布一系列财务、市场指标和一些与长期战略有关的目标。还常常会提出要出XX产品当然BOSS的产品只是个商业概念XXX时间必须发布画下一条红线越线则死成功则生赏。下图“神”画下了红线游戏开始产品经理先登场将BOSS的愿望图纸化绘出血肉筋骨。一般需要从商业市场和产品三个层次考虑主要有商业需要遵从公司的总体商业目标考虑具体的投资回报和产品的商业模式并绘制一个产品的高层愿景。市场需要根据公司总体业务分析目标行业和客户理解他们的业务工作流程发现问题有什么新问题需要解决以处理的问题解决的是否满意确定机会。产品确定产品针对的细分市场目标客户。针对的市场机会要做的具体功能及路线图、版本计划、运营规划等。以上内容主要变成三分文档BRD、MRD和PRD也有公司会根据需要合作为立项时的需要双方遵守的契约。下图立项及契约。接着产品经理开始推动立项过程固定具体的产品范围要求项目经理对发布结果承诺哦。通常产品经理会在PRD中塞入尽可能多的功能因为要求多多益善是人类的弱点他们代表了客户得为他们争取竟可能多的利益^_^尽可能多的写下来当出问题时可以转嫁责任给项目经理研发团队先求无过。博弈论人性的弱点潜规则天知道…过程中项目经理则尽可能减少、简化功能因为实现太复杂会影响发布少做是人类的弱点没有要求做当客户愤怒时可以转嫁责任给产品经理先求无过。$#%$^…双方通过一轮轮的评审不断在产品范围上拉锯时间则在向红线不断逼近…下图立项的时间在评审中不断游移终于双方达成共识了虽然实际很可能是双方都累了无暇再考虑细节就这么模糊的定了)。产品经理长舒一口气他只需等待发布其余交给项目经理了。但是从立项到发布期间还有N长时间似漫漫长夜让人恐惧因为将发布的东东现在还是一堆纸 …后续都是技术活产品经理有心也无力了。立项结束项目经理接过指挥权。熟练的将任务分解为分析、设计、编码和测试阶段逐步明晰需求细化设计然后实现期间可能还会输出诸如SRS、HLD甚至LLD等文档确认是否走在正确的路上。但是通常会发现产品需求模糊且广大细化需求工作力量巨大导致需求分析时间冗长。需求分析累了或用时太多必须加快进度不得不开始设计。然后因为需求模糊导致设计时再需求和设计间来回摇摆耗时同样冗长还可能因为设计问题缩水、遗漏需求。因为时间原因急忙开始编码期间发现很多需求、设计问题导致时间冗长压缩了测试时间。因为发布日期临近匆匆测试急忙上市终于产品发布了但是客户不满意缺少重要甚至必须的功能性能不佳等等问题一堆。游戏终局常见情况是当然神也是会发雷霆之怒的…