在軟體開發中，如果你問任何經理「在管理專案中，你的痛點是什麼？」，超過85%的人會說-需求。
在這個領域，我們的經驗教訓是什麼？未來在專案中我們如何做的更好？
接下來，我們將強調我們在需求培訓課程中所教的原則如何幫助需求分析師來提高他們的工作：
問題1：「在需求階段我們沒有識別和包括『正確的』干係人。這經常會在專案後期引起不必要的需求變更。」
例子在最終的使用者驗收測試中，客戶告訴我們系統的授權功能沒有滿足他們的需求。我們發現在需求誘導階段我們與之交談的客戶代表們沒有告訴我們這個授權需求。這些代表們是資歷較淺的員工。他們沒有意識到這個需求。
所以我們立刻召集最好的技術員工來做變更。我們估算我們要多花費至少25個人天來做這個事情。幸運的是，整個專案延遲了7個工作日。
:經驗教訓：
干係人的重要性。。。 詳細的干係人模板。
問題2：「在專案結束時，我們評審。我們得出的結論是我們所建立的解決方案不是解決問題的最佳方案。」
例子「我們正為一家重要的保險公司開發乙個現金管理系統。因為現金管理非常重要，所以該公司在總部的整個組有乙個非常有經驗的團隊來管理所有現金。該公司的銀行合作夥伴來銷售保險服務。作為交換，這些銀行想要保險組存錢到銀行。
當我們和這個保險組的財政部門討論時，他們提出了這項需求：如何管理現金流的需求-每個地方分支機構必須從總部拿到現金來滿足他們的地方銀行合作夥伴
我們聽到了這個需求，並且在系統中增加功能來滿足。我們把這個作為系統的乙個功能包括進來。在5個月內我們開發並交付了系統。
在專案完成之後，我們有乙個專案結項會議。當我們回頭看時，發現乙個更好的解決方案：為每個分支設定乙個準則即保持滿足當地銀行營業額的乙個百分比更簡單，而不是管理總部和分支之間的複雜的現金流。但是我們僅僅與該保險公司的現金管理部門談論過，他們沒有全域性的視角。他們只能告訴我們他們的問題，並且希望有乙個it系統來解決他們的問題。」
經驗教訓
需求分析師必須把自己放在行業專家/諮詢師的位置上。他們不應該把自己侷限於只是為客戶問題提供it解決方案。而要針對商業問題對能為客戶提供價值的商業解決方案進行更多的思考。
如果我們必須構建軟體，那麼它必須為擁有它的人提供最理想的價值。
需求發現者的職責，就是確定擁有者看重的價值是什麼。
客戶不一定總能給你正確答案。有時候客戶也不可能知道什麼是對的。有時候他
就不知道需要什麼。
傳統來講，需求活動被看成是某種類似速記員的任務。也就是說，業務分析師仔細聆聽利益相關者，準確記錄他們說的所有東西，並將他們的要求翻譯成產品的需求。這種方法的缺點是；它沒有考慮到利益相關者在試圖描述需求時的困難，展望乙個產品來解決乙個問題，這不是一項簡單的任務，尤其是問題並非總是理解得很切底。考慮到今天業務
的複雜性和規模，個人確實很難理解業務所有適當的部分。也有『增量改進』的問題。有詢問有關新系統時，利益相關者常常會描述原有的系統，並加上一些改進。這種增量的方式通常排除了所有重大的創新，常常會導致平庸的產品，不能滿足期望。
專案管理最佳實踐之專案執行
1 唯有參與才有認同 專案經理給下屬分派的任務最好能讓當事人自己親自進行評估，至少也應該在任務開始執行之前得到當事人認可。2 千斤重擔大家挑，人人頭上有目標 良好的分工有利於更好地合作。3 確保專案進度不拖延的乙個最有效措施就是讓下屬自己給承諾，專案經理根據下屬的承諾給予監督。4 專案建設過程中，我...
IT專案管理最佳實踐（管事篇）
讀書筆記 序號最佳實踐 可歸併入的過程組 可歸併入的知識領域 1在制定專案之前，應盡可能識別出專案干係人，特別是專案的主要干係人 啟動專案干係人管理 2在專案正式開工之前，應該和專案各方商定並簽署工作協議 內容涵蓋責任 權力 義務和獎懲等 啟動專案整體管理 3制定 專案計畫 一般需要執行四個基本步驟...
IT專案管理最佳實踐（理人篇）
讀書筆記 序號最佳實踐 可歸併入的過程組 可歸併入的知識領域 1唯有參與才有認同 專案經理給下屬分派的任務最好能讓當事人親自進行評估，至少也應該在任務開始執行之前得到當事人認可 規劃專案整體管理 2管理者在培養和教育員工時要多講故事 管理者在表揚和批評員工時則一定要講事實 如果不這樣做則很容易出現事...