敏捷，scrum，看板，精益，xp，瀑布、PRINCE2和PMBOK，這么多不斷演變的項目管理方法可能會讓人困惑。在你看了這個完整的項目管理方法指南中，這一切都變得非常簡單易懂。

有許多不同的項目管理方法可以應(yīng)用于不同的項目，但了解它們之間的差異，以及選擇適合使用哪種方法卻是非常棘手的。

閱讀本指南，讓您自己了解最常用的項目管理方法，并考慮它們?nèi)绾尾拍茉谛畔F隊交付項目的過程中發(fā)揮最佳作用。

常見9種項目管理方法概述：

• 敏捷 — 協(xié)作迭代交付任何作品
• Scrum — 使一個小型，跨職能，自我管理的團隊能夠快速交付
• 看板 — 通過提高工作進展的可視性，提高交付速度和質(zhì)量，并限制多任務(wù)處理
• Scrumban — 像看板一樣每天都像Scrum一樣限制工作進展
• 精益 — 簡化和消除浪費，以更少的投入獲得更多
• XP — 極限編程方法 – 堅定地進行開發(fā)以確保質(zhì)量
• 瀑布 — 完全規(guī)劃項目，然后通過階段執(zhí)行
• PRINCE2 — 受控的項目管理，沒有任何機會
• PMI的PMBOK — 將通用標(biāo)準(zhǔn)應(yīng)用于瀑布項目管理

看完下面關(guān)于每種方法的介紹之后，請關(guān)注本頭條，還將繼續(xù)介紹《如何選擇項目管理方法》《對于外包團隊最佳的項目管理方法》

介紹項目管理方法

讓我們試著了解項目管理方法是什么。PMI對項目管理方法論的廣泛定義是有幫助的 – “方法論是一個在一門學(xué)科中工作的人使用的實踐，技術(shù)，程序和規(guī)則的系統(tǒng)” – 但方法學(xué)必須植根于更基本的東西，這就決定了我們?yōu)槭裁匆x擇以某種方式做事，所以我建議它也應(yīng)該包括主題。

作為項目經(jīng)理，交付項目有很多不同的方式。一般來說，這些方式是我們的方法論 – 應(yīng)用不同的原則，主題，框架，流程和標(biāo)準(zhǔn)來幫助為我們交付項目提供結(jié)構(gòu)。

項目管理方法

某些項目管理方法只是簡單地定義了基本原則，比如Agile敏捷。而有的則定義了包括主題，原則和流程的“全套”方法框架，如Prince2。有些是與一些過程有關(guān)的標(biāo)準(zhǔn)的廣泛列表，如PMI的PMBOK或XP，其中一些非常輕便，并且簡單地定義過程，如Scrum。

也許會有爭議，但是與其無休止地爭論爭論哪些屬于方法論哪些不是，我寧可認(rèn)為使用對項目管理方法的較為寬泛（也許不準(zhǔn)確）的理解，簡單地指我們綜合運用各種方法一起把項目完成的最佳實踐框架。我不認(rèn)為一種方法必須是一個完整的全棧實現(xiàn)“系統(tǒng)”才能被視為一種方法。

這是一個很好且有用的定義，因為事實上，作為項目經(jīng)理，我們會使用為客戶和項目量身定制的各種原則，主題和流程的大雜燴。

在我們開始之前，讓我們先弄清楚一件事情，方法論有很多，但沒有絕對“正確的”方法。沒有一種萬能的方法是每個項目都應(yīng)該始終使用的方法。

最終，最好的方法是合理的且最適合項目、團隊和客戶的。我們先來看看一些比較流行的項目管理方法，并了解一些在信息世界中交付項目的寶貴經(jīng)驗。

通用項目管理方法

敏捷方法論 – 協(xié)作迭代交付任何作品

讓我們從每個人最喜歡的流行詞開始，敏捷。事實上，敏捷并不是一種方法論，而是一套開發(fā)軟件的原則。敏捷宣言概述了四條基本原則 – 個人與過程與工具之間的相互作用 ; 通過全面的文檔工作軟件 ; 客戶協(xié)作合同談判; 回應(yīng)計劃的變化 – 敏捷更多的是理念和一套遵循的價值觀和原則，而不是適用于項目的過程。

當(dāng)人們談?wù)撁艚蓓椖抗芾矸椒ㄕ摃r，他們通常所描述的是一個靈活的迭代設(shè)計和構(gòu)建過程。敏捷項目的特點是根據(jù)具體情況需要構(gòu)思，執(zhí)行和調(diào)整的一系列任務(wù)，而不是預(yù)先規(guī)劃的過程。敏捷可以幫助團隊通過增量迭代工作流程來應(yīng)對不可預(yù)測性。

就像一個好廚師在烹飪過程中品嘗食物時一樣，在添加缺少的成分時，一個敏捷的項目管理過程要求項目團隊循環(huán)執(zhí)行規(guī)劃，執(zhí)行和評估過程。

敏捷與其他項目管理方法不同，后者通常認(rèn)為影響項目的因素是可預(yù)測的，因此它強調(diào)對變化情況的適應(yīng)性，項目團隊之間以及他們與客戶之間充分和持續(xù)的溝通。敏捷方法非常適用于動態(tài)環(huán)境，這些動態(tài)環(huán)境可能會發(fā)生變化或不斷變化的需求，例如軟件和游戲開發(fā)。

作為一套原則，敏捷是一個大的概念，并且傾向于被用作包括Scrum，極限編程（XP），看板和Scrumban在內(nèi)的敏捷風(fēng)格的總稱。簡而言之，敏捷并不是一種可以直接使用的方法或流程，這讓事情變得混亂 – 如果您掌握了這些原則，您仍然需要定義交付項目的流程。

Scrum方法論 – 使一個小型，跨職能，自我管理的團隊能夠快速交付

Scrum是一種項目管理方法，提出了改進交付的原則和流程。在軟件開發(fā)中，Scrum是將敏捷原理應(yīng)用于實踐的最流行和最簡單的框架之一。

Scrum的目標(biāo)是改善溝通，團隊合作和發(fā)展速度。如果你聽到人們在談?wù)摏_刺，混亂，積壓和burndowns，他們可能在談?wù)揝crum或其衍生物。

Scrum并不是一個真正的項目管理方法論，而是一個持續(xù)開發(fā)和維護復(fù)雜產(chǎn)品的框架。Scrum是一種輕量級的方法，它定義了一組簡單的角色，會議和工具，以高效，迭代和遞增方式提供有價值的可交付功能。

從根本上講，Scrum的重點是讓自我管理團隊提供和定義角色和責(zé)任，以便在盡可能快地提供正確的方式和正確的方式之間創(chuàng)造健康的緊張關(guān)系。

Scrum倡導(dǎo)使用一個由多達(dá)9人組成的小型跨職能團隊來處理待處理項目 – 一組用戶故事（需求） – 由產(chǎn)品負(fù)責(zé)人定義并確定優(yōu)先級。

工作被分為一個個“sprints”，一個通常為2-4周的開發(fā)周期，在此期間，每天的“scrum”發(fā)生在團隊報告進展和障礙的地方。在每個sprint結(jié)束時，工作將在Sprint評審會議上進行審核，以便與產(chǎn)品負(fù)責(zé)人一起確定是否通過完成定義（DoD）。

Scrum由Scrum Master提供支持和服務(wù)，Scrum Master支持并領(lǐng)導(dǎo)Scrum，Sprint演示和評論，領(lǐng)導(dǎo)開發(fā)團隊完成他們的最佳工作，并在每個sprint之后領(lǐng)先進行“sprint回顧”，以確保團隊持續(xù)優(yōu)化和改進。

Scrum最初是為軟件開發(fā)而設(shè)計的，盡管Scrum可以提供靈活的構(gòu)件，但Scrum并不適合整合到通常更具戰(zhàn)略性和創(chuàng)造性的外包開發(fā)領(lǐng)域。即使在一個網(wǎng)站的開發(fā)項目上，固定的預(yù)算，時間表和范圍也會讓一個Scrum自我管理團隊缺乏靈活性，而這個項目的開始和結(jié)束都是定義好的。

這并不是說它不適用于開發(fā)項目 – 外包開發(fā)項目經(jīng)理可以扮演scrum的主人，而客戶則可以作為一個大型快樂混合團隊的產(chǎn)品所有者。但它通常比這更復(fù)雜，固定的預(yù)算和范圍提供了嚴(yán)重的限制。這就是為什么許多機構(gòu)采用scrum的一些概念 – 小型，自組織，跨職能團隊，日常站立，進度演示和回顧，并以某種混合方式使用它們。

看板方法論 – 通過提高工作進展的可視性并限制多任務(wù)，提高交付速度和質(zhì)量

看板是一種專注于精益原則和提高效率的嚴(yán)格流程的項目管理方法論。它在很多方面與Scrum類似 – 它們都是盡早發(fā)布，并經(jīng)常與合作和自我管理團隊合作。但與Scrum相比，看板是一種更具進化性的變化，因為它不太具有說服力，所以它更輕松地登陸敏捷世界。

看板流程簡單，靈活，沒有規(guī)定的角色，只是試圖通過增加團隊對真正重要的事情的關(guān)注來提高吞吐量。核心實踐是對工作流進行可視化，限制正在進行的工作，衡量交付周期，明確制定工藝策略并不斷評估改進機會。

看板的重點是不斷發(fā)布的工作，速度更快，質(zhì)量更好。對于優(yōu)先級經(jīng)常變化的運行或維護環(huán)境而言，這非常棒。看板的重點是測量提前期 – 在收到簡報后需要多長時間才能交付。

通過看板，項目經(jīng)理通常在Kanban白板或Trello等在線工具上使用便箋來表示團隊的工作流程，其分類很簡單，如“待辦事項”，“正在做”和“已完成”。

這可以顯示您想要執(zhí)行的操作并限制正在進行的工作（WIP），以便在您測量和優(yōu)化完成項目的平均時間時改進工作流程。

它還使團隊可以直觀地看到接下來會發(fā)生什么，這可以輕松重新排列優(yōu)先順序，發(fā)現(xiàn)過程問題并防止任務(wù)停滯。這也有助于他們了解新任務(wù)如何影響正在進行的工作。

看板非常適合需要穩(wěn)定生產(chǎn)的工作，如生產(chǎn)或支持和維護。在機構(gòu)的世界里，它也可以成為一個有用的工具，因為它更適應(yīng)變化，客戶也喜歡不斷地改變主意。如果Scrum看起來太僵化了，但你想做'敏捷'，看板是一個更簡單的選擇。

Scrumban方法論 – 像看板一樣每天都像Scrum一樣限制工作進展

Scrumban是一種相對較新的混合項目管理方法，將混合Scrum和看板方法結(jié)合到項目管理中。它需要看板的靈活性，并增加了一些Scrum結(jié)構(gòu)來創(chuàng)建管理項目的新方法。

Scrumban并沒有在潛在的限制性時間框沖刺中工作，而是使用按需計劃原則來填補積壓工作，而任務(wù)由團隊負(fù)責(zé)分配任務(wù)，因為他們可以適應(yīng)這些任務(wù)，就像看板一樣。這意味著進行中的工作是有限的，開發(fā)團隊仍然專注于手頭的任務(wù)，而不是擔(dān)心沖刺審查會議和團隊承諾在沖刺中提供什么。

然而，并非所有的看板 – Scrumban保留每日Scrum與審查和回顧，以改善只在需要時使用的過程。此外，沒有沖刺的限制，計劃是在需要的基礎(chǔ)上進行，而不是在沖刺周圍進行 – 這可能會節(jié)省時間。

Scrumban真的只是通過消除沖刺和允許自適應(yīng)方法來為Scrum添加一些靈活性。或者，您可以將其看作是為Kanban添加一些急需的結(jié)構(gòu)，通過會議來協(xié)助和優(yōu)化流程。

對于產(chǎn)品開發(fā)而言，Scrumban可能非常有用，因為前景不清晰，需求不斷發(fā)展或沒有明確的路線圖，以及流程是否需要在流程中包含支持和維護工作。

精益方法 – 精簡和消除浪費，以更少的資源交付更多

精益是一種專注于效率主題的項目管理方法論。可以說敏捷教父 – 精益就是用更少的錢做更多的事情。它通過識別價值開始，然后通過持續(xù)改善，通過優(yōu)化價值流動和消除浪費來最大化價值。

這是一個有原則的主題，而不是一個方法論的決定過程和事情。它表明，通過解決導(dǎo)致浪費的三種功能障礙，您可以少花錢多辦事; Muda，Mura和Muri，也被稱為3Ms。

• Muda正在消除廢物處理過程或任何最終不會增加客戶價值的事情。在數(shù)字世界中，這可能會消除幾輪修訂。
• Mura正在消除變化 – 消除標(biāo)準(zhǔn)流程造成的差異。對我們來說，這可能意味著標(biāo)準(zhǔn)化簡報和審批流程。
• 穆里關(guān)于消除超載 – 最佳容量在60-70％; 除此之外，任何事情都會變慢。我們可以將此應(yīng)用于最小化我們試圖通過代理機構(gòu)運行的項目數(shù)量。

精益專注于改變我們的經(jīng)營方式，以激光為中心實現(xiàn)價值。它將關(guān)注點從優(yōu)化獨立技術(shù)，資產(chǎn)和垂直部門轉(zhuǎn)向優(yōu)化通過整個價值流的流量項目，這些價值流橫跨技術(shù)，資產(chǎn)和部門橫向流向客戶。

在審查項目交付過程時，精益可以成為一種有益的思維方式 – 思考如何將項目過程剝離回僅僅提供價值的切合實際的要素，并且刪除那些只是松散的事情，或者你總是完成的方式它 – 你會想到精益。

XP – 極限編程方法 – 堅定地進行開發(fā)以確保質(zhì)量

極限編程（XP）是一種軟件開發(fā)項目管理方法，它定義值和流程以提高軟件質(zhì)量并確保對不斷變化的客戶需求的響應(yīng)。的值，或原理非常類似于Scrum的，圍繞簡單起見，通信，反饋，尊重和勇氣。

它真正背離Scrum的地方在于定義規(guī)則或規(guī)范流程。其中一些類似于Scrum，但是圍繞設(shè)計編碼和測試的技術(shù)實踐有規(guī)則，這些規(guī)則使得它成為開發(fā)項目的特定對象。這些規(guī)則包括強制性的; 包括用戶故事，測試驅(qū)動開發(fā)（TDD），結(jié)對編程以及其他許多方面的持續(xù)集成。

瀑布方法 – 充分規(guī)劃項目，然后分階段執(zhí)行

通常被稱為SDLC（軟件開發(fā)生命周期）的瀑布是一個項目管理方法學(xué)主題，它具有非常簡單的方法，它重視可靠的規(guī)劃，一次做好并且做得對，而不是增量和迭代交付的敏捷方法。這很容易理解，因為你只需制定一個好的計劃，然后執(zhí)行就可以了。

項目經(jīng)理往往比較龐大而且負(fù)責(zé)，而且工作是事先進行廣泛的規(guī)劃，然后按照嚴(yán)格的順序執(zhí)行，遵守要求，以一個單一且通常很長的周期交付項目。

任何工作開始前，需求都會在瀑布頂部的開始處全部定義。然后工作級聯(lián)，如通過項目階段的瀑布瀑布。在瀑布模型中，每個階段必須在下一個階段開始之前完成，并且階段中沒有重疊。通常，在瀑布方法中，一個階段的結(jié)果將作為下一個階段的輸入順序。

在計劃獲得批準(zhǔn)后，除非絕對必要，否則幾乎沒有必要調(diào)整計劃，而且所需的更改通常需要更改請求。然后該項目從需求流程開始，直到設(shè)計，實施，測試和維護。

由于采用單循環(huán)方法，因此在瀑布項目中，一旦完成某項工作，就沒有多少空間可以反思，修改和適應(yīng)。一旦你進入測試階段，很難回頭去改變在概念階段沒有很好設(shè)計的東西。當(dāng)你走的時候，也沒有什么可以顯示并告訴客戶的。你大肆宣傳完成該項目，并祈禱客戶喜歡它。這可能是非常危險的。

一般認(rèn)為，瀑布在一些機構(gòu)中被視為一種效率低下且過時的傳統(tǒng)項目管理方法。但是，如果需求是固定的，有據(jù)可查的和清晰的，技術(shù)被理解和成熟，項目很短，并且沒有從“敏捷”中獲得額外價值，瀑布可以成為一種有用且可預(yù)測的方法。瀑布方法實際上可以為預(yù)算，時間表和范圍提供更可預(yù)測的最終結(jié)果。

PRINCE2方法論控制的項目管理，沒有任何機會

PRINCE2是一個'完整的'瀑布式項目管理方法論，包含原則，主題和流程。它是由英國政府于1996年為IT項目創(chuàng)建的。'PRINCE'表示PR ojects IN ? ontrolled ê nvironments。它是一種非常面向過程的方法，將項目分為多個階段，每個階段都有自己的計劃和流程。該方法為項目的每個階段定義投入和產(chǎn)出，以便不會有任何機會。

該系統(tǒng)強調(diào)企業(yè)采取的課程理由，因此第一步就是確定項目的明確需求，目標(biāo)客戶是誰，是否有現(xiàn)實利益以及徹底的成本評估。項目委員會擁有該項目并對其成功負(fù)責(zé)。該董事會為團隊定義了結(jié)構(gòu)，而項目經(jīng)理負(fù)責(zé)監(jiān)督較低級別的日常活動。該方法基于八個高層流程，為團隊提供更多的資源控制和有效降低風(fēng)險的能力。

作為一種方法論，它非常全面 – 它是如何運行大型可預(yù)測的企業(yè)項目的一個很好的框架。它闡明了將會交付什么，確保關(guān)注項目的可行性，明確界定角色和責(zé)任，通過例外（可以說是敏捷原則）支持管理，與PMBOK類似，提供了一個我們可以應(yīng)用于其他方法的通用詞匯。另一方面，雖然原則和主題很好，但這個過程可能會使小項目變得繁重和繁瑣。

PRINCE2專為大型IT項目而設(shè)計，因此絕不會在某個機構(gòu)中用作項目管理方法。但是，當(dāng)我們考慮為客戶管理項目時，強調(diào)利用KPI和價值創(chuàng)造良好的商業(yè)案例，明確角色和職責(zé)，管理變更和風(fēng)險很有幫助。

PMI的PMBOK方法 – 將通用標(biāo)準(zhǔn)應(yīng)用于瀑布項目管理

PMI（項目管理協(xié)會）項目管理方法論并不是一種真正的方法學(xué)，而是一套參照項目管理的五個流程步驟的標(biāo)準(zhǔn)，它們概述了項目管理知識體系（PMBOK）。這些是啟動，計劃，執(zhí)行，控制和關(guān)閉。

這不僅僅是一種方法論，而是一種在項目管理行業(yè)內(nèi)被接受為標(biāo)準(zhǔn)的標(biāo)準(zhǔn)，慣例，流程，最佳實踐，術(shù)語和指導(dǎo)方針的框架。它包含許多項目管理過程和技術(shù)，通過它們來評估或完成項目運行方式或使用的方法。

因此，這是一個更理論化的參考指南，您可以通過認(rèn)證，雖然它在IT方面很受歡迎，但并不真正在機構(gòu)世界中飛翔。您實際上無法運行PMI或PMBOK項目，但您可以利用這些標(biāo)準(zhǔn)在項目周圍創(chuàng)建通用語言和最佳做法。與PRINCE2相比，你可以想象PMI的PMBOK和PRINCE2是互補的，而不是兩種不同或獨立的瀑布方法。

如何選擇正確的項目管理方法

選擇正確的項目管理方法很重要，因為它定義了我們的工作方式。項目管理方法論提供了可以指導(dǎo)我們實現(xiàn)項目成敗的結(jié)構(gòu)。

因此，在決定在項目中使用哪種項目管理方法時，我們需要考慮項目的簡單性或復(fù)雜性，客戶，可用資源和項目限制（包括對變更和風(fēng)險的偏好），時間表，工具和人。

在涉及項目管理方法時，沒有適用于所有業(yè)務(wù)類型，規(guī)模或行業(yè)的萬能解決方案。無論您是在一個充滿變化和變化的動態(tài)環(huán)境中工作，而是采用靈活的方法。或者，如果您在非常固定，嚴(yán)格的要求，時間表和預(yù)算內(nèi)工作，并采用瀑布式方法，那么每種項目管理方法都有其自身的優(yōu)勢和弱點。

最終，所選擇的方法應(yīng)該基于其為客戶提供最大價值的能力進行分析，對交付方案的影響最小，滿足組織目標(biāo)和價值的程度如何，項目團隊必須處理的限制，利益相關(guān)者的需求，涉及的風(fēng)險，項目規(guī)模，成本以及項目的復(fù)雜性。

外包開發(fā)團隊最好的方法是什么？

簡而言之，沒有對錯 – 這取決于你的客戶，你的團隊和項目。

也就是說，在一個團隊中，幾乎普遍地建議瀑布對于一個項目來說可能是一個好方法，這無異于為自己畫一個大目標(biāo)。瀑布是沒有客戶或團隊想要聽到的東西 – 我們都希望被視為最前沿，而瀑布絕對不是很酷。

這不僅不是很酷，但瀑布是具有挑戰(zhàn)性的，因為它在任何創(chuàng)造價值的工作完成之前需要大量的前期規(guī)劃。有時需要規(guī)劃，因為客戶需要批準(zhǔn)成本，時間表和范圍。但是客戶通常不愿意為計劃付費，即使他們這樣做，如果您的計劃不符合要求，會發(fā)生什么？

事實上，在IT世界中，我們經(jīng)常會遇到要做出準(zhǔn)確的預(yù)估。我們通常在不是太明確的項目中使用新技術(shù)。因此，除非您一次又一次地做同樣類型的項目，否則一旦開始項目，您的計劃可能就會過時。因此，雖然客戶喜歡可交付成果，預(yù)算和時間表的可預(yù)測性，但瀑布式方法本質(zhì)上不靈活。

那么敏捷的味道呢？

在代理和客戶之間，對敏捷的理解往往非常流暢。敏捷在很大程度上被稱為'不是瀑布'，而且被廣泛誤解為意味著以更少，更快，更便宜的方式做更多的事情。你為什么不想要那個？

客戶傾向于喜歡敏捷的想法，因為它明顯具有靈活性來支持項目，并為他們提供更多的機會來提供反饋或在整個項目中持續(xù)改變他們的想法。

他們經(jīng)常認(rèn)為這意味著他們會以更少的工作量完成更多的工作，或者他們實際上不需要對任何事情做出最終決定，因為他們可以改變自己的想法，甚至到最后一刻。

這是真的，但不是真的整個故事。

故事的其他部分是這種靈活性是昂貴的 – 是的，你可以樞軸轉(zhuǎn)動，改變主意，但它耗費時間，而且時間花錢。

另一個挑戰(zhàn)是，為了成功并且真正敏捷，客戶必須使自己能夠獲得并被授權(quán)作出決策（這在分級和董事會導(dǎo)向的組織中是罕見的），并且提供持續(xù)的反饋和優(yōu)先級以便保留項目移動。這通常非常棘手。

在很多方面，這歸結(jié)為信任。客戶是否真的相信該機構(gòu)能夠提供價值，他們是否愿意為成功之路付出失敗的代價？從根本上說，機構(gòu)想要為他們所從事的工作獲得報酬，并且客戶希望機構(gòu)能夠第一時間完成他們的最佳工作。需要有一些快樂的媒介。

少花錢多辦事，消除浪費是一種很好的精益原則，但這種方法面臨的挑戰(zhàn)往往是客戶 – 外包方關(guān)系; 大量的浪費是由客戶引起的，沒有真正的嵌入式客戶端，具有真正的決策權(quán)力和大量的相互信任，沒有任何一種敏捷項目方法能夠解決這個問題。

但是，如果有相互信任，并且愿意嘗試，它可以創(chuàng)造出魔術(shù)發(fā)生的正確條件。事實是，敏捷可能會更好，但敏捷并不便宜或容易。

所以敏捷可能意味著應(yīng)用從Scrum到XP的各種不同方法 – 最好的方法是挑選最適合您和您的團隊的產(chǎn)品，以實現(xiàn)最大的價值。

它要求我們的客戶成熟起來，明白我們不能確切地定義他們會得到什么，或者什么時候，但有了一些健康的信任，我們將一起努力，盡我們所能。

結(jié)論是

選擇最合適的項目管理方法可能會很棘手。這取決于很多變數(shù)，其中許多變數(shù)是我們無法控制的。

但這是真正重要的 – 超越了這個領(lǐng)域方法論的“搶地盤游戲”。項目管理方法只是幫助我們交付項目的工具。對于方法論的最終細(xì)節(jié)來說，真的不值得爭論 – 相反，我們應(yīng)該把重點放在更大的局面上。無論是看板，瀑布還是其他方法，它都無關(guān)緊要。

重要的是要做好質(zhì)量工作，滿足用戶需求，為我們的客戶創(chuàng)造價值。

最好的方法是持續(xù)有機地改進，適應(yīng)并通過強大的協(xié)作增加產(chǎn)出的價值，因此總和遠(yuǎn)大于部分。

這是一種讓客戶感到驚喜和愉悅的方法，通過持續(xù)不斷交付有價值和正確的產(chǎn)品。要做到這一點，你需要務(wù)實，而不是機械教條地使用你的方法。

來源：轉(zhuǎn)載

關(guān)注公眾號：PMP項目管理之家、才聚項目管理PMP暨NPDP考試中心