1. 誰喜歡被管制

   公元兩千多年前，我們腳下的這片土地，處在一個人人向往的太平盛世，以至于現(xiàn)在我們這些后人，都時時引之以為榮。（更有些高高在上的人，不知臉皮為何物地吹噓當世可以為它的翻版。）這段我們向往的歷史，即是“文景之治”。其治理策略更為人所熟知 - “無為而至”，“輕徭薄賦”，“與民休息”。（說白了，就是什么也不干?）

   很不幸，作為開發(fā)人員，似乎我們很難碰到像劉恒或劉啟那樣的老板。正好相反，項目經(jīng)理或者更高級的主管們往往會在我們沉靜在思考中時，像蒼蠅一樣嗡嗡地飛來采集進度 - 不懂技術(shù)的，只是一個會說話的監(jiān)視攝像頭；略知技術(shù)的，往往會提出一些干擾性大于操作性的建議；即使有真的精通技術(shù)的，除了提了建議炫耀自己的專業(yè)實力，更多的是打擊開發(fā)人員并養(yǎng)成其依賴性......

結(jié)果......
   我常常聽到下面的人抱怨：我們領(lǐng)導煩死了，除了監(jiān)工啥也不干!
同樣有趣的是，我也常常聽到管理者抱怨：下面這些員工啊，素質(zhì)低，愛偷懶，不把工作當回事，只圖完成任務交差而已！

   軟件開發(fā)歸根到底是人為主導的行業(yè)，人性化是無法忽略的。我們渴望在軟件開發(fā)工作中拋棄官本位，拒絕垂直命令，解放自己，同時也解放管理者。

2. SCRUM的一個原則 – 拜托，請您不要管太多！

   SCRUM提醒經(jīng)理們，你的任務是支持開發(fā)人員，掃清障礙。而不是傳統(tǒng)的命令和控制！習慣了當官的人不明白 - 支持？只是支持？不會吧？那種自我膨脹和虛榮的感覺都沒了？我必須得控制，得發(fā)號施令！再說不這樣也不行啊，不催項目就會延期。

   讓我們對比一下大家常見的真實世界和SCRUM提倡的情景吧！看看究竟那種方式更有成效。

  場景一：初步制定了一個開發(fā)周期計劃以后，開發(fā)組和項目經(jīng)理一起開會討論計劃，表述了計劃日期和原因以后：
真實的世界=>
開發(fā)組長（小心翼翼地）：“您看著計劃如何，同意否？”
項目經(jīng)理：“恩，還行。不過我覺得這個功能看起來沒有那么難吧，嗯哈...你們估算的時間怎么這么長？”
開發(fā)組長: “（陳述原因）......”
項目經(jīng)理：“哎...大家加加班，辛苦點嘛...有什么要求盡管可以提嘛...（畫餅。通常提了要求也得不到滿足）”
后果：開發(fā)組不得不聽從上頭意見加班，滿肚子怨氣，責任心進一步降低了。開發(fā)組長覺得自己的評估遭到否決，自己的話語權(quán)被剝奪，還要為了縮短的時間不斷壓迫成員。
SCRUM的世界 ---- 開發(fā)組是交付成果的真正負責人??！=>
開發(fā)組長（小心翼翼地）：您同意否？
項目經(jīng)理：你們覺得該計劃沒問題？能按時按質(zhì)量完成？
開發(fā)組長：是的。
項目經(jīng)理：那就按照你們的做。
后果：開發(fā)組長對自己有了信心，開發(fā)組成員感覺到了自己的話語權(quán)（雖然是很有限的），即使加班，也是對自己的計劃負責，怨不得上級壓迫。

   場景二：開發(fā)組例行會議. 項目經(jīng)理也來湊熱鬧
真實的世界 =>
會議開始，開發(fā)組長打開一個word或者什么文檔，然后請每個人輪流匯報進度。
會議進行中，每個人輪流匯報進度...項目經(jīng)理突然就匯報中的某問題提問，開發(fā)人員回答解釋....
會議趨于尾聲，開發(fā)組長請項目經(jīng)理發(fā)言
項目經(jīng)理：“恩，我覺得...你們應該注意*#@#$$，你們還要#%#$...還要#%$T#$”
會后結(jié)局：開發(fā)

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html