博客园_老翅寒暑

项目进度控制的技术

2012-04-05T09:10:00Z

项目进度控制是项目经理的一项重要职责。俗语说的“时间就是金钱”在这里体现得再明显不过了。项目管理和自驾车回老家过年是相同的，实际上按照项目的定义，“自驾车回老家过年”也是一个不折不扣的项目，只是它更贴合大家的生活，更容易引起共鸣，我们就拿它来做例子说明。

从乘客的角度，如果坐车很久，但是没有达到预期的目的地的时候，就会产生疑问，一般都会去询问司机“到哪里了”，如果司机的回答没有那么令人满意，这个疑问就会积累。积累到一定程度，就会开始怀疑是否迷路，如果这个疑问一直无解，最终就会要求停车问路。如果坐的是出租车，就会导致乘客下车，换车继续前进。

项目进行过程中同样如此，因为软件项目的“不可见”特性，客户心理更脆弱和不稳定。如果每次项目经理给出的进度都是无法验证的，客户的疑问就会积累，最终到无法忍受而爆发。

人对一个事物的完成都会有自己的“心理预期值”，这个值会随着人对该事物的了解的加深而进行调整，并变得越来越准确。乘客坐车到目的地，如果他对路线熟悉的话，一般都会跟踪一些关键的地标和时间的对应关系。比如从南山科技园到深圳火车站，一般用时不会超过1小时，开车走深南的话，肯定会经过世界之窗、市民中心、帝王大厦，最后到火车站。如果在晚上8点出发，过了半小时都没看到世界之窗，乘客会怎么想？

项目也是如此，客户的心理预期就是项目“里程碑事件”的到达时间。项目经理制定项目的里程碑，目的之一就是去影响客户的心理预期。但是这种行为是一把双刃剑，会影响客户的心理，同时也会对项目构成约束。

实际上，项目进度表现在两个程度，一个是微观的层面，这个层面上，所有的事情都是一个一个的task，一个项目下来，有成百上千个task要去完成，这个层面是项目经理和项目组员关注的，是最准确的进度描述；另一个是宏观的层面，这个层面是客户以及项目外部的干系人所关注的，每一个进度都是一个“里程碑事件”，这种层面的进度描述并不是十分准确。

依然从心理角度去分析，项目经理给出的进度有误差是肯定的，关键是和现实的落差是否在范围之内。如果客户持续觉得项目的进度描述是准确的，那么对项目也就越有信心，对项目的支持也就越好，对失误的宽容度也越高。反之，如果对项目进度没有信心，那么就会对项目施压，对失误的处置也会越严厉。

如何把握进度和进度的报告，常用的方法有“堵”和“疏“。所谓的”堵“就是隐瞒，项目经理可以进度造假造得很漂亮，但是到最后交付不了，就会被修理得很惨；而”疏“则是如实汇报，让项目干系人透明地掌握项目的主要细节。实践中，很多项目经理采用了折中的方法，有些如实汇报，另外一些则隐瞒起来，避免不必要的麻烦。但是实际上，项目经理”说真话“是要有一定能力的。

首先是”项目组实际的完成能力“，通俗点就是每天、每周最多能完成多少任务，如果项目经理和客户都知道这个速度，客户就不会提出过分的进度要求，项目经理也可以拒绝所有超出能力的进度要求。这个”能力“其实就是项目经理”Say No“的底气来源。现实中很多项目经理因为不知道团队真实的能力，胡乱应承，结果害了自己，也坑了团队。

其次是”项目进度的预测能力“，如果项目经理给出的完成时间每次都能做到，他以后的项目工作就会越来越顺畅。许多项目组和客户的冲突，起因大都是因为”进度预测不准“甚至”无法预测进度“导致的，进度再一再三地突破客户的心理预期，想不让人发飙都不行了。

在项目实战中，项目进度的评估和预测非常不容易，但是并不是完全做不到的。我们可以反过来看，从项目结项的那一刻开始。在结项时刻（算上变更之后的），项目的进度毫无疑问是100%，往前推一周，我想进度是可以预测的，但是往前推一个月就会模糊一点了，越往前越模糊。换言之，项目的进度预测是随着项目的进展而越来越清晰的。

先分析”为什么会模糊“。问题在于两个方面，一个是”任务分解“，一个是”临时性的任务“。对于前者我们可以逐步分解、逐点清晰的方法来解决，对于后者我们可以预留时间。我们可以先用大块的任务写在任务列表中，等要处理之前再去分解细化并再评估，随着工作的进行，任务列表会越来越细，评估也越来越准确。对于”临时性任务“则在计划表中预留时间去处理。

接下来分析”如何清晰“。

首先是”预估“，把当时能够想到的所有任务都写在计划表中，不要怕不详细，也不要怕不准确，有总比没有好，但是要记得及时对所有可以细化的任务进行细化；

其次是”记录“，项目经理把项目组所有做过的任务都记录到任务计划中，等到积累到一定程度之后，就可以从计划表中看到项目组完成任务的速度，即”项目组实际的完成能力“，这个能力值的单位可以是”任务/天“、”工时/天“、”工时/周“等。同时可以得到的，就是”计划外工作量“的值，这个值可以指导项目组调整为“临时性任务”预留的时间。

最后就是“优化和预测”，通过前两步的成果，对未来的进度进行预测并及时进行调整。

总之，项目进度管理中，要遵循的就是如下三个公式，任何一个懂得小学数学的人都可以完成：

            开发速度 = 已完成工作量 / 已耗费时间
            当前进度 = 已完成工作量 /总工作量
            剩余时间 = 剩余工作量 / 开发速度 = （总工作量 - 已完成工作量） / 开发速度

而实战中，通过“记录任务”知道“已完成工作量”，并得到“开发速度”，通过不断细化逐步逼近“总工作量”，也就得到了越来越准确的“当前进度”和“剩余时间”了。

项目进度管理其实并不难，不是吗？真正难的，是“驱散恐惧”。

本文链接

项目管理沙龙第十二次会议纪要--为没有共识的项目组定制敏捷方法

2012-01-05T15:10:00Z

项目管理沙龙第十二次会议纪要

本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法。这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。

但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。所以，“暗渡陈仓”或“偷梁换柱”地实施敏捷，是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字，那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。

之所以我们要探讨这种情况，因为我们坚信“敏捷不会把事情变得更糟”，既然敏捷肯定不会“砸场子”，肯定“效果>=现状”，所以“暗渡陈仓”就是有价值的，也是可行的一种推广方法。

我们的目标项目组情况是这样的：团队成员之间技术水平差异较大，但是工作热情高涨，气氛较好，而且项目组感觉“陷入泥潭”已经很久了，看着一堆难以维护的代码，大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧，不支持也不反对，但对敏捷始终保持着足够的距离，既不拒绝，也不欢迎，更不去深入了解。在管理方法上，项目组采用月计划和周计划相结合的管理方法，即每月定一个计划，本周的计划细化到可执行。但是可想而知，管理比较混乱，计划也经常不准确。

面对这样的项目现状，我们首先讨论的是实施策略：

1. 绝口不谈敏捷两个字，也不谈敏捷相关的什么术语，避免反弹。
2. 选取敏捷方法中最有价值的几个行为，改良项目组的管理现状。
3. 在达到效果，取得大家的认同之后，全面实施敏捷方法。

经过讨论，我们总结出的敏捷成功的要素有如下几个：

1. 管理上的PDCA循环。通过Plan-Do-Check-Adjust形成一个不断改进的循环。
2. 工作的可视化。通过将工作以可视的形式展示出来，让团队对进度有切身的感受。
3. 任务的定量化。所有的任务在阶段开始前就已经定好，一般不再改变。
4. 沟通。定期、按需沟通，保持信息流转的顺畅。信息包括：任务，进度，问题等。
5. 团队工作。团队的每个人都知道所有的事情，了解一致，当然就没有歧义。

事实上，敏捷的这几个要素纳入到任何一种管理方法中，这种方法也就立刻符合了“敏捷”的规范，因为“敏捷”本身就是一种“价值观”，在同一个价值观下，可以有N中不同的方法。“老酒”兑“新水”自然也是可以的。

讨论之后的具体实施方法如下：

1. 沿用原来的“月度计划”和“周计划”结合的管理方式。用敏捷术语就是一个“迭代”长度为1月，但是考虑到一个月时间太长，不容易出效果，所以在每个月的15日加入一个局部总结会议。实际上把一个月分为上下两个半月，即2周一个迭代。这个也是目前公司敏捷经验中推荐的初期迭代长度。

   a) 每月月初开“每月例会”，内容就是规划本月的工作，并且将工作细分为可分配的任务，颗粒度粗一点没关系，但是要保证一个月够用，不需要中途再加。例会上所有的工作都要进行讨论，保证大家都对工作没有分歧，其次要对每个工作进行评估，评估的单位采用传统的“工作日”。只有所有工作都进行了评估，才能评估任务的进度。

   b) 每月15日左右开“月中总结会”，负责总结一下上半月的工作情况，讨论改进措施，并根据进度，酌情调整下半月的任务进度安排。

   c) 每月月末召开“月度总结会”，负责总结整月的工作情况，并讨论改进。月末总结会议一般不要和月初的例会合在一起开。

2. 开始实行每日例会。会议上监控如下的几个问题：

   a) 每个人当天的工作状况是否都已经更新

   b) 对停滞超过2天的工作要询问原因，可考虑进一步细化和分解。

   c) 鼓励在例会上交流，慢慢形成交流的气氛。

3. 所有的工作和进度，在白板或者wiki上展示，统一管理。

   a) 初期的工作任务描述可以简单，但是要在计划和总结会议上形成口头共识，防止歧义。在实施过程中逐步精细化，慢慢达到敏捷对Backlog的要求。

   b) 暂时不考虑使用敏捷工具，避免反弹。

在实施过程中，还有一些技巧需要酌情使用：

1. 任务评估由具体执行人给出评估时间，然后乘以相应的系数，作为实际的任务期限。

2. 某些需要形成共识的地方，可以故意引导对方出错，然后给出相应的正确方法。比如代码难看难维护，可以先采用“每周代码show”的方式，逐渐形成集体对代码质量的重视，达成共识之后，进而引入“代码评审”的方法。

接下来的沙龙时间里，我们会持续跟踪这个方法的实施效果。

考虑到目标项目是真实的项目，为了保证实施的隐蔽性，本次沙龙会议纪要仅在沙龙成员和特邀嘉宾内部发布，请勿外传！

本文链接

项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候

2011-12-29T16:45:00Z

项目管理沙龙第十一次聚会纪要

本来这次聚会要讲一下项目管理的流程概貌，同时对第一个阶段进行一次试探性的深入探讨。可惜这次缺席人数太多，变成了“锵锵三人行”，原定想要谈的内容，也就弱化了。其实每周一次的沙龙，并不需要太多的负担，就当是每周一次的茶会吧，大家紧张了一整周，放松个90分钟，也是应该的。

不过“三人行必有我师焉”，只要有意愿，肯定能够谈出新话题来。

今天分享的知识是“Dreyfus模型”，全称是“Dreyfus技能获取模型(Dreyfus Model of Skills Acquisition)”，是两兄弟研究人工智能时候得到的成果。这个模型把人对知识的学习过程分为几个阶段：新手(Novice)、高级初学者(Advanced Beginner)、胜任(Competent)、精通(Proficient)、专家(Expert)、大师(Master)。这六个学习过程中，新手到胜任的过程基本是线性的过程，但是之后的过程就是非线性的了，每一个过程的进阶都是一个质的飞跃。这个也就能解释为什么小孩子通过“幼小初高中大学”的学习就可以学到和大人差不多的知识。

Dreyfus的六个阶段的主要特点如下：
1.新手（Novice）：需要详细的指导，要手把手地教，并且新手分不清重点。
2.高级初学者（Advanced Beginner）：熟悉基本步骤，能够单独完成任务，且觉得自己学得不少了。简历上的“精通”就是从这个阶段开始出现的。但是一旦任务遇到难点，他们就搞不定了。
3.在胜任（competent）：他们可以分解目标和组合一系列任务以达成某个目标，但是通常这些组合不是最佳的。他们也能初步做一些指导工作，并很讨厌被人指手画脚地指挥。大部分人都处在这个阶段，他们大多不想再投入精力改进，而只想完成工作而已。
4.在精通（Proficient）：能够给出成型的并覆盖主要细节的解决方案。已经能够将知识和经验结合，开始喜欢谈“哲学”和“方法论”。并且在继续学习中领悟更多。
5.专家(Expert) ：有自己解决问题的方法论。依靠直觉和自发工作，在他自己的领域中很少犯错误。喜欢和其他专家交流来提高自己的能力，更加谦虚和低调。
有趣的是，处于初级阶段的人们倾向于过高估计自己的能力，而在较高阶段的人则更加谦逊。

模型特别指出，大部分人都很难超越“胜任”这个级别。由此可见，那些满天飞的简历里边的“精通”两字是多么幼稚和可笑。

我们的话题谈到了一个没有共识的团队如何逐渐推行敏捷方法的问题。这个是非常普遍的需求，如果需要用另一种方式来描述这个问题的话，就是“如何让敏捷快速见效”？初步的意见就是一些常用的敏捷实践需要立刻实施，因为他们能够解决实际的问题。
1. 最容易开始的就是“每日例会”，它可以即刻解决项目组沟通不畅的问题，让项目经理不再需要询问任务的进度，团队其他成员也不再需要每天填写工作日志。
2. 其次就是backlog的编写和评估，初期可以让项目组自由评估，等到出现问题之后，逐渐改进到用point评估和计算投入时间。

不过这个话题没有深入，但是我们约定下一个聚会就将此作为讨论话题，并且为某个项目组量身定做一个实施计划。

目前到了年底，项目组要么很忙，要么很闲。忙还好办，但是闲就不好办了，所以这个时候需要项目经理更多地去安排一些轻松的任务，最常见的就是安排一些共同学习。而且架构师要去深入地思考一下架构的问题。对于定制交付类型的项目，架构问题还不是很突出，而且很多都已经有了成熟的架构方案，借鉴一下就可以。但是对于产品型的项目，架构就很重要了，而且基本是从无到有的搭建，所以设计就非常重要。就拿EAS来说，简单的CRUD操作定制起来会爽的不得了，但是一旦有了特别的定制，结果就会很难受，有人举例说客户拍着桌子骂人：“你们修改一个标题要10天吗？”

一个不当的设计，很快就会成为生产力的阻碍。很多老板重商务轻产品，无可厚非，毕竟商务会带来现金流，可是有没有人想过，一个没落的产品能够带来什么？有人说一个好的产品能够创造一个新的市场，真的是这样，比如第一个做MQ产品的，第一个做ESB产品的，第一个做数据库产品的，无一例外都生成了一个新市场新领域。

因为话题比较自由，我们谈到了年龄和时间。有人谈到了他一贯的观点：女朋友的年龄=自己的年龄/2+7，然后如果交往顺利的话，就在第18个月的时候结婚，因为这个时候互相的了解已经足够，并且新鲜感没有褪去，一旦时间过长，互相依赖成了一种习惯之后，比如那些在一起5、6年的情侣，越往后结婚的概率越低。从项目管理的角度去看，不仅浪费时间，而且明显风险过大。

浪费时间是可耻的！
（部分关于人生、时间点的内容不想写了）

参考文献：
1. 更好的最佳实践 http://www.infoq.com/cn/articles/better-best-practices
2. 如何从小工到专家——Dreyfus模型应用 http://gurudk.iteye.com/blog/324204
3. Dreyfus模型和最佳实践 http://blog.sina.com.cn/s/blog_493a84550100c8vz.html

本文链接

项目管理沙龙第十次聚会纪要-AOM项目的敏捷实践

2011-12-26T16:53:00Z

项目管理沙龙第十次聚会纪要

会议一开始，就有人跟我们分享了一个名词，“分析瘫痪”，意思是不断地追求完美，结果始终在设计状态，无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。与会者都有同感。而破解“分析瘫痪”的诀窍，就是“敢于行动”，因为人就是在不断的错误中学习并改进的，不犯错，当然也就谈不上改进了。如果用沙龙常用的术语说，那就是“敏捷”。

今天的敏捷话题是分享AOM的敏捷过程。AOM是一个基础平台产品，在实施敏捷之前，采用周计划的模式来管理，即每周定制计划，组员按照计划完成工作，并且更新自己的工作状态。这种管理模式在需求控制，角色分工，任务分配和团队激励上，都存在较大的问题，所以AOM团队想到了利用敏捷方法来改进项目管理。所以这一点上AOM和NSEC最大的不同，就是AOM是主动“拥抱敏捷”，而NSEC是“被敏捷”。

AOM有产品经理（PO）的角色，负责需求的最终拍板。敏捷教练（SM）负责团队敏捷过程的正确性和改进，但是和一般SCRUM规则不同的是，SM是项目组之外的人，且不负责项目的进度，项目的进度由项目组自己来管理。项目组依然有项目经理（PM）的角色，但是在实行过程中，这个角色的作用被弱化了，变成了一些关键事务的协调人和PO的代理人。日常的进度监控工作，则由轮换的“主持人”完成。

在产品的计划会议上，AOM使用纸牌游戏的方式来对每一个任务评估point数。并且根据团队的能力，设置sprint计划的point总数。和NSEC不同，AOM不会在每一个sprint中预留point，而是将一些项目之外的事务变成backlog放到sprint中一起进行跟踪。如果外部干扰太大，就要及时调整sprint中未开始的backlog，删掉一些优先级较低的backlog，并且用更小的backlog弥补进来，并保持sprint总的point数不变。就像长跑的时候呼吸和脚步的频率要非常一致才能跑得很好一样，敏捷过程也很重视“节奏”。所以AOM的sprint时间长度也基本是稳定的，目前是两周一个sprint，部分为三周。

在产品的回顾会议上，所有的问题都会被分析一遍，对于投票最多的前三项问题，会在下一个sprint中生成backlog并分配专人跟踪和完成。其他问题，如果是规则性的，就会去更新规则。

每日站立会议上，主持人会先向大家通报一下上一个工作日的task完成情况和进度的预测，然后团队每个人再回答一下三个问题：昨天做了什么，今天做了什么，遇到什么困难。在日常任务的跟踪上，AOM通过纸质的任务看板和纸质的backlog卡来进行跟踪，每天下班前，主持人会根据看板的进度情况，敦促当事人及时更新任务卡片，并将任务卡片的进度数据同步到ScrumWorks中（大家回忆起了读书时候的“课代表”）。每次站立会议都会有一个人记录会议纪要，并且将其内容登记在wiki上，以便全体成员（包括缺席人员）备查。

主持人机制在AOM敏捷过程中占据十分重要的地位，它负责对团队每个成员进行敏捷管理意识和能力的培养，通过角色轮换的方式，让团队成员获得一种比本职角色更高的角度去看待软件开发和管理，尝试他们以前不太有机会去尝试的团队管理或设计方面的工作。在AOM团队中，主持人按周轮换，除了跟进项目进度之外，还要负责控制会议的时间。

不同的会议，控制时间的基准也是不一样的。对于计划会议，则每个backlog的讨论时间=会议计划长度/sprint中backlog数目。对于每日例会，每个人发言时间=15分钟/发言人数，最长没人发言时间不超过（30分钟/发言人数）。回顾会议上，每个问题的讨论时间=会议计划长度/问题总数。另外，对于讨论和辩论，控制时间是每项讨论和辩论不超过1分钟。只要超过时间，主持人就会主动打断，维持会议效率。

AOM同时也引入了“结对”的机制。组员自由结对，分主副手。所有的任务要两个人同时签名才有效，主程序员负责编码，副手负责单元测试，并且在sprint结束之后，主副手角色调换，副手负责维护该部分代码，包括修改bug和增强功能。这种结对延伸到项目组的每一个方面，所以每天站立会议会议纪要，也是会议主持人的结对伙伴来记录的。

AOM的敏捷过程中，大家发现使用纸牌、看板、任务卡片的方式，使整个过程充满了“游戏性”，具有很强的“参与感”。组员之间互相关心，在任务分配上更公平，工作效率更高，每项任务中的职责分工更明确，当然产品的质量也更高了。而且轮换主持机制让每个人都有更多的角色体验，可以让PM空出来思考更深层的问题。

目前AOM尚未在每个sprint结束之前进行show case。

与会者在讲述过程中插入了很多的讨论和分析，大致有如下几个话题：

与会者首先关心的是“需求来源”问题。因为项目的特殊性，AOM的需求更多来自于团队的拍脑袋，其次是公司内其他项目提出的要求。与会者一致认为，不管怎样，“有目的的手机用户需求”是肯定的，但是需求的筛选也是值得注意的方面，要结合项目的目标来进行。比如iPhone多半可以肯定不会去实现什么“双卡双待”和“收音机”的功能。但是有时候的“拍脑袋”和“摸着石头过河”也是不可避免的。这就要求PO充分担负起责任来，PM也要担当一下，比如某些需要预研才能确定做不做的技术，就要先动起来。

关于showcase，有人发现公司的一个怪现象：“产品的名字大家都听过，但是长相大多都不知道”。仅从这个意义上去看，showcase的重要性也是不言而喻的。大家一致的意思是要用起来，因为它可以让团队充分感受到目标和时间的压力。但是初期不一定非要每个sprint都show，在掌握方法之后慢慢提高，最终达到每个sprint都show的程度。但是一定要注意showcase是要求不要做特别的准备的，也就意味着showcase的成果就是日常工作成果。

“到底有多敏捷”是与会者提出的一个问题，有人觉得公司内部的过程改进组织就应该来回答这种问题，通过对项目组敏捷过程的观察，给出一个敏捷的级别，并且以此来逐步指导和提高项目组的敏捷程度。

有人关心“任务没有人领”的问题，经过讨论，我们发现虽然有部分任务会存在只有某人能够完成的情况，但是只要经过细分，大部分任务的难度都会降下来，并降到其他人也可以认领的程度。有人发现如果能够将“个人学习计划和任务结合起来”，是可以降低某些任务对人的依赖性的。

“如果团队中有破坏者怎么办”，这是有人用“六顶思考帽”的思考方式提出的问题。但是大家在讨论中发现，利用每日例会和看板，我们很容易发现那些虚假的进度汇报，并且敏捷中持续的沟通，让谎言在其中生存的难度变得极大。一旦“破坏者”被发现，要么被清除出团队，要么自动离开，或者痛改前非，融入团队。

在分析“轮换支持”机制的时候，有人举例了IBM的60%工作，40%沟通的时间安排比例，谈到了如何让员工更多思考，聪明工作的问题。不过未展开。

敏捷其实不是一种新生的事务，无论从其指导思想，还是各种使用的工具和方法，大部分都是敏捷提出之前就已经存在的，比如看板就是源自丰田的精益管理方法，每日例会则来自于服务行业。现在敏捷已经不仅限于软件开发，在市场销售、公司管理都有应用案例。

最后，有人提出“敏捷管理方法如何在餐厅运用”的问题，引起了大家热烈的讨论，但是考虑到沙龙的时间，讨论在一片欢乐中结束，不过我们不排除以后会抽出一个专题来讨论这个问题。

本文链接

项目管理沙龙第九次聚会纪要

2011-12-08T14:57:00Z

项目管理沙龙第九次聚会纪要

前不久在腾讯举行了2011敏捷大会，但是因为加班或者报名的原因，沙龙里只有一个人参加了敏捷大会，所以本次聚会由夏勇分享参加大会的心得。

对大家印象比较深刻的首先是雅各布森给出的一系列敏捷卡片，我们拿到的这一系列卡片有四组，基本覆盖了敏捷过程的方方面面，对于敏捷过程的指导作用还是比较强的。所以我们决定接下来将这个卡片电子化一下，让每个人都可以看到。

QZone的产品经理的演讲还是挺让人感兴趣的，他号称是QZone每周五天可做到约二十次发布。在这种情况下，如何保证项目成果的质量稳定，是需要一定的水平的。QZone前台使用php，后台使用C++，所有模块集中发布。他们有一个专门的发布系统，可以做到“一键式发布”。他们在发布之前做的测试，只测试一些关键逻辑，小的地方就不测试了。QZone自己把这种发布形式叫做“灰度发布”。结合从会议上听到的消息，我们分析他的测试方法大致有如下几个：产品关键部分要做专门的测试；修改所牵涉的部分做简单的测试；使用招募的内测用户对系统进行在线测试；将用户群拆分，比如把某个二线城市的用户都切换到新版去用，跟踪他们的使用状态等。有人举了一个淘宝为世纪光棍节做系统压力测试的例子，因为要产生一个访问的峰值，所以淘宝发了一个优惠券让大家去抢，结果峰值自然就出来了。不过像QZone这样的测试，最小测试颗粒度都应该是User Story级别的，再小可能就太细太多了。

QZone在划分Backlog的时候，先定2～3个月的目标，颗粒比较粗，然后定每个sprint的目标。我认为这种形式比较适合于那些开始时候需求不明确，需要在过程中不断挖掘需求的项目。在制定Backlog的时候，采用颜色将Backlog分类，比如数据界面的Backlog标为绿色，属于Bug的标志为红色等。这个办法值得学习。

敏捷会议上的另外有人提出了“轻敏捷”的概念，和与之相对应的“传统敏捷”相比，他抛弃了过程数据的收集，只看结果。其他经验的包括流程可视化，流程梳理，以及交流一定要面对面。

雅各布森讲了“如何做有效的Backlog”。大致就是说从项目干系人、蓝图、用户的变更申请等处得到Idea，然后把Idea整理成Use Case。Use Case要包含范围、场景描述等。再基于Use Case整理出可以Telling的Story。最后把Story拆分成一个个可以交付的Backlog。经过优先级排序、价值评估、风险评估之后，就可以将这些Backlog纳入到Sprint中去。

一个Backlog可以分成许多个Task，一个Task分配到一个人。在状态处理上，Task可以被Block，Backlog可以被归为impediment。Task的颗粒度要细分到保证能够在一天内完成。一个Backlog的所有的Task完成之后，称为Backlog的Complete，但是Backlog要从Complete到Done，还需要经过测试和验证才行。所以要注意所有Task完成之后，到Backlog的Done还是需要有时间的。另外，上一次Sprint没有完成的Task，要作为下一个Sprint中最高优先级的工作来做。

下一次聚会，我们请AOM讲一下他们的敏捷实战经验。

本文链接

项目管理沙龙第八次聚会纪要

2011-11-27T14:55:00Z

项目管理沙龙第八次聚会纪要

本次沙龙依然是NSEC的敏捷经验总结。这次依然谈到了客户与需求的问题。因为客户和开发组不在同一个地区，所以客户完全没有参与到项目的开发工作，所有的沟通都通过项目经理来进行。从开发人员的角度看，需求变化最大的问题是开发人员无法确定是否真的是对客户有用的。客户首先是自己有很多的想法，变来变去，PM也因为距离的关系，无法和客户面对面沟通，所以也就只能拍脑袋和猜谜语。结果开发人员心里没底，做不出成就感，心情自然也就好不起来。引出的问题就是：开发人员到底怎么办？

面对这种情况，经过讨论，大家认为首先还是要充分信任PM，但是PM也有责任去和客户充分沟通。这个时候，我们一直强调的“原型法”就会有很大的作用。原型工具可以有很多种，比如一连串简单的html页面，或者一个ppt演示。前者的好处是可以快速地完整演示一个流程，后者的好处是可以将一些用户界面效果也同时演示出来。总之，原型工具就是那种可以快速构建，快速抛弃的东西。非常适合用在客户需求不稳定甚至不成形的情况下。

实际上，NSEC的需求问题根源并不在客户，也不在PM，而是和其他大多数项目一样，缺少了一个角色，“业务分析师”，简称BA。许多项目的BA都由PM担任，或者商务人员担任，但是他们要么身兼多职，要么没有受过专门的业务分析训练，无法充分引导客户的需求，结果就造成了需求不明确，不稳定等问题。引用沙龙成员的一句话：程序员不反对变更，但是反对浪费！

BA的作用很重要，在敏捷结对中，BA的结对对象就是客户代表。他的工作就是负责引导客户，让他们的需求变得更明确，更稳定。原型法是一种很好的需求引导方法，就像我们一直强调的，“客户不知道自己要什么，但是明确知道自己不要什么”，原型法的作用就是让客户能够不断地否定自己的想法，最终形成一个明确稳定的客户想要的东西。这个也就是项目组梦寐以求的“稳定的”需求。其实BA的工具远远不止这些，“语法分析”也是BA的工作利器。根据客户所说的语句，将其划分为名词、动词、形容词和主语、谓语、宾语。根据每一个词语的特性，我们可以整理出一系列有针对的问题。一个有经验的BA，只要客户不断地开口说话，就会将客户的所有需求都问出来。具体的方法，我们可以在以后的沙龙中详细探讨。

NSEC的另外一个问题是客户不定期不定时地要求项目组发布成果。针对这种情况，我们觉得自动化构建和上次谈到的UAT环境就很有作用了。这种问题的出现，根源其实还是在客户需求的不稳定上。当然，定期发布成果并让客户能够感受到进度的变化，也是非常重要的。

“没有验收标准文档”是另外一个NSEC的问题。从我们的角度看，这个是中国几乎所有项目的共同问题。理论上，我们会在中标之后对客户进行需求调研，然后把形成的需求规格说明书作为合同的附件，并以此作为客户验收的标准。实际上能够做到这种程度的项目几乎没有，即使做到了，这个合同附件中的需求也会在开发过程中不断地变更，最终变得面目全非。有经验的人肯定会拿出“变更控制”的办法来，可是实际项目过程中，有多少客户愿意每次需求变更都来签字呢？又有多少客户代表因为要签字就放弃需求变更呢？答案都是“很少”甚至“没有”。很多项目就是因为限制客户变更需求，或者变更需求过程中和客户经常产生不愉快，导致客户关系恶化，最终项目失败。这个也是“传统”项目和“敏捷”项目的最大的区别。

从敏捷的角度去看，项目组完全接受变更所带来的影响，但是所有的变更都不能影响当前正在进行的迭代过程，所有的变更最快也要到下一个迭代才能生效。但是真的有紧急的需求变更怎么办？事实上并不存在什么“紧急”的需求变更，因为所有的需求的实现都是需要有时间的，需求是一种未来性质的东西，项目组一定要把“需求”和“BUG”区分清楚，不能用解决BUG的方法去应对“需求变更”（这个也是大多数项目组常犯的错误，任务没有优先级的结果就是经常性的加班）。针对一个需求变更，除非它能够让当前迭代的某个任务即刻作废，我们才需要即时改变迭代的任务安排，否则本次迭代不受影响。

没有验收标准文档是一个问题，但是“依赖客户进行测试”是另外一个更严重的问题。因为之前所讲的客户不定期要求项目发布，所以项目组在发布的时候的时间都很紧张，加上平时没有充分的测试，所以项目组就希望客户能够抽出人力去做验收测试。实际上，客户几乎不会去做什么认真的测试。有与会成员认为“依赖客户进行测试”本身就是项目的一种失败。

本文链接

项目管理沙龙第七次聚会纪要

2011-11-23T14:18:00Z

项目管理沙龙第七次聚会纪要

本次沙龙的主题是由NSEC项目组介绍他们的敏捷实践经验。作为公司第一个实施敏捷的项目，他们的成绩给整个公司带来了震动，也是公司其他项目实施敏捷的参考和基础。因为时间是所限，这次沙龙虽然只来得及只讨论了NSEC的四个问题，不过逐个问题讨论的过程中，我们涉及到了更多的方面。

上次沙龙提出的“代码秀”在NSEC实施了一周，效果不是很好，首先是频率问题，上次沙龙谈到的代码秀周期是“周”或“月”为单位，NSEC的实践证明以“天”为单位确实是太频繁了；其次是项目组太忙了，没时间总结，而且分散独立提出各自的代码片段，如果没有专人汇总收集的话，分享起来还是不太方便；另外出现的问题是，程序员知道某些做法是错误的，但是太忙了，没有时间去写的更好。对于最后一种情况，每日的代码审查效果会更好些。

NSEC启动的时候，由他们的敏捷教练给大家讲了一个多小时的敏捷方法，但是大部分人之前没有听说过敏捷，并不是十分了解敏捷给各方面带来的好处，当然也就没什么想法，用时髦的说法，就是属于“被推行”敏捷的。在实施的过程中，感觉每日例会有些用处，另外就是感觉工作压力大了，尤其是在结对的时候。于此相对应，AOM的敏捷实施就好很多，感觉推行起来比较有趣。当然最开始也有一个敏捷启动会议，说明一下试试敏捷对大家的好处，使大家能够理解并支持。所以项目的敏捷启动会议是很重要。AOM的实施过程中对角色划分有了一定的改进，把标准定义中的ScrumMaster职责划归两个角色，一个是PM，负责项目的进度，另外则是新的ScrumMaster，他仅负责和保证敏捷的规则实施的准确性。这样的分工，敏捷教练可以身兼多个项目组的教练职责。

另外需要说明的是，因为NSEC的项目进度压力比较大，依然加班比较多。这种NSEC达到的快速交付效果，到底是敏捷带来的还是加班带来的，其实很难分清。即使从现在来看，也一样。

PM对敏捷能否正确理解是很重要的。有一段时间，NSEC的敏捷教练因为工作关系只要一没去跟踪，敏捷规则就会松懈下来。如果项目组内部有人熟悉敏捷，保持持续的跟踪，效果会更好一些。在敏捷的实施过程中提出了很多的问题，比如状态更新不及时，多任务并发的时候如何去处理等等。NSEC项目组采用的方法是ScrumWorks和卡片同时进行的方法，所以每个人除了去更新卡片的进度之外，同时还要去更新软件里边的进度，所以忘记更新的概率很大。在AOM的实施过程中，同样也是ScrumWorks和卡片同时使用，但是做了改进，每个人都只需要去更新卡片的进度，并由专人把每个卡片的进度同步到ScrumWorks中去。这个工作由每日例会的主持人负责。除了同步进度之外，主持人还需要每天在例会开始时候向大家报告项目的总体进度（已做的、正在进行的、未开始的），并且还要对本次sprint的完成时间进行预估，除了例会之外，还需要负责sprint计划会议和回顾会议。AOM的例会主持人是每周轮换的。每周轮换主持人的效果很好，每个人的积极性和学习都非常投入，项目成员对于一些深入的做法也比较容易接受。一个典型的例子就是他们的设计和文档工作，做到了很仔细的程度。但是每周轮换主持人也有不好的地方，就是团队主持人的能力提高速度比较慢，因为每周都是新人，所以每周都是初学者状态，直到一次轮换结束。如果在此期间敏捷教练缺席的话，敏捷制度就可能松懈。相比而言，ASPI项目的轮换做得就比较好，轮换是以月为单位。主持人有充分的时间来学习和提高，即使敏捷教练缺席，主持人也可以担当起“规则的维护者”这个角色来的。

从AOM和NSEC的敏捷实施过程中来看，都出现了每个人都只关注局部而忽视总体的情况，最后解决的方法也大同小异，基本都是派出一个专人去负责这个事情。也就是我们的敏捷团队中依然存在有“架构师”的角色。

在任务评估方面，NSEC是最早引入“打扑克”backlog评估方式的项目组，但是NSEC在backlog评估完毕之后，没有去进一步跟踪point数和实际工时的对应关系，也没有在总结回顾的时候评估point评估的准确性。对比AOM团队和BPM团队，目前也仅评估了每一个backlog的point数，并没有深入去评估每个task和工时的对应关系。ASPI评估了point和每个task的工时，但是没有去跟踪两者的对应关系。从实践来看，不把point换算成实际的工时，对敏捷的继续发展没有多大的影响。但是和NSEC相比，其他几个项目组采用了简单的效率计算公式，就是“效率=sprint的总point数/（人数×sprint工作日数）”，这个效率就是每人每工作日可以完成的point数，目前的数据是1个point/人日，因为一个point对应0.5工作日，所以也就是平均工作效率为50%，虽然有提高的空间，但是也已经够可以了。

在我们参考的书中特别提出，敏捷在实施三个月之后会有危机出现。事实上我们虽然没有出现危机，但是也有了一些的坏味道，比如改进错误的速度降低了，随意增加backlog或随意扩大backlog的工作量，随着时间的推移，在大家习惯了敏捷的快节奏之后，问题会出现的更多，应该对此做好准备。

NSEC的另外问题是缺少一些敏捷的要素，比如现场没有客户或客户代表，做完之后和客户的期望不符导致返工等。经过我们的讨论，认为客户不再现场有几种方法可以缓解或避免：要么有客户代表或让产品经理和客户充分沟通，要么使用设计原型和客户事先就达成一致，要么就是建立UAT（User Acceptance Testing）环境，让用户可以实时看到系统的变化情况。

在讨论过程中，与会人员冒出了两句经典错误认识，“敏捷不要文档”和“敏捷实施需要高超的能力”，遭到了大家的驳斥。首先说“敏捷不要文档”，对了一半，敏捷只是不要重复去做一些只为了看的文档，敏捷更重视过程原始数据的收集和分析。也就是说，如果文档和推进项目进度和交付的目标不符，那么这种文档就尽量不要，即使需要，也是用最简单的格式记录一些原始数据就可以了。至于“敏捷实施需要高超的能力”，正好相反，从我们的实践中就可以知道，敏捷的实施并不需要什么特别的准备，只需要项目团队实施敏捷的共识而已。更不需要管理者有什么高超的能力，无论如何实施，敏捷都“不会做的比项目组的现状更差”。

下一次的聚会，依然讨论NSEC的敏捷实践。

本文链接

项目管理沙龙第六次聚会纪要--模式“苹果酒屋”

2011-11-13T17:10:00Z

项目管理沙龙第六次聚会纪要--模式“苹果酒屋”

《项目百态》模式36名字叫“苹果酒屋”。大意是说，苹果酒屋是工人们下班之后的聚会场所，他们经常在吃完饭之后，一起爬到房顶上去乘凉，喝啤酒。于是女主管就制订了苹果酒屋规则，基本上就是“不许爬到房顶上”，“不许喧闹”等诸如之类的规定。可想而知，这种“苹果酒屋规则”不会有人遵守的。因为规则的制定者从来不会在苹果酒屋住宿，也当然不会知道屋顶上是那里唯一凉快的地方。

这种“局外人”制定规则的情况在企业内部非常常见，最终的结局也都和“苹果酒屋规则”差不多。会上列举了几种常见的推广场景，一种是“强推法”。比如“空降”到项目组或公司的能人，经常会不顾公司的现状，强行给他的下属制定各种规则，试图将做出改变。这种强推的手法，经常会导致项目组的动荡，进而引发人员的非正常变动。但是强推并不总是坏的，当年华为从IBM引进并推行制度的时候，也是一样是强推，并且任正非还特意强调几年之内不许改。一种是“循序渐进”推进法，一点一点地让“局内人”去体验，逐步获取经验，然后加入更多的规则，最后所有的规则都生效。这种做法需要耗费很长的时间，并且还需要专人进行跟踪和分析；一种是“自制规则”，这个也是《项目百态》的作者推荐的方法，即由游戏者自己来指定规则。这样无论是规则的接受程度，还是实施的效果，都会非常的好。但是这种方法容易走弯路；另一种是“专家法”，即通过利用具有专家身份的人，来向大家推行新规则，并且在规则的实施过程中不断地解答游戏者提出的问题。专家可以让游戏者快速地形成共识，并且朝正确的方向前进，但是同样需要在实施过程中进行跟踪和监督，及时对方向调整。

这些做法都各有利弊，归纳起来，无非就是时间、空间和效果上的折衷和平衡。谈到这里，有人从自身的经历，谈到了程序员做了一段时间的测试之后，再回去写代码的话，代码质量会变得很好，很容易测试。这种角色的互换，比推行任何一种“测试要求”/“测试标准”的效果都要好。这时，有人举出了DT网项目的例子，因为第一期已经进入了维护阶段，所以该项目的下一阶段的开发项目就明显开始注重质量了。

相比这种通过“自身实践”得到的改变，让专家对工作进行总结，得到“最佳实践”方法之后，在全公司推广并评估效果，这种效率就会高很多。其实这么做也就回到了我们刚才讲的“专家法”的推广了。

因为刚才谈到了“测试”问题，所以话题继续围绕测试展开。有人谈到了测试人员的水平问题。现在很多公司里，程序员的薪资水平要比测试人员要高很多，也就是程序员的编程水平通常比测试人员要高。可是引出了一个问题，就是水平最高的那个程序员的代码，谁有能力测？这个问题的答案并不简单，首先要看公司处于什么样的市场地位，处于领先地位的公司更考虑质量一些，处于追赶地位的公司更偏重功能，所以前者的测试要求会比后者高一些。其次要看公司的价值导向，眼光长远的公司对质量及测试的要求就高，急躁一点的公司对测试的关注度就小一些。还有就是要看项目的类型，对于产品型的项目，质量要求就会高，而对于一次性的定制项目，质量要求就低一些。其他还有很多的因素，包括公司的大小、技术能力等，都会影响到对测试的编制、地位和安排。

虽然如此，但是测试人员的水平大于开发人员的假设也并不一定成立。因为测试所需要的并不只是个人能力，和开发相比，测试有更多的流程，更多的工具，也有更多的有成效的方法来弥补与开发人员的技术水平差异。从某种程度上来说，产品的测试并不是依赖测试人员，而是开发者自己来进行的。因为所有的测试类型中，“单元测试”是最重要的测试，而单元测试的主要编写者恰恰是程序员自己。可是我们发现大部分的中国程序员都十分痛恨单元测试。我们一位与会者给大家解释了一大堆的“单元测试”概念，比如测试覆盖率，条件测试，边界值测试等等，以及单元测试的重要性又是如何如何。这些话从公司管理人员、项目经理、测试人员、客户以及维护人员，都非常消受，可是从程序员的角度听来，则是非常刺耳。虽然从实践中来看，有适当的单元测试覆盖的产品和没有单元测试的产品相比，后期的BUG量可以减少六至八成，但是这么重要的一种编程行为，即单元测试对于程序员的意义，哪怕是TDD都没有明确地强调出来：

“单元测试可以极大地降低调试的难度，加快开发的速度！！！”

这个其实也是我们沙龙要对所有程序员发出的强调。实际上，程序员的水平越高，对于测试也就越重视。当然，除了提高人员的自觉性之外，要推广单元测试还需要流程和制度的安排，比如结对测试。另外，测试的独立性也很重要，现在的测试都是被开发牵着鼻子跑，这种情况严重降低了测试的效率。

在讨论中，有人提到了一种反面现象，就是如果片面强调单元测试覆盖率的话，会有人只写出测试“永远正确”的单元测试来（显然这是中国式应试教育的变种）。经过讨论，大家认为这种情况并不严重：通过培训，可以提高程序员们对测试的能力；通过引导，可以让程序员们意识到1到2年的开发时间和10年为单位的运行维护时间相比，眼光应该更多落在持续的维护和升级上，避免一些短期行为对产品质量的影响。

最后，大家总结出来了一种“代码show”的方法，就是项目组不定期地召开“代码秀”，让项目组每个成员都找出自己写的最好的代码和最差的代码，展示并解释给大家，并集体讨论和分析，甚至还可以请专家点评。会议不做记录不批评更不做考评，让与会者可以没有后顾之忧。通过这种方式，我们觉得是有助于提高大家编码能力的。

嗯，这样算是“专家推广法”么？哈哈！

本文链接

项目管理沙龙第五次聚会

2011-11-09T14:27:00Z

项目管理沙龙第五次聚会

本次的话题从第30个项目百态模式《短铅笔》开始。“短铅笔”模式里最让人印象深刻的是这一句话“只有把用短的铅笔交上去，才能更换一支长铅笔”。很多人都遇过这样的公司，因为要所谓的“控制成本”，结果却把自己的员工当成了“贼”那样提防，显然这是一种错误的做法。

有人在聚会上提出了另外的观点，“成本控制无所谓好与坏，关键是从什么角度去看”。不同的角度看问题，得到的结果是不一样的，对于公司来说，当然是要千方百计盈利，所以“控制成本”本身并不是问题，但是在做法上一定要考虑“负面情绪”的影响。

另外有人举了一个真实的例子：一个部门的重要会议上，一个员工突然接到他老婆的紧急电话，要求他去医院接她。但是这个会议却了他就开不成，而且老板在场。作为老板，这个时候怎么处理才是最恰当的？经过讨论，最合适的方法就是先询问是否可以开完会再去，如果不可以，就派公司车去接送一下，减少时间浪费。而现实中这位老板却是和员工发生了一点不愉快，让本来能够提高核心员工满意度的行为，变成了一个彻底的减分动作。

在任何一个行动上，如果是一种公司行为的话，就一定要考虑是否能够产生收益和回报。这种收益可以是金钱、感情、知识等的各种形式。如果说因此的“投入”和“回报”不合算的话，就需要考虑是否要停止或者干脆不做。典型的例子是我们集团提供了一年的“下午茶”，虽然出发点是解决有人下午肚子饿的问题，可是实际上对每个人都只是纯粹的解馋作用，有它不多，没它不少，但是真正晚上加班饿肚子的情况却无人理会。所以这种“投资”行为完全是失败的，因为它想解决的“问题”根本就不是问题，真正需要解决的问题却没有涉及。

另外的例子是某个与会者的亲身经历，因为工作需要，他做了一种技术的预研，打算完成之后同时在几个项目组进行实施，但是却在即将成功的时候，被迫中断，并进入某个项目组继续他的技术。围绕这个例子，大家给他做了一些分析，一致认为他和上级领导的沟通出现了问题，进度不透明，沟通不到位，导致功败垂成，而且显然他的工作策略也有问题。从公司的角度去看，在某个项目组实验技术成功之后再推广，风险最低，效果也最明显。这不正式“敏捷”所倡导的方法么。

从这个例子里我们可以看到，人处在不同的位置，其成本计算模式也是不同的，因为每个位置的人看到的成本内容并不一致。成本除了显性成本之外，还有隐性成本。回到一个PM的立场去看，PM是对项目了解最全面的人，所以PM要充分了解上级对项目的看法，并且在上级需要作出决策的时候，及时给出建议和选择项，让他充分了解项目中的隐性成本因素，有利于上级作出更准确的决策。

企业要消减成本，必须要提高员工价值。但是对于企业来说，衡量员工价值的重要方式就是“绩效评估”。随后话题转到了绩效问题上，也正好契合了第64模式《乌比冈湖儿童》的话题：通常绩效评估都是不准确的。与会者谈到了很多的绩效评估方法，比如外企通常会规定很多KPI，thoughtworks公司提倡的自我管理、团队管理等。但是首先公司要对员工的定位要清晰。

最后讨论了一下第75模式“冰箱门”，项目组有一个公开的，大家都可以方便接触的沟通场合是非常重要的，在敏捷项目中，有“看板”，有“每日立会”都符合这个模式。

本文链接

项目管理沙龙第四次聚会纪要--模式“快！赶上”和“死鱼”

2011-11-06T12:50:00Z

项目管理沙龙第四次聚会纪要--模式“快！赶上”和“死鱼”

今天聚会讨论了两个模式“快！赶上”和“死鱼”，在 http://book.51cto.com/art/201101/244195.htm 可以看到两个模式的内容。

模式“快！赶上”是一个正模式，也就是好的模式。这个模式里其实讲了两个极端的情况，一种积极前进的“强团队”和一种拖拖拉拉的“弱团队”。与会者对强团队的特点非常有感触，部分参加EAC的与会者认为早期的EAC团队就是一个比较典型的强团队。当时EAC团队在去北京之前，大家都不知道客户的需求是什么，但是到了北京之后封闭开发的那段时间里，形成了一个“客户沟通-分析-实现-客户验证”的一个短促而高效的迭代循环，而团队每一个人都对自己的任务非常明确，弯路很少，即使走了一些弯路，在极短的时间内就可以纠正。EAC的这一段时间，给每一个参加者留下了深刻的印象和回忆。

会中有人问如果谈EAC这段时间的贡献，领导和团队的哪一个贡献较大。有人认为可能会达到1：1的程度，因为别忘记这个是由公司研发的精英组成的团队，而这种水平的团队，即使没有管理，他们也能工作的很好。其他与会者认为组织者会更重要些，作为一个组织的推动者，关键是要先动起来，当整个团队工作形成一种节奏之后，做什么事情都会变得快起来。当“团队的能力”到“领导者的信心”到“客户的满意度”形成一种正反馈循环的时候，团队自然就渐入佳境了。

目标明确是团队能力走强的重要因素（甚至可以是最关键因素），在“明确目标”上，团队领导的重要性毫无疑问是最大的。在如何划定目标范围的问题上，有与会者提出了从微软学习到的方法，就是凡是划定范围，先划定“不做什么”，然后再定“做什么”。在我们前几次的沙龙中经常提到“客户不知道自己要什么，但是很明白自己不要什么”，从这个角度也很容易推断出，先定“不做什么”的合理性。比如我们今天沙龙的目标，首先就是不谈设计，也不谈需求分析。即使不说下去了，大家心里也觉得这个目标比说之前明显要清晰了一些。

这两个模式，都属于团队的极端情况，实践中都很难遇到，大部分团队都是介于两者之间的状态。话题自然就转向了团队管理中如何兼顾和管理那些较弱的成员的问题上。有人回忆了他项目管理生涯早期所遇到的“个性很强”的组员，最终找个机会这个把组员“送”给了其他部门的故事。另外有人也说了一个拙于表达的成员因为不适应敏捷开发的氛围而离职的事情。这时候有人提醒大家，PM在这两种情况下一定要注意沟通，因为无论是哪一种团队成员，他都有自己的诉求和原因，在充分了解对方的诉求和原因之后，才能有针对性地采取措施。不过有人有提醒大家，作为PM，这个时候也受到资源（尤其是时间）的约束，他可能没有时间去慢慢地沟通和帮助后进生提高能力，将这种人请出项目组其实也可能是一种无奈之下的最佳选择。

不过大家一致同意的是，采取敏捷管理方法的团队，无论是团队氛围，还是成员能力培训上，情况都要比传统管理方法的团队要好的多。

模式“死鱼”是一个反模式，讲述了另外一种类似于“死亡行军”的团队形式。和前一个模式相比，他们有一个共同的特点，就是“项目经理”，只要项目经理尽力，“弱团队”和“死鱼团队”都是可以缓解甚至避免的。在如何防止出现死鱼团队的问题上，与会者很快达成了一致，就是“透明度”，无论对于高层的管理者还是客户，保持一定的透明度有利于他们对项目状态的充分了解。当然，如果项目正好用了敏捷管理方法那就更好了，在第一个迭代之后就可以得到工作效率的数据，和工作总量除一下，就得到时间了。只要客户是理智的，看到数据就会说服。接下来无非就是三角关系“功能-质量-时间”中砍掉哪一些的问题了。

但是针对中国特有的“献礼”工程怎么办？这是有人提出的新问题，如果你是修建某个高速铁路的项目经理，客户要求在某个特别的日子就载客运行。你怎么保证不出现事故？讨论的结果是“透明度”原则还是有效的，毕竟每个人都是希望项目往好的方向发展。实在不行，大不了通车之后实现全路闭塞，每次路上只开一辆车。

另外有人举例ZS项目，讲述了客户对项目不管不问的情况。随后总结下来，大家认为这个属于不可抗力。不过我个人觉得这个话题还有继续讨论的空间。

最后总结一下本次沙龙，按照书本的顺序依次讨论所讲的模式效果不好，下一次还是要认真选题才行。

本文链接