軟體以人為本2 – 為什麼軟體要以人為本？

軟體以人為本，這是一個值得討論的話題嗎？

1. 回顧“軟體工廠” 

至今還記得在我國九十年代中期興起，兩千年左右火爆的 “軟體工廠”運動。CMMI、TSP、PSP、RUP、UML還有MDD等等就是在那幾年開始火爆的。招募一幫代碼工人，給他們合適的工具，用最好的流程和方法學管理他們，他們就能生產出符合要求的軟體產品。多麼好的想法啊！公司老闆和管理員太喜歡了，於是很多公司轟轟烈烈加入了“軟體工廠”運動中。如果加上MDD，在不遠的未來代碼都可以自動產生，代碼工人可以取締，於是真正的“軟體工廠”就建成了。當時作為軟體開發人員的我也有點小恐慌，做開發真的是青春飯啊，這才做開發幾年，連寫代碼這個工種都要淘汰了。

軟體工廠如此定義軟體開發：

1. 軟體是針對既定需求的產品。

2. 軟體可由預定義的模組組裝，也可由預定義的模型產生，也可由代碼工人編寫程式碼完成。其終極目標是根據預定義模型，基於預定義模組進行的組裝。

3. 軟體中最重要的是語言，方法，流程和工具。代碼工人只是資源而已。

時至今日，軟體工廠的概念已經隨時間流逝而漸漸淡去。然而這種思想在現在依然很有市場，因為它的最大賣點在於可管理性和可預測性，很符合企業管理的特點。

案例1：客戶不等於需求

專案經理：“這是我們為你開發的產品，請驗收。”

客戶：“對不起，我們不能驗收，這不是我們想要的。”

專案經理：“但我們是按照需求報告開發的，你們當時還簽了字的。”

客戶：“。。。。。。”

案例2：開發不等於資源

專案經理：“這個業務要下周交付的話恐怕不成，資源已經全部被佔用了。”

業務：“那從另外一個業務去調一個過來，時間應該趕得上吧！”

專案經理：“我試試！”

開發還是資源，很難談得上成長。專案經理還在救火，業務還是一團忙亂。

案例3：規則還是交付

專案經理：“這個業務延遲了5天，因為我們前端開發資源緊缺。”

業務：“那能不能讓其他的開發人員做呢？”

專案經理：“前端組的有要求，不讓自己做！前段時間他們去老大那裡投訴了，我很被動。”

公司大了，分工細了，協調難了。部門間目標不一致了，滿足客戶和遵守規則衝突了，流程越來越多越來越僵硬了，人的力量越來越難發揮了。

案例4：開發和業務的溝通難題

開發：“業務那邊又變了，這事沒法搞，改來改去，他們到底要的是什麼，不能先搞清楚嗎？”

開發找到開發的老大：“老大，我們是不是給他們增加個需求評審。”

業務：“開發怎麼還沒開發出來，這樣的話業務怎麼能完成任務。”

業務找到業務老大：“老大，我們是不是要他們給出開發計劃，用這個來管他們。”

2. 軟體以人為本 

2.1 為什麼軟體要以人為本

在傳統的思想中，我們應對溝通、應對人、應對變化的方式就是把它固定下來。所以我們試圖把客戶的需求固定下來，把工作流程固定下來，把工作崗位固定下來，把開發模式固定下來，把管理方式固定下來。在這個過程中，為防止其他人的變化給我們的工作造成的困擾，我們不停的給其他人帶來的變化設定更高的門檻。當然，軟體開發中的所有人都試圖這麼做，所以我們製造出了相應的組織、文檔、流程、方法、工具，試圖避免減少與“人”的溝通交流合作，試圖降低對個人能力和創造性的依賴，試圖用簡單的、可重複的、易於管理的方式取得成功。

但是時間能夠固定下來？變化能夠固定下來嗎？人能夠固定下來？溝通合作能夠固定下來？創造效能夠固定下來？

這就是軟體以人為本的由來了。“人”是變化之因，“人”也是應對變化之本。

如果讓我重新來定義軟體開發，我會如此定義：

1. 軟體是為客戶（人）創造更高價值的產物。客戶（人）對更高價值的理解會隨時間而變化，軟體需應對這種變化。

2. 軟體是客戶與Team Dev和Team Dev內的人與人間合作的產物。個人的能力與團隊的合作是軟體能否成功開發的關鍵。

3. 語言、方法、流程和工具的主要作用是輔助個人和團隊發揮更大的力量，從而能更高效地為客戶創造更高的價值。

軟體以人為本將包括對如下內容的獨立思考：

1. 如何提升個人的開發能力和管理能力？如何提升與他人的溝通能力和自己的影響力？

2. 如何融入團隊，進行團隊合作？如何建立團隊，促進團隊合作？如何有效利用工具（語言、方法、流程和工具）輔助個人能力提升，協助團隊發揮力量？

3. 如何與客戶更好合作以在更短的時間內為客戶創造更大的價值？

2.2 敏捷十年

來自InfoQ《敏捷宣言十年後的思考2》。在敏捷走完十個年頭的時候，敏捷大牛們紛紛發表意見，不少敏捷大牛認為敏捷在人方面並未取得期望中的成功。他們對敏捷社區提出了下述期望：

1. 渴求技術卓越

2. 促進個人轉變和領導組織變革

3. 管理知識並推動教育

4. 力圖在整個流程中最大化地創造價值

軟體以人為本看來是一個長期的問題。