程序員的生產力始于需求而非工具

Marco Behler是一位資深開發者與市場營銷人員，同時也是Marco Behler GmbH的創始人。近日，Behler就程序員生產力這一話題展開 論述 ，在社區產生了較大的影響。

你真的知道影響程序員生產力的關鍵因素是什么嗎？是VIM、Emacs、最新的Haskell Web框架，還是鐘愛的NoSQL數據庫呢？遺憾的是，如果你將關注點放在工具、框架或是流程上，那就說明你還是沒有真正理解這個問題。我認為，影響程序員生產力的關鍵因素在于起點：恰當的需求。

作為開發者緣何要關注需求，這難道不是業務人員的事情？

當然了，創始人/產品經理/團隊領導必須要關注這個問題：到底開發什么才能讓客戶最終埋單呢？但如果從開發者的視角看待這個問題會是怎樣的呢？有時會出現這樣的情況，有人拍打桌子，大叫：現在就開始開發XYZ，馬上，立刻，如果中間出現問題，我們可以在開發過程中解決，這就叫做先發優勢？其實，我們稱之為：盡快開始，但永遠不會結束。很有可能你所開發的一半以上的東西都是不清晰的。

你怎么知道自己完成了？

意料之中的，如果不能完全理解需求，那就會導致遺漏，當問起什么時候能夠開發完，你可能會忘記這個，忘記那個。那么該如何測試不清晰的需求呢？這與你喜歡的BDD工具沒有任何關系。如果輸入不清晰，那么測試也不會清晰，輸出就更不清晰了。

你總是自我激勵，對嗎？

不過更糟糕的是，頻繁的不清晰的需求是個信號，表示業務人員不確定客戶到底想要什么。遺憾的是，這也表示你所開發的很多工作都是徒勞無益的。如果這種情況頻繁出現，就會對程序員的生產力造成很大的破壞，這將嚴重影響程序員的效率。

到底什么才是恰當的需求？

那么什么才是恰當的需求呢？我認為恰當的需求的制定過程應該是下面這個樣子的：

• 需要業務人員與程序員共同討論，并且經過雙方充分的溝通
• 需要不斷拆解、拆解、再拆解
• 不斷打磨，經得起推敲

我是個程序員，需求的事與我無關？

誠然，在大型組織中可能會有專門的業務分析師，他們的主要工作就是在將詳細的需求規范傳遞給實現團隊之前對其進行不斷的完善。在理想情況下，這么做是完美無缺的，你只需坐在那兒編寫代碼就行，不過實際情況卻并非如此。

無論怎樣，組織的規模越小，程序員需要處理的事情就越多。公司的創始人可能會拍著桌子大喊：作為程序員的你不僅要負責實現，還要關注需求的產生過程。

無論怎樣，你都應該成為一名專家

對于你來說，可能閱讀AngularJS 2.0的升級路徑要比與客戶討論領域問題和需求更有趣。不過，我想說的是，你的技術、對框架或算法的理解只是你每天工作的一部分。對于所有開發工作來說，基礎則是“恰當的需求”。

Behler的文章刊出后很快就引起了眾多開發者的共鳴，很多人也紛紛表達了自己的觀點，下面摘錄出一些典型反饋以饗讀者：

Sasi Pallekonda說到：

說得太棒了！開發者不僅要考慮該使用什么數據結構，還需要思考需求是如何匹配最終用戶的，并且如何實現需求，讀了Behler的文章獲益匪淺。

Erik Gollot說到：

非常同意文中的觀點，我現在對如何編寫好的需求非常感興趣，因為根據我的經驗，用戶故事是遠遠不夠的。

Wes Higbee說到：

非常同意Behler的看法，對此我也做了深刻的思考，我認為：方向要比速度更為重要，只有確定了方向，速度才是有意義的，否則再快的速度也是徒勞無益的。

Jussi Laasonen說到：

很多時候，人們都認為敏捷軟件開發只不過是“立刻開始構建XYZ”，但事實上，這么做是完全錯誤的。

Fayez Naccache說到：

我已經在我們稱之為精益創業的組織中工作6個多月了。在這期間，我們沒有計劃、沒有詳細需求、沒有你所說的恰當的需求。我覺得工作起來非常困難，一點動力都沒有。我很喜歡文中的這句話：盡快開始，但永遠不會結束；還有無論怎樣，組織的規模越小，程序員需要處理的事情就越多。這對我現在的工作來說真是再恰當不過的描述了。

Eliseu Monar說到：

Behler關于程序員生產力的文章引起了很多人的共鳴，同時他也專門編寫了一本名為 Customer Requirements 的圖書。該書主要介紹了需求溝通的技巧、如何恰當地進行估算、如何防止模糊不清的需求產生、如何與同事和客戶溝通需求、恰當合理的需求對于開發與測試會產生哪些積極影響，同時每一章都提供了實際的例子供大家參考。

程序員生產力這一話題是每一個開發人員都津津樂道的，那么對于你來說，影響生產力的因素都有哪些呢，不妨分享出來我們一同討論。