當還是個少年的時候，我記得經(jīng)常會玩一些即時戰(zhàn)略游戲像X-COM, Civilization, 紅警之類的。

[[127293]]

這些游戲使用一種被稱作“戰(zhàn)爭迷霧”的機制。當玩家開始游戲的時候，他們被籠罩在一片黑暗中，而地圖隱藏其中。唯一可以看到你周遭情形的方法就是探索。當你移動的時候，越來越多的地圖就會展開在你面前。

這將玩家置于一種策略上的不利之處：他們不能看到附近的危險，障礙或者機會。每次成功的前進都需要一點兒運氣。

這種場景是不是聽著很熟悉？

“戰(zhàn)爭迷霧”是對當前程序員被要求工作情形的一個極好的比喻。他們被置于一個項目中，被要求完成某一特定模塊的代碼，但是他們對于這個任務之外的事情一無所知。

對程序員來說，看到“完整的游戲地圖”是非常重要的。對全局清楚地認識可以幫助他們做出更好的決定。這里列出一些他們可能會問的問題：

• 1. 我們?yōu)槭裁匆鲞@個項目？它是如何改善了客戶的生活？
• 2. 和這個項目相關(guān)的歷史代碼是什么樣的？
• 3. 這個項目會影響到該應用軟件的其他那些部分？
• 4. 這個項目會影響到我們生意的其他哪些部分？
• 5. 我們?nèi)绾蝸碓u估這個項目是否成功（或失?。?？

一旦他們可以看到這整個的布局，程序員就可以有目的的開始工作。他們不再是一臺機器里面的齒輪而是可以影響項目取得成功的參與者。

這也帶來巨大的激勵好處。Joe Stump總結(jié)為：

程序員通常不知道任務背后的問題，這意味著一些最富有創(chuàng)造力的思考者卻不能考慮到一個給定的目標可能會碰到的問題。

比如說，如果我是一個后端程序員，你告訴我要實現(xiàn)一個API，但我不知道為什么你需要這個接口。

但是如果我負責任，多很你聊一聊，我將會深入地圍繞這個問題思考，因為我將作為程序員的工作和企業(yè)的成功更具體的聯(lián)系了起來。

這突出了強調(diào)每個項目背后的愿景和使命的重要性。

• 愿景：我們?yōu)槭裁匆觯窟@將如何改變這個世界？
• 使命：目標是什么？我們需要在哪里完結(jié)？

一旦他們理解了愿景和使命，程序員們也成為了項目計劃過程中有價值的合作者。他們可以預見潛在的風險幫你避免犯一些代價高昂的錯誤。在這篇非常棒的文章中，Paul Boag描述了不讓程序員參加需求設計會議的危險：

在Digg的全盛時期，我記得在Daniel Burka（掘客的***設計師）和Joe Stump（***程序員）的一段對話。他們講了這么一個故事，Daniel想要改變Digg的按鈕設計，從他的角度來說，這個改動微乎其微。但是當他和Joe說起的時候，他發(fā)現(xiàn)這個極小的改動可能會對網(wǎng)站的性能有非常大的影響，可能會迫使Digg升級它的處理能力和服務器架構(gòu)。

應該怎么做

在Sprintly公司，來自產(chǎn)品，支持和工程技術(shù)方面的代表會一起開會制定開發(fā)計劃。

會后，我們會創(chuàng)建一個Sprintly標準規(guī)格的需求書，包含我們在之后的三個月中將要做的事情。這份需求書會寄給所有的開發(fā)團隊，他們需要在工作開始前簽署同意。

經(jīng)理不是將軍，程序員也不是士兵

有時候經(jīng)理表現(xiàn)的好像每個項目都是秘密活動，信息只有在需要知道的基礎上才能給予。這個維基條目清楚地解釋了為什么這種情況可能發(fā)生：

需知（諸如其他保密措施）會被一些人誤用，這些人希望拒絕其他人知曉他所知道的信息，試圖增加他們的個人權(quán)力或者阻礙對他們工作的回顧。

這種保護主義并不會生成更好的代碼，項目或者增長的銷售額。不要將程序員置于黑暗中。邀請他們參與到你的整個策略制定中。

注：Justin Abrahms寫了一篇非常精彩的姐妹篇，The Omission of Why.

如果你正尋找一個好的框架來保持產(chǎn)品團隊負責，可以查閱Jason Evanish的product thesis.

祝好！