自從發了上一篇博文，這幾天收到很多朋友的來信。

大家從各個開發語言的優缺點和適用領域，一直討論到設計模式、框架、重構、單元測試，乃至敏捷編程，最后都討論到了軟件開發過程管理，甚至都談到了盈利模式和中國軟件的悲哀。

最后不了了之，都覺得改善中國內地現在的軟件生產狀況不可能。

為什么呢？

我重新把這幾天大家的討論留言翻了一遍，發現大家的軟件團隊都存在著這樣一種普遍現象：

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!

轉載于:https://www.cnblogs.com/xiaobeisong/archive/2008/06/02/1212159.html

總結

以上是生活随笔為你收集整理的【转】三五个人十来条枪 如何走出软件作坊成为开发正规军的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。