在魔球的數據管理學中曾提及運用數據分析對於管理的好處，這次則是要用實例來說明數據中暗藏的陷阱。
大型的專案管理常會仰賴報表，這些報表不外乎用來讓管理者快速掌握進度、人力、經費等資源情況，但卻可衍生出各種不同的樣貌與規格。有個朋友曾待過一家軟體公司，專案通常為一年期，分期中與期末兩個階段審查驗收，專案成員每天要填寫工作日誌，每周要備份檔案到指定的儲存空間，專案經理除了這些例行公事之外，還要定時更新當週時程表與下周預估時程表，每周有例行進度會議，每月則要製作專案狀態報告，每季則有大型內部稽核。專案狀態報告包含了一份完整的excel追蹤清單，記錄了期初與各階段人員、資源、進度、學習狀態、費用等狀態。
此外，公司另建立專案管理辦公室(PMO)，將各部門PM納入旗下，每月透過交叉評鑑的方式，為各個專案進行狀態表的檢核，同時則有QA小組負責表格格式的追蹤，確保專案使用的表格一致。
這樣的管理架構的脈絡，是期望透過期初完整的規劃，勾勒出整個專案的各項配置，然後藉由每人每天的工作紀錄，彙整成每周、每月的數據，藉此比對預估與實際進行的差異，修正執行策略。而為了讓全公司在統一的標準下執行，因此由另一群人負責督導，也為了確保PM不會謊報，所以又讓各PM互相檢核對方的專案。
一個看似完整的管理結構，其實在運作上卻是困難重重 :
1.該公司的管理框架是以管理的角度出發，因此各種表單皆是為了讓管理能有效掌控專案而設計的，但軟體開發卻有大量的工程資源耗用，進度很難透過表格呈現，因此只能依投入的人力、時間來進行回報，本身就存在管理上的盲點。除此之外，公司長時間的工作文化，已經造成期初估算的數據有誤，進而影響後續的追蹤，這些卻是表單中看不出來的現象。
2.所謂管理是管事理人，在朋友的案例中，公司對於管理事務十分有一套，卻忽略了人性。管理思維中，透過數據的呈現可以快速掌握專案的現況，但過多的paper work，反而讓團隊成員產生反感，不但數據不真實，過程中還浪費了不少時間在定義規格。不斷交叉比對以及頻繁的會議，則顯示對PM的不信任，在不被公司信任的前提下，PM又如何展現應有的態度呢? 於是錯誤的資訊又在執行過程中持續回報，累積到最後就產生與實際開發進度完全不同的結果。
舉一個例子來說，朋友所負責的專案中，包含了數個手機應用程式的開發(App)，專案計畫書內明訂前三分之一的時程進行需求訪談與系統設計，並於檢核點產出系統設計規格書，在這段過程中，投入的人力相對少，而且因瀑布流的開發形式，造成專案前後資源分配不均，但為了順利取得公司預算，通常會將資源比重平均化，計算出合理的人力與軟硬體，進而編列部門預算。期初的估算值錯誤，每月追蹤的時候，PM為了降低被稽核而衍生的多餘工作，開始美化數字，讓專案看起來似乎在初期就投入不少人力，但相對的產值卻是偏低的。可是過程中公司多半只針對文件進行查核，無法了解軟體真正開發的進度，所以即便投入了大量行政人力，還是無法找出真正的原因，進而如願提升專案的品質。
在這個例子中，公司設計了完整的管理架構，也運用大量的數據來掌控進度，卻忽略了原有的工作文化以及人性的反應，所以一直陷在數字的謎團中無法釐清問題(當然也有可能是大家睜一隻眼閉一隻眼)，所以他們的專案就這樣始終處在產值十分不穩定的狀態，而PM總是要應付許許多多的paper work。
留言列表
