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

发表于2017-08-03
评论7 1.13w浏览

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

·         初期,一板一眼的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点,大家还保持着亢奋的工作劲头。而也是我们普通的一个夜晚。

 

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

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台