上面，我簡要談了項目管理中的需求開發(fā)和管理，這里就和各位以閑話家常的方式討論下項目規(guī)劃和項目監(jiān)控。項目規(guī)劃、項目監(jiān)控其實也是項目管理中比較核心的工作，也是很多開發(fā)人員最敏感的話題，因為這兩個東西與公司的領導和員工關系都非常的密切。

　　先從我以前的學校說起，以前我們學校有片荒地，當時的領導覺得學校應該搞綠化，于是組織在荒地上植樹，不到一年換了一個校長，這位校長覺得學校應該抓體育運動，決定再造一個足球場，于是把樹移走，造了一個足球場，再后來北京奧運會來了，學習為了迎合綠色奧運的理念又開始植樹，這就是沒有規(guī)劃和監(jiān)控的典型例子，結(jié)果是勞民又傷財。當然對于學校來說，有國家財政的支持，有資本這么折騰，可是對于小公司做項目來說，這么折騰幾下估計很快就要犧牲了。

　　事實求是的說大多數(shù)小公司在這兩個方面做得很少有令人的滿意的，小公司的老板其實也會意識到公司在項目規(guī)劃和監(jiān)控方面做得不咋地，但很少能做到有效的改進，其實這個也是有很多方面的原因的，以我自作多情的猜測主要有以下兩個原因，對于小公司，盡管盈利不是很多，但基本還是可以撐下去的，老板會覺得管他亂不亂，公司總之每個月還是有盈利的，少就少點吧，多干幾年自己的下半輩子基本有別墅有車了，所以比較保守，要是改革吧，萬一雞飛蛋打怎么辦?還是本分點好，小心使得萬年船。其實是對項目規(guī)劃和監(jiān)控其實需要大量的成本，老板覺得錢應該花在刀刃上，搞這些東西就是在務虛。再者更惡劣的老板有病就亂燒香，就有想想借助CMMI這個洋玩意治病的，其實很多老板都蠻喜歡CMMI的，CMMI就是假定人就是一個機器的部件，可以替換可以不停的運轉(zhuǎn)，總之管機器總比管人省心吧，結(jié)果是萬分的矛盾，銀子撒了一大把，收效卻甚微，甚至比以前更亂，大家做的都不開心。與其聽咨詢師們拿什么高深的方法論來瞎掰，不如我們談點實際的，想就以下議題來和各位消遣。

　　1 工作量估算

　　對于工作量估算很多項目經(jīng)理(老板)喜歡用數(shù)學公式來計算，可能數(shù)學公式更加的客觀和科學，ok,，看看市面流行的計算方法吧，最常見的是基于代碼行的數(shù)學模型，那么這里存在不少問題，工作量估算主要是為了在項目進行中進行有效的項目監(jiān)控，那么軟件開發(fā)尚未結(jié)束，誰知道最后的代碼行有多大?代碼經(jīng)常會被修改，那么修改的代碼算不算?如果算，那么代碼修改越多難道能說明工作量越大?代碼效率的區(qū)別也是很大的，假如一個10行代碼可以實現(xiàn)的東西被寫成50行，難道能客觀的反映工作量?還有2種比較高級點的方法是基于功能點和COCOMO的方法，那么我想問的是它們的公式中的系數(shù)該怎么定?那么不少咨詢師忽悠我說，根據(jù)自己的實際情況來定唄，那么我想問的是，算命是迷信，電腦意味著科學，那么用電腦算命算不算迷信?所以我是主張這里還是要靠人的經(jīng)驗來估算，大家可以在項目周會上對工作量進行充分的估算，在估算時要同時考慮到項目執(zhí)行的難度，根據(jù)經(jīng)驗給出合理的評估。

　　2 任務分配

　　大多數(shù)的做法是將整個項目劃分成一個個可以獨立執(zhí)行的原子任務，這些任務要劃分優(yōu)先級和難度，至少心理有個數(shù)，并且每項任務要制定負責人。那么問題就出在這個任務分配上了，軟件開發(fā)是一項智力創(chuàng)造的活動，如果按CMMI假設的那樣，在分配任務時忽略人的因素是萬萬不可取的，我就有血的教訓，不久之前做一個ruby的項目，然后開始在公司內(nèi)部隨便抓了幾個有點ruby基礎的人，也沒太顧忌別人的想法。做著做著，覺得他們有點心在曹營心在漢，平時還是抱著本 thinking in java看，做ruby也是在敷衍了事，結(jié)果是代碼質(zhì)量不行，需要大規(guī)模的修改。當然按理說員工應該服從公司的安排，做一樣就要做好一樣，但員工也有員工的規(guī)劃，你去叫他做他壓根就不喜歡的事只能說明管理有問題。

　　另外還有一個普遍性的問題是能者多勞，有個朋友剛進公司動手能力很強，也非常的積極，每次做項目都分給他最難最累的任務，做著做著也就厭倦了，這時老板會忽悠你說，你能力強，要挑起公司的大梁，以后公司壯大了給你個什么職位，我覺得這就是在扯淡，這就是我經(jīng)常見到的忽悠式的管理，很多管理手段完全靠人情，很多人都是在這種環(huán)境中被忽悠長大，到最后怎么樣?被忽悠了幾年還不是另謀高就了，所以指望人情化管理的公司很難長大。我覺得該講原則的地方就要講原則，在任務分配上給能力強的分配少而精的任務，而且要考慮到員工自己的想法，有些人想做java架構(gòu)師，你叫他做oracle dba就不合適，有些對ui設計感興趣，你叫他做系統(tǒng)分析員也不合適，有些人就喜歡搞技術，你硬要叫他做管理也是不合適。

　　3 進度管理

　　在做進度之前，一項最重要的任務是識別關鍵任務，很多進度表進行任務安排時將各項任務平均分的特點為覺得極不合適，有些任務比較難處理，而且許多后續(xù)任務依賴于該項任務，那么這項任務就應該配備更精良的人手和充裕的時間，依我的經(jīng)驗80%的時間都是在處理這些20%的關鍵任務上。這里還有個比較重要的問題是時間安排，我聽很多項目經(jīng)理說時間安排要盡可能的緊，也就是比預計要靠前，這樣員工才有緊迫感。我覺得這是不可取的，首先即使你按原計劃進行，八成也是要要延期的，那么這就會導致項目嚴重延期，長此以往，項目延期成了家常便飯，不延期反而不正常，于是大家都成了老油條，那么進度表不就是廢紙一張，毫無約束力而言嗎!我覺得根據(jù)實際情況指定個合理的進度表是比較重要的，或許你會說項目還是在延期，那我覺得是你項目估算沒有做好，項目延期在10%左右比較正常，否則就可以調(diào)查是什么原因?qū)е逻M度滯后，如果是客觀原因，以后完全可以延長項目時間，總之一個合理的進度表比較重要。

　　4 項目獎金

　　這里牽扯到一個錢的問題，據(jù)我了解國內(nèi)大多小公司很少有項目獎金這么一說，年底給點路費就不錯了!國內(nèi)的大多數(shù)項目經(jīng)理更像是一個技術負責人，根本沒有用錢的權利，我就曾像公司申請項目獎金，結(jié)果計劃全盤泡湯，給的理由很荒唐，說項目獎金不好分配，給張三多一點吧，李四不爽，反之亦然。我心理暗自想：“你丫不想給就直說唄!”，這里會導致一個問題，就是“項目經(jīng)理”憑什么約束成員，大鍋飯的道理我也不想再解釋了，總之結(jié)果就是3個月的項目就得做個5個月，其實老板的小算盤看似很精明，其實未見得，雖然項目獎金能省就省了，那么工作效率的下降所帶來的成本的提高，孰輕孰重?長遠一點說，產(chǎn)品質(zhì)量的下滑導致的項目維護的成本你計算過嗎?依我的經(jīng)驗，3個月的有效工作時間其實也就是1個月，這已經(jīng)不錯了。不過項目獎金的分配確實是個難問題，但有沒有項目獎金和分配合理與否是2碼子事吧?由于我也沒有能耐申請到項目獎金所以也就沒有深入研究這個問題，只得望梅止渴，看看人家華為了，員工根據(jù)能力分等級，加上年限、加班、表現(xiàn)得出個權值來計算。總之現(xiàn)有雞才能有蛋，這個問題需要更深入的討論。