三五個人十來條槍 如何走出軟體作坊成為開發正規軍

[轉]三五個人十來條槍 如何走出軟體作坊成為開發正規軍 從發了上一篇博文，這幾天收到很多朋友的來信。

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

的悲哀。

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

為什麼呢？

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

1大部分人所在的公司，開發人員僅3-5人，多的在10人。別看就這幾條槍，還從售前支援，軟體開發，測試、打包發布、文檔編寫、實施安裝、培訓、支援人員都做。
這還不算什麼，而且幾乎是一個人負責一個產品或一個項目，一個人從頭跟到尾，而且負責多個客戶的維護工作。
這還不算什麼，而且隨時老闆會找來八竿子打不著的新活，要的還挺緊，突然要開發，打亂了所有的計劃，最後都懶的按計划行事，每天撞鐘，老闆有事就吩咐，沒事就上網，還不讓聽歌，當然更不讓打遊戲。甚至還不讓看技術書籍，呵斥不幹工作。只能上網裝作在工作。

2老闆和員工互相鬥智鬥勇，在年終獎、報銷、出差、平時福利上啊，都明爭暗鬥。老闆卡的緊，員工就在項目和產品上下藥，還不知道是誰佔了誰便宜，誰給誰打了工。

3員工一邊在刻苦鑽研各種開發工具，閱讀原始碼，學習做DEMO例子，閱讀UML、設計模式、單元測試、敏捷編程等等，一邊卻懶的修改現在公司的產品，有問題就打補丁，客戶不嚷嚷就懶的修改，代碼不最佳化，介面不友好，架構沒架構，代碼不封裝

但是，在討論中，我時時都強烈感覺到，大家是想把產品開發好，把開發過程管理的井井有條，但是都心有餘而力不足。閱讀了N多軟體工程的書籍，從重型方法到輕型方法都閱讀了，但都無法把現在的開發狀態一點點扭轉好。

許多人想鬧革命，把現在這些產品和團隊都砸塌，然後重新來過，但這隻是夢想，說說而已。只能希冀下一次跳槽，能找到一個好的公司，把自己平生所學全部發揮出來，但這好像也只是夢想，因為交流了一下，大家彼此的境況基本相同。

一些極端主義者自己開了公司，才發現不持家不知道油鹽貴，現在自己和手下變成了老闆和員工的關係，走了過去的老路。

更有一些極端主義者辭職，自己做軟體，最後由於生活拮据或做做發現這個軟體沒什麼意義，就丟棄了自己的夢想，隨便找一家公司開始沉默撞鐘。

一些聰明的傢伙，有的入了外企，有的進了大的網遊公司，有的進了外包公司，有的進了大網站公司，都是講究大規模開發的公司，希望能找到一條中國式團隊開發產品保證之路

作為小軟體公司，我們真的無能為力了嗎？我們真的成為炮灰了嗎？

但是，中國軟體行業大部分都是這樣的公司。從每年的CSDN的程式員調查都可以看到，中國軟體公司大部分都保持在這種Team Dev規模，開發人員大部分都在畢業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!

冠億科技,盡心儘力