网易互联网项目管理

我是一个从传统IT行业里走出来的项目经理，在我刚工作的那个年代里，项目还是走合同的，目标和需求还是那么明确的，项目周期还都是一年半载的，瀑布流程运转的还是很溜的，那是个多么“美好”的年代。

后来，也许客户的日子都越来越难了，他们等不了1年半载那么长，他们想要更快的看到IT上投入的回报，他们受够了变更个需求还要走审批，改的多了还老拿合同说事儿跟他们要钱。迭代和Scrum应运而生，项目产品变成了增量交付，周期短，回报快，想改就改，想停就停。

再后来，互联网时代突飞猛进，所带来的不仅仅是变化更快的需求，而是整个市场环境、商业模式，甚至是人们生活方式和思维模式的剧烈变化。同样的，这些变化和不适，反应到了软件产品的研发上、项目管理上。

说实话，面对这样的窘境，我们还没看到特别好的成体系的项目管理方法论可以参考借鉴。事实上，它已经动摇了项目管理在整个产品过程中的作用和定位，由于外部环境的剧烈变化，产品研发迭代的过程已经延伸到了市场运营，这让项目经理们纠结、挣扎也在不断定义和重生。

虽然我们没有成体系的互联网项目管理方法论可以参考借鉴，但仍旧还是有很多好的理论可以学习、实践和吸收， 比如Scrum、精益产品、LeSS和SAFe等等。我们网易杭研的项目经理们，通过学习这些理论，在各自的产品中折腾，不断的失败，不断的尝试，逐渐形成了一些适应互联网的项目管理的方法。虽然它还不完善，也还不完整，但我们觉得同样值得总结下来，分享给有需要的朋友们。

核心目标

首先还是来谈谈项目经理在现在的产品团队中所承担的责任，定位和目标到底是什么？刚接触互联网产品的时候， 我经常有这样几个问题：有了产品经理，还需要项目经理吗（事实上已经有很多互联网公司没有项目经理这样一个角色了）？团队更需要一个有项目管理能力的产品经理，还是一个有产品管理能力的项目经理？到现在， 我们也无法回答这样的一个问题，也许需要，也许不需要，也许都需要！这完全取决于不同的产品，不同的产品团队以及他们所面临的主要矛盾。但是我们在探究这些问题的过程中，我们确立了我们作为网易杭研项目经理的定位和目标。

在产品闭环周期内，提升各个环节的效能（效率、质量），以提高产品成功的概率。

产品经理更注重产品本身，项目经理更注重效能本身， 但无论是产品经理还是项目经理两者都是不可偏废的。

核心框架

在互联网时代背景下，产品的研发也早已不是设计好一个产品，然后花个1年时间研发完成后发布这样的形式。无论是《精益产品》还是《设计冲刺》都有一个最小可用产品的概念去做市场验证，然后增量发布，不断再验证再调整，每次发布可能只有1-2周，甚至早期以天来计。所以相比以前的产品研发，不仅仅要快，还要有市场验证的环节来完成产品的完整闭环。这也是我们曾经对于项目管理专注研发的一个很纠结的点，要不要包含市场运营？怎么做？做到什么程度？现在的答案是肯定的，但是是在项目经理的定位下，围绕我们的核心目标去做市场运营的工作。如下图所示：

上图描述了我们的互联网项目管理的核心框架，包含了产品探索、产品研发、产品运营这三个环节形成一个闭环，围绕着效能的核心目标。每个环节都有其相应的核心过程，核心指标，以及相应的最佳实践。

核心过程

我们在产品探索、产品研发已经定义好了适合网易杭研特定情况的主要过程，而在真实的产品中，项目经理们都是基于这样的主要过程而演化出各自产品的具体流程。换个角度说， 我们也是在基于项目经理们在各自产品中的具体实践而抽象出了共同的主要过程，而成为我们互联网项目管理体系的核心过程。该过程一定程度上是在网易杭研特定环境下抽象出来的，还不一定能够适合到更广泛的标准中去。至于产品运营的核心过程，我们在一定程度上还有争议，还需要更多的经验总结，在此时就按下不表，希望在不久的将来，在我们新的文章、分享中能够具体介绍。

l   产品探索

如上图所示，一个完整闭环的产品功能会经过策划、交互、视觉、研发和验收的过程，而产品策划要对整个过程负责直至功能按照预期上线验收。这里对于产品策划的职责基本上涵盖了产品研发的所有内容，对于简单团队来说，产品策划跟进到细节还是可以做到的。基本上来说，他已经是一个具有项目管理能力的产品经理了。但是对于复杂团队来说，让产品策划跟进每一个协作的细节，着实是一件比较吃力的事情，但是做到跟踪和支持， 却是必要的，但无论怎样对最终上线的功能负责这一点是毫无疑问的。

l   产品研发

如上图所示，一个产品版本（多个功能点）会经过分析、设计、评估、开发、测试和上线的过程，而产品开发要对整个产品版本的过程负责直至上线验收。这整个过程看似是一个瀑布的过程，但并不妨碍我们采用敏捷的研发方式，只不过里面的每个部分是简单略过，还是着重强化，是手工处理还是自动化工具。因为我们可以根据不同团队的现状，采用不同的方式， 甚至逐渐变化演进，根本的目的还是为了达到更好的效能。这个过程在一定程度上是被产品探索的过程所包含的，同时产品策划和产品研发的职责也是有一定的重叠的，但这也没有关系，不是吗？因为他们的目标应该就是要统一的。

l   产品运营

虽然我们还没有完全定义好这环节的过程，但这仍然是我们不可或缺的一部分。因为没有这环节，互联网下的项目管理就没法形成闭环。形成闭环的主要目的就是能够自我验证，自我改进，不断提升产品价值。因为很有可能，产品研发的效率再高，然而无法找到正确的市场定位，这一切也许就是零。这也是为什么我们项目管理把目标定在效能上，因为在方向不确定的前提下讲“效率”是无意义的。但也没有定成“价值”，因为价值真的很难定义，他可以被无限拔高变的很难量化，也很难讨论。比如：一个用户量很大但赚不到钱的产品有价值吗？有，也没有，这得看你从哪个层面和高度来看，对吗？所以我们换成了“效能”，把“价值”的意义限定在了产品本身目标的范畴当中，而产品运营除了推广和销售，还承担了验证和反馈产品，找到产品定位和目标的责任。

核心指标

德鲁克曾说：“如果你无法量化它，就无法管理它”。这些核心指标就是来帮助我们从一定程度上来度量我们这个体系的目标达成情况，从而在此基础之上进行分析比较，不断改进。网易PMO的项目经理们经过了大量的讨论，分别从效率、质量、周期这三个方面给出核心指标。很遗憾，和核心过程一样我们还未讨论出运营侧的核心指标，这里主要还是聚焦于研发侧。

l   效率

投入产出比=完成规模/完成周期的总人力投入

       我们通过定义不同“完成”的规模和各个环节所需的人力投入来进行计算，从而得出不同环节的投入产出比，应用在各个环节。

例如：在产品研发环节，“完成规模”可以定义成已经上线并通过产品策划验收的所有功能大小，而“完成周期的总人力投入”可以是进入产品研发阶段的所有人力投入。而在产品探索环节，“完成规模”可以定义成上线并且达到功能设计预期的所有功能的大小，而“完成周期的总人力投入”除了研发人力还需包括产品策划、交互、视觉等。

这个投入产出影响的因素很多，比如：人力成本，时间成本等等，在一定程度上和我们的闭环周期也有关系，能够帮我们发现很多可能存在的问题。

l   质量

线上Bug数=一定周期内线上环境发现的Bug数总和

这是一个比较简单指标，同样的，我们对于Bug引入的环节的不同，来定义不同环节的质量

例如：在产品设计过程中就引入的bug，还是研发过程中引入的bug。

l   周期

产品交付周期=产品功能从开始策划到验收上线的时间

研发周期=产品版本从计划开始到实际发布的时间

这两个指标，分别从产品探索环节和产品研发环节，来衡量产品的响应能力或者说是自我调整的能力。我们经常说现在的产品研发要“快”，更多的其实是指交付周期，这也是一个非常重要的指标。

我们网易杭研的项目经理们， 也会经常讨论，以上的几个指标统计出来了之后到底有啥用处？其实，这也是针对我们项目管理所提出的目标，所关注的效能分解出来的一定程度上来描述产品情况的最核心的几个数据指标。它们能帮我们发现，从项目管理角度产品目前是否出现了问题或者需要改进，通过进一步的分析具体的原因，决定是否需要采取措施，采取什么措施。而指标数据本身好看与否，其实并不是最重要的事情，更不适合作为绩效考核的唯一依据。

网易PMO最小数据集

l   基础数据的定义

名称	定义/计算方法	Jira取值
计划规模 Story Point	周期初计划的所有Story的Story Point之和	在一个周期开启时，由项目经理手动填写在story下的“storypoint”字段中， “storypoints”，有数可以取到总的，项目经理在版本开启时到有数上取
实际规模 Story Point	周期末实际的所有Story的Story Point之和	1.在周期内，story发生需求变更引起规模变化时，项目经理手动修改对应的“storypoint” 2.在一个迭代点release时，项目经理到有数上取总的storypoints
完成规模 Story Point	周期末所有关闭的Story的Story Point之和	点release的时候，项目经理手动到有数上取
内部bug数	周期内发现的所有开发阶段的Bug数之和（除去invalid和duplicate的）	Jira上导出（QA工程师处获得）
线上bug数	周期内发现的所有线上环境的Bug数之和	Jira上导出（QA工程师处获得）
计划研发周期	计划的版本开始时间和结束时间的长度（工作日）	——
实际研发周期	实际的版本开始时间和结束时间的长度（工作日）	实际研发周期 : 取release时的值

l   最小数据集的定义

指标	计算方法	期望的趋势	潜在负面影响及推荐用法
完成率	（完成规模/ 实际规模）*100%	意义：指示周期内需求交付的情况 期望：完成率逐步增高	一味追求完成率，可能导致DoD制定及执行不严格、可能导致质量的降低  人天的规模计算，受制于人员技能等，推荐逐步向故事点过渡
需求蔓延率	（实际规模/ 计划规模）*100%	意义：指示周期内需求变更的情况 期望：需求蔓延率逐步接近于1	一味追求需求蔓延率，可能导致业务拥抱变化能力变弱 过程中可能发生需求划变更，推荐及时记录说明，但不应影响蔓延率分母
延期率	（实际研发周期 - 计划研发周期  /  计划研发周期）*100%	意义：指示团队按期交付情况 期望：延期率逐步趋近0	一味追求按期交付，可能导致质量降低以及规模缩减  过程中可能发生计划变更，推荐及时记录说明，但不应影响延期率分母
内部bug率	（内部Bug数 / 完成规模) *100%	意义：指示开发过程中的质量，部分指示测试质量 期望：内部bug率逐步降低	开发可能拒绝承认bug，影响测试提交bug 在开发没有提升改进前提下， 此数值可以大体衡量测试质量 两者互相制衡，以期获得客观有效的bug
冒烟通过率	（通过的冒烟用例/全部冒烟用例）*100%	意义：指示提测质量 期望：冒烟通过率上升，一次冒烟达到100%	较为坚定支持冒烟通过率100% 应谨慎对待冒烟用例的选择，过多过细的冒烟用例会造成冒烟滥用 ，过少的冒烟用例会无法起到主干保障作用 ，冒烟测试不应引起开发测试的对立，妥善引导
线上bug数	期望线上bug数逐步降低	期意义：指示线上质量 望：线上bug数逐步降低	出于团队绩效的博弈，可能线上bug情况会有漏记少记  部分bug可能因为过于细小而被认定不计入线上bug，可以接受  不同的团队对于线上bug的认定标准不同

l   最小数据集的意义

我们搜集这些数据的目的是为了在一定程度上量化目标，进行分析比较，从而对产品和团队进行持续改进。而这些数据就是在核心指标的基础之上，进行细化或者分阶段，又或者换一个角度进行统计，从各种维度分析找到原因，当然数据的统计和分析还不仅仅限于以上这些数据，只不过我们认为产品研发常规的分析是应该包含这些的，所以也称之为最小数据集。

使用数据统计的项目经理们往往会进入两个误区。

误区一：数据作为评价产品和团队好坏的标准

数据作为对一个复杂系统的评价，是不客观也不完备的，至少我们所统计的或者看到的数据量是远远不够的。如果抱着评价一个系统的方式去看待数据， 那么很容易就会使用数据来对人员和团队进行绩效考核并反推他们“改进数据”本身，而非实质意义上的改进。而另一种态度是承认数据无法完整评价人员或者团队，从而对于统计数据就产生了怀疑，甚至于不愿意去统计数据。这两种态度都是对数据本身的作用误解，我们是要拿数据去监控和发现问题，并对他们进一步分析，从而采取有针对性的措施，进行改进，而非评价。

误区二：忽视忽略数据所展示出来的问题

我们刚开始统计数据，数据的结果往往不是我们想象的那样漂亮，而是偏离标准非常远。有一种情况就是我们会认为这是一种可接受的现状，并对数据所展现出来的问题进行选择性的接受。而数据展现出来的问题是不是一个需要正视的问题，是应该由我们对这个问题做进一步的分析，有必要的时候需要再把这个数据分解（分阶段、分角度、分场景等等）来找到产生这个差异的真正原因，从而采取一些必要的措施，逐步改进。当然也许这个数据展现出来的问题，并不是一个真正的问题，那么我们就该思考是否还有必要保留这个数据指标，并用真正合理的算法和指标来取代他。

当你们看到这里， 我相信你们内心还是充满了疑问，还有很多问题这里并未作出解答或者提及。因为我们网易杭研的项目管理部在这方面本身还在不断的探索和实践，以上也只是我们目前所总结出来的经验，特别是在产品运营和产品探索这部分， 我们还没有彻底研究透，实践的还远远不够。我们还会在这几个方向上持续的探索和实践，相信在不久的将来会有更多的内容补充进来。

我们作为项目经理在这样一个日新月异的时代是挣扎和痛苦的，但同样也充满了机遇和挑战。事实上，所有的行业或者是职业都面临了颠覆性的变革，打破并重新定义。在这条挣扎和痛苦的道路上，我们会携手同行，共同探索出一条新的互联网项目管理之路。

本文来自网易实践者社区，经作者钟欣授权发布。