转载

游戏中的“战争黑雾”和现实中的程序员处境

英文原文： Don’t leave developers in the dark

当还是个少年的时候，我记得经常会玩一些即时战略游戏像 X-COM , Civilization , 红警之类的。

这些游戏使用一种被称作“战争迷雾”的机制。当玩家开始游戏的时候，他们被笼罩在一片黑暗中，而地图隐藏其中。唯一可以看到你周遭情形的方法就是探索。当你移动的时候，越来越多的地图就会展开在你面前。

这将玩家置于一种策略上的不利之处：他们不能看到附近的危险，障碍或者机会。每次成功的前进都需要一点儿运气。

这种场景是不是听着很熟悉？

“战争迷雾”是对当前程序员被要求工作情形的一个极好的比喻。他们被置于一个项目中，被要求完成某一特定模块的代码，但是他们对于这个任务之外的事情一无所知。

对程序员来说，看到“完整的游戏地图”是非常重要的。对全局清楚地认识可以帮助他们做出更好的决定。这里列出一些他们可能会问的问题：

我们为什么要做这个项目？它是如何改善了客户的生活？
和这个项目相关的历史代码是什么样的？
这个项目会影响到该应用软件的其他那些部分？
这个项目会影响到我们生意的其他哪些部分？
我们如何来评估这个项目是否成功（或失败）？

一旦他们可以看到这整个的布局，程序员就可以有目的的开始工作。他们不再是一台机器里面的齿轮而是可以影响项目取得成功的参与者。

这也带来巨大的激励好处。Joe Stump 总结为：

程序员通常不知道任务背后的问题，这意味着一些最富有创造力的思考者却不能考虑到一个给定的目标可能会碰到的问题。

比如说，如果我是一个后端程序员，你告诉我要实现一个 API，但我不知道为什么你需要这个接口。

但是如果我负责任，多很你聊一聊，我将会深入地围绕这个问题思考，因为我将作为程序员的工作和企业的成功更具体的联系了起来。

这突出了强调每个项目背后的愿景和使命的重要性。

愿景：我们为什么要做？这将如何改变这个世界？
使命：目标是什么？我们需要在哪里完结？

一旦他们理解了愿景和使命，程序员们也成为了项目计划过程中有价值的合作者。他们可以预见潜在的风险帮你避免犯一些代价高昂的错误。在这篇非常棒的文章中，Paul Boag 描述了不让程序员参加需求设计会议的危险：

在 Digg 的全盛时期，我记得在 Daniel Burka（掘客的首席设计师）和 Joe Stump（首席程序员）的一段对话。他们讲了这么一个故事，Daniel 想要改变 Digg 的按钮设计，从他的角度来说，这个改动微乎其微。但是当他和 Joe 说起的时候，他发现这个极小的改动可能会对网站的性能有非常大的影响，可能会迫使 Digg 升级它的处理能力和服务器架构。