忽视了承诺管理 

　　当我使用Amazon.com的搜索引擎对“承诺管理”进行关键字搜索时，我发现仅有极少量关于这方面的出版物且没有一个具有代表性。接着我再使用相同的搜索引擎对“承诺”进行关键字搜索，发现了超过170，000本相关书籍，但大部分与男女之间关系（如婚姻）的承诺有关。Watts S.Humphrey是CMM的发明者，如果你读过他的书《软件工程过程》和《个人软件过程》，你将会发现他对“承诺管理”的描述是相对表面的。

　　由于对承诺管理缺乏重视和教育，以下的承诺管理问题在软件/IT项目开发中随处可见。让我们先来看看“我会尽我最大的努力”这句话是不是承诺。假如老板对下属说：“你能在星期五前交付X项目给我吗？”，很多下属会回答说“我会尽我最大的努力”。但这同一句话所隐含的对上司的承诺程度是不一样的。下属A也许就是“一定做到”的意思，而下属B承诺背后的意思实际上是“不能保证”，下属C嘴上说“尽力”但结果多数会延迟。“我会尽我最大的努力”常常被错误地当作是“做得到”的坚定承诺，这种开始时便含糊的承诺，往往带来日后的惊讶和失望。

　　进一步的问题是，呈交计划书是否等于对自己所写的计划做出承诺？有的人呈交计划书，最多只是表示他在交计划书时是“同意”计划书所写的交付期限，但并没有资料显示迟些时候他会“不同意”。此外，也没有足够的资料显示他做足了功课，充分地明白了项目需要的资源和时间，准确地评估了自己的能力。他不是判定自己有能力控制工作的复杂程度，才呈交计划书。假如呈交的计划书有部分或全部是他人所写，事情则会更复杂。然而通常的情况是呈交计划书被当作是“做得到”的承诺，这种一开始就不清晰的承诺却给软件/IT界带来不少失败的结果。

　　承诺管理的重要性及可行模式 

　　软件/IT公司的成本限制模式与工厂一样，要求准时交货且不能超出预算，但其生产却与工厂不一样，极其依赖智力工作者。由于智力工作者的产出率和产出质量是不容易度量的，甚至不适合以数字来形容，故管理智力工作者的承诺是相当重要的，不然软件/IT公司是管无可管，完全超出控制之外。

　　由于软件/IT的工作中有成千上万要依赖或互相依赖的东西，而它们中任何一个，都能成为今日的“推诿”或明日的“借口”。假设A问B：“你可以在星期五前交付项目X吗？”B可能会有如下的借口：回答一为“我可以，但我需要倚赖C做Y”；回答二为“我可以，但如果C会迟的话，我也可能会迟”；回答三为“我可以，但C一定要在星期三前把Y交给我”。B在这种情况下很容易用C或者Y来做借口，若A要确保B成功，他必须同时管理B和C。除此之外，B甚至可以将责任推诿到上班所乘的公交车上，所能发生的偶然和必然事件都成为了B无法兑现承诺的借口。因此，如果A不懂得加强团队的自我管理，就会陷入追踪项目里的每一样东西的局面。故在设计承诺管理模式的时候，一定要以自我管理为主，确保每一个要依赖的东西都由最适合的团队成员负责。

　　在此，我描述一个我多年实践出来的承诺管理模式，该模式包括以下三个互相联系的要素：

　　1. 理解和评估；

　　2. 协议和沟通；

　　3. 后果。

　　首先，智力工作者要对自己的能力做一个自我判断，包括判断自己的产出能力、管理他人产出的能力以及管理自己依赖物的能力是否适合管理所要承诺项目的复杂性（智力工作者能否准确地评估当然与他对自己及项目的明白程度有关。一旦承诺做出，当事人将要让他的老板、同事以及其需要依赖的人清楚这个承诺。仍以A、B为例，当A给B分派一项任务的时候，B要对A做出一个完成任务的承诺，但这个承诺与简单的口头表述和单纯呈交计划书不同，B要具备承诺管理的意识。他首先要对自己完成任务的能力做出一个客观准确的判断，不仅如此，他还必须分析自己的工作需要依赖哪些资源（如同事的工作进度和其他公司的协助等），以及如何管理这些资源才能保证自己任务的完成。此外，B 还要考虑到影响任务完成的客观外界因素，如交通情况和家庭问题等。在这样一个对自身充分了解和判断的基础上，B才能向A做出真正的有意义的“承诺”。在他人知晓了B的承诺后，以往的不可控因素都会有所减少。

　　上述的承诺管理模式是如下管理方式的混合，包括对运作类型的管理、生产线的管理以及创造性的管理。它能将软件公司特有的机械和动态的管理方式结合起来，换句话说，为动态的智力型工作者提供了一个可控的承诺方式。

　　该承诺管理模式的好处在于团队成员之间靠真正的承诺来进行合作，即使是一个新的成员，也能名正言顺地从其他团队成员那里获得适当的承诺。承诺一旦做出，成员们就很难再为任务的拖延找到借口，因为这些承诺都是在对自我判断自我管理的基础上建立起来的。同时，在这种管理方式下，成员们也可以发现成员中谁对自己的判断经常出错，从而更好地建立督促和淘汰机制。