|
|
通過反復的交談，Bill Caputo最終說服了我，讓我相信了一些不可思議的事情。這些事情改變了我整個看問題的方式，也讓我重新思考如何更好的工作。
軟件開發中沒有“生產效率”。
幾乎正如10年前 Martin Fowler 發現的，用生產效率來衡量軟件開發工作沒有任何意義。原因就在于，它們不屬于同一范疇。換句話說，生產效率不具有作為衡量軟件開發工作的適用性。“今天創造了多少代碼/軟件？”這是一個沒有意義的問題。即使可以這樣測量，軟件開發工作上的生產效率也不能以任何有意義的方式估計出它的商業價值。
這是因為，軟件開發這種工作并不一定非要生產出什么東西。讓我來舉個例子：比如說，碰巧有兩個程序員分別在開發兩個完全一樣的項目，他們在同一天被分配了相同的任務。第一個人，弗蘭克，回到電腦前，寫出了一個有1000行代碼的框架，完美的解決了問題。代碼規范書寫，全面測試，有詳細的文檔描述部署和操作的流程。第二個程序員，皮特，轉身去了公園，在哪里，他一邊喂鴿子一邊思考問題。大概在下午4：45分，皮特溜達回辦公室，刪掉了200行代碼，并部署了他的修改…問題就這樣解決了。
這兩個程序員，今天的“生產效率”誰的更高？答案是：這無關緊要。緊要的是，皮特解決了問題，同時為團隊消減了長期維護的成本。弗蘭克同時也解決了問題，但他因為生產了代碼，提高了維護成本，所以，(在其它方面完全等效的情況下)他的方案差一些。而把皮特稱作更有“生產效率”，則完全從實效性上扭曲了這個比喻。
我認為，優秀的程序員，他所做的事情應該是去除問題。而相對的則是生產出什么。所以，技術上的生產產物，例代碼，文檔，數據等，對于實現“去除問題”的目標來說，都是必要但有害的。這就是為什么有時候，這最有效的解決方案是5分鐘的交流溝通。
對這種思考模式最有力的支持：當你用這種思維去看待軟件開發后，很多棘手的、能看得到但無法測量的問題突然間變得很容易理解。例如，為什么當程序員和他們的客戶隔離開時會顯得缺乏效率。難道讓他們避免打攪不會提高工作效率嗎？答案是不會，按常理這會使他們更有效率…但也會造成他們更沒效率。因為他們的工作是為客戶解決問題，與客戶的隔絕導致他們無法找到問題，確定問題。相反，跟有問題的人保持溝通能更有效的解決問題，甚至有時候你一天8小時手指根本不需要碰鍵盤。
這將我們引向了另外一個問題：為什么軟件開發中維護成本相比起其它方面的成本顯得很難接受？為什么我們永遠無法在第一次做出“正確”的東西？一種解釋就是，軟件是一個對可能變化的問題的固定解決方案。當問題發生變化時(或我們對它的理解發生變化時)，問題和解決方案之間就出現了裂痕。這種隨著問題的演變而不停的修補產生的縫隙的活動代價高昂。這也解釋了為什么相對于其它軟件項目，視頻游戲通常的維護成本較低。這是因為它們需要解決的問題(讓人們去買這個游戲，玩這個游戲)基本上是根據人類心理學，而這是不常變化的。
好的程序員和壞的程序員之間10倍之差的“生產效率”又是從何說起？每個人都說這是事實，但事實上沒有人能直接的測評。我們的理論同樣能解釋這個問題。相比起工作效率來說，“解決問題”是一種更容易“調控”(金融詞匯)的東西，使得產生一個數量級差別的效果很容易實現。解決問題需要的是信息和洞察力。你要么有，要么沒有。不需要原材料，沒有生產能力限制。并不是差的程序員打字速度慢。并不是如果他們努力就能做得更好。他們是缺乏這種高效解決問題的眼界和必要的信息。也許無法測量好程序員和差程序員在生產效率上的差別的原因就在于沒有東西可測量。
還有很多現象都可以用這個理論來解釋。如果你去找，一定能發現一些。最近我一直在搜羅這方面的案例….試一試，看看這個理論是否也體現在你的工作中。每當發現自己在說提高“生產效率/工作效率”時，問問自己是否是在用正確的方式解決問題。銘記在心：如果不通過生產任何東西就能解決問題，那生產出的任何東西都是一種浪費。
it知識庫：程序員的工作不能用“生產效率”這個詞來衡量，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
