第一篇：關于華為敏捷項目管理

華為公司項目管理

關于華為敏捷項目管理

IPD – 集成產品開發(fā)，華為花重金從IBM購買的一套產品集成開發(fā)流程，業(yè)界有一本書，PACE講的就是這一套IPD流程，而IPD并不去講你的開發(fā)要怎么做，IPD做的就是“投資決策、市場驅動”，更多的是決定做不做這個事情，做這個事情對于投資人員是不是受控的，所以在IPD里面會有DCP點（決策評審點），每個點上都會去考慮該不該做、值不值得去做，在引入這個東西以前，華為實際上是技術驅動的，并不是市場驅動的，就是說以前華為聽說有個新技術，然后就開始做，做了很多這樣的東西，但是后來都賣不出去，所以后來就引入了IPD，以市場驅動。在引入IPD后，是解決了做什么的問題，但是怎么做，還是按照自己的想法去做，后來就引入了CMM，引入CMM后對華為確實起了非常大的作用，其產品開發(fā)的質量確實是比起前提高了，所以在前幾年，通過IPD+CMM使得華為走向了一個非常成熟的過程。在這個基礎之上，關于質量管理、項目管理華為提出一些自己的體系，比如從項目的開始到項目的結束，有項目review、度量分析、根因分析、缺陷預防等一系列活動，在項目管理方面有風險管理、問題跟蹤管理等活動，同時還會有質量審計以及相關的推動等事情，通過這些項目管理和質量保證使得IPD和CMM很正常的運作下去，但是現(xiàn)在行業(yè)已經發(fā)生了一些變化，比如需求變化快等方面華為也碰到了一些問題，以前產品質量是可控的，大多數(shù)產品的發(fā)布周期也是穩(wěn)定的，比如對客戶承諾什么時間提交產品基本上是有保證的，另外項目在管理層的進展也是非常清晰化的，你在向某某領導匯報的時候只用告訴他比方項目到了SRS階段了，基本上這個項目的老大就知道這個項目還有多少事情需要去做，比如告訴他到單元測試階段了，他就知道快搞定了，這樣確實使得這個進展能夠口頭化。其實，流程存在的價值，就是能夠給我們的管理層提供進展的可視化，所以從目前來看，對于客戶、員工、管理層這三個利益相關人來講確實達到了這樣一個目的。

但是現(xiàn)在行業(yè)中，需求變化太快，不管我們怎么努力去做，發(fā)現(xiàn)還是不能滿足客戶的需要，不管需求搞得多么細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟件，這是華為面臨的一個挑戰(zhàn)，如何解決這個問題？

軟件開發(fā)中有三個要素：人、過程、技術和工具。對于一個軟件項目成功來說，這三個要素都不可省，而在以前大家強調IPD和CMM，更多的是強調大家規(guī)范的把它運作起來，對于人、技術和工具基本上不提了，忽略了，所以后來就反饋出一個問題，就是很多項目，看起來那個過程做的那個漂亮，那個報告寫得那個完美，但是交出去的產品那個爛，其實這三個因素是缺一不可的，你必須得均勻的發(fā)展，還有一個是人的方面，因為人是具備創(chuàng)造能力的，所以從華為的教訓給我啟發(fā)，過度的關注過程而忽視人、忽視技術和工具，我們就得要思考和反省了。

針對這些問題，華為也就提出了敏捷。華為在99年之前基本上都是土生土長游擊隊的做法，到了2001年的時候就引入了IPD和CMM，到2006年的時候，就發(fā)現(xiàn)了瀑布模型的問題，如交付周期特別長，就是每做一個客戶的需求，然后一分析，這樣一走半年就過去了，所以就引入了RUP，最初的想法就是加速我們項目的交付周期，能夠快速的給客戶響應，但是敏捷實際上已經進入了一個低谷期，所以當時就引入了迭代，實施了一年之后也發(fā)現(xiàn)，RUP里面的東西實際上也是挺多的，所以后來就接觸了XP、SCRUM這些方法，這樣就從07年開始向敏捷這個方向在走。

有一個圖在業(yè)界流傳比較廣泛，也叫洋蔥圖，共分三圈，也就是從三個不同層面描述了敏捷開發(fā)方面的一些最佳實踐。XP為什么叫極限編程？如果你覺得這個軟件開發(fā)的實踐是一個好的實踐，那么你就把它發(fā)揮到極致。比如，結對編程，一個在編，一個人在看，實際上看的人不會白看，其實起到了一個review的作用，既然review這個作用有效，那么為什么不把這個作用發(fā)揮到極致，所以就采用了結對編程將review這個作用發(fā)揮到極致。在敏捷中有一個8個字的原則：溝通、反饋、交流、勇氣。它認為項目團隊中的成員這個溝通是比較重要的，既然你非常重要，那么我也要把你發(fā)揮到極致，所以兩個人一起在干活的時候就會不停的有交流與溝通，所以，結對編程是一個典型的把review、溝通交流發(fā)揮到極致的實踐。另外，TDD也可以認為是那剛好夠用的事情發(fā)揮到極致。我們以前傳統(tǒng)的軟件開發(fā)的做法是，先做好這個軟件，然后去測，看看是不是實現(xiàn)了這樣一個功能，但是我們總會發(fā)現(xiàn)這里面有很多代碼其實是從來就沒有用過的，只是在下代碼的時候順手就把它寫了，在分析那些產品的時候發(fā)現(xiàn)有的產品這樣的沒用到的代碼高達50%，而TDD的思想是，我既然要實現(xiàn)什么功能，然后我就先寫對應的用例來驗證它，然后在開發(fā)的時候就開始寫代碼，使得這個用例剛好通過，這樣就使得我們寫出來的代碼是剛好滿足這個系統(tǒng)的功能的代碼，這樣，前面出現(xiàn)的50%就可以不用做了，這就是把剛好夠用發(fā)揮到極致。其他的就不一一講了。XP在2001年到2003年之間非常的紅火，過了之后又相對的沉寂了一點，現(xiàn)在又冒出來一個新的敏捷的方法論，就是SCRUM。XP是過分的強調將軟件開發(fā)里面的實踐發(fā)揮到極致，而這些實踐都是同編程實踐相關，但是在管理方面就比較弱，所以，在用了幾年之后，大家發(fā)揮XP不是起到那么大的作用，所以就開始沉寂下來。這個時候就出現(xiàn)一個流派，就是SCRUM。SCRUM其實就是一個非常非常輕量的項目管理框架，基本上沒有什么編碼實踐方面的東西，你說看到的都是管理上的活動，這個管理上的活動很多人就會有一種似曾相識的感覺，記得前不久，同華為的一個項目團隊在聊，就談到這個項目的backlog，一講，項目團隊的人就說其實他就是那樣子做的，他以前也沒與聽說過什么SCRUM，就是把這些需求一條一條的列出來，鎳鎘優(yōu)先級，估個工作量，一看，就是這個東西。SCRUM的核心其實比較簡單，2分鐘就能講出來，就是3個3。

一、3個角色。Product Owner，負責決定產品要做什么，做成什么樣子；保證項目能夠遵循SCRUM的方式運作下來；項目團隊成員，包含開發(fā)、測試、質量等等所有的人。

二、3種會議。迭代的計劃會議、中間的站立式會議、迭代的評估會議，屬于三個管理的活動。

三、3個交付件。待開發(fā)的任務列表、待修復的缺陷任務列表、項目的進度圖。

SCRUM就是通過這3個3將項目非常簡潔的管理起來，有一個思考就是關于PMP里面講到的9大領域多少活動不一定對這種敏捷項目適用。那么大家可能提出一個疑問，就是項目的進度是不是就不可視了。其實，敏捷項目的進度可視很簡單，就是通過一個白板（進度墻、任務看板），將每個人的進度情況這么一貼，這就是最簡單最直接的管理方式，一看，所有人都知道，就算你去開發(fā)一些什么復雜的一些IT支撐系統(tǒng)，可能都起不到這個白板的作用。在華為關于敏捷的一些項目管理工具，用Scrumworks、Bingo這些管理工具也能夠把項目的進度管理起來，但是你要做的就是必須得把電腦打開，要把瀏覽器打開，這樣才能看到你的進度是什么樣子的，而在辦公區(qū)直接樹一個白板就能夠很簡單、很方便的知道我的這個進度情況。所以，在華為，對于敏捷項目，管理的框架上是采用的SCRUM，指導如何編碼實現(xiàn)上就采用了一些XP的實踐，當然XP的實踐不會全部去選，會根據(jù)項目的實際情況

去選一些實踐，如果你把所有實踐都選的話，實際上的效果是非常差的。那么如何來選擇就得根據(jù)項目的實際情況去評價。華為在實踐的過程中也引入了精益、消除浪費的思想。比如，在平時的工作中存在停工等活的浪費。什么是停工等活的浪費呢？比如我們開發(fā)在做開發(fā)的時候，我們的測試就會輕松一點，那么測試在做測試的時候我們的開發(fā)就會輕松一點，大家覺得這樣也挺好的，但是你從整個組織角度去分析，實際上是停工等活的，開發(fā)時測試在等著，測試時開發(fā)在等著，如果你從精益的角度考慮的話，為何不通過迭代的方式把開發(fā)和測試等待的時候整合在一起來工作，使得效益得到提升。有很多項目團隊自己去做了，確實效果比較明顯。其實在2006年實踐RUP的時候就感覺到這樣的好處了是非常明顯的。引入敏捷之后，自然而然的就會想到同公司已有流程之間的關系，原來是IPD+CMM，所以就有同事問到是不是我這個就不用了。分析可以知道，IPD是決定做不做，決定之后如何去做就可以采用敏捷開發(fā)，所以對于敏捷產品的流程就是IPD+敏捷的方式，所以有很多以前采用瀑布型的團隊逐步的被敏捷代替了，還有些團隊正在代替中，還有些團隊就覺得原來那套玩得很流暢就繼續(xù)采用原來的方式。所以目前在華為，項目團隊是可以自己來選擇采用哪種方式進行，現(xiàn)在可以發(fā)現(xiàn)，那些愿意選擇敏捷方式走的往往就是原來那些頑固不化的爛項目，因為以前在推流程的時候，那幫人整天在那里叫，有問題，我不干，我不愿意做，實際上，后來做深入分析發(fā)現(xiàn)，他的那種模式并不適合按照瀑布型去做，但現(xiàn)在成了積極分子，所以每個項目的模式是不一樣的。

在做敏捷的時候也存在一些容易做的事情和不容易做的事情。比如說SCRUM的項目管理是比較容易去實踐的，就是3個3，對于那些想敏捷的，我建議可以先做這個，還有也會做一些結對編程、持續(xù)集成的實踐。比較難的，有這么幾點。華為從99年開始都是按照開發(fā)、測試等團隊去運作的，團隊與團隊之間就會形成部門的墻（華為有一個外籍員工給起了一個名字叫Chinese Wall），對每個部門來說，希望把這個墻樹高一點，這樣能獲取更多的資源非常順利的開展工作，所以墻就會越樹越高，很多部門甚至還有checklist，你只要給我什么東西，我就按照checklist打勾，打勾不通過的就要干啥干啥，這樣通過約束管理層，罰款的制度就來了，而這個問題就很難搞，涉及到很多很多的人員，涉及到部門角色定位的問題，這是華為覺得最難的一點。第二難的問題就是TDD，在很多項目都試過，但是試過之后，很多項目都無疾而終，或者訴苦說這個我實在搞不下去，分析后發(fā)現(xiàn)，是涉及人做事情方法的改變，這個挺難的，以前寫代碼都是邊想編寫，就能寫出來，現(xiàn)在你就得先想好、驗證好等等，然后再想辦法填進去，就發(fā)現(xiàn)這個很難，這是一個開發(fā)習慣的改變，這也是很難的一件事情。第三個，就是Customer Tester，就是要客戶參與驗證，可能對于互聯(lián)網企業(yè)可以部署一個系統(tǒng)，用戶參與測試就可以做起來了，但是對于華為而言，客戶是電信企業(yè)，而電信是買方，買了之后再供他們的客戶去用，這個里面客戶就存在好幾層，所以要客戶真的參與進來還是比較難的。第四點，也是很難的，我們有一個團隊，要到各個團隊去宣傳為什么做敏捷，這涉及到觀念的轉變，所以這也是非常難的事情。（一夜的引入，長時間的改變。）比如你說你這個團隊敏捷了，明天就開始站立式會議，但是你最后會發(fā)現(xiàn)，要真正敏捷實際上是一個漫長的過程。

在華為實施敏捷的過程中，也有一些經驗性的東西。第一個是QA從警察的角色轉變到一個教練的角色。在以前，團隊實施CMM的時候，QA更多的是一個警察的角色，他整天拿著一個checklist、報告什么的到處去團隊里面看，你是否ok，不ok就要怎么怎么樣，整天就干這個活，但是引入敏捷之后，QA就覺得有點失落，都敏捷了，我都不知道該怎么下手了，然后，在華為，就把QA轉變了一下，將QA更多的充當教練的角色，充當?shù)慕巧?，他去指導項目團隊該如何去開這個站立式會議，該怎么去做迭代的計劃等等指導性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，這樣他見得也多，所以在敏捷的實踐里面是需要這么一些人來干這么一些事情。第二個就是要營造一個一體化的團隊，也就是將所有有墻的部門通通打掉，直接按照項目型運作，把大家拉到一起，不要考慮你原來是什么部門，先把項目做出來再說，這就是在XP的外圈中的Whole Team實踐，因為大家就真正是一條船上的。在很對項目中，總是存在這樣的一些人，項目成功不成功對他們是無關緊要的，但是有些人項目不成功對他們是非常重要的，而真正的敏捷項目就要這些人來掛帥，并且這些人是站在一條戰(zhàn)線上的，所以就叫拉到一體化的團隊里面來，大家都對交付負責。第三個就是辦公環(huán)境最好也能夠隨著改變。以前大家都是那種小格間的方式，但是這種方式是非常不利于做交流和做項目的。第四個就是現(xiàn)身說法。前面講到有很多這樣的人會到團隊中去說敏捷怎么怎么好，但是如果你讓一些對項目成功不成功都不相關的人去講是沒用的，因為大家一聽，首先就會質疑50%，所以華為當初經常搞的活動就是讓項目經理他們在講，將他們當時是怎么開展敏捷的，這樣別人一聽才能理解到原來你是這么這么做的。

第二篇：淺談敏捷項目管理和PMP

淺談敏捷項目管理和PMP

敏捷項目管理方法一般適用于中小型研發(fā)項目，追求項目管理態(tài)度，方式上的“敏捷”，推崇“以構架為中心、用例驅動、迭代開發(fā)”，從而達到快速交付的目的。PMBOK的理念是項目應該具備完備的可持續(xù)改進的項目計劃，并時時強調項目管理計劃的更新持續(xù)于項目整個生命期。項目管理者聯(lián)盟

敏捷項目管理聲稱要擺脫繁冗的流程制度文檔，但是對于關鍵的項目文檔，比如需求規(guī)格說明書等，也是要求必須具備的。所以，敏捷項目管理在項目流程制度上的管理可以看作是對一套完善的項目管理流程制度的裁剪，只不過這個裁剪的尺度較大，從而也對敏捷項目團隊成員的適應性，自主性提出了較高的要求。項目管理者聯(lián)盟

具體的敏捷方法(以SCRUM為例)在每個迭代周期中都存在立會制度，燃盡圖、看板監(jiān)控，計劃發(fā)布等，這些和PMBOK中對項目生命期的五個過程組啟動，規(guī)劃，執(zhí)行，監(jiān)控和收尾的定義沒有沖突矛盾。實際上，敏捷項目管理的這些措施可以看作是PMBOK項目生命期五個過程組執(zhí)行的微縮版，區(qū)別在于，敏捷項目管理的迭代周期時間很短，在其執(zhí)行過程中，裁剪了許多規(guī)范正式的項目管理流程制度。項目管理者聯(lián)盟

敏捷項目管理方法在IT研發(fā)領域取得了一定的成效，但是這種項目管理方法對項目團隊的整體素質提出了較高的要求。同時，對項目管理者的團隊建設水平也提出了較高的要求。敏捷項目管理追求的“敏捷”，雖然貌似在項目管理流程制度等項目管理建設金字塔的底層“硬件”部分要求不高，但是對項目管理軟技巧這些例如團隊建設，溝通協(xié)調，領導力，激勵等項目管理建設金字塔的高層“軟件”部分，提出了更高的要求。項目管理者聯(lián)盟

個人認為，一個項目管理者如果具備卓越的項目管理能力，那么他首先應該精通項目管理建設金字塔的底層建設，只有系統(tǒng)掌握了項目管理體系理論，結合工作經驗，項目管理者才能逐漸凝練出自己對于軟技巧的總結，從而進行更符合實際情況的應用，才能做到有的放矢。沒有系統(tǒng)知識體系的積累奠基，所謂的軟技巧就如無本之木，無源之水。因此，作為敏捷項目的項目管理者，學習掌握專業(yè)的項目管理知識體系也是十分必要的。

第三篇：Scrum Agile敏捷項目管理歸納總結

D:iknowdocsharedatacur_work80505777.docx 《Scrum/Agile敏捷項目管理》歸納總結

前言

此文檔是由我閱讀《Scrum敏捷項目管理》Ken Schwaber著，清華大學出版社。歸納總結Agile項目管理的核心內容。

核心精髓

? 20/80法則

20%交付功能代表80%的最終商業(yè)價值。

? 敏捷團隊組成

Scrum Master，產品負責人，團隊。

? Sprint計劃會議

此會議限時8個小時。分兩部分，各4小時。第一部分挑選Backlog，第二部分準備Sprint Backlog 與會者包括ScrumMaster、產品負責人和團隊?？裳埰渌藛T補充業(yè)務或技術領域的信息和建議，在信息提供完畢后離開。雞類人員不可擔任觀察者。

產品負責人應在會議前準備好產品Backlog.如果缺少產品負責人或產品Backlog的情況下，ScrumMaster需要代理些職。第一部分會議

會議第一部分（前4個小時）團隊的目標是挑選將承諾轉化為潛在可交付產品功能增量的產品Backlog條目。團隊將在Sprint結束時的評審會議上，向產品負責人和利益相關者展示該功能。團隊可提建議，但由產品負責人制定Sprint產品Backlog。

團隊負責從產品負責人制定的Backlog中挑選出期望在當前Sprint內完成工作。第一部分會議結束后立即召開第二部分Sprint計劃會。限時4小時。第二部分會議

產品負責人必須出席，回答團隊對產品Backlog可能的疑問。

團隊必須獨立決定如何將選定的產品Backlog轉化為潛在可交付的產品功能增量，該過程中團隊不接受外界指導。

第二部會議將制定出”Sprint Backlog”。是一張包括任務、任務預估及開發(fā)功能的工作分配清單。任務清單不一定完整，但必須反映團隊全體成員的共同承諾，以順利完成Sprint第一部分，在過程中團隊可以為Sprint Backlog增加其他任務。

/ 2

D:iknowdocsharedatacur_work80505777.docx ? 每日Scrum簡會

不論團隊人數(shù)多少，每日Scrum簡會限時15分鐘。

在每個工作日的同一時間，同一地點召開每日Scrum簡會。它是全天工作中的第一件事。

團隊全體成員必須出席。如某位成員無法出席，則應參加電話會議或請其他成員代為報告工作情況。團隊成員必須準時。不論出席情況如何，Scrum必須在指定時間開始會議。SrcumMaster請他（她）左邊第一位成員開始匯報情況。團隊每位成員僅回答3個問題。

1，自上次Scrum簡會后的1天里你為該項目做了什么？

2，從現(xiàn)在到下次Scrum簡會后的1天里你準備為項目做什么？

3，什么妨礙你盡可能高效的工作。

會議圍繞上述3個問題展開，成員不得離題講其它事宜、設計、討論問題或閑談。ScrumMaster確保成員輪流且干脆利落地匯報工作。

每日Scrum簡會不得有人同時發(fā)言。發(fā)言人匯報工作情況，其它與會者是聽眾，不可在一旁私下談話。與某位成員匯報的情況涉及其他成員興趣或需要他們協(xié)助時，可在每日Scrum簡會后立即召集有關人員開會。

雞類人員不得講話、評論等。并站在團隊外圍，以免干擾會議。若雞類人員出席人員過多，ScrumMaster有權限制出席人數(shù)。確保會議有序、集中。雞類人員不得在會后請團隊成員深入解或向團隊提供建議和指示。

不能遵守上述規(guī)定的豬類或雞類人員將被禁止雞類參加會議或把豬類開除出團隊。

/ 2

第四篇：(講座1)智慧的敏捷項目團隊管理

報告題目：智慧的敏捷項目團隊管理 報告人：DJ Ning

IBM Rational 中國區(qū)技術總監(jiān)

講座時間：2011年1月22日晚上（周六）5：30-8:45 講座地點：交大徐匯校區(qū)工程館212教室

一、大會主要內容

1月22日大會上，DJ Ning主要講述了什么是敏捷方法、敏捷方法的提出、敏捷建模、敏捷開發(fā)的生命周期等內容。敏捷方法（XP、SCRUM、Feature－Driven Development、Crystal、DSDM、Agile Unified Process、Adaptive）是一個靈活的開發(fā)方法，用于在一個動態(tài)的環(huán)境中向干系人快速交付價值，努力在軟件開發(fā)過程當中減少變化帶來的成本。個人和交互代替原有的流程和工具，可運行的軟件代替原有的復雜文檔，與客戶的協(xié)作代替基于合同按部就班的操作，快速響應變更代替原有的遵循計劃。例如，XP使用快速迭代計劃和開發(fā)循環(huán)盡早地產生最有價值的特性。另外，XP中的持續(xù)的、系統(tǒng)化的測試確保高質量，盡早發(fā)現(xiàn)缺陷和相應的解決方案。

二、聽后感

現(xiàn)在，在IT預算被大幅度地削減的情況下，我們的IT管理人員的壓力仍然在不斷增大。同時，業(yè)務環(huán)境正以非常高的速度持續(xù)改變，這使IT艱苦奮斗，以便能夠跟上這種變化速度。這些變化導致了以“快速發(fā)布和靈活而又高質量的維護為承諾”的敏捷軟件開發(fā)方法論產生了很大的興趣。

軟件的項目管理目前面臨諸多挑戰(zhàn)，軟件項目開發(fā)的進度難于預測，需求在不斷變化，而且速度快，變化的范圍同時也難于控制，團隊協(xié)作不夠，配置和變更管理不當?shù)榷荚斐晌覀冊浻行╉椖繜o法完成。

我認為，加強管理才是敏捷方法被成功采納并應用的關鍵，然而傳統(tǒng)項目管理方法學和工具卻與這些新的敏捷方法缺少關聯(lián)。而這種低關聯(lián)性就是深層次問題的癥狀。這些深層次問題表現(xiàn)在：對于處理變化、控制、命令、組織、人員以及解決方案等方面的基本假設方面的不同。

結合日常的工作，采用敏捷開發(fā)可以更早地持續(xù)地交付有價值的軟件，可以滿足我們的需求，即使到了開發(fā)的后期，也能夠適應變更；頻繁交付可工作的軟件，而可工作的軟件是度量進度的主要標準；我們的業(yè)務人員和開發(fā)人員必須每天協(xié)同工作；圍繞著激勵起來的個人來構建項目；面對面的交談是最有效和效率最高的溝通方法；提倡可持續(xù)的開發(fā)速度；持續(xù)的優(yōu)化技術和設計；簡單是工作效率最大化的藝術；最好的架構、需求和設計，出自自組織團隊；定期總結回顧，思考我們的團隊如何更加高效，并作出相應調整。

一個好的團隊是項目是否成功實施的基礎。高效的團隊所具備的基本要素應該有：承諾使用統(tǒng)一方法，互相依賴、互相負責；少數(shù)成員要注重實效，容易分享和溝通，打造共同的團隊價值觀；技能互補，解決問題和決策，并且注重人際關系技巧；承諾為共同的目標而奮斗。

在敏捷項目中，我們的客戶需求在整個生命周期中是不斷變化的；我們單位在過去傳統(tǒng)項目中，客戶需求在一開始是被完整定義的和靜態(tài)的，明確了高層次的需求，并進行優(yōu)先級劃分，往往時間是影響緊急業(yè)務需求交付的關鍵約束，資源又是固定的，并被有效管理以在指定成本內交付。項目交付周期從傳統(tǒng)的瀑布模型轉變?yōu)榈降拿艚蓓椖可芷?，即將長的、復雜的項目周期變?yōu)槎痰?、簡單的迭代周期；明確項目的完成時間往往又不是一個時間點，而是一種可能性的分布。這樣使用里程碑交付件作為一種有效的評測軟件；提出合適的項目計劃；盡早反饋和經常反饋；迭代地、增量地交付可工作的交付件。

第五篇：華為管理

任職資格管理被任正非視為華為過去十年的三大成功變革之一，對華為成功邁入全球市場居功至偉，其兩大特點就是“管好大腦，看好手腳”，是一種適合中國國情的、企業(yè)高速成長過程中的人才解決方案；這也標志著華為人力資源管理模式已從績效考核過渡到了任職資格管理．．．．．．

華為公司任職資格管理解密

——管好大腦，看好手腳

德為咨詢：豆世紅 謝安

本文摘要：

1.知識經濟下，對人的管理是21世紀管理的中心

2.華為人力資源管理模式已從績效考核過渡到了任職資格管理

3.德為咨詢歸納出任職資格管理的兩大使命：管好大腦，看好手腳

4.任職資格管理被任正非視為華為過去十年的三大成功變革之一

一、要管“事”，更要管“人”

在員工的管理方面，我們發(fā)現(xiàn)，國內企業(yè)往往過于關注對“事”的管理，卻忽視對“人”的管理，導致管理失衡，矯枉過正，效果不佳。

經過多年的管理實踐和管理變革，國內的不少企業(yè)已經引進了或者正在引進西方較為成熟的一些管 理方法和手段，例如基于職位評估的薪酬管理，基于關鍵績效指標（KPI）的績效管理以及與之掛鉤的激勵手段如項目獎、提成獎等，這些管理手段已經被證明在 過去的相當長的時間內是發(fā)揮了較大的效用的，因此得到了廣泛的應用，但是也有其不足，即上述管理手段主要基于職位，或基于事件（如KPI），實際上是偏重 對“事”的管理方式，而知識經濟條件下，對人的管理將成為管理的中心（德魯克《21世紀的管理挑戰(zhàn)》），因此國內企業(yè)在進入21世紀以來，普遍遇到了同樣 的發(fā)展瓶頸，即缺乏對“人”的有效管理手段，例如員工職業(yè)化程度不高，所需要的管理人才和專業(yè)人才不能滿足業(yè)務的需要，對人的評價不到位，沒有有效的員工 發(fā)展通道，激勵失衡、好的經驗無法傳遞等等。

比較普遍的表現(xiàn)有以下方面：

1、就事論事

常?？吹竭@樣的現(xiàn)象，公司的及時交貨率越來越成問題，老板心里憤怒不已，把下屬叫過來就是一 頓大罵，可是罵完之后還是但解決不了問題，因為老板沒有那么多精力去了解分析這些具體問題，更找不到好的解決辦法；而下面的人在被罵后就開始兜圈子，理由 一大堆，不去主動分析解決問題。做的稍微好點的老板，可能會考慮引進績效考核來進行管理，例如將及時交貨率作為KPI進行管理和考核，這樣做或許在短期可 以取得一定的成效，卻還是治標不治本，因為員工還是沒有辦法去分析、解決問題。這種就事論事，頭痛醫(yī)頭的簡單的管理模式很常見。他們沒有考慮到，事是人做 出來的，要把事做好，須從人的管理開始，這其實是一個關于員工的責任、權利、做事的方式（職業(yè)化）的系統(tǒng)問題，罵一通或簡單的設置幾個指標，只涉及了問題 冰山的一角，是不能根本解決問題的。

2、短期行為

基于崗位評估來確定崗位價值，通過績效考核來確定員工的回報，是中國很多企業(yè)在管理基礎很薄 弱的情況下需要跨越的一個階段，這是一個從沒有規(guī)范到有規(guī)范的過程，但是它并非員工價值衡量和價值分配的理想模式，因為這是一種做的好就獎勵，做不好就懲 罰的管理思想，依舊是以事為中心，它無法解決員工的長遠發(fā)展需要和激勵問題。這種管理方式要求在評價期內（一般時間較短，例如績效考核周期一般為3個月）對員工有比較精確、量化的評價，而人恰恰是不能在短期內精確評價的，華為的任正非就指出，管理其實就是一個在混沌中探索的過程，管理的突破就猶如從一個混 沌進入另一個混沌；而日本企業(yè)則從來不對員工進行考核。因此，對人的管理需要平衡好短期與長期，對人的評價尤其要注意精確與模糊的平衡，否則，在短期內硬 是要求做出精確評價，必然是鼓勵短期行為。

因此，崗位評價與績效考核或許有必要，卻并非終極目標與手段。很多公司將其視為人力資源管理的奮斗目標，不惜代價在上面精益求精，不能不說是一種遺憾。

此外，提成等手段被很多企業(yè)廣泛采用，在企業(yè)的特定階段起到了很好的作用，但也帶來了很多問 題。員工做一天算一天，沒有安全感，不可能為企業(yè)的發(fā)展出謀劃策，有時會急功近利，過多的短期行為則導致企業(yè)的核心競爭力無法提升，不能滿足企業(yè)基業(yè)常青 的發(fā)展目標。安然就是一例，這家公司由于過于追求業(yè)績，對高業(yè)績的經理人采取重獎，導致經理人共同把公司的短期業(yè)績做到虛高，以從公司的股票中套利，導致 公司轟然倒塌。

3、本位主義

有的企業(yè)建立了簡單的考核指標，推行了績效考核，但發(fā)現(xiàn)考核還不如不考核。主要問題就在于考 核指標是基于職位要求設定的，但是在當前市場需求變化非?？斓那闆r下，公司內的責任、任務、活動卻是靈活的，事實上，那些對市場反應快的公司的一個顯著特 點就是，多數(shù)員工都在不同的項目里工作，而不是在部門里工作，因此，當前的考核與公司目標往往背道而馳。于是考核指標的設置不幸成為跨部門合作的障礙，導 致員工各掃門前雪，以完成個人考核指標為中心而非完成公司的目標為中心，甚至為了考核結果比其他人好，互相拆臺。不少人又會想到，設定跨部門考核指標不就 解決這個問題了嗎？只要深入做過考核的人都知道，計劃趕不上變化，這依舊不是根本解決之道。

以上種種，表明員工沒有與公司擰成一股繩。公司只關注“事”，較少關注“人”，公司沒有很好 的關注員工的想法，沒有很好的管理員工的大腦，沒能把公司的目標轉化為每個員工的使命。我們經常在提“以人為本”，實際上我們對以人為本既了解得不夠深，更沒有找到好的管理方法和手段來加以落實。

這實際上是當前面臨的一個重大管理命題，即目前的管理手段還具有工業(yè)時代的顯著特征，強調對 “事”的關注，而知識經濟下對知識工作者的管理需要新的管理模式，強調以“人”為中心，這種管理模式目前尚沒有明確的答案。華為從績效考核轉向任職資格管 理，可以說正是這個轉變的一個重要探索，應該說，任職資格管理是中國企業(yè)在探索新的管理模式上的最佳實踐之一，它被任正非視為華為過去十年的三大成功變革 之一，也備受業(yè)界推崇和效仿，已經顯示了其強大的生命力。

在這個管理命題上，日本企業(yè)也已經跨出了成功的一步。德魯克在《21世紀的管理挑戰(zhàn)》中指 出，21世紀最大的管理挑戰(zhàn)就在于，傳統(tǒng)的以西方為代表管理模式已經在應對知識工作者的管理上遭遇了瓶頸，過于強調分析、量化、邏輯、系統(tǒng)的管理方式帶有 較強的物理性和數(shù)學性，關注的是“事”，但是這與人的特征，特別是知識工作者的特征是不吻合的，人身上所具有的價值觀、使命、人的才能、不同人員的風格等 軟性因素，恰恰是無法用上述“硬”的方式來衡量的。反之，日本企業(yè)為代表的強調終生雇傭制、集體價值觀的管理方式，非常注重“人”的因素，有利于組織的穩(wěn) 定性、和諧性、協(xié)調性，恰好與解決這些西方企業(yè)面臨的問題的方向相對應，因此德魯克預言21世紀的日本企業(yè)的管理一旦取得突破（即解決終生雇傭制和人力資 源的流動性問題），將是世界學習的榜樣?？梢哉f，對人的管理，東方人的思想更具有優(yōu)勢。

下面，我們就從這個問題出發(fā)，來探討一下華為的任職資格管理。概括一點說，華為的任職資格管理可以用“管好員工的大腦，看好員工的手腳”兩點來形容。

二、管好員工的大腦

很多公司認為公司的目標是高層的事情，員工只需要接受目標分解下來的工作分派即可，結果就是公司目標、政策不穩(wěn)定，在員工眼中一變再變，員工看不到方向和希望，缺乏對公司的認同和信任感。

這實際上漠視了員工的需求，而事實上，要使員工的工作卓有成效，他們必須首先知道自己要往哪里去，要做什么，沒有任何員工可以不帶著自己的大腦和信念而工作。

德魯克指出，要發(fā)揮員工尤其是知識工作者的創(chuàng)造力，就不能把他們當作“雇員”，而要把他們當 作“志愿者”來管理。他們需要知道整個組織的使命，并且深信不疑。郭士納受命重建IBM的時候，首先是提出了8條管理原則做為IBM的核心文化，在以后的 十年間，我們看到了這些原則帶來的巨大變化。正是因為市場的不確定性，員工不應該由一些條條框框來指導自己的工作，而必須是共同的使命和愿景，以及之下具 體的管理原則來作為他們的“基本信仰”，形成工作中的動力杠桿。

因此，管理員工首先要管好員工的大腦，要明確公司的使命、愿景和發(fā)展目標，并共同制定實施策略。

以華為為例，通過建立基本法，在一場70%以上的員工廣泛參與的群眾運動中，共同完成了這個 過程。實際上，基本法并不解決任何具體問題，但可以說把華為上萬人形形色色的思想整合到一個共同的框架內，在剛剛進入市場經濟不久而處在混沌狀態(tài)的的眾多 中國企業(yè)中，基本法如一道耀眼的強光，劃亮了華為上萬員工的共同前進方向。

雖然不一定每家公司都有精力和能力做這種大運動，建立基本法也不是唯一的途徑，但是，毫無疑 問的是，任何公司必須將公司的目標內化為員工的使命，形成共同的價值觀，以促使員工自我負責、自我發(fā)展，這樣，公司才可能使員工的努力工作、積極創(chuàng)造成為 自發(fā)行為，而不必受困于或過度依賴于發(fā)獎金、處罰等胡蘿卜加大棒之類的外在手段。

要做到這一點，就需要進一步把目標的實現(xiàn)與員工的利益聯(lián)系起來，確保價值創(chuàng)造、價值評價、價 值分配規(guī)則的清晰、穩(wěn)定。華為的任職資格體系較好的回答了這個問題。在有的公司，工程師就是工程師，可能一輩子都沒有變化，員工越做越沒有希望，而在華 為，工程師被分為五級，從初級工程師到專家，能覆蓋員工整個職業(yè)生涯階段的能力、責任與貢獻的特點，同時，除了上述的技術通道外，有管理潛質的技術人員也 可以申請往管理方向發(fā)展。通過任職資格的認證，處在不同等級的員工獲得相應的回報，從初級工程師的一般性薪酬福利到專家所能獲得的股權、專業(yè)決策權、配備 技術助理等政治待遇，這符合公司的業(yè)務需求，也涵蓋了員工不同職業(yè)生涯階段的個人需求。

這樣，就形成了公司與員工共命運的管理機制，每個員工都主動想策略、找問題，員工基于使命和責任來工作，才能最大的發(fā)揮主觀能動性，實現(xiàn)共同成長。

這樣也就避免了傳統(tǒng)績效考核中那種上級不斷的想提高目標，下級則不斷的找借口和理由降低目標的博弈局面。

三、看好員工的手腳

在前面的那個關于公司的交貨及時率的案例中，員工之所以不能有效的分析解決問題，而是找理由 兜圈子跟老板周旋，還有一個重要原因，就是員工不知道怎么做，以及怎么做才能做的最好，在這種情況下公司高層介入對事情的處理，很可能就弄錯了方向，越管 越亂是理所當然的。多數(shù)企業(yè)在績效方面表現(xiàn)不佳的一種問題恰恰就在此，即員工想做好，但是沒有辦法做好。

反觀餐飲業(yè)巨頭麥當勞，光就如何制作一個漢堡，操作手冊就有一本書厚，而正是職業(yè)化的操作手冊，成就了一個西方快餐巨無霸。

很多公司高層或培訓師常常遇到這樣的尷尬，在闡述某個問題的時候，到興致上，需要在白板上比 劃比劃以增強效果，可是拿起白板筆寫不上兩個字就發(fā)現(xiàn)沒墨水了。在華為，基本上不會出現(xiàn)這種情況，因為在有關的作業(yè)指導書上，非常清楚了提示了在會議或培 訓前，秘書需要檢查白板筆有無墨水，在會議或培訓前30分鐘需要將白板筆倒立豎放，以便墨水倒流到筆尖，書寫流暢。正是由于有了這種成功做法和最佳實踐的 作業(yè)指導書（這里指

因此，在具體到如何把工作做好的問題上，管理員工還需要管好員工的手腳，即需要把如何做、如何做好整理成規(guī)范的操作指導書。華為的一些主要職位族都 建立了操作指導書，例如上面提到的秘書操作指導書，就是華為從國內各大知名院校招聘了以碩士學歷為主的數(shù)百名畢業(yè)生，進入秘書工作崗位，在實踐中整理出來 的；而對于技術類崗位、管理類崗位的作業(yè)指導書，則由外部顧問、內部專家、優(yōu)秀員工代表等共同在最佳實踐的基礎上，結合演繹和歸納等方式做出來的。

這樣，員工才能在成功經驗的基礎上，把事情做對、做好，最后，通過檢查、檢查、再檢查，公司的管理水平、職業(yè)化水平就會節(jié)節(jié)提高。

四、華為公司任職資格管理體系的特點

綜上所述，華為任職資格管理體系主要解決了在中國的職業(yè)化進程中的一些重要問題，特別是在工業(yè)經濟轉向知識型經濟的過程中傳統(tǒng)的管理手段不能解決的員工管理問題，即由以事為中心轉向更為關注人的管理模式，這是符合知識經濟的本質要求的。

概括來說，它主要解答了以下兩個重要的問題：

1、將公司的目標使命化

我們知道，只有真正從內在動機方面管理好了員工，外在的管理要素（如獎勵、懲罰）才能發(fā)揮作 用，任職資格所明確的員工職業(yè)發(fā)展通道，以責任、員工能力、貢獻為核心的任職資格標準及相應的評價手段和價值分配機制，正是通過將公司的目標與員工的個人 需求和利益捆綁在一起，從而將公司的目標內化為員工個人的使命和責任。這樣，公司無需時刻揮舞大棒或利用胡蘿卜，而員工自然會積極努力，無所不能，才能達 到公司管理的高等境界——無為而無不為。

2、將工作行為職業(yè)化

同樣，員工也需要知道如何把事情做好，通過對成功經驗的總結或學習借鑒，制定規(guī)范的作業(yè)指導 書，可以培養(yǎng)員工的職業(yè)化行為。我們需要了解，職業(yè)化的工作水準并非一定要非常優(yōu)秀的員工才能做到，它也不是聘請一兩個培訓師來講幾堂課所能解決（外部的 經驗不一定能在本公司獲得成功），只有在成功經驗的基礎上，適當?shù)倪M行借鑒，總結出職業(yè)化的行為，讓員工持續(xù)的堅持這些行為，自然會形成習慣，從而形成職 業(yè)化的素養(yǎng)。通過對作業(yè)指導書（亦即做事的方式）的不斷優(yōu)化，公司的職業(yè)化水平、工作效率自然會不斷提高。