程式設計師的生產效率源於需求，而不是工具！

你確定你真的知道到底是什麼促使一個程式設計師高效率的嗎？是因為使用了 VIM 和 Emacs 這些強大的編輯器，還是因為應用了最新的 Haskell Web 框架，抑或是你最喜歡的 NoSQL 資料庫？
很抱歉，如果你注重的是工具、框架，甚至是程式，那麼我不得不說，你搞錯了！程式設計師生產效率的真正起源是：正確的需求。

為什麼你作為一名程式設計師也必須關心需求——而不僅僅是業務人員！
顯然，產品負責人必須滿足客戶的需求，因為這樣才能讓客戶心甘情願地付出報酬。對此，開發人員又是怎麼看的呢？
曾經有位開發人員說出了大多數人的心聲：“直接構建。出現了問題，就放到開發過程中處理。這樣，至少我們開了一個頭，不是嗎？“
我們將這種做法稱之為：馬上啟動，永不結束——一開始構建的時候沒有什麼準確的目標，至少有一半的內容是尚不清楚的。

你怎麼知道你已經搞定了？
由於並不是 100％ 瞭解，所以在開發過程中狀態百出——不知道接下來該做什麼，自以為快完成了卻這裡忘記了，那裡有遺漏，功能不匹配，等等等等。
再問一句，請問你打算如何去測試模糊不清的需求呢？對此，你最喜歡的 BDD 工具可是束手無策的哦。
如果輸入是不明確的，測試也是不明確，那麼輸出就更加不明確了。

你總是特別有積極性，可能嗎？
所有開發人員都非常討厭的一種情況是，業務人員頻繁地給出不確定的需求。這表明業務人員本身也不知道客戶真正想要什麼功能。
而這也意味著，很多你構建的東西會被棄之於垃圾桶。一鼓作氣，再而衰，三而竭，程式設計師的積極性就是這樣給磨滅的。

那麼什麼樣的才算是正確的需求？
現在說說什麼樣的才是正確的需求？是不是一句寫在索引卡上的話——“作為一個使用者我希望能夠使用亞洲建行信用卡”，好了，over，就 ok 了呢？
一個正確的需求包括（1）經過業務人員和程式設計師雙向的溝通和研究；（2）反覆解構，解構，再解構；（3）論證，其中包括我們常說的”angling“和”skinning“。

拜託！我是一個程式設計師，需求不是我的工作！
的確，在一些大型的公司中，通常會有專門的業務分析人員，其唯一的工作職責就是在遞交給實施團隊之前先整理出詳細的需求說明。在理想的情況下，你只要照著說明編碼就行了，但是，這在現實中顯然是不可能的。
而且，企業越小，程式設計師的工作就混雜。可能你的老闆就是這麼認為的：你，作為一個”程式設計師“不僅要知道怎麼實施，也應該清楚需求。

無論如何，你都應該專於此！
升級 AngularJS 2.0 路徑肯定比研究客戶的問題領域和需求要有趣的多——這是毋庸置疑的。
但是，你的技術技能，你的框架，還有你的演算法都只是你每天日常工作的一部分。而所有開發工作的依據卻是：正確的需求。
最後，歡迎分享你的感受。

英文原文：PROGRAMMER PRODUCTIVITY STARTS WITH REQUIREMENTS, NOT TOOLS!
譯文連結：http://www.geekwww.com/programmer-product-not-tools.html