新書推薦：
《
高性能储能器件电解质：设计、制备与应用
》
售價：NT$
493.0
《
四时如意 国风纹样线描涂色集
》
售價：NT$
279.0
《
活下去才是硬道理：华为的36条生存法则
》
售價：NT$
437.0
《
森林：保护6万种树木的家
》
售價：NT$
403.0
《
数字经济：“数字中国”顶层规划与实践路径
》
售價：NT$
386.0
《
算者生存：商业分析的方法与实践
》
售價：NT$
447.0
《
共享现实：是什么让我们成为人类
》
售價：NT$
717.0
《
女佣异闻：乙一出道25周年纪念短篇集
》
售價：NT$
279.0
|
| 編輯推薦： |
写给项目经理们的《孙子兵法》
第18届Jolt生产效率大奖图书
|
| 內容簡介： |
项目管理对于项目成败至关重要，项目经理往往面临着巨大的压力和挑战：虽然已经有很多项目管理理论和方法，但实践中每个项目都有自己的独特性，没有现成的解决方案可以套用。
怎么办？这部荣获软件业奥斯卡——Jolt奖的著作给出了很好的解答。作者多年来帮助许多高科技公司成功地解决了各种有关产品开发管理的棘手问题，本书正是她宝贵实战经验的提炼。书中从应对实际风险的角度出发，讲述了从项目启动、项目规划到项目结束的整个管理流程；展示了作者的思考过程，从评估项目背景，选择生命周期，直到为项目建立清晰的条件；同时穿插了丰富的提示和真实案例，介绍了可能遇到的常见问题。这些真知灼见不仅适用于软件项目管理，同样适用于其他产品的开发项目。
这是一本可使项目经理即刻上手的名副其实的实战指南。任何类型的项目经理，无论你是使用瀑布式、迭代式、还是敏捷式生命周期模型，运用书中总结的精髓和理论，都能在应对大小项目时攻无不克战无不胜。
|
| 關於作者： |
Johanna Rothman
世界知名的管理顾问，擅长高科技产品开发管理，经验丰富。1994年创办Rothman咨询公司。她也是活跃的技术作家，长期担任Fast Company和Software Development等业界著名杂志以及Computerworld.com和StickyMinds.com等一流在线媒体的专栏作者。除本书曾获大奖之外，她还与人合著有《门后的秘密：卓越管理的故事》，也广受好评。她的博客地址http:www.jrothman.comblogs.html。图灵社区曾对她做过访谈：http:www.ituring.com.cnarticle1788。
译者简介：
郑柯
从事 IT 行业十余年，历任程序员、项目经理、市场、销售，曾混迹于《程序员》、InfoQ 等技术媒体。现自由职业，以艺术普及为毕生志业，独立创办、运营“一天一件艺术品”豆瓣小站以及微信公众订阅号。
|
| 目錄：
|
第1章 启动项目1
1.1 定义项目和项目经理1
1.2 管理项目的关键驱动因素、约束和浮动因素3
1.3 与客户或出资人讨论项目约束5
1.4 决定项目的关键驱动因素7
1.5 应对喜欢过多干预项目的出资人8
1.5.1 预测未来9
1.5.2 使用与上下文无关的问题识别项目真正的驱动因素9
1.6 编写项目章程，共享现有决策10
1.6.1 远景11
1.6.2 需求11
1.6.3 目标11
1.6.4 成功标准12
1.6.5 ROI13
1.7 理解质量对于项目的意义13
第2章 规划项目16
2.1 踏上征程16
2.2 使项目足以启动的规划16
2.3 开发项目规划模板18
2.3.1 产品意图18
2.3.2 历史记录19
2.3.3 发布条件20
2.3.4 目标20
2.3.5 项目组织20
2.3.6 日程总览21
2.3.7 人员配备22
2.3.8 建议日程23
2.3.9 制订项目风险列表23
2.4 制订发布条件24
2.4.1 确定当前项目最重要的因素25
2.4.2 草拟发布条件26
2.4.3 让发布条件符合SMART原则27
2.4.4 在发布条件上达成多方共识28
2.5 使用发布条件28
第3章 使用生命周期组织项目31
3.1 理解项目生命周期31
3.2 生命周期概览32
3.3 在项目中寻求反馈36
3.4 大规模项目需要组合使用多种生命周期37
3.5 管理架构风险40
3.6 从瀑布中摆脱出来41
3.7 我最钟爱的生命周期42
第4章 安排项目日程43
4.1 注重实效的项目日程安排43
4.2 可供选择的项目日程安排技术45
4.2.1 自顶向下式日程安排45
4.2.2 自底向上式日程安排45
4.2.3 由内及外式日程安排45
4.2.4 哈德逊湾式启动46
4.2.5 短期迭代47
4.3 用低技术含量工具安排项目日程47
4.3.1 使用便利贴安排项目日程的基本技术49
4.3.2 使用便利贴和箭头安排项目日程51
4.3.3 为每一个职能组使用便利贴安排项目日程51
4.3.4 按功能使用便利贴安排项目日程51
4.3.5 使用便利贴安排项目日程的好处52
4.3.6 基于可交付物的规划52
第5章 估算工作54
5.1 实用的项目估算方式54
5.1.1 对比历史数据进行估算54
5.1.2 通过Delphi和宽带Delphi方式进行估算54
5.1.3 何时不应相信团队的估算55
5.1.4 小心顺序式生命周期的估算陷阱56
5.1.5 使用自信心范围进行估算57
5.1.6 使用日期范围进行估算59
5.1.7 使用三个日期：最佳状况、最有可能、“墨菲”日期60
5.1.8 在估算时分开考虑任务的大小与持续时间61
5.1.9 规划扑克62
5.1.10 在估算前用试探性开发收集数据63
5.1.11 让估算更容易的提示63
5.2 用里程碑切分项目64
5.3 你们能够不做哪些事情66
5.4 身背多个项目时的估算66
5.5 主动安排人们进行多任务67
5.6 使用波浪式规划68
5.7 决定迭代的持续时间69
5.8 尽可能使用“小石子”进行估算70
5.8.1 当任务不清楚时创建并使用“小石子”71
5.8.2 如何得到“小石子”71
5.8.3 为什么使用“小石子”72
第6章 识别和避免日程安排游戏73
6.1 给我一块石头73
6.2 “希望”是我们最重要的策略75
6.3 拒绝女王77
6.4 把灰扫到地毯下面79
6.5 幸福日期80
6.6 屁股着火82
6.7 分散注意力84
6.8 日程等于承诺85
6.9 到了之后，我们会知道身处何方86
6.10 日程安排工具总是对的，又称为梦幻时间日程88
6.11 我们必须拥有这个功能，否则就完蛋了90
6.12 我们不能说“不”91
6.13 日程小鸡93
6.14 90%完成状态94
6.15 我们马上会变得更快95
6.16 令人恍惚的日程96
第7章 创建出色的项目团队99
7.1 招募需要的人99
7.2 形成团队凝聚力101
7.2.1 好工具让团队有好的发挥102
7.2.2 软件配置管理系统应满足的最低要求102
7.2.3 缺陷跟踪系统应满足的最低要求102
7.2.4 团队发展的5个阶段103
7.3 让组织配合你的工作103
7.3.1 以项目经理的方式管理单一职能团队104
7.3.2 管理矩阵式项目团队105
7.3.3 管理跨职能项目团队105
7.4 对必需的团队规模了如指掌105
7.5 知道何时应该加人107
7.6 成为出色的项目经理107
7.6.1 提升人际交往技能108
7.6.2 提升功能性技能108
7.6.3 提升专业领域技能109
7.6.4 提升工具和技术的专业技能110
7.7 知道何时该全身而退111
7.7.1 什么样的组织不适合你111
7.7.2 什么样的团队不适合你115
7.7.3 什么样的产品不适合你115
第8章 掌控项目117
8.1 掌控项目的节奏117
8.2 举行中途回顾118
8.3 为需求排序119
8.4 用时间盒限定需求相关的工作122
8.5 将迭代限制在4周或是更少的时间内124
8.6 使用波浪式规划和日程安排125
8.7 创建跨职能团队127
8.8 根据项目的风险选择生命周期模型128
8.9 保持合理的工作时间129
8.10 使用“小石子”130
8.11 管理干扰131
8.11.1 应对其他项目干扰131
8.11.2 应对其他人的干扰132
8.12 管理缺陷，从项目初就开始132
第9章 保持项目节奏137
9.1 在项目中使用持续集成137
9.2 为构建创建自动化冒烟测试138
9.3 按功能实现，而不是按架构140
9.3.1首先实现具有最高价值的功能142
9.3.2 按功能调试142
9.3.3 按功能测试142
9.4 多几只眼睛盯着产品143
9.5 准备重构145
9.6 通过用例、用户故事、角色和场景来定义需求146
9.7 分离需求与GUI设计147
9.8 尽可能使用低保真度原型148
第10章 管理会议150
10.1 取消这些会议150
10.1.1 避免不需要你解决问题的会议151
10.1.2 绝对不要举行多人参加的顺序式进度报告会议151
10.1.3 避免这些会议152
10.2 举行下列会议153
10.3 项目启动会议153
10.4 发布版本规划会议153
10.5 进度报告会议154
10.5.1 每日站立会议155
10.5.2 一对一会议156
10.5.3 通过可见的方式了解进度157
10.5.4 通过电子邮件，从团队成员那里获取每周进度报告157
10.5.5 每周向团队报告进度158
10.6 向管理层报告进度158
10.7 项目团队会议159
10.8 迭代审查会议160
10.9 会议疑难问题解答160
10.10 管理与远程团队的电话会议162
10.10.1 通用引导指南163
10.10.2 准备工作163
10.10.3 进行事先规划164
10.10.4 引导会议164
10.10.5 电话会议后的工作165
第11章 创建并使用项目仪表板166
11.1 测量有风险166
11.2 根据项目完成度来衡量进度168
11.2.1 使用速度图表跟踪日程安排进度169
11.2.2 使用迭代内容图跟踪总体进度170
11.2.3 计算软件项目的挣值并无实际意义171
11.2.4 用EQF跟踪最初的估算173
11.2.5 更多度量能提供更多信息175
11.2.6 如果只能度量项目日程，那就这么做175
11.2.7 与项目团队人员分配情况相关的图表177
11.2.8 判断项目的变化率178
11.2.9 查看开发人员是在取得进展还是在白费时间179
11.2.10 测量查找和修复问题的成本181
11.2.11 了解开发人员和测试人员是否在解决缺陷方面取得进展182
11.2.12 展示测试进度183
11.2.13 展示定性数据184
11.2.14 用图表展示团队同意采用的实践185
11.2.15 度量敏捷项目187
11.3 为出资人创建项目仪表板187
11.3.1 展示风险列表187
11.3.2 展示在满足发布条件方面取得的进展188
11.4 使用项目气象报告189
11.4.1 要小心定义气象报告的图示190
11.4.2 建立可信的气象报告192
11.4.3 每周发布气象报告193
第12章 管理多地点项目194
12.1 提一个问题的成本是多少194
12.2 识别项目的文化差异195
12.3 在团队间培养信任196
12.3.1 确保每个地点都有完整的项目可交付物196
12.3.2 确保各个团队可以互相协作198
12.3.3 让人们建立个人接触198
12.4 在团队间使用互补实践199
12.4.1 使用互补生命周期200
12.4.2 详细说明每个团队的里程碑和交接物200
12.5 寻找潜在的多地点项目和不同文化导致的问题206
12.6 在外包时要避免下列错误207
第13章 在项目中集成测试209
13.1 从一开始，就让人们将“减少技术债务”牢记心间209
13.2 使用小规模测试降低风险210
13.3 TDD是在项目中集成测试最简便的方式211
13.4 使用多种测试技巧214
13.5 确定每个团队成员在测试工作中的角色216
13.6 正确的开发人员与测试人员之比应该是多少220
13.6.1 产品风险对比率的影响220
13.6.2 项目和流程风险对比率的影响221
13.6.3 人员及其能力对比率的影响222
13.7 让测试与开发同步进行224
13.8 为项目制定测试策略224
13.9 系统测试策略模板225
13.10 QA与测试有差别227
第14章 管理项目群229
14.1 如果你要管理项目群229
14.2 将多个相关项目组织到一个发布版本中230
14.3 随时间推移组织多个相关项目232
14.3.1 将产品的多个版本组织到发布列车中232
14.3.2 让发布列车为你服务233
14.3.3 在不使用发布列车的情况下，将多个版本组织到一个产品中234
14.4 管理项目经理234
14.5 创建项目群仪表板236
14.5.1 度量互相依赖的项目236
14.5.2 度量一系列项目237
第15章 结束项目238
15.1 管理发布早期版本的请求238
15.2 管理beta版本239
15.3 项目经理何时知道无法按时发布项目240
15.3.1 “避免小的偏差”240
15.3.2 承诺一个新日期241
15.3.3 估算系统测试时间243
15.3.4 在时间不够的情况下管理系统测试245
15.4 指导项目走向完成246
15.4.1 管理“结束游戏”247
15.4.2 避免“缺陷提升和降级的游戏”247
15.4.3 准备项目回顾248
15.4.4 准备庆祝249
15.5 取消项目251
第16章 管理项目组合253
16.1 构建所有项目的组合253
16.2 评估项目254
16.2.1 定性评估项目254
16.2.2 定量评估项目255
16.3 决定现在为哪个项目提供资金255
16.4 对组合中的项目进行排序256
16.5 尽快启动项目256
16.6 使用产品待办事项列表管理新功能需求258
16.6.1 构建产品待办事项列表258
16.6.2 管理待办事项列表260
16.7 组合管理答疑260
16.7.1 管理从事多个项目多个任务的情况260
16.7.2 说服管理层：“切换上下文”是个坏主意261
16.7.3 如何对多任务说“不”263
附录A 关于项目生命周期的更多详细信息266
附录B 术语汇总276
附录C 参考书目278
|
| 內容試閱：
|
第1章
启动项目
要
想从头搞砸一个项目，最简单的方式就是不动脑子，直接开始。还想让保留一点儿成功的希望？那就多做一点儿组织和规划。项目经理必须知道：什么是项目的关键驱动因素，项目要怎样才算“完成”，而且还得把这些结论写到章程中，让整个项目团队都能了如指掌。
1.1 定义项目和项目经理
项目到底是什么？我们首先要有一个一致的定义。
项目：一个独特的任务或是系统化的流程，其目的是创建新的产品或服务，完成交付产品和服务，标志着项目的结束。项目都有风险，并且受制于有限的资源。
项目经理负责管理风险和资源。交付日期迫在眉睫，技术目标难以达成，产品质量漏洞百出，项目资金即将告罄，人手面临匮乏困境——没有项目管理，贯穿于项目中的这些风险如何应对？
因为各自的关注点不同，每个项目都是独一无二的。项目经理要根据每个项目不同的实际情况，进行管理和规划。在启动之前，可以从着手收集信息开始，了解项目要实现哪些目标。
我们的目标是什么？
——克里斯，项目经理
我是一个大公司的项目经理，负责软件和硬件集成项目。我的同事妮姬负责主办各种活动。我的团队开发电脑系统，妮姬的团队负责组织活动——虽然彼此的产出根本不沾边儿，可我们都是项目经理。
我们面对的风险完全不同，对外交付的东西也根本不一样。我要的是软件、硬件以及相关文档，而妮姬需要展览摊位、食品，以及其他成功举办活动需要的东西。
我们的工作有一个共同之处：开始时要知道项目的目标，这样就可以马上知道我们接下来要做什么了。知道要做什么、“完成”意味着什么，这对我和妮姬的团队很有帮助。
每个项目都是独一无二的。项目团队规模不同，各自的能力也有所区别。有些项目的客户是内部的，有些则是外部的。有些项目面临很紧迫的时间压力，有些项目则可能要面对完全不同的威胁和风险。产品是每个项目的核心，让我们再就产品的定义达成共识。
产品：项目产生的一系列可交付物。
作为一名成功的项目经理，或者想成为成功项目经理的你，应该花些时间来发现当前项目的独特之处。这样，你就有机会成功启动、管理和结束这个项目。
我们现在已经有了项目和产品的定义，接下来该搞清楚项目经理的职责了。怀德曼说，一个项目经理“被赋予管理项目的权力和责任，并带领项目团队，通过项目管理来达成项目的目标”。 这个正式定义还挺不错的。不妨看看下面这几句大实话，比较而言，也许它给人的感觉更加模糊，但同时也更准确。
项目经理：负责向团队清晰说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。
其中，完成的说法是暗含风险的。我可以确定：任何项目产品一定伴随着风险，我们会在后面讨论如何对这些风险进行识别和分类。在进一步行动之前，项目经理必须明确项目的关键驱动因素。
无论规模大小——是项目就有风险
——埃里克，资深项目经理
我曾参与过延续数年、团队达数百人的大项目；也参与过一些小项目，我们的团队只有两三个人，客户也只有两到三个人配合，整个项目持续时间三个月。关于项目，我有一点非常确定：通往最终交付的道路上，总是有风险伴随在我们左右。
有时，风险因团队具体情况而不同。设想整理床铺这件简单的小事。对我来说，这只不过是待办事项清单上的一个条目。可我的孩子们却觉得，铺床就是一个满是风险的项目，最主要的风险，就是他们无法在睡觉之前把床铺好。
1.2 管理项目的关键驱动因素、约束和浮动因素
要完成一个项目，如果不能理解项目的背景，前进的路上必然充满艰险。
项目的背景由所在组织的关键因素决定。项目的驱动因素是什么？是否存在约束？有没有可能在驱动因素和约束之间进行折中？项目经理能否为自己争取更多的自由运作空间？
当前项目的驱动因素与上一个不同
——斯图尔特，项目经理
我现在正在管理我的第二个项目。第一个项目的交付物，是公司旗舰产品的一个补丁版本，因而很容易就能知道我们的工作重点：添加几个功能特性，并修复多个缺陷。
但是这第二个项目——哎，可完全不一样了。这个项目会被用作目标市场的探路石。我们需要很多新功能，这些功能还得没啥大问题。但工作重点不是解决缺陷，因为交付日期马上就要到了，得赶紧让产品投入市场。老板跟我说可以多给我几个人，但是不会有外包公司参与，因为要控制成本。
能看出是哪些因素在推动项目，这让我获益匪浅。优先级最高的就是功能集，其次是交付日期，接下来是人。只要能发布，公司对于缺陷和成本卡得就不那么死了。
也许大家都听说过项目的“铁三角”：成本和时间是这个三角形的两条边，第三条边一般是质量或范围（见图1-1）。其实铁三角过于简单了。看看斯图尔特的两个项目，其驱动因素跟铁三角就存在很大差异。
图1-1 传统的铁三角
像斯图尔特这样成功的项目经理会权衡许多因素，而不仅限于铁三角。以为只要让客户从铁三角中选择他最看重的两条边，然后就可以交付他想要的结果，这根本是痴人说梦。要是这么简单的话，那任何人都能当项目经理了。
首先，要写下客户的期望——从客户的角度来看，项目的驱动因素是什么［Rot98］。这个列表中应该包括：客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）［Gra92］。
接下来，写下项目约束。环境是什么样子的？能否灵活安排团队位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束可以改变（出问题的项目常会如此）。约束决定了项目的规模（还有持续时间和质量）。
对比客户的期望列表和项目的约束列表。你脑海里蹦出来的项目成功的必要因素有哪些？选择其一，比如发布时间，这就是识别出来的项目关键驱动因素。
列表上还剩下什么？应该还能看到功能集合、低缺陷率、发布成本，等等。在这些条目里，管理哪些才能保证项目成功？可以按重要性排列这些关注点，当然，它们不如关键驱动因素重要。客户和出资人会在这些方面对项目形成限制。从中选择两到三项，我们称之为项目的约束。
再看看剩下的条目。有些条目很重要，不过它们有很大的调整余地，我们称之为浮动因素。一个项目至少要有三个浮动因素。
最后看看还没选择的条目，是不是还有哪个比已经选择的更重要呢？如果有，那就再调整一下；如果没有，这个项目的关键驱动因素、约束、浮动因素就都找出来了。
我曾经见过有三个约束的项目，团队必须付出超乎寻常的努力，才能保证项目成功。以我的经验，如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理。
理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。大部分情况下，我们管理的都是不那么理想化的项目，所以如果项目有一个关键驱动因素、两个约束、三个浮动因素，这也可以成功。过多的关键驱动因素或约束，会让项目过于受限。这种情况下也许能够成功，但是项目经理和团队就得选择促成项目成功的组织形式和实践——不过还是要有点心理准备，因为可能无法获得百分之百的成功。
如果存在过多的关键驱动因素和约束，而且项目经理除了启动项目之外别无选择，这时所能做的就是选定一个关键驱动因素，并尽可能频繁地向出资人提交项目的产出，帮助他们决定自己真正想要的东西。启动项目时，为了得到项目的成功条件，可以问一些与上下文无关的问题（请看1.5节）。还要定义出发布条件（请看2.3节），这样就知道到什么程度算做完了。
提示：要是约束太多了，你就自己作决定吧
受到过多限制的项目难以逃避失败的厄运。过多的关键驱动因素，意味着没有人知道成功的条件是什么。约束过多，意味着组织中没人愿意去判断孰轻孰重。
有必要的话，让你的管理层决定项目的关键驱动因素、约束和浮动因素。如果这不可行，那项目经理就自己做决定吧，项目和组织会从中受益。
想创建出不受约束限制的项目需求是不现实的。假设有一个可以承重5斤的书包，如果你硬要往里面塞10斤的书，不外乎两种结果：要么书包带断掉，要么书包底破掉。管理项目也是如此，要根据约束来管理需求。要想同时应付过多的需求，那不管用什么办法，人手、时间、预算还有工具这些资源可能就是不够用，发布出的产品也很难具备高层想要的全部功能，同时可能有很多缺陷。
1.3 与客户或出资人讨论项目约束
要主动理解出资人想要的东西。下面这段谈话，是我在最近的项目中与出资人的对话。
JR：哎，克莱德。咱们看看到底是什么在驱动这个项目吧。
克莱德：可别！别再整我了。上个项目的时候，你就让我做过一次了啊。
JR：没错。还记得吗？你当时想添加新功能。你希望在产品发布之前塞进去尽可能多的功能，我可以加，因为当时组织项目的方式还允许。当时确实不容易，不过还是有可能做到。
克莱德：啊，对，我忘了。不过这个项目不一样啊。
JR：哦？跟我说说。
克莱德：你瞧，管人是你的事情，项目的运作情况你也得管。不过你不需要固定资产投资，我也不担心成本问题，因为唯一的成本就是工资。
JR：还有软件呢。
克莱德：你还真挑啊。好吧，如果需要什么软件，跟我说。不过老实讲，基本上工资就是这次的全部成本——我也不用管，我最关心的是项目要多久才能完成。
JR：那需要哪些功能呢？对它们的质量有什么要求？这是给财务部门用的小程序，你也知道他们总是要求完美。要是我不能保证给他们的东西毫无问题，莱斯丽会跟上面吹风的。
克莱德：没错，不过我会帮你扛着的。我就是希望给他们够用的功能就行了，这样你跟你的团队就能很快搞定，比如在十周之内。
JR：如果到了第八周，我们还没有开发完所有的功能，而且还有很多bug要改。你会怎么想？
克莱德：JR，别啊。我需要全部的功能。你们开发团队曾经完成过类似工作，我相信这次也一定行。
JR：克莱德，如果我能理解你到底想要什么，你知道，我们开发团队会尽力的。
克莱德：好吧。千万不能有不完整的功能。你尽管开始，把它做完，而且要让莱斯丽喜欢它。否则，她非把我头砍下来不可。文斯已经启动了一个大型的项目群，过段时间，我想让你们开发团队加入到那边去。他说已经准备好在十个星期后接收更多人了。这样，你也有足够的时间来给莱斯丽一些用得上的东西。
1.4 决定项目的关键驱动因素
在与克莱德的对话中，我让他说明他最看重的是什么。克莱德提到：一个大型项目群会在10个星期之后启动，很明显，日期就是这个项目的关键驱动因素。
在项目早期，似乎一切皆有可能，特别是没有估算任何工作的时候。出资人可能会说：“我们想要这5个功能，在8月1日之前完成，还不能有严重的问题。我们还想让你把成本控制在一百万美元之下。给你这6个人。OK？”
可别轻易说OK。
估算了工作量之后，就能知道用这么多钱、这么长时间，这6个人能不能做完项目。要是可以，蛮好。不过很可能没有办法按照出资人对时间、金钱、人力的要求，在规定的工作环境中，提供符合他们质量要求的产品。此时，出资人需要作出艰难的决定，要考虑组织中的项目驱动因素，包括发布日期、功能集合、成本、人员分配及其加入时间、将要采用的技术和实践，等等。
要是出资人不愿意判断项目的驱动因素是什么，这个责任就落到项目经理肩上了。如果项目经理不做决定，团队自己会决定。但是他们会各拿各的主意，而且这些主意也不一定符合出资人的想法。实际上，每个人，不管他在项目中的角色是什么，都会根据自己的想法判断。有的人会优先考虑满足发布日期要求，把减少缺陷的想法抛在脑后。有的人会根据日程安排，优先考虑仅实现一个功能——一个包含完整回归测试套件的功能，其余的功能却都没做完。有的人会优先考虑实现功能集合，开发出尽可能多的程序桩（stub），当测试人员发现问题时再去填充，直到时间用完为止。每个人都会做自己认为正确的事，而不是从出资人（或项目经理）的角度出发，因此作出的决策彼此不同。
制定优先级列表可以解决这个问题，其过程跟数独游戏类似，即将所有可能的驱动因素列在左边，右边空出来等着填数字。
使用矩阵表明项目的优先级
下面是克莱德的排序矩阵。
项目驱动因素排序
发布成本5
发布日期1
功能集合2
减少缺陷3
人员配备4
工作环境6
在这个项目中，发布日期是最主要的驱动因素。如果产品今年不能发布，这个项目就没有什么存在的意义了。但是完备的功能也很重要——功能不齐全，即使及时发布，整个项目也没有价值。而且，由于公司业务属于受管制行业，产品的缺陷率必须很低。接下来是人员配备，因为这些人必须能在十个星期之后参与下个大项目群。项目的成本控制不太重要，因为项目价值很高。工作环境排在最后，为了保证及时交付，我可以灵活调整某些因素。
即使已经有了排好顺序的优先级，我们还是没有多少灵活性。不过了解了项目的关键驱动因素，我就可以定义出项目的成功条件，然后选择适合项目的生命周期。项目团队可以制定出发布条件，并根据驱动因素合理地安排各自的工作。啊，对了，最后，我们按照当初的要求，成功交付了项目。
1.5 应对喜欢过多干预项目的出资人
很多时候，关于成功标准的谈话不会进行得那么顺利。读者也可以看到，我必须促使克莱德作出选择。类似情况很常见。
有些项目对于功能集合、减少缺陷、时间安排这三者的要求都是最高的，而且优先级都是头等。我敢说，读者一定以项目经理或团队成员的身份参与过类似项目。你不能再给团队添加更多人手了，而且项目的预算不可改变。项目流程必须按照公司的强制要求执行，还得使用公司规定的办公室和家具，也许还有其他一些工作环境问题也让项目难以推进。除非没有技术或时间上的风险，否则没人能够使这样的项目成功。不过还是有一些方法，能够理清这些看来已经没有余地的约束条件。
在1.4节中可以看到项目的驱动因素矩阵。如果出资人愿意排定优先级，那这种方式再好不过，可以帮助有些勉强的出资人做决定。项目经理有时要先草拟一个优先级列表，拿给出资人看。比如，几个出资人对于优先级的排序可能无法达成一致；或是遇到一个不愿意拿主意的出资人。此时，项目经理就只好自己做决定，然后再给出资人看。他可能会愿意去修正优先级列表，或者直接签名通过，就不再自己搞一个了。
要想明确项目真正的驱动因素，有两种不同的途径可供选择：预测未来；使用与上下文无关的问题。
1.5.1 预测未来
让出资人设想这样的情况：现在离项目预定交付时间只剩三个星期，却还有功能尚未实现。（着重讨论该出资人需要的一两个功能。）除了没做完的功能之外，还有很多严重的缺陷等着修复。这样看来，要想在预定的发布日期之前开发完所有功能并修复所有缺陷，很明显是不可能了。这个时候，出资人该怎么办？
如果出资人这么说：“把你的脑袋砍下来给我吧。”那就该考虑“三十六计走为上”了。请看7.7节。
不过出资人很可能会这样说：“把这个该死的项目做完吧。你还需要几个人？”接着，你可以问他：“是先做完所有的功能，还是先修复所有的缺陷？”他一般会说：“这两个功能和这些问题都得解决掉。”再问他：“以项目目前的优先级顺序，是吗？”项目经理要经常帮助出资人搞清楚：哪些约束是真正的约束，哪些是出资人自己一厢情愿的想法。
在对话中提出与上下文无关的问题，有助于找出项目的驱动因素、约束以及活动余地。
1.5.2 使用与上下文无关的问题识别项目真正的驱动因素
明确了驱动因素之后，项目经理就可以发掘项目的需求了。与上下文无关的问题有助于抽取出这些需求。提出这些比较抽象的问题，可以诱导其他人说出他们对于项目的假设。不妨从下面这些问题开始。
项目要怎么样才算成功？
为什么想得到这样的结果？
这种解决方案对你来说价值何在？
这个系统要解决什么样的问题？
这个系统可能会造成什么样的问题？
要注意，少用“为什么”之类的问题。“为什么”问得越少，对于业务需要反而能了解得越多（而且问问题的人也不会像个令人厌烦的三岁小孩子。）同时，“为什么”这类问题很容易让对方产生戒心。也得注意避免“怎么做”之类的问题，出资人会觉得你在让他们设计系统。
在问问题时，要让人感觉到你真心希望了解这个项目，而不要让别人抱有戒心。这些问题可以为项目经理和出资人将来的合作打下良好的基础，而不是形成龃龉。
这些问题可以找出系统的价值。向出资人提问时，要营造平等的气氛。在纸上做笔记，而不是用电脑，这样你和出资人之间就不存在障碍。用这些问题开启对话。刚开始时，从出资人那里收集到越多关于项目价值的信息，你就能更深入地了解如何设计这个项目。
项目要怎么样才算成功？
——贾斯汀，项目经理
几个月前，我开始管理这个会持续两三年的项目。这两天，老板跑过来跟我说他想加入一个新的功能。一个我在说：“酷啊，这个新功能一定会很棒的！”而另一个我说：“噢不，我们介入这个项目已经两个月了。如果我给老板留下可以随意加入新功能的印象，要么得调整我们团队的工作方式，要么我一定会有麻烦。”于是，我问老板这个问题：“对你来说，项目要怎么样才算成功？”
使我大吃一惊的是，老板认为这个项目要能完全随需应变才算成功。他十分确定：不到最后一刻，需求不会停止变化——也许要到我们发布前一周才能最后明确。我以前可从来没有管理过类似的项目！不过既然现在知道了，我就能着手筹划应对之策了。
1.6 编写项目章程，共享现有决策
项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。整个团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。
在启动项目时，编写项目章程可以让大家知道应该完成什么目标，以及项目干系人提出的约束条件。即使不知道完成项目需要的细枝末节，编写章程也有助于发现潜在的问题。项目章程可以帮助项目经理和团队理解风险和成功标准，大家也可以藉此考虑组织和操控项目的方式。
如果你在管理敏捷项目（使用敏捷生命周期的项目，请查看附录A.4节），项目章程会很简短，只要包括项目远景（参与项目的人可以做出正确的决策）和发布条件（这样就不会为了给产品“镀金”而错过项目的结束时间）就够了。
下面是我的项目章程模板。
远景
需求
目标
成功标准
ROI估算
项目章程是有意要设计成这么简短的，目的是帮助团队赶紧启动。它不会包含团队对于这个项目“完成”的定义，也不会介绍团队如何组织项目，但是已经足够让大家着手开展工作了。
1.6.1 远景
每个项目背后总有一个缘由（或者两个、三个）。发起这个项目的缘由何在？项目的价值何在？要用描述远景的句子来说明项目的价值。越早向大家阐明项目的价值，团队就越有可能告诉你接手这个项目是否明智。也许他们会告诉你，囿于目前的约束、资源和他们的能力，这个项目就不可能完成。要是不能明确阐明项目远景，很可能这个项目就是“不可能完成的任务”了（因为没有远景的项目无法完成）。实用的项目远景对团队来说不可或缺。
1.6.2 需求
某些情况下，项目唯一的需求，就是要在某个特定日期到达之时发布某些功能。更多时候，需求掺杂在这样的语句之中：“2月20日发布的主要版本中，我们需要这个又棒又炫的功能。”这些才是项目的驱动因素，产品功能列表不是。
1.6.3 目标
项目目标是项目经理希望通过项目要达成的目的，不过客户跟出资人可能并不赞同这些目标。（想了解更多关于目标的讨论，请查看2.3节）。
小乔爱问……
谁来撰写项目章程呢？
撰写章程，可以帮助团队早点形成凝聚力。要让尽量多的团队成员参与编写章程。
要是还没有为项目分配人员，那就先自己写章程吧。如果不是单枪匹马，就跟大家一起写。在项目启动会议中（请查看10.3节），把章程跟大家过一遍，确保每个人都知道其中的内容及其缘由。
目标与需求不同［DeM97］。项目并不一定必须交付它的目标。遵循传统的阶段-关卡（phase-gate）式开发过程或瀑布式开发过程的项目，它的产品里面会有比较严重的技术债务（technical debt，请查看附录B）。重新设计以解决技术债务、添加更多自动化测试、设计冒烟测试等，这些都是可能的项目目标。
客户有时会提出一些特定的要求：“如果目前的时间安排允许，并且不麻烦的话，我想要一个电子签名。”作为一个注重实效的项目经理，你可以说：“OK，我们会把它加到项目目标里面去。要是雪丽和简有时间，她们会去做的。”
1.6.4 成功标准
项目完成后，客户能用交付的产品做什么，这就是成功标准的定义。成功的标准并不涉及缺陷，而只关注能力。（请看［Rot02b］和［Wie05］）。
下面是一些成功标准实例。
要包括功能1、2、3，这样我们的产品就可以打入目标市场了。
要提升产品性能，再测出相关数值，我们就可以将其与竞争对手的产品进行对比，编写新的市场营销材料。
客户不需要访问我们的网站，就可以打开安装包、加载软件。
在第一季度发布。
你还没有意识到，项目就已经开始了
项目通常在正式开工之前就已经启动了。也许有人已经开始了原型化工作，也许有人已经预想了一些功能，也许管理层已经跟首席架构师探讨了项目在技术上的可行性。不管你怎么看，这些都是项目的组成部分。
由于项目在你意识到之前就已经开始了，所以大可不必因项目章程、项目规划和项目日程的反复修改而烦恼。作为注重实效的项目经理，在项目前期，虽然有些工作已经开始了，你还是应该张开双臂拥抱项目，接受眼前的一切。在项目中期，你应该不断评估项目进程和风险，从而掌控整个项目。项目收尾阶段，如果你一直都注重实效，那就没什么好担心的了。
团队控制着成功标准。项目经理要确保：成功标准中不会包含非团队成员要完成的任务（比如“卖出50 000套软件”）。项目经理和团队不能控制别人做什么，只能控制自己和团队的行动。要确保成功标准在项目经理的掌控之中。
1.6.5 ROI
我接触过的客户中，很少有人度量ROI（即投资回报率）。毕竟，要操纵数字太容易了。不过，如果管理层要求的话，项目经理可以估算项目的回报，试着计算ROI。在项目完成后，可以看看是否达到了当初预计的数字。
1.7 理解质量对于项目的意义
要想理解质量对于出资人和客户的意义，必须先要理解项目的关键驱动因素、约束和浮动因素。出资人是为项目提供资金的人，客户是使用产品的人，他们不一定是同一群人，而且他们对质量的定义也不一样。没错，这让项目经理的工作更不好做了。不过，知道了对于项目来说“质量”意味着什么，也就部分理解了“完成”的含义。
温伯格这样说：“质量，就是对于某人的价值。”［Wei92］这个定义也就意味着可以为项目产品添加新功能，并可查看一个功能吸引了多少个（以及什么样的）“某人”。加快或者延迟某个版本的发布，会吸引（或是拒绝）多少个“某人”。在想到出资人和客户的时候，不妨考虑一下他们希望从项目中得到什么。这样一来，项目经理便可以根据实际情况调整发布时间、项目预算和人员配备；同时，项目经理也可以权衡：是否所有的“某人”都需要某个功能。如果项目经理和团队知道“某人”对于质量的定义，大家就可以朝着这个方向来努力；即使他们改变了主意，团队仍然可以取得成功。
根据项目产品所处的不同市场应用阶段［Moo91］，如图1-2所示，客户对于质量的定义也有所差别。
图1-2 摩尔的鸿沟
当产品处于市场应用的早期阶段时，顾客群的规模不大，但是技术狂热者们已经想先睹为快了，所以会面临比较大的发布压力。此时产品不必具有很多功能，而且也不必有很高的稳定性，但是它必须具备自己的独特之处，来吸引更多客户。
产品进入初期市场时，无论客户群大小，人们都会有各自不同的需求。所有客户都希望马上得到新版本，而且要具备他们自己想要的功能。此时的产品用起来不能太费事，不过由于只有你的产品能够解决客户的问题，所以即使有点儿缺陷，它的销路还是会很不错。
一旦产品（或有替代产品）进入到大众市场之后，实用主义者们就会关心产品的缺陷能否得到及时修复。如果在之前的版本中累积了技术债务（请查看附录B），现在就到了还账的时候了。鉴于实用主义者拥有强大的购买力，管理层会迫于压力而决定频繁升级产品——即使有些客户不想安装最新的版本。在加强产品稳定性的同时，每次发布的新版本中多少要加入一些新功能。
保守主义者也会购买你的产品，但往往是迫于某种压力作出的选择。如果产品不能完成承诺的功能，或者有太多缺陷，保守主义者们会抓住一切机会发起抨击。他们不需要新功能，只希望承诺的功能好用就行了。此时只要发布缺陷修复补丁，或是发布更加可靠、更高性能、更稳定的产品即可。
对于你的产品，盲从者和怀疑论者有可能买，也有可能不买。处于这个阶段的产品有时会被称为“现金牛”，因为公司此时为产品提供支持带来的收入，要超过提供支持需要付出的成本。
在产品生命周期早期，尽管发布的很多版本都会面临很大压力，但在产品生命周期后期，客户群规模日益增大，他们要求尽量减少缺陷，这时项目面临的压力会更大。
铭记在心
每个项目启动时都要有章程。
对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。
要知道“质量”的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
