【文章內容簡介】 員。 綜上所述，項目管理想要更好地發(fā)展，就搖把目光放遠些，追求精益管理，無疑是未來項目管理發(fā)展的主流。 6 小督辦解決 項目 管理大問題 A 集團公司經過十年的發(fā)展已經形成一家以化工產業(yè)為主，并涉及相關上下游不同行業(yè)的集團化公司，集團總部對下屬各分公司 的管理方法有財務管控，也有全面的經營管理，還有參股的獨立核算型的分公司， 2020 年為提升集團公司整體的管理水平 。 集團公司在信息化方面進行了整體的規(guī)劃，在原有財務系統(tǒng)的基礎上，又使用了 ERP、OA系統(tǒng)。集團在規(guī)范化及效率方面都了很好提升。 不過最近一次小小的失誤，給公司造成了不小的損失。不僅丟失了客戶，還對公司的品牌形象造成了惡劣影響。 這讓集團高層開始思考，如何更好地對細節(jié)進行把控？管理者身居高位，事必躬親不現實，事無巨細很累人，但用什么方式來彌補細節(jié)失誤所可能帶來的損失？ 集團公司提出 要加強內部的監(jiān)管，把問題處理在萌芽之中，對各職能范圍內出現問題實行問責制。在各分管領導看來，定戰(zhàn)略、帶團隊、打硬仗都沒為題，但卻常常免不了在不起眼的細節(jié)處摔跟頭，如今集團公司的一紙令文也可謂是當頭棒喝。 如果說，以前的失誤是可以彌補的，這次的教訓卻讓大家開始懷疑結果型的工作管理是否合理？有沒有更好的管理模式？過程管理如何更好地實現？ 過程管理的重要性不言而喻，但由于管理面廣，并非事事都能時時跟蹤。即使工作通過OA 系統(tǒng)實現了電子化，也依然難以實現理想中的過程管理狀態(tài)。 OA？當想到 OA 應用以來，公司在 流程管理上的提升，高管們再一次想到了 OA 系統(tǒng)。 有沒有辦法通過 OA實現更加科學規(guī)范的過程管理？！當各位高管聚集在信息中心時，所有的壓力突然間轉移到了信息中心的 c主任身上，問題像雪片一樣飛向信息中心，都是需要支持的。還好，多年的管理經驗讓 c主任很快冷靜下來，梳理思路、分析總結，他發(fā)現問題集中在兩個方面： 在管理范圍內但是沒有直接參與的流程，也可以隨時查看； 如果我發(fā)現問題，是不是可以隨時給出建議，進行指導和指正 ,從而影響執(zhí)行的結果。 這不就是 “督辦 ”？！ c 主任突然想起不久前在泛微公司的 OA 深度應 用培訓，主題就是“督辦 ”。當時感覺這個功能確實是為整個 OA系統(tǒng)錦上添花了，但并沒有深入思考這個功能的業(yè)務應用，現在看來，一些小小的功能背后可能隱藏著管理之道呢！ 馬上行動！ c主任趕快找來文檔查看，并咨詢了泛微公司的客服人員，終于吃下了定下丸！ “流程督辦：為了滿足一部分管理員不在流程設置的流轉范圍內，但是需要對某些流程進行監(jiān)督催辦，系統(tǒng)通過提供流程督辦功能來指定相關人員對指定類型的流程有查看的權限，并能對流程提出相關的督辦意見。 ”就是這樣！ C 主任馬上和業(yè)務部門的負責人進行了溝通，在泛微客服 人員的協(xié)助下搭建了測試環(huán)境。當各分管領導再來信息中心的時候， C主任要做的，就是登陸系統(tǒng)，點一下督辦菜單，把所有督辦事宜展現出來！ 督辦功能的上線使用順理成章。很快， “督辦 ”功能成為高管們最常使用的工具之一。由于高層的督辦，事務處理效率在原來基礎上又提升了一個臺階，細節(jié)的把控更加到位，管控風險大幅降低，信息化助力企業(yè)提升管理能力得到了又一次的驗證。 綜上，在項目管理中，負責監(jiān)管的督辦其實負有很大的責任，雖然作用不是很明顯，但是對于一個項目來說，卻是無可替代，舉足輕重的。 7 談談 SCRUM 中的 項目經理 1. 誰喜歡被管制 公元兩千多年前，我們腳下的這片土地，處在一個人人向往的太平盛世，以至于現在我們這些后人，都時時引之以為榮。（更有些高高在上的人，不知臉皮為何物地吹噓當世可以為它的翻版。）這段我們向往的歷史，即是 “ 文景之治 ” 。其治理策略更為人所熟知 “ 無為而至 ” ， “ 輕徭薄賦 ” ， “ 與民休息 ” 。（說白了，就是什么也不干 ? ） 很不幸，作為開發(fā)人員，似乎我們很難碰到像劉恒或劉啟那樣的老板。正好相反，項目經理或者更高級的主管們往往會在我們沉靜在思考中時，像蒼蠅一樣嗡嗡地飛來采集進度 不懂技術的，只是一個會說話的監(jiān)視攝像頭；略知技術的，往往會提出一些干擾性大于操作性的建議；即使有真的精通技術的，除了提了建議炫耀自己的專業(yè)實力，更多的是打擊開發(fā)人員并養(yǎng)成其依賴性 ...... 結果 ...... 我常常聽到下面的人抱怨：我們 領導煩死了，除了監(jiān)工啥也不干 ! 同樣有趣的是，我也常常聽到管理者抱怨：下面這些員工啊，素質低，愛偷懶，不把工作當回事，只圖完成任務交差而已！ 軟件開發(fā)歸根到底是人為主導的行業(yè)，人性化是無法忽略的。我們渴望在軟件開發(fā)工作中拋棄官本位，拒絕垂直命令，解放自己，同時也解放管理者。 2. SCRUM 的一個原則 – 拜托，請您不要管太多！ SCRUM 提醒經理 們，你的任務是支持開發(fā)人員，掃清障礙。而不是傳統(tǒng)的命令和控制！ 習慣了當官的人不明白 支持？只是支持？不會吧？那種自我膨脹和虛榮的感覺都 沒了？我必須得控制，得發(fā)號施令！再說不這樣也不行啊，不催項目就會延期。 讓我們對比一下大家常見的真實世界和 SCRUM 提倡的情景吧！看看究竟那種方式更有成效。 場景一：初步制定了一個開發(fā)周期計劃以后，開發(fā)組和項目經理一起開會討論計劃，表述了計劃日期和原因以后： 真實的世界 = 開發(fā)組長（小心翼翼地）： “ 您看著計劃如何，同意否？ ” 項目經理： “ 恩，還行。不過我覺得這個功能看起來沒有那么難吧，嗯哈 ...你們估算的時間怎么這么長？ ” 開發(fā)組長 : “ （陳述原因） ......” 項目經理： “ 哎 ...大 家加加班，辛苦點嘛 ...有什么要求盡管可以提嘛 ...（畫餅。通常提了要求也得不到滿足） ” 后果：開發(fā)組不得不聽從上頭意見加班，滿肚子怨氣，責任心進一步降低了。開發(fā)組長覺得自己的評估遭到否決，自己的話語權被剝奪，還要為了縮短的時間不斷壓迫成員。 SCRUM 的世界 開發(fā)組是交付成果的真正負責人！！ = 開發(fā)組長（小心翼翼地）：您同意否？ 項目經理：你們覺得該計劃沒問題？能按時按質量完成？ 開發(fā)組長：是的。 項目經理：那就按照你們的做。 后果：開發(fā)組長對自己有了信心，開發(fā)組成員感覺到了自己的話語權（雖然 是很有限的），即使加班，也是對自己的計劃負責，怨不得上級壓迫。 場景二：開發(fā)組例行會議 . 項目經理也來湊熱鬧 真實的世界 = 會議開始，開發(fā)組長打開一個 word 或者什么文檔，然后請每個人輪流匯報進度。 會議進行中，每個人輪流匯報進度 ...項目經理突然就匯報中的某問題提問，開發(fā)人員回答解釋 .... 會議趨于尾聲，開發(fā)組長請項目經理發(fā)言 項目經理： “ 恩，我覺得 ...你們應該注意 *@$$，你們還要 %$...還要 %$T$” 會后結局：開發(fā)組認為自己被干涉，上面管的太多太瑣碎。 SCRUM 的世 界 只有開發(fā)組自己才能對自己負責！ = 項目經理： “ 我不應該出現??！這個會議不是為了向我匯報成果展示績效 , 而是為了解決開發(fā)過程中的問題，應該由他們自由討論。 ” 會后結局：高效的會議！組員不只是為了秀自己的進度給上級，更關鍵的是提出了自己的問題和困惑并得到其他成員的支持去解決問題。 場景三：交付成果審查，項目經理發(fā)現了一個問題 真實的世界 = 項目經理： “ 你們這里有一個漏洞，我知道一個解決方案，你們應該 $$@...” 結果：開發(fā)人員的信心被打擊，并趨向與養(yǎng)成對經理審核的依賴性 SCRUM 的世界 項目經理不應該干涉過多，發(fā)現問題，解決問題都應該留給開發(fā)組自己！ = 項目經理： “ 恩，非常好！不過好像沒有考慮到一個問題， (但是我不會說出來 )，我相信你們自己會發(fā)現，請仔細審查一下。 ” 結果：開發(fā)組自己發(fā)現并解決問題，面子被照顧，并且日后會更加認真。同時對項目經理的專業(yè)能力表示贊同。 場景四：不干涉不行 重回老路？？ 實施 SCRUM 有一段時間后，項目經理發(fā)現開發(fā)組的工作效率和工作熱情都提高了！一切似乎進行的不錯，開發(fā)組長和組成員都開始從心里對項目，產品有了較 高的負責心，不再只是單純?yōu)榱藢Ω渡厦娴娜蝿樟?。可是有一天，項目經理的上司，公司的高級經理來了? 高級經理要求審視所有進度和發(fā)布成果。在項目經理完成展示后，高級經理很不高興。 高級經理： “ 這個項目