[引用] 三五个人十来条枪 如何走出软件作坊成为开发正规军
自從發了上一篇博文，這幾天收到很多朋友的來信。
大家從各個開發語言的優缺點和適用領域，一直討論到設計模式、框架、重構、單元測試，乃至敏捷編程，最後都討論到了軟件開發過程管理，甚至都談到了盈利模式和中國軟件
的悲哀。
最後不了了之，都覺得改善中國內地現在的軟件生產狀況不可能。
為什麼呢？
我重新把這幾天大家的討論留言翻了一遍，發現大家的軟件團隊都存在著這樣一種普遍現象
1大部分人所在的公司，開發人員僅3-5人，多的在10人。別看就這幾條槍，還從售前支持，軟件開發，測試、打包發布、文檔編寫、實施安裝、培訓、技術支持都做。
這還不算什麼，而且幾乎是一個人負責一個產品或一個項目，一個人從頭跟到尾，而且負責多個客戶的維護工作。
這還不算什麼，而且隨時老闆會找來八竿子打不著的新活，要的還挺緊，突然要開發，打亂了所有的計劃，最後都懶的按計劃行事，每天撞鐘，老闆有事就吩咐，沒事就上網，還不讓聽歌，當然更不讓打遊戲。甚至還不讓看技術書籍，呵斥不干工作。只能上網裝作在工作。2老闆和員工互相鬥智斗勇，在年終獎、報銷、出差、平時福利上啊，都明爭暗鬥。老闆卡的緊，員工就在項目和產品上下藥，還不知道是誰佔了誰便宜，誰給誰打了工。
3員工一邊在刻苦鑽研各種開發工具，閱讀源代碼，學習做DEMO例子，閱讀UML、設計模式、單元測試、敏捷編程等等，一邊卻懶的修改現在公司的產品，有問題就打補丁，客戶不嚷嚷就懶的修改，代碼不優化，界面不友好，架構沒架構，代碼不封裝
但是，在討論中，我時時都強烈感覺到，大家是想把產品開發好，把開發過程管理的井井有條，但是都心有餘而力不足。閱讀了N多軟件工程的書籍，從重型方法到輕型方法都閱讀了，但都無法把現在的開發狀態一點點扭轉好。
許多人想鬧革命，把現在這些產品和團隊都砸塌，然後重新來過，但這只是夢想，說說而已。只能希冀下一次跳槽，能找到一個好的公司，把自己平生所學全部發揮出來，但這好像也只是夢想，因為交流了一下，大家彼此的境況基本相同。
一些極端主義者自己開了公司，才發現不持家不知道油鹽貴，現在自己和手下變成了老闆和員工的關係，走了過去的老路。
更有一些極端主義者辭職，自己做軟件，最後由於生活拮据或做做發現這個軟件沒什麼意義，就丟棄了自己的夢想，隨便找一家公司開始沉默撞鐘。
一些聰明的傢伙，有的入了外企，有的進了大的網游公司，有的進了外包公司，有的進了大網站公司，都是講究大規模開發的公司，希望能找到一條中國式團隊開發產品保證之路
作為小軟件公司，我們真的無能為力了麼？我們真的成為炮灰了麼？
但是，中國軟件行業大部分都是這樣的公司。從每年的CSDN的程序員調查都可以看到，中國軟件公司大部分都保持在這種開發團隊規模，開發人員大部分都在畢業1-3年。
我們是在等待時間讓人變得成熟麼？我們是在等待時間讓人變得技術綜合實力增強麼？
依筆者看，作為中國軟件群體最大的小軟件公司，需要的不是UML/RUP/CMM這些重型方法，不是前幾年大家關注的小組開發方法，也不是敏捷編程這樣的結對方法，我們都無法有這樣的資源實現這樣的方法。
但是，想想，星星之火可以燎原。紅軍能從爬雪山過草地起家，最後解放全中國。我們就沒有方法？
那我們就需要想，就我們目前能擁有的權力和資源，我們如何一點點改進。我們需要的是從游擊隊到兄弟連，從兄弟連到正規軍的方法。我們現在還處於游擊隊，一個隊長領了一幫遊兵散勇，有的人甚至沒有槍還背著大刀，有的人還沒殺過鬼子。
首先，要把我們自己變成兄弟連。
我常常觀看國際著名的CS戰隊的比賽錄像，他們配合的多好啊。如果他們都單兵作戰，那麼早就死翹翹了。這和咱們的軟件開發多麼相像。我們多麼神往這種默契的配合，打的多麼流暢。我們要的就是這個。他們也不幾個人麼。
那讓我們來分析分析吧。
我們想好好專職的開發軟件，但我們的時間都被實施安裝、培訓、技術支持佔去了。為什麼我們要做這些？是因為我們軟件沒有操作說明，其他部門人都不會用。而且我們也沒有培訓機制，其他部門人更不會用。而且我們的軟件不穩定，其他部門人都拒絕實施。由於我們軟件不穩定，老出問題，出了問題其他部門人也幫不上忙，只能我們自己去做技術支持。
從以上來看，主要矛盾就是在：操作說明、培訓機制、穩定性。如何保證這三點。而且從以上來分析，穩定性是最重要的。不穩定，你即使有操作說明和培訓機制，其他部門人都躲著實施，誰想去客戶那裡尷尬丟臉挨罵呀。所以，其他部門人會找各種理由向老闆告開發部的狀，以躲避實施，說軟件太爛，根本無法拿出去。這也就是開發部往往和其他部門關係都不好，開發人員老抱怨自己就悶頭辛苦開發解決問題，沒有人說好，卻被奸人陷害。天長日久，積怨頗深。其實說起來，根源還在開發部自己這裡。
如何保證穩定性？
大家第一想到的就是招測試人員。當然，一些公司的老闆是拒絕養測試人員的。另外，如果你只想到招測試人員，其他方法不配合測試人員，即使有了測試人員，軟件穩定性仍然不會有提高。所以，有一些工作，是不管有沒有測試人員，都必須是我們開發人員要做的：
每個人的技術水平都參次不齊的，每個人對自己代碼的負責認真性也都是不一樣的，所以要想提高穩定性，必須專門從隊伍中找一個人，他作為公共代碼開發員。每個產品或項目的修改需求，必須首先經過他的思考，能做成公共代碼，能封裝成函數，就他來做。其他的程序員只管調用函數，實現客戶UI操作和輔助功能。這個公共代碼開發員必須具備以下能力：
A參與過幾個主要項目的開發、實施、支持。這樣，他對客戶需求有綜合的把握。如果隊伍中沒有這樣的人，只有開發經理一個人有這樣的經理，那麼接到客戶需求，分析客戶需求，分解析辨是公共代碼員來做還是其他開發人員來做。
B公共代碼開發員具有負責認真的工作態度，代碼細心嚴謹考慮周詳異常保護做的到位內存創建釋放有頭有尾，代碼優美，代碼可閱讀，代碼重構，代碼性能和穩定都高
C公共代碼開發人員的技術能力高，知道封裝成什麼樣的函數接口，在靈活性，以後的修改變化性上最好
應該說，找一個技術能力好的，工作認真負責的人，應該是不難找到的。而且專門做這件事，不讓他參與各種雜事，他是應該能干好這件事的，而且會越做越好，這就是術有專攻。
剛才還講到一件事，那就是開發經理要熟悉客戶需求，而且是深刻理解客戶需求。
客戶需求，客戶需求。這個讓開發部最頭疼的字眼。每當想起客戶需求，就想起了以下這些話：
1 程序員說：這是你們家個性的需求，太邪門，我們不做。客戶說：不做我們找你們老闆去，我們是花錢買了你們的產品的。
2 客戶說：我不會用鼠標，你給我做一個語音輸入吧。我們還想要一個類似QQ的東西供我們內部溝通，你們給我們做一個吧。程序員：我暈。
3 程序員說：等你們內部鬥爭完，你們協調完了，我再調研需求。
似乎，我們在需求上無能為力，我們永遠在追趕客戶的需求，滿足他們的現狀，把N多家的客戶需求都加進軟件中，只要能實現的，我們盡量咬牙實現了。
最後，我們發現，我們的軟件無比複雜，誰也不會用了，連開發部門都不會用了，誰也不知道這個需求當時為什麼是這樣的。因為無比複雜，所以實施、培訓、技術支持都成了問題，穩定性更成了問題。代碼互相交叉，根本無法理清有多少交叉影響點。維護的程序員都快崩潰了，天天在祈求，千萬別接到客戶電話，千萬別接到客戶電話。
這個問題終歸是問題，而且是軟件開發最大的問題。雖然我們也動用了這樣的技巧：
1 客戶業務部門不能隨便提需求。必須集中匯總到客戶IT部門，由客戶IT部門匯總過濾完，再集中報給軟件公司
2 客戶IT部門的需求，必須客戶方負責IT項目的老闆簽字才能生效，才能報給軟件公司
3 不能隨時報，每3個月集中報一次
4 不能口頭報（即使在現場實施支持也不行），不能電話報，只能MAIL或傳真來報
5 必須按我們規定的格式報，要嚴格寫清楚需要實現的功能的界面，輸入數據或輸出數據，輸入輸出數據的格式要求，誰操作，多長時間操作一次。
6 軟件上線後只能免費修改3次。以後再有需求，就必須另簽合同另收費，否則不予修改。
經過這麼幾招，客戶也疲了。需求是不提了，開發部歡呼雀躍。但我們真的做好了麼？難道客戶真的滿意了麼？客戶為什麼要用我們的軟件？難道僅僅是為了把他們現在手工做的，然後轉到計算機去做。讓計算機的查詢統計計算速度代替人工？
客戶為什麼要提這樣的需求？客戶要根本解決什麼問題？這些問題誰來想，誰來想解決辦法？
OH，My God!我們無能為力，因為我們是技術人員，我們不懂業務。
那這個問題誰來解決？
程序員苦笑了：沒有人解決，也沒有人能解決。客戶就要，你不做他就要給老闆打電話。
噢，那就讓程序員的噩夢繼續吧。誰也救不了你，能救你的只有你自己。
要救我們自己，必須我們自己走出我們自己。誰讓我們就處在這樣的處境呢？我們都想過的好，只能我們自己救我們自己。
那我們就鼓足勇氣，走出來，從我們的設計模式、OO、軟件工程、虛擬接口、反射、持久化、框架中走出來。開發經理來承擔起客戶行業研究來：
1 客戶行業這個群體有多大？大中小規模各有多少家，各分佈在什麼省？我們面對的最佳客戶是什麼規模什麼信息化程度的？我們的次佳客戶是什麼規模什麼信息化程度的？
2 我們的上層競爭對手、本層的競爭對手、下層競爭對手目前的產品怎麼樣？他們各自的優點是什麼？他們各自的缺點是什麼？我們應該突出的優點是什麼？我們的缺點是什麼？
3 客戶行業的過去5年，現在2年，未來3年的發展歷史和趨勢是什麼？他們面臨哪些挑戰和機遇？
4 我們現在所做的典型客戶，他們的組織結構，人員規模，每個崗位每日業務流程、每個崗位每日每週每月每季每年的異常處理業務流程，每個崗位每日每週每月季每年的輸入表格，每個崗位每日每週每月季每年的常用數據查詢，每個崗位每日每週每月季每年的統計報表
5 針對以上的了解，客戶面對未來挑戰和機遇，未來應該如何變更他們的崗位和職責和流程，盡量流程少，效率高，運轉快？
其實，開發經理就相當於業務架構師（因為我們還是游擊隊，不可能有專職的業務架構師），公共代碼開發員就相當於技術架構師。
柳傳志說的非常好：搭班子，定戰略，帶隊伍。你班子不行，上什麼需求管理軟件、版本管理軟件、項目進度管理軟件、自動測試、自動集成軟件，都是無法落地執行的。
有了夯實的業務+技術，功能實用、功能符合客戶操作、功能穩定。這是軟件最基本的要求，就都能滿足了。這時候再招測試人員，就能把質量再夯實了。
而且，測試人員由於熟知產品，他們還能做技術支持呢，這樣可以有更多的開發人員來專職開發，開發的專業性就能越來越提高了。
好的產品，還需要有好的文檔和培訓，否則其他部門還是不會接開發部的產品的。
那就招一個文案人員，寫幫助說明，製作操作視頻，製作學習版數據庫，參與輔助測試（這個很重要，否則文案人員不熟知產品，無法寫出有質量的文案）。有了這些文案的基礎，最熟悉產品的非開發人員就有了兩個崗位：測試兼技術支持，那麼文案就兼起培訓工作（由於他自己寫文案自己用自己的文案做培訓，在培訓中會有各種提問，會更加增進他對文案和產品的理解，能寫出更好的文案。而且他不是開發人員，他能站在使用者的角度上來寫來講，而且他屬於開發部門，他會給產品開髮帶來更多更好的產品易用性建議）。
好了，開發部的四套馬車終於起來了，這就是我要講的開發模式：從游擊隊轉變為兄弟連，從軟件作坊走向
記住：業務架構、技術架構、測試兼技術支持、文案兼培訓，四套馬車。
我們一直用它，效果很好，搭建團隊容易，循序漸進不革命。
有了這麼好的團隊，就能比過去產出更好的軟件，軟件的質量，軟件的進度，軟件的競爭力就都上來了，再上各種管理軟件：如項目管理軟件、版本管理軟件、BUG管理軟件、自動測試軟件，就水到渠成了。
其他部門也願意接軟件了，軟件的實施和培訓和技術支持都被其他部門接過去了。開發部門也終於專職專業起來了，整個公司都很協調了，部門間也不互相陷害抱怨了。公司發展速度蹭蹭的。
老闆看著形式這麼好，也不摳門了。獎金福利隨之而來。老闆看著公司產品銷售這麼好，也不用再為公司生存發愁了，不用隨處找單子養活了，給開發部門更帶來了專業理順的計
劃發展。老闆也開始重視研發部門了，研發部門在公司的地位高多了，給與研發部門的資源和支持也更多了。
OH，My God!
原創:
本著作係採用創用 CC 姓名標示-相同方式分享 4.0 國際 授權條款授權，文章歡迎轉載，請註明出處，謝謝~~~