成功項目管理的方法

1、成功項目管理的秘密 1. 定義項目成功的標準 在項目的開始，要保證風險承擔者對于他們如何判斷項目是否成功有統(tǒng)一的認識。經常，滿足一個預定義的進度安排是唯一明顯的成功因素，但是肯定還有其它的因素存在，比如：增加市場占有率，獲得指定的銷售量或銷售額，取得特定用戶滿意程度，淘汰一個高維護需求的遺留系統(tǒng)，取得一個特定的事務處理量并保證正確性。 2. 識別項目的驅動、約束和自由程度 每個項目都需要平衡它的功能性，人員，預算，進度和質量目標。我們把以上五個項目方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進行操作，要么定義成與項目成功對應的驅動，或者定義成通向成功的自由程度，你可以在一個規(guī)定的

2、范圍內調整。相關的詳細信息，請參照我的創(chuàng)建一種軟件工程文化（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。 3. 定義產品發(fā)布標準 在項目早期，要決定用什么標準來確定產品是否準備好發(fā)布了。你可以把發(fā)布標準基于：還存在有多少個高優(yōu)先級的缺陷，性能度量，特定功能完全可操作，或其它方面表明項目已經達到了它的目的。不管你選擇了什么標準，都應該是可實現的、可測量的、文檔化的，并且與你的客戶指的“質量”一致。 4. 溝通承諾 盡管有承諾不可能事件的壓力，從不作一個你知道你不能保證的承諾。和客戶和管理人員溝通哪些可以實際取

3、得時，要有好的信譽。你的任何以前項目的數據會幫助你作說服的論據，雖然這對于不講道理的人來說沒有任何真正的防御作用。 5. 寫一個計劃 有些人認為，花時間寫計劃還不如花時間寫代碼，但是我不這么認為。困難的部分不是寫計劃。困難的部分是作這個計劃-思考，溝通，權衡，交流，提問并且傾聽。你用來分析解決問題需要花費的時間，會減少項目以后會帶給你的意外。 6. 把任務分解成英寸大小的小圓石 英寸大小的小圓石是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確的估計它們，暴露出在其它情況下你可能沒有想到的工作 活動，并且保證更加精確、細密的狀態(tài)跟蹤。7. 為通用的大任務開發(fā)計劃工作表 如果你的組經常承

4、擔某種特定的通用任務，如實現一個新的對象類，你需要為這些任務開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他/她必須處理的大任務的每個實例相關的工作量。 8. 計劃中，在質量控制活動后應該有修改工作 幾乎所有的質量控制活動，如測試和技術評審，都會發(fā)現缺陷或其它提高的可能。你的項目進度或工作細分結構，應該把每次質量控制活動后的修改，作為一個單獨的任務包括進去。如果你事實上不用作任何的修改，很好，你已經走在了本任務的計劃前面。但是不要去指望它。 9. 為過程改進安排時間 你的小組成員已經淹沒在他們當前的項目中，但是

5、如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進上。從你的項目進度中留出一些時間，因為軟件項目活動應該包括做能夠幫助你下一個項目更加成功的過程改進。不要把你項目成員可以利用的時間100的投入到項目任務中，然后驚訝于為什么他們在主動提高 方面沒有任何進展。10. 管理項目的風險 如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定你如何減輕或預防它們。要一個軟件風險管理的簡要的指南，參見我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998

6、）。 11. 根據工作計劃而不是日歷來作估計 人們通常以日歷時間作估計，但是我傾向于估計與任務相關聯的工作計劃（以人時為單位）的數量，然后把工作計劃轉換為日歷時間的估計。這個轉換基于每天我有多少有效的小時花費在項目任務上，我可能碰到的任何打斷或突發(fā)調整請求，會議，和所有其它會讓時間消失的地方。 12. 不要為人員安排超過他們80的時間 跟蹤你的組員每周實際花費在項目指定工作的平均小時數，實在會讓人吃驚。與我們被要求做的許多活動相關的任務切換的開銷，顯著地降低了我們的工作效率。不要只是因為有人在一項特定工作上每周花費10小時，就去假設他或她可以馬上做4個這種任務，如果他或她能夠處理完3個任務，你

7、就很幸運了。 將培訓時間放到計劃中13. 確定你的組員每年在培訓上花費多少時間，并把它從組員工作在指定項目任務上的可用時間中減去。你可能在平均值中早已經減去了休假時間、生病時間和其它的時間，對于培訓時間也要同樣的處理。 14. 記錄你的估算和你是如何達到估算的 當你準備估算你的工作時，把它們記錄下來，并且記錄你是如何完成每個任務的。理解創(chuàng)建估算所用的假設和方法，能夠使它們在必要的時候更容易防護和調整，而且它將幫助你改善你的估算過程。 15. 記錄估算并且使用估算工具 有很多商業(yè)工具可以幫助你估算整個項目。根據它們真實項目經驗的巨大數據庫，這些工具可以給你一個可能的進度和人員分配安排選擇。它們同

8、樣能夠幫助你避免進入“不可能區(qū)域”，即產品大小，小組大小和進度安排組合起來沒有已知項目成功的情況。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一試的好工具。 16. 遵守學習曲線 如果你在項目中第一次嘗試新的過程，工具或技術，你必須認可付出短期內生產力降低的代價。不要期望在新軟件工程方法的第一次嘗試中就 獲得驚人的效益，在進度安排中考慮不可避免的學習曲線。17. 考慮意外緩沖 事情不會象你項目計劃的一樣準確的進行，所以你的預算和進度安排應該在主要階段后面包括一些意外的緩沖，以適應無法預料的事件。不幸的是，你的管理者或客戶可

9、能把這些緩沖作為填料，而不是明智的承認事實確實如此。指明一些以前項目不愉快的意外，來說明你的深謀遠慮。 18. 記錄實際情況與估算情況 如果你不記錄花費在每項任務上的實際工作時間，并和你的估算作比較，你將永遠不能提高你的估算能力。你的估算將永遠是猜測。 19. 只有當任務100%完成時，才認為該任務完成 使用英寸大小的小圓石的一個好處是，你可以區(qū)分每個小任務要么完成了，要么沒有完成，這比估計一個大任務在某個時候完成了多少百分比要實在的多。不要讓人們只入不舍他們任務的完成狀態(tài)；使用明確的標準來判斷一個步驟是否真正的完成了。 20. 公開、公正地跟蹤項目狀態(tài) 創(chuàng)建一個良好的風氣，讓項目成員對準確地

10、報告項目的狀態(tài)感到安全。努力讓項目在準確的、基于數據的事實基礎上運行，而不是從因為害怕報告壞消息而產生的令人誤解的樂觀主義。使用項目狀態(tài)信息在必要的時候進行糾正操作，并且在條件允許時進行表揚。 這些提示不能保證你的成功，但是它們將幫助你在你的項目上獲得一個堅實的把手，并且保證你做了所有你可以做的事來讓項目在這個瘋狂的世界上成功。 Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no jo

11、b training. Sometimes you must rely on coaching and survival tips from people who have already done their tour of duty in the project management trenches. Here are 20 such tips for success, which Ive learned from both well-managed and challenged projects. Keep these suggestions in mind during your n

12、ext project, recognizing that none of them is a silver bullet for your project management problems. Laying the Groundwork Tip #1: Define project success criteria. At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project

13、is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Some examples are increasing market share, reaching a specified sales volume or revenue, achieving specific customer satisfaction measures, retiring a high-maintenance lega

14、cy system, and achieving a particular transaction processing volume and correctness. Tip #2: Identify project drivers, constraints, and degrees of freedom. Every project needs to balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensio

15、ns as either a constraint within which you must operate, a driver aligned with project success, or a degree of freedom that you can adjust within some stated bounds to succeed. For more details about this, see Chapter 2 of my Creating a Software Engineering Culture (Dorset House, 1996). Tip #3: Defi

16、ne product release criteria. Early in the project, decide what criteria will determine whether or not the product is ready for release. You might base release criteria on the number of high-priority defects still open, performance measurements, specific functionality being fully operational, or othe

17、r indicators that the project has met its goals. Whatever criteria you choose should be realistic, measurable, documented, and aligned with what quality means to your customers. Tip #4: Negotiate commitments. Despite pressure to promise the impossible, never make a commitment you know you cant keep.

18、 Engage in good-faith negotiations with customers and managers about what is realistically achievable. Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against unreasonable people. Planning the Work Tip #5: Write a plan. Some people

19、believe the time spent writing a plan could be better spent writing code, but I dont agree. The hard part isnt writing the plan. The hard part is actually doing the planningthinking, negotiating, balancing, talking, asking, and listening. The time you spend analyzing what it will take to solve the p

20、roblem will reduce the number of surprises you have to cope with later in the project. Tip #6: Decompose tasks to inch-pebble granularity. Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might

21、not have thought of otherwise, and permits more accurate, fine-grained status tracking. Tip #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets fo

22、r these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle. Tip #8: Plan to do rework after a quality contro

23、l activity. Almost all quality control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you dont actually have to do

24、any rework, great; youre ahead of schedule on that task. But dont count on it. Tip #9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, youll have t

25、o invest some time in process improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Dont allocate 100% of your team members available time to project tasks and t

26、hen wonder why they dont make any progress on the improvement initiatives. Tip #10: Manage project risks. If you dont identify and control risks , they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you c

27、an mitigate or prevent them. For a concise tutorial on software risk management, see my article Know Your Enemy: Software Risk Management (Oct. 1998). Estimating the Project Tip #11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I pref

28、er to estimate the amount of effort (in labor-hours) associated with a task, then translate the effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get,

29、meetings, and all the other places into which time disappears. Tip #12: Dont schedule people for more than 80%of their time. Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with

30、the many activities we are all asked to do reduces our effectiveness significantly. Dont assume that just because someone spends 10 hours per week on a particular activity, he or she can do four of them at once; youll be lucky if he or she can handle three. Tip #13: Build training time into the sche

31、dule. Determine how much time your team members typically spend on training activities annually, and subtract that from the time available for them to be assigned to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training ti

32、me the same way. Tip #14: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust w

33、hen necessary, and it will help you improve your estimation process. Tip #15: Use estimation tools. Many commercial tools are available to help you estimate entire projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff al

34、location options. Theyll also help you stay out of the impossible region, combinations of product size, team size, and schedule where no known project has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre (www.spc.ca). Tip #16: Respect the learning curve. If y

35、oure trying new processes, tools, or technologies for the first time on this project, recognize that you will pay a price in terms of a short-term productivity loss. Dont expect to get the fabulous benefits of new software engineering approaches on the first try, so build extra time into the schedul

36、e to account for the inevitable learning curve. Tip #17: Plan contingency buffers. Things never go precisely as you plan on a project, so your budget and schedule should include some contingency buffers at the end of major phases to accommodate the unforeseen. Unfortunately, your manager or customer may view these buffers as padding, rather than the sensible acknowledgement of reality that they are. Point to unpleasant surprises on previous projects as a rationale for your foresight. Tracking Your Prog