项目管理修炼之道

前言

我的藏书中有一些非常经典，如迪马可、温伯格、布鲁克斯、麦康乃尔、考克伯恩、麦卡锡还有汉弗莱写的书

• 从项目管理相关的教科书与PMP的培训教材里能够学到的是一个项目经理需要具备的基本技能。这些技能只能让你成为一名项目经理，但是无法让你成为优秀的项目经理，其中的差异就在于是否有实战经验的积累
• 并不具有对项目整个图景清晰、理智的分析和认知，没有详细考量项目的驱动因素、约束、风险等。总而言之，就是没有一套成体系的理论、方法和实践
• 你的项目每天都在加快节奏，你的客户变得越来越不耐烦，大家越来越不能容忍无法正常工作的产品。也许你之前的做法还算不错，让你获得不少好评，可将来很可能不太奏效。你必须运用各种的方法和技巧来减少项目的风险，这其中就包括在每个项目中使用敏捷方法
• • *

第1章 启动项目

• 项目经理必须知道项目的关键驱动因素是什么、项目要怎么样才算『完成』，而且还得把这些结论写到章程中，让整个项目团队都能了如指掌

定义项目和项目经理

项目：一个独特的任务或是系统化的流程，其目的是创建新的产品或服务，产品和服务交付完成标志着项目的结束。项目都有风险，并且受制于有限的资源

• 在启动之前 ，着手收集信息，了解项目要实现哪些目标
• 开始时要知道项目的目标，这样就可以马上知道我们接下来要做什么了。知道要做什么、『完成』意味着什么，这对团队很有帮助

产品：项目产生的一系列可交付物

一个项目经理『被赋予管理项目的权力和责任，并带领项目团队，通过项目管理来达成项目的目标』

项目经理：负责向团队清晰说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品要要求，也能满足客户使用这个产品的需要

• 无论规模大小——是项目就有风险

管理项目的关键驱动因素、约束和浮动因素

• 要完成一个项目，如果不能理解项目的背景，前进的路上必须充满艰险
• 项目的背景是由所在组织的关键因素决定的。项目的驱动因素是什么？是否存在约束？有没有可能在驱动因素和约束之间进行折中？项目经理能否为自己争取更多的自由运作空间？
• 也许大家都听说过项目的『铁三角』：成本和时间是这个三角形的两条边，第三条边一般是质量或范围。其实铁三角过于简单了

• 像斯图尔特这样成功的项目经理会权衡许多因素，而不仅限于铁三角。以为只要让客户从铁三角中选择他最看重的两条边，然后就可以交付他想要的结果，这根本是痴人说梦

1. 首先，要写下客户的期望——从客户的角度来看，项目的驱动因素是什么。这个列表中应该包括：客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）
2. 接下来，写下项目的约束。环境是什么样子的？能否灵活安排团队的位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般只有项目出问题的时候才能改变）。约束决定了项目的规模、持续时间、质量
3. 对比客户的期望列表和项目的约束列表。脑海里蹦出来的项目成功的必要因素有哪些？选择其一，比如发布时间，这就是识别出来的项目的关键驱动因素
4. 应该还能看到功能集合、低缺陷率、发布成本等条目。在这些条目里，需要对哪些进行管理才能保证项目的成功？可以按重要性排列这些关注点。客户和出资人会在这些方面上对项目形成限制 。从中选择两到三项，我们称之为项目的约束
5. 有些条目很重要，不过它们有很大的调整余地，我们称之为浮动因素。一个项目至少要有三个浮动因素

这个项目的关键驱动因素、约束、浮动因素就都识别出来了

• 以我的经验，如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理
• 理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。大部分情况下，我们管理的都是不那么理想化的项目，所以如果项目有一个关键驱动因素、两个约束、三个浮动因素，这也是可以成功的。过多的关键驱动因素或约束，会让项目过于受阻
• 如果存在过多的关键驱动因素和约束，而且项目经理除了启动项目之外别无选择，这时所能做的就是选定一个关键驱动因素，并尽可能频繁地向出资人提交项目的产出，帮助他们决定自己真正想要的东西。在启动项目的时候，为了得到项目的成功条件，可以问一些与上下文无关的问题。还要定义出发布条件，这样就知道到什么程度算做完了

受到过多限制的项目难以逃避失败的厄运。过多的关键驱动因素，意味着没有人知道成功的条件是什么。 有必要的话，让管理层决定项目的关键驱动因素、约束和浮动因素。如果这不可行，那项目经理就自己做决定吧

使用矩阵表明项目的优先级

应对喜欢过多干预项目的出资人

• 要想明确项目真正的驱动因素，有两种不同的途径可供选择：预测未来；使用与上下文无关的问题

预测未来

• 让出资人设想这样的情况：现在离项目预定交付时间只剩三个星期，却还有功能尚未实现。（可以着重讨论该出资人需要的一两个功能）。除了没做完的功能之外，还有很多严重的缺陷等着修复。这样看来，要想在预定的发布日期之前 开发完所有的功能并修复所有的缺陷，很明显是不可能了。这个时候，出资人该怎么办？
• 如果出资人这么说：『把你的脑袋砍下来给我吧』那就该考虑『三十六计走为上』了
• 不过出资人很可能会这样说：『把这个该死的项目做完吧。你还需要几个人？』接着，你可以问他：『是先做完所有的功能，还是先修复所有的缺陷？』他一般会说：『这两个功能和这些问题都得解决掉』。再问他：『以项目目前的优先级顺序，是吗？』项目经理要经常帮助出资人搞清楚：哪些约束是真正的约束，哪些是出资人自己一相情愿的想法

使用与上下文无关的问题识别项目真正的驱动因素

• 从下面这些问题开始

1. 项目要怎么样才算成功？
2. 为什么想得到这样的结果 ？
3. 这种解决方案对你来说价值何在？
4. 这个系统要解决什么样的问题？
5. 这个系统可能会造成什么样的问题？

• 要注意：少用『为什么』之类的问题。『为什么』问得越少，对于业务需要反而能了解得越多。也得注意避免『怎么做』之类的问题，出资人会觉得你在让他们设计系统
• 在向出资人提问时，要营造平等的气氛。在纸上做笔记，而不是用电脑，这样你和出资人之间就不存在障碍了

编写项目章程，共享现有决策

• 项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。整个团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致
• 下面是我们的项目章程模板

1. 远景
2. 需求
3. 目标
4. 成功标准
5. ROI估算

• 项目章程是有意要设计成这么简短的，目的是帮助团队赶紧启动。它不会包含团队对于这个项目『完成』的定义，也不会介绍团队如何组织项目，但是已经足够让大家着手开展工作了

远景

• 每个项目背后总有一个缘由（或两个、三个）。描述远景的句子来说明项目的价值。越早向大家阐明项目的价值，团队就越有可能告诉你接手这个项目是否明智

需求

• 『2月20日发布的主要版本中，我们需要这个又棒又炫的功能』

目标

• 希望通过项目要达成的目的，不过客户跟出资人可能并不赞同这些目标

成功标准

• 围绕客户能基于完成的产品做什么给出的定义。
• 成功的标准并不涉及缺陷，而只关注能力

1. 要包括功能1、2、3……，这样我们的产品就可以打入目标市场了
2. 要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，并编写新的市场营销材料了

• 项目经理要确保成功标准中不会包含非项目人员才能完成的任务

ROI

• 项目经理可以估算项目的回报，试着计算ROI。在项目完成后，可以看看是否达到了当初预计的数字

理解质量对于项目的意义

• 出资人是为项目提供资金的人，客户是使用产品的人，他们不一定是同一群人——对质量的定义可能有差别。知道了对于项目来说『质量』意味着什么，也就部分理解 了『完成』的含义

1. 当产品处于市场应用的早期阶段时，顾客群的规模不大；但是技术狂热者们已经想先睹为快了，所以会面临比较大的发布压力。此时产品不必具有很多功能，而且也不必有很高的稳定性，但是它必须具备自己的独特之处，来吸引更多客户
2. 在产品进入市场的初期，无论客户群大小，众都会有各自不同的需求。所有客户都希望马上得到新版本，而且要具备他们自己想的的功能。此时的产品用起来不能太费事，不过由于只有你的产品能够解决客户的问题，所以即使有点儿缺陷，它的销路还是会很不错
3. 一旦产品（或有替代产品）进入到大众市场之后，实用主义者们就会关心产品的缺陷能否得到及时修复。如果在之前的版本中累积了技术债务，现在就到了还账的时候了。鉴于实用语义者拥有强大的购买力，管理层会按压压力而决定频繁升级产品——即使有些客户不想安装最新的版本。在加强产品稳定性的同时，每次发布的新版本中多少要加入一些新功能

铭记在心

1. 每个项目启动时都要有章程
2. 对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动
3. 要知道『质量』的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策

第2章 规划项目

• 在项目启动会议上跟团队成员一起把它过一遍
• 规划和日程安排是两种不同的活动

规划是指制订带有发布条件的项目计划，而日程安排则是对工作项目的有序描述

踏上征程

1. 跟团队成员商量接下来的几天或几周之内要做什么，同时要将项目的产出牢记心间
2. 如果已经收集到一些需求，团队就可以开始原型化的工作，或开展第一次迭代的开发工作了
3. 甚至根本不知道接下来该干什么，可以让一些成员去修复上个版本留下的缺陷

使项目足以启动的规划

• 规划不必完美无缺。实际上这也是做不到的。只要这个规划能让项目启动起来，同时能让大家看到成功的希望，就可以了
• 时间盒（timebox）是指特定的时间长度，个人或团队用它来完成某项特定的任务

我们最近的一个大项目，预计耗时两年左右 ，需经历多次发布。我们把制订初始规划的时间盒设定为三天。三天过后，我们有了项目章程、项目规划，并制订出了第一次发布的发布条件，以及前三周的工作日程安排。就是这些 ，不过已经足够启动项目了 我们最近的几个小项目（耗时不到半年），制订初始规划的时间盒设定为一天，其中包括安排一个为期两周的工作日程。当项目工作展开后，再根据执行初始规划得到的反馈，指导后续的规划 做一点规划，收集一些数据，再重新规划。这样做无往而不胜

提示：要根据经验而不是预言来规划项目 经验式规划也就是指不妨先做少量规划，再根据实际过程中收集到的信息反馈来影响未来的规划，这样做具有很高的可行性。预言式规划则是试图预测未来，是很难奏效的

开发项目规划模板

1. 产品意图
2. 历史记录
3. 发布条件
4. 目标
5. 项目组织
6. 日程总览
7. 人员配备（人员曲线）
8. 建议日程
9. 风险列表

产品意图

• 简单描述产品，为什么公司要开发这个产品，它能为公司带来哪些效益，等等。发布版本的价值何在，它是否在后续发布版本（用三四句话）

历史记录

• 对项目情况知道得越少，感到惊讶的几率也就越大

发布条件

• 要详细列举出项目产品的关键可交付物。想识别出它们，不妨问一问：『要是不那么做，我们还能发布产品吗？』要将功能、性能和质量要求都涵盖在内

目标

• 书籍的目标也许隶属于以下几类

1. 产品目标也许包括这样一些需求，它们已经被设定好优先级，但是不承诺在当前发布版本中完成
2. 项目目标也许是诸如性能标准之类的目标，对它们的要求会高于一般需求，或者是『在产品交付时，要将未解决缺陷的数目从50个减少到40个』
3. 团队目标可以是『增加产品的自动化冒烟测试所占的百分比』。团队也许希望改进某个特定功能的性能或可靠性
4. 组织目标可以是『减少项目的耗费时间，以提升组织的敏捷性』

项目组织

• 要明确说明团队在项目中的职责分配，指明项目经理如何使用生命周期组织项目工作，要采纳哪些关键实践，以及是否有决策人可以影响当前项目。如果你知道需要一些原型化的工作，要在这里说明
• 要说明项目的一般运作方式。比如，在项目启动时加强整个项目团队意识 ，招聘新人，开发包括代码和文档在内的完整功能，编写所有的代码，同时检查一下（在那个时间）可以记录些什么，诸如此类的事情

日程总览

• 应该创建一个日程总览，其中标有主要的里程碑，还要说明人们从这些里程碑处可以得到什么
• 日程总览让我的领导知道项目的实际进展

• 对于复杂项目来说，如果在开始之间就已经三汤五割到日程安排上的风险，不妨考虑多准备几个方案，让出资人进行选择。下图提到的组织就是基于矩阵的方式来组建项目团队的

人员配备

• 很多项目经理不能控制项目团队的人员配备。要在这里说清楚：要在何时需要多少、何种类型的人员

建议日程

• 使用公共区域，让大家都能看到日程安排 。这样一来，如果日程有问题，项目团队也可以早点提醒项目经理

小心过早细化日程 如果过早地向出资人提供了非常详细的日程，他们就会认为项目中几乎没有风险。他们会注意到日程中的项目结束日期，并以此作为项目真正的结束日期

制订项目风险列表

• 在项目规划中，至少要将排名前十的风险记录在案。还要经常监控这些风险，并在适当的时机更新这个列表。如果觉得项目目前的风险不到十个，不那就买吧眼项目团队一起坐下来，进行一次头脑风暴
• 要尽早开始识别和管理风险

制订发布条件

• 发布条件会告诉你项目中『完成』的含义
• 制订发布条件不是为了责怪哪个组的人，而是要为产品是否可以发布提供一些客观的评判标准。出资人和客户可以用发布条件作出合理的决策，对产品的质量和风险做出判断
• 制订发布条件时，要先判断当前项目的关键因素是什么。例如，为什么公司要做这个项目？为什么客户会买这个产品？
• 使用下列步骤来制订和使用发布条件

1. 确定当前发布最重要的因素，这样可以将监控发布条件的活动贯穿项目始终
2. 草拟发布条件
3. 让发布条件符合SMART原则 ：确定的、可测量的、可达成的、相关的和可跟踪的
4. 获得项目团队与高层管理人员认可

确定当前项目最重要的因素

• 当前项目的关键因素是由组织的需要和客户的需要共同组成的。客户在购买产品时，不会考虑其中有无缺陷或是缺陷数目，而是要看到这个产品解决了困扰客户的某个问题

草拟发布条件

1. 所有代码必须针对所有运行平台编译并构建
2. 没有高优先级的bug
3. 所有未解决的bug和临时解决方案都要记录在版本发布说明中
4. 所有计划好的测试都要运行，要保证通过率至少为98%
5. 在最后三周内，未解决缺陷的数目要不断下降
6. 在发布之前 ，功能X要由开发人员完成单元测试，由测试组完成系统测试，由客户A和客户B完成验证
7. 准备6月1日发布

让发布条件符合SMART原则

• T表示可跟踪性，这可以让整个团队明白：在创建发布条件时，我们要能够在项目的整个生命周期中评估这些条件

在发布条件上达成多方共识

• 在就发布条件获得大家共识的过程中，可以提下面这些问题

1. 在发布日期之前 ，我们是不是必须满足这个条件？
2. 要是我们不能在发布日期之前满足这个条件，会发生什么？
3. 如果不能满足这个条件，我们的产品或公司是不是会因此而承担风险？人们的安全感是不是会因此被破坏？

一旦获得多方共识，就可以用这些条件来监控项目了

使用发布条件

• 到产品发布的时候，发布条件只能有『满足』和『未满足』两种状态
• 项目经理可以随着项目进度评估发布条件，并在项目预期结束时满足这些条件。发布条件不可能总是能够达成的。发生类似情况时，要坦诚面对现实

在必要时变更发布条件

• 假设项目经理所在的项目无法满足发布条件

1. 首先，要跟团队确认为什么无法满足条件
2. 接下来，向管理层解释无法满足条件的原因。促使管理层向项目团队解释目前的状况，就像这样：『我们曾经认为这些条件很重要，但是现在知道发布日期是更重要的。我们将会准时发布产品，即使不能满足所有的发布条件』如果事实如此，项目经理可以让他们补充：『我们会找出这次不能达成发布条件的原因，并在下个项目时注意不再发生同样的问题』如果不向团队解释，他们会觉得自己正在玩日程排定游戏

铭记在心

1. 项目规划是在不断进行的，这只是开始
2. 为项目团队、出资人和项目经理自己制订发布条件 ，以明确定义『完成』的含义
3. 项目规划不必完美无瑕，但是它必须存在

第3章 使用生命周期组织项目

理解项目生命周期

• 项目经理必须找出对于客户最重要的风险。选定的生命周期要可以很好地应对下面这些风险：是否能够及时发布、缺陷、特性、成本等，其他的风险可以通过一些实践来管理，还要为项目选好人手

生命周期概览

• 不同类型生命周期管理风险的方式

• 用甘特图的方式看不同的生命周期

在项目中寻求反馈

• 团队越早获得产品反馈（不是产品说明，虽然这也会有帮助），预测就越容易

大规模项目需要组合使用多种生命周期

• 多站点项目管理的关键，是要定义出各阶段交付物的模样，以及何时完成交付

管理架构风险

• 对于接近『完成』的原型，要尽早在项目中对其展开迭代，包括对这些原型进行测试。如果采用的都是『快而脏』的原型，那就很难发现架构的性能或可靠性是否可以满足实际要求
• 项目经理所在的组织，或者存在出资人、资深管理层或PMO项目启动之前 希望先看看架构的情况，或者存在如果不进行架构复查可能会带来很大风险的情况。这种情况下，我仍然建议项目经理要完整地完成一些功能的原型化设计，这样多少可以获得一些经验，有助于判断能否放心地在项目中使用这个架构。
• 在项目中，项目经理要随时注意架构 能否满足项目要求，而且这方面的风险发现得越早越好。如果不能及时察觉，整个项目可能因此而功败垂成

我最钟爱的生命周期

• 我喜欢在项目中使用Scrum来产生演进的架构和交付功能。这个项目管理框架可以让项目一目了然、易于审核，并且适应性很强。如果可能，我还会加入极限编程实践
• 团队成员对于敏捷式的协作毫无兴趣，我还是倾向于使用阶段式交付的生命周期，并用时间盒来限制需求收集和架构设计阶段

铭记在心

1. 在组织项目时，使用任何生命周期或是多种生命周期的组合，都可以让项目踏上成功之路
2. 不要怯于创建反映你自己项目实际情况的生命周期。『完美的』生命周期只是模型布局，你是生活在现实世界中的
3. 阶段-关卡流程或瀑布式生命周期，只有在确定使用它可以获得成功时才使用，而不是不经思考，上来就用

第4章 安排项目日程

• 最初的规划只要能让项目启动就可以了。在安排 （以及重新安排）日程时，要准备改进规划。在重新规划时，如果需要改进日程，也不必担心

注重实效的项目日程安排

• 估算要准确，而不是精确
• 在没有任何数据的情况下，如果想过早知道结束日期，我一定会犯错的。既然知道一定会出错，那为什么还要花时间去做详细安排呢？

提示：对于项目来说，规划和日程安排 二者不可或缺 一个注重实效的项目经理，为了先让项目启动起来，会做恰到好处的规划，并随项目进展不断进行规划和重新规划。不管怎么做，规划与日程安排都不可忽视，尤其是规划中的发布条件

• 生命周期是项目的模型，让别人看到项目是如何组织的。在创建日程时，可以将生命周期用作指导方针。不过每种生命周期模型都有其内在风险，无论采取何种方式安排日程，都要保证处理这些风险

提示：用时间盒限制初始规划 前期规划活动耗费的时间要尽量少，特别是在团队人员已安排到位的情形下 让每个人把注意力放在项目启动的关键活动上。一旦大家知道将来的一到两周内要做什么，项目经理就可以再考虑规划和日程安排中还需要补充哪些内容了

可供选择的项目日程安排技术

自顶向下式日程安排

• 一种低技术含量的日程安排技术——使用放在墙上的卡片。使用放在墙上的卡片安排日程，每个人就会把应该由自己完成的任务写在卡片上。然后再用线把这些卡片连起来。如果不知道从何下手，这个技术可以助你一臂之力

由内及外式日程安排

• 思维导图，把我知道的所有项目与项目有关的东西都放进去

哈德逊湾式启动

『哈德逊湾式启动』方式源自17世纪加拿大东北部的哈德逊湾公司，这家公司配备了运送皮手的商船。为了确保商船不会忘记需要的东西，他们会在距离哈德逊湾几英里的地方先临时停留一段时间。由于离海湾并不远，商船 可以确保他们在离开文明世界进入茫茫大海之前 不会忘记任何工具和给养。使用这种一种启动旅程的短时间方式，他们能明确知道自己能否可以安然过冬

用低技术含量的工具安排项目日程

• 把任务写在即时贴上很方便，再将其贴在墙上，跟团队其他成员一起讨论—有时声音很大——任务的顺序 、分配或者项目的风险。而且，如果任务的摆放位置不对——因为团队发现可以通过另外的方式来组织项目——要移动这些即时贴也很容易的
• 项目经理一次只能输入一个任务，而且只有项目经理可以创建任务。日程软件一次只能展示一页信息，如果团队人员不能看到整个时间表，他们可能对整体计划没有概念

使用即时贴安排项目日程的基本技术

• 将整个团队集中在一个房间，这个房间有一面很长的墙或者一块很长的白板。为每个人发一叠黄色 即时贴和一支中等粗细或更粗的黑笔
• 让每个人把其所有的任务都写在即时贴上，每个即时贴一个任务。写完之后，他们可以将其贴在墙上

• 现在项目经理就可以后退一步，把位置让出来了。项目团队成员开始一起讨论事件的顺序、任何前置条件、假定以及问题
• 开发人员写自己任务时，会向需求分析人员、需求编写人员和测试人员提出问题，而测试人员也会有问题要问他们。团队就已经开始像跨职能团队一样工作了
• 在现在的日程安排中可能会有下面问题

1. 项目经理可能会看到很长的任务安排序列。就得问问团队：是不是有什么阻碍了他们以并行的方式并行

使用即时贴和箭头安排项目日程

• 当时间表稳定之后，他们会在即时贴之间画上箭头，这会有多种帮助作用

1. 如果一张即时贴掉下来了，他们会知道再放回什么位置
2. 用即时贴做完日程安排后，可以将其结果 录入到日程安排软件中

为每一个职能组使用即时贴安排项目日程

• 使用即时贴式日程安排 ，通过让管理层察看每周的时间计划，让他们知道按职能组织 的团队会拖项目后腿。
• 在一个大白板或是粘在墙上的白纸上画几条竖线，每条表示一周。使用不同颜色的即时贴，用其表示处于不同职能组织的不同人的工作状况

按功能使用即时贴安排项目日程

• 如果管理的项目很复杂，在集成项目时会发现很多依赖关系，这时不妨通过即时贴规划一个迭代要完成的工作任务，这会有很大帮助
• 当团队需要将可交付物的代码集成到代码库中时，由他们自己去组织 。让团队写明严格要求的截止日期，『如果你到时候不能交付这个功能，那么在这个迭代结束时，我们就完不成任务了』
• 尤其是短期迭代的情况，项目经理不必将即时贴上的内容生成甘特图。项目经理可能要把即时贴用胶带粘起来，或者使用甘特图管理依赖关系

使用即时贴安排项目日程的好处

• 项目经理应该把各个团队的带头人或项目负责人召集到一起，确保他们理解：谁负责在何时将什么交付给谁。此时要解决的是主要里程碑，可以使用视频会议或网络会议系统，并使用类似于即时贴的方式来安排项目日程

基于可交付物的规划

提示：延迟的项目无法弥补时间进度，一定会延迟 在项目开始时，如果项目经理认识到团队没有按进度进行，那他就得想点别的办法了。延迟的项目是无法弥补时间进度的，它们会变得越来越迟……

第7章 创建出色的项目团队

• 创建出色团队需要两个步骤

1. 招聘或引进所有需要的人才
2. 发挥他们的能力，一起工作，成为高效的团队

招募需要的人

• 也许团队的人都不受你的管辖。关键在于每个项目都要有能够胜任工作的人，不管他们是一个人担任多个角色还是怎样
• 如果项目经理没有吸引、招募或淘汰团队成员的权力，那失败几乎无可避免

小心只会用PPT的架构师

形成团队凝聚力

• 帮助团队形成一体的最佳方式就是让他们一起工作，而不是去参加什么团队拓展活动。如果大家有同一目标，彼此承诺完成互相依赖的任务，而且采取商定好的工作方式，这就是一个团队

团队发展的5个阶段

1. 组建期（forming）：团队刚刚形成
2. 激荡期（storming）：当团队开始共同工作并彼此试探时
3. 规范期（norming）：如果团队（或项目经理）可以让彼此就大家的行为意见一致
4. 表现期（performing）：在这个阶段可以把工作干得不错 。当大家更加紧密地协作时
5. 中止期（adjourning）：项目完成

项目经理可以促进团队经过这些阶段，但必须花时间留意项目的风险和问题，并与团队成员不断沟通。不要把时间都用来与项目团队无关的人开会，或是绘制甘特图。如果你需要详细的甘特图，找一个全职的项目日程安排人员来更新甘特图

让组织配合你的工作

• 项目经理要让职能经理知道：团队成员要先对项目负责，而不是对职能经理负责。这意味着项目经理要与职能经理讨论多任务的危险之处

以项目经理的方式管理职能团队

• 每个职能项目经理领取一些功能或是一系列需求，并使用跨职能团队来完成项目
• 尝试找一小组开发人员、测试人员和技术文案一起，按功能进行开发 。
• 要是人们（包括经理和技术人员）都决定待在自己的小天地，看看是不是能找一个人作为总体项目经理，从项目一开始到最终发布，他都对项目负责

管理矩阵式项目团队

• 要跟职能经理说好，谁负责给团队成员反馈和指导。项目经理（或技术带头人，或项目中其他人）要担起这个责任，对项目成员的表现进行反馈
• 职业是由职能经理提供的。要跟职能经理分清楚，哪些人负责与团队成员讨论什么样的话题

管理跨职能项目团队

• 你要知道团队中每个人的工作方式，这样才能提供有价值的反馈，并对他们进行指导
• 你也许不能直接管理每一个人。这种情况下，你的下属项目经理和技术事实砂人就必须知道如何给出有效的反馈和指导。

对必需的团队规模了如指掌

• 项目经理一个人最多还是可以管理9个人的团队。如果团队成员多于9人，项目经理需要一些技术带头人或是其他项目经理的协助
• 用9这个数字是有其原因的。一旦到达这样的规模，团队的气氛就会发生变化 。大规模团队成员之间的关系并不紧密。特别是位于不同地点的团队，项目经理要花费更多精力来让团队觉得自己是一个整体，而不是一个小组

责任与权威：项目经理也要使用自己的影响力来让人们完成你需要他们做的事情 。要事先在组织中打好发挥影响力的基础。这样一来，等你需要帮助时，就可以吴娟其他人来帮你推进项目了。我曾经让销售人员、服务人员、运营人员，还有市场人员来帮我推进项目

知道何时应该加人

• 如果项目刚启动，项目经理应该尽快加入需要的人手。每次人员变动都会对团队的工作效率产生影响，所以应该尽量一次性将人员配备整齐，避免成员变更降低工作效率
• 如果项目进入到中期，加人就得小心。要记住布鲁克斯法则：向进度落后的项目中增加人手，只会使进度更加落后
• 项目快结束时，要避免新增人手。只有下面这种例外情况才能加人：项目的延迟已不可避免，而且当前的人手也无法完成项目。那就增加需要的人吧，然后重新规划

成为出色的项目经理

提升人际交往技能

1. 倾听技能：项目经理要倾听团队成员的言谈，还要从他们那里了解 项目的状态
2. 谈判技能：项目经理要争取资源、交换资源和信息
3. 写作技能：项目经理要能够编写计划，让每个人都可以理解计划以及做出的妥协
4. 以目标为导向：项目经理要能够完成一个项目，还得帮助大家把注意力都放在项目的目标上
5. 了解和尊重项目相关的工作人员。项目经理不必成为每个人的朋友，但是必须要能看出来别人什么时候陷入困境，什么时候出现了问题，什么时候一切正常运转
6. 能够应对信息不足的状况，也就是可以适应信息不足的情形，并且做出决策。我管理过的每一个项目，信息都不是完备的
7. 能够管理细节。即使项目经理不是一个细心的人，也必须要学会管理项目的细节
8. 解决问题的技巧：项目经理要识别出哪些问题当前必须解决，哪些问题可以推迟，以及如何解决问题。『三种备选方案原则』（The Rule of Three）是很好的问题解决工具。（一种备选方案是陷阱 ，两种备选方案是两难的困境，三种备选方案就可以让相关人员开始考虑真地该怎么做了）
9. 辨别、寻找进度的障碍，并消除它们

掌控项目的能力。要观察目前的状况，指出项目当前方向与你最初的规划有何不同，并可以引导 项目进入新的状态

提升功能性技能

1. 对于项目中的问题以及如何解决这些 问题，项目经理不需要知道二者的具体技术细节，但是如果一点都不了解问题和解决方案的专业知识，项目经理就很难做出好的决策
2. 不懂技术的项目经理，不要试图遮掩自己技术上的不足。要敢于承认自己的不足，雇佣聪明的人，而且可以在了解项目的技术点时咨询这些聪明人。如果项目经理能够坦诚表明自己的弱点，并表示出学习的意愿 ，团队是愿意帮你成功的
3. 理解不同的生命周期模型，知道哪一种最适合你的项目
4. 能够安排项目的日程规划
5. 能够估算任务，或者指导其他人完成任务估算
6. 知道如何评估风险、管理风险
7. 清楚如何度量项目状态，以及如何报告项目状态
8. 知道如何处理已完成和未完成的工作，可以使用速度图表或是挣值

提升领域专业知识技能

• 软件项目的项目经理要能理解人们收集和排序需求的方式，要知道如何了解设计是否完成、如何评估技术风险和日程风险，要知道软件配置管理系统的作用以及如何有效作用，还得知道测试人员能够提供什么样的信息

项目经理不必成为项目的技术专家，但是应该了解 开发用到的技术是如何解决客户问题的，还要知道团队用到的流程，以了解项目风险 项目经理越了解开发中的产品，就能做出更好的决策，或是指导团队做出更好的决策

知道何时该全身而退

什么样的组织不适合你

1. 你不能选择团队成员。成功的项目经理可以一次管理一个项目。要想多管几个，你会把自己搞疯掉，而且基本上不可能成功
2. 出席会议变成行政任务
3. 出资人让你不得好死
4. 别人想让你承担一些开发相关的工作。如果你在管理项目的话，要帮助大家看清目标、移除障碍，还得监控他们的进度，你是没有时间从事技术工作的
5. 管理层强制切分项目工作。根据驱动 因素、约束和浮动因素来重新组织 ，要么走人。在资源不足的情况下启动项目，必败无疑

什么样的团队不适合你

• 对于管理项目需要的信息了解不足。项目经理可以没有管理过此类项目的经验，但是一定要知道团队如何工作，以及项目试图解决的问题
• 你的管理层非要给团队施加帮助，可你无法拒绝
• 对于管理项目需要的信息了解过多。你的技术经验非常丰富，而且也曾管理过项目。不过这个项目用到的技术你非常熟悉。你能做到不去管技术，而全心全意管理项目吗？

什么样的产品不适合你

• 你不具备解决方案空间域的专业知识——其他人也没有。你需要做原型化的工作，还得按功能逐个实现，这样就可以知道团队是否交付了真正有用的东西

铭记在心

1. 项目风险越大，团队的多样化程度就应该越高
2. 提升多方面的技能：人际效技能、功能性技能、领域技能，还有非技术功能
3. 知道何时应该离开

第8章 掌控项目

• 如果还没有制订出项目的仪表板，现在赶紧动手。定性和定量的度量方式都需要，这样才能反映项目的真实状态。
• 掌控项目意味着寻找风险和管理风险

掌控项目的节奏

• 下面这些打断项目正常节奏的问题

1. 不知道先要完成哪些需求
2. 允许项目的需求收集阶段持续过长时间
3. 允许GUI随时发生变化，而GUI相关人员在项目中不知该如何是好
4. 没有架构的整体描述，不知道各个部分如何构成
5. 无法及时向项目中加入必要的人员，使得他们很难取得成功

举行中途回顾

为需求排序

• 评估的条件

1. 功能对架构的影响
2. 估算的实现时间
3. 该功能对于特别重要的客户的重要性
4. 特定人员实现或测试该功能的可行性

评估标准

• 制订并维护不断变化 的需求日志：产品待办事项列表。要是有可能，只要一听到需求就应该对它们排序

用时间盒限定需求相关的工作

• 即使不适用迭代式开发 ，也要用时间盒限制 初始的需求收集和分析活动
• 用时间盒限制初始的需求相关活动，并持续收集更多的需求。项目经理可以选择一个合理的短时间段（不超过项目总体持续时间的10%），要求收集到最重要的需求
• 用时间盒限制所有的需求定义活动

提示：用一分为二的方式减少迭代持续时间 如果迭代效果不好，不妨试试把它一分为二。如果迭代持续6周，就改用3周

使用波浪式的规划和日程安排

• 里程碑定义完成后，要为每个里程碑设定验收条件。这样一来，项目经理就可以知道里程碑何时算完成了。不要试图规划所有的工作。只规划将来3-4周的详细工作，这样每个人都知道接下来要做什么，后续几周要完成哪些任务
• 项目经理要做的就是监控项目进度，牢记里程碑验收条件。里程碑验收条件是为了达成特定里程碑必须要完成的任务
• 团队一完成手上的任务，项目经理就可以向当前的详细规划中添加新的任务了。假定项目经理制订的是4周的波浪式规划，如果目前处于第3周，那就可以规划第7周的工作了
• 敏捷生命周期会自然而然地使用波浪式规划，因为每个迭代都是一个时间盒。项目经理规划的工作只需启动迭代即可，要在迭代中监控进度，而且确保迭代完成时提交完成的工作

创建跨职能团队

• 我建议项目经理应该在自己的团队中配备几种不同角色的人员。团队的构成应该是跨职能的

1. 跨职能团队的工作效率更高。单一职能团队可以更快地完成各人负责的部分
2. 具有多样性。测试人员试图从可测试性方面考虑问题，技术文案跟开发人员和测试人员一起确认如何表示项目产品的工作方式

保持合理的工作时间

• 项目经理如果发现项目工作进展过慢，可以考虑下面提到的这些 方法，并用之来维持项目的节奏

使用『小石子』

现在我们会把每个任务都拆成『小石子』（有时会用『探索式开发』的方式）

管理干扰

• 干扰会导致人们丧失多达40%的时间。有两种类型的干扰

1. 其他项目
2. 其他人

应对其他项目干扰

• 人们有时不知道他们的干扰会影响你的项目。将一周之内发生的干扰记录下来，让人们看到这些干扰的影响。要以事实为依据，但是不要去责怪别人——项目经理要起到教育和通告的职责

应对其他人的干扰

• 鼓励大家结对编程（或是结对制订需求、结对测试），这样人们就可以共同学习和了解 系统。如果结对不起作用，就要让人们在隐秘的空间中讨论，从而不至影响其他人。弄一个项目『作战室』吧，可以在其中贴出项目的仪表板、架构文档等各种产出物

管理缺陷，从项目初就开始

如何影响别人

• 只要你愿意放弃『命令和控制』式管理所带来的幻象，学习影响别人就很容易了。也许需要你在心态上做出调整

1. 记住问题不是你一个人的。在项目中，发布日期、功能集合、缺陷水平，每个人都对这些有责任
2. 思考你能为组织带来的价值。一旦明白了自己的价值，你就可以想想这些 价值对于别人的意义了。这些价值可以帮你寻求别人的帮助，并给予回报
3. 发现其他人或团队的驱动力。发现其他人或团队中为我所用的东西。有人喜欢做有意思的事情，有人希望得到公众或个人的认可。要把这个因素找出来
4. 建议项目经理和负责的人（或团队）共同面对问题。这可以让项目经理能够友善、开放地接受他人的建议和想法。如果让他们自己找答案，他们会更容易去解决问题
5. 倾听团队。团队会告诉项目经理他们要怎么样才能达到最高的工作效率
6. 在讨论时，给他人思考的时间。在推行你自己的想法时，要允许别人认真思考和质疑这些想法
7. 不要固执己见。如果你借助影响力，以协作方式工作，别人就能发送你提出的解决方案

• 如果运营与开发同时进行，我该如何应对干扰？

1. 调出几个开发人员，用1-2周的时间专门负责运营工作。并且在运营期间调换这些人员
2. 假定每个人每周只能用2-3天进行开发，其余的时间都用来处理突发任务。每个人在一天之内不能从事多个任务
3. 加入更多人手，这些人必须是喜欢从事『灭火』任务的。他们的首要职责就是解决突发问题，接下来才是项目中的任务
4. 成立一个小组，组员的职责就是负责运营

• 如果项目经理不在项目初期就开始管理缺陷，那缺陷就会反过来控制你。项目的技术债务会不断增长

铭记在心

1. 作为项目经理，你要带头考虑使用或调整哪些管理实践
2. 评估项目的问题，然后根据这些 问题来判断使用或调整哪些实践
3. 要寻找可以建立和维持项目节奏的实践