Question

一般而言，一个敏捷流程是不需要总监级别的高层直接参与的。但是总监应该对敏捷流程适当干预，一方面要把握重构和产品的平衡，以确保一个“度”，另一方面则要提高人力的利用率，可以从开发效率、座位安排、静时这些点入手，从而让团队始终具有高产出。

10.6.1　重构与产品需求的平衡

App兴起的早期，各大互联网公司都急急忙忙把自己网站的功能搬到了App上，而没有考虑更为长远的事情，久而久之，每开发一个新功能，花的时间很长，质量也不高，App的代码架构急需重构和优化。

本节讨论什么时候做重构。

在我的项目排期中，是永远不会有重构的任务的。我对产品经理的承诺是，优先把所有产品需求都做完。

我一般会在两次迭代的间隙，来进行重构。因为这时候大家都在确认需求制定计划，最忙的是产品经理和项目经理，开发人员是有时间进行重构而不影响项目进度的。

另外，在迭代过程中，会有需求被砍掉或者弱化的时候，省下来的时间也可以用来做项目重构。实践证明，这样的情况是很多的，而以往，由于没有事先规划好，这些时间是被荒废掉的。

每次重构都要事先规划好：

·解决方案

·工时

·影响范围

·测试方案

经常出现重构时没有预估好工时、越做越大、收不了尾的情况——我都见怪不怪了。开发人员总是太自信，以为自己能搞定一切，而不做好规划，殊不知改动越大，风险越大。

好的重构方法是，拆分重构工作，循序渐进，每次做一点。这样既可以尽可能多的完成需求，也可以降低重构的风险。

你可能会说我老了，思想越来越保守了。但你要知道我肩负的责任有多大，对于一个千万级用户的App而言，稍有闪失都会对公司的生意造成重大损失。

10.6.2　提高效率，拒绝6×12

我曾经经历过6周时间的6×12工作制，包括Android和iOS两个项目的Scrum Master，带领着团队艰难地熬过这段时间。

说是熬，一点也不夸张。开始时三周，大家的精神状态还好。三周之后，就发现团队和之前不一样了，主要表现为：

·战斗力急剧下降。

·质量下降，bug激增。

·脾气开始变得暴躁，容易发生冲突。

·每天就是在耗时间。周六基本就是中午来吃个饭，然后四点多就下班了。

·上班越来越晚，午休时间变长，晚餐后还要散步半个小时。

综合而言，表面上看起来是6×12，但实际上只有5×8+4，也就是说，每天实际工作8小时，再加上周六的4个小时。

另一个只有项目经理才能感觉到的问题是，随着开发人员每天的工作时间延长到12小时，项目经理的工作时间会变得更长，每天甚至会超过12小时，因为有更多的项目上的事情需要去沟通解决。我记得项目到了后期，我基本上是7×12的节奏了。

我还发现，违背项目管理流程的是，6×12相当于没有了项目缓冲时间，也就是说如果6×12还是发现有事情做不完，那么就真的做不完了，因为不会让团队周日也过来加班而不休息一天。

6周后得到的经验是，6×12适合于搞突击，但时间应控制在3周以内。想提高开发人员的效率，还要想别的办法。

我一向是反对硬性要求开发人员加班的。研发人员不同于其他工种，他们写了一天代码，需要很好的休息，才能保证第二天继续高效的工作。偶尔加班1~2小时，因为程序员大多吃青春这口饭，所以可以凭借年轻缓过来。但是长期的加班就不同了，只会使得代码质量下降，bug变多。

我曾经计算过每天上班8小时（朝9晚6，午饭1小时不计入）的实际利用率。以下时间是要扣除的：

·上班整理工位、吃早饭时间。

·WC时间。

·饭后散步时间。

·午休时间。

·QQ闲聊时间。

·淘宝购物时间。

·各种被打扰时间，比如线上投诉的跟踪解决、各种紧急会议、其他部门咨询，等等。

其中前4项是不能省的，每项约半小时，那么每天就有2小时不在工作，每天工作6个小时是极限了，但如果算上QQ闲聊和淘宝购物时间，那就只剩下4个小时不到了。

所以，作为团队负责人或项目经理应注意以下几点：

·要减少团队在QQ闲聊和淘宝购物上花费的时间，充分利用好这实打实的6个小时。我的做法是，只要事情提前做完了，剩下的时间开发人员干什么都可以。当然我更鼓励员工闲下来去学校新技术，为自己增值。

·另一方面，还是要控制每个Task的工时，精细到0.5天。拒绝那种有很大水分的Task评估，这就是项目经理的职责了。开发人员往往喜欢给自己留一些buffer，其实半天时间就够了。

·减少被打扰时间。我在微软时，所在的团队有一项很好的制度，每周三下午是Quiet Time，也就是静时。这段时间不和外界任何人沟通，专心做自己的事情，效率是非常高的。

10.6.3　无线部门的座位安排

一种排摆工位的办法如图10-4所示（空白处的表示过道）。

图10-4　无线部门的座位图1

这种座位的排列，对于刚刚成型规模不大的无线部门比较有利，主要体现为：

·App开发人员，无论是iOS还是Android，都可以快速与MobileAPI开发人员进行沟通，联调。因为后者坐在中间位置。

·App开发人员、MobileAPI开发人员、测试人员可以快速找到产品经理和设计人员。

·测试人员可以快速地找到开发人员，尤其是iOS开发人员。

随着人员的极速扩充，以上座位图不能满足需求，一种新的方案如图10-5所示。

图10-5　无线部门的座位图2

这种座位的排列，对于“大兵团”作战非常有利，主要体现为：

·以Android团队为例，他们背靠背坐成两排，有技术上的问题找左右或者转个身就能最快寻求到帮助。

·即使测试人员坐到过道的另一边，仍能快速地找到开发人员和产品经理。

·开发、测试、产品经理、设计人员之间的沟通仍然很便捷。

·每次增加新人，就向两边扩充，比如新来一个Android开发人员，就让他坐在Android开发7的左边。

每个团队招多少人是有预算的，每年年初都定好指标了，所以每年需要调整一下座位。HR和行政人员往往以为招的都是你无线中心的人，坐在哪里都是一样的，所以找个角落随便给安排个座位就算完成任务了，于是你会看到一个团队大部分人坐在一起，而还有2个人分别坐在天南地北的两个角落里，其实这是有问题的，至少说明了在无线互联网飞速发展的今天，全民都已经学会连去厕所都会带上手机把玩自己心爱的App的同时，HR却在工作上未能与时俱进，没搞清楚自己所在公司的无线部门怎么排摆座位才能达到工作效率最高。

如果团队继续扩充呢？这就不是简单的排摆座位就能解决的了。我们知道，任何一个精干的团队，超过8人都是有问题的。首先Team Leader管理多于8人的团队就会捉襟见肘。所以要进行拆分，目前看起来，根据业务线进行拆分，是个不错的办法。每条业务线都有自己的产品经理、设计人员、Android开发、iOS开发、MobileAPI开发、HTML5开发、测试人员、运营人员。于是每条业务线的座位排摆方式就又回到了第一张图那样——可以认为这是一个由量变引起质变的过程。

10.6.4　静时

软件公司的很多理念，在互联网行业是行不通的，比如说软件开发流程就不一样，前者是敏捷流程而后者是瀑布流程。因为互联网永远是快节奏，所以会不按规则出牌，一切以快速上线为最高优先级，为此而牺牲了流程，所以你会看到，互联网公司，永远是乱哄哄的，没有一方“静”土。一方面，大家都在忙着处理快速上线后的各种问题，于是讨论的时间会多于静下来工作的时间；另一方面，大家都在为下一次迭代上线赶进度，却发现需求不到位、设计稿不到位、后台数据不到位，为此又不得不一轮又一轮进行讨论，等都讨论完，却又发现留给自己的工作时间已经不多了，所以加班是不可避免的。

抽丝剥茧，你会发现，开发人员的时间被严重碎片化了。任何人都可能来打扰他们。比如说突然发现的线上bug，比如说客人投诉、比如说产品经理临时修改需求、比如说领导视察工作、各种谈心。

要想办法把这些碎片化的时间汇集在一起，开发人员的效率就能大幅提高了。这比多招几个开发人员、在架构和代码上进行优化要更管用。

为此，我们引入“静时”的概念。

静时（Quiet Time）是软件公司的术语，就是说，每周有几个下午，开发人员关掉所有通讯方式、不再进行沟通或者被沟通，全身心的投入编程工作，不被任何人任何事打扰。我在微软切身经历过这种机制，每周三下午的效率是最高的。整个办公区域会安静下来，当然，副作用是容易犯困，开始几次还真不适应。

软件公司的任何理念，想在互联网公司着陆，都是需要修正的，否则就会因为水土不服而达不到效果。我记得一开始施行静时的时候，App团队倒是安静下来了，专心去做项目赶进度修bug了，但是其他团队就乱套了，其中最突出的问题是线上bug没人去查了，而这些问题往往很急，需要立刻解决，越快越好。

于是我们为每次静时指定一个值班人员，由他在这段时间作为外界的统一接口，处理这些乱七八糟的线上问题。开始由各团队的Leader担当值班人员，慢慢地就由团队成员轮流担任。这就相当于过春节放长假大家都回家休息了，但一定要有值班人员，能够处理线上各种紧急状况。

在App团队彻底安静下来之后，我们就发现，MobileAPI团队也可以静下来啊，产品经理团队也可以静下来啊，于是各个团度都设定了自己的静时。实施后我就发现，各个团队的静时设置为同一天，只能保证那一天效率很高，其他时间还是会很乱很低效。把各个团队的静时设置为一周的不同时间，反而能达到效率的最大化，因为每天都有团队要安静下来，只能投入1个人参与讨论，这就间接减少了其他团队想沟通的愿望。

静时是为了解决频繁沟通、无效沟通的问题。但是搞过火了会导致信息不同步，从而引发更严重的问题。为此，每天静时后，还是要留出半个小时，处理一下其他团队的诉求。另一方面，要提前协调好和其他团队协同工作的时间，要让其他团队知道，在什么时候可以来找你商量事情。