不知道各位有没有玩过魔兽、X-COM、文明帝国、红色警戒之类的策略游戏。

这些游戏使用了所谓的“战争迷雾”。刚进入游戏的时候，每一个玩家的地图都是被黑暗笼罩的，想要前行的唯一途径就是不断的摸索。随着我们不断地移动，地图越来越可见化。

这种战略的劣势是：玩家看不到周围的危险、障碍以及机会。每一次的成功都需要一点点的运气。

有木有感觉这种情景有点熟悉？

“战争迷雾”完美地形容了开发人员的工作处境。他们总是被要求去搞定某一段特定的代码，但是却不告知任务的相关情况，等于是在让他们自己在黑暗中摸索。

对于开发人员，看到“整个的游戏地图”很有必要。对全局有一个清晰的把握有助于他们做出正确的决策。下面这些问题是他们所需要知道的：

• 为什么要创建这个功能？它为客户提供了哪些方便？
• 围绕这个功能的代码经历了怎么样的一个发展过程？
• 此功能会影响应用程序的其他哪些部分？
• 这是否会影响业务的其他部分？
• 我们如何衡量这个项目的成功（或失败）？

当开发人员掌握整个框架之后，才能有针对性地开始工作。他们的深思熟虑谋定而后动非常有助于项目的成功。

同时也有巨大的激励效应。Joe Stump 总结道：

开发人员对于任务背后的问题往往得自己摸索，这意味着对于给定的对象可能开发人员并不能真正地思考到点子上。

但是如果够负责的话，开发人员会沉浸于这个问题的思考，因为其工作具体说来，更为依赖于在商业上的成功。

举个例子，如果我是后端开发人员，你告诉我去实现一些 API 端点，我需要考虑一下为什么你需要这些端点。

这突显了了解每个项目背后的目的和任务的重要性：

• 目的：我们为什么要这么做？
• 任务：目标是什么？做到怎么样的程度算完成？

在了解了目的和任务之后，开发人员也就成为了规划进程中有价值的合作伙伴。他们可以预见一些潜在的“地雷”，以免你踩到从而付出高昂的代价。在一篇杂志文章中，Paul Boag 描述了将开发人员摒弃在一些相关会议之外的危险：

在 Digg 的鼎盛时期，Daniel Burka（Digg 的首席设计师）和 Joe Stump（其主要开发人员）之间就一个 Digg 按钮曾举行过一次会议讨论。Daniel 想要更改其设计，因为从他的角度看，变化不大。但是对于 Joe 来说，他发现这个小设计将会对网站的性能产生很大的影响，迫使 Digg 因为这么一个按钮而升级它的处理能力和服务器架构。

你能做什么

首先我们应该负责任地参与到产品、支持和工程规划的会议讨论中去。

会后，我们可以创建接下来所需要的有关规范文件。

管理人员不是将军，开发人员也不是战士

有时候，管理人员搞的好像这个项目是什么紧要机密一样，只给出一些“需要知道的基础知识”。

但是这种保护措施却不会导致更好的代码、更受欢迎的项目，也不会增加销售。不要让开发人员在黑暗中摸索，应该邀请他们一起参与到整体的战略讨论中来。