給我一塊石頭

給我一塊石頭！」——專案經理應該小心的遊戲之一

克里夫與團隊一起，用一周時間制訂出了專案日程。他們完成了"哈德遜灣式啟動"，並且確定已經識別出了主要的技術風險。他將風險和日程安排告訴了他的上司諾姆。"你就不能再早點完成專案了麼？"諾姆的一句話將克里夫送回了團隊，步履蹣跚。

克里夫與團隊又花了一周時間修改時間表，得到另外乙個日期。他走進諾姆的辦公室，說道："如果你能在這裡和這裡為我提供更多的人手"，他指著幾個里程碑，"我就能用乙個月時間完成專案。"諾姆皺著眉頭說道："還不夠好。我需要這個專案早點兒結束。"克里夫嘆了口氣，又回到專案團隊中去了。

又過了一周，克里夫拿著另乙個日程來找諾姆，"好吧，這就是我們力所能及的結果了"，克里夫說。

諾姆幾乎連看都沒看，就說道："但是還是不夠好。"

克里夫暴怒道："你到底想要什麼？"

"給我一塊石頭"，這就是諾姆玩的遊戲。不管你制訂出什麼樣的日程，你的出資人總是希望專案能更早完成。你只會發現：出資人對你提出來的每乙個截止日期都不會認同--你的日期總是離他們的期望值很遙遠。

當"他們"希望專案能更快交付，但是不告訴你何時需要或為什麼的時候，就會玩"給我一塊石頭"遊戲。如果他們告訴你期望截止日期，你就能告訴他們能完成哪些工作。如果他們告訴你原因，你和團隊也許就能想出一些創造性的解決方案來滿足他們的要求。

講求實效的專案經理自有應對之策，其中就有克里夫採取的談判策略。可一旦談判失敗，或者看起來永遠難以成功，不妨試試下面的方式。 blog.mypm.net

·在試圖取更多石頭之前，先提幾個問題：你喜歡短的日程，還是長的日程？是要更多的人，還是更少的人？要是少實現幾個功能會如何？先知道什麼是最重要的，這會幫專案經理產生更加合理的解決方案，多少也能為你的談判做些準備。

·找出是什麼原因促成了他們期望的截止日期。探尋出這個專案的戰略原因，並搞清楚"成功"的真正含義。

·要讓出資人明白你做出的選擇以及背後的原因。也許出資人會有更容易操作、更快實現的好主意。

·為你提供的日期說明信心範圍。很可能管理層不明白你的估算意味著什麼，而且你也有可能不理解他們所要的東西。

·在提供日期時要說明發布條件，這樣你就可以提一些問題，了解他們對於發布版本的質量和功能的要求。我們可以讓這個功能的效能極其出色，但是就得先放下那個功能，這樣做可以麼？使用者們可以接受帶有更多缺陷的產品麼？

在乙個組織中，"給我一塊石頭"會反**生。很多時候，每個專案都會發生這種狀況。如果你總是碰到"給我一塊石頭"的問題，考慮採用下面的實踐：

·制訂排好優先順序的產品代辦事項列表。

·使用短小的時間盒（持續時間少於四周），這樣出資人就可以看清專案程序。如果你每隔幾周就能展示出專案的有價值的進展，截止日期就沒那麼重要了。你可以開始討論何時實現哪個功能，他們對質量的要求又是什麼。

即使專案經理自己努力做好估算、規劃和日程安排工作，你遇到的出資人、管理層和團隊成員還是有可能視日程安排為兒戲。專案經理要把這些人帶回現實，不過首先要學會識別這些日程安排遊戲。所有的出資人和管理層都會逼你在日程安排上做出一些讓步。即使你制定的專案日程已經相當合理了，他們還是會玩這樣的遊戲。不過他們抗拒的方式很容易識別，很少脫離幾種固定的模式。專案經理只要能夠識別出他們所玩的遊戲，就可以更容易地掌控專案，得到理所應當的產出。

「希望」是我們最重要的策略——專案經理應該小心的遊戲之二

幾年前，乙個資深經理打**給我，說道：「我們有個專案出問題了。在啟動的時候，我們充滿了希望，但是現在看來已經不可能了。」我問了幾個問題，發現他們之前從來沒有做過類似的專案。相對以前，這個專案的規模更大，使用新的開發語言，基於新的平台，而且日程安排更短。

整個公司的未來都押在這個專案的成功上，問題是它比以前做過的專案都要複雜，而且要求也更高。他們唯一的策略就是「希望」。

他們沒有安排任何關於專案所在領域、使用的開發語言或新作業系統的培訓。他們對這個專案希望能夠達到的時間要求，也是以前從未做到的。

僅有希望，不足以交付乙個成功的專案。

講求實效的專案經理會這樣做：

·識別風險並記錄下來。風險可能來自於技術（新的開發語言、新的平台）、日程安排（時間過短、人太少），很多時候兩者皆有。

·不到萬不得已，不要選擇瀑布式生命週期。為什麼？因為你沒有任何資料足以成功支援瀑布式需要的前期計畫過程。要是你從未做過類似的專案，用迭代進行原型化，或者通過迭代開發幾個功能，看看會是怎麼樣乙個情況。

·可以用「哈德遜灣式啟動」看看是不是能做出些什麼東西。要使用即將使用的新的開發語言、作業系統、資料庫以及類似新技術，這樣做效果尤其好。「哈德遜灣式啟動」能夠讓團隊了解要做的東西，而且可以揭示一些目前尚未發現的風險。專案管理培訓

·考慮所有工作都採取迭代的方式進行，特別是專案規劃和日程安排。

·由於缺少經驗和專業知識，可以尋求相關的幫助和資訊。跟團隊成員一起商量如何能讓別人了解他們的工作進展。

·制訂里程碑條件（里程碑也可以是迭代的）。在管理層複審會議上審查這些條件。即使管理層或出資人不願意做複審，專案經理也可以主導這些會議。如果不知道怎麼樣才能讓專案正常運轉，可以按里程碑週期性審查專案進度。

不要指望僅憑希望就能得到好的結果。

作為專案經理，你的工作就是要計畫、再計畫，並努力工作，以得到最好的產出。以下這些實踐可以幫你達到目的。

·使用有時間盒限制的迭代，這樣所有的人都可以看到專案的進度。

·使用速度圖表展示專案進度。要讓大家都能很明白地看到進度（或匱乏的資源）。這樣一來，特別是在需要幫助的時候，這些資料可以拿來使用。

拒絕女王——專案經理應該小心的遊戲之三

有些老闆就是不願意面對現實。你告訴他們：「我們無法達到你對時間上的要求。」他們就好像根本沒聽見，看著你，然後告訴你：「我相信只要你上心，就一定能按時搞定。」你坐在那裡啞口無言，他們卻高高興興地走了，好像專案在他們給出的日期前一定可以交付。出現這樣的狀況，你就是碰見「拒絕女王」了。

有不少原因會引發「拒絕」。我所見過最常見的原因，就像上面提到的經理，他希望鼓勵專案團隊。有時，人們拒絕是因為他們害怕專案無法在截止日期之前完成，他們不會管你說什麼，這就是鴕鳥效應。有時，公司高層相信：如果設定模糊或是不可能的日期，專案團隊就可以早於他們自己預想的時間完成專案。

可以用下面的方式應對「拒絕」。

·找出為什麼你的經理表示拒絕。嘗試用一些與上下文無關的問題，以此來理解專案背後的原因。比如，你可以問：「對這個專案來說，要怎麼樣才算成功？」

·寫下專案的風險及其潛在影響。用高、中、低來討論嚴重程度和暴露程度，不要用數字。不拿你制訂的日程當回事的人，對這些風險數字也不會認真。

·展示你所能做到的事情，並測量團隊在專案中的實際開發速度。沒錯，這裡用迭代是非常方便的，而且速度圖表可以告訴別人專案的真實現狀。

·保證參與專案工作的每個人都有相關領域的專業知識。

如果管理層認為「拒絕」是鼓勵團隊的方式，建議他採取其他的鼓勵技巧。通常，這意味著讓他去幹點兒其他對團隊有益的事情（比如通過談判去縮小需求的範圍），或者將他的注意力吸引到別的專案上去。管理層可能認為拒絕現存問題或潛在問題可以鼓勵團隊，其實這反而會對團隊形成障礙。將他們的注意力轉移到其他專案上是一種很有用的技巧，可以讓他們不再總盯著你的專案。

只要專案經理能夠接受現實，「拒絕女王」就不一定能造成災難。

有個團隊試圖說服專案經理接受專案的現實。失敗幾次後，他們放棄了，並且決定自己組織起來，忽略專案經理的存在。他們不再參加專案團隊會議，並且將專案經理的話拋在腦後。他們開發了專案的部分功能，並且產生了一些資料（不過不是速度圖表）。幾個月之後，大家都看出來專案經理根本不了解目前的狀況，此人也因此被炒了魷魚。可這時，專案團隊也已經損失了很多時間，他們很難再控制什麼時候交付哪些功能了。

現實總是會在某個時候跟「拒絕」面對面，這不可避免，而且這就是「拒絕女王」為什麼只是規劃遊戲，而不會總是造成災難的原因。當管理層看到了真正的現實之後，專案經理要確保自己有部分可以工作的產品、可以展示的資料，讓管理層可以跟你討論接下來能夠做些什麼。此時也是討論「有哪些事情可以不做」的好時機，這樣你就可以完成當前的專案，並且為後續專案做更好的規劃。

如果專案經理總是遇到「拒絕女王」，那麼在進行管理的時候，可以把下面的方法整合進去，大家也就可以看到實際進展了。

·使用有時間盒限制的迭代，這樣所有的人都可以看到專案的進度。

·制訂排定優先順序的產品待辦事項。團隊可以按照功能的業務價值，從高到低逐個實現。等到出資人如夢初醒，終於意識到專案無法按他給出的日期交付時，團隊也已經開發完成了若干高優先順序的功能，這樣專案經理也會得到一些有價值的東西。

給我一塊石頭

最後一塊石頭重量

推一塊石頭上山

Leetcode 最後一塊石頭的重量

給我一塊石頭

最後一塊石頭重量

推一塊石頭上山

Leetcode 最後一塊石頭的重量

相關推薦