不知道各位有沒有玩過魔獸、X-COM、文明帝國、紅色警戒之類的策略遊戲。
這些遊戲使用了所謂的“戰爭迷霧”。剛進入遊戲的時候，每一個玩家的地圖都是被黑暗籠罩的，想要前行的唯一途徑就是不斷的摸索。隨着我們不斷地移動，地圖越來越可見化。
這種戰略的劣勢是：玩家看不到周圍的危險、障礙以及機會。每一次的成功都需要一點點的運氣。
有木有感覺這種情景有點熟悉？
“戰爭迷霧”完美地形容了開發人員的工作處境。他們總是被要求去搞定某一段特定的代碼，但是卻不告知任務的相關情況，等於是在讓他們自己在黑暗中摸索。
對於開發人員，看到“整個的遊戲地圖”很有必要。對全局有一個清晰的把握有助於他們做出正確的決策。下面這些問題是他們所需要知道的：
爲什麼要創建這個功能？它爲客戶提供了哪些方便？
圍繞這個功能的代碼經歷了怎麼樣的一個發展過程？
此功能會影響應用程序的其他哪些部分？
這是否會影響業務的其他部分？
我們如何衡量這個項目的成功（或失敗）？
當開發人員掌握整個框架之後，纔能有針對性地開始工作。他們的深思熟慮謀定而後動非常有助於項目的成功。
同時也有巨大的激勵效應。Joe Stump 總結道：
開發人員對於任務背後的問題往往得自己摸索，這意味着對於給定的對象可能開發人員並不能真正地思考到點子上。
但是如果夠負責的話，開發人員會沉浸於這個問題的思考，因爲其工作具體說來，更爲依賴於在商業上的成功。
舉個例子，如果我是後端開發人員，你告訴我去實現一些 API 端點，我需要考慮一下爲什麼你需要這些端點。
這突顯了了解每個項目背後的目的和任務的重要性：
目的：我們爲什麼要這麼做？
任務：目標是什麼？做到怎麼樣的程度算完成？
在瞭解了目的和任務之後，開發人員也就成爲了規劃進程中有價值的合作伙伴。他們可以預見一些潛在的“地雷”，以免你踩到從而付出高昂的代價。在一篇雜誌文章中，Paul Boag 描述了將開發人員摒棄在一些相關會議之外的危險：
在 Digg 的鼎盛時期，Daniel Burka（Digg 的首席設計師）和 Joe Stump（其主要開發人員）之間就一個 Digg 按鈕曾舉行過一次會議討論。Daniel 想要更改其設計，因爲從他的角度看，變化不大。但是對於 Joe 來說，他發現這個小設計將會對網站的性能產生很大的影響，迫使 Digg 因爲這麼一個按鈕而升級它的處理能力和服務器架構。
你能做什麼
首先我們應該負責任地參與到產品、支持和工程規劃的會議討論中去。
並可以提出自己有建設性的建議，除了應用開發人員，很少會有人注意到應用開發的安全性問題，這時就需要程序員根據自己的經歷、經驗、以及相關研究所得出的結論：藉助專業的第三方安全平臺——移動應用安全智能服務提供商，來達到保護的目的！
會後，我們可以創建接下來所需要的有關規範文件。
管理人員不是將軍，開發人員也不是戰士
有時候，管理人員搞的好像這個項目是什麼緊要機密一樣，只給出一些“需要知道的基礎知識”。
但是這種保護措施卻不會導致更好的代碼、更受歡迎的項目，也不會增加銷售。不要讓開發人員在黑暗中摸索，應該邀請他們一起參與到整體的戰略討論中來。