不知道各位有没有玩过魔兽、X-COM、文明帝国、红色警戒之类的策略游戏。
这些游戏使用了所谓的“战争迷雾”。刚进入游戏的时候，每一个玩家的地图都是被黑暗笼罩的，想要前行的唯一途径就是不断的摸索。随着我们不断地移动，地图越来越可见化。
这种战略的劣势是：玩家看不到周围的危险、障碍以及机会。每一次的成功都需要一点点的运气。
有木有感觉这种情景有点熟悉？
“战争迷雾”完美地形容了开发人员的工作处境。他们总是被要求去搞定某一段特定的代码，但是却不告知任务的相关情况，等于是在让他们自己在黑暗中摸索。
对于开发人员，看到“整个的游戏地图”很有必要。对全局有一个清晰的把握有助于他们做出正确的决策。下面这些问题是他们所需要知道的：
为什么要创建这个功能？它为客户提供了哪些方便？
围绕这个功能的代码经历了怎么样的一个发展过程？
此功能会影响应用程序的其他哪些部分？
这是否会影响业务的其他部分？
我们如何衡量这个项目的成功（或失败）？
当开发人员掌握整个框架之后，才能有针对性地开始工作。他们的深思熟虑谋定而后动非常有助于项目的成功。
同时也有巨大的激励效应。Joe Stump总结道：
开发人员对于任务背后的问题往往得自己摸索，这意味着对于给定的对象可能开发人员并不能真正地思考到点子上。
但是如果够负责的话，开发人员会沉浸于这个问题的思考，因为其工作具体说来，更为依赖于在商业上的成功。
举个例子，如果我是后端开发人员，你告诉我去实现一些API端点，我需要考虑一下为什么你需要这些端点。
这突显了了解每个项目背后的目的和任务的重要性：
目的：我们为什么要这么做？
任务：目标是什么？做到怎么样的程度算完成？
在了解了目的和任务之后，开发人员也就成为了规划进程中有价值的合作伙伴。他们可以预见一些潜在的“地雷”，以免你踩到从而付出高昂的代价。在一篇杂志文章中，Paul Boag描述了将开发人员摒弃在一些相关会议之外的危险：
在Digg的鼎盛时期，Daniel Burka（Digg的首席设计师）和Joe Stump（其主要开发人员）之间就一个Digg按钮曾举行过一次会议讨论。Daniel想要更改其设计，因为从他的角度看，变化不大。但是对于Joe 来说，他发现这个小设计将会对网站的性能产生很大的影响，迫使Digg因为这么一个按钮而升级它的处理能力和服务器架构。
你能做什么
首先我们应该负责任地参与到产品、支持和工程规划的会议讨论中去。
会后，我们可以创建接下来所需要的有关规范文件。
管理人员不是将军，开发人员也不是战士
有时候，管理人员搞的好像这个项目是什么紧要机密一样，只给出一些“需要知道的基础知识”。
但是这种保护措施却不会导致更好的代码、更受欢迎的项目，也不会增加销售。不要让开发人员在黑暗中摸索，应该邀请他们一起参与到整体的战略讨论中来。
