現實點，不要急!
算是咨詢服務：這間人數超過百人的公司，沒有基本的軟件過程。這種情形比較常見，公司技術負責人做過努力，但很難推動。這是最終建議的草稿，文字未經組織，直接寫完。思路的唯一優點是：現實，抓關鍵點。解釋了一些簡單的概念，非常初級，供大家參考。
從公司現狀來說，流程改進有三個目標：確保項目和產品研發工作高質量完成，大幅度降低人工成本，保障公司技術團隊的總體穩定。三者說白了，就是提升公司的營銷能力和降低成本的問題，技術永遠是為公司經營服務的。若不能達到這三個目標，就是在做樣子。改進過程中的全面折騰，虛耗人力、正常的項目實施受到影響，我一般稱之為：既無益，反有害。我所強調的，都是最低限度的東西，是影響成本、質量、響應速度的關鍵點，期望做最少的事情，實現平穩過渡，不沖擊現有部門架構、不影響現行經營。
一、必須立刻將技術團隊和實施團隊分開：
1、怎樣分開：
現狀：我們以XX行業為例，同一個產品，不同地市、縣幾乎都作為單獨的項目，一到三個人負責，很多情形下，技術人員在現場編程，實施人員和銷售，對客戶新增需求經常承諾難以達成的時限。
合理的安排應該是：行業部門篩選主力程序員，成立項目組，集中在公司。軟件將划分成數個區塊，分別指明數名程序員承擔前端、后端的開發工作。行業部門的其他人員，包括未能進入項目組的初級程序員、新人，作為實施人員。初級程序員在公司期間，也會承擔少量的編程任務，作為項目組的后備補充人員，熟悉之后有可能進入項目組。新錄用的初級程序員，只能進入實施小組。項目組人員，原則上不到現場。
工作的流程：實施人員收集用戶需求、將需求和用戶時限要求書面形式報項目組，可向客戶承諾完成，但不得第一時間承諾時限。項目組評估后，決定具體時限、哪些功能可說服客戶暫緩，一到兩小時內文字回復。實施人員再據此與用戶落實。這樣的流程，既避免盲目承諾無法做到，又不至於影響營銷競爭力，規范的流程相反會令用戶更加認同。
2、為什么要分開？
我們經常聽到一些公司經理或技術負責人，抱怨手下完全沒有可用之人，幾乎所有的技術人員都不合格。這種抱怨是普遍現象，但真正的罪魁禍首，不是技術人員，恰恰是這些在抱怨的、高高在上的管理者。
每個人的能力是有限度的，按照現在的划分，一個技術人員，需要精通(不是了解)：整個軟件系統的所有業務需求、前端編程、后台編程、理解原有程序每個部分的代碼、懂得所有性能和安全方面的技巧。更要命的，是所有這些，必須在非常短的時間內做到，在現場工作也很難得到同事的支援。這種要求難道不變態嗎？
按照改進的安排：程序員只需要了解軟件系統一部分的需求、前端開發人員只需要使用他掌握的技能、遇到不擅長的問題可即時請教同事，這是現代工廠的流水線模式。實施人員根本不需要編程，工作壓力也大幅降低。這是從用人的角度，必須做到的，技術團隊只有在這種狀態下，才能保持穩定，新人才能很快上手工作。
人數的需求大幅降低：幾個人在公司負責軟件某個區塊，面對全省客戶，做自己熟悉的事情。
人員素質的要求大幅降低：初級程序員也是能夠勝任工作的，不一定非要名校本科、碩士之類。
人員的穩定性更容易保證：主力程序員技能的起步要求大幅降低，出差不多，工作中能隨時和同事交流，資金投入傾向他們，這樣工作的情緒會大為改善，生存狀況向好，穩定性容易保障。過於強調吃苦耐勞、要求技術人員以健康為代價奉獻，這是不切實際的幻想。不能保障體面生活，如何能要求對方的忠誠度？
3、如何平穩過渡，降低對現有架構和項目實施的沖擊？
這種改進，不影響公司的部門結構。改進的結果，除了降低對項目組和實施人員的工作技能要求、減輕工作壓力之外，對所有成員無現實利益損失。
實施的步驟，以篩選骨干程序員，組建項目組為起點。指定兩名候選人，由項目組決定項目組長。骨干程序員通常薪酬更高，視情況增加適量津貼。對實施人員，不安排整體培訓，提供文字形式的業務知識、溝通技巧、工作流程與紀律、需求采集、系統使用等手冊，並安排專人答疑。
二、必須立刻改進技術人員聘用條件和流程：
結合行業部門架構的改進，程序員聘用條件和流程，必須相應變化。
1、招聘條件降低為有一次實際項目經驗、不限學歷：
2、筆試以自編的基礎題和項目過程描述為主，絕不出難題、偏題，多出選擇題、填空題。
3、面試的核心目標，是弄清項目經驗的真實性、對方承擔的真實職責。面試不對潛力評估，這將在進入實施小組后在工作中考察。
4、在團隊相對穩定后，中層以上的關鍵崗位，將主要從現有人員中選拔提升，除特殊情形不對外招聘。
5、初級程序員不得直接進入項目組。在實施工作過程中，他們會理解業務、掌握軟件系統的操作，在公司期間承擔簡單編程任務，有助於技術能力提升。
現有模式存在的隱患，是人員會無止盡的擴張，上次提及的某個案例，投資100萬元在八個月用完、產品卻沒有研發完成的例子，其實和公司現在的狀況很相似。我知道公司目前資源雄厚，但現在同時做40個”項目”，60人尚覺得不夠，一年人工成本其實也有1000萬樣子。如果，不幸，公司接到了80個項目，人員又需要增加，但這個期間一過，增加的人員可以辭退嗎？辭退，影響公司骨干的穩定性，兔死狐悲。不辭退，如果今后一到兩年項目不飽和，這種成本如何承擔？天長日久，消耗和浪費的資金，並不是眼下拍拍腦袋，就覺得可以一直承受的。
尤其這種模式下，新增人員對產品質量、公司在客戶心目中的評價，經常會帶來損失，新手更多的時候是拖累項目進度，而不是人越多做事越多，新手至少有三個月對項目產生的是負價值，這是不可忽視的、無形的負面成本。
改進的模式：當接單較多人員吃緊的時候，實施人員是最好的后備力量。新招的初級程序員只能補充進實施隊伍，這樣就避免了在項目關鍵時期，因為新手的介入影響進度。
而初級程序員，最初做實施工作，有助於了解業務。在公司期間，適當承擔少量編程任務，有助於提升技術能力、增進對現產品的了解。他們第一個明確的目標是進入項目組，一部分人可能因為溝通能力、需求分析能力，轉到相關領域，無法進入項目組且希望繼續做技術工作的，會因為待遇、興致問題離職，這是新陳代謝。
這樣能清晰的弄明白：哪些人是必須要盡量長期穩定的，哪些人可能具備需求分析、現場項目經理甚至售前能力，那些人是公司需要自然淘汰的。
三、必須立刻啟動源代碼版本統一管理：
從目前的情形來看，項目在省內不同縣市，或多或少都有不同。
沒有任何人能說清楚，每個縣究竟增加了什么功能，修復了哪些Bug，調整了哪些功能。
如果存在30個不同的版本，程序員每到一個新的地方，面對的任務往往不是他完全掌握的，他甚至難以理解為什么這個縣的版本里，會有這樣一串奇怪的代碼。
組織少量人力，將每個版本部署運行，然后存入源代碼庫，作為一個分支。每個版本，需要列出與主版本明顯的不同，並將其文檔化。之后，程序員臨時接到某縣的新增需求任務，幾秒鍾內即找到這個縣的分支，與主版本的區別也很容易看到文檔。所有修改都在同樣的分支存入，項目整個生命周期，某個版本對應唯一的一個分支，單是這樣，每個程序員至少要少花費半天的人工。大家其實都有體會，臨時送來的源碼壓縮包，說不准有多個，挑選、調試運行通過，往往需要2-4小時。
當程序員離職之后，由於他只負責軟件的一部分，同時是和多人負責的，對項目沖擊較小。新加入的程序員，透過源碼庫能清晰看到每次改動的內容，更容易立刻接手。
沒有源碼版本管理，是混亂不堪的。這種混亂不堪，在我看來，就是人力的浪費，本質上是資金的浪費，同時也是在用戶現場造成惡劣后果的主要原因。帶錯版本，到現場增加功能，卻發現幾處以前修復的Bug又冒頭，這時候找到原來的版本、再合並此次的修改，1個人天就浪費了，日積月累，絕不可輕忽。
四、必須立刻建立任務單制度：
很多項目經理，往往是粗略的要求，你做這項功能、他做那項，什么時間完成，一張嘴說話。這種情況，等同於靠天吃飯，5天后發現毫無進展的時候，項目經理能做什么？
因此，開發任務的划分，我本人的經驗，是不要超過半天工作量，給程序員一天時間。細致，導致的結果，是項目經理每天都會檢查完成情況，即時的調配人力。工作量看似增加，但項目經理是做什么的？下達命令之后，休息五天再來看結果？
至於公司技術負責人說：找不到能夠分配任務的人，指定誰分配任務，最后的結果是這個人一個人做了，其他人沒活干。
這是培訓的問題，多數情況一天能夠做到：每項功能，界面邏輯設計、頁面設計、頁面美化、數據層、邏輯層、邏輯層與頁面銜接、可能存在的服務接口、測試，根據復雜程度每個划分成1到3項任務，普通程序員能做到。現在覺得困難，是因為沒有確立規范，2個小時、一篇文檔和一個例子就能解決大部分問題。
對於任務單制度，目前只設立項目、功能、任務三個層次。Bug修復、疑難解決也作為額外的任務，分配到人。
紙張傳遞費時且不安全，對於asp.net方向，我建議使用Tfs管理整個生命周期，Tfs能夠在局域網和互聯網上完整的支持上書5種任務的共享，項目經歷隨時能看到每項工作進展程度，程序員每天能在開發環境中找到他的任務。
這些功能、任務、Bug、疑難，本身和Tfs源代碼管理是結合的，你完成任意一項任務，都能找到對應的修改是哪些，能夠看到開發過程中，所有代碼的變更歷史。
好的制度，要有可行、簡單的工具做支撐。項目管理本身是有成本的，這種成本會蔓延到每一個程序員身上，盡量的簡單、盡量的抓住核心，非常重要。
任務單制度建立之后，對每個程序員的工作績效，將有非常清晰的客觀判斷。
誰是對公司最重要的？誰一直在混時間？一目了然。光靠管理者的印象，是非常不靠譜的，人性中最重要的特征：是喜歡他人逢迎。情感決定項目經理判斷的成分，遠比我們想象的多。很多管理者，總強調”我不喜歡聽好聽的，我希望一切就事論事直截了當”，這個，只有聖人才能真正做到。據我所知，當代的中國，聖人這種動物早就不存在了。
解決問題的方式只有兩點：客觀和透明。任務單制度，是一種客觀的評價，每個人做過哪些事情，按照他每項”一天“這種度量單位的工作結果記錄在案，每一個bug的責任人，代表不同人的工作質量，每一個疑難的解決，代表技術人員的分析、學習能力。使用項目管理工具，所有項目組成員都能看到每個人的任務和完成情況，這是透明的力量，項目經理絕無可能過於不公平，數據在那里，每個人都知道，不平則鳴是最好的矯正。
五、不急：java和Asp.net雙團隊問題要慎重
建立單一團隊的代價，包括：
1、舊項目維護問題，會影響客戶關系，造成市場流失。
2、舊項目會投入人力重新開發，但新開發的產品是否能穩定運行，替換舊版本，周期較長。
3、技術部門應以營銷部門為上帝，在遇到商業前景巨大的單子時，java團隊很難撤銷。
只有滿足如下條件，才能考慮單一技術方向問題：
1、舊項目生命周期有限，短期內將被替換。
2、有新的項目，允許我們重新開發新版本。
3、有所為有所不為，新的、要求用java的項目，無關戰略的要勇於舍棄。