下面是最近對公司研發管理的一些思考，和大家一起討論。對於想網際網路這樣「小而快」的行業，敏捷開發無疑是適合的。但是對於電信行業這種「大而笨」的行業，是否也適合？我一直有這樣的疑問。
電信行業有他自身的特點，比如，需求變化一般不大，相對比較穩定；對穩定性的要求比對快速發布的要求要高，如果穩定性有問題，影響一般很嚴重；一般採用更底層的語言（比如c）來進行開發。將敏捷理解成「裸奔」，通過犧牲質量來達到快速交付也許有些狹隘，但是在快速的交付的同時保持高質量，這對開發人員和開發工具（特別是自動化測試工具）的要求較高，我們很難滿足這個要求，一般小公司也很難滿足這個要求。況且很多專案對持續交付的要求並不強烈。
更具啟發的一種思路是，不要把敏捷認為一種流程（比如scrum）或工具，而是一系列行動的思想和原則——他本來或許就是如此。這樣的話，我們可以適當的引入一些有啟發的思想和原則來武裝我們的大腦：
1、個體與互動 重於 過程和工具。2、最有效的溝通方式是面對面的溝通。
3、自組織團隊。
4、要做到簡潔，即盡最大可能減少不必要的工作。
5、定期反省，思考對團隊和工作的優化。
對於流程優化，我的基本思想還是缺陷驅動：缺陷驅動的流程優化和技術引進。小公司在骨子裡就和敏捷開發走得很近，也許他們真的有什麼「血緣」關係？
有幾點是小公司生就具備的，比如看重個體互動勝過過程工具，看重工作的軟體勝過面面俱到的文件，看重對變化的響應而非遵循計畫（有的時候可能沒有計畫）等等，雖然做的不是盡善盡美，但是有這樣的價值取向。
有一點我印象比較深刻。在上一家公司的時候遇到過一件事情，由於工作中正式溝通使用郵件，兩個開發人員背對背坐著，為了說某件事情發郵件發了半個小時。那個時候我也有郵件綜合症，剛到現在這家公司的時候，我問同事有沒有郵件系統，他好奇的問我要做什麼，我說可能要溝通事情，他笑著說喊一聲或者走過去就可以了（通訊****）。
對待開發一定要擺脫那種非此即彼的思路。我們為什麼非要在結構化開發和敏捷開發中作出乙個選擇？為什麼選擇了敏捷就一定要排斥結構化開發？要擺脫這種非此即彼的思路，就要用漸進的方式來思考他們，看下圖，我心中的結構化開發和敏捷開發：
從左到右，從結構化到敏捷，都是乙個漸進的過程，代表了幾個不同的價值取向：
流程和工具——個體和互動
詳盡的文件——工作的軟體
合同談判——客戶合作
遵循計畫——響應變化
我們要選擇的，是根據自己的實際情況，選擇乙個自己的位置。針對我們目前的情況，我們的位置以及理想中我們的位置：
我們目前的位置並不是說我們敏捷的很遠。過猶不及，我們之前一直受一些問題的困擾，比如過分重視工作的軟體忽視文件，甚至沒有文件；過分重視個體和互動而基本沒有流程；響應變化而很少有計畫等等。我想這可能是很多小公司都可能面臨的問題。
結合我們的專案特點以及我們團隊的特點，我們理想中的位置應該是在結構化開發和敏捷開發之間而偏向結構化開發。具體的措施可能是巨集觀上採用結構化開發的思想，而微觀上這借鑑敏捷開發的思想。至於如何達到這個效果，還要繼續實踐。另外，根據具體專案的不同，可能採用的方法也不盡相同，並不是我們所有的專案都處於此位置。
乙個比較另我糾結的問題是，如何從現在的位置移動到理想中的位置？一定要體驗一下完全的結構化開發，理解一下結構化開發的痛才能夠移動到目前的位置？直接引入敏捷的思想是否會出現拔苗助長的現象：即開發人員沒有相關成長體驗、無法理解敏捷開發而對它存在牴觸？
用乙個詞來描述我這幾年開發對文件的體驗，最貼切的也許就是「雞肋」了：
1、食之無味：在上一家公司體驗過完全的結構化開發，對文件要求相當嚴格，開發過程中花費了巨大的精力寫了大量的文件。而到了專案後期，隨著需求和設計的更改，保持最終的程式和文件的同步又耗費巨大的精力。關鍵是，開發完畢後，大部分文件就被束之高閣，不見天日 了。
2、棄之可惜：在這家公司也遇到過時間很急，匆匆忙忙開發而沒有文件的專案。到維護期時，做了什麼，怎麼做的都無從查起。特別是遇到人員流動的情況，更加難於處理。
之前寫過一篇文章：
軟體開發過程文件如何寫作？——「文件==雞肋」？
也許應該利用「二八定律」來對待文件：花20%的時間來記錄文件，獲得80%的價值。至於另外20%的價值，也許花費80%的時間，這一塊可以放棄。關於如何寫這20%的文件，可以參見上面的這篇文章。
這是乙個比較沉重的話題。
每年總有那麼一段時間，和自己工作多年的同事要離開。其實這也是沒有辦法的事情，公司的規模，成長的空間和機會決定了他能夠留住多少人。要想留住更多有經驗的人，必須要有大的發展才可以。至於如何才能有大的發展，涉及的因素相當多。如果真的有這樣的機會，我想很多人才還是會選擇留下了的。在乙個公司成長壯大的過程中，會產生很多的機會，包括職位，技術，物質等各個方面。
加之整個行業風氣有些浮躁，小公司在人才問題上有些傷不起。
在招聘方面，主要的渠道還是應屆畢業生。小公司在校園招聘上處於劣勢，無論是薪水，福利，品牌。即便是其他一切都相當，我想很多學生還是會選擇大公司。所以我們只能招聘大公司「挑剩下的」。不過這個不是什麼問題，多年的經驗讓我們發現「人才是培養出來的」。只要畢業生愛學習，會學習，踏實，招過來好好培養一下，在工作中多給他們一些機會，他們一般情況下都會成長的很快。我總是感覺（也是我個人的體會），小公司提供給新員工成長的機會，可能會比大公司要多，特別是在技術方面。
不要擔心這樣的團隊是取得成功瓶頸。看一下《團隊之美》中對醜陋的團隊的描述，看一下他們要如何才能戰勝明星團隊。另外也可以參考一下劉邦的創業團隊：創業的首要因素。
一家小公司的文化很多都取決於它的創始人，應該是創始人性格的寫照。
乙個企業最難改變的也許就是文化了。想在乙個企業中建立乙個文化迥異的團隊是乙個非常大的挑戰，要面臨大環境的同化，非得有強大而堅韌的影響力才可以。
敏捷倡導團隊文化
需求在不斷地變更，客戶的權力接力棒在不斷地轉接，很多的軟體開發企業的領袖都選擇敏捷開發作為其軟體過程，那麼在打算實施敏捷以前先得知道是否具備敏捷的一些潛質，敏捷的本質又是什麼？而我們的建議是不要讓敏捷成為混亂的乙個藉口，這同時也是軟體架構師可以考慮的問題。一般而言很多人都把2001年敏捷聯盟大會的成...
Naresh Jain談印度敏捷
naresh jain是印度敏捷軟體社群的創始人，也是即將來臨的敏捷印度大會的主席。我們聯絡了naresh，討論了印度公司敏捷方法的應用現狀以及前路幾何。u0026 xd n infoq 你覺得敏捷在印度的應用現狀是什麼樣子的？u0026 xd n u0026 xd n naresh jain 很瘋...
敏捷轉型（2） 企業文化
一直以來，許多企業進行敏捷轉型，不少轉型推動者其本身都有豐富的專案管理經驗，認為找到乙個流行的敏捷框架 比如scrum 就能把敏捷轉型做好 這太理想化了。企業文化是企業的靈魂，是推動企業發展的不竭動力。它包含著非常豐富的內容，其核心是企業的精神和價值觀。這裡的價值觀不是泛指企業管理中的各種文化現象，...