獅麪人---走出軟件作坊：三五個人十來條槍 如何成爲開發正規軍（二十六）
http://blog.csdn.net/david_lv/archive/2008/06/30/2599190.aspx讀後感：事情不僅要做好，還得讓人認識到你做的好。
原文：
好多人都說：你這個方法根本就不是三五個人十來條槍的方法，項目經理，公共代碼開發員，測試員，文檔員，那得多少人的公司才能配得齊這樣的團隊。
嗯。其實，我們的團隊也不怎麼大，我們本身也是一個很典型的中小企業。
一般，都是一個產品或一個項目，由一名業務開發組長、一名主程、一名輔程組成。如果項目簡單，基本就是一名業務開發組長和一名主程構成。如果業務開 發組長的開發實力也能和主程相當，而且刻苦努力，不僅協調做的好，需求設計做的好，代碼開發也做的好，那麼比較中型的項目也是這兩個人組成。有幾個產品， 就會有幾個這樣配對的開發團隊。
研發部其他的人就剩下項目經理、公共代碼開發、測試員、文檔員這些角色了。
一般，研發部會有一到兩名項目經理。我們老承接一些大的合作開發集成項目，老需要有人去客戶現場去和其他合作伙伴一起開會，討論，方案提交、工作量 報告、工作進度報告。總需要有人去跑這些項目協調會。另外，銷售打單的時候，客戶總會提出一些技術性的問題或某個需求能不能做的問題，銷售也模棱兩可，不 知道能做還是不能做，於是總會拉上一名項目經理。關於產品的、技術的、開發週期、工作量估算、項目團隊組成的PPT和方案由研發部的項目經理來做，關於價 格和商務條件上的由銷售來做。在打單過程中需要講解產品或回答客戶產品疑問，都讓這名項目經理來兼任售前支持。對於項目型的，項目經理有時還擔任需求調研 經理，使用需求調研方法產出需求說明書。不過，需求調研，有時也是業務開發組長來做。主要看業務開發組長在客戶面前的溝通力。因爲業務開發組長是開發人員 出身，但技術一般，業務知識很熟，管理能力差不多夠管理個1-2人，工作年限長一些工作經驗也多一些，但有些人比較內向，不適合和客戶調研溝通，就不做需 求調研。所以誰來做，看具體人。不過按職責來，項目經理和業務開發組長都要能做需求調研。
然後就是公共代碼開發人員，一般就一個人。對於企業管理軟件的開發，框架的開發和維護，公共代碼的開發，高難度的問題跟蹤，需要高性能的設計，需要 高擴展性的設計，需要高穩定的代碼，需要高安全的代碼，需要高併發的操作，需要複雜代碼重構。需要性能優化，不知道的技術API，都可以尋求這位公共代碼 開發人員的幫助。他還負責新技術跟蹤、新技術介紹、新技術試驗。但這個新技術必須是爲了改進公司現有產品和現有客戶。新技術的跟蹤必須上報給技術總監，以 防不符合公司目標亂跟蹤或跟蹤方法和思路不對。對於有利於現有開發的新技術，可以籌備好培訓課，由研發部經理安排時間，讓公共代碼人員給研發部全體人員講 解。如果大家認可這種方法，就需要選擇適當的時機在產品中引入。
研發部的測試人員，一般也兼任服務部門技術支持人員。如果有服務部門解決不了的技術問題，可以轉給他。而且測試人員還兼任配置人員，在產品打包、產 品安裝測試、產品發佈、版本分支管理、源代碼備份、歷史版本歸檔方面都由他來管理。兼職是有好多好處的。如果他不兼任技術支持，他就不瞭解客戶是怎麼使用 的，他測試也是瞎測試。如果他不管理產品打包發佈，程序員就會自己私自發布版本。可能版本還有問題，爲了修補問題，就趕快修改完再打包一個，但版本號卻不 改變，引起了一個版本號代碼不同錯誤不同，讓服務支持起來很莫名其妙。由測試人員控制產品版本發佈，能不能發佈，就是測試員說了算。測試員感覺質量沒有達 到，就有權不發佈。很多軟件作坊，程序員權力很大，一個老哥從頭到尾負責整個項目，項目質量如何，全看這位老哥自己的素質和責任心了。爲了不讓項目質量和 特定人密切相關，使公司研發保持連貫性水準，必須做到分工專業，互相配合互相牽制。
一般，研發部也就配1-2名測試人員，根據同時並行的項目和產品開發和開發的強度來定。我們並不生產向國際上的產品那樣的質量。我們做行業企業管理 軟件開發，是在客戶質量要求、客戶簽單額、競爭對手質量水準這三者平衡上做到一個質量的認可。我們無法做到微軟那樣一比一的開發測試人員比例。研發部所有 的產品和項目，都由這1-2名測試人員負責所有的測試工作，包括編寫測試案例，編寫測試結果，參與項目的需求測試、設計測試。
對於研發部的文檔方面，如文檔的正規化，都由文案來負責。項目經理經常要提交給客戶一些文檔，而項目經理往往是技術出身，文檔工作水平不行，於是文 檔的正規化、美化、文字校對、空格段落措辭標點符號，都由文案製作。幫助文檔，也由文案負責。幫助方面，有版本更新說明幫助、安全配置幫助、系統維護管理 幫助、基礎數據配置與維護幫助、業務功能操作幫助、軟件操作演示視頻、產品簡介PPT、產品演示版，都由文案來做。爲了防止文案不懂產品而寫產品幫助，在 需求說明書、設計說明書這些文檔性的工作上，如果有什麼文檔體力活之類的工作，也由文案人員來做。文案人員還兼任產品輔助測試，主要是作爲一個普通的操作 者來測試，在製作演示版的過程中模擬客戶流程客戶數據來進行操作錄入，測試出普通使用中的BUG。一般，一個專業的測試，經常呆在軟件的環境中，思維就有 一種定勢，但實際的用戶並不那樣操作，但測試人員自身感不到。而文案人員就能充當普通用戶來測試。我們招聘文案人員也沒有強調會什麼軟件，文案寫的好就 OK。他們確實是最普通的用戶，他們的困惑和操作手法代表了大量的普通用戶。而一個研發部，文案人員也往往是1-2名，隨並行的項目數量和規模來定。
所以說，一個研發部，一名研發部經理，1-2名開發人員，一名項目經理，一名公共代碼開發人員，一名測試，一名文案，也就是5-6人完全符合一個軟 件作坊的人員數量。有時候團隊小了，研發部經理就是項目經理，公共代碼開發人員就是主程，這樣，一個開發團隊也就是3-4人就OK了。但方法照樣能用起 來。因爲我所講的方法也就是適應於這四套馬車的組織架構的。每個人都身兼數職，而且都對自身的提高非常有好處，而不是給他身上堆砌毫不關聯的工作內容。每 一項職責都是能互相互補的，整體提高他的崗位專業性。
作爲業務開發組組長，他很大的一個職責就是開發項目的進度和質量管理。手下也就1-2個人，開發人員的素質也就這麼高，我們也會經常遇到突然來了個 項目的事情或者突然有個過去的項目問題必須開發人員跟蹤，所以開發人員也總是會被左抽右調。對於還能保證開發進度正常，業務開發組長確實每天都在監控進度 異常，監控每個開發人員目前身上揹着的開發任務和開發進展。每天下午5點的時候都要詢問一下自己手下這兩個人的開發進展。因爲有的人不喜歡主動說自己遇到 的什麼問題，總喜歡自己去到處找答案，弄的延誤了正常的開發計劃。所以，開發組長必須每天下午5點主動問遇到了什麼問題，是不是很棘手，能不能保證進度。 如果不能保證，業務開發組長就會想辦法，是全小組一起診斷出謀劃策呢，還是尋求公共代碼開發員呢，還是尋求研發部經理呢。爲什麼是下午5點？主要因爲 5：30-6：00就下班了。如果快下班了你纔去問，大家早就心思不在這裏了，誰都想趕快下班回家，問題就被隔了一夜，留了個不清楚的尾巴。如果在5點鐘 詢問，有了問題，如果此問題業務開發組長有經歷，他會很快決定該怎麼解決。如果詳細聽完了此問題的來龍去脈，業務開發組長也無法決定，他已經清楚了問題， 他會在晚上思考，第二天一上班來就有了決定。這就一叫一點都不耽誤。
我們使用的是BUG管理系統來管理開發任務。這並不要緊，誰說BUG管理工具只能管理BUG。我們只需要解決我們的問題而已。當然，我們管理真正BUG的系統是另一套，只不過我們使用的是同一個工具而已，我們當然不會把BUG和任務混在一起。
來自需求管理系統中的需求，來自BUG管理系統的BUG，都會被業務開發組長來評估，根據自己團隊當前每個人的工作量來適機添加、定優先級、分配任 務、調度任務。也根據這個任務分配，哪些任務超期了，哪些任務完工了，哪些任務還沒有開工，哪些任務正在進行當中，來判別開發人員的開發進度和工作量。
業務開發組長也會每日主動向研發部經理報告進度，簡要說明一下現有問題和解決思路。進度列表，當然是從工具中導出的，列明今日關閉的任務，還沒有關 閉的任務。這樣，研發部經理一思考：項目已經開始了這麼多天，還有這麼多任務沒有完成，到期能不能完成，他就會思考是不是要做些調整。
對於項目進度，不管客戶是不是需要必須在XX月XX日之前上線，我們都會設立一個項目最終結束的日期。而不能讓項目隨波逐流。
這個最終的項目開發結束日期，並不是由業務開發組長排腦門想出來的。
我在以前的文章中就有介紹。業務開發組長負責功能點清單整理、功能優先級劃分、詳細功能說明書編寫。而且每編寫一塊就開始分配任務給開發人員。
在業務開發組長劃分完功能優先級以後，因爲每個功能的複雜性都差不多，如果某個功能複雜，就會再被拆分。業務開發組長就能預估出一個大概的項目開發 週期。根據以往的團隊經驗，也能預估出給集中測試時間和集中文檔測試打包發佈的時間。這樣，整個軟件什麼時候能最終出來，業務開發組長是有個預估的。如果 一個團隊是新組建的，每個人的能力還不清楚，預估就會有偏差，需要磨合才能得到經驗值。如果磨合，我也會在以後講到。
在實際分配開發人員的時候，就是根據這個總目標完成時間來倒推時間的。這個倒推出來的，有一個每個功能的完成時間週期，而項目經理對於某個特定的開 發人員的能力預估也有一個時間，而開發人員自己對完成這個功能自己也有一個預估時間。開發人員怕完不成任務被追究，往往會把完成時間往後放1/3時間，甚 至有人想偷懶幹自己的活，會更多出自己預估時間一倍，也就是說自己覺得3天能完成，就說6天才能搞定。當然，業務開發組長也不是喫素的。業務開發組長也是 開發出身，到底難度多大心裏有數。而且業務功能就是業務開發組長設計的，如何實現，會遇到什麼難點，自己一清二楚。而且天天管這幫開發人員，誰能力高低誰 想偷懶，天天在一個辦公室，誰不知道誰。所以，每個任務的時間，都會是業務開發組長在開發人員自己預估的時間基礎之上進行調整，獲得一個開發人員和業務開 發組長都能接受的任務時間段。然後根據每天的進度報告來隨時調整這個時間，讓開發進度儘量能現實，而不是計劃前就定好實際工作中就不能改。
對於項目進度的保證，還必須有一個條件，就是：我們不允許開發人員在客戶現場開發，我們更不允許開發人員和業務開發組長不在一起。
開發人員在客戶現場，往往開發進度和功能需求變更容易受客戶控制，致使開發團隊做的計劃和設計都被客戶視爲扯淡的東西。開發人員不滿客戶的做法，但 在現場又沒有辦法，只好敷衍答應開發權且應付。本來一個理性的設計，被客戶自己自以爲是的好做法而推翻。軟件什麼擴展性啊，兼容性啊，都被扔在了一邊。來 客戶現場，就要聽這個特定客戶的，你必須口對口服務這個特定客戶，你如果和他講其他客戶怎麼辦，他纔不管呢，反正他付了你的錢，在你眼中他必須是你唯一的 客戶。（客戶和女人一樣，都希望是男人眼中唯一的女人，但現實的是，世界上都很多女人，而且很多女人都差不多，都要求她所對應的那個男人必須唯一）
另外，開發人員在客戶現場開發，就無法實現每日構建每日測試。開發，是個團隊配合的事情。一個軟件，並不是開發人員就能全部完成的（許多老闆都這認 爲有開發人員就行）。缺少了測試，質量就無法保證；缺少了文檔，產品就是光禿禿的軟件。而許多老闆還認爲測試和文檔可以在代碼編寫完後可以做，真是對軟件 質量如何保證一無所知。
我們也不允許開發人員和業務開發組長分離。因爲在開發當中，設計文檔又不是代碼，機器運行完就一種結果。每個業務開發組長的文檔水平有高低，每個人 的思考思路也不同。我們經常會遇到一個現象，就是用郵件、MSN溝通老出誤會，而且由於不及時調整，誤會越來越大，後來乾脆氣憤的直接打電話。而打電話 呢，有時還不行，你問他理解了麼，他說理解了，你根本看不到他的表情，你猜測不到他是真理解了還是假理解了。你以爲他理解正確了，他也以爲自己理解正確 了。你問他進度，他說沒有問題。開發出來了，測試人員又有自己的理解，到底這三者理解的是不是一個東西，誰都沒個準。只有業務開發組長和團隊一起工作在一 起，每天能看到實際的軟件，能面對面和每個人交流反饋，纔不至於代碼開發完畢才一看不行。有許多剛當上業務開發組長的朋友，往往和手下搞的很僵硬。手下認 爲他一天三變，頻繁推翻自己的代碼，很氣憤。而業務開發組組長認爲手下的理解能力低，多次講都講不清楚，還跟自己頂嘴，還不如自己去開發代碼省事。完了， 又回到程序員了。
我也同樣不允許團隊出現多種技術。多個技術，會讓團隊成本升高，每個人都得會多種技術。而我們做企業管理軟件，要想上升賺錢，必須大規模一般員工團 隊低成本開發，這是我和老闆都認同的一種思路。所以，我們必須使用最常用最普通的技術。除非沒有辦法。我曾經有一個手下，怕自己跳槽沒有競爭力，於是老學 習流行技術。PHP火的時候，他就學PHP。Ruby火的時候，他就學Ruby。如今網遊和嵌入、通信、無線很火，他就開始學C。手機開發火的時候就學 J2ME。而且他還想有實際的開發經驗，以在應聘中說自己拿這門技術做過什麼。於是他想盡辦法在項目中要引入這些技術。說：用.net，我沒法保證性能和 穩定性，所以我必須使用VC++。？？唬誰呢？大家都是開發出身，這個藉口未免太可笑。
我也不允許團隊使用最新技術。我們只使用最合適的技術。我們不要客戶爲不需要的新技術而買單。客戶的水平只能管理了SQLSERVER這樣的數據 庫，我們就決不使用Oracle。如果客戶要求在unix上運行，我們就使用JAVA開發。我們謹慎的評價和引入框架，都在覈心圍繞客戶能不能簡單維護， 我們有沒有顯著好處，我們面臨最棘手的問題能不能很好解決。如果只能解決我們不怎麼緊急的問題，如果只能解決我們通過人工或管理就能解決的問題，我們就不 引入。一切的一切，都圍繞速度、成本、質量在尋找解決方法。
我們也採取了每日構建每日測試，來保證軟件的進度和質量。不每日測試，哪到什麼時候才測試。到那個時候測試，會不會出現其他什麼不可控的問題，我們 都說不清。這種對未來的恐懼，讓我們需要把風險控制到最小，到天，而且到今天。今天關閉的任務，明天一測試，就知道問題大不大。有問題的，必須由測試人員 登記BUG系統，並且業務開發組長根據目前情況適機把BUG修復當作一項任務來添加。
我們也採用了版本管理工具。版本管理工具不僅可以使我們對比源代碼差異，找回歷史版本，隨時打包更新版本，分支每個客戶的定製需求，還可以是我們的一個工作的體現。大家經常會聽到這樣的話：不知道開發部這幫傢伙在幹嗎？是不是故意利用我不懂代碼在偷懶。
我們到底在幹嗎？我們能否證明。有的時候確實是，一個問題三兩天都解決不了。我們真的不好意思說我們三天就做了一個功能。我們如果解釋這般技術難題爲什麼爲什麼，老闆更是沒有興趣聽，他認爲你在嘲弄他不懂開發技術故意拿技術問題來騙他。
我們能如何證明呢？能拿一些大家都能理解的方法來證明自己呢？所以，我想到了文檔數量和尺寸大小，想到了BUG數量，想到了任務數量，想到了需求數量，想到了開發進度報告，想到了版本發佈次數，想到源代碼歸檔容量和源代碼行數。
一個項目開發結束，任務數300多，BUG數量400多，文檔尺寸70多M，項目歷次討論開會紀要30M，項目歷次方案提交20多M，開發進度報告100多份，幫助文檔100多M。這些都能量化都能看得見的東西，讓老闆覺得確實做了許多事。
我們曾經有一個客戶，嫌10萬塊錢買了一張光盤，覺得貴死了。說地攤上一張才5塊，你賣我10萬。我們於是就把所有的幫助文檔都打印了出來，600 多頁，裝訂成3本書，印刷好封面交給他。然後把軟件裝在一個很精美的木製盒子裏，客戶笑的很開心，把盒子和手冊都鄭重其事的放在了IT部門的櫃子最上面。 我想，軟件是由代碼組成的，確實不容易讓客戶理解其中的艱辛和付出，所以客戶並不認可我們的付出。能拿客戶可以理解的方式去講明白就是解決方法。我一貫遵 守的原則就是：要麼解決問題，要麼閉嘴。如果你想不出解決方法還抱怨影響團隊情緒，那麼滾蛋，這種人就是團隊的毒藥。
過去，我們講了業務開發組長如何履行功能設計的職責的一些方法，今天，我們又介紹了業務開發組長在任務分配、軟件進度、軟件質量保證、工作量化的一 些心得，這就是一個開發組組長的份內之事。希望能給被提上開發組長的朋友一些啓發，不要把自己定爲一個寫代碼的頭兒，那樣你不符合國內現狀，國內的開發組 組長就需要做這些事情。外國怎樣怎樣那是外國的事情，你也享受不到，這是中國。要麼去做，要麼老老實實繼續當個程序員。