1）通常工作梳理用5w1h法： (p82)
1.why——為什麼幹這事兒？（目的）
2.what——什麼事情？（物件）
3.where——在什麼地方執行？（地點）
4.when——什麼時候執行？什麼時候完成？（時間）
5.who——由誰執行？（人員）
6.how——怎樣執行？採取哪些措施執行？（方法）
2）四象限法 (p83)
3）專案管理9大領域 (p94)
4）專案三個目標 (p96)
就是時間、成本和質量，對應的就是「快好省」。
2. 成本：專案計畫花多少錢？每項子任務分別打算用多少錢（多少人月）來完成？是否發生了偏差？如果有偏差，怎麼處理？
3. 質量：軟體功能完整嗎？軟體操作方便嗎？執行結果正確嗎？執行效率夠快嗎？軟體**符合規範嗎？客戶用起來滿意嗎？
5）專案管理方法 (p98)
4. 以控制為手段【12月的時候，專案已經處於暴走階段，對原型的理解不深，經常發現需求理解錯了】
6）打造「凝膠型」團隊 (p116)
在這樣的團隊中，大家有著清晰的共同目標，彼此合拍，每個人都是全身心的投入，每個人貢獻自己全部的智慧型和力量，團隊顯示出超強的戰鬥力。
「凝膠型」團隊可以分兩種，星形和網格型：
1）專案執行的常見誤區 (p163)
4. 拖延症【臨時開會，人員面試，資料處理等經常會出現很多事情打斷原先的任務，導致托到明天做】
5. 只管專案整體，對細節不知【在看原型的時候，只是看了個大概，但真做的時候，發現到處都是深水區】
7. 無效溝通【由於第一次合作，客戶端和介面端面對面溝通都會出現偏差，對問題的理解存在差異】
2）重要細節應問5個為什麼 (p176)
「連問5個為什麼」的工作方法，可以用來問自己，刨根問底，分析專案中的潛在問題。例如「總體目標達成情況」，「團隊士氣如何」，「有哪些潛在的風險」，「軟體總體質量如何」......
3）專案執行為快不破 (p187)
抓住重點的20%，也就是「二八法則」。注意以下問題：
1. 重點處理客戶的核心業務需求
2. 將核心人員用在核心問題上
3. 面對問題時，要分析主要因素，並加以處理
4. 將大部分時間處理少部分重要的工作
4）打造團隊執行力 (p200)
1. 有效溝通，在溝通中經常會出現失真的情況，導致理解出現偏差
2.需求調研的要點
階段要點 說明
準備工作
理解使用者業務
要聽懂別人的業務術語，知道他們在說什麼
準備調研提綱
想達到什麼目標，提哪些問題都要整理成提綱
讓客戶做選擇題或判斷題
如果讓客戶做論述題，那資訊的完整性和準確性將得不到保證
準備系統原型
圖形化的系統介面更加能激發使用者的思維
調研中做好筆記
不要不懂裝懂
要敢於問問題，「連問5個為什麼」，在理解對方傳遞的資訊時，也需要打破沙鍋問到底的精神
主動複述
將客戶講的內容，用自己的話複述一下，由客戶來裁定你的理解是否正確，存在偏差就能及時糾正
問問題要具體
調研後每天整理分享調研成果
專案整體
調研過程要有計畫有層次
先整體後區域性，先粗略後細化。方法上分三個階段，先收集資料、再填寫需求調研**，最後細化訪談
如果有可能，讓客戶編寫需求文件
1）胸有成竹 (p220)
其實胸有成竹只是一種表面現象，就好像一座冰山露出水面的部分，水面以下還有龐大的支撐。
2）專案失控的表現 (p233)
看看你公司現在佔了幾個？
專案管理領域
失控症狀
專案管理領域
失控症狀
整體管理
目標不科學，制定了不可能完成的目標
拍腦袋制定專案計畫
專案問題百出，無法控制
專案經理不知道該如何有序地開展工作
人力資源
團隊成員士氣低下，工作效率低
人員流動大
人人火氣很大，專案中衝突不斷 範圍
範圍不斷蔓延
需求不斷變更 溝通
無法準確評估專案資訊，並傳達給相關人員
專案干係人極度不滿 進度
進度嚴重延期 風險
專案狀況頻出，嚴重影響專案正常開展
成本成本嚴重超支 採購
外包的質量無法達到要求，進度緩慢
無法及時響應我方要求 質量
質量達不到要求，
經常返工或重做
3）專案失控的7大原因 (p236)
再看看你公司佔了幾個？
原因 說明
原因說明
沒有指定完整的
專案目標
1. 需求過多，系統過於龐大複雜
2. 需求不穩定，使用者無法決定他們要解決的問題
3. 需求模稜兩可
4. 需求不完整
團隊中缺少
資深人員
資深人員通過豐富的經驗
可以給專案組提供成熟的解決方案
幫助專案組識別風險、解決突發事件等
拙劣的計畫和評估
對專案的難度和工作量評估不準確
硬體/軟體**商的
低劣表現
將專案中的部分工作或產品外包
如果**商不給力，只有乾著急的份兒
採用新技術
1. 專案組成員對新技術掌握有限
2. 新技術不一定成熟
質量無法滿足要求
1. 功能做了一遍又一遍，每次接近一點，但始終不能達到
2. 如果效能或可靠性出現問題，可能給客戶帶來重大損失
缺乏或根本不具備
專案管理方法
1. 沒有章法，想到什麼做什麼
2. 等事情做，有問題才覺得工作很充實
專案問題不斷冒頭，成為「打地鼠式管理」
1）響應變化重於遵循計畫 (p250)
出現的原因有以下幾點：
1. 經驗不足或過分依賴經驗
2. 考慮不周，所謂「百密必有一疏」
響應變化重於遵循計畫有2個重要思想：
2）滾動計畫以適應變化 (p252)
專案執行中會出現意外情況，產生偏差，有些可以修正，有些無法彌補，這時候就根據實際情況來「修改路線」。注意以下2個問題：
1. 要隨**估專案，要時刻有一副如何到達目標的地圖。許多次小的變動可能讓你的地圖失效。
2. 思考變更的原因與必要性。需求變更通常是客戶提出的，而客戶的想法有時候不是深思熟慮的，我們就得幫助他們想透徹、理清楚。
滾動計畫有2個方面的內涵：
1. 計畫需要認識的加深而修改。在專案啟動的時候就要做計畫，即使需求沒確定，其實需求調研需求分析也是計畫的一部分。
2. 近期計畫細緻些，遠期計畫粗略些
3）在現有的資源下做出成績 (p255)
1. 把專案組調動起來，充分挖掘，在不影響專案把控的情況下親力親為。
2. 用好現有的資源，用好每乙個人。首先要把事情理清楚，讓大家明明白白的做事。
4）怎樣對待需求變更 (p279)
1. 需求沒變，是我們對需求的理解在變。也就是我們沒有理解清楚客戶的需求。
2. 管理需求，減少變更。深入挖掘需求，不要停留表面，需求評審不可少。
3. 變更流程要書面化正規化，提出申請、評審（是否有必要變更、是否有替代方案、對其他功能影響等）、跟蹤（監控評估變更的效果，避免產生新的問題）
思維的蛻變 從程式設計師到專案經理
文 火星人 出處 it168 因為我在參與的軟體專案開發表現出色，公司在新乙個軟體開發專案上委派我做專案經理，全權負責專案各種事務的管理。繁忙的事務處理使我體力透支,有一種脫了一層皮的感覺，但最使我心力交瘁的是從軟體程式設計師到專案經理的一種思維方式和觀念的痛苦轉變。在軟體越來越複雜，需求多變的情況...
《從程式設計師到專案經理》學習筆記
一 為什麼要當專案經理？1 專案經理作為最基礎的管理職位，沒有職業瓶頸。2 專案經理75 以上時間用於溝通，與人交流，更有助於自己心智成熟。3 專案經理的經驗可用到生活的方方面面。二 從程式設計師打專案經理要克服的障礙 1 溝通能力弱，與人溝通，聽說讀寫能力都要加強 2 固執自傲 視野狹窄，太講邏輯...
從程式設計師到專案經理 專案管理三大目標
專案管理的三大目標即時間 成本和質量，實際是告訴專案經理應重點關注什麼因素，專案控制應該做什麼工作。三大目標雖然簡單，但如果能將其真正貫徹 到自己的行動中，那麼對專案計畫制定 過程控制等工作，均能起到引導作用。有了努力的方向，專案經理也就可以真正告別 盲目 了。1.我的第一次頓悟 1 懂三大目標才算...