本篇文章由導學寶**：
為什麼在實際工作中做調整最難呢？答案其實也很簡單，變數太多！再好的規劃也無法**到以後會發生的事情，哪天突然停電了，哪天**了，哪天員工生病了，你能想得到啊？！既然無法想象得到，我們就得在發生時隨時做調整，調整資源，調整時間，甚至增減專案。
當然，**也未必有的，所以大家也放寬心，員工請個假也正常，其他人幫忙頂頂，或者到時週末加個班，這些都是可以解決的，最最最重要很難解決的是什麼知道嗎？就是我們怎麼來判斷乙個事情對專案的影響程度，也就是我怎麼來知道現在要不要加人減人，要不要延期，要不要加錢，如果不需要，那什麼時候應該做這些事情。
很多時候，我們都是在專案快要完成的時候才意識到這種問題，不過那個時候已經來不及了，延期是必定了，甚至客戶不想買了，損失就可能很大了。 所以我們需要提前意識到這類問題，從而提前解決掉。這個就是我們當初決定用techexcel devplan的乙個最最最重要的原因！（大家有沒有聽說過蝴蝶效應這個理論，乙隻蝴蝶在西半球震動了一下翅膀，可能導致東半球刮颱風，為什麼呢，蝴蝶震動了一下翅膀，會導致周圍空氣發生變化，這塊空氣的變化可能就會影響旁邊地方的空氣變化，就這樣一塊接一塊地發生連鎖影響，最後就導致了颱風的生成。 由此可見，如果乙個員工某一天遲到了或者請假了，都可能導致嚴重的事情發生，如果能夠預見到可能發生的結果，那是多麼有意義！）
其實這個問題也是很多公司都有的問題，即使你的設計再精彩，開發再出色，測試再專業，只要中間出了些問題，且沒有來得及解決好，那就什麼都沒用! 那這個問題能不能解決呢，怎麼解決呢？當然，答案還是很清楚，肯定是yes，不過有些網友還是想知道細節，所以還是來稍微說明一下吧：
一般出問題的時候，我們可以來分析一下原因是什麼，客戶臨時決定要加幾個功能，領導拍板說要做，設計以為很簡單，開發也很快做好，測試發現了很多這個功能影響很大，發現了很多問題，所以導致開發需要花很大精力去修bug，最後其他功能也沒完成好，再最後，時間到了，產品沒出來。
是誰的問題呢？都有問題是吧，客戶你就不該加這幾個功能，呵呵（哼，不做不給錢）；老闆呢，你老是這樣拍板（客戶要的，我得給）；設計人員總是說很簡單，不會有影響（的確好像挺簡單的啊）；開發總是考慮得太少相關功能（也不是我沒考慮全，時間就這點，我還得做其他活了）；測試人員總是愛找bug（我愛bug，我愛bug）。。。。。。，呵呵，其實誰都沒有問題，那問題在**呢？
問題在於，我還需要多點時間，或者多點人力。可是誰也沒提，如果當初客戶要加功能的時候，老闆可以爭取多點時間，如果開發接到活的時候，多要點時間或者人手，如果測試拿到build以後，根據bug情況也要求一些額外資源，想必這個專案起碼能稍微好一點，即使最後還是延期了，起碼是在大家已經早就預料到的情況下了。
我們以前也經常碰到這種事情，在用了devplan系統以後，這種事情已經大大減少了，因為在devplan中，很多可能會影響到人力，時間和成本的因素，都會有自動預警機制，使得你可以早做調整，去增加人力或者增加時間，相應的，這個專案規劃圖就會實時進行更新，領導們也能隨時看到這種情況，而且通過關鍵路徑或者基線（baseline）的比對，管理層可以很清楚得知道這個專案會不會延期，會不會超支等。
也許有人還不太明白devplan如何實現預警功能的，這個我之前也不明白，後來問了techexcel的何工後才稍微了解了一下，原來由於devplan可以與軟體開發的其他環節的管理軟體（techexcel devsuite解決方案的其他幾個產品，我們公司也買了）無縫整合，共享資訊，而那些產品，比如需求管理工具（devspec），開發管理工具（devtrack），測試管理（devtest），報工管理工具（devtime），文件管理工具（knowledgewise），都是管理著最直接的產品開發工作，也就意味著能獲得最精確的工作資料，比如這個功能預計要做多少時間，實際用了多少時間；按照當前的工作效率，剩下的功能還需要多少時間完成；加了這個功能，可能會影響多少的時間；測試最近幾周發現嚴重bug的趨勢如何；之前的成本投入情況怎樣，按照現在趨勢，未來一段時間的成本會有多少。。。。。。所有這些資料都是非常精確的資料（甚至可以精確到個人在專案開始以來花了公司多少成本，做了多少功能，修了多少bug，工作效率是否一直很好還是有所下降），然後這些資料可以在devplan被呼叫到，devplan再根據這些資料通過一定的演算法就會得出專案調整的預警，比如知道了測試最近提交bug的數量趨勢，就會決定是否安排更多開發去修或者是延長時間；知道了這個新功能加入後預計完成所需時間，就可以提醒老闆是否跟客戶說一下延長一下交貨時間；知道了這個員工同時在做幾個功能，工作量已經超負荷了，需要減負或者加人；知道了有人馬上要修婚嫁了，就得派其他人接手一下。。。。。。
就這樣子，基本上能解決現在碰到的大部分問題，當然不同公司有不同的流程，也許有的公司還不能照搬這個方式，不過我對這個系統還不是很熟，也許還有其他功能，以後慢慢研究。
（未完待續）
文章出處：
專案規劃管理 5
為什麼在實際工作中做調整最難呢？答案其實也很簡單，變數太多！再好的規劃也無法 到以後會發生的事情，哪天突然停電了，哪天 了，哪天員工生病了，你能想得到啊？既然無法想象得到，我們就得在發生時隨時做調整，調整資源，調整時間，甚至增減專案。當然，也未必有的，所以大家也放寬心，員工請個假也正常，其他人幫忙頂...
it專案管理（5）
分析題 收集需求與定義範圍 請三選二 使用教材 中的微型案例 running case 請寫乙份兩頁的報告，描述收集需求的方法，並附上收集的需求跟蹤矩陣 不少於五個需求 使用思維導圖，為作業1或2構建wbs 並使用專案管理工具製作wbs或根特圖。並按要求檢查工作包的可管理性，分解完整性。例如 檢查測...
專案規劃管理 6
上面簡單的講了一下，大家應該稍微了解了我們公司在專案規劃管理方面的流程了吧，主要也就是先建立初步規劃，然後再根據實際資料來調整規劃，說簡單也簡單，管理人員只要每天看看有沒有預警，再分析分析一些報表就可以了 說難麼也難，員工每天的工作都得真實地記錄在系統中，這樣子才能得到真實的資料來供devplan分...