Question

很多公司不设置项目经理，这是导致项目经常失控的原因之一。是否需要项目经理，取决于团队的负责人是技术型还是管理型，对于前者，是需要项目经理的出现的。

项目经理主要和人打交道，要具备良好的沟通技巧和协调能力，同时，他还必须具备其他几项技能，接下来我会逐一介绍。

10.4.1　项目经理的任务评估表

每次迭代的初期，最忙的就是项目经理了。他要在一天时间内完成以下工作：

1）汇总产品经理的需求，形成一个excel。把这个excel下发给设计团队、Android团队、iOS团队、MobileAPI团队、QA团队，由各个团队的Leader把需求分配个具体的开发人员和测试人员。

我们以Android项目举例，这个excel应该由以下列组成：

·需求名称

·产品经理

·需求地址（往往是wiki）

·设计师

·UI提供时间

·MobileAPI接口负责人（如果有）

·MobileAPI联调时间

·Android开发人员

·Android工时

·Android工期

·测试人员

·测试工时

·测试工期

2）召开需求确认会，请产品经理为开发和测试人员讲解需求。在此之前，开发人员和测试人员应该按照自己分到的Task阅读相应的需求，以便于讲解过程中理解深刻。

3）搜集各个团队每个需求的负责人和工时、工期。设计团队提供设计师和UI提供的时间，MobileAPI团队提供MobileAPI接口负责人和联调时间。Android团队则提供每个Task的工时。

每个人的工时会不太均匀，比如说，每个开发人员只有7天的开发时间，必然有人超过7天，有人不足七天，这就需要开发团队的Team Leader来协调，对Task的分配进行微调，以保证每个人的工时都控制在7天，并且尽最大可能的消化需求。如果安排不下来，就要和产品经理商量，根据优先级删减需求。

在Android开发人员给出工时后，要根据MobileAPI的联调时间、设计师提供UI的时间来调整Android开发人员每个task的工期，以确保开发时UI和数据接口都是可用的。

4）把每个Task都写到小纸条上，贴到敏捷白板上，接下来的几周时间，就看这些小纸条的威力了。

5）有些公司倾向于把所有Task都用Jira来管理，这就要求项目经理额外再花一些时间去维护Jira。

由于每天的站例会上都会过每个人的进度，并且还会把每天的进度作为会议纪要的一部分，发送给所有人。项目经理清晰的知道每个人每个Task的进度，所以可以由项目经理每天来更新所有人员在Jira中Task的进度，从而把开发人员和测试人员从Jira中解放出来，专心致志进行开发或测试工作。

此外，不允许有超过2天的Task。对超过2天的Task，需要开发人员和测试人员对其进行细化，直到每个子Task都控制在1-2天之内。

开发人员往往因为对某个模块不熟悉而预估出很多时间。这是不好的，会导致我们永远不知道每次迭代我们最多能消化多少需求。想解决这个问题，只能把App按照模块进行拆分，确保每个模块都有1-2名开发人员长期进行维护，这样估算出来的工时，就是相当准确的了。

10.4.2　贴小纸条的艺术

在敏捷白板上贴小纸条，是一门艺术。如图10-3所示。

图10-3　敏捷白板

这项工作最好在每次迭代正式开工前做好。每个小纸条上需要有以下几项内容：

·需求标题

·开发人员

·工时

·工期

·测试人员

通常而言，白板上会有一个时间轴，按照敏捷流程而分为几个阶段：

·BackLog：待办列表。

·Doing：开发进行中。

·CC：开发完成，等待测试。

·Testing：测试中。

·Done：测试完成。

通常，Doing阶段中还会细分出另一个子阶段：与MobileAPI联调。当然，这一步是可选的，因为有些需求不需要MobileAPI的支持。

迭代期间，会陆陆续续发现线上的bug，或者加入新的需求，或者项目本身的代码优化，我们会将其写到小纸条上，暂时贴到BackLog中，有时间再做。这里的时间，不光指开发时间，测试所需的额外工时也要考虑。

最后，要防止小纸条粘性不够，经常掉地上，风一吹就不见了。我的经验是用胶带，这样比较牢靠一些。此外，小纸条的材质也很讲究，经常会发生写不上字的情况。要注意贴纸的正反面，只有一面是可以正常写字的。

10.4.3　敏捷迭代中的会议纪要

只要是一群人在一起开会，一定要有人做会议记录，然后把会议记录群发邮件给大家。

下面介绍敏捷开发过程中的四种必不可少的会议纪要及邮件。

第一种：站例会邮件。项目经理在站例会后，要立即发会议纪要的邮件，会议纪要的格式如下：

1）每个开发人员的进度。基本就是流水账，与敏捷白板上的小纸条同步。

2）提测功能，当天新提测的功能要用红色高亮显示，以区分之前提测的那些功能。

3）UI和MobileAPI进度，列出目前还没有提供的UI和MobileAPI接口。

4）发现问题，包括新增需求、需求变更、开发计划调整，都应该在这里列举出来。此外，还包括在敏捷过程中发现的不合理之处，比如MobileAPI与App的配合不默契。

5）风险评估，任何风吹草动，都要反映在风险评估中。项目经理要有足够的敏感度，在项目中遇到的人员请假、第三方依赖的不确定性、需求变更、bug数量激增，等等，都是潜在的风险点，要如实反映在邮件中。

以上5点中，最重要的是第5点，不要怕得罪人，要如实反映项目中的潜在风险，只报喜不报忧的邮件是没有任何意义的。

第二种：测试团队邮件

在站例会的会议纪要中，我们会发现，这份会议记要中没有每日的测试进度和Bug情况。这是因为，测试相关的邮件要单独由测试团队于每天下班前发出，包括本次迭代中每个需求的测试进度，每个开发人员当天的剩余bug数量，每个测试人员目前还没验收的bug数量。

第三种：分析Monkey邮件

每天下班前，开发团队和测试团队要执行Monkey测试，跑一个通宵。每天上午，由测试人员统一把昨天晚上所有Monkey测试的结果发出来，然后由开发人员分析这些Monkey日志，尤其是崩溃的地方，发一封邮件出来，列举出每个崩溃发生在哪个页面，指派该模块的负责人去修复。

第四种：项目总结邮件

每次迭代结束后，都要举行项目总结会议，请每个团队成员给出本次迭代做的好的和不好的地方各3点，好的要继续发扬光大，并且看是否能做得更好，不好的地方要想办法解决，下次迭代不能还是这样，至少要减轻它的影响。由项目经理总结后发出邮件。

每次项目总结会上，都要对上次总结的内容进行回顾，看做得不好的地方是否有了改善。

10.4.4　开站例会的技巧

站例会，英文名为Stand Meeting，因为是一群人每天都站着开会过进度，所以也有的人称之为站立会（或站例会）。

1.早上开会效果会更好

每天我们都要开站例会，开发人员、测试人员、产品经理聚在白板前。有的团队早上开站例会，有的团队则是下班前开站例会。

早上开站例会的好处是，作为一天的开始，可以安排今天要做些什么。下班前开站例会的好处是，作为一天的结束，可以知道每天的进度是否正常，如果有问题，可以及时做出调整，等到明天早上才知道就晚了。两种方式我都试过。一开始是每天早上开站例会，但是一段时间后发现，虽然早上把工作都安排好了，但是当天的进度只有第二天早上才知道。久而久之，每天早上，总会有开发人员给我一个惊喜——各种延期。后来就改为每天下班前开站例会了。虽然能提前知道每天的工作进度，但是明天要做些什么，虽然今天晚上站例会都安排好了，但是睡了一觉后，第二天就忘记80%了。

于是过了几个月后，我又改回早例会的方式了，但是每天下班前我会走到开发人员座位旁，简单询问每个人当天的进度，以确保没有太大的惊喜。一段时间后，发现效果显著，每个开发人员的剩余价值都被榨了出来，在效率提升的同时，我也发现自己的强迫症更加严重了。

2.务必全员准时参加

开站例会一定要准时。定好了9点半，就一定在那个时间把人都召集到白板前。项目经理作为会议的组织者首先不能迟到，否则整个团队也都会上行下效。

任何人都不希望中途被打断，希望集中精力做事情，尤其对于工程师而言，他们最抵触开会，抵触的直接表现就是开站例会的时候懒懒散散，不准时参加，一定要忙完自己手里的事情再过来——我也遇到过这样的情况，我的经验是，提前5分钟走到团队工位，提醒每个开发人员和测试人员把手头工作收一收，5分钟后准备开会。

此外，每个人的“生物钟”不太一样，慢慢调整每个人员的生物钟，不要与站例会冲突。当然，人有三急，遇到突发情况，也没有办法。对于因故不能参加会议的同学，等他有空了，再单独和他同步进度。

开站例会一定要确保开发人员、测试人员、产品经理都在场。其中，开发人员和测试人员很重要，要确保他们尽可能都参加。如果再把七八个产品经理也包括进来，那么二十多人的站例会就不是敏捷了。这说明团队大了，需要拆分了。一个敏捷团队要控制在10人以内。

曾经有一段时间，站例会每次都有将近20人参加。于是，我尝试过把站例会按照模块拆成两个小的站例会，这样每次就有10个人参加会议了。但这样做的前提是，开发和测试团队都已经实现了模块化，每个模块都有固定的开发和测试人员。

3.站例会控制在15分钟

就算是10个人的站例会，也要控制在15分钟。每人介绍一下自己的开发进度和测试进度，各个团队的Leader说一下今天要做的一些公共的事情。需要牢记的是，每件事讨论不能超过2分钟，一旦发现2分钟说不清楚，那么项目经理就要站出来打断他，记下这个事情，会后叫上相关的人再详细讨论。

项目经理要控制站例会的节奏，不能跑题。我经常犯这样的错，说着说着就不正经了。

另一方面，因为参加会议的人很多，所以大家不要私下开小会。问到自己就说，否则就不要开另一个话题和旁人聊下去。

10.4.5　如何确保项目不延期

我带团队做过很多新项目，新项目就是从无到有。说老实话，开始的几个项目我做得并不好，原因有几个：

1）估算工时过于乐观，以至于虽然每天我也参与大量的开发工作，和团队加班到九、十点钟，但是仍然延期。

2）新项目因为一切从零开始，所以会有各种狗血的事情中途发生，会严重影响士气。

3）新项目要做的功能往往比较多，所以一次性评估出一两个月的工时和工期，会有很大的风险，比如说：

·首先是计划赶不上变化，每次需求变动都会调整事先排好的工期；

·其次是时间太长，开发人员会看不到尽头，士气会逐渐降低，直到崩溃。士气低的直接反映就是质量差。

·再次是测试团队的介入点，工期排的很紧，我并没有给开发人员预留修之前提测功能的bug修复时间。做到后面，我会发现，开发人员一边在做新功能，一边在修之前的bug。两线作战，疲于应付。

吃过几次亏，决不能再犯同样的错误，比如我最近做的一个新项目，就将其拆分成3次迭代，每次迭代做一个完整的功能，包括App开发、MobileAPI开发、测试、修bug、产品验收，每次迭代2周时间。最后再预留出一个迭代（2周时间）做buffer，用来处理一些突发事件，比如之前的架构设计得不好需要修改，比如我们对外界的依赖不可用了，比如上线前的一堆准备工作。

这样把一个2个月的新项目拆分成4次小的迭代，每次迭代都能发布一些新功能给产品经理甚至是大老板看，大家每次迭代的目标都很明确，每次迭代如果都能按时完成任务，士气就会很高涨。这样即使中途加一些新需求，也能消化掉（当然随便加新需求这样不好）。

更多时候，我们所做的项目是有外界依赖的，比如说无线部门往往依赖于公司的底层部门，比如说搜索及产品信息、支付、安全、运维这些部门，尤其是在项目上线之前，对测试环境的依赖性非常大。经常会发生测试环境上午是好的，吃过午饭后就不能使用的现象，所以项目经理在保证自己团队项目进度的同时，还肩负着与其他部门沟通、协作的工作。

10.4.6　迭代风险管理

不夸张地说，无项目不延期。

所以，尽管机关算计，无论是两周的迭代，还是四周的迭代，都会有延期的可能。我接下来讨论的，是如何规避风险、以及遇到了风险如何把风险降到最低。

就以两周的迭代为例子吧。第二周的周三晚上，应该完成所有的功能，称为Code Complete。如果这个点踩不住，那就有风险了，开发人员往后延期几天，测试也就相应的延期几天，这就导致App发版时间也会顺延。

延期一般发生在MobileAPI。当然不能全都怪从事MobileAPI开发人员，因为他们只是一个中间层，问题出在底层的系统上，包括搜索、产品信息、支付系统、会员体系等等，传统互联网公司的这些系统原型都是为网站服务的，不能直接搬到移动互联网上。

要想规避因此而导致的延期，有3种解决方案：

·让MobileAPI的进度提前两周（一个迭代）。只有这样，MobileAPI才能告诉App开发人员，下期迭代能做什么和不能做什么。

·让HTML5网站先行，App下个迭代后续跟进。考虑到HTML5页面开发起来很快，发布起来也很简单，能迅速上线并收集到用户反馈，所以可以让HTML5网站先去“趟雷”，以确保App开发时少走弯路。

·如果算来算去，MobileAPI还是要和App一起开发。那么MobileAPI一定要在开工前就做好技术调研，需要提供哪些接口，用到底层哪些功能，这些功能是否满足所有需求，这些功能是否都能正常工作。要第一时间知道本次迭代能做多少，否则每走几步就会遇到一个坑，所有人停下来等解决方案；再走几步又遇到一个坑，然后大家又只能停下来等结论。

接下来说第二周的周四，这一天应该做到bug日清，如果达不到，说明有风险。对于bug重灾区对应的那部分功能，要么是相应的开发人员技术能力不够，要么是需求和交互设计过于复杂了。我们有必要建议产品经理弱化需求，以便该功能能够平稳上线。

做任何需求，我们都要为自己留一条后路，也就是最坏打算，如果未能按期完工，或者质量很差，该如何面对？就算是砍需求，也是需要人工成本去做这个事情的，把代码回滚到最初的状态，所以一定要有个最晚的时间点，过了这个时间点如果还有很严重的问题就要采取断然措施。

最后是第二周的周五，即最后一天，全功能回归测试及发版。这一天，即使是发现了bug，也不能急着去修复了。这时大家要坐下来一起商量，只修复那些最重要的bug；对于影响不大的bug，匆匆忙忙修复反而有可能引起更严重的bug，这才是风险所在。

要做好带bug上线的心理准备，这些bug一类是小问题，影响不大，可以延期到下次迭代解决，另一类是大问题但是改动量很大，所以也只能忍痛延期到下次迭代，当作一个Task来做。

综上所述，我们会发现，每次迭代的最后三天，是至关重要的，是风险的汇集地，作为管理者，这三天一定要睁大眼睛盯着任何风吹草动，盯着bug报表的波动情况。