2.1　对抗角色

本书的某位审校者很讨厌这一章，他说自己差点因为本章而丢下这本书。在他组建过的团队中，从未出现过对抗关系。整个团队总是能和谐共事，没发生过什么矛盾。

我为他感到高兴，但是我怀疑他的那些团队是否真像他自己以为的那样毫无矛盾。如果真是如此，我很怀疑那些组员是否真能够有效工作。我的个人经验告诉自己，面对艰难决定，直面不同角色的冲突是最好的办法。

每位经理都承担着工作职责，绝大部分经理也知道该如何尽职尽责。其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。

同样，程序员也自有其工作职责所在，绝大多数程序员也知道该如何出色地尽职尽责。如果他们是专业程序员的话，他们也会竭尽所能地去追求和捍卫自身的目标。

你的经理要求你在明天之前完成登录页面，这就是他在追求和捍卫的一个目标，那是尽他的工作职责。如果你明知第二天之前不可能完成登录页面，嘴上却说“好的，我会试试的”，那么便是你失职了。这时候，尽职的唯一选择是说“不，这不可能”。

可是难道你不该照经理说的话去做吗？当然不该，你的经理指望的是，你能像他那样竭尽所能地捍卫自己的目标。这样你们俩才能得到可能的最好结果。

可能的最好结果，是你和你的经理共同追求的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。

协商过程有时可以相当愉快。

Mike：“Paula，你在明天之前要完成那个登录页面。”

Paula：“噢，喔！要那么快啊？那好吧，我会尽量试试。”

Mike：“好极了！谢谢！”

这是段轻松的小对话。没有任何冲突。双方都微笑着离开。一派和谐。

但是双方表现得都不够专业。完成“登录页面”所需时间绝不止一天，Paula对此心知肚明，她这么回答无异于撒谎。她或许不觉得这是什么谎言。或许她觉得自己真的会去努力尝试，而且或许她真对按时完成抱着些微薄的希望。但到最后，这仍只会是个谎言。

另一方面，Mike把“我会尽量试试”当作了“好的，没问题”。这无异于自欺欺人。他本该明白那只是Paula在尽量避免和他产生正面冲突，因此他应该进一步确认：“你看起来有些犹豫。你确信明天能完成吗？”

下面是另一个轻松愉快的对话。

Mike：“Paula，你在明天之前要完成那个登录页面。”

Paula：“噢，抱歉Mike，这么短时间完成不了的。”

Mike：“那你觉得什么时候能完成呢？”

Paula：“再过两周怎么样？”

Mike：（在他的本子上记了几笔）“好的，谢谢。”

这样对话确实轻松，但其中的问题也很严重，大家表现得极不专业。双方都没尝试寻求最佳的可能结果。Paula不该问两周是否可以，而应该更坚定地说：“Mike，这个活需要两周才能完成。”

另一方面，Mike毫无异议就接受了这个日期，仿佛他自己的目标无关紧要似的。这也不免让人猜想他是不是会直接向老板报告——由于Paula的原因，客户的demo将不得不推迟。这种消极对抗的做法应该受到谴责。

在这些例子中，双方均未尝试寻求可接受的共同目标。双方均未努力寻求最佳的可能结果。我们再来看下面的这个对话。

Mike：“Paula，你在明天之前要完成那个登录页面。”

Paula：“不，Mike，这个活要两周才能完成。”

Mike：“两周？架构师估计这只要3天，而你已经花了5天时间了！”

Paula：“架构师们错了，Mike。他们是在接到产品销售需求前做的预估。我至少还需要10天才能做完。你没看到我在wiki上更新的预估吗？”

Mike：（表情严肃、沮丧得发抖）“Paula，这可不行。客户明天就要来看demo了，我必须向他们展示个能用的登录页面。”

Paula：“明天你需要登录页面的哪部分能用？”

Mike：“我要整个登录页面！必须要能登录。”

Paula：“Mike，我可以给你做一个能登录的假页面。这个现在就已经可以。但是页面不会检查用户名和密码。如果你把密码忘记了，也还没办法发邮件告诉你。页面顶部也还不能像时代广场的大屏幕那样有新闻栏在滚动，帮助按钮和浮出说明都还不能用，它没法为你保存cookie以便下次登录，也不会设定任何权限限制。但你确实可以登录。你看这样可以吗？”

Mike：“我可以登录？”

Paula：“是的，可以登录。”

Mike：“好极了，Paula，你真是个大救星。”（松了口气，说了声“太棒了！”，走开了。）

在这个例子里，他们达成了最佳的可能结果。他们各表异议相互说“不”，然后找到了双方都能接受的解决方案。他们的表现是专业的。对话中虽稍有冲突，也有片刻不愉快发生，但如果双方坚持追求的目标不能完美切合时，这是比较理想的情况。

“为什么”重要吗

或许你觉得Paula应该解释下为什么“登录页面”还要花那么长时间才能完成。我的经验是，“为什么”远不如“事实”重要。事实是，“登录页面”还需要两周才能完成。而为什么需要两周，则只是个细节。

尽管这样，知道“为什么”可能还是会有助Mike了解并接受事实。那是最好不过的了。如果Mike恰好有技术背景和好脾气去倾听理解，这些解释也许会有用。另一种情况则是，Mike可能会不认同Paula的结论，他可能会觉得Paula的做法不对，他可能会告诉她不用做完整的测试和代码审查，或者可以把第12步省略掉，诸如此类。有时候，提供太多细节，只会招致更多的微观管理。