Linuxeden开源社区作者 ，译者 孙浩
核心观点
- 顶层的决策者们可以对一个软件项目的品质和商业价值有巨大的影响。
- 他们需要选择去提炼如何运用这种影响力。
- 施加影响力并不需要决策者一定要拥有一个计算机科学的学位，以便用软件团队内部协作的语言和他们沟通。
- 通过一些关键的时间窗口及常用非技术手段的应用，可以帮助决策者事半功倍。
- 通过运用书中介绍的改变开发团队的心态的策略，决策者可以帮助团队使项目展现出令所有人震惊的积极变化。
决策者可以并且应该参与到软件开发的过程中。Roland Racko的著作《Timimg is Almost Everything》中论述了如何在软件开发计划的早期阶段，利用“问询式管理”执行风格影响团队的思考和行为，从而提升软件的成功。
InfoQ 读者可以下载 《Timimg is Almost Everything》书籍片段。
决策者为什么必须参与软件的开发过程？为什么作者决定选择Essence并用非专业术语的问题来问询？如何处理组织中的人员感到超负荷的情况？开发商和技术主管可以做些什么来获得管理人员的改进支持？决策者如何与中层管理人员合作以获得改进？针对上述问题，InfoQ采访了Roland Racko。
InfoQ：为什么会写这么一本书？
InfoQ：这本书是写给谁看的？
Racko：表面上看本书是写给初创企业家的，有些很有钱的人雇用程序员来让他们的软件更出色，但是不太可能有共同语言和经验来调动他的新创软件团队。然而，书中的内容对于所有经理和软件团队都是有用的，不管是初创公司或者是其他公司。许多读者在本书的网上评价中都说明了这一点。
InfoQ：为什么决策者需要参与到软件开发的过程中？为什么不能把这个工作交给技术人员？
Racko：决策者不能“不参与”。举个例子，假设执行官问“系统完成了多少了”？假设他得到答案“95％完成，老板”。如果他接受这个答复并走开，他就陷入了一个高风险的处境，很快就需要他的直接干预。为什么？因为这个“95%”将在接下来的四个月内反复提到直到项目超时。这种超时将需要他的直接干预并提供适当的新资源。请注意，决策者在企业运营的其他领域，如销售、分销、生产或其他更传统的企业专业领域通常不会完全“交给员工处理”，因为他对这些领域有着远见，同时对这些领域的质量水平有感知。是什么使软件免于这种有远见的监督？
当然，在大公司决策者不一定是CEO，可能是CIO、CTO，首席架构师或者其他职位。无论如何，本书并不提倡最高管理层对软件开发过程进行全面微观管理。本书提倡在软件开发过程中的一些特定点进行非常有选择性，有针对性的和时间敏感性的干预措施。
InfoQ：在书中您提到决策者经常对问题反应迟钝，这是什么原因导致的呢？
Racko：他们并不是对问题反应迟钝，实际上他们非常及时的对问题爆发后的混乱进行了反应。大部分决策者在反应过程中并没有意识到问题是什么时候产生的。因此，在外人看来，他们似乎反应“迟钝”了。当一个决策者可以从书中学到如何在合适的时点干预项目从而阻止问题的发生，那么在外人看来决策者对项目的反应就如同天才一般了。
InfoQ：如果他们运用自己的影响力修正错误会发生什么呢？
Racko：一个决策者制定的影响团队的命令包含两个组成部分：时点和力度，即什么时候施加影响，和施加的力度。本书的第一部分描述了非专业术语的问题和预期中团队的回答。这些内容帮助决策者确定研发团队是否偏离了决策者的目标。第一部分阐述了如何规划提出问题的时间以便提前预防一些特定的、普遍的软件开发失败的模式。本书第二部分阐述了决策者如何调整问题的力度以得到他们想得到的答案。有3种可能的结果：一无所获、好结果或者坏结果，这完全取决于决策者在这个过程中如何使用时点和力度。
一般而言，决策者的干预缺乏第二部分中所说的力度的时候，结果通常是“一无所获”。面对新的决策层干预时，如果存在敷衍的情况，软件团队的心态是“我们不需要按照他们说的去做”，因为他们感觉到管理层的干预行为无力、空洞且不适用。管理层的干预可以认为是团队管理缺乏惩罚性制度的一种现象。
当团队反应迟钝时，决策者翻倍提供资源、大声喊叫、提出更多命令并且举行更多补救的会议。正如之前所说的，出现这样的“坏结果”是因为增加资源的时点已晚。本书第2部分的全部内容是为读者提供详细和尽可能微妙的方法，以确保第1部分中那些他们喜欢的想法以正确的力度传播并保证被团队真正落实。相比较而言其他书只是告诉你出色的管理理念，但是让你自己摸索如何在公司中将其落实。
“好结果”发生于决策者展现出先发制人的影响力，并将这种影响力在本书第一部分阐述的项目特定的早期阶段展现出来。使用书中的问题在项目的初始阶段进行沟通并预设项目进展的方向。相对于“倍增资源”，当早期沟通和本书第二部分的战术相结合后，这种先发制人的影响力会相对较弱一些。
InfoQ：当决策者委托一个软件开发计划时您建议他们做什么呢？
Racko：每一个经验丰富的帮助数百个软件项目的顾问都有自己最爱的“高管在项目开始时应该做的事情”的列表。看看这本书，并决策把我列表上的项目当做是告诫去和项目团队在早期进行沟通，这是个多少有些婆婆妈妈的新时代方法。尽管这种做法并不坏，但它完全忽视了真正的要点。那就是，问问题的人必须对事情接下来的发展有完全的掌控力。
这意味着，认为利用书中的问题，仅仅能检验软件团队管理事实，这是完全错误的。当然，通过这些问题可以达到事实，并且这些事实会决定决策者是否改变做法。然而，重要的是要意识到，为了回答本书中这些具体的问题，团队必须开始以某种方式思考甚至为问题制定有用的答案。这些问题含蓄地聚焦、局限和引导。这是为什么我称这个技巧为“问询管理”。
在某种意义上，我要求决策层详细思考他对该项目在技术层面上的成功的定义，并据此定制出其答案可以定义这种成功的细节的问题。如果经理一再反复询问某些类型的问题，团队从中得到的讯息将会是非常明确的 – 这些问题的主题对于决策者而言是衡量成功的重要指标。制定正式规则、质量属性、立场文件、法令、准则和备忘录的需求因此大大减少。对决策者想法的抵制减少了，因为问题的答案是执行任务的人意识到的，而不是被领导层强加的。因为他们自己想到了这些答案，所以团队拥有这个答案，并且也会自然地遵循这个方向，因为他们感到那是他们自己的方向。事实也确实是这样。
例如，考虑这四个关于项目用户界面的团队问题：“用户界面的开发进行得如何了？”“用户喜欢新界面吗？” “关于用户界面质量，到目前为止你在项目中得到的最新心得是什么？ “是什么阻止我们在行业中拥有最神奇，友好的用户界面？”
表面上看，所有的问题似乎都是关于用户界面的状态的，读者可能会认为它们是可互换的。但是仔细探究，每一个问题都隐含地传达了什么对决策者是重要的，并且每个问题的例子都具体传达了与其他问题的例子完全不同的东西。其中一些问题只会得到二元的答案，不需要团队的思考，同时向决策者提供基于现实的建议。其他的问题则有完全不同的效果。
所以我对于决策者在委托项目时应该做什么的建议是，首先要问自己怎么样才认为这个项目是成功的：有什么证据可以显示出项目非常出色，超越同类？然后开始考虑在项目开始、中间和临近发布日期的各阶段要提出什么问题以不断强化（这与“需求”不同）这种证据的产生。此后不断的提出这些问题。本书的第二部分把这种做法叫做“用天鹅绒手套锻炼你的力量”。
InfoQ：您的书提供了基于Essence的非专业术语的问题。什么让您决定选择Essence？
Racko：历史上有许多尝试来获取软件开发过程的片段和部分的名称和词汇。目前在软件工程领域我认为Essence是涵盖最全面的。此外，在本书中所使用的专业级别，那些词汇对于非技术人员，如用户或资助机构也是可以理解的。这是一个真正的加分项。
InfoQ：决策者应该如何使用这些问题呢？
Racko：本书主要使用Essence问题来确定开发过程所处的进展状态—即项目在从开始到结束的时间线中的什么位置。然而，细心的读者也会发现，其中一些问题可以帮助确定如“团队”或“软件要求”的合适程度。
InfoQ：这些问题只是给决策者使用的吗?
Racko：虽然本书假定Essence问题及其他任何问题将被具有软件项目的审批控制或管理控制的决策者使用，但是实际上这些问题可以被想要解决困扰软件开发的典型问题的任何级别的任何人使用。这些问题不仅是为了解决问题而设计的，它们旨在间接地使团队对软件开发转变思路以得出答案。这种转变可以对软件开发的长期过程产生积极的影响，不管这些问题对目前的项目可能产生的影响如何。从这个角度来看，这些问题中的许多个都可以被任何人使用以来普遍重塑公司的思想状态。
InfoQ：您在书中提到，组织中必须有空间和能量容纳改变以促使改变的发生。如果组织中的人感到超负荷应该怎么办？您是怎么处理的？
Racko：我们很容易反感那些不管实际状态如何，都说自己已经超负荷工作了的员工。但即使这是对公司人员的客观评估，第一步也应该是探讨这一观点的细节，从而揭示造成超负荷现象的根源。超负荷不是什么捉摸不透的巨大云团。假设在充分考虑了人员配置和资金来源的情况下，超负荷通常有四个来源：
- 目前公司内部混乱的状态导致效率低下，从而引起的超负荷;
- 同时尝试太多技术变革引起的超负荷；
- 低估了与其他部门或地理位置协调软件项目所需的接口活动而产生的超负荷；以及
- 由于非正式的系统规范或非正式的架构设计过程而导致的不断的系统返工所引起的超负荷。
减少超负荷的第一步是确定超负荷是以上哪些来源引起的，然后针对来源采取适当的补救措施。因为你无法纠正你无法衡量的内容，因此本书还在附录中提供了调查样式的问卷表，帮助您了解除了上述一般来源以外的其他超负荷来源。
InfoQ：开发者和技术负责人可以做些什么以获得决策者对于改进的支持？
Racko：这真是一个非常好的问题，这个问题的答案将会为世界各地的公司带来令人难以想象的积极改变。我这样说是因为每次我为一个出问题的项目做咨询的时候，其实这个公司内的某人、某处已经有了答案。
然而，针对任意特定改进从头开始改变公司是项令人畏惧的工程。事实上，自下而上的变化需要一本专门的书来讨论，与本书的自上而下的主题是不同的。但是，如果希望改变的内容是本书中特别讨论的，那么最简单的方法，虽然不能保证有效果，是让这本书来做说服工作。下面是大致的步骤：
首先要做的是认识到公司（即高层决策人员）不希望在没有他们许可的情况下对公司进行节流。每天都会有人走进顶层决策者的办公室说：“老板，我有方法可以为公司节流10%。”所有老板会做的都是从那些建议中采取10项可以让公司的利润水平达到100％的建议。另一个可能发生的情况是不管下层员工提出的建议有没有价值，管理层从心理上就比较轻视这些建议。
为了摆脱这些障碍，开发者必须用以下方式进行：
- 让改进成为目标经理自己的想法；
- 改进带来的成功归功于目标经理。
开发人员或技术主管通过问目标经理及其同事问题开始这项工作。这些问题应该问的很随意，在茶水间，茶歇时间、下班后的停车场等场合。问这些问题的目的是为了找到什么是让目标经理晚上睡不着觉的苦恼事儿。什么是令人担忧的事情？总经理的愿景是什么？是什么在阻止这个愿景发生？技术负责人也应该试着找出什么事情可以让目标经理很好的取悦于他的老板。花一些时间做这个，也许是几个星期。
通过这些信息，制定一些汇总表概括这些调查。该表应小心避免对问题的牢骚和抱怨，仅仅专注于可以帮助解决技术负责人正在努力解决的问题的信息。
此后在另外的茶水间谈话中，技术负责人应该用这样的话术将这些想法引导给管理者：“嘿，老板，关于那天您提到的那个士气问题（或者是什么问题），这里有本书中提到了一些不寻常的想法可能有用。我很好奇您的看法。”然后把书给他。
永远不要直接让他读这本书。你的后续跟进可以用这样的问题：“我很好奇这本书中有什么内容让你感兴趣了？”
然后看看会发生什么。
技术负责人应该认识到，我之前提到的超负荷问题可能也困扰着目标经理。此外，目标经理可能受到一些他不能明说的限制，且这些限制可能会影响到目标的达成。向经理问询这本书的次数不能多于2次，再多就显得技术负责人像个抱怨者。如果在那之后没有得到回应，而问题本身又非常让人烦恼，就考虑换家公司吧。
InfoQ：高管应该如何与中层管理者合作，以获得改进？
Racko：中层管理人员往往以“现状”为导向。另一种说法是他们经常是从众的。因此，对应的战术是要让中层管理人员认为有一群人在支持正在提出的这个观点。这里的“一群人”指中层以上的管理人员和决策人员以及中层以下的工作人员。对于中层反对派，如果他们的上层和下层都支持正在提出的改变措施，那么中层管理者几乎也总是倾向于同意这些措施。对于超负荷的考虑也适用于中层管理者。作为调整，可将中层管理人员列入实施改进激励计划的一部分。奖励说服同级经理或下级员工等其他人进行改进的中层经理，这是种特别有效的奖励措施。
关于本书作者
Roland Racko有40余年担任信息技术顾问、讲师和导师的经历。他帮助瑞典、德国、东非、台湾、加拿大和美国的财富100强公司的许多软件团队管理软件项目的成功。他为几本电脑杂志撰写专栏，同时他的文章也被整理为两本著作。他的主要技能之一就是找出隐藏在表面问题背后的原因，帮助团队和管理人员以新颖且有用的方式理解是什么在阻止他们取得成功，然后带领他们采取必要的积极措施。您也可以通过Linkedin找到Racko。获取更多书籍下载资源，请点击。
查看英文原文：Q&A on the Book Timing Is Almost Everything
转自 http://www.infoq.com/cn/articles/book-review-timing-everything