關鍵字：項目管理 專用軟件  

　　適用于：專用軟件開發(fā)的項目管理，與通用軟件不同，與大眾消費軟件不同。涉及甲方、承建方。
 
　　觀察項目的三個指標：時間、預算、質(zhì)量及功能完整性。

　　失敗的項目一般體現(xiàn)為：超時、預算超支、犧牲了部分功能或質(zhì)量。徹底失敗的項目，就是一個最后壓根沒有完成的項目，比如爛尾樓。
 
　　首先，我們討論其中的一個指標，時間。

　　每個人對時間的理解不同，同樣在項目里面的每個人對項目的時間理解也是不同的。
 
　　1、  公司，　希望項目在最短的時間內(nèi)完成，這樣時間和預算都是最小的。當然能做到的項目少之又少，業(yè)內(nèi)有數(shù)據(jù)的。

　　2、  項目經(jīng)理（為行文方便，暫稱為PM，下同），　希望項目的計劃時間盡可能地長，這樣才有機會應付各種突發(fā)事件和不可抗的影響，畢竟很多原因是客觀存在的。墨菲定律。

　　3、  功能模塊小組長(如.....等，暫稱為小組長)，　一方面承受著項目經(jīng)理的壓力，一方面又承受著來自基層開發(fā)人員的壓力。PM會要求小組長以最短時間完成所負責的部分；開發(fā)人員則很反感長期加班、高度的壓力感。
 
　　從過去的一年多來看，在時間要求方面，我們公司的意愿并不強烈。當然并不是強烈就可以解決的，后面會講到，這是本文的重點。

　　在我們公司，最后決定項目時間長短的關鍵，是開發(fā)人員。在人數(shù)不變、人員不更換的前提下，每個開發(fā)人員的產(chǎn)出是固定的，至少目前來說是固定的。加班，也不會有更好的改善，原因已經(jīng)在我以前的郵件中說明過了。

　　那么，從上至下形成一種新的強制性時間要求，會不會有效呢？事實上，不是沒人試過，結果估計并不理想。程序開發(fā)是一種腦力勞動，決定一件任務完成所需時間是由程序員的腦袋決定的，甚至任務完成到什么程度，如果不花費大力氣的檢查也是不會輕易能發(fā)現(xiàn)的。這點有過中層管理經(jīng)驗的人，應該都清楚。例如，管理人員要求用三天完成某個新功能，開發(fā)人員說至少要一周時間，即使最后管理人員令開發(fā)人員妥協(xié)了，他得到的也很可能是一個半成品——能用，但有缺陷；或者表面功能完成了，主線功能有部分沒有完成。

　　換人吧，中國程序員遍地都是，這不是問題的關鍵，所以換人作用不大。新人很快會被同化。那全換吧？全換是什么概念，換到哪個級別，這是個Big Question。而且還有另外一個問題——知識傳承。弄不好，傷筋累骨，結果還不一定就能如愿。

　　那么，問題是不是無解了呢？ 不知道，我也沒有經(jīng)驗，這里只能提供一點看法，周末不想逛街，就寫點東西，分析一下身邊的問題，說得不對，就按一下DEL，不會太費事。就當是閑聊吧。
接著……其實還有一類人的時間，或許他們的時間要求才是最值得研究的。
 
　　4、 甲方(客戶)　一般地，政府作為甲方，內(nèi)部意見并不完全統(tǒng)一。我們作為承建方，可能要配合那些支持我們的某些甲方代表（暫稱友好方，下同），另一方面也要考慮到對我們不太支持的另一些人（暫稱反對方）。很可能看起來無關緊要的一個小員的一句話，就會對項目產(chǎn)生不可挽回的影響。
　　甲方內(nèi)部的友好方和反對方，他們的時間要求是不一樣。反對方，在具體開發(fā)的過程中會有一些不配合，另一方面對項目完成的時間要求又會格外的嚴格。所以，我們的時間表，以達到甲方內(nèi)部的反對方的時間要求為最優(yōu)，以達到甲方內(nèi)部友好方的時間要求為及格。如果我們在開發(fā)中，處處以友好方的時間表作為自己的時間表，完全不預留安全時間，那么到最后我們會非常被動。
甲方的時間表對我們的可能影響包括：
 
　　A、 要弄清楚甲方真正的時間表，尤其是反對方的，并傳達到公司內(nèi)部每一個相關人員，所有計劃都就應按這個時間表走。（反觀我們，一方面我們只考慮友好甲方的時間表。另一方面，現(xiàn)在整個時間表其實已被開發(fā)人員劫持，我們的計劃是按開發(fā)人員人數(shù)×每周工作量攤開的，呵呵。)
 
　　B、 系統(tǒng)主要功能的真正完成，是真正完成，需要與客戶多次反復交互、反復調(diào)試修改。第一次提交的版本，完全不能算是最終版本。對于具體的某個功能，或?qū)τ谡麄€系統(tǒng)來說，都是這樣。（反觀我們，我們可能無法在客戶要求的時間表之前（之前！）提交版本，即使提交了，也是首次提交，而非經(jīng)與客戶反復聯(lián)調(diào)過的版本）
 
　　C、 準確把握業(yè)務需求，還要準確地把握客戶的非業(yè)務需求（如性能、推動試運行、UI易用性人性化、配套的培訓等等）。準確地把握這兩件東西，將會對開發(fā)效率，乃至于項目進度都會產(chǎn)生極大的助益。（反觀我們，我們現(xiàn)在的絕大部分兵力，都投在研發(fā)環(huán)節(jié)，投在客戶身上的時間實在不夠，下面還會著重提到。）
 
　　D、 公司應該有自己的時間表，產(chǎn)品研發(fā)計劃應與市場運作聯(lián)動。如獲取業(yè)內(nèi)行家的好評，需要我們及時發(fā)布可用的、漂亮界面的、穩(wěn)定的、功能完整的版本；如搞財政系統(tǒng)內(nèi)的推介會，我們也需要這樣一套東西。對于我們沒有的系統(tǒng)，我們應該有演示版本，而演示版的制作，也需要公司有專門的部門提前研究潛在的客戶要求、業(yè)務需求。
 
　　E、  產(chǎn)品研發(fā)的進度，任何時候都應該有5～10％的彈性。不是說要把時間表隨意向前一調(diào)就叫彈性。（如果所謂的時間表到了一點動靜都沒有，下次開發(fā)人員也會學精的。同一個老鼠夾都會給老鼠識破，何況是自以為天下最聰明的程序員們呢。這是事實，不止一次發(fā)生了。比如說1月1號系統(tǒng)上線，1.1到了什么事也沒有。結果才知道原來甲方要求的是2月1號上線。而甲方給上級的承諾是2月15號。雙重忽悠！下次再說某月某日上線，大家就心里有底了，反正還有一個半月。忽悠的反作用。要么，就說1.1是我們上線第一次全面測試；1.15再做一次全面測試；2.1如果有時間就做第三次全面測試。我們的要求是最少做兩次全面測試。這聽起來都會好一點。）而是需要我們真正掌握產(chǎn)品研發(fā)中哪些因素在影響我們的開發(fā)進度，如何激活這些因素，在必要的時候為我們所用。比如說建立一套量化的、可監(jiān)測的指標系統(tǒng)，在需要時加入一些物質(zhì)激勵，讓各項指標在固定時間內(nèi)得到實質(zhì)性的增長。（如在服裝廠，假設剪線工段是瓶頸，平時一個剪線工每天可以剪100件牛仔褲的線頭，趕單的時候只要提出每人日產(chǎn)量達到150件，每件的單價提高20％。那么用一個瓶頸工段的費用，激活了整個生產(chǎn)線。前提是有指標衡量，而且知道哪一個工段是瓶頸。我家里是曾經(jīng)做牛仔褲的，且家鄉(xiāng)共計有1000多家牛仔褲公司，這是實例。）
 
　　F、時間表至少應該有兩份，公開也無所謂。一份為最優(yōu)時間表，一份為合格時間表。項目整體時間，或具體的小項任務都應該有。Time is money. 報價1000萬的項目，用500萬/年成本×1年完成，跟用250萬/年成本×2年完成，其結果是截然不同的。推薦高德拉特的《關鍵鏈――突破項目管理的瓶頸》P53，第九章，其中有“安全時間”的討論。 [NextPage] 
 
　　下面討論一下具體問題 
 
　　××做為一個專用軟件開發(fā)的公司，內(nèi)部事務可分為兩類：
 
　?。?、銷售　促成客戶采購決策。關鍵字：采購。

　?。?、交貨　開發(fā)并保證客戶順利收貨。關鍵字：收貨。
        
　　包括采購前試用、采購后交貨。因兩者在實際工作中沒有質(zhì)的區(qū)別，所以統(tǒng)一討論。
 
　　交貨，可以說是我們當前絕大部分工作的目標。

　　根據(jù)具體工作的復雜度，可將它分兩個部分。如果這兩部分的復雜性沒有一定的當量，那么以下的討論將失去意義。劃分如下： 
 

　　一、客戶部分；（負責人：項目經(jīng)理）

　　目標：在低于報價的預算成本、在既定的時間內(nèi)，保持主要功能完整性的基礎上，讓客戶滿意并保證順利收貨。

　　重點：真正搞清楚客戶需要的是什么？包括業(yè)務需求、非業(yè)務需求等。

　　難點：客戶

　　負責人職責：

　　泡在客戶那里，研究客戶。
　　為研發(fā)部門，提供清晰、完整的需求文檔及時間表。
　　推進安裝聯(lián)調(diào)、試運作的進展。
　　負責產(chǎn)品階段的質(zhì)量測試檢查。
 
　　二、研發(fā)部分；（負責人：研發(fā)經(jīng)理）
        
　　目標：更好地實現(xiàn)需求，完成研發(fā)任務。
　　重點：如何更快更好地完成開發(fā)。
　　難點：技術細節(jié)、需求變化、框架設計、技術人員管理
　　負責人職責：
　　　分析需求文檔，設計實現(xiàn)方案。
　　　管理開發(fā)人員的日常工作。
　　　提供研發(fā)進度表。
　　　負責開發(fā)階段的質(zhì)量測試。
 
　　理想的模式及比例：兩邊的圈一樣大

　　我們當前的架構安排：（沒有專門的客戶代表。少量的客戶接觸+大量的技術細節(jié)）
　　兩個階段各自不同的復雜性，決定了這兩部分工作不能由同一個人負責，因為一個人的精力不可能應付這兩種復雜性。同時關注兩個領域，意味沒有關注。
        
　　項目經(jīng)理的工作焦點是客戶；研發(fā)經(jīng)理的工作焦點是技術。一個將工作重點放在技術細節(jié)的項目經(jīng)理……或者相反，對于公司都可能是一個災難。是不是如此，我們只要判斷一下，或詢問一下，就可得知。這種錯位，一般有以下表現(xiàn)：
 
　　a、客戶的意志，在公司內(nèi)部沒有人傳達，或傳達失真。做過市場的人就知道，客戶代表往往在公司內(nèi)部充當著客戶利益的代言人，會為客戶催單。對于產(chǎn)品的質(zhì)量問題，往往比研發(fā)人員、生產(chǎn)人員更加敏感。因為大家的立場不一樣，技術人員對于自己的作品往往有著非理性的感情，而客戶代表一般沒有這種感情，他基于公司與客戶的共同利益，往往先于客戶在公司內(nèi)部處理掉一些可能會令客戶不滿的內(nèi)容。

　　典型地，客戶要求的時間表，對于一個平時聚焦在技術細節(jié)的經(jīng)理，他往往傾向于以技術上的客觀原因，反對客戶的時間表，或為項目的延遲提出純技術性的原因。對于客戶要求的需求變更，往往有抵觸心理。這點在其他軟件公司有時表現(xiàn)成為一種公司內(nèi)部的沖突，市場人員與開發(fā)人員的沖突。這種沖突是一種良好的現(xiàn)象。說明立場、利益在沖突，這種沖突在公司內(nèi)部發(fā)生，總好過在客戶與公司之間發(fā)生。
        
　　所以，當客戶要求的時間表發(fā)生延遲的時候，技術經(jīng)理和客戶代表的態(tài)度是截然不同的，雖然他們的公司立場可能是一致的，但關注點卻是完全不同的。技術經(jīng)理更傾向于忽略這種延遲的重要性，而表現(xiàn)出一種麻木感。這對于客戶來說，很可能是致命的。對于判斷項目的實質(zhì)進展，公司內(nèi)部與客戶常有截然不同的定論。
 
　　b、公司內(nèi)部沒有人真正掌握客戶的需求。我是指此時此刻的真正需求，這不是資深的行業(yè)顧問，或完整的項目協(xié)議書能夠體現(xiàn)的。
        
　　典型地表現(xiàn)為，研發(fā)人員經(jīng)常會因為客戶的需求變更而抓狂。為什么會這樣？皆因沒有人真正超越技術層面，去研究客戶的需求?？蛻舻男枨笥泄δ苌系男枨?，也有非功能性的需求，對于不同的需求有著完全不同的優(yōu)先級和完全不同的時間表。
        
　　不了解客戶，才會被客戶牽著走，才會對于客戶要求的一些變化感到突然、無所適從，才會被不斷新增的需求掩埋，即使很多需求是關聯(lián)的，甚至是同一件事情不同的面。
 
　　c、所有人對于產(chǎn)品的質(zhì)量都不敏感。不會有人跳出來說，我們的產(chǎn)品就是垃圾，那我們就要警惕了。據(jù)我所知，在做外貿(mào)的工廠中，跟單人經(jīng)常會跟車間的負責人吵，最常用的話就是，這種垃圾，你叫我怎么跟客戶交待??？多悅耳的話語，至少對于老板來說是這樣。
        
　　我們的系統(tǒng)，有沒有人跟你講過很慢啊，界面很難用啊，功能很不穩(wěn)定??？如果沒有，小心了！
　　以下為建議部分 
 
　　公司架構服務于公司的目標，也服務于客戶，而不是服務于公司歷史，最多只受歷史的限制。
        
　　所以，我個人覺得應劃分為以下四大部門，如行政/財務/人力/后勤等功能性的部門就暫時忽略不談了。
 
　　一、市場銷售部（商務部、市場部、銷售部、營銷中心，都一樣了……）
        
　　負責促成客戶采購決策傾向于××公司。
　　……
　　二、客戶項目部（項目部、客戶部……什么好聽、習慣都可以，把握重點就好）
        
　　負責在常駐客戶所在地的項目管理工作：
　?。?、為研發(fā)部門，提供清晰、完整的需求文檔及時間表；
　?。?、推進安裝聯(lián)調(diào)、試運作的進展；
　?。?、負責產(chǎn)品階段的質(zhì)量測試檢查；
　　４、協(xié)助推進商務工作的開展；
 
　　人員組成：（除市場人員外，全部歸PM旗下的編制） [NextPage]
　?。?、PM;
　　２、各系統(tǒng)的需求代表；（新職位，由組件派員，由公司專門培訓后派出。也可解決部分技術問題）
　?。?、實施人員；
　　４、產(chǎn)品質(zhì)量檢測人員；（測試員）
　?。?、客戶代表（市場部派員）
　?。?、配置人員；
 
　　三、研發(fā)中心（各組件組、研發(fā)項目組、開發(fā)部……）
        
　　負責產(chǎn)品研發(fā)：
　?。?、分析需求文檔，設計實現(xiàn)方案。
　　２、管理開發(fā)人員的日常工作。
　?。场⑻峁┭邪l(fā)進度表。
　?。?、負責開發(fā)階段的質(zhì)量測試。
 
　　人員組成：
　?。?、研發(fā)PM;
　?。?、設計人員（當前的條件，可由PM、副PM負責）
　?。场㈤_發(fā)人員；
　?。?、開發(fā)測試人員；（新職位，偏測試的開發(fā)人員）
　?。怠⑴渲萌藛T；
　　四、質(zhì)量部

　　負責對公司內(nèi)所有產(chǎn)品的質(zhì)量指標負責（新職能）、規(guī)范公司研發(fā)過程：
　　１、設計規(guī)范過程，并定期評估各部門的過程規(guī)范水平、效率瓶頸。
　?。?、監(jiān)控各部門過程規(guī)范的執(zhí)行情況，定期匯報；
　?。?、設計公司的質(zhì)量監(jiān)控指標體系；
　?。?、推動公司所有產(chǎn)品的質(zhì)量指標；對產(chǎn)品的質(zhì)量水平負責；
　?。?、負責項目組、研發(fā)中心的測試人員的培訓，并負責業(yè)務上的指導管理；
　?。?、將測試階段前推至需求階段；
　　７、構建公司的知識共享、知識傳承體系；將公司知識資產(chǎn)以物理方式保存下來；
　?。?、負責培訓各部門的配置、數(shù)據(jù)庫管理人員，提供業(yè)務上的指導管理；
 
　　人員組成：
　?。?、部門經(jīng)理；（專職）
　　２、……暫時沒有，呵呵?？葱璨恍枰煽紤]增加人手支持。
 
　　新架構需要的輔助制度、工作方法規(guī)定……
 
　?。?、項目組與研發(fā)中心的溝通標準。原來的項目管理和研發(fā)中心是基本二位一體，很多時候，溝通的過程都是非標準的。
        
　　如定期由項目組向研發(fā)中心發(fā)送新需求清單＋缺陷清單，附上完整的需求文檔。這些文檔可讓在項目組內(nèi)部的需求代表（研發(fā)中心派員，新增職位，見上）參與撰寫需求文檔。文檔可能需要來回溝通，但最后應有一個標準的需求文檔、待完成清單。
        
　　研發(fā)中心，定期向項目發(fā)送研發(fā)進展表（針對新需求清單＋缺陷清單）。
        
　　溝通的周期，應盡量地小，最大不應超過一周，周三應該有一份非正式的清單反饋，縮小溝通周期以免影響項目進展。如有信息化的項目管理系統(tǒng)的公司，這些都是實時的，可以遲點再考慮。
 
　?。病⒀邪l(fā)中心新增設了“開發(fā)測試人員”，所以研發(fā)中心應對發(fā)布出來的產(chǎn)品保證一定的質(zhì)量。所以項目組每周的缺陷清單，應抄送指定的行政人員備檔，每月統(tǒng)計各研發(fā)產(chǎn)品的產(chǎn)品測試階段發(fā)現(xiàn)的缺陷數(shù)量。
        
　?。?、各項目組與研發(fā)中心的各組件開發(fā)小組，應制定標準的溝通人員清單。規(guī)定哪些問題，應由哪些人員來負責溝通。以前的經(jīng)驗是，大問題由小兵來負責，小問題由項目經(jīng)理來負責，完全混成一片。應做徹底的梳理和規(guī)范。保證溝通的有效性。對于沒有溝通協(xié)調(diào)能力、或溝通能力較弱的小兵（比如我），應盡量避免讓其參與到部門與部門之間、或跨地域之間的溝通，極影響溝通效率。
　　公司應規(guī)定哪些標準文檔、溝通內(nèi)容，應由行政人員備份。以記錄項目進展和研發(fā)進展。定期發(fā)布各項目的實質(zhì)進展報告。周期不應超過三個月，最佳為每月發(fā)布一次。文檔可由行政部來草擬（進展文檔就應該傻瓜到行政人員都可以統(tǒng)計，客戶也和行政人員水平差不多，如果行政人員看不懂項目到哪了，那么客戶也差不多），成稿之后，交給研發(fā)中心各組件負責人、各項目經(jīng)理簽字，在公司內(nèi)局部發(fā)布。
 
　　４、項目經(jīng)理，應定期撰寫客戶對項目進展的要求及評價報告，此報告應站在客戶的角度撰寫。在公司內(nèi)局部發(fā)布，以保持各部門對客戶態(tài)度的準確把握。
 
　　５、研發(fā)工作量化管理制度。較復雜，另文再詳述。