關鍵字：項目管理 專用軟件
適用于：專用軟件開發的項目管理，與通用軟件不同，與大眾消費軟件不同。涉及甲方、承建方。
觀察項目的三個指標：時間、預算、質量及功能完整性。
失敗的項目一般體現為：超時、預算超支、犧牲了部分功能或質量。徹底失敗的項目，就是一個最后壓根沒有完成的項目，比如爛尾樓。
首先，我們討論其中的一個指標，時間。
每個人對時間的理解不同，同樣在項目里面的每個人對項目的時間理解也是不同的。
1、 公司， 希望項目在最短的時間內完成，這樣時間和預算都是最小的。當然能做到的項目少之又少，業內有數據的。
2、 項目經理（為行文方便，暫稱為PM，下同）， 希望項目的計劃時間盡可能地長，這樣才有機會應付各種突發事件和不可抗的影響，畢竟很多原因是客觀存在的。墨菲定律。
3、 功能模塊小組長(如.....等，暫稱為小組長)， 一方面承受著項目經理的壓力，一方面又承受著來自基層開發人員的壓力。PM會要求小組長以最短時間完成所負責的部分；開發人員則很反感長期加班、高度的壓力感。
從過去的一年多來看，在時間要求方面，我們公司的意愿并不強烈。當然并不是強烈就可以解決的，后面會講到，這是本文的重點。
在我們公司，最后決定項目時間長短的關鍵，是開發人員。在人數不變、人員不更換的前提下，每個開發人員的產出是固定的，至少目前來說是固定的。加班，也不會有更好的改善，原因已經在我以前的郵件中說明過了。
那么，從上至下形成一種新的強制性時間要求，會不會有效呢？事實上，不是沒人試過，結果估計并不理想。程序開發是一種腦力勞動，決定一件任務完成所需時間是由程序員的腦袋決定的，甚至任務完成到什么程度，如果不花費大力氣的檢查也是不會輕易能發現的。這點有過中層管理經驗的人，應該都清楚。例如，管理人員要求用三天完成某個新功能，開發人員說至少要一周時間，即使最后管理人員令開發人員妥協了，他得到的也很可能是一個半成品——能用，但有缺陷；或者表面功能完成了，主線功能有部分沒有完成。
換人吧，中國程序員遍地都是，這不是問題的關鍵，所以換人作用不大。新人很快會被同化。那全換吧？全換是什么概念，換到哪個級別，這是個Big Question。而且還有另外一個問題——知識傳承。弄不好，傷筋累骨，結果還不一定就能如愿。
那么，問題是不是無解了呢？ 不知道，我也沒有經驗，這里只能提供一點看法，周末不想逛街，就寫點東西，分析一下身邊的問題，說得不對，就按一下DEL，不會太費事。就當是閑聊吧。
接著……其實還有一類人的時間，或許他們的時間要求才是最值得研究的。
4、 甲方(客戶) 一般地，政府作為甲方，內部意見并不完全統一。我們作為承建方，可能要配合那些支持我們的某些甲方代表（暫稱友好方，下同），另一方面也要考慮到對我們不太支持的另一些人（暫稱反對方）。很可能看起來無關緊要的一個小員的一句話，就會對項目產生不可挽回的影響。
甲方內部的友好方和反對方，他們的時間要求是不一樣。反對方，在具體開發的過程中會有一些不配合，另一方面對項目完成的時間要求又會格外的嚴格。所以，我們的時間表，以達到甲方內部的反對方的時間要求為最優，以達到甲方內部友好方的時間要求為及格。如果我們在開發中，處處以友好方的時間表作為自己的時間表，完全不預留安全時間，那么到最后我們會非常被動。
甲方的時間表對我們的可能影響包括：
A、 要弄清楚甲方真正的時間表，尤其是反對方的，并傳達到公司內部每一個相關人員，所有計劃都就應按這個時間表走。（反觀我們，一方面我們只考慮友好甲方的時間表。另一方面，現在整個時間表其實已被開發人員劫持，我們的計劃是按開發人員人數×每周工作量攤開的，呵呵。)
B、 系統主要功能的真正完成，是真正完成，需要與客戶多次反復交互、反復調試修改。第一次提交的版本，完全不能算是最終版本。對于具體的某個功能，或對于整個系統來說，都是這樣。（反觀我們，我們可能無法在客戶要求的時間表之前（之前！）提交版本，即使提交了，也是首次提交，而非經與客戶反復聯調過的版本）
C、 準確把握業務需求，還要準確地把握客戶的非業務需求（如性能、推動試運行、UI易用性人性化、配套的培訓等等）。準確地把握這兩件東西，將會對開發效率，乃至于項目進度都會產生極大的助益。（反觀我們，我們現在的絕大部分兵力，都投在研發環節，投在客戶身上的時間實在不夠，下面還會著重提到。）
D、 公司應該有自己的時間表，產品研發計劃應與市場運作聯動。如獲取業內行家的好評，需要我們及時發布可用的、漂亮界面的、穩定的、功能完整的版本；如搞財政系統內的推介會，我們也需要這樣一套東西。對于我們沒有的系統，我們應該有演示版本，而演示版的制作，也需要公司有專門的部門提前研究潛在的客戶要求、業務需求。
E、 產品研發的進度，任何時候都應該有5～10％的彈性。不是說要把時間表隨意向前一調就叫彈性。（如果所謂的時間表到了一點動靜都沒有，下次開發人員也會學精的。同一個老鼠夾都會給老鼠識破，何況是自以為天下最聰明的程序員們呢。這是事實，不止一次發生了。比如說1月1號系統上線，1.1到了什么事也沒有。結果才知道原來甲方要求的是2月1號上線。而甲方給上級的承諾是2月15號。雙重忽悠！下次再說某月某日上線，大家就心里有底了，反正還有一個半月。忽悠的反作用。要么，就說1.1是我們上線第一次全面測試；1.15再做一次全面測試；2.1如果有時間就做第三次全面測試。我們的要求是最少做兩次全面測試。這聽起來都會好一點。）而是需要我們真正掌握產品研發中哪些因素在影響我們的開發進度，如何激活這些因素，在必要的時候為我們所用。比如說建立一套量化的、可監測的指標系統，在需要時加入一些物質激勵，讓各項指標在固定時間內得到實質性的增長。（如在服裝廠，假設剪線工段是瓶頸，平時一個剪線工每天可以剪100件牛仔褲的線頭，趕單的時候只要提出每人日產量達到150件，每件的單價提高20％。那么用一個瓶頸工段的費用，激活了整個生產線。前提是有指標衡量，而且知道哪一個工段是瓶頸。我家里是曾經做牛仔褲的，且家鄉共計有1000多家牛仔褲公司，這是實例。）
F、時間表至少應該有兩份，公開也無所謂。一份為最優時間表，一份為合格時間表。項目整體時間，或具體的小項任務都應該有。Time is money. 報價1000萬的項目，用500萬/年成本×1年完成，跟用250萬/年成本×2年完成，其結果是截然不同的。推薦高德拉特的《關鍵鏈――突破項目管理的瓶頸》P53，第九章，其中有“安全時間”的討論。 [NextPage]
下面討論一下具體問題
××做為一個專用軟件開發的公司，內部事務可分為兩類：
１、銷售 促成客戶采購決策。關鍵字：采購。
２、交貨 開發并保證客戶順利收貨。關鍵字：收貨。
包括采購前試用、采購后交貨。因兩者在實際工作中沒有質的區別，所以統一討論。
交貨，可以說是我們當前絕大部分工作的目標。
根據具體工作的復雜度，可將它分兩個部分。如果這兩部分的復雜性沒有一定的當量，那么以下的討論將失去意義。劃分如下：
一、客戶部分；（負責人：項目經理）
目標：在低于報價的預算成本、在既定的時間內，保持主要功能完整性的基礎上，讓客戶滿意并保證順利收貨。
重點：真正搞清楚客戶需要的是什么？包括業務需求、非業務需求等。
難點：客戶
負責人職責：
泡在客戶那里，研究客戶。
為研發部門，提供清晰、完整的需求文檔及時間表。
推進安裝聯調、試運作的進展。
負責產品階段的質量測試檢查。
二、研發部分；（負責人：研發經理）
目標：更好地實現需求，完成研發任務。
重點：如何更快更好地完成開發。
難點：技術細節、需求變化、框架設計、技術人員管理
負責人職責：
分析需求文檔，設計實現方案。
管理開發人員的日常工作。
提供研發進度表。
負責開發階段的質量測試。
理想的模式及比例：兩邊的圈一樣大
我們當前的架構安排：（沒有專門的客戶代表。少量的客戶接觸+大量的技術細節）
兩個階段各自不同的復雜性，決定了這兩部分工作不能由同一個人負責，因為一個人的精力不可能應付這兩種復雜性。同時關注兩個領域，意味沒有關注。
項目經理的工作焦點是客戶；研發經理的工作焦點是技術。一個將工作重點放在技術細節的項目經理……或者相反，對于公司都可能是一個災難。是不是如此，我們只要判斷一下，或詢問一下，就可得知。這種錯位，一般有以下表現：
a、客戶的意志，在公司內部沒有人傳達，或傳達失真。做過市場的人就知道，客戶代表往往在公司內部充當著客戶利益的代言人，會為客戶催單。對于產品的質量問題，往往比研發人員、生產人員更加敏感。因為大家的立場不一樣，技術人員對于自己的作品往往有著非理性的感情，而客戶代表一般沒有這種感情，他基于公司與客戶的共同利益，往往先于客戶在公司內部處理掉一些可能會令客戶不滿的內容。
典型地，客戶要求的時間表，對于一個平時聚焦在技術細節的經理，他往往傾向于以技術上的客觀原因，反對客戶的時間表，或為項目的延遲提出純技術性的原因。對于客戶要求的需求變更，往往有抵觸心理。這點在其他軟件公司有時表現成為一種公司內部的沖突，市場人員與開發人員的沖突。這種沖突是一種良好的現象。說明立場、利益在沖突，這種沖突在公司內部發生，總好過在客戶與公司之間發生。
所以，當客戶要求的時間表發生延遲的時候，技術經理和客戶代表的態度是截然不同的，雖然他們的公司立場可能是一致的，但關注點卻是完全不同的。技術經理更傾向于忽略這種延遲的重要性，而表現出一種麻木感。這對于客戶來說，很可能是致命的。對于判斷項目的實質進展，公司內部與客戶常有截然不同的定論。
b、公司內部沒有人真正掌握客戶的需求。我是指此時此刻的真正需求，這不是資深的行業顧問，或完整的項目協議書能夠體現的。
典型地表現為，研發人員經常會因為客戶的需求變更而抓狂。為什么會這樣？皆因沒有人真正超越技術層面，去研究客戶的需求。客戶的需求有功能上的需求，也有非功能性的需求，對于不同的需求有著完全不同的優先級和完全不同的時間表。
不了解客戶，才會被客戶牽著走，才會對于客戶要求的一些變化感到突然、無所適從，才會被不斷新增的需求掩埋，即使很多需求是關聯的，甚至是同一件事情不同的面。
c、所有人對于產品的質量都不敏感。不會有人跳出來說，我們的產品就是垃圾，那我們就要警惕了。據我所知，在做外貿的工廠中，跟單人經常會跟車間的負責人吵，最常用的話就是，這種垃圾，你叫我怎么跟客戶交待啊？多悅耳的話語，至少對于老板來說是這樣。
我們的系統，有沒有人跟你講過很慢啊，界面很難用啊，功能很不穩定啊？如果沒有，小心了！
以下為建議部分
公司架構服務于公司的目標，也服務于客戶，而不是服務于公司歷史，最多只受歷史的限制。
所以，我個人覺得應劃分為以下四大部門，如行政/財務/人力/后勤等功能性的部門就暫時忽略不談了。
一、市場銷售部（商務部、市場部、銷售部、營銷中心，都一樣了……）
負責促成客戶采購決策傾向于××公司。
……
二、客戶項目部（項目部、客戶部……什么好聽、習慣都可以，把握重點就好）
負責在常駐客戶所在地的項目管理工作：
１、為研發部門，提供清晰、完整的需求文檔及時間表；
２、推進安裝聯調、試運作的進展；
３、負責產品階段的質量測試檢查；
４、協助推進商務工作的開展；
人員組成：（除市場人員外，全部歸PM旗下的編制） [NextPage]
１、PM;
２、各系統的需求代表；（新職位，由組件派員，由公司專門培訓后派出。也可解決部分技術問題）
３、實施人員；
４、產品質量檢測人員；（測試員）
５、客戶代表（市場部派員）
６、配置人員；
三、研發中心（各組件組、研發項目組、開發部……）
負責產品研發：
１、分析需求文檔，設計實現方案。
２、管理開發人員的日常工作。
３、提供研發進度表。
４、負責開發階段的質量測試。
人員組成：
１、研發PM;
２、設計人員（當前的條件，可由PM、副PM負責）
３、開發人員；
４、開發測試人員；（新職位，偏測試的開發人員）
５、配置人員；
四、質量部
負責對公司內所有產品的質量指標負責（新職能）、規范公司研發過程：
１、設計規范過程，并定期評估各部門的過程規范水平、效率瓶頸。
２、監控各部門過程規范的執行情況，定期匯報；
３、設計公司的質量監控指標體系；
４、推動公司所有產品的質量指標；對產品的質量水平負責；
５、負責項目組、研發中心的測試人員的培訓，并負責業務上的指導管理；
６、將測試階段前推至需求階段；
７、構建公司的知識共享、知識傳承體系；將公司知識資產以物理方式保存下來；
８、負責培訓各部門的配置、數據庫管理人員，提供業務上的指導管理；
人員組成：
１、部門經理；（專職）
２、……暫時沒有，呵呵。看需不需要，可考慮增加人手支持。
新架構需要的輔助制度、工作方法規定……
１、項目組與研發中心的溝通標準。原來的項目管理和研發中心是基本二位一體，很多時候，溝通的過程都是非標準的。
如定期由項目組向研發中心發送新需求清單＋缺陷清單，附上完整的需求文檔。這些文檔可讓在項目組內部的需求代表（研發中心派員，新增職位，見上）參與撰寫需求文檔。文檔可能需要來回溝通，但最后應有一個標準的需求文檔、待完成清單。
研發中心，定期向項目發送研發進展表（針對新需求清單＋缺陷清單）。
溝通的周期，應盡量地小，最大不應超過一周，周三應該有一份非正式的清單反饋，縮小溝通周期以免影響項目進展。如有信息化的項目管理系統的公司，這些都是實時的，可以遲點再考慮。
２、研發中心新增設了“開發測試人員”，所以研發中心應對發布出來的產品保證一定的質量。所以項目組每周的缺陷清單，應抄送指定的行政人員備檔，每月統計各研發產品的產品測試階段發現的缺陷數量。
３、各項目組與研發中心的各組件開發小組，應制定標準的溝通人員清單。規定哪些問題，應由哪些人員來負責溝通。以前的經驗是，大問題由小兵來負責，小問題由項目經理來負責，完全混成一片。應做徹底的梳理和規范。保證溝通的有效性。對于沒有溝通協調能力、或溝通能力較弱的小兵（比如我），應盡量避免讓其參與到部門與部門之間、或跨地域之間的溝通，極影響溝通效率。
公司應規定哪些標準文檔、溝通內容，應由行政人員備份。以記錄項目進展和研發進展。定期發布各項目的實質進展報告。周期不應超過三個月，最佳為每月發布一次。文檔可由行政部來草擬（進展文檔就應該傻瓜到行政人員都可以統計，客戶也和行政人員水平差不多，如果行政人員看不懂項目到哪了，那么客戶也差不多），成稿之后，交給研發中心各組件負責人、各項目經理簽字，在公司內局部發布。
４、項目經理，應定期撰寫客戶對項目進展的要求及評價報告，此報告應站在客戶的角度撰寫。在公司內局部發布，以保持各部門對客戶態度的準確把握。
５、研發工作量化管理制度。較復雜，另文再詳述。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
