《做專案，不得不這麼幹》讀後感
讀完一本名著以後，想必你有不少可以分享的東西，何不靜下心來寫寫讀後感呢？怎樣寫讀後感才能避免寫成“流水賬”呢？以下是小編為大家收集的《做專案，不得不這麼幹》讀後感，供大家參考借鑑，希望可以幫助到有需要的朋友。
按照事業部的要求，抽時間閱讀了郭致星的《做專案，不得不這麼幹》一書。雖然大道理都是CMMI、專案管理所必須的，但書中有很多活生生的案例，能給我們更多的啟發。本書從實用出發，系統介紹了專案管理中的難題和建議的處理方法，根據大量的實踐經驗，尤其是從失敗中得到的經驗教訓，總結出現不確定和可變的專案管理過程中，造就卓有成效的專案經理所需的關鍵因素及技巧，是一本實踐性和指導性都很強的專案管理工具書。我們的專案管理者真應該靜下新來仔細體會，並選擇合適的內容在專案管理中進行實踐，逐步提高專案管控能力。
"在溝通中最重要的事情就是聽到沒有說出來的話——彼得德魯克"；
"分析痛點，也就是表現出來的'最擔心的方面，重複的就是痛點"；
這些都是專案管理的重要過程—需求獲取時的真知灼見。我們都提到要開啟客戶的需求，但要真正做到談何容易。需求獲取準確性的問題，需要理解客戶的需求，弄清需求背後的真實業務，重視干係人潛在或者隱含的需求，是專案最終成功的關鍵因素之一。書中提到的一個觀點："避免出現選擇性知覺，獲取真實需求，挖掘痛點"感覺在需求過程中尤其重要。可能我們是某個領域的專家，但客戶的真實意圖並一定跟我們潛意識理解的一致，因此"需求調研的核心是澄清而不是說服"就顯得尤其重要了。
書中提到：研發包括研究和開發兩種不同的活動：前者指對新技術、新工藝、新方法的研究，後者是對新產品、新服務等的開發；前者主要是創造性活動；後者是研究成果的整合性、應用性活動。沒有研究，企業就沒有未來的競爭力，沒有開發，企業就難以生存。研發專案的根本是"開發"，沒有開發出產品的研發專案就是失敗的專案，因此研發的專案要以市場為導向，能儘快地應用到實際開發專案中，為企業創造價值。仔細回想一下我們的平臺研發專案，貼近需求並保證適當的前瞻性才是重要的，我們推出的產品與技術是為兄弟部門服務的，也就是要切實解決他們的"痛點"問題，只有這樣的開發技術和工具才能夠得到迅速的推廣並在使用過程中不斷完善。前瞻性是我們技術研發人員必須具備的技能，並不是推動平臺研發的必要條件，因此平臺專案在進行研發時，需要貼近開發需求，瞄準專案開發過程中的痛點，在開發效率與可測試性等方面持續提升。
"高素質複合型人才"是難以自拔的陷阱，當專案的執行效率不那麼令人滿意時。"員工素質不高"是管理者常掛在口頭的詞彙，實際上，過渡依賴高素質複合型人才會是組織忽視積累屬於組織的知識和技能，反過來又會使企業更加依賴這些高素質的複合型人員。當企業沒有屬於自己的核心知識和技能時，"缺乏高素質人才"是我們最好也是最沒用的藉口。
儘管大量的統計結果表明，專案失敗的原因大多來自組織、管理方面，單純由於技術原因造成的專案失敗的比例很低，但是在大量的專案實施過程中，技術問題卻是大家最常用以說明問題的理由，因此"技術問題"成為了檔箭神器，當然參與的技術人員也自然地背起了黑鍋。書中提到的這些真是說出了開發人員的心聲，於我心有慼慼焉。
讀完這本書，心中不禁產生一個疑問：書中講的內容我們在CMMI規程規範中都能找到相關的影子，為什麼實際專案在執行中總有這樣那樣的問題呢？回顧一下我們公司的CMMI研發管理的過程檔案，從最初的生命週期模型選擇、專案立項過程中的過程裁剪、專案計劃、需求獲取與需求開發、設計有敏捷開發、測試與釋出、直到專案實施過程，都有比較詳細的指導方法，是這些內容和措施水土不服？估計有這方面的原因，更多的原因則是意識形態上的問題，認為過程管理是一個付出遠大於收益的過程，除了一些大專案，在專案過程中發揮不了多大的作用。另外缺少必要的專案總結和經驗積累、並根據經驗教訓不斷完善過程檔案，使之執行更加高效。
再分析一下部門的研發專案，專案經理更多是技術層面的領導者，在專案立專案標確立、專案評審和計劃實施中並不盡科學和嚴格，另外開發內容也沒有貼近公司或者事業部的痛點，開發人員費大力氣做出的產品在技術上雖然有競爭力，但由於很難在公司內推廣，造成一定的技術浪費，同時開發人員也沒有獲得應有的成就感，必然會產生一定程度的挫敗感。我們的研發經理需要多掌握專案管理知識，理論聯絡實際，分析自己的短板，明確團隊和專案的目標，認真審視和對待專案計劃，使得研發工作更加科學和高效。
