引導語：專案管理：計劃、進度和控制的系統方法。以下是yjbys小編為大家整理的關於專案管理案例分析問答，希望對大家有所幫助。
某公司準備開發一個軟體產品。在專案開始的第一個月，專案團隊給出了一個非正式的、粗略的進度計劃，估計產品開發週期為12~18個月。一個月以後，產品需求已經寫完並得到了批准，專案經理制定了一個12個月期限的進度表。因為這個專案與以前的一個專案類似，專案經理為了讓技術人員去做一些“真正的”工作(設計、開發等)，在制定計劃時就沒讓技術人員參加，自己編寫了詳細進度表並交付稽核。每個人都相當樂觀，都知道這是公司很重要的一個專案。然而沒有一個人重視這個進度表。公司要求儘早交付客戶產品的兩個理由是：
1)為下一個財年獲得收入;2)有利於確保讓主要客戶選擇這個產品而不是競爭對手的產品。團隊中沒有人對儘快交付產品產生懷疑。
在專案開發階段，許多技術人員認為計劃安排的太緊，沒考慮節假日，新員工需要熟悉和學習的時間也沒有考慮進去，計劃是按最高水平的人員的進度安排的。除此之外，專案成員也提出了其他一些問題，但基本都沒有得到相應的重視。
為了緩解技術人員的抱怨，計劃者將進度表中的計劃工期延長了兩週。雖然這不能完全滿足技術人員的需求，但這還是必要的，在一定程度上減少了技術人員的工作壓力。技術主管經常說：產品總是到非做不可時才做，所以才會有現在這樣一大堆要做的事情。
計劃編制者抱怨說：專案中出現的問題都是由於技術主管人員沒有更多的商業頭腦造成的，他們沒有意識到為了把業務做大，需要承擔比較大的風險，技術人員不懂得做生意，我們不得不促使整個組織去完成這個進度。
在專案實施過程中，這些爭論一直很多，幾乎沒有一次能達成一致意見。商業目標與技術目標總是不能達成一致。為了專案進度，專案的規格說明書被匆匆趕寫出來。但提交評審時，意見很多，因為很不完善，但為了趕進度，也只好接受。
在原來的進度表中有對設計進行修改的時間，但因前期分析階段拖了進度，即使是加班加點工作，進度也很緩慢。這之後的編碼、測試計劃和交付物也因為不斷修改規格說明書而不斷進行修改和造成返工。
12個月過去了，測試工作的實際進度比計劃進度落後了6周，為了趕進度，人們將單元測試與整合測試同步進行。但麻煩接踵而來，由於開發小組與測試小組同時對程式碼進行測試兩個組都會發現錯誤，但是對測試人員發現的`錯誤響應很遲緩，開發人員正忙於完成自己的工作。為了解決這個問題，專案經理命令開發人員優先解決測試組提出的問題，而專案經理也強調測試的重要性，但最終的程式碼中還是問題很多。
現在進度已經拖後10周，開發人員加班過度，經過如此長的加班時間，大家都很疲憊，也很灰心和急躁，工作還沒有結束，如果按照目前的進度方式繼續的話，整個專案將比原計劃拖延4個月的時間。
問題：
1. 在本案例中，我們能吸取什麼教訓嗎?
2. 編制計劃時，邀請專案組成員參與有哪些好處?
3. 學習曲線對軟體專案有哪些影響?
1 本例存在的問題
(1)前期制定工作計劃沒做好
專案啟動時沒有就專案的範圍、技術可行性、資源可利用性等進行充分論證和評估，計劃制定時沒有做好評審，專案干係人的溝通工作沒有做好。風險控制沒有做好。做計劃時，沒有像做預算一樣留出風險控制期。什麼都按照最緊張的來做，一旦有地方出現問題，進度延誤就成了必然的了。
專案組成員沒有參加，這個問題就很嚴重，專案經理認為一個完全合格的程式設計師是可以在規定時間裡完成指定的任務的，但是事實是這樣嗎?開發期間難免會遇到技術瓶頸，這些都是需要時間去研究的，新員工不熟悉的專案也沒有考慮。制定工作計劃的時候，專案經理最好是給一個大概的框架，在自己判斷的基礎上徵求專案組成員的意見，儘量安排一個大家都認可的計劃。
(2)管理問題
專案組的成員在做完這個專案後，都很疲憊，另外自信心也很受打擊，花了時間沒有交出一個好的專案，問題就不止在技術層面了，這大部分是管理的問題，從長遠來看，這個專案組的成員離開的機率很大，公司的人才會流失。
整個案例中沒有發現專案經理的工作是什麼，專案經理的定位一定要明確，本案例中計劃編制者更像是一個系統推銷人員，是從市場出發的，完全沒有考慮到開發的難度。
專案經理不知道各部門人員的立足點。即便專案經理制定了限期，也應該把專案的各個階段策劃目標向大家進行報告，讓各個職能部門能夠在框架下、限期內合理安排各自的工作內容。
對與大專案，專案組內的分層管理也很有必要。專案經理把指標分解給各個開發組組長，具體的開發工作讓他們安排下去，專案經理可以花點時間去考慮一下專案組的整體問題，例如：成員疲憊等問題。抽一個晚上不加班，組織點活動讓專案成員透透氣，比加班效果好得多。例如風險的審視、計劃統籌調整、組織層面的一些問題推動。
(3)溝通問題
專案實施階段，商業目標與技術目標意見分歧很大，這個就是溝通嚴重有問題了，為什麼在實施前沒有討論好?
做專案計劃之前要充分和專案干係人溝通。尤其是技術主管和發起人。一個是從技術角度考慮，一個是從商業角度考慮。要讓兩個人的要望都得到滿足，這樣的計劃才可行。案例中，只是從商業角度去考慮了這個問題，根本沒有考慮技術上的實現難度，單純的計算出所需的人月數。人月神話本身就是一個錯誤的理論。
員工抱怨。員工的抱怨並不是無理的，正是因為他們沒有得到動員和鼓勵，更沒有得到階段性的工作目標。員工也都有自己的想法和構思，應該統一大家的思想，便捷的方法就是讓他們知道他們在做什麼，價值在那裡，他們的各自工作安排如何，才能讓整個團隊步調一致，協調統一。
(4)專案跟蹤沒有做好，應該定時開進度研討會。關鍵的里程碑沒有得到有效控制，規格說明書等關鍵節點沒有控制好。
(5)單元測試與整合測試一起做
在時間緊的情況下，這樣做也是沒有辦法，但是研發人員和測試人員一定得分清問題的嚴重程式，功能性的BUG，導致系統不能正常使用，必須優先修改，使用者體驗方面的修改，可以等系統試用後徵求使用者的需求再進行修改
(6)專案的人力資源問題
有新老員工，做計劃時一定要考慮新員工前期的培訓週期，這是影響計劃的一個重要因素。不能按照人月來定週期，還要考慮實際的工作能力。
2. 編制計劃時，邀請專案組成員參與有哪些好處?
做專案計劃時，商務、客戶代表、專案管理人員、QA、專案技術骨幹、甚至公司的技術委員會成員等都要參與，至少在評審時一定要參與。讓大家都瞭解專案的背景，意義和要求。可以統一思想，減少溝通風險和技術風險。對進度計劃評估的更貼近實際。讓參與的各部門人員明白自己將要完成工作的時間和未能按期完工對其他部門會產生的影響，還有就是根據時間節點分配自己任務。成員自己給出的承諾，他會對計劃的結果上心一點。
3. 學習曲線對軟體專案有哪些影響?
學習曲線對專案的影響：
(1)需要有一個過程，前面比較慢、技術的儲備、熟練程度的把握;
(2)計劃編制時前期安排一定的緩衝時間，便於學習&掌握技能，對設計、架構等關鍵節點做好相應的評審工作;
(3)加強學習和培訓，加快專案組人員的進入狀態
軟體專案的技術中，有些不可預知的難題，這個需要由專人，專門的時間來攻克。做計劃的時候，要把這個人和這個時間也留出相應的餘地。另外專案成員的流失率是不得不考慮的一個問題，對新進成員的培訓，也要考慮到，否則同樣是1人月，工作效率可是完全不同的。
