当还是个少年的时候，我记得经常会玩一些即时战略游戏像X-COM, Civilization, 红警之类的。
这些游戏使用一种被称作“战争迷雾”的机制。当玩家开始游戏的时候，他们被笼罩在一片黑暗中，而地图隐藏其中。唯一可以看到你周遭情形的方法就是探索。当你移动的时候，越来越多的地图就会展开在你面前。
这将玩家置于一种策略上的不利之处：他们不能看到附近的危险，障碍或者机会。每次成功的前进都需要一点儿运气。
这种场景是不是听着很熟悉？
“战争迷雾”是对当前程序员被要求工作情形的一个极好的比喻。他们被置于一个项目中，被要求完成某一特定模块的代码，但是他们对于这个任务之外的事情一无所知。
对程序员来说，看到“完整的游戏地图”是非常重要的。对全局清楚地认识可以帮助他们做出更好的决定。这里列出一些他们可能会问的问题：
- 1. 我们为什么要做这个项目？它是如何改善了客户的生活？
- 2. 和这个项目相关的历史代码是什么样的？
- 3. 这个项目会影响到该应用软件的其他那些部分？
- 4. 这个项目会影响到我们生意的其他哪些部分？
- 5. 我们如何来评估这个项目是否成功（或失败）？
一旦他们可以看到这整个的布局，程序员就可以有目的的开始工作。他们不再是一台机器里面的齿轮而是可以影响项目取得成功的参与者。
这也带来巨大的激励好处。Joe Stump总结为：
程序员通常不知道任务背后的问题，这意味着一些最富有创造力的思考者却不能考虑到一个给定的目标可能会碰到的问题。
比如说，如果我是一个后端程序员，你告诉我要实现一个API，但我不知道为什么你需要这个接口。
但是如果我负责任，多很你聊一聊，我将会深入地围绕这个问题思考，因为我将作为程序员的工作和企业的成功更具体的联系了起来。
这突出了强调每个项目背后的愿景和使命的重要性。
- 愿景：我们为什么要做？这将如何改变这个世界？
- 使命：目标是什么？我们需要在哪里完结？
一旦他们理解了愿景和使命，程序员们也成为了项目计划过程中有价值的合作者。他们可以预见潜在的风险帮你避免犯一些代价高昂的错误。在这篇非常棒的文章中，Paul Boag描述了不让程序员参加需求设计会议的危险：
在Digg的全盛时期，我记得在Daniel Burka（掘客的首席设计师）和Joe Stump（首席程序员）的一段对话。他们讲了这么一个故事，Daniel想要改变Digg的按钮设计，从他的角度来说，这个改动微乎其微。但是当他和Joe说起的时候，他发现这个极小的改动可能会对网站的性能有非常大的影响，可能会迫使Digg升级它的处理能力和服务器架构。
应该怎么做
在Sprintly公司，来自产品，支持和工程技术方面的代表会一起开会制定开发计划。
会后，我们会创建一个Sprintly标准规格的需求书，包含我们在之后的三个月中将要做的事情。这份需求书会寄给所有的开发团队，他们需要在工作开始前签署同意。
经理不是将军，程序员也不是士兵
有时候经理表现的好像每个项目都是秘密活动，信息只有在需要知道的基础上才能给予。这个维基条目清楚地解释了为什么这种情况可能发生：
需知（诸如其他保密措施）会被一些人误用，这些人希望拒绝其他人知晓他所知道的信息，试图增加他们的个人权力或者阻碍对他们工作的回顾。
这种保护主义并不会生成更好的代码，项目或者增长的销售额。不要将程序员置于黑暗中。邀请他们参与到你的整个策略制定中。
注：Justin Abrahms写了一篇非常精彩的姐妹篇，The Omission of Why.
如果你正寻找一个好的框架来保持产品团队负责，可以查阅Jason Evanish的product thesis.
祝好！
来源：51CTO
