优秀产品经理应掌握的4个项目管理要素

熊宝(网名“路小佳”)

欢聚时代高级产品经理,现任YY客户端基础功能产品负责人。曾就职于腾讯,先后担任QQ For Mac、QQ手机版、QQ HD、腾讯微博HD等产品经理。

具有国际PMP项目管理认证,中山大学岭南学院MBA,逻辑思维严密。在处理问题时,会综合各方面得失利弊,选择可接受的损失,避免不可承受的损害,做最有利的选择。

擅长社交领域产品设计,对把握用户心理有独特研究。在陌生人社交、熟人社交、大V影响力方面都有独特心得。近年来,主要研究偶像与粉丝经济。

【精彩观点】

多、快、好、省是矛盾的,我们该做的是全面统筹地考虑问题,做出最有利的选择,从而实现利益最大化。

项目管理有个著名的三角形:范围(多)、时间(快)、成本(省)、质量(好)相互制约,任何一方变动都会引起至少另一方变动。对于互联网产品经理来说:每个迭代的产品功能(范围)、上线时间(时间)、需要投入的人力(成本)、产品上线后的收益(质量)这几方面也是相互制约的,需要综合考虑。

例如,一个产品迭代中包含12个功能,需要15个程序员,共20个工作日才能完成。假设领导突然通知我们,15天之后必须发布,也就是时间被缩短了,那我们有以下几种选择:

1)维持15个程序员的数量不变,把功能从12个砍成9个,相当于成本不变、范围缩小。

2)维持12个功能不变,把程序员从15个增加为20个,相当于范围不变、成本增加。

3)维持12个功能、15个程序员不变,工作时间从目前每天8小时变成11小时,相当于范围不变、成本不变,时间也不变(11小时共15天,跟之前8小时共20天,时间差不多)。

4)维持12个功能、15个程序员不变,开发完成不再测试,直接上线,相当于范围、成本不变,但是质量降低了。

……

从上面的例子可以看到,范围、时间、成本、质量这四者任意一方变动,至少会引起另一方的变动,并不存在“多快好省”的完美解决办法。所以,优秀的产品经理需要对每次迭代的功能范围、开发成本、上线时间、产品质量有全面的认识,在遇到突发异常情况时,能够权衡得失利弊,做出对产品有利的选择——用可以承受的损失,避免不能接受的损害,达到利益最大化。

【实践案例】

十年之前,我们说思科,说微软,说诺基亚。十年之后,我们说谷歌,说腾讯,说Facebook。现在的世界,已不是技术推进革命的江湖,而是互联网改变你我生活的欢聚时代。

2011年,随着iPhone 4的“再次改变一切”,国内对Apple的另一系统Mac也关注起来。于是,在这样一个用户日渐挑剔、产品日新月异的年代,在SNS风起云涌、微博巅峰白热化,在IM老去,喜欢隐身多于发言的时刻,2008年,我成了MacQQ产品经理,同时承担项目经理工作。

MacQQ当时已经两年没更新,仅靠两名开发同事搭建起来的框架,满足用户能在Mac OS下聊天的最基本功能,而视频、语音、表情收藏、传文件夹等扩展性功能完全没有。因此,我作为产品经理和项目掌控者之一,最首先需要决定的就是了解产品现状和用户需求,规划最近几个版本的需求优先级。当时外界呼声较高的功能包括:视频会话、语音会话、QQ表情管理、支持密保登录、区分好友登录来源、讨论组功能、系统消息还原操作、个人信息管理、头像修改、界面美化、传文件夹等。

一个好的产品经理不仅要知道要做什么,而且更要知道不做什么。项目资源总是有限的,包括产品交互、开发测试,我需要平衡范围、质量、时间、成本这四者的关系。在项目团队例会上,产品、项目、交互视觉、开发、测试先对接下来半年的目标达成一致。

时间:为了向外界展示一个全新的产品团队,我们希望保持大概6周为一个版本周期,让外界感觉到我们的改变诚意,所以时间是整个项目开始最重要的因素。在6周的周期内,产品交互提前两周先行,把需求准备好。

范围:先提供优先级最高,能够立竿见影的需求,辅以用户体验,提高MacQQ品牌形象。

成本:每个迭代按照优先级高、中、低需求组合,同时考虑产品、设计、开发、测试人力资源。

质量:内测版本Bug高单100%解决,外发正式版本Bug中单100%解决,提供稳定质量的版本供用户使用。

木桶原理适用于环环相扣的项目团队,任何一个环节缺兵少将,都将导致整个产品的根基不稳。所以每个迭代的需求排期,要综合产品、设计、开发、测试人力安排。合理的排期P0、P1、P2需求应该是金字塔组合。在项目资源有限的情况下,已经安排了重点需求之后,那些呼声高、投入少、见效快的需求,如隐藏在线联系人、好友登录来源区分等需求,必然就是优先处理的需求。

在经过多轮沟通讨论之后,我们确定了接下来半年里的主要版本需求和愿景。

在V1.1.0版本中,因为整个项目团队都是崭新的组合,所以彼此需要磨合期。刚开始,团队存在很多问题,例如:

  • 时间掌控不强:开发前没有做好需求评审,没有详细地评估工作量,导致各需求出现延迟风险,从而影响正式发布时间。
  • 信息沟通不顺畅:例如产品或交互更改了需求,只知会了开发没有通知测试,测试还根据老的测试用例来测试已更改的需求,浪费劳动力。
  • 发布前出现重大bug:常常在正式版将要发布才发现重大影响的bug。
  • 责任不明:有时候会议讨论后,大家会忘记彼此的任务,到记起来时已经耽误了一段时间。

针对以上问题,产品、设计、开发、测试派代表组成了项目团队,每周一进行项目例会,并逐渐形成了以下的改进措施。

(1)梳理需求流程

产品需求→交互出稿,设计团队内部通过评审→产品发需求评审邮件,要求开发、测试24小时内阅读→产品发邮件后的48小时内组织现场需求评审→评审通过,发会议纪要,需求存档,需求进入开发阶段→需求开发完成,产品体验、测试,提出优化建议→开发进行bug fix、体验优化→需求完成。

(2)信息沟通

每天早上项目组都开晨会,沟通昨天工作内容、今日工作内容、需要关注事项,互相了解对方进展。

所有的需求变更,都用邮件发送来实现整个项目组,信息共享;

所有的需求更新,都需要及时更新在tapd和共享服务器上。

(3)风险管理

公司内部环境单一,即使提供了内测版本供用户使用,也常出现重要bug到最后关头才发现的风险,从而导致发布延期。为了解决这个问题,新建了几个500人的超级群,邀请外部用户进行体验测试,帮助我们发现各种复杂环境下才会出现的问题,从而为全国用户提供高稳定性的版本。

(4)责任落实

采取首问责任制,每个需求、bug都只安排一名特定人员负责,由他去推动进展;

做好会议纪要,每次开会都把会议达成结论和需要跟进的事项记录下来,抄送整个项目组,分清责任。

经过一系列的磨合整理,从MacQQ V1.1.0、V1.1.1、V1.2.0、V1.3.0、V1.4.0,整个团队的配合越来越默契,互相信任,彼此间合作越来越顺畅。各个角色知道自己在每一环节需要负责的工作,同时也懂得换位思考,互相体谅,从而促进整个项目团队良性发展。

2011年6月23日,QQ For Mac V1.1.0正式发布,功能包括外界呼声最高的视频聊天、自定义表情管理、支持代理登录等功能,Pony、Tony转发微博宣传,引起外界高呼:腾讯终于重视Mac平台了,MacQQ有救了!

7月15日,在所有leader、开发主力都去台湾旅游的情况下,我身兼数职,协调各外部、内部团队,终不辱使命,顺利发布QQ For Mac V1.1.1性能优化版。

9月1日,QQ For Mac V1.2.0美化版发布,这次重新优化的主界面和聊天窗口简约轻快,让用户聊天的心情都明亮起来。同时,密保登录、自动升级检测、临时会话、群内成员快速查询等重点功能也获得一致好评。在这个美化版里,我们终于可以昂起头对别人说:我们是MacQQ团队!

10月9日,在扣除国庆长假之后,我们四周半内推出了QQ For Mac V1.3.0版本。这个版本提供了精美的单独语音会话功能,改造了用户最常用的消息提醒通知系统,跟Mac整体风格更为贴近!10月5日,伟大的乔布斯离我们而去,没有他便没有现在的Mac OS X系统。我们也许是世界上第一个在软件里纪念Jobs的产品“Thank you,Steve Jobs 20111005”

而当年12月月底发布的V1.4.0版本中加入了实时屏幕分享功能,这是一个集远程协助、屏幕录制、视频通话于一身的功能,这在所有IM中尚属先例,在内测用户中已经获得了很多赞扬之声,认为我们不再是只会复制而无创新的团队。我们团队也将再接再厉,在这两周内继续完善产品,提高产品品牌形象。

【总结分析】

从MacQQ半年内推出5个迭代,把App Store分数从1.5分变为4.5分的历程中,我很好地将项目管理知识应用到了互联网产品的管理中,收获了很多,优秀的产品经理需要具备多方面的综合素质。

  • 范围:他需要有良好的市场敏锐感,能把握用户的痛点,提炼出需求,确定功能的范围和优先级。
  • 成本:他应该具有产品经理的交互设计、细节把握等基本能力,估算出成本,并组织虚拟团队投入开发。
  • 时间:他需要有优秀的执行力和沟通能力,做好风险管理,按照时间计划推动团队向目标前进。
  • 质量:最后,他应该是问题的解决者,处理各种异常情况,保证产品上线的质量。

产品经理应该时刻想着这几个事情:做什么事、做到什么程度、手上有多少资源、什么时候需要发布,而这几个事情之间又是相互制约、相互影响的,因此确定这几个事情的优先级事关重要。我们无法真正做到“多快好省”面面兼得,但可以衡量在不同的阶段它们不同的重要性,综合权衡各方面得失,选择可以接受的损失,避免不可承受的损害,做最有利的选择,让整个项目利益最大化!