去验收去验收去验收 - 量体裁衣的团队管理

一、项目初期，管理方式的转变

·         初期，一板一眼的Scrum方法。 项目最早期使用的Scrum管理方法介绍。

酷跑团队13年一月初立项。项目刚刚开始的时候，压力很大，当时觉得有种容不得任何闪失的感觉。这个时候团队的项目管理方式，是一板一眼的Scrum敏捷管理方式，每周为一个Sprint，一周开始时Sprint计划，Daily Meeting，Sprint Review。作为PM的我，严格追踪每个Sprint的工作条目和时间计划，总是担心出现意外情况。

那段时间把团队氛围绷的比较紧，另一方面，也是想把这次腾讯移动游戏平台攻坚的压力，让整个团队都感受到。但是需求总是多变的，即使把开发团队绷的那么紧，也改变不了各合作方时间点都频繁变动，以及频繁的更改游戏设计需求。

二、无法应对项目当前情况

因为我们做的项目合作部门太多，涉及移动游戏产品部、平台包括手Q微信等，一共有10多个合作部门。初期平台要承载哪些功能，都是各方boss才能拍板决定的。今天能做后天说不能做这种事情经常发生。

我们是第一批游戏，所以产品的形势与深度（单局游戏深度难度、付费深度等）也是在探索，经常会变。产品要求也很高，UI换过无数遍。酷跑最早的时候是竖版的。在需求的源头无法控制的时候，根本谈不上严格执行与推进，很多设计可能每周都会变。把团队绷的再紧，也改变不了实际情况。并且解决不了计划频繁被打乱的开发特点。

其实前面铺垫了那么多当时的情况，是说明后面项目管理方式改变的原因，由于这样的情况，Scrum的方式已经不足以应付，不得不进行一些项目管理方式的转变；

·         寻找新方法，应对多变的需求。大胆进行改善，用新的方法进行管理；

·         0成本构建。 打碎验收周期，把产品验收与质量提升变成日常工作。

首先是版本，由于产品关注度高。在第一版可以玩以后，老板们要求经常看版本，不同的老板不同时间来看版本。还要求看版本的时候有改进和新功能。并且给老板们看的版本可千万不能Crash。一周一个版本的频率显然不行。

和技术团队讨论下来，我们建立了自动构建服务器。让编译版本成为零成本的工作，随时可以编译一个最新版本下载到设备上运行。随后我会在每日编译的版本中，选择一个版本作为今天的稳定版本。要求质量要过关，没有明显bug，可以进行对外展示。

所有的开发内容，也在每日的构建的版本中验收。要求修复处理明显bug。

这些措施，实际上是把一个Sprint一验收的周期打碎，把Feature验收这件事变成一个项目开发中的日常工作。也许传统的每一个Sprint一次版本验收，与集中时间安排Debug质量完善会显得效率高，但是我们当时的情况，更多的要求是在功能展示频率，与版本开发时间内取得平衡。老板们要体验更多的功能，又要求版本的产出频率高。我们自己又要在长期项目计划上，慢慢的推进游戏完成度。把每周一版本改称每日一版本，目前看来这是最好的方法，对版本质量的提升非常大，即使到了一个要做质量回归和提升的阶段，我们也可以把这个时间变得非常的短。

为何会提升质量？这个方法和后面提及的应对需求变化和团队管理是关联的。

·         去掉迭代 ，需求kick off会议。 抛弃以迭代为周期的开发方式，随时开始新需求。

之前说把版本的验收周期打碎，在天天酷跑的项目管理中，其实我也把Sprint打碎。原因就是需求太多变化太临时。

之前提过，酷跑项目早期的需求变化，基本是不可抗力的情况下。我想到的不是更加紧的和严格的执行迭代计划，敏捷和Scrum的建议都是一个迭代内的需求不变。相反，我们把Sprint和以迭代产出版本为目标的方式渐渐抛弃了。而更加注重日常管理和团队管理。

首先，每周一个Sprint计划经常变更的情况下，三天两头周知迭代变化，团队成员也不会有好心情。取消Sprint，这样也会降低需求变化的严重性，减少反感。

之后的开发过程中我们不开全员的Sprint Meeting，只开一下几类会议：

·         新需求的分析会；

·         开发同事对于代码架构的设计、质量提高以及互相备份的会议；

·         定期美术设计质量Review会议；

·         每天的晨会；

每种会议都会只选择相关同事参与，减少会议人数。后几种会议比较常见。

第一种需求的分析会议上，是策划已经对新需求进行过考虑，策划间已经达成共识的情况下，再请相关程序和美术参与，对需求的讲解，以及边界条件的讨论等。在会上同时能大致得出开发所需要的时间。

每次新需求和需求变更，就开这样小规模的需求会议后，实际也能基本估算出后续功能所需要的大致时间，让PM做到心里有数。然后立刻把新需求加入下一步开发列表中，就像一个堆栈。当然也是有优先级的，每加入或变更一个任务，我们都要对整体任务列表序列排个序，然后着手做最重要的工作。之前打碎的版本构建周期，也能很好的支持这个新的工作方式。

·         对团队提出新的要求。各个职责的团队成员都有明确的工作要求。

对于策划，我们不要求详细的文档，最早期的时候，在白板上画的流程图写的说明，拍了照我们就可以开始开发了。但是要求更加完善和充分的思考。我会要求每一条Feature，有明确的验收步骤，就像小的测试用例。并且，策划对于品质和产品验收需要更加的倾注时间。我常常和策划说，要陪着程序大哥开发。开发的过程当中，不要最后功能出来再验收，要有一点看一点，发现问题及时交流。

美术，除了画画以外，还要关注实现过程，关注产品本身。更加关注使用场景中的美术表现。举例子，我们之前美术制作的游戏背景很精美，但是由于我们游戏是高速移动的，很多人反映头晕。最终让美术自己验收版本，找出原因就是因为背景太过于精美，细节过多。在启动了零成本构建版本以后，美术也可以自己改美术资源，构建版本验收自己输出的效果。这个对品质提升很大。

开发作为最终的输出者，承担了很大的压力和责任。在我们的开发流程中，自己开发的代码合入svn不算最后完成，合入后保证自动构建机上的跑出来没问题才算完成。由于有每日构建的要求，所以一般明显的Bug会在每天的版本里发现。这个也要求处理的即时，影响每日版本的需要当日修复。其余的记录在bug list上，协调修复。如今我们的开发团队已经已经是非常值得信任的团队了。

三、任务推进去中心化

这是传统的项目开发流程，基本是项目经理或者制作人去验收开发成果。

再不愿意承认，再想要亲历亲为，再不想官僚化，一个人最有效的也只能直接负责管理7个人，和7个人以内的交流和负责，才是最有效的。所以，责任一定要分散。在项目开发过程中，我和制作人，并不会去验收每一条Feature；

我保留了Scrum中的Owner机制，为每一个Feature设立一个Owner，一般来说是策划。Owner负责推进Feature中的开发以及美术资源到位和整合等。每一条Feature的开发完成，务必是要策划亲自体验过，验收过，才可以算完成的。而且必须进行一定的DeBug。

并且，我们会有一个定期的整体项目组成员一起Review版本的活动，我们叫做狗粮；所有的Feature，会最终在版本里再验收一遍，所有人一起。

四、不停的梳理前置任务和产品Backlog

其实Scrum 框架在12年加入了Grooming的机制，不知有多少人知道。Scrum当时也是发现了梳理的重要性，然后建议每个迭代专门开一次Grooming Meeting，用来整理 Backlog；

在任务推进去中心化之后，作为PM，工作的相当一部分，其实是放在梳理上。和Scrum建议的不同，在酷跑的项目管理中，我的梳理非常的频繁。在整体的Backlog中，我把前置的工作和后续需要产出策划方案的工作标记的特别显眼。基本每周数次去询问相应的负责同事，更新这些任务的状态。

并且，由于我们产出版本非常多，其实每次版本体验，大家都会有一些新的想法，或者改进的建议，这些都会影响Backlog的优先级。

前面的环节，加速了版本产出，加速了产品验收，去掉了迭代；这个梳理，其实是要求项目经理自己也加速，要做到时刻对时间与内容，都明白团队现在应该做什么；

不停的推进后续策划方案的产出，找出后续哪些是可以先做的，与梳理并且Push前置任务；

更大的周期目标还是要的，比如大时间节点上的要求，测试，提交等。作为PM要对大时间点时刻心中有数。在梳理的时候，常常去Review这些大节点。周知团队大节点的时间。

·         新的闭环

这里总结一下，新需求的需求分析会开始，进行新需求的讲解与评估。然后团队进行去中心化的开发与推进，最后在持续集成和自动构建中一起验收；

另外一个贯穿始终的，就是对于团队和产品的梳理。这样形成一个和原来Scrum框架不同的新闭环；

其实对比一下会发现，整个的周期变得更短。但是迭代短，其实不是关键，后面会再说。

·         改变的对比

这里的对比，是说酷跑现在的管理方式，也就是之前说的新闭环流程，和Scrum框架的对比；

最直接的呢，就是我们版本产出更多。Scrum框架下，其实迭代时间一般是2-4周，而且也不建议再短了，他们觉得2周以上的时间是比较容易让团队有工作节奏感的。当然，这相对传统软件业，版本验收和产出周期已经非常短了。我们这边就更短，每天可以编译数个版本来验收功能，然后每周可以输出数个可以对外展示的版本（虽然要求是每日版本，但还是允许耽搁一到两天的）。

之前说到对质量有提升，由于我们的开发方式，等于是每天都在对质量做提升，因为开发团队整体体验版本的次数，远多于之前的开发模式，所以看到Bug，流程进行不下去，要立即修复，是每天都在做的事情，而且，常常大家在体验版本的时候，提出很多小的优化体验的需求，这些需求如果可以快速完成的，开发也会迅速做掉，而不是到下个迭代做一个优化的需求，这些都在传统的项目管理流程记录里体现不出来。最终，我们的版本完成后的专门Debug时间，可以控制在1 － 2 周内。而且我们也常在提交前三天改需求，甚至在提交当天还改需求。这在以前是不敢想像的。当然，大家也知道天美工作强度是很大的，我们的工作时间比别人长原因之一，也是每天在功能开发完后，做质量提升的工作。

·         交付。项目经理影响项目成败。

至此，从之前的严厉要求组员、逐步按照计划的管理方式，我做了以下几点工作和决策：

·         一周一版本改称每日一版本。打碎验收周期，每日验收增加每日版本质量；

o        加速验收，持续打磨；

·         简化流程，抛弃Sprint规划，“拥抱变化”，随时快速开始新需求；

这样，在各位老板面前展现项目的印象是：一，版本多；二，可以经常在版本中看到新功能。三，质量还不错。

给老板多看版本，项目才有更多的机会。而作为互娱的项目经理，面对内部如此大的压力和激烈的竞争，唯有持续的、高质量的交付，才是项目继续进行的希望。

五、一些秘密

其实前面讲的新的闭环，似乎是一个新的流程，但是其中的概念呢，持续集成自动构建，团队自组织，敏捷；

都不是新概念，谁都知道；

关键在哪呢？在于要让这些环节有用，并且要让团队觉得这些流程是有用的。曾经另一个团队，虽然也是可以自动编译，但是每天构建的版本他们并不看。他们的程序员也不知道为什么要自动构建，就认为是出版本比较方便。所以要从制作人和PM出发，让这个开发方式贯穿在团队开发过程中，真正有用的东西，是留的下来的。

还有我觉得这个新闭环的一个核心，就在验收两个字；更短的验收频率，对产品的提升是之前无法想像的，毕竟策划案只是在构思的阶段，计划也都是一个构思。验收可以提升质量，提升团队融合度，最重要的是可以持续的让团队知道我们就是是不是在开发对的产品。

即使现在，我也基本每天都在和策划团队说，去验收去验收去验收！

六、全速团队

根据上面这几点，基本达成了酷跑团队的项目管理的架构：专注提高整体团队前进的速度与流畅的配合程度，效率达到高了之后，那么所得到产出就可以认为是最大化的产出。

达到全速团队的目标，除了做到上面这些，其实更重要的，是时刻保持团队的氛围。感谢我们两年来始终如一，辛苦付出的团队。

下面这张照片，是一时兴起，拍于某周四晚上的11点，大家还保持着亢奋的工作劲头。而这也是我们普通的一个夜晚。

感谢阅读，希望能够给大家带来一些团队管理上的思路。