成功項(xiàng)目管理的方法

1、成功項(xiàng)目管理的秘密1. 定義項(xiàng)目成功的標(biāo)準(zhǔn)在項(xiàng)目的開始， 要保證風(fēng)險(xiǎn)承擔(dān)者對(duì)于他們?nèi)绾闻袛囗?xiàng)目是否成功有統(tǒng) 一的認(rèn)識(shí)。經(jīng)常，滿足一個(gè)預(yù)定義的進(jìn)度安排是唯一明顯的成功因素， 但是肯定還有其它的因素存在，比如：增加市場(chǎng)占有率，獲得指定的銷 售量或銷售額，取得特定用戶滿意程度，淘汰一個(gè)高維護(hù)需求的遺留系 統(tǒng)，取得一個(gè)特定的事務(wù)處理量并保證正確性。2. 識(shí)別項(xiàng)目的驅(qū)動(dòng)、約束和自由程度每個(gè)項(xiàng)目都需要平衡它的功能性，人員，預(yù)算，進(jìn)度和質(zhì)量目標(biāo)。我們 把以上五個(gè)項(xiàng)目方面中的每一個(gè)方面，要么定義成一個(gè)約束，你必須在 這個(gè)約束中進(jìn)行操作，要么定義成與項(xiàng)目成功對(duì)應(yīng)的驅(qū)動(dòng)，或者定義成 通向成功的自由程度，你可以在一

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

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

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

5、員已經(jīng)淹沒(méi)在他們當(dāng)前的項(xiàng)目中， 但是如果你想把你的組提 升到一個(gè)更高的軟件工程能力水平， 你就必須投資一些時(shí)間在過(guò)程改進(jìn) 上。從你的項(xiàng)目進(jìn)度中留出一些時(shí)間，因?yàn)檐浖?xiàng)目活動(dòng)應(yīng)該包括做能 夠幫助你下一個(gè)項(xiàng)目更加成功的過(guò)程改進(jìn)。 不要把你項(xiàng)目成員可以利用 的時(shí)間 100 的投入到項(xiàng)目任務(wù)中，然后驚訝于為什么他們?cè)谥鲃?dòng)提高 方面沒(méi)有任何進(jìn)展。10. 管理項(xiàng)目的風(fēng)險(xiǎn) 如果你不去識(shí)別和控制風(fēng)險(xiǎn)，那么它們會(huì)控制你。在項(xiàng)目計(jì)劃時(shí)花一些 時(shí)間集體討論可能的風(fēng)險(xiǎn)因素，評(píng)估它們的潛在危害，并且決定你如何 減輕或預(yù)防它們。要一個(gè)軟件風(fēng)險(xiǎn)管理的簡(jiǎn)要的指南，參見我的文章 “Know Your Enemy: Softwa

6、re Risk Management ”( Oct. 1998 )。11. 根據(jù)工作計(jì)劃而不是日歷來(lái)作估計(jì) 人們通常以日歷時(shí)間作估計(jì)， 但是我傾向于估計(jì)與任務(wù)相關(guān)聯(lián)的工作計(jì) 劃(以人時(shí)為單位)的數(shù)量，然后把工作計(jì)劃轉(zhuǎn)換為日歷時(shí)間的估計(jì)。 這個(gè)轉(zhuǎn)換基于每天我有多少有效的小時(shí)花費(fèi)在項(xiàng)目任務(wù)上， 我可能碰到 的任何打斷或突發(fā)調(diào)整請(qǐng)求，會(huì)議，和所有其它會(huì)讓時(shí)間消失的地方。12. 不要為人員安排超過(guò)他們 80的時(shí)間跟蹤你的組員每周實(shí)際花費(fèi)在項(xiàng)目指定工作的平均小時(shí)數(shù)， 實(shí)在會(huì)讓人 吃驚。與我們被要求做的許多活動(dòng)相關(guān)的任務(wù)切換的開銷，顯著地降低 了我們的工作效率。不要只是因?yàn)橛腥嗽谝豁?xiàng)特定工作上每周花費(fèi) 1

7、0 小時(shí)，就去假設(shè)他或她可以馬上做 4 個(gè)這種任務(wù)，如果他或她能夠處理 完 3 個(gè)任務(wù)，你就很幸運(yùn)了。13. 將培訓(xùn)時(shí)間放到計(jì)劃中確定你的組員每年在培訓(xùn)上花費(fèi)多少時(shí)間， 并把它從組員工作在指定項(xiàng) 目任務(wù)上的可用時(shí)間中減去。你可能在平均值中早已經(jīng)減去了休假時(shí) 間、生病時(shí)間和其它的時(shí)間，對(duì)于培訓(xùn)時(shí)間也要同樣的處理。14. 記錄你的估算和你是如何達(dá)到估算的當(dāng)你準(zhǔn)備估算你的工作時(shí)，把它們記錄下來(lái)，并且記錄你是如何完成每 個(gè)任務(wù)的。理解創(chuàng)建估算所用的假設(shè)和方法，能夠使它們?cè)诒匾臅r(shí)候 更容易防護(hù)和調(diào)整，而且它將幫助你改善你的估算過(guò)程。15. 記錄估算并且使用估算工具有很多商業(yè)工具可以幫助你估算整個(gè)項(xiàng)目。

8、 根據(jù)它們真實(shí)項(xiàng)目經(jīng)驗(yàn)的巨 大數(shù)據(jù)庫(kù)，這些工具可以給你一個(gè)可能的進(jìn)度和人員分配安排選擇。它 們同樣能夠幫助你避免進(jìn)入“不可能區(qū)域”，即產(chǎn)品大小，小組大小和 進(jìn)度安排組合起來(lái)沒(méi)有已知項(xiàng)目成功的情況。 Software Productivity Centre() 公司的 Estimate Pro 是可以一試的好工具。16. 遵守學(xué)習(xí)曲線如果你在項(xiàng)目中第一次嘗試新的過(guò)程，工具或技術(shù)，你必須認(rèn)可付出短 期內(nèi)生產(chǎn)力降低的代價(jià)。 不要期望在新軟件工程方法的第一次嘗試中就 獲得驚人的效益，在進(jìn)度安排中考慮不可避免的學(xué)習(xí)曲線。17. 考慮意外緩沖 事情不會(huì)象你項(xiàng)目計(jì)劃的一樣準(zhǔn)確的進(jìn)行， 所以你的預(yù)算和進(jìn)度安排

9、應(yīng)該在主要階段后面包括一些意外的緩沖，以適應(yīng)無(wú)法預(yù)料的事件。不幸 的是，你的管理者或客戶可能把這些緩沖作為填料，而不是明智的承認(rèn) 事實(shí)確實(shí)如此。 指明一些以前項(xiàng)目不愉快的意外， 來(lái)說(shuō)明你的深謀遠(yuǎn)慮。18. 記錄實(shí)際情況與估算情況如果你不記錄花費(fèi)在每項(xiàng)任務(wù)上的實(shí)際工作時(shí)間，并和你的估算作比 較，你將永遠(yuǎn)不能提高你的估算能力。你的估算將永遠(yuǎn)是猜測(cè)。19. 只有當(dāng)任務(wù) 100% 完成時(shí)，才認(rèn)為該任務(wù)完成使用英寸大小的小圓石的一個(gè)好處是， 你可以區(qū)分每個(gè)小任務(wù)要么完成 了，要么沒(méi)有完成，這比估計(jì)一個(gè)大任務(wù)在某個(gè)時(shí)候完成了多少百分比 要實(shí)在的多。不要讓人們只入不舍他們?nèi)蝿?wù)的完成狀態(tài)；使用明確的標(biāo) 準(zhǔn)來(lái)判

10、斷一個(gè)步驟是否真正的完成了。20. 公開、公正地跟蹤項(xiàng)目狀態(tài)創(chuàng)建一個(gè)良好的風(fēng)氣，讓項(xiàng)目成員對(duì)準(zhǔn)確地報(bào)告項(xiàng)目的狀態(tài)感到安全。努力讓項(xiàng)目在準(zhǔn)確的、基于數(shù)據(jù)的事實(shí)基礎(chǔ)上運(yùn)行，而不是從因?yàn)楹ε聢?bào)告壞消息而產(chǎn)生的令人誤解的樂(lè)觀主義。 使用項(xiàng)目狀態(tài)信息在必要的 時(shí)候進(jìn)行糾正操作，并且在條件允許時(shí)進(jìn)行表?yè)P(yáng)。 這些提示不能保證你的成功， 但是它們將幫助你在你的項(xiàng)目上獲得一個(gè) 堅(jiān)實(shí)的把手， 并且保證你做了所有你可以做的事來(lái)讓項(xiàng)目在這個(gè)瘋狂的 世界上成功。veManaging software projects is difficult under the best circumstances. Unfortun

11、ately, many new project managers receive virtually no job 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 I learned from both well-managed and challenged

12、projects. Keep these suggestions in mind during your next project, recognizing that none of them is a silver bullet for your project management problems.Laying the GroundworkTip #1: Define project success criteria. At the beginning of the project, make sure the stakeholders share a common understand

13、ing of how they will determine whether this project 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 sati

14、sfaction measures, retiring a high-maintenance legacy 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 obje

15、ctives. Define each of these five project dimensions 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 Engi

16、neering Culture (Dorset House, 1996).Tip #3: Define 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, specif

17、ic functionality being fully operational, or other 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

18、 impossible, never make a co mmitment you know you can ' t keep.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 unreas

19、onable people.Planning the WorkTip #5: Write a plan. Some people believe the time spent writing aplan could be better spent writing code, but I don' t agree. The hardpart isn ' t writing the plan. The hard part is actually doing the planning thinking, negotiating, balancing, talking, asking,

20、 and listening. The time you spend analyzing what it will take to solve the problem 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

21、 helps you estimate them more accurately, reveals work activities youmight 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

22、a new object class, develop activity checklists and planning worksheets for 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 ta

23、sk he or she must tackle.Tip #8: Plan to do rework after a quality control 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 ta

24、sk after every quality contro l activity. If you don' t actually have to do anyrework, great; you're ahead of schedule on that task. But don' t counton it.Tip #9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if youwa

25、nt the group to rise to a higher plane of software engineering capability, you' ll have to 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 mo

26、re successful. Don' t allocate 100% ofyour team members ' available time to project tasks and then wonder why they don ' t make any progress on the improvement initiatives.Tip #10: Manage project risks. If you don t identify'and control risks , they will control you. Spend some time

27、during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can 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 ProjectTi

28、p #11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I prefer 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

29、how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.Tip #12: Don ' t schedule people for more than 80%of their time.Tracking the average weekly hours that your te

30、am members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Don' t assume thatjust because someone spends 10 hours per week on a particular act

31、ivity, he or she can do fo ur of them at once; you' ll be lucky if he orshe can handle three.Tip #13: Build training time into the schedule. Determine how much time your team members typically spend on training activities annually, and subtract that from the time available for them to be assigne

32、d to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time 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 arr

33、ived at each of them. Understanding theassumptions and approaches used to create an estimate will make them easier to defend and adjust when 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

34、projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation option s. They ' ll also help you stay out of the "impossible region," combinations of product size, team size, and schedule where no known p

35、roject has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre ().Tip #16: Respect the learning curve. If you' re 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 pr

36、oductivity loss. Don' texpect to get the fabulous benefits of new software engineering approaches on the first try, so build extra time into the schedule to account for the inevitable learning curve.Tip #17: Plan contingency buffers. Things never go precisely as you plan on a project, so your bu

37、dget and schedule should include somecontingency 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 ProgressTip #18: Record actu