我們的方法還是比較實用的
舉個具體的例子
我們做任何乙個工作,都先做sample,比如寫詳細設計,leader必須先寫,定sample,然後看leader做需要多少時間,然後按一定比例,比如pert方法就可以,然後按畫面去分,畫面數/預期每日完成數,測試也一樣,先做sample再算預期case數,再除預期日完成數.回過頭來說,比如8個人,7個人都可以按時完成,第8個不能順利結束,一般就要換人了
專案管理的核心是找的合適的人做合適的事情，其他一切都不能稱之為核心。你可以稱其他要素為關鍵的，重要的，但是絕對不能說是核心的。計畫和計畫實施過程的監控自然是重要的，但是絕對是最重要的。
估算和計畫，我在這個論壇已經說過很多次了。基本上說，最靠譜的估算就是基於經驗的拍腦袋的做法。當然培養這個估算的能力，是有乙個過程的，並且我推薦可以將psp的做法加以改進，以加強自己的複習工作，從而可以很快的提高自己的估算的能力。當然這個地方有很多的策略和各種策略的優缺點，以後專門討論的時候再展開。
至於任務的分配和進度的確定，這個方面我以前也說過很多了。這裡我需要強調的是，任務和需求的粒度化其實才是解決這些問題的核心基礎實踐，沒有這個基礎，基本上這些事情僅僅就是一種紙上談兵。
至於說績效考核以及分配，這個話題太大，而且專業性太強，我建議大家不要著急討論。
總的來說，我覺得樓主可能看pmp之類的東西太多了，中毒了。
哈哈，等我明天忽然想整乙個估算與計畫培訓班的時候，我可能就會改口了。當然這是乙個玩笑。不過我確實看過很多估算方面的資料，也參加過很多培訓和討論，自己也給別人介紹和輔導過很多這個方面的內容。然而最終我自己發現，往往是我在專案最初的直覺，最終都是最準確的。並且我做過調查，基本上當乙個開發者在保持複習專案的習慣半年之後，對於專案規模的直接就很準了。而這也使我對估算這個問題有了新的視角，我現在更願意教大家如何回顧和複習自己的工作，並不斷對自己的直覺估算能力做訓練。
當然同時我們必須還認識到，至少對於我來說同樣的需求，所帶來的任務和完成的工作量並不是很恆定的，它會由於開發者的選擇有十分大的伸縮性。比如同樣是做乙個**，即使你使用同樣的技術和高層設計，並且是同樣的人員，最終的**規模和完成的時間長短以及工程的質量都可能差別很大。並且很多時候，開發者自己也知道這一點，並且是有意的利用了這一點。當然如果把專案放在極限狀態下考慮，這一點就該被強烈的重視起來。
而我也發現當專案處於極限狀態下，在混亂與秩序的邊界，其收益和實施的過程往往是最具有活性的。當然人與組織之間的區別很大，這個交界點的差異就更大。這也需要大家不斷的對自己的工作進行回顧和複習。
這裡我確實需要解釋解釋。我說什麼什麼是核心，並不是說只要有了核心就行了，還需要有外圍的輔助。
比如你拿到乙個專案，最佳的方案是找到乙個合適的人，全權委託給他去做。然而往往我們找不到這樣乙個人，我們只能找到一些可以完成這個事情一部分比較合適的人。這個時候，你就需要把這個事情劃分為適應於這些人各自不同情況的組合，並將這些組合委派給他們去完成。而由於是組合，很可能他們之間的工作還有所聯絡。因此你就需要做協調。當然由於你要協調，對他們各自的工作情況就需要有乙個監控，以使你可以在合適的時間採取相應的措施。這個任務的劃分就是計畫，這個監控就是專案的過程控制。由此我們就可以明白，所謂的計畫面向的是人，服務的是人；所謂的過程控制，面向的也是人，服務的還是人。
而進一步看這個問題，我們可以說，設計也是應該面向人的，交流還是面向人的，一切的一切都是面向人的。
如何估算測試工作量（一）常規的估算測試工作量的方法
如何估算測試工作量 一 常規的估算測試工作量的方法 作為乙個管理者，你是否被詢問到某個專案要花多少時間，多少人力測試 或是作為乙個普通的測試員，你是否被詢問到要花多少時間來完成某個任務或是一次回歸測試？我想大多數在軟體行業的人或多或少都會碰到這樣的關於工作量估計的詢問。那麼你是怎麼回答的呢？你對你自...
估算速達5000開發工作量
採購系統 採購申請管理 根據訂貨申請採購 根據缺料申請採購 銷售系統 倉庫系統 pos系統pos機銷售管理 pos機銷售款管理 pos機銷售彙總 pos銷售彙總管理 班次資料管理 會員卡資料管理 其他系統 從上述模組中按照ei eo eq ilf eif幾個方面找出各自的fp數，然後可以採用簡單的工...
軟體專案的工作量估算方法
1 經驗法 delphi方法 需要多個專家參與。模擬法 可以乙個專家根據歷史相似的專案進行估計。2 模型法 一元線性關係 工作量 規模 生產率 c 生產率借鑑歷史專案的資料，c為乙個常量，多數情況下為0。這是最簡單的估算模型。多元線性關係 工作量 規模 生產率 復用率 難度係數 人員能力係數 c 生...