出家如初,成佛有余

互联网运营期产品评审杂思

Posted in 产品管理 by chuanliang on 2011/03/27

    评审制度是互联网产品管理的重要手段,评审制度贯穿于产品管理的战略规划、产品设计、技术实现、产品运营、产品营销等各个环节。可以说高效的评审制度是一个公司产品管理能力的重要度量标准。简单列举一下评审制度的一些价值所在:

  • 通过评审制度可以帮助利益相关方达成对产品建设目标的一致理解;
  • 通过评审制度可以对产品规划方案、产品需求方案、技术方案、运营方案、营销方案等的质量进行把关,提升产品品质;
  • 通过评审制度可以对产品规划建设过程中的关键点、风险点等进行把关,降低项目实施的风险
  • 通过评审制度可以有效提升参评人员的能力;
  • 通过评审制度来对方案进行把关,保证系统产品架构、架构设计的精神始终如一地贯彻下去

     尽管产品评审如此重要,但似乎没有哪家公司的评审制度是高效的,大家都在抱怨评审制度的万千罪恶,评审会议或是演变成了过形式,或是演变成了各大阵营的PK大会。关于评审制度,在各种软件工程的图书及方法论都有所涉及,这里的重点不是讨论评审制度的通用准则(例如产品评审那点事 ),这里主要讨论一下一个平台型的产品在运营过程中怎样通过评审制度来把关。

1、建设期项目 VS. 运营期项目

   对于诸如支付平台、开放平台这类采用了产品平台理念的互联网产品(产品平台),其处于建设期的产品的项目管理与处于运营期的产品的项目管理所面对的挑战不尽相同。

   之所以强调这些产品平台,主要在于对于很多互联网产品而言,主要逻辑就是网站前端,因此这些网站的评审相对容易,只需要采用原型驱动的方式。但对于这些平台化产品,不单纯只是一个简单的网站页面开发工作,这些系统最复杂的逻辑一般在于后端的业务规则、业务逻辑,而这些并不是一个原型就能够说明清楚的。

  1)、建设期项目特征

  • 项目周期相对长,例如1个月以上
  • 项目资源相对于充裕,可以以单独项目组形式运作
  • 项目管理可采用传统项目管理方式或者敏捷项目管理方式
  • 项目前期准备工作相对充裕,例如产品文档相对完整、完整的原型、完整的项目计划、项目立项讨论会/需求讨论会等、市场调研/竞争对手产品分析等等
  • 项目相对独立,受到其他项目的约束较小

  2)、运营期项目特征

  • 周期较短,大部分为2周以下
  • 资源有限,项目组成员可能还要并发维护其他产品

      由于随着公司业务的扩张,熟悉产品及技术架构的人员始终稀缺,这些人一般都去负责一些重点新项目,必须在工作中帮助新人熟悉系统

  • 项目管理一般采用诸如Scrum、XP这样的敏捷项目管理方式,甚至是裁减过的敏捷开发
  • 项目准备并不是很充裕,也不可能准备充足后再做
  • 项目需要在现有产品基础上进行优化、重构,不能影响现有系统。对于运营型产品,产品架构、系统架构的就是在一点一滴的修改中失控、变形的,必须有机制来控制这些因素

   这里重点讨论运营期的产品评审、技术评审的方法。

2、运营期产品评审的原则

  • 不管再紧急的项目都必须做产品评审、技术评审
  • 评审必须保持敏捷性
  • 评审的形式不重要,评审!=开会,评审的形式可以正式评审、也可以为非正式评审。评审最核心的是需要有熟悉系统、有能力的人对方案进行把关
  • 评审的目的不是找到最优的方案,而是在现有资源约束下最合理的方案
  • 没有完美的评审制度,关键在实践中持续优化评审制度,建立适合自己公司情况的评审制度及跟进措施

3、运营期产品评审的方法

      对于运营期的产品评审而言,并没有最佳的实践方案可供参考,每一家公司都有自己现实的业务状况,不同的业务模式有不同的评审方式。可以说对运营期的产品进行高效评审是门平衡的艺术,必须均衡管理规范性、敏捷性、业务现实的要求。只不过整体而言,运营期产品评审的方法核心都是相同的:基于团队协作前提下的持续完善。

  • 运营期的评审制度需要运营期的产品研发流程支撑。应当制定针对运营期产品研发的简化流程(相对于建设期的产品研发流程而言),以便从其他流程环节的收集暴露评审制度的问题,来保证产品评审制度的持续优化。例如通过质量测试、运营、销售、营销等环节的反馈,发现评审制度失效的项目,纳入到案例库,持续优化研发流程、评审制度
  • 建立必须进行评审的硬性标准,细化成可量化的checklist形式(简单为第一准则)

       例如开发时间1周以上或少于1周但涉及重点业务模块的都必须过评审。之所以要采用工期及影响1刀切的方法而非采用接口人来评估是否需要评审,主要是避免太多的人为因素导致评审制度流于形式。

       对少于1周且不涉及重点业务模式改动的,由负责人来自行判断。

  • 评审必须有利益相关者参与,不能单纯让产品人员、技术人员自己评。例如:产品方案必须有技术人员、运营人员、财务人员等;技术方案必须有产品人员、架构师、业务专家等。参与评审的利益相关者有权将方案打回重做。当然这有涉及到另外一个更大话题:团队协作问题,如果一个团队无法建立信任关系,那再完美的制度都会变成PK会。
  • 评审人不需要做全面评审,只对需求关键点、关键业务规则、风险点的方案做评审,以保证评审的高效性。评审结果需要记录相关的流程表单中。
  • 建立评审案例库,定期(每月)过评审案例库,持续优化评审制度。评审案例的总结对事而非对人,不要让评审人有必须对结果全面负责的负担。

   一个制度的执行不在于制度最初定义得多么的完美,关键在于制度能否持续不断地优化。持续优化/持续改进/持续完善 是各种管理方法众所周知且行之有效的核心秘密之一,但也是最难贯彻执行的,尤其是相对于那些管理时尚流行语,提持续改进太没新意、太没高度了,于是乎我们都指望有“银弹”来解决面临的各种问题。

 

从Flipboard Killer:zite看产品竞争策略

Posted in 移动互联网, 产品管理 by chuanliang on 2011/03/12

    号称Flipboard Killer的Zite在3.10日发布了第一个版本。如果说Flipboard以杂志式的阅读体验引领了ipad上新的阅读模式,而Zite则通过基于社会化关系的个性化推荐方式在Flipboard光环下获得了引爆点。与Flipboard类似,在发布初期由于用户量过大导致服务器容量不足的问题在Zite身上也遭遇了,可见其火爆。尽管在功能上及操作界面仍然略显粗糙,但基本上能够看出Zite关于移动终端阅读的野心:基于社会化关系的个性化推荐阅读方式

    与此同时Flipboard在3.10也发布了其1.2版本,主要变动如下:增加了社交搜索、集成Instagram、速度加快、增加了Wired.com和Pictory新合作商、增加了特别推荐。由此可以看出,Flipboard目前的战略重点主要还是集成各种社会化应用及内容源,并以其创造性的阅读体验方式展现出来。

    对于类似于Flipboard这样的产品而言,其产品的发展战略应该大致如下:

   以愉悦的阅读方式成为ipad上最佳的阅读工具,成为大部分用户的首选->集成更多的社会化应用及内容源,成为用户的信息入口->引导用户逐步导入其社会化关系,积累用户的阅读习惯->基于阅读的个性化推荐(包括广告推荐、用户推荐、内容推荐等)。也即从所谓的social graphs 演变成interest graphs

    大部分山寨Flipboard模式的产品基本上采用以上的竞争战略,例如国内的Zaker、鲜果联播等,于是乎都可以标识为:另外一个Flipboard。除了在内容源上有所谓的本地化优势以外,似乎看不出他们与Flipboard有多大的差异。

   在操作体验上,Zite仍然借鉴了Flipboard赖以出名的杂志式的阅读体验方式。但zite并没有像Flipboard、Zaker那样从成为最棒的google reader、twitter的阅读器开始,试图做一个“更棒的Flipboard”。这也是刚使用Zite时候最不适应的,按照Flipboard的阅读器模式去看待Zite,找Google Reader、Twitter的内容目录入口,找了半天都没有找到。

   Zite之所以能够从Flipboard的光环下脱颖而出,就在于其没有按照Flipboard模式的战略步骤来做, 如果说Flipboard的战略是从内容->社会化关系->社会化推荐,而Zite的战略就是直接从社会化推荐来做,通过将google reader、twitter作为用户兴趣的初始内容源及初始的社会化关系,从而获得用户初始的兴趣爱好及社会化关系,产生推荐,有效避免了推荐引擎的“冷启动”问题。相信后续Zite会引导用户导入更多的社会化关系,这样相应的社会化推荐会更加精准。

   一点体会:

  1、产品定位真的很重要,尤其是在当下山寨盛行的年代,与其成为一个更好的第二者,还不如选准一个细分领域做区隔,成为这个细分领域的领先者。Flipboard是ipad上最棒的杂志式阅读模式的创造者,Zite是ipad上最棒的社会化推荐阅读的创造者

  2、做产品必须控制自己的欲望。所有人都在哲人状地说:“少即是多” ,要懂得取舍。但轮到我们自己做产品时候,我们总是怕少了这、少了那,觉得每一个功能都是最佳的竞争点。很多时候我们不缺少所谓的创意,我们缺少的是进行取舍的智慧和对自己欲望的自制

3、山寨与创新只有一线之隔,区隔山寨与创新最重要的因素是洞察力和智慧。山寨只是试图原封不动地抄袭别人的所有优点和缺点。洞察力让我们能够看清楚别人产品下的产品气质,进而明白别人产品的设计理念,最终明白别人产品战略布局;智慧让我们找到最适合的产品定位及竞争策略。对于曾经的山寨者如今的创新者来说,这个过程可以称之为“标杆学习”

 

关于人员预算的一点思考

Posted in 管理杂思 by chuanliang on 2011/03/05

    做年度规划时候,习惯性按照“新做多少产品/项目,每个产品/项目需要加多少人”的思路汇总各产品及项目组的人员预算,汇总后发现人力需求总数高得很不靠谱。先抛开人员预算问题,按照以往的人员招聘经验,要在短短几个月内招进那么多人也很不靠谱,除非降低招聘标准,只要是有点经验的就行。

    于是只能够对各产品/项目上报的预算进行压缩。只不过此过程很痛苦,所谓“手心手背都是肉”,毕竟收入、毛利指标高挂头顶,按照每个项目可能带来的收入、毛利来度量,感觉每个项目都重要, 都可能带来很大收益,要是压缩掉所需要的资源,就可能对产品研发、运营带来较大影响。

    然后考虑按照所谓“资源池”方式进行人员复用;对各项目组上报的人员预算平均压缩编制;调整项目优先级,对低优先级、尚不确定的项目暂不考虑添加人手等方式进行人员压缩。最终倒是压缩了一大部分,感觉压缩的空间也不大了。此这过程也很痛苦。

    然后公司层面基于各种因素考虑,对各个部门的进人指标来了个一刀切的方案,不考虑各个部门要做多少重要的项目,只从公司层面按照盈利角度考虑确定了今年所能够增加的最大人员数,然后分解到各个部门,发现所得到的指标与预算的指标差距极大,要用这些指标来完成所要做的事情,简直是不可能完成的任务。

    只不过要增加指标已经不可能了,于是乎只有梳理目前的产品及项目,一来了解各项目的任务,得到实际的人员需求;二来看能否提升各项目的效率。

    尽管一直感觉团队管理上还行,整体效率还行,平常也注意团队的培养,项目进度的监控,只认为对项目情况也了如指掌。但仔细梳理项目,尤其是借助外力来帮助梳理,一下暴露了很多问题,甚至有点触目惊心。我们所谓的效率已经最大化的想法只不过一厢情愿而已,所有的团队都有提升效率的空间。最后不可能完成的任务其实还是能够完成的。

   一些感受:

  1、团队管理时候,我们习惯性指望通过增加资源的方式来解决问题,但增加资源恰恰是造成团队内耗、效率低下的重要原因,我们经常高估自己的管理能力,低估团队快速膨胀所带来的管理挑战。考虑问题时候,应当首先从提升效率角度来考虑问题的解决而非从资源的角度来考虑

  2、单纯依靠通过增加人员来提升团队生产力的方式只能适得其反,尤其是团队管理能力低下的情况下。团队生产力就像海绵里的水,只要愿挤,总还是有的。

  3、在目标的落实过程中,不需要所谓的“战略高度”、“理论高度”,需要的是“精细化”的管理,需要管理者对于目标落实过程中的各个环节了如指掌,这样才能够为团队成员提供及时的帮助,为他们的成长创造所必须的氛围。作为管理者,我们太把自己当回事,认为自己是主管,不应该管细节的琐碎事情。授权成为了我们最常用的管理词汇,于是我们习惯于在目标分解过程中,将目标的落实简单授权给下级,然后等待结果。管理者对于各项目标的状态都不是很清楚,逐级询问才能够得知目标的具体落实情况。官僚体制在这样逐渐形成,最终整个组织丧失掉作为小公司曾经拥有的对于市场的敏感性、灵活性。

  4、团队目标自上而下分解过程中,保证团队成员对于分解后目标理解的一致性至关重要 ,经常做一下小游戏问问自己及团队,大家的目标真的是一致的吗:让组长写出小组各成员最重要的3件事情,同时让团队成员写出团队最重要的3件事及其自己负责最重要的3件事情,团队成员的答案与团队管理者的答案千差万别

  5、有时候看似简单粗暴非理性的管理方法可能反而是最有效的,尤其在面对挑战性的目标时候。面对挑战性的任务,我们有太多的道理和托辞,习惯性地从资源角度来论证目标的不靠谱。在我们每一个人内心深处都有一堵高高的墙,这堵看似无法翻越的墙决定了我们所能够到达的高度,也圈定了我们自己的地盘。要打破常规获得高速发展,首先要推倒我们心中的这堵墙;要获得更好的平台,首先要摒弃“我的地盘我做主”的观念,要有气度拥抱外部的各种挑战。没有挑战就没有成长。