1 工作量估算
對于工作量估算很多項目經理(老板)喜歡用數學公式來計算，可能數學公式更加的客觀和科學，ok,，看看市面流行的計算方法吧，最常見的是基于代碼行的數學模型，那么這里存在不少問題，工作量估算主要是為了在項目進行中進行有效的項目監控，那么軟件開發尚未結束，誰知道最后的代碼行有多大?代碼經常會被修改，那么修改的代碼算不算?如果算，那么代碼修改越多難道能說明工作量越大?代碼效率的區別也是很大的，假如一個10行代碼可以實現的東西被寫成50行，難道能客觀的Cye.com.cn反映工作量?還有2種比較高級點的方法是基于功能點和COCOMO的方法，那么我想問的是它們的公式中的系數該怎么定?那么不少咨詢師忽悠我說，根據自己的實際情況來定唄，那么我想問的是，算命是迷信，電腦意味著科學，那么用電腦算命算不算迷信?所以我是主張這里還是要靠人的經驗來估算，大家可以在項目周會上對工作量進行充分的估算，在估算時要同時考慮到項目執行的難度，根據經驗給出合理的評估。
2 任務分配
大多數的做法是將整個項目劃分成一個個可以獨立執行的原子任務，這些任務要劃分優先級和難度，至少心理有個數，并且每項任務要制定負責人。那么問題就出在這個任務分配上了，軟件開發是一項智力創造的活動，如果按CMMI假設的那樣，在分配任務時忽略人的因素是萬萬不可取的，我就有血的教訓，不久之前做一個ruby的項目，然后開始在公司內部隨便抓了幾個有點ruby基礎的人，也沒太顧忌別人的想法。做著做著，覺得他們有點心在曹營心在漢，平時還是抱著本 thinking in java看，做ruby也是在敷衍了事，結果是代碼質量不行，需要大規模的修改。當然按理說員工應該服從公司的安排，做一樣就要做好一樣，但員工也有員工的規劃，你去叫他做他壓根就不喜歡的事只能說明管理有問題。
另外還有一個普遍性的問題是能者多勞，有個朋友剛進公司動手能力很強，也非常的積極，每次做項目都分給他最難最累的任務，做著做著也就厭倦了，這時老板會忽悠你說，你能力強，要挑起公司的大梁，以后公司壯大了給你個什么職位，我覺得這就是在扯淡，這就是我經常見到的忽悠式的管理，很多管理手段完全靠人情，很多人都是在這種環境中被忽悠長大，到最后怎么樣?被忽悠了幾年還不是另謀高就了，所以指望人情化管理的公司很難長大。我覺得該講原則的地方就要講原則，在任務分配上給能力強的分配少而精的任務，而且要考慮到員工自己的想法，有些人想做java架構師，你叫他做oracle dba就不合適，有些對ui設計感興趣，你叫他做系統分析員也不合適，有些人就喜歡搞技術，你硬要叫他做管理也是不合適。
|
