自從寫了關於《三五個人十來條槍 如何走出軟體作坊成為開發正規軍》走出軟體作坊：三五個人十來條槍 如何成為開發正規軍（二），系列文章後，收到了很多網友的評論，也收到了很多網友的疑問請教。而大部分人都已經當上了專案經理，手下有個2-3個人或5-6個人。少部分人還在上學或者才畢業出來1-2年，詢問的還是學什麼語言和什麼才是核心技術的之類問題。
從接到的請教來看，許多中國國內軟體公司都是以專案為主，有單做單，沒單就幹靠，靠的時間長了老闆心毛了就裁人，來活了就招人，就這樣反反覆覆。所以，大量的公司沒有開發部（因為除了銷售，開發部從開發到實施到支援都全做），當然也沒有開發部經理，只有專案經理。更不用提技術總監和CTO。即使有個技術總監的頭銜，也是為了給客戶的名片，而手下也就5-6個人，專案一來，技術總監也需要編碼和實施，其實就是一個專案經理。
在國內，專案經理這個詞如此常見。均為實施專案經理和開發專案經理混為一身，統稱專案經理。雖然，開發和實施是軟體產品的不同階段，不同階段關注的重點也有不同。但既然都為專案經理，那麼其關注點也有共性之處。
專案經理，主要職責是：
專案範圍定義
專案計劃制定、分解、分配、協調、彙報
專案質量控制
專案需求變更控制
國內專案經理一般沒有人事權和財務費用權。老闆給分配什麼人就帶什麼人，自己只是一個最能幹的工人加工頭而已，當然更沒有財務費用權，要想請客戶吃頓飯，當然需要和老闆打報告（自己團隊想休息娛樂會，只能聯機打把遊戲，想團隊吃頓飯，不可能給費用的）。
不過，從現狀來看，國內現在的專案經理，連專案範圍和專案需求都無法控制。老闆說什麼就是什麼，客戶說什麼就是什麼，使用者說什麼就是什麼，只要自己和自己的團隊能做，並且不累死或者不跑路，能做的都照單全收。當然，做什麼，什麼時候做完，都不屬於自己管理和控制，當然，專案計劃的制定由專案經理制定，就是虛設了。唯一剩下的，就是專案質量控制：開發有程式碼的質量，實施有實施的質量。
接到網友很多詢問，都問我工具的使用情況（對組織結構和流程問的極少，可能覺得都自己改變不了，根本沒有機會實現，道理能不能行的通也就不用去想了，因為想了也白想）。問我現在的團隊使用什麼UML工具、什麼壓力測試工具、什麼資料庫設計工具、什麼版本管理工具、什麼需求管理工具、什麼進度管理工具、什麼BUG管理工具。
在他們眼裡可能覺得，一個團隊，只要用上先進的工具就會成為一支裝備了機關槍的軍隊。就跟我們的客戶一個想法，只要上了這套ERP軟體，我們的管理就上了一個臺階，我們的盈利就會提升。這個想法，真是奇怪，就如同一個人拿了一把屠龍刀，人沒砍到，倒是把自己砍傷了。一把好廚子的刀，到了不會做菜的人的手裡，仍然做不出好菜，就這麼淺顯的道理，但大家還在幻想。
許多人想得到答案，覺得一個正規的開發團隊應該使用是Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。
但其實，我們也並沒有使用這些工具。
我一直在商業軟體公司工作，也深深的明白自己的責任就是幫助公司最大限度的利潤最大化。而利潤最大化的實現手段就是最小的成本、最少的人、最少的時間、最簡單的方法達到老闆的目的，拿出合適質量和功能的產品，包裝好，賣上儘可能高的價格。只要能賺到老闆想賺到的錢，達到老闆的目的，只要不影響這個目標，不影響大目標，小磕磕碰碰自然難免，有問題解決問題，沒問題繼續前進。哪個企業沒個矛盾沒個利益集團，哪個企業沒個問題沒個埋怨，有人愛自然有人恨。就是這樣，這樣是常態，不是異常。所以，我使用工具，一般都是在各種手段我都使用的差不多的情況下自然使用的，而非為了正規而正規，而是為了解決問題，而且是很有效的解決問題，而且是最簡單的解決方法。我從來不為面子工程付出成本。
我們最先遇到的問題當然也是軟體質量的問題。軟體的質量問題，引起了實施培訓、實施推動上線的困難、客戶使用效果的困難、支援費用的增高、支援難度的加大。最後實施部不願意實施、銷售部不願意銷售、支援部直接把電話轉開發部。所有人對把自己工作的不順利和不順心歸罪到開發部。當然，這樣的開發部，不被老闆開掉才怪。
於是我空降入主了。
我採取的第一個策略就是：專門劃出一個輔助開發人員（因為他對客戶需求也不瞭解，講了3遍也不懂，寫的程式碼也考慮不周全，所以程式碼漏洞百出。不過這個小夥耐心還不錯，就是有些懶。看來懶人一般都耐心不錯。不過還是有些得過且過，做一天和尚撞一天鐘。就這麼個才。），讓他做技術支援兼測試。
過去是實施部有不少人，每個人都直接開啟發員的電話。支援部也是。客戶也是。老闆呢，不懂軟體也不深入操作研究軟體，卻從使用者角度老提意見，看到哪裡想到哪裡就直接給開發員打電話讓開發員修改，從最皮毛的字的字號到最深入的商業智慧問題，都提，而且讓立即改掉，其他所有人包括客戶提的都靠後。這樣，一個開發被干擾的無法工作，最後離職。
我劃出開發部專人支援後，規定流程。所有的需求，不管是哪個部門或哪個客戶，都歸口到他這個人手上。即使還有人直接打給開發員，包括老闆打給開發員的，開發員必須把需求或問題再並口到這個技術支援手裡，我來統一安排排程開發。
開發人員是消停了，可以安心按我的安排的進度和優先順序修改了。而支援小夥子呢，電話開始被打爆。幸好我給小夥子的指示是，都先接上記錄好，能不能解決，能不能快速解決，看自己能力，不著急，誰跟你急，你跟我說。於是，小夥子被吃了一顆定心丸。
小夥子一開始使用的是一個EXCEL。別人提的問題都自己記錄在裡面。但是弄到最後，我的手裡、小夥子手裡、開發人員手裡、支援人員手裡，都出現了不同版本的EXCEL。互相都說這個已經修改了，那個說沒有修改。這個說有多少BUG，那個說不可能。
於是，我上了第一個工具，BUG管理系統。不管是BUG還是需求還是建議還是疑問，誰想提，都提到這裡來，隨時記錄。不管你是出差還是在支援部坐班，都記錄到這裡來。凡不記錄者，一律不解決。
於是，天下太平。經過技術支援和開發人員努力，一個大風浪過去。利益衝突處於一個平衡或者可能隨時崩塌引來下一次衝突。
我於是給支援小夥子分配了另一項重要工作。測試。為了不讓你以後繼續享受折磨，那麼你必須卡好關。你自己卡不好，那麼以後的技術支援仍然很痛苦。小夥子為了自己以後能過上幸福的上班生活，於是測試做的不錯。所有測試出來的BUG也記入到BUG管理系統。 現在，開發人員工作量和工作質量有了量化，支援人員的工作量和工作質量也有了量化，給我安排計劃和考核人員和申請資源做了大量的支援工作。
所以，一個BUG管理工具，能把計劃、進度、質量、需求、BUG都能管理起來，而且能追溯，能考核，能統計工作量和工作質量。真是必備。
但是，接下來發現了一個問題。就是在修改的時候，老誤會客戶的需求。程式設計師一天在家裡面開發，不瞭解外面的客戶和在第一線戰鬥的實施人員到底想表達什麼。於是修改完，程式設計師覺得自己費了很大的勁，而實施人員和客戶卻非常惱火，一點不領情還發怒。最後，搞的開發人員和實施人員衝突不斷。
需求如何描述清楚，成了必須提上日程的事情。許多沒有經驗的專案經理尤其會在這一步犯暈。UML工具、資料庫設計工具，需求管理工具，能上的都上，最後也沒解決問題，把自己和自己的團隊累的半死。
我使用了PPT+WORD+腦圖+EXCEL的描述方法。
因為很多需求都是這個支那個叉出來的。程式設計師往往想的了這頭想不了那頭。這就是人的思考的周密性差異。
想讓人能從千萬絲絛中理出頭緒，於是腦圖軟體上場。把各個分支來龍去脈表現清楚。
到了描述某個節點的時候，PPT上手。一頁PPT相當於一個介面視窗。每頁PPT的圖形模仿了選單、輸入框、按鈕。按鈕按下，還可以跳轉到其他的PPT頁上，和軟體操作流程非常相似。
PPT讓程式設計師很直觀的看到未來軟體作出來是什麼樣子。關於PPT的詳細描述，如欄位，流程，特殊注意，特殊控制，都用WORD說明好。
遇到有報表功能的時候，用EXCEL把報表畫出來，讓程式設計師喜聞樂見。
這樣，從表及裡，從概要到詳細，從分支到關聯，都表述OK。客戶也能明白，程式設計師也能明白，實施人員也能明白，老闆也能明白（這點非常重要。雖然老闆不懂軟體，但他要干涉軟體，他如果不明白，他就不知道這幫傢伙到底在幹嗎，是在真正幹活還是在偷懶，到底工作量是大是小，軟體功能是複雜還是簡單。老闆如果不明白，老闆在給與資源和時間上就會很謹慎，處處提防。這是許多專案經理都忽略了大事。還拿UML做秀，誰也看不懂，誰也用不了，白花費時間畫那些好看的圖。這就是中國的現狀，我們站哪個山頭就唱哪個山頭的歌，有效解決問題提高銷售收入才是我們的根本任務，我們不抱怨不幻想踏實推進解決問題）。
於是，老闆的天平開始向開發部傾斜了。資源，當然就容易申請了。
畫這些EXCEL+PPT+腦圖+WORD，當然很費時間（我直到引進了日本外包開發過程管理才發現，我們的解決方法和強調質量的日本人的做法非常相似）。於是，我申請一個人，把過去實施的一個專案經理（還居然會寫點SQL，從資料庫查資料，調整個報表。實在太強了）調入開發部，專門編寫這些檔案。
開發部開始蒸蒸日上。專案經理、開發人員、測試兼技術支援已經到位。工具也已用的不亦樂乎，深入到了公司的每個部門。每個部門都按照標準描述方法和標準流程走。現在，連實施人員都會畫EXCEL報表格式、PPT介面。
軟體到位，就需要包裝，否則軟體就賣不上好價格。這是很自然的事情。幹啥都要個品相。漂亮的姑娘誰都喜歡。
軟體包裝，第一步就需要幫助檔案、視訊操作、解決方案、產品介紹、演示系統。當然，文案人員很快到位。美工美化也自然到位。能多賺錢幹嗎不做，老闆也不是傻子。誰喜歡賣一個土灰土臉的產品。
有了好的產品，出不去開發部也是個問題。只有自己內部人知道功能怎麼用，怎麼滿足客戶的需求，其他部門都不知道。許多人都不知道新功能和舊功能的改變。文件中都寫了，更新說明也有，就是沒有人看。還是打電話找技術支援，技術支援只能不斷解釋。問題又來了。
文案出馬。每次版本釋出，功能更新，文案反覆舉辦集中培訓，辦班，一批次一批次的培訓，百其不厭。
四套馬車，於是真正的天下太平了。
從此，開發人員和實施人員過上了幸福的生活。
後續記：
接到很多網友的評論，都說老闆不可能給資源的。說我寫的太理想。
嗯，如果你看完我的文章就直接找老闆要資源，當然是會被趕回來的。因為，你什麼都沒有做就開始要資源。
有人還說，公司就這幾條槍，能幹活的更是那幾頭蒜。根本不可能給你派人。
嗯，如果你思考的目標不是為老闆賺取更多的錢，那麼老闆不可能給你一丁點的，甚至還會把你幹掉。如果你覺得，這樣的老闆我還不伺候呢，那麼中國大部分都是這樣的公司，除非你轉行不幹這行了。要幹，就別混日子。想得過且過讓老闆公司倒閉，這個基本不可能。再說老闆倒閉了對你一點好處都沒有。
邁出你的第一步吧。不邁出第一步，你都會覺得這是不可能完成的任務。
想過幸福的生活，從現在就開始腳踏實地的動手吧。