业务侧（产品、运营）的项目管理
在腾讯，项目经理的定位和团队对项目经理的期望在不同的项目有较大的不同。我在行政部门上属于研发中心，但在腾讯大致经历过三个阶段的项目管理：
1、研发侧项目管理：偏重研发效率
2、研发侧项目群大项目经理角色的项目管理：7-8个子项目群的管理工作
3、全流程（产品、研发、上线、运营）的项目管理
这篇文章就结合自己的感受说一下业务侧的项目管理，即如何做一个产品、运营的项目经理，从全流程的团队做项目管理工作来提升业务绩效。（个人感觉特别重要，PM的角色应该是一个中立的角色，协调好项目各个角色和诉求，平衡好团队的资源，处理好不同阶段的瓶颈和问题，全流程去做项目管理工作，把团队拧成一股绳。如果把业务侧的内容也协调管理起来，是一种从起点就开始的项目管理工作，最大化项目的【价值目标】，收益价值会很大。如果只是从需求评审再开始介入，项目管理的价值会大打折扣）
基本的基调
业务侧的项目管理，不是去限制产品，压抑创意，而是辅助和建设一个更棒的产品环境和产品团队。
业务侧问题
那项目经理要针对产品的哪些问题或者点进行管理呢？以我个人接触的产品、运营，业务侧不同程度存在以下问题
⦁ 憋大招：策划的产品系统或者形态太大，开发、上线周期长。
⦁ 做功能细节容易忽略产品目标：即先着手画图写文档，描述按钮等交互，而整个功能在系统里面应该承担怎么样的位置和目标，有无可量化的上线预期数据，思考不是太充分
⦁ 调研的数据论证不足：一定程度主观想像用户需求
⦁ 不纯粹：有时偏向如何争取研发资源和上线效率，产品设计的事花的心思较少
⦁ 需求断档
⦁ 优先级
⦁ 频繁的需求变动
⦁ 缺乏规范
为什么会存在以上问题？个人的分析有以下原因：
⦁ 需求的不确定性和复杂性
⦁ 产品成员同样是项目成员，策划水平存在参差不齐的现象
⦁ 业务的LEADER风格对组员的影响非常大
所以针对产品侧的项目管理是特别复杂的，也特别具有挑战性（搞不好就会受到抵触和质疑），以下是我个人特定在我现在的项目下的一些思路（可能有一定争议性，未必适合其他项目，甚至是其他项目未必需要）
建立产品节奏
这个是基础，而且对于复杂的产品管理PM要切入的门槛较低。只有节奏建立起来了，产品人员的产出才是有序的稳定的。在现在我带的项目里面，有三件事情需要项目经理过刻意的固化起来：1、每个月初由PM收集下个月的产品规划和重点 2、每周三组织需求评审。3、分步的上线发布。
收集下月产品规划（面向产品LEADER或者总监），互联网的产品不确定确实非常大，PM也不应该去抵触变化或者去约束产品的思维。产品成员可能会比较讨厌要他确实未来几个月后的事情，因为未来的策划很容易出现变动，一个头脑风暴，一些更好的IDEA出来，可以直接就打破原计划的所有内容。可是没有规划又会导致策划的生产力不足，或者策划内容无重心，产品方向比较随机。那么，未来的规划的度应该把握在哪个点上呢？从个人与产品LEADER的沟通与实际操作，【一个月】应该是比较好的未来规划平衡点，这里有两个原因：第一、下一个月要做的东西努力去想，肯定是可以初步定下来的；第二、下个月要交付上线的策划内容，可能从现在开始（提前一个月）就要开始策划和逐步细化成需求了，（要注意：产品策划也是有工作量，而且从一个IDEA到一个细化可提交研发的需求，周期和工作量可能还不小，策划的质量也是要保证的）。所以PM向产品LEADER收集下月规划，有助于产品提前去划定策划的重点，推进产品侧的执行力和产出。收集完后，PM要注意产品LEADER是否把重点策划及时划分给相应产品成员并及时推进策划案子，如果没有，给予一些提醒。把这个点做好，“需求断档”这样的现象可以尽可能的避免。另外还有一个收获，避免“需求的仓促”，即今天提出一个IDEA下周就要上线，这种仓促产品自身策划时间的是很不足的（来不及细想，需求质量可能保证不了），二来研发长期接这样的需求，进度质量也保证不了。那如何出现了收集完下月规划重点后，有变动怎么办？这个一点都不可怕，要变就变呗，支持有价值和必要的变更，这个时候PM要做的不是挑战产品的变化，而是平时和LEADER多做沟通，产生变化的时候及时的调整资源和人力投入，而且在收集下个月的规划重点时将变化更新过来。
周三评审需求（面向产品普通组员），这个是用来细化产品月规划重点的，这个最好是固化下来，就周三评审，其他时间都不评审。周三还没有准备至可移交研发的，就下周三再评审（马上评审然后必须马上启动的需求，没有那么多）。做这个事情的好处是什么？约束产品成员尽可能的碎片化的产出，规定了周三评审，节奏建立起来了，产品的组员就会加快平时的策划进度，因为周三还准备不好需求，只能下周，他会担心产品LEADER怀疑自己的执行力，也会担心下周三再评审自己负责的需求上线周期变长。这里需要强调的一点：可以全面的想清楚一个大功能，但可以分块的进行细化和分块的进行评审。即一个功能如果是十分庞大时，第一周可能想清楚大概有哪些点，初审，和研发说大体要做什么内容（但不启动开发先，可以有一些技术骨干介入，了解有没有技术风险和做初步的设计），第二周并细化好核心玩法，将核心玩法先评审；第三周细化好了这个功能的另外一个模块，再评审；第四周，如此循环，直至整个大功能全部评审完成。这样没有压抑到产品对功能的规划，而且前面评审完的需求，在后续的几周就在实物的产出，产品在有实际产出验收的时候还可以辅助他去策划和修改后面的功能细节。相反的例子我也遇到过？没有周三评审环节，评审时间不定，有良好自控能力的产品问题不大，但如果自控不强的产品，问题就来了：前期研发不饱和，集中式的产品策划中。中期抛出一个很大的东西，评审后需要做好几个月。后期启动开发后，发现评审的东西很多停留在IDEA层面，有很多细节的点反复讨论，甚至有些点技术实现不了。这种状态是比较糟糕的，首先在前期产品执行力和产出可能不会太好，因为落实到每个产品组员，可能会想“我在策划了”什么时候要出来又是没有时间要求的，所以做快做慢就会就变成依赖每个组员的能动力上了。第二评审的内容太大，预期上是移交研发了，但这个时候的评审可能是【无效的评审】，如果需求内容存在异议，当多人挑战的时候，或者确认细节发现有问题的时候，需求已经是无效不稳定的状态了。第三，由于内容很大，整个团队都会往大里面做，即研发也是设计了一个巨大的东西，中间过程没有产出和可供产品验收的内容。奋斗了很长时间做出来的东西，产品一体验流程发现和之前想的东西不一样，流程需要变动，无疑又多了一项没有必要的变更。
分步的上线，如果做了月规划和周三的评审，研发也会有将功能分步的准备到“可上线”状态了。这里，只要研发分步产出了可上线的功能内容，是否分步上线发布就是发布策略的问题了。这个由内容的粘合度来决定这种上线策略：如虽然是每个功能分步准备至可上线状态，但功能之间要完成才能发挥这个内容的价值的，可以全部放一起，做一个完整版本，最后发布（举例：如微信朋友圈，发朋友圈、赞、回复和评论，每个功能无论是否是分步准备至可上线，最后还是要一起发布，因为如果只发布一个发朋友圈没有赞和回复的功能，这个东西可能就玩不起来了）。但功能和粘合度不高，或者是只要核心玩法存在，其他附属功能有没有并不影响核心玩法，那么都可以分步的进行上线发布。我们在做具体需求的时候，有较多的是优化内容和独立需求，没有必要让B内容耽误了已经完成的A内容的上线时间。这也是符合敏捷里面的【可交付的增量用户价值】思想的。
分解产品目标
这是一个以结果和目标导向的思维。通常情况下目标是不成问题的，成问题的是分解和执行，即分解和执行没有弄好，导致目标没有办法实现。这里有两个核心：大目标的分解 小目标的积累。
大目标的分解
每个月收集下一个月的规划，其实这就是一种大目标分解的过程。这不过这个分解是分步的，即每个月一次，分步的分解是让我们更有把握去实现大目标，而且在过程中可以作出判断和调整（因为分步分解，出来的成果是否达到预期，是否要在下一个月做更多的内容，可以有一些判断）。
另，在临近KPI考核的前两个月，我做了这样一件事情：和两个项目的产品LEADER和运营LEADER做一个KPI分解的图。互联网产品，在明确长期做的内容很难。但不久后就要KPI考核了，离KPI大目标的差距有多大，我们手上有多少可以打的牌和资源，这个是相对明确的。提前的去分解这个大目标，更有利于我们充分利用好手上的资源，打完应该打的牌，没有牌就创造牌。
小目标的积累（更重要）
小目标（一个功能和产品目标或者是一次阶段性目标）的积累有两种情况：可计算、不可计算。两种情况是不同的做法的。可计算，即针对“有经验值、有参考、有类似形态的产品或者竞品”。不可计算，指“创新性的，没有参考的”。
前者（可计算），因为有参考，可以引导业务成员多去找相应信息，这样业务成员心里先有目标（这个东西能否做得成，大概可以做到多大，还没有策划最好有个量化的目标，即预期收益），后面对着目标来策划细节的产品功能，上线后再比对之前的预期目标。这样只是从意识上给产品成员引导了，但力度还不够，不过的是有什么形式能够让这种意识在落地的时候比较好操作？个人推荐公式化；举例：产品组员A提交了一个“评论”的需求，这个是很多产品有类似形态的，有参考的一个东西。应该引导产品在目标的达成论证上努力，我和他聊天“这个功能上线，你的预期收益是多少，渗透用户的比例是多少，如果有这样的分析，应该做这个功能的把握会大些，而且你和你领导说这个功能的时候，也更具说服力，他会相信你是认真去做，而且有自己的判断的。怎么去定这个量化的目标，你可以做一个公式：腾讯新闻的评论参透率是多少，然后腾讯新闻和你的产品用户的不同点是什么，得到一个折损或者是提升的系数，你的量化产品目标就是：腾讯新闻的渗透率*系数“。再举例，手机的一个运营活动，运营的目标是拉新总用户N，PM要努力去引导成N=(N1 N2 N3)目标是工式化计算出来的，因为运营的广告点击是多少，这个有参考，点击去到宣传页面下载的比例是多少，这个也有参考。这两个参考加上奖品吸引力的权重再加上活动形式吸引力的权重然后减去一些称筛选用户的门槛就到N这个目标，可以公式化下来。如果工公式化下来后，发现离目标有一定距离，那么想办法去调整有权重的东西，如提高奖品、产品形式吸引力，降低门槛等措施。这样的事情做多了，积累的经验很有价值，判断也会更加准确。反而，如果这块做得弱，文章前面我提的问题“忽略产品目标、数据论证不足”等问题就来了。很容易形成这种状态：产品做一个需求（没有想要达到怎么样的预期），就画图，上线一看，数据不好，然后做下一个需求。运营做一次活动，下手写活动形式，上线，推广，推广后数据不好，做下一个活动（很有可能这个活动流程上有些地方不顺畅的，让很多用户没有办法触达。或者是礼包，广告资源整体上是十分不平衡的，公式化可以在没有做这前就挖掘出这些信息）。这是两个反向的例子是缺乏预期目标的体现，这种状态出来的策划，很容易和其他产品做得一模一样，原因是没有提前分析目标不会有很强的去分析哪些点可以加强以便达到预期目标的，哪些点是可以不要的因为对目标没有帮助，可以节约资源，加快上线效率。而是会以平常见过的其他相应产品形态抄过来，理所当然的认为功能就是应该做成这样的（被其他类似产品功能的形态带着走），原因是产品很容易陷入到里面去，优化的地方通常是边角的打磨，而不是核心的形式的创新。产品运营团队的组员，如果这种状态特别多，对目标的达成，对组员个人能力的提升都会存在不良影响。这样做成功的概率较低。
如果是后者（不可计算），一种创新的形态，比如微信的“摇一摇”，在还没有做出来之前谁也不知道这个东西会怎么样。这种情况目标就拍，拍完做完再看，再调整。这个没有什么好说的，但在我们日常的工作中，很多内容是前者（可计算的）。
要把握住，可计算的尽量去算，不可计算的要回头看，这样在过程中，产品组员能力有所提升，过程结束目标也更好的达成。
启发式的约定
这个更偏向于问题的管理，这里PM要承担起“制定规则”的角色 “监控执行”的角色。因为每个团队的问题都是不同的，而且团队永远是有问题需要持续的不断的优化的。所以启发式的约定，就是针对业务团队的特定事件，特定问题进行一定程度上优化的一个措施。
案例一：我带的某一个项目（我同时带多个项目），策划了一个“战队的玩法”，玩法的大概形式是队长发起召集，队员10秒内响应，后面相互间做一些任务。我没有去判断这种玩法的吸引和乐趣（因为术业有专攻，产品团队有产品的业务敏感度和创造力，PM对这个事去判断吸引力可能很不准确，会害了团队），但基于项目经理风险识别的基因，我觉得这种形态可能会有些门槛，因为规定时间内无人响应，发起者就不想再次去发起，东西就玩不起来了。于是我推动并和产品经理一起做了一件事情，策划的数据论证：我们收集了战队这个形态的数据分布，结果发现80%的人是没有加入战队的（这样这个功能只能面向20%的用户了），然后50人以下的战队又占了绝大部门（这样50人的一个战队，安装了APP的算10人，10同时打三的算3人，这时要队长开了APP并发起召集，另个两个人10秒就进行响应）。这种数据的形态，决定了这种形态的产品策划就一个伪命题。如果没有这种数据的论证，没有发现这个问题就策划了这种形态，那很可以花几个月的整个团队的奋战，最后的回报为0。而且出现这样问题的时候，也不是提高研发效率可以解决的问题。这个例子很典型，这个时候PM要和产品LEADER多沟通，形成一种约定，约定就是“功能策划要有数据论证的过程”，而且在后面的需求评审中，PM要去监控是否是按这个约定来的，没有的时候给予必要提醒。
案例二：我们做了一次手机的运营，运营的结果很不理想（我客观的调研了产品LEADER对这次运营活动的评价，打分是：不及格）。运营交出这个成绩，我和产品LEADER运营LEADER一起对这事情探讨，回顾的分析会有很多原因，如上线太紧，活动有BUG；礼包和PC侧共享；广告语设计的吸引力不够；活动时间太长用户后期参与积极性不高，等。我抛出来我认为的一个最关键的问题：“用户被PC分流，即用户可能在PC参与活动也可能在手机参与活动，大部分用户已经在PC把活动做完了，懒得下载手机APP”，让大家来探讨。这个得到了大家的认可，原因很简单，我当时是这样说的“池塘里面有10条鱼，有9条已经被捉走了，剩余1条，然后我们在岸上讨论捕鱼技术，改良捕鱼工具，是没有意义的”。然后我们有了一个约定，手机的运营活动一定要只有在手机才可以进行，要有【独有的竞争力】，就像双11，京东的运营，PC和手机都可以买五折的东西，这个不算手机的运营，但手机下单“少5块”，这才是手机的运营，因为只有用手机才可以用到。这个约定下来了，在以后的运营案子提交的时候，PM要负责起监控，PM都检查一下有没有符合这个约定。
像上面的案子有很多，都是具体问题具体分析，然后成形共识，成形约定，最后在执行层上去加固。大家认可的约定多了，而且也执行下来，那么这个团队做事的套路会清晰（当然不同阶段的重点问题是不同的，如果有一些前期的约定发现不适用了，可以改良或者废弃）。这种约定的价值很大，可以帮助业务侧产品运营同学，有一条较好的路子走，减少重复的踏相同的坑，或者是一些新业务同事入职，也可以有一定的指引，对业绩的达成起到的作用是相当明显的。
附录
上面说了那么多东西，都是关于如何做好业务侧（产品、运营）的项目管理的，这里有四个点需要说明一下。
一：只适合具体的项目，未必每个项目业务侧的管理都这样。在不同的产品或者是业务组里面，方法可能完全不同。比如：可能产品总监是PM晋升上去的，这个时候很可能做产品侧项目管理的时候就是“如何扩展产品成员的视野，或者是如何产生更好的策划IDEA了”（这个是我的假设）
二：这里不是PM可以做一些产品做不到的事情，而是产品在IDEA层面是较好的，PM在方法论是较好的（两个互补）。这样PM最好以项目管理的思维去辅助业务的同事，能够成长更快，建设一个比较好的环境让业务目标更好的达成。
三：有一部分的问题和措施看起来是比较基础的，那为什么那么基础的东西还做得不很好？一方面PM是天天和团队在一起，比较清楚每个角色的诉求，另PM要担当起微调这个团队去做，并守做一起原则。因为虽然基础，但因为关注度不够或者是没有要去坚持，这样会导致一些认同的想法在执行的时候走样。但这个要把握好度，规则应该遵守轻量有效的原则，让产品团队背着包袱走，也是害了产品。
四：这样业务侧的管理工作，要特别注意好关系人的管理，即平时和产品LEADER，产品总监等沟通要是充足的，信息是对齐的，只有PM和产品LEADER和产品总监在一条线上，这样的管理价值才会体现出来。
另，在文章最开始提出的业务侧的问题，如果项目经理能够在上面我说的具体的点深入的落实下去，对那些问题都是有较明显的改善的。欢迎大家探讨。