碼農是如何煉成的 Vol.5

今天說說有關需求的問題，可能有的人會說我是個碼農，需求是產品或者運營的事，與我有毛線關係。

我不太清楚像BAT這類大公司的碼農，他們須要對產品和用戶需求會有多深的瞭解，但我認爲一個碼農，必需要儘量瞭解客戶或用戶需求，也就是你在乾的這個事解決了什麼問題。

不是我看不起作需求工做的同志，但在實際工做中因爲決策層面的影響，常常會致使派沒有掌控需求能力的人去負責需求工做，其最主要的問題就在於需求理解錯位或深層次的需求沒法挖掘。

你不能期望客戶或者用戶懂產品，他們想要A說出B，對他們來講再正常不過，但若是最後程序員也按B作，那就完蛋了。

另外一個問題是沒有能力過濾掉不合理的需求，這個比較麻煩，你既然敢去說NO，就必須給出足夠的說NO的理由，更牛逼的是要作到讓對方以爲你說NO其實是站在他的角度上幫他在考慮問題。

這個真不是剛工做1-2年的小朋友能作的。

其實我也知道，真讓碼農去作需求估計在通常公司基本不可能，但這確實是提高本身的最好途徑之一。

能身臨第一線掌握到用戶真正須要什麼，用本身的專業知識與分析能力告訴用戶哪些是他們真正想要的，哪些對他們來講只是吃力不討好，是不可取的。

可能一開始你沒有這種能力，但若是坐在屋子裏聽一生非專業人轉述的需求，那就永遠沒有這種能力。我在此只是想告訴你們一種快速進步的方式，至於如何得到機會，看造化和努力吧。

我以前提過，業務專家與碼農結合，絕對是1+1大於2的，說實話，對一個系統的熟悉程度，使用者絕對比不上一行代碼一行代碼敲出來的碼農。

早些年一個朋友跟我說的一件事：有個集團的信息總監曾經爲了制定數據採集議的軟件需求，去當了半個月走南闖北的銷售人員。

回來後說了一句話：普通業務員每天在來回跑，他們跑兩年也就是那麼一回事；而我只要跑半個月，就已經徹底明白了到底他們須要什麼。

這就是一個擁有典型程序員思惟的人與實際客戶的業務人員之間最本質的區別——思考。思考是程序員的特質之一，其很大一部分增加都是藉助於接觸客戶需求實現的。

固然，你們也不要期望剛開始工做就有接觸業務需求的機會，仍是得先把代碼寫好，再說這一步的事。下一章開始講寫代碼。