我是一名管理顾问，我的关注点是风险：不论这些风险是来自于项目成员，或者你管理项目人员的方式，还是项目自身。我所做的就是：帮助人们发现风险，和帮助人们管理风险。

一部分是辅导；当然也有研讨会和培训。我花费相当可观的时间做鉴定，来搞清楚到底发生了什么，又是为什么发生。因为你会碰到由不同问题根源引起的许多症状。而你想立刻知道是什么导致这一切。有时候是技艺高超的成员们并非都处于合适的职位，有时候则是一团糟的流程。你必须管好这一切。有时候人们只是并非真正知道他们应该做什么以及怎么做。因此你需要知道详情或是综合状况，以帮助人们度过最困难的时期。有时候鉴定是正确的选择，有时候是培训或研讨会，有时候则是辅导。我辅导项目经理，行政官员，有时候是scrum master，但不多。我并不专注于辅导scrum master。有很多时候只要花费一点点力气就可以帮助人们渡过难关，使他们可以顺利地继续前进，也有可能他们需要我回去帮更多的忙。

我想要提到的第一本书是和人相关的。因为如果没有合适的人为项目工作，你无法完成任务，那根本就没有希望。那就是为什么我写了《Hiring the Best Knowledge Workers, Techies and Nerds: the Secrets and Science of Hiring Technical People》一书。（讲一个关于能力不足的人员和冗长的头衔的笑话，在那本书中我也有写到。）大意是，不合适的人员招聘方法非常多，这导致人们被安置在不合适的职位上，而他们可能是非常好的人，也许能够完成其他的任务，但他们却无法做被雇佣来要从事的工作，于是他们转变成一个极大的障碍，成为组织的一个巨大瓶颈。我们并不希望那样。如果你就是那个员工你并不希望那样，如果你是经理你也不希望那样，从头到尾那都是灾难。那就是我写书的原因，事实上我是在为一个客户工作的时候开始写那本书的，当时我正在辅导一个客户服务经理，而非其他人，他曾说过：“你知道，我就是无法找到合适的人选。他们不在那里，我面试了上千个人（并不是上千人，而是数十个），但我无法找到合格人选，而且我既无法找到合适的人也没有谁愿意和我一起工作。”于是我说道：“你有做这些事吗？”他说“没有”。“你有做那些事吗？”，“没有”。于是我写下这些概要，然后他说“啊，这真的是非常有用，能不能就第一件事情再多说点：怎么分析这个职位？”

并不完全正确，因为你知道书是怎样的。不过，是的，这件事确实有帮助，让我对于要揭示什么和如何去做心里有底，而且效果真的很好。那变成了书中“人的风险”部分。随后我意识到你能够找到合适的人选，我们拥有许多行业内的聪明人，但人们今天想做开发者，明天想做经理，而你所接受的所有培训都是“这些是你所需要填写的表格”。你并不知道如何处理一对一的关系，你并不知道如何提供反馈，你并不知道如何去辅导，你并不知道如何去协调工作，你甚至都不知道如何会见。作为一名经理有各种各样的事情需要去处理，而这些事，是技术人员，甚至即使是头号技术人员也根本就不需要做的。这真的很重要：你如何成为伟大的经理，你如何练习去成为一名伟大的经理，以及你如何去获得反馈，那些关于你自己是否正在做正确的事情的反馈。

Esther Derby和我写过《Behind Close Doors: Secrets of Great Management》，我们在七周的工作中密切观察一名几乎完美的理论派经理，然后就我们在这七周里面所使用的工具和技巧展开讨论。那很有效，Esther 和我完成了一系列“Behind Closed Doors”研讨会，都很不错，接着我发现还是有许许多多之前习惯于串行生命周期的项目经理。他们都很聪明，并不笨，但他们多少受锢于“让我们先确认所有的需求”的思维。虽然我已经在这个行业工作30年之久，我也从没有那样思考过。首先，如果必须先做的话我们可以尝试确认部分的需求，但我们绝不会想要确认所有的需求，而且那永远都不会是正确的。那么和这些刻板的人一起你会做些什么？他们所考虑的关于项目的第一件事就是错误的，之后它影响到项目发展过程中所有其余的部分。于是我写下《Manage It. Your Guide to Modern Pragmatic Project Management》这本书（你会发现这个书名简短多了）。用于指出这些问题，例如，在项目起步阶段、项目进行时、以及项目末期，项目经理如何做出有益的选择以真正产生作用。

好的，我从1997年也或许是1996年起就开始讲授项目管理研讨会，这促成了《Manage It. Your Guide to Modern Pragmatic Project Management》一书的问世。在参加我的研讨会时，人们问：“噢，我没想到你能够象那样组织项目。也没想到你可以在串行生命周期中使用时间盒方法，或是在迭代生命周期中施行持续集成，或是在增量生命周期中采用自动化冒烟测试。我没想到居然有这么多种的生命周期方式。”正因为我一直在教授此研讨会，当然还包括在过去的10年中的不断发展，相对而言写书自然是轻而易举。

我们当中那些写过“相对容易”这个词的人知道它毫无疑问是指相对的。但我曾真的很想知道，当你并不必须采用敏捷模式时如何进行项目管理工作？我喜欢使用敏捷管理和实践的某些方法，经验表明这样能够尽最大努力地降低所有的技术风险，以及进度的风险。但也许你做不到，比如你的组织坚持基于阶段性状态来度量你，比如在组织里，因为各种原因造成你至少必须是按顺序串行方式启动项目，会有各种不同的原因，像是无法开始测试，营销人员觉得他们需要给你一份500页之巨的市场需求文档（Marketing Requirements Document，MRD），或者他们只完成了200页，还有大约180页之多。在这样的组织里你该怎么办？

完全正确。因为有太多的组织无法匹配完整体系，或是人们没有以敏捷的方式工作，或是他们说：“不，出去！不受欢迎的人，搞敏捷的都是黑客。”我不想和大家争执，也不想给任何人贴上标签。我想要帮助人们做那些最有效的事。时间盒并非是一个出现于90年代或80年代甚至70年代的词汇，而是自古以来就已经存在了。那么既然你使用时间盒已经有段历史，为啥不用？持续集成并不是什么新概念。回溯到1990年，我曾经在某个项目中强迫实现了持续集成，那时我们还没有好的持续集成工具，也没有真正好的版本控制工具。不，不，我没有lava lamp灯，也没有CruiseControl软件，任何一个我都没有。但是我们可以每晚构建，也能够看到是什么破坏了软件包。而且依然有必须去适应持续集成的组织。

假设你要替换系统中已经存在的一大块，而此时人们需要使用这个系统。你并不会使用每一天改动一点点的方法。然而，你可以每天从主线上取下遗留系统中将被替换的部分，与团队成员当前所做放在一起。他们可以持续地从主线中获取，然后做修改，他们所做的就是持续集成。当需要将改动合并回去时，发生的合并冲突和各种问题的数量非常明显的减少了。这时根本就完全不需要做阶段式集成。大多数认识到持续集成价值的人都这样做。一些人有点疑惑，你需要帮助他们认识到“我怎样才能做到？”于是我列出基于不同项目经验的大量经历，想法和事件，以及我客户在不同项目中所做的来描述：“这就是让它工作起来的办法，既然可以在我的组织里发挥作用，对你也一样可以。”

几乎每个项目中，甚至是一些敏捷项目，你都会和“进度游戏”打交道。如今，在敏捷项目中你会常常碰到类似于“我们必须接受，否则就有大麻烦”的进度游戏，例如营销部门的某人或是产品负责人或是某个客户方代表会说：“我们能够往里面就再增加这么一项么？”，而没有人会真正说：“我们去掉一些任务腾出空间给这一项吧”。那是进度游戏中管理方的情况。而进度游戏中团队一方则是：“我们无法说不。我们热爱自己的客户，想要做有用的东西，善于团队配合，我们会吸收下来的……”。于是任务清单越来越长。

这些是相互依赖的进度游戏，因为在同一个组织内你会习惯于接受“我们必须接受，否则就有大麻烦”以及“我们无法说不”。而人们没有意识到的是他们完全可以让自己活得轻松许多。我在称为“敏捷游击战”的讲演中通过进度游戏案例来协助向敏捷的过渡，它不是“这就是你怎么真正做到敏捷”，也不是自顶向下的方法，而是把想法和实践经验带入到组织中的方法。我把它看做是采取措施促进组织发展。那两个进度游戏案例真的在帮助人们从时间盒转移到迭代的过程中起到了很大作用，尤其是缩短迭代的时间盒长度、用于排列产品 backlog和帮助团队学习如何更准确的估计。那些做出估计却无法获得反馈性意见的团队永远也无法得知他们的估计是做得好还是不好，于是只能凭感觉给出 5、8、13，或是其他数值的估计。但如果你不知道你的估计究竟有多好，也从来不会回过头来再查看，那你如何知道哪些做得好，哪些又需要被换掉？因此，假设你们处于两周的迭代周期，第一周中的时候有人来找，如果刚好有些任务还没有开始，你或许可以换掉它们。但你必须确认你的估计是有效的，你必须确认你的估计刚好接近精确，这样你才可以用值为8个故事点的任务来交换另一个8故事点任务，但是如果有人想用13故事点来交换你迭代中的某个5故事点的任务，你就无法替换——你不能那样做，那违反了自然规律。我看到过大概14个如下的进度游戏：“给我找块石头”，“否定女王”，“希望是我们最重要的策略”。你不可能依靠希望来管理项目。希望和祈祷也许有帮助，但那并不是管理项目应该使用的方法。你必须能够看到进展，真正了解正在发生什么，这样才能够消除进度游戏，许多的敏捷实践都真的有帮助。

“给我找块石头”是一种进度游戏，当你为项目拿出一个日程表时，即使敏捷项目经理们或scrum master们不得不说：“我觉得我们可以在一次迭代中做这么多：看起来像是8、9或10个迭代周期”，最后你还是会得到一个期限。“给我找块石头”是指：你拿出你最佳的日程表，而后某些高级经理说“挤一挤”。于是你回到你的团队并想办法做到。当然人们所说的第一件事是：“我们把测试砍掉”，仿佛那真的可以帮助你们更快地完成产品。可那不会，但人们依然那样做。“我们可以平行化这个，我们可以砍掉这个边角，我们能做这个”，但其中任何一样都不曾有效。你将时间缩短了两周。接着你将新的期限告诉高级经理，然后他们说：“不够好”。

你可以一直这样做直到你准备好拔光你的头发，或是你可以问一大堆关于是什么在引导项目的问题，有些上下文无关的问题可以问，你可以说：“‘完成是什么意思？我们的发布标准是怎样的？让我们先确定我们都在谈论同样的东西”。你可以从时间盒换到迭代，因而能够以优先级顺序完成尽可能多的工作（最好以价值排序，而非风险），并保持不断地完成进度。当他们说：“你该做完了”时，你的确完成了任务，只是不一定实现了想要的所有功能而已。所以我认为“找块石头给我 ”是一个非常常见的进度游戏。很多的项目经理都被卷入其中。“或许我们能够更有效些”，“或许我们可以进行得更快些”，则是另一个进度游戏。它不断地继续下去。

是的，并且这些功能失常现象可能发生在贯穿项目周期的任何时候，而不仅仅是规划时。例如“分割注意力”的进度游戏，在这种情况中，你认为你拥有团队中每一个人的部分时间。于是他们被设想为将一部分时间投入在这个项目，将另一部分投入到那个项目。那就是多任务化进度游戏。你不可能同时集中精力在两件事情上，我打赌你做不到一只眼看这里另一只眼看那里。你做不到，那是不可能的。但是如此之多的高级经理们，由于他们的工作自身决定了每天都始终是多任务化的状态，忘记了或是真的不知道技术工作者们需要充足的时间来真正地投入到他们所做的工作中，他们需要思考。有时候思考涉及捡起一支笔，有时候思考包括在电脑上打字，有时候它包括和其他人交谈，而有时候人们只是坐到椅子上休息一下并思考。如果他们经常地从一个项目移到另一个项目，那就没门。而且很扯淡。有时候经理们同时分配给你两个项目的任务，仅仅是为了不让你感到无聊。但我们很少有人现在会感到无聊。有时候他们无法决定那个项目更重要，就像处于“裤子着火”的情形。

是的，“裤子着火”，事实上是Elisabeth Hendrickson或是Tim Lister（我一时想不起来，但我有写在书中）命名了这个游戏。我希望我聪明到可以命名所有的游戏，但我并没有指定所有的名字。[名字会很长！]是的，它们会的，我遭受过长名癖的痛苦。“裤子着火”意思是：首先高级经理想要做某个项目，然而大约一周之后他们想把另一个项目设为最高优先级。接着一、两周后他们又改变了主意，或是三、四周后。因此你不停地从一个项目转到另一个再到下一个，无法完成任何东西。我们知道如何处理这样的情况：一到两周的短迭代周期，足够你一次在单个项目上取得实质的进展。如果高级经理正在整理产品目录，难以置信但可能发生的是，很快地，你被调到另一个项目。只有这种情况下我才会建议使用在周末终止的迭代周期。在周五或是你们工作周的最后一天结束，那么你就能用周末来做一个天然的衔接过渡，然后到了周一都是从头开始一个新项目。不然，我会建议团队们在一周的中间完成迭代，或是重要的里程碑。[以抵制周末干活的诱惑！]你相信，你就会得到。

我希望是这样。这就是我插入进度游戏章节的原因，因为我觉得如果人们为一些事物命名，即使团队会说“噢，我们的VP Joe正在使用的招式是‘给我找块石头’或‘否定女王’” —— “否定女王”是另一个进度游戏 —— 至少你们拥有了一个共同的词汇表。而且拥有一个有趣的名字，附上漫画图片（其实我让一个漫画家为那个章节画了好些图片），我想会帮助人们对它产生一点点的预期。除非我曾经看到过，否则我无法为这些进度游戏命名；而我曾经见识过所有的游戏 —— 让人欣慰的是并非都在同一组织内，而是在我职业生涯的整个过程中见识的，而且我非常肯定的是我都曾亲身经历过。接着，拥有词汇表，并发现有了选择余地，我就不需要死守着一条路不放，我可以尝试这个方法，如果没有用我可以尝试另一个，要是还不顶用我还可以再试试别的。针对每个进度游戏，我都有至少四或五种，通常来说更多的可能的选择。试试这个，试试那个，试试这个，试试那个。它帮助人们意识到：“好，也许我可以按自己的方法处理这个进度游戏”。不一定就会发生在明天，可能在一周之内、可能是迭代结束时、也可能是我们达到某个特别的里程碑时，如果我们能拥有一个共同的词汇表，我就能把团队的其他人带进来。我们完全可以作为一个团队来解决难题，不论你工作在任何一个团队，这都会极大地帮助团队以协同的方式工作。