1. 如何開展項目跟蹤與監控 詳細�0�3
� 2011-1-30 TPCA SEPG 5 了解項目跟蹤與監控的目的 了解CMM中對項目跟蹤與監控的要求 了解項目跟蹤與監控的要素 了解項目跟蹤與監控的方法 2011-1-30 TPCA SEPG 6 需具備項目管理知識 需掌握軟體項目計劃技能 需掌握項目估算知識 需掌握風險管理知識 2011-1-30 TPCA SEPG 7 部門經理 項目經理 技術管理經理 SQA人員 2011-1-30 TPCA SEPG 8 共計:0.5 天 詳細安排 00:05 課程介紹 00:25 項目跟蹤與監控的目的及意義 00:10 CMM中的項目跟蹤與監控 00:10 項目計劃是項目跟蹤與監控活動的依據 00:15 軟體項目跟蹤與監控的六大要素 00:50 如何進行項目的跟蹤與監控 00:00 參考資料 00:05 問題&反饋 Total: 2 hours 2011-1-30 TPCA SEPG 9 詞彙表 域值：跟蹤項的標准（可允許）偏差范圍（上下限）。 2011-1-30 TPCA SEPG 10 圖例—為什麼要進行項目的跟蹤與監控 2011-1-30 TPCA SEPG 12 項目管理中的常見問題 無法確定項目進度，項目經常延期�6�1 項目進展到什麼程度了？�6�1 是否按計劃完成？還有百分之多少未完成？ 無法控制項目費用，經常超支�6�1 項目費用是否在按計劃執行？�6�1 目前項目是超支還是節余？ 無法控制項目風險，有可能導致項目失敗�6�1 項目中存在問題嗎？�6�1 項目中的風險都消除或降低了嗎？ 2011-1-30 TPCA SEPG 13 項目管理中的常見問題(Cont.) 無法確定項目的規模，不知道項目規模的變化�6�1 項目有多大？�6�1 項目規模比前一階段變大還是變小了？ 無法確定項目資源是否夠用和可用�6�1 項目資源是否充足？�6�1 已有的資源都可用嗎？ 無法確定工作量�6�1 我到底做了多少工作�6�1 項目的工作量有多少？ 2011-1-30 TPCA SEPG 14 產生問題的根源 無計劃 計劃不完整 計劃不合理 沒有做項目估算 沒有評估項目風險 沒有制訂跟蹤與監控策略 跟蹤與監控策略不合理 沒有做跟蹤 沒有根據跟蹤措施採取相應的行動 。。。 2011-1-30 TPCA SEPG 15 解決問題的最佳途徑 制訂合理的項目計劃 進行項目估算 在項目計劃中確定合理的項目跟蹤與監控策略 在項目開發過程中根據跟蹤結果不斷調整和優化項目計劃 在項目開發過程中根據跟蹤結果不斷調整和優化項目的跟蹤與監控策略 2011-1-30 TPCA SEPG 16 項目跟蹤與監控的目的及意義 目的：通過項目的跟蹤與監控活動，及時反映項目的進度、費用、風險、規模、關鍵計算機資源及工作量等情況，通過對跟蹤結果的分析，依據跟蹤與監控策略採取有效的行動，使項目組能在既定的時間、費用、質量要求等情況下完成項目。 意義：�6�1 是計劃執行的保障�6�1 是項目經理工作的重要依據�6�1 是項目成功的保障 2011-1-30 TPCA SEPG 17 回顧：項目跟蹤與監控的目的及意義 項目管理中常見的問題有哪些？ 為什麼會產生這些問題？ 如何解決這些問題？ 項目跟蹤與監控的目的是什麼？ CMM —CMM對項目跟蹤與監控的要求 2011-1-30 TPCA SEPG 19 CMM-項目跟蹤與監控 簡介：�6�1 CMM2級的一個關鍵過程區域—為了提供項目活動和狀態的可視性。�6�1 監視項目活動，採取控制措施�6�1 以項目計劃為中心—項目計劃是前提 用項目計劃作為跟蹤與監控的基礎 必要時修訂約定�6�1 偏差=>糾正措施「設法使接近」 2011-1-30 TPCA SEPG 20 CMM-項目跟蹤與監控（Cont.） 目的：�6�1 提供足夠的實際進度可視性，使得當項目的實際執行情況與計劃發生重大偏離時管理者能夠採取有效的行動。 包括：�6�1 跟蹤，評審�6�1 基於實際情況的調整 進度確定：�6�1 比較規模、工作量、費用、進度�6�1 在項目結束和在選定的里程碑處 2011-1-30 TPCA SEPG 21 CMM-項目跟蹤與監控（Cont.） 目標：�6�1 目標1：針對軟體計劃跟蹤實際結果和執行情況。�6�1 目標2：當實際結果和執行情況與軟體計劃發生重大偏差時採取了糾正和措施以使其與計劃相符。�6�1 目標3：受影響的組和個人對軟體約定的更改達成了一致。 2011-1-30 TPCA SEPG 22 CMM-項目跟蹤與監控（Cont.） 約定：�6�1 約定1：指定了一個項目經理對軟體活動和結果負責。�6�1 約定2：項目根據一個書面的組織方針管理軟體項目。 2011-1-30 TPCA SEPG 23 CMM-項目跟蹤與監控（Cont.） 能力：�6�1 能力1：存在一個被批準的書面的軟體開發計劃。�6�1 能力2：項目軟體經理清晰地分配了軟體工作產品和活動的負責者。�6�1 能力3：為項目跟蹤工作提供了充足的資源和資金。�6�1 能力4：軟體經理接受過管理軟體技術和人員方面的培訓。�6�1 能力5：一線軟體經理接受過軟體項目技術方面的定向培訓。 2011-1-30 TPCA SEPG 24 CMM-項目跟蹤與監控（Cont.） 活動：�6�1 活動1：一個文檔化的軟體開發計劃被用於軟體活動和溝通狀態的跟蹤；�6�1 活動2：根據一個文檔化的過程修訂項目的軟體開發計劃。�6�1 活動3：高級管理者根據一個文檔化的過程評審組織外部的個人和群組提出的軟體項目約定和對軟體項目約定的變更。 2011-1-30 TPCA SEPG 25 CMM-項目跟蹤與監控（Cont.）�6�1 活動4：軟體工程組和其他的軟體相關組的成員得到被批準的影響軟體項目約定的變更的通知。�6�1 活動5：跟蹤軟體工作產品的規模，並在必要時採取了糾正措施。�6�1 活動6：跟蹤項目的軟體工作量和費用，並在必要時採取了糾正措施。�6�1 活動7：跟蹤項目的關鍵計算機資源，並在必要時採取了糾正措施。 2011-1-30 TPCA SEPG 26 CMM-項目跟蹤與監控（Cont.）�6�1 活動8：跟蹤項目的軟體進度，並在必要時採取了糾正措施。�6�1 活動9：跟蹤軟體工程技術活動，並在必要時採取了糾正措施。�6�1 活動10：跟蹤項目中與軟體費用、資源、進度和技術等方面的風險。�6�1 活動11：記錄軟體項目的實際度量數據和重計劃數據。 2011-1-30 TPCA SEPG 27 CMM-項目跟蹤與監控（Cont.）�6�1 活動12：軟體工程組定期針對軟體開發計劃進行技術進展、計劃、執行情況和問題的內部評審。�6�1 活動13：根據一個文檔化的過程在選定的項目里程碑舉行確定軟體項目完成情況和結果的正式評審。 2011-1-30 TPCA SEPG 28 CMM-項目跟蹤與監控（Cont.） 度量：�6�1 對軟體跟蹤與監控活動進行度量並用於確定其狀態。 2011-1-30 TPCA SEPG 29 CMM-項目跟蹤與監控（Cont.） 驗證：�6�1 驗證1：高級管理者定期評審軟體項目的跟蹤與監控活動。�6�1 驗證2：項目經理定期或事件驅動地評審軟體項目的跟蹤與監控活動。�6�1 驗證3：軟體質量保證組評審和/或審計軟體項目跟蹤與監控的活動和工作產品並報告結果。—項目計劃及項目控制策略是有效的進行項目跟蹤與監控的基礎 2011-1-30 TPCA SEPG 31 項目計劃定義了項目跟蹤與監控的內容 進度 費用 風險 規模 關鍵計算機資源 工作量 其他 2011-1-30 TPCA SEPG 32 項目計劃定義了項目跟蹤與監控的策略 跟蹤的范圍 跟蹤頻度 跟蹤項偏差計算公式及域值 數據的收集方式 偏差的處理措施 2011-1-30 TPCA SEPG 33 回顧：項目跟蹤與監控的依據 項目跟蹤與監控的依據是什麼？ 為什麼說它是項目跟蹤與監控的依據？—跟蹤與監控所關注的要素 2011-1-30 TPCA SEPG 35 六大要素 要素一 進度 要素二 費用 要素三 風險 要素四 規模 要素五 關鍵計算機資源 要素六 工作量 2011-1-30 TPCA SEPG 36 要素一 進度 進度是反映項目進展程度的一種指標 進度一般用任務完成百分比表示 通過對項目進度的合理安排和控制，可以使項目按計劃有序的進行 不合理的進度計劃不利於項目的實施和跟蹤 不進行進度控制可能導致項目延期，違反項目開發合同或失去市場機會 2011-1-30 TPCA SEPG 37 要素二 費用 費用即項目開發過程中所產生的花費 費用一般用貨幣表示（如美元、人民幣等） 過低的費用估算會使項目無法完成 過高的項目費用會使軟體產品成本過高，從而失去市場競爭力 不對項目費用進行跟蹤與控制可能會使項目費用超支 2011-1-30 TPCA SEPG 38 要素三 風險 風險是有可能影響項目進度、費用、質量等一系列事件的集合 風險是一種可能，是不可預知的 風險是可預測的 風險是可規避或降低其危害程度的 不對風險進行評估、跟蹤與控制有可能導致項目失敗 2011-1-30 TPCA SEPG 39 要素四 規模 規模是表示項目大小的一種指標 規模可用多種方式表示(如UCP、KLOC、 FP等) 規模決定項目的工作量、費用、周期和項目人員安排 不對項目規模進行跟蹤與監控就無法對項目的費用和工作量進行重新估算 2011-1-30 TPCA SEPG 40 要素五 關鍵計算機資源 關鍵計算機資源：軟體組織內部構成軟體項目開發環境的、潛在需求量可能會超出其實際供給量的、可能在軟體開發過程中成為軟體項目風險的、公用的計算機資源。如對公共網路的連接需求數，對公共伺服器存儲空間的需求量等。 2011-1-30 TPCA SEPG 41 要素六 工作量 工作量是指完成某項任務所花費的人力 工作量一般可用人.時、人.周、人.月等表示 工作量會影響項目成本 不對項目的工作量進行跟蹤與控制可能會增高項目成本 2011-1-30 TPCA SEPG 42 回顧：跟蹤與監控的六大要素 項目跟蹤與監控的六大要素是什麼？ 什麼是風險，為什麼要進行風險控制？ 為什麼要對項目的進度進行跟蹤與控制？—項目跟蹤與監控方法 2011-1-30 TPCA SEPG 44 項目跟蹤與監控的本質�6�1 計劃（估算）�6�1 收集實際數據�6�1 比較實際值與計劃（估算）值的差異�6�1 重新計劃（估算），修正偏差計劃（估算）比較重新計劃（估算） 2011-1-30 TPCA SEPG 45 第一步 制訂項目計劃 估算項目規模 計劃項目進度�6�1 確定里程碑�6�1 確定階段�6�1 計劃項目任務 估算項目成本 評估項目風險 評估與確定項目的關鍵計算機資源 估算與分配項目的工作量 2011-1-30 TPCA SEPG 46 第二步 確定項目跟蹤與監控策略 確定跟蹤與監控的范圍�6�1 規模�6�1 進度（關鍵路徑，所有路徑）�6�1 費用（所有費用，設計費、折舊費等）�6�1 工作量（按核心工作流，按明細任務等）�6�1 風險（前五大風險，前十大風險，所有風險）�6�1 關鍵計算機資源�6�1 其他（技術進展，需求狀態，基線狀態等） 2011-1-30 TPCA SEPG 47 確定項目跟蹤與監控策略（Cont.） 確定每個跟蹤項的跟蹤頻度�6�1 規模（每周、每月、每階段、每里程碑等）�6�1 進度（每天、每周、每月、每階段、每里程碑等）�6�1 費用（每周、每月、每階段、每里程碑等）�6�1 工作量（每天、每周、每月、每階段、每里程碑等）�6�1 風險（每周、每月、每階段、每里程碑等）�6�1 關鍵計算機資源（每周、每月、每階段、每里程碑等） 2011-1-30 TPCA SEPG 48 確定項目跟蹤與監控策略（Cont.） 確定數據的收集方式�6�1 明確每項跟蹤數據的提供者�6�1 明確每項跟蹤數據的接收者�6�1 明確使用的工具（資料庫、電子表格等）�6�1 確定收集途徑（自動工具、郵件、在例會上陳述等） 2011-1-30 TPCA SEPG 49 確定項目跟蹤與監控策略（Cont.） 確定每個跟蹤項的偏差計算公式及域值�6�1 規模（（當前實際規模-上次估算規模）/上次估算規模；±10%， ±20%等）�6�1 進度（（當前實際進度-計劃進度）/計劃進度）；±5%，± 10%， ±20%等）�6�1 費用（（實際費用-預算費用）/預算費用）；預算±10%， ±20%等）�6�1 工作量（（實際工作量-計劃工作量）/計劃工作量；±10%， ±20%等）�6�1 風險（見《風險管理計劃》）�6�1 關鍵計算機資源（有/無，充足/不充足，最低數量等） 2011-1-30 TPCA SEPG 50 確定項目跟蹤與監控策略（Cont.） 確定偏差的處理措施 每個跟蹤項的偏差超出域值下限時應採取的措施，超出域值上限時應採取的措施�6�1 規模�6�1 進度�6�1 費用�6�1 工作量�6�1 風險（見《風險管理計劃》）�6�1 關鍵計算機資源（資源不足或不可用時應採取的措施） 2011-1-30 TPCA SEPG 51 第三步 在項目過程中進行跟蹤 在項目進行的過程中，根據項目計劃中定義的頻度和收集方式收集項目的跟蹤數據 2011-1-30 TPCA SEPG 52 第四步 分析跟蹤數據 利用實際跟蹤數據和計劃（估算）數據、偏差計算公式計算偏差率： 實際值 – 計劃值�6�1 偏差率 = ——————————— X 100% �6�1 計劃值 2011-1-30 TPCA SEPG 53 第五步 採取行動 根據跟蹤與監控策略，對發生的偏差採取相應的行動：�6�1 一般情況下，若偏差超出域值范圍，應對規模、工作量、費用進行重新估算，應重新調整項目進度、重新計劃項目任務、重新分配工作量。�6�1 對於風險應按《風險管理計劃》執行。�6�1 對於關鍵計算機資源應重新調整資源計劃。
2. 如何做好計劃跟蹤項目
當你預期的那一天，也許是害怕的那一天，終於來到了：從工程師的隊伍里你被提拔到了軟體項目領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科、人員管理以及領導能力的相關教育。 這需要更多的領導能力和管理（它們不是一回事），而不能象Dilbert（譯註：著名IT漫畫主角）那樣簡單地和老闆對抗了。當你考慮新的目標時，請考慮下面的活動計劃列表。一次就抓住了每個亮點，這是不可能的。但是這份建議說明可以幫助你將注意力放在可以提高你和你的團隊績效的活動上。 建立優先順序 作為經理，首先要做的、最重要的事是你需要有意識地建立優先順序。當你仍陷於繁重的軟體開發活動中時，你需要一套新的職責。過多的經理新手不能抗拒技術的吸引而陷於此類活動，這將導致項目組的其他人員想要獲得經理的幫助時，卻得不到幫助。 有成效的領導知道他們首要的任務是為其他組員提供服務。這些服務包括訓練和指導、解決問題和沖突、提供資源、建立項目目標和優先順序、提供適當的技術指引。要使每個組員都能清楚的知道，你總是可以幫助他們。我發現將自己定位於為被我監督的人工作是非常有意義的，而不是相反的。在你所作的事情中，對於組員要求你幫助他們這件事，應該具有非屏蔽中斷的優先順序。 第二重要的，是使你的客戶滿意。作為一名經理，沒有直接的能力使客戶滿意，因為你已不再是作為個人提供產品和服務完成這點。相反，你必須建立一種環境，准許你的組員最大程度上滿足客戶的需求。經理提供了強有力的方法，有效地提高客戶的滿意度。 第三重要的，是為你的項目工作。因為也許還有其他許多技術上的項目，或者其他經理的請求幫助，諸如為指導委員會工作。當這些和二個高級別的發生沖突時，都要准備推辭掉。 很明顯，使其他經理滿意的事情是你最不重要的事情。在一個有秩序的組織里，如果你在三個以上的重大環節上獲得了成功，其他的經理都會很激動的。我們並不都能很幸運地工作在一個良好的環境里，但一定要對你任務單上排在最前面的工作任務努力盡到最大的責任。集中精力有效地、快樂地、盡可能地幫助你的組員，不要將精力放在使你上司滿意的上面。 分析你的技能差距 除非你已經為新位置做好了准備，否則相對於你當前的領導能力和管理技能，你會感到一些差距。出色的技術背景或許是你被選為領導角色的一個因素，但是你要想幹得出色，你需要更多的技能。針對別人的評論和項目，真實地列出你的長處和短處，然後減少差距。 軟體人員並不以令人滿意的人際關系技能出名。你會希望增強處理人際關系的經驗：解決沖突、說服以及灌輸想法。你也不得不處理包括招聘、解僱、商談計劃表，以及在你的辦公室里評論某人業績使其傷心落淚等一些事務。 我發現從一堂傾聽技能課開始我的管理職業是非常好的。當作為個體提議人，積極地將我們自己的技術議程提交小組時，我們經常對此感到非常愜意。有效的管理要求更多的合作和善於接受的人際關系方式。要花點時間學習如何（何時）巧妙地引導自己的自然判斷。傾聽技能課提供了一種交流機制，我已經發現在許多場合下都很有用。 接著，到講台的另一側，提高你的演講能力。如果你真的不適應公開場合的講話，學習戴爾．卡內基的課會有幫助的。你會發覺，通過這樣的培訓獲得的經驗，以及獲得提高的交流能力，都可以幫助你更好地適應將來的工作。 作為項目領導，為了計劃和跟蹤項目，以及當需要項目回退而採取修正措施時，你有責任調整其他人的工作。參加項目管理的培訓課，閱讀一些有關項目和風險管理的書籍和文章。參加項目管理學會，閱讀其月刊--PMNetwork。SEI的軟體能力成熟度模型對於軟體項目計劃和項目跟蹤提供了很多有用的建議。建立優先順序的能力、控制有效果的會議、清晰的交流，對於你，作為一名經理的績效將會有實質上的影響。 定義「質量」 幾乎每個人都會認真地對待質量問題而且都希望生產出高質量的產品。然而，對於軟體的質量含義，沒有一個統一的定義。傳統上的軟體質量觀點和「足夠好」的軟體觀點有著激烈的爭論。為了幫助小組走向成功，需要花一些時間和你的組員、客戶共同探討質量的含義。 這兩種陣營在思想上經常不會有相同的定義，可以很容易的就不同目的開展工作。關注交付計劃的經理對於想正常地檢查每行代碼的工程師會不耐煩的；認為可靠性非常重要的客戶對一個帶有很少使用但帶有很多bugs的特性的產品是不會滿意的；一個很好的GUI也許會讓用戶厭煩，因為用戶已經熟記了如何有效地使用前一個版本的產品。 為了更好的理解客戶對軟體質量的看法，在Kodak，我的小組曾經邀請了我們的客戶和他們的經理就這個議題在一個開放的論壇展開討論。這個論壇是很有意義的，那些使用我們產品的人有著自己的理解，通過討論，我們可以知道我們制定質量的思路有哪些和他們是不相符的。明白了不同，就可以使你集中精力，照顧客戶的最大利益，而不是使開發人員獲得最大滿意。 軟體質量的傳統描述包括要與說明書一致，滿足客戶的需求，代碼和文檔沒有缺陷。「六個∑質量」（six-sigmaquality）這個流行詞，建立了一個非常高的尺度，用於監測失敗的頻率和密度。但它不適用於如快速產品交付，可用性，充足的特性集，已支付價錢的交付意義這樣的質量尺度，。對於我們生產和購買的產品，我們總是熱衷於盡可能涵蓋所有的這些質量特性，然而，妥協總是必須的。 在一個項目的需求階段，我們制定了包括十項質量屬性的一個列表，如效率，協同性，正確性以及宜於學習，我們認為這對於用戶來說是最重要的。我們請客戶關鍵人物代表小組以1到5的尺度評估每項屬性。一旦我們決定了哪些屬性是最重要的，我們就可以設計並實現這些目標。如果你在了解了對於客戶的質量含義並在設計實現質量屬性的過程中沒有麻煩的話，而且客戶對質量屬性表示滿意，那你是很幸運的。 在眾多關注的質量說明中，我曾聽到過一個：「客戶回來了，但產品沒有」。和你的客戶、開發人員一起對每一個產品都確定適當的質量目標。一旦決定了，就給出達到質量目標的明確的最高優先順序。以身作則，按很高的質量標准要求你自己的工作。採用這個座右銘：「力求盡善盡美，滿足於優秀。」 表彰成績 對你組員成績的表彰和獎勵，是激勵他們的一種很重要的手段。除非你的小組中已經有了一種表彰程序，否則這應是你最重要的事情之一。表彰包括象徵性的東西（證書，旅遊獎勵）以及實際的東西（電影票，餐館禮品券，兌現獎）。在送贈品時要說一些親切的話語：「感謝你所給予的幫助」或者「祝賀取得了成績」。在表彰和獎勵上花費很少的心思和錢，就可以獲得很多的友好和將來的合作。包括客戶代表，以及為項目成功做出過貢獻的支持人員等等開發組外的人員也可以獲得表彰。 和你的組員討論，了解他們感興趣的表彰和獎勵的方式。使得無論大小成就的表彰活動成為小組文化的一個標准組成部分。對每位組員對其所作的工作表現出發自內心的興趣也要給與含蓄的表揚，為消除所有影響他們戰鬥力的障礙盡你的力量。表彰是展示組員以及小組外的其他人的一種方式――你要知道並感謝他們為小組成功所作的貢獻。 學習過去 你的小組在過去承擔的一些項目有可能沒有取得完全的成功。甚至在成功的項目上，我們也能經常認為一些事情我們下次會作得更好。當你進入了新的領導角色，需要花點時間了解早期的項目為什麼失敗，並要計劃避免犯同樣的錯誤。對於軟體開發，每位經理花時間處理每種可能要發生的錯誤是非常困難的，學習過去的成功和失敗就是個成功的開始。 可以從過去你們小組承擔的一個沒有經過檢查評估的項目著手，不要管其成功還是失敗，實施項目後的回顧（有時稱作事後調查分析）。你的目標不是判定責任，而是為了在將來項目中作得更好。藉此，可以了解什麼已經作得很好，什麼應該作得更好。在當前每個項目的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領導小組用頭腦風暴的方式對其展開分析。 另外，要了解領悟已有的軟體工業的最佳准則。一個好的起點是SteveMcConnell的JoltAward獲獎作品：快速開發（RapidDevelopment，MicrosoftPress，1996）的第三部分，敘述了27個最佳准則。也要避免McConnell敘述的36個常見的軟體開發錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領導，要確保團隊一致連續地使用最佳可用的方法、過程和工具。積極促進組員之間的信息共享，這樣局部單個最好的實踐經驗就能成為每個開發人員的工具箱的一部分。 建立改進目標 一旦你對過去的項目建立起了回顧，確立了質量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否採取了適當的過程朝著目標前進。 例如，如果你認定由於需求的不穩定導致項目經常延期，你可以建立一個改進需求穩定的目標，在6個月內提高50%。這樣一個目標需要你確切知道每周或每月需求的變化數，清楚他們的出處，採取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。 你的目標和階段是軟體過程改進程序的組成部分，你要使之有序。作為缺乏創造力的官僚主義的最後避難所，輕視「過程」很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結果。 有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預知的可能威脅項目成功的問題。領導你的小組找出當前正在使用的方法的長處和短處，以及項目面臨的風險。 我的小組召開了一次「兩段式頭腦風暴」練習，來確定改進軟體生產力和質量過程的絆腳石。在第一次會議中，參會者在便條上寫出他們關於會議主題的想法，一個便條一個想法。組織者將他們寫在便條上的想法收集上來並分組。最後，我們就會得到一打主要的分類，並將其記錄到活動掛圖上。 第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，並貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現軟體的質量和生產力的目標。 建立可度量和可達到的目標，便於你集中精力實現改進。要使目標具有明顯的優先順序，並可周期性地監視過程。記住你的目的是，提高你的項目和公司完成的技術和業務上成功，不要滿足於一些過程改進書籍里提到的期望細節。要把改進的工作視為迷你項目，具有可分發、資源、計劃和有責任的小項目。否則，過程改進活動將總處於比誘人的技術工作低的優先順序上。 緩慢的開始 這篇文章提供了許多建議，幫助你，一位軟體經理新人，帶領你的小組走向偉大的成功。在日復一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟體開發小組的文化和習慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環境最相關的的幾個開始。 作為軟體經理，除了項目要按時按照預算完成外，你要擔負的責任還很多。你還要：領導技術人員，將他們形成一個具有凝聚力的團隊；建立協同團隊工作的環境；鼓勵和獎賞高級軟體工程師的實踐應用；平衡來自客戶、公司，組員和你自己的需求。 這是項重大的任務，祝你好運。
3. 項目策劃書
一、策劃書名稱
盡可能具體的寫出策劃名稱，如「×年×月××公會××活動策劃書」，置於頁面中央，當然可以寫出正標題後將此作為副標題寫在下面。
二、
活動背景
：
這部分內容應根據策劃書的特點在以下項目中選取內容重點闡述；具體項目有：基本情況簡介、主要執行對象、近期狀況、組織部門、活動開展原因、社會影響、以及相關目的動機。其次應說明問題的環境特徵，主要考慮環境的內在優勢、弱點、機會及威脅等因素，對其作好全面的分析(SWOT分析)，將內容重點放在環境分析的各項因素上，對過去現在的情況進行詳細的描述，並通過對情況的預測制定計劃。如環境不明，則應該通過調查研究等方式進行分析加以補充。
三、活動目的、意義和目標：
活動的目的、意義應用簡潔明了的語言將目的要點表述清楚；在陳述目的要點時，該活動的核心構成或策劃的獨到之處及由此產生的意義（經濟效益、社會利益、媒體效應等）都應該明確寫出。活動目標要具體化，並需要滿足重要性、可行性、時效性
四、資源需要：
列出所需人力資源，物力資源，包括使用的地方，如教室或使用活動中心都詳細列出。可以列為已有資源和需要資源兩部分。
五、活動開展：
作為策劃的正文部分，表現方式要簡潔明了，使人容易理解，但表述方面要力求詳盡，寫出每一點能設想到的東西，沒有遺漏。在此部分中，不僅僅局限於用文字表述，也可適當加入統計圖表等；對策劃的各工作項目，應按照時間的先後順序排列，繪制實施時間表有助於方案核查。人員的組織配置、活動對象、相應權責及時間地點也應在這部分加以說明，執行的應變程序也應該在這部分加以考慮。
這里可以提供一些參考方面：會場布置、接待室、嘉賓座次、贊助方式、合同協議、媒體支持、校園宣傳、廣告製作、主持、領導講話、司儀、會場服務、電子背景、燈光、音響、攝像、信息聯絡、技術支持、秩序維持、衣著、指揮中心、現場氣氛調節、接送車輛、活動後清理人員、合影、餐飲招待、後續聯絡等。請根據實情自行調節。
六、經費預算：
活動的各項費用在根據實際情況進行具體、周密的計算後，用清晰明了的形式列出。
七、活動中應注意的問題及細節：
內外環境的變化，不可避免的會給方案的執行帶來一些不確定
性因素，因此，當環境變化時是否有應變措施，損失的概率是多少，造成的損失多大，應急措施等也應在策劃中加以說明。
八、活動負責人及主要參與者：
註明組織者、參與者姓名、嘉賓、單位（如果是小組策劃應註明小組名稱、負責人）。
注意：
1、本策劃書提供基本參考方面，小型策劃書可以直接填充；大型策劃書可以不拘泥於表格，自行設計，力求內容詳盡、頁面美觀；
2、可以專門給策劃書製作封頁，力求簡單，凝重；策劃書可以進行包裝，如用設計的徽標做頁眉，圖文並茂等；
3、如有附件可以附於策劃書後面，也可單獨裝訂；
4、策劃書需從紙張的長邊裝訂；
5、一個大策劃書，可以有若乾子策劃書。
4. 如何跟蹤項目的管理、控制與策劃
建議：
一，對項目管理的工作流程做一個清理，對工作的環節，部門間的銜接做一個梳理；
二，對單個項目做一個典型的管理計劃，不同類型的項目非別理出關鍵節點；主要針對需要協調和交接的事項；
三，用項目管理軟體編制進度計劃，方便多項目的綜合協調管理；
四，圖表曲線等直觀管理工具運用。
這些是從項目管理的角度來看的，實踐中可以運用市場管理的專業要求作靈活安排。
淺陋之見，略供參考。