manage-it-minibook-by-infoq

Johanna Rothman 著

郑柯 译

免费在线版本

（非印刷免费在线版）

登录China-Pub网站购买此书完整版

了解本书更多信息请登录本书的官方网站

InfoQ中文站出品

本书由InfoQ中文站免费发放，如果您从其他渠道获取本书，请注册InfoQ中文站以支持作者和出版商，并免费下载更多InfoQ企业软件开发系列图书。

本迷你书主页为

8be13794daef5ef7ba0d3c1c/cn/minibooks/manage-it

1

2

序

3

4 大家好，欢迎阅读约翰娜的新书。我在软件行业已经有数十年经验了，目前是位于伯克利的Yahoo！的一名总监。不过，也许你听过数字设备公司（DEC，为互联网早期发展奠定了基石）

和它的Alpha系统。那是我曾参与的一个意义重大的项目。

5

6 在Alpha系统的交付过程中，我扮演了非常重要的角色。那是一个名垂青史的项目：2000多

名工程师遍布世界各地，携手开发同一个系统的不同部分。这需要严谨的规划和项目管理才能成功。我们按照为期四年的时间表，在距离目标日期不到一个月的时间内交付了项目。所以，你大概也能想象得到，我觉得自己是个相当不错的项目经理！不过，我后来才知道什么是真正杰出的项目经理。7 8

1996年5月，我决定离开DEC。听说波士顿地区一家大型软件公司正在招产品团队总监，这正是我所期许的挑战，去领导一个陷入混乱的团队。我当时这么想：太棒了！这才是我想要的工作——循循诱导混乱的团队，帮助他们交付可以实际工作的产品——赶紧把我的大洋马牵过来！9 10

我听说有个咨询顾问已经先期加入，试图根据团队产品beta版本的开发状况，分清轻重缓急，

帮团队解决问题。这却更加让我坚信：不久之后，他们就会发现，我——才是他们一直在等待的

大救星。

11

12

可是，我很快就感到了羞愧和震撼（而且感觉越来越强烈）。我知道咨询师们是干什么的，

可是他们有谁能够通过实际行动、以实用的方式来厘清所面对的问题？可这位咨询师就做到了。仅两、三个月的时间，她就让一切各就各位：项目章程、工程计划、项目计划、明确的角色和职责、明确的开发流程、恰到好处的度量标准、发布条件、参与beta测试的客户……所有这些成功项目的必备要素一应俱全。13

14

15

16

要想把所有这些要素都安排妥当，怎么也得花上大半年时间，尤其是还面临启动资金不足的问题。可事实已经摆在那儿了！你可能已经猜到了，这位咨询师就是约翰娜·罗丝曼。（约翰娜在她的网站上放了一个案例研究，就是关于我们这次合作的；为了保护隐私，其中当事人的名字都使用了化名。）

II序

认识约翰娜后的几年里，我先后在大大小小的几家公司里带过软件开发团队。很多时候，我都需要约翰娜的服务，帮助我的团队整体水平再上一个台阶。她的评估流程非常严谨，而且为有效的项目管理活动打下了坚实的基础。她主持的研讨会覆盖了很多话题——给我们讲过的有迭代产生项目需求、项目管理和QA。我曾聘请她出任临时的管理职位，让她使用自己丰富的技能完成一对一的培训指导。约翰娜拥有丰富的经验，曾在很多组织中处理过各种各样的复杂情况，她也总能拿出现实可行的方案，真正解决重大问题。

所以，本书可以说是约翰娜管理才华与丰富经验的结晶。

她把自己多年一线工作积累的经验，以系统严密的方式展现给读者。本书提供了可供你分析所处的实际环境，构建项目管理框架和理性的执行计划，然后予以推进的各种工具。而大量提示和实例，则告诉你哪些路可以走，哪些路行不通，更重要的是如何避开诡秘的陷阱。对我来说，即使已经有了这么多年的项目和工程管理经验，我还是可以在书中发现新东西。当我处于陌生的境况、面临全新挑战时，当我需要一个好参谋帮我应对难题时，约翰娜是我一定要找的人。

我和约翰娜合作的第一个项目最后怎样了？啊对了，我们将产品交付给了做beta测试的客户，而它也确实可以正常工作！

我坚信，约翰娜的这本书同样可以助你一臂之力。

艾伦·R.索尔兹伯里（伯克利Yahoo!研发中心总监）

2007年4月

1

2

前 言

3 4 说到项目管理，你一定被不计其数的技巧、实践轰炸得头昏脑胀，时不时地还有各种相关建议迎面袭来。它们全都在说：“瞧我，我是最正确的。”

5 哎，它们很多都是正确的——在特定情况下。每个项目都是独一无二的，你必须要评估项目的情境（项目、团队、所在公司），然后再实事求是地作出判断，看看哪些可行，哪些不可行。

6 7 你的项目每天都在加快节奏，你的客户变得越来越不耐烦，大家越来越不能容忍无法正常工作的产品。也许你之前的做法还算不错，让你获得不少好评，可将来很可能不太奏效。你必须运用各种的方法和技巧来减少项目的风险，这其中就包括在每个项目中使用敏捷方法。

8 本书从风险角度出发帮助读者规划和指导项目。项目经理、团队成员、软件经理都能通过本书学习成功之道。即使你要构建有形的产品，比如一座房子、某种电路板，或是要管理服务类型的项目，本书中的很多内容仍然适用。

9 10 本书假设读者负责管理高科技项目，而且项目至少涉及一些软件开发。也许你像我一样，已经拥有了一些项目管理经验：包括纯粹的软件项目以及软、硬件结合的项目。我也管理过一些服务项目，比如规划和主办会议；参与过一些建筑项目（一套新房子、一次小规模的重新装修、一次大规模的重新装修）。可是我主要的项目经验都来自软件或是软、硬件结合的项目。

11 12 相对于交付实体产品的项目来说，软件项目要更加难以管理。软件很难把握，它没有形状，不需要原材料，也不是由物质构成的，所以看不见、摸不着，也没有办法直接测量。很难看到产品实实在在地在我们眼前发生演变，很难发现和预测风险，因此也就更难以应对风险。而开发软件产品的方式也并非总有助于我们了解项目进度或者把握其方向。

13 14 15 16 如果管理的是开发有形产品的项目，项目经理可以看到产品逐步成型。你可以见到房屋的框架、完工的墙体从框架到墙体，以及所有的建造过程。对于服务型的产品，比如像会议这种会产生具体结果的项目，你可以深入了解一些项目的临时交付物，比如会议报告草稿或是会议日程，等等。所以，在运作项目期间，你可以看到有形产品项目和一些服务项目的具体进度。

IV前 言

要是不能直接看到项目进度，那该怎么办呢？当你发现项目有点儿不对劲儿，而且可能濒临险境时，你该怎么办？如果此时有些项目干系人不支持你的决定，你又该怎么办？

本书可以让你深入了解你的软件项目，并让你成功管理项目的风险，无论这些风险是伴随着项目开始而存在、还是在项目进行到中间阶段时才出现。从章程制定到产品发布，每一章都讨论了一种能帮助你看清软件项目本质的方式，让你从各个方面度量它、感受它、品味它、体会它。

但在本书中，你找不到项目管理的绝对真理，因为没有在所有项目中都颠扑不破的绝对真理。你也看不到普适的最佳实践，我提出的能帮你和你的团队达成目标的实践，都有其针对的特定生命周期。

你在书中会发现有很多前后交叉引用的内容。这是因为项目是非线性系统。早先所做的决策会影响到项目如何结束，甚至可能影响到如何启动下一个项目。你管理项目的方法，也会影响你管理产品待办事项列表或项目组合的思路。

书中的所有文档模板可以在本书的主页上找到：8be13794daef5ef7ba0d3c1c/titles/jrpm。

我想感谢所有为我撰写和修改本书提供帮助的人：Tom Ayerst、Jim Bullock、Brian Burke、Piers Cawley、Shanti Chilukuri、Esther Derby、Michael F. Dwyer、Mark Druy、Jenn Greene、Payson Hall、Peter Harris、George Hawthorne、Ron Jeffries、Bil Kleb、Michael Lee、Hal Macomber、Rob McGurrin、Andrew McKinlay、Erik Petersen、Dwayne Phillips、Frederick Ros、Ellen Salisbury、George Stepanek、Andrew Wagner和Jim Ward。我的编辑Daniel Steinberg提供了非比寻常的有益反馈。Kim Wimpsett再次证明他是一个极其出色的文字编辑。我要感谢Steve Peter在排版上的神奇表现。Rotate Graphics的Mark Tatro绘制了日程游戏一章（第6章）中所有的卡通图画。与Andy Hunt 和Dave Thomas的再次合作，同样让我深感荣幸。书中任何错误都由我来负责。

书中讲述的故事全部源于真人真事，但考虑到保护隐私，相关的人名、公司名和事件细节都已做过修改。

我们开始吧。

约翰娜·罗丝曼

2007年4月

1

目 录

序...................................................................I 前言.............................................................III 第1章 启动项目 (1)

1.1定义项目和项目经理 (1)

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

浮动因素 (2)

1.3与客户或出资人讨论项目约束 (5)

1.4决定项目的关键驱动因素 (6)

1.5应对喜欢过多干预项目的出资人 (7)

1.5.1预测未来 (8)

1.5.2使用与上下文无关的问题

识别项目真正的驱动因素 (8)

1.6编写项目章程，共享现有决策 (9)

1.6.1远景 (10)

1.6.2需求 (10)

1.6.3目标 (10)

1.6.4成功标准 (11)

1.6.5ROI (11)

1.7理解质量对于项目的意义 (12)

第2章 规划项目 (14)

2.1踏上征程 (14)

2.2使项目足以启动的规划 (14)

2.3开发项目规划模板 (16)

2.3.1产品意图 (16)

2.3.2历史记录 (17)

2.3.3发布条件 (17)

2.3.4目标 (18)

2.3.5项目组织 (18)

2.3.6日程总览 (19)

2.3.7人员配备 (20)

2.3.8建议日程 (20)

2.3.9制订项目风险列表 (21)

2.4制订发布条件 (21)

2.4.1确定当前项目最重要的因素 (22)

2.4.2草拟发布条件 (23)

2.4.3让发布条件符合SMART原则 (24)

2.4.4在发布条件上达成多方共识 (25)

2.5使用发布条件 (25)

第3章 识别和避免日程安排游戏 (27)

3.1给我一块石头 (27)

3.2“希望”是我们最重要的策略 (29)

3.3拒绝女王 (31)

3.4把灰扫到地毯下面 (33)

3.5幸福日期 (34)

3.6屁股着火 (36)

3.7分散注意力 (38)

3.8日程等于承诺 (39)

3.9到了之后，我们会知道身处何方 (40)

3.10日程安排工具总是对的，又称为梦幻

时间日程 (42)

3.11我们必须拥有这个功能，否则就

完蛋了 (44)

3.12我们不能说“不” (45)

3.13日程小鸡 (47)

3.1490%完成状态 (48)

3.15我们马上会变得更快 (49)

3.16令人恍惚的日程 (50)

第4章 掌控项目 (52)

目 录

4.1掌控项目的节奏 (52)

4.2举行中途回顾 (53)

4.3为需求排序 (56)

4.4用时间盒限定需求相关的工作 (57)

4.5将迭代限制在4周或是更少的时间内 (58)

4.6使用波浪式的规划和日程安排 (59)

4.7创建跨职能团队 (62)

4.8根据项目的风险选择生命周期模型 (62)

4.9保持合理的工作时间 (63)

4.10使用“小石子” (64)

4.11管理干扰 (65)

4.11.1应对其他项目干扰 (65)

4.11.2应对其他人的干扰 (66)

4.12管理缺陷，从项目初就开始 (66)

第5章 创建并使用项目仪表板 (70)

5.1测量有风险 (70)

5.2根据项目完成度来衡量进度 (72)

5.2.1使用速度图表跟踪日程安排

进度 (72)

5.2.2使用迭代内容图跟踪总体

进度 (74)

5.2.3计算软件项目的挣值并无

实际意义 (74)

5.2.4用EQF跟踪最初的估算 (76)

5.2.5更多的度量能提供更多信息 (78)

5.2.6如果只能度量项目日程，

那就这么做 (79)

5.2.7与项目团队人员分配情况

相关的图表 (80)

5.2.8判断项目的变化率 (82)

5.2.9查看开发人员是在取得进展

还是在白费时间 (83)

5.2.10测量查找和修复问题的

成本 (84)

5.2.11了解开发人员和测试人员是否

在解决缺陷方面取得进展 (85)

5.2.12展示测试过程 (86)

5.2.13展示定性数据 (87)

5.2.14用图表展示团队同意采用的

实践 (88)

5.2.15度量敏捷项目 (90)

5.3为出资人创建项目仪表板 (90)

5.3.1展示风险列表 (90)

5.3.2展示在满足发布条件方面取

得的进展 (90)

5.4使用项目气象报告 (92)

5.4.1要小心定义气象报告的图示 (93)

5.4.2建立可信的气象报告 (95)

5.4.3每周发布气象报告 (95)

1

2

3

4

5 想从头搞砸一个项目，最简单的方式就是不动脑子，直接开始。多做一点儿组织和规划的工作，就能为项目多保留一些成功的希望。项目经理必须知道项目的关键驱动因素是什么、项目要怎么样才算“完成”，而且还得把这些结论写到章程中，让整个项目团队都能了如指掌。 要

6

7

1.1 定义项目和项目经理 8

项目到底是什么？我们首先要有一个一致的定义。 9

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

项目经理负责管理风险和资源。交付日期迫在眉睫，技术目标难以达成，产品质量漏洞百出，项目资金即将告罄，人手面临匮乏困境——没有项目管理，贯穿于项目中的这些风险如何应对？ 11

因为各自的关注点不同，每个项目都是独一无二的。项目经理要根据每个项目不同的实际情况，进行管理和规划。在启动之前，着手收集信息，了解项目要实现哪些目标。 12

我们的目标是什么？ ——克里斯，项目经理 13

我是一个大公司的项目经理，主要负责软件和硬件的集成项目。我的同事妮姬负责主办各种活动。我的团队搭建电脑系统，而妮姬的团队负责活动组织——虽然彼此的产出根本不沾边儿，可我们都是项目经理。 14

15

我们面对的风险完全不同，对外交付的东西也根本不一样。我要的是软件、硬件以及一些文档，而妮姬需要展览摊位、食品、以及其他有助于活动成功的必备之物。 16

① ? 2007 R. 麦克斯·怀德曼，8be13794daef5ef7ba0d3c1c 。经许可后转载。

2第1章 启动项目

我们的工作有一个共同之处：开始时要知道项目的目标，这样就可以马上知道我们接下来要做什么了。知道要做什么、“完成”意味着什么，这对我和妮姬的团队很有帮助。

每个项目都是独一无二的。项目团队规模不同，各自的能力也有所区别。有些项目的客户是内部的，有些则是外部的。有些项目面临很紧迫的时间压力，有些项目则可能要面对其他威胁和风险。产品是每个项目的核心，让我们再就产品的定义达成共识。

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

作为一名成功的项目经理，或者想成为成功项目经理的你，应该花些时间来发现当前项目的独特之处。这样，你就有可能成功地启动、管理和结束这个项目。

我们现在已经有了项目和产品的定义，接下来该搞清楚项目经理的职责了。怀德曼说，一个项目经理“被赋予管理项目的权力和责任，并带领项目团队，通过项目管理来达成项目的目标”。①这个正式定义还挺不错的。不妨看看下面这几句大实话，比较而言，也许它给人的感觉更加模糊，但同时也更准确。

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

其中，完成的说法是暗含风险的。我可以确定任何项目的产品一定伴随着风险，我们会在后面讨论如何对这些风险进行识别和分类。在采取任何进一步行动之前，项目经理必须理解项目的关键驱动因素是什么。

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

——埃里克，资深项目经理

我曾参与过延续数年、团队达数百人的大项目；也参与过一些小项目，我们的团队只有两三个人，客户也只有两到三个人配合，整个项目持续时间三个月。关于项目，我有一点非常确定：通往最终交付的道路上，总是有风险伴随在我们左右。

有时，风险因团队具体情况而不同。设想整理床铺这件简单的小事。对我来说，这只不过是待办事项清单上的一个条目而已。可我的孩子们却觉得，铺床就像是一个满是风险的项目，最主要的风险就是他们无法在睡觉之前把床铺好。

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

要完成一个项目，如果不能理解项目的背景，前进的路上必然充满艰险。

①? 2007 R. 麦克斯·怀德曼，8be13794daef5ef7ba0d3c1c。（经许可后转载）。

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

项目的背景是由所在组织的关键因素决定的。项目的驱动因素是什么？是否存在约束？有没

有可能在驱动因素和约束之间进行折中？项目经理能否为自己争取更多的自由运作空间？

1

2 当前项目的驱动因素与上一个不同

——斯图尔特，项目经理

3 我现在正在管理我个人的第二个项目。第一个项目的交付物是公司旗舰产品的一个补丁版本，因而很容易就能知道我们的工作重点：添加几个功能特性，并修复多个缺陷。

4 但是这第二个项目——哎，可完全不一样了。这个项目会被用作目标市场的探路石。我们需要很多新功能，这些功能还得没啥大问题。工作重点不是解决缺陷，因为交付日期马上就要

到了，得赶紧让产品投入市场。老板跟我说可以多给我几个人，但是不会有外包公司参与，因

为要控制成本。

5

6 能够识别出哪些事情在推动项目让我获益匪浅。我发现优先级最高的就是功能，其次是交付日期，接下来是人。只要能发布，公司对于缺陷和成本卡得就不是那么死了。

7 也许大家都听说过项目的“铁三角”：成本和时间是这个三角形的两条边，第三条边一般

是质量或范围（见图1-1）。其实铁三角过于简单了。斯图尔特的两个项目的驱动因素就存在很

大差异。

8

9

10

成本 质量 成本 范围

11

12

时间 时间

13

图1-1传统的铁三角

像斯图尔特这样成功的项目经理会权衡许多因素，而不仅限于铁三角。以为只要让客户从铁

三角中选择他最看重的两条边，然后就可以交付他想要的结果，这根本是痴人说梦。要是这么简

单的话，那任何人都能当项目经理了。

14

15

首先，要写下客户的期望——从客户的角度来看，项目的驱动因素是什么。这个列表中应该

包括：客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何

（缺陷等级）。

16

4第1章 启动项目

接下来，写下项目的约束。环境是什么样子的？能否灵活安排团队的位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般只有项目出问题的时候才能改变）。约束决定了项目的规模（还有持续时间和质量）。

对比客户的期望列表和项目的约束列表。你脑海里蹦出来的项目成功的必要因素有哪些？选择其一，比如发布时间，这就是识别出来的项目的关键驱动因素。

列表上还剩下什么？应该还能看到功能集合、低缺陷率、发布成本等条目。在这些条目里，需要对哪些进行管理才能保证项目的成功？可以按重要性排列这些关注点。客户和出资人会在这些方面上对项目形成限制。从中选择两到三项，我们称之为项目的约束。

再看看剩下的条目。有些条目很重要，不过它们有很大的调整余地，我们称之为浮动因素。一个项目至少要有三个浮动因素。

最后看看还没选择的条目，是不是还有哪个比已经选择的更重要呢？如果有，那就再调整一下；如果没有，这个项目的关键驱动因素、约束、浮动因素就都识别出来了。

我曾经见过有三个约束的项目，团队必须付出超乎寻常的努力，才能保证项目成功。以我的经验，如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理。

理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。大部分情况下，我们管理的都是不那么理想化的项目，所以如果项目有一个关键驱动因素、两个约束、三个浮动因素，这也是可以成功的。过多的关键驱动因素或约束，会让项目过于受限。这种情况下也许能够成功，但是项目经理和团队就得选择促成项目成功的组织形式和实践——不过还是要有点心理准备，因为可能无法获得百分之百的成功。

如果存在过多的关键驱动因素和约束，而且项目经理除了启动项目之外别无选择，这时所能做的就是选定一个关键驱动因素，并尽可能频繁地向出资人提交项目的产出，帮助他们决定自己真正想要的东西。在启动项目的时候，为了得到项目的成功条件，可以问一些与上下文无关的问题。还要定义出发布条件，这样就知道到什么程度算做完了。

提示：要是约束太多了，你就自己作决定吧

受到过多限制的项目难以逃避失败的厄运。过多的关键驱动因素，意味着没有人知道成功的条件是什么。过多的约束，意味着组织中没人愿意去判断孰轻孰重。

有必要的话，让管理层决定项目的关键驱动因素、约束和浮动因素。如果这不可行，那项目经理就自己作决定吧；项目和组织会因此而受益。

1.3与客户或出资人讨论项目约束 5

想创建出不受约束限制的项目需求是不现实的。假设有一个可以承重5斤的书包，如果你硬要往里面塞10斤的书，不外乎两种结果：要么书包带断掉，要么书包底破掉。管理项目也是如此，要根据约束来管理需求。要想同时应付过多的需求，那不管用什么办法，人手、时间、预算还有工具这些资源可能就是不够用，发布出的产品也很难具备高层想要的全部功能，同时可能有很多缺陷。1 2 3

1.3与客户或出资人讨论项目约束

4

要主动理解出资人想要的东西。下面这段谈话就是我在最近的项目中与出资人的对话。

5 JR：哎，克莱德。咱们看看到底是什么在驱动这个项目吧。

6 克莱德：可别！别再整我了。上个项目的时候，你就让我做过一次了啊。

JR：没错。还记得吗？你当时想添加新功能。你希望在产品发布之前塞进去尽可能多的功

能，我可以加，因为当时组织项目的方式还允许。那确实挺不好弄的，不过还是有可能做到。

7 克莱德：啊，对，我忘了。不过这个项目不一样啊。8 JR：哦？跟我说说。

9 克莱德：你瞧，管人是你的事情，项目的运作情况你也得管。不过你不需要资金，我也不担

心成本问题，因为唯一的成本就是工资。

10

JR：还有软件呢。

11

克莱德：你还真挑啊。好吧，如果需要什么软件，跟我说。不过老实讲，基本上工资就是这

次的全部成本——我也不用管，我最关心的是项目要多久才能完成。

12

JR：那需要哪些功能呢？对它们的质量有什么要求？这是给财务部门用的一个小程序，你

也知道他们总是要求完美。要是我不能保证给他们的东西毫无问题，莱斯丽会跟上面吹风的。

13

克莱德：没错，不过我会帮你扛着的。我就是希望给他们够用的功能就行了，这样你跟你的

团队就能很快搞定，比如在十周之内。

14

JR：如果到了第八周，我们还没有开发完所有的功能，而且还有很多bug要改。你会怎么想？

15

克莱德：JR，别啊。我需要全部的功能。你们开发团队曾经完成过类似的工作，我相信这次

也一定行。

16

JR：克莱德，如果我能理解你到底想要什么，你知道，我们开发团队会尽力而为的。

6第1章 启动项目

克莱德：好吧。千万不能有不完整的功能。你尽管开始，把它做完，而且要让莱斯丽喜欢它。否则，她非把我头砍下来不可。文斯已经启动了一个大型的项目计划，过段时间，我想让你们开发团队加入到那边去。他说已经准备好在十个星期后接收更多的人了。这样，你也有足够的时间来给莱斯丽一点儿用得上的东西。

1.4决定项目的关键驱动因素

在与克莱德的对话中，我让他说明他最看重的是什么。克莱德说一个大型计划会在十个星期之后启动，很明显，日期就是这个项目的关键驱动因素。

在项目早期，似乎一切皆有可能，特别是没有估算任何工作的时候。出资人可能会说：“我们想要这5个功能，在8月1日之前完成，还不能有严重的问题。我们还想让你把成本控制在一百万美元之下。给你这6个人。OK？”

可别轻易说OK。

估算了工作量之后，就能知道用这么多钱、这么长时间，这6个人能不能做完项目。要是可以，蛮好。不过很可能没有办法按照出资人对时间、金钱、人力的要求，在规定的工作环境中，提供符合他们质量要求的产品。此时，出资人需要做出艰难的决策，要考虑组织中的项目驱动因素，比如发布日期、功能集合、成本、人员分配及其分配时间、将要采用的技术和实践，等等。

要是出资人不愿意判断项目的驱动因素是什么，这个责任就落到项目经理肩上了。如果项目经理不做决定，团队自己会决定。但是他们会各拿各的主意，而且这些主意也不一定会符合出资人的想法。实际上，每个人——不管他或她在项目中的角色是什么——都会根据自己的想法进行判断。有的人会优先考虑发布日期的限制，从而把减少缺陷的想法抛在脑后。有的人会根据日程安排，仅仅实现一个功能——一个包含完整回归测试套件的功能，其余的功能却都没做完。有的人会优先考虑实现功能集合，开发出尽可能多的程序桩（stub），当测试人员发现问题时再去填充，直到时间用完为止。每个人都会做自己认为正确的事，而不是从出资人（或项目经理）的角度出发，因此做出的决策彼此不同。

通过制定优先级列表可以解决这个问题，其过程跟做数独游戏有些类似，即将所有可能的驱动因素列在左边，右边空出来等着填数字。

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

下面是克莱德的排序矩阵。

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

项目驱动因素排序 1 发布成本 5

发布日期 1

2 功能集合 2

减少缺陷 3

3 人员配备 4

工作环境 6

4 在这个项目中，发布日期是最主要的驱动因素。如果产品今年不能发布，这个项目就没有

什么存在的意义了。但是完备的功能也很重要——功能不齐全，即使及时发布，整个项目也没有价值。而且，由于公司业务属于受政府管制的行业，产品的缺陷率必须很低。接下来是人员配备，因为只要这些人能在十个星期之后参与下个项目计划就可以了。项目的成本控制不太重要，因为项目的价值会很高。工作环境排在最后，为了保证及时交付，我可以灵活调整某些事情。5 6 7

即使已经有了排好顺序的优先级，我们还是没有多少灵活性。不过了解了项目的关键驱动因

素，我就可以定义出项目的成功条件，并选择适合项目的生命周期了。项目团队可以制定出发布条件，并根据驱动因素合理地安排各自的工作。嗯，最后，我们按照当初的要求，成功地交付了项目。8 9

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

10

在绝大多数情况下，关于成功标准的谈话不会进行得那么顺利。读者也可以看到，我必须促

使克莱德做出选择。类似情况很常见。11

有些项目对于功能集合、减少缺陷、时间安排这三者的要求都是最高的，而且优先级相同。我敢说，读者一定以项目经理或团队成员的身份参与过类似项目。你不能再给团队添加更多人手了，而且项目的预算不可改变。项目流程必须按照公司的强制要求执行，还得使用公司规定的办公室和家具，其他一些工作环境问题也让项目难以推进。除非没有技术或时间上的风险，否则没人能够使这样的项目取得成功。不过还是有一些方法，能够理清这些看来已经没有活动余地的约束条件。12

13

14

在1.4节中可以看到项目的驱动因素矩阵。如果出资人愿意排定优先级，那这种方式再好不过了。有些勉强的出资人可能因此而变得更加坚定。项目经理有时要先草拟一个优先级列表，拿给出资人看。比如，几个出资人对于优先级的排序可能无法达成一致意见。要是出资人不愿意拿主意，项目经理就只好自己做决定，然后再给出资人看。她可能会愿意去修正列表，或者直接签15

16

8第1章 启动项目

名通过这个列表，自己就不再建新的了。

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

1.5.1预测未来

让出资人设想这样的情况：现在离项目预定交付时间只剩三个星期，却还有功能尚未实现。（可以着重讨论该出资人需要的一两个功能。）除了没做完的功能之外，还有很多严重的缺陷等着修复。这样看来，要想在预定的发布日期之前开发完所有的功能并修复所有的缺陷，很明显是不可能了。这个时候，出资人该怎么办？

如果出资人这么说：“把你的脑袋砍下来给我吧。”那就该考虑“三十六计走为上”了。请看7.7节。

不过出资人很可能会这样说：“把这个该死的项目做完吧。你还需要几个人？”接着，你可以问他：“是先做完所有的功能，还是先修复所有的缺陷？”他一般会说：“这两个功能和这些问题都得解决掉。”再问他：“以项目目前的优先级顺序，是吗？”项目经理要经常帮助出资人搞清楚：哪些约束是真正的约束，哪些是出资人自己一厢情愿的想法。

在对话中使用与上下文无关的问题，有助于识别出项目的驱动因素、约束以及活动余地。1.5.2使用与上下文无关的问题识别项目真正的驱动因素

明确了驱动因素之后，项目经理就可以发掘项目的需求了。与上下文无关的问题有助于抽取出这些需求。通过这些比较抽象的问题，可以诱导其他人说出他们对于项目的假设。不妨从下面这些问题开始。

?项目要怎么样才算成功？

?为什么想得到这样的结果？

?这种解决方案对你来说价值何在？

?这个系统要解决什么样的问题？

?这个系统可能会造成什么样的问题？

要注意，少用“为什么”之类的问题。“为什么”问得越少，对于业务需要反而能了解得越多（而且问问题的人也不会像个令人厌烦的三岁小孩子。）同时，“为什么”这类问题很容易让对方产生戒心。也得注意避免“怎么做”之类的问题，出资人会觉得你在让他们设计系统。

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

在问问题时，要让人感觉到你真心希望了解这个项目，而不要让别人抱有戒心。这些问题可

以为项目经理和出资人将来的合作打下良好的基础，而不是形成龃龉的关系。

1

2 这些问题可以找出系统的价值所在。在向出资人提问时，要营造平等的气氛。在纸上做笔记，

而不是用电脑，这样你和出资人之间就不存在障碍了。将这些问题作为谈话的开端。在刚开始时，

从出资人处收集到的关于项目价值的信息越多，你就能更深入地了解如何设计这个项目。 3

项目要怎么样才算成功？

4 ——贾斯汀，项目经理

几个月前，我开始管理这个会持续两三年的项目。这两天，老板跑过来跟我说他想加入一个新的功能。一个我在说：“酷啊，这个新功能一定会很棒的！”而另一个我说：“噢不，我们介入这个项目已经两个月了。要是我给老板留下可以随意加入新功能的印象，如果不调整我们团队的工作方式，那我一定会有麻烦的。”于是，我问老板这个问题：“对你来说，项目要怎么样才算成功？”5 6 7

使我大吃一惊的是，老板认为这个项目要能完全随需应变才算成功。他十分确定：不到最后一刻，需求不会停止变化——也许要到我们发布前一周才能最后明确。我以前可从来没有管

理过类似的项目！不过既然现在知道了，我就能着手筹划应对之策了。8

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

10

项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。整个

团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。

11

在启动项目时，编写项目章程可以让大家知道应该完成什么目标，以及项目干系人提出的约

束条件。即使不知道完成项目需要的细枝末节，编写章程也有助于发现潜在的问题。项目章程可

以帮助项目经理和团队理解风险、成功标准，而大家也可以藉此考虑组织和操控项目的方式。

12

13

如果你在管理一个敏捷项目（使用敏捷生命周期的项目，请查看附录A.4节），项目章程会很

简短，只要包括项目远景（参与项目的人可以做出正确的决策）和发布日期（这样就不会为了给

产品“镀金”而错过项目的结束时间）就够了。14

下面是我的项目章程模板。

15

?远景

?需求16 ?目标

10第1章 启动项目

?成功标准

?ROI估算

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

1.6.1远景

每个项目背后总有一个缘由（或者两个、三个）。发起这个项目的缘由何在？项目的价值何在？要用描述远景的句子来说明项目的价值。越早向大家阐明项目的价值，团队就越有可能告诉你接手这个项目是否明智。也许他们会告诉你，囿于目前的约束、资源和他们的能力，这个项目就不可能完成。要是不能明确阐明项目的远景何在，很可能这个项目就是“不可能完成的任务”了（因为没有远景的项目无法结束）。实用的项目远景对团队来说不可或缺。

1.6.2需求

某些情况下，项目唯一的需求就是要在某个特定日期到达之时发布某些功能。更多时候，需求掺杂在下面这样的语句之中：“2月20日发布的主要版本中，我们需要这个又棒又炫的功能。”这些才是项目的驱动因素，产品功能列表不是。

1.6.3目标

项目目标是希望通过项目要达成的目的，不过客户跟出资人可能并不赞同这些目标。（想了解更多关于目标的讨论，请查看2.3节）。

目标与需求不同。项目并不一定必须交付它的目标。遵循传统的阶段-关卡（phase-gate）式开发过程或瀑布式开发过程的项目，它的产品里面会有比较严重的技术债务（technical debt，请查看原书附录B）。通过重新设计解决技术债务、添加更多的自动化测试、设计冒烟测试等等，这些都是可能的项目目标。

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

客户有时会提出一些特定的要求：“如果目前的时间安排允许，并且不麻烦的话，我想要一个电子签名。”作为一个注重实效的项目经理，你可以说：“OK，我们会把它加到项目目标里面去。要是雪丽和简有时间的话，她们会去做的。”1 2

1.6.4成功标准

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

关注能力。 4

下面是一些成功标准实例。

5 ?要包括功能1、2、3，这样我们的产品就可以打入目标市场了。

?要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，并编写新的市场营销材料了。

6

?客户不需要访问我们的网站，就可以打开安装包、加载软件。

7 ?在第一季度发布。

8

在你意识到之前，项目就已经开始了

项目通常在正式开工之前就已经启动了。也许有人已经开始了原型化的工作；也许有人已

经预想了一些功能；也许管理层已经跟首席架构师探讨了项目在技术上的可行性。这些都是项

目的组成部分，即使你不这么认为。

9

10

由于项目在你思考之前就已经开始了，所以大可不必因项目章程、项目规划和项目日程的

反复修改而烦恼。作为一个注重实效的项目经理，在项目前期，虽然有些工作已经开始了，你

还是应该张开双臂拥抱项目，接受眼前的一切。在项目中期，你应该不断评估项目进程和风险，

从而掌控整个项目。项目收尾阶段，如果你是注重实效的，那就没什么好担心的了。

11

12

团队要控制成功标准。项目经理要确保成功标准中不会包含非项目人员才能完成的任务（比

如“卖出50 000套软件”）。项目经理和团队不能控制别人做什么，只能控制自己和团队的行动。

要确保成功标准在项目经理的掌控之中。

13

14 1.6.5ROI

我接触过的客户中，很少有人会去度量ROI（即投资回报率）。毕竟，要操纵数字太容易了。不过，如果管理层要求的话，项目经理可以估算项目的回报，试着计算ROI。在项目完成后，可以看看是否达到了当初预计的数字。15

16

12 第1章 启 动 项 目

1.7 理解质量对于项目的意义

要想理解质量对于出资人和客户的意义，必须先要理解项目的关键驱动因素、约束和浮动因素。出资人是为项目提供资金的人，客户是使用产品的人，他们不一定是同一群人——对质量的定义可能有差别。没错，这让项目经理的工作更不好做了。不过，知道了对于项目来说“质量”意味着什么，也就部分理解了“完成”的含义。

温伯格这样说：“质量，就是对于某人的价值。”这个定义也就意味着可以为项目产品添加新功能，并可查看一个功能吸引（或排斥）了多少个（以及什么样的）“某人”。在想到出资人和客户的时候，不妨考虑一下他们希望从项目中得到什么。这样一来，项目经理便可以根据实际情况调整发布时间、项目预算和人员配备；同时，项目经理也可以权衡：是否所有的“某人”都需要某个功能。如果项目经理和团队知道“某人”对于质量的定义，大家就可以朝着这个方向来努力；即使他们改变了主意，团队仍然可以取得成功。

根据项目产品所处的不同市场应用阶段，如图1-2所示，客户对于质量的定义也有所差别。

客户群大小

末期市场

鸿沟

大众市场 初期市场 技术狂热者 梦想者 实用主义者

盲从者 怀疑论者 时间 图1-2 摩尔的鸿沟

当产品处于市场应用的早期阶段时，顾客群的规模不大；但是技术狂热者们已经想先睹为快了，所以会面临比较大的发布压力。此时产品不必具有很多功能，而且也不必有很高的稳定性，但是它必须具备自己的独特之处，来吸引更多客户。

在产品进入市场的初期，无论客户群大小，人们都会有各自不同的需求。所有客户都希望马上得到新版本，而且要具备他们自己想要的功能。此时的产品用起来不能太费事，不过由于只有你的产品能够解决客户的问题，所以即使有点儿缺陷，它的销路还是会很不错。

本文来源：https://www.bwwdw.com/article/mr1e.html