為了避免落入循環論證，或是假因的推論，讓我們先從釐清問題症狀看起，不急著推論原因，對號入座。
先排除單一事件，將之列入觀察；反之，有重複發生，普遍存在的問題，優先處理。我們先將問題概念化，找出模式，再來模式匹配，與驗證假設。
依照前文:解決問題的五個要素，三個方向，加以分析:
溝通問題的症狀，就是誤解。回報問題，則是失真，失焦，不及時，或是複雜化。
流程問題的症狀，有相當的不穩定，時好時壞，難以信賴。交接，里程碑，稽核點都不可靠。面對變化的客戶需求，供應變動，專案團隊難以適應。預算，時程，甚至數量，品質，都沒有可靠度。
組織問題的症狀，則是該組織對其成員，對其能力，也對業務的執行承諾，失去可信賴度。無法提供成員的肯定與成長，以致流失。無法有效率地分享能力，也無法產生新的技術或工程能力。對專案執行的資源與目標，都無人可以或需要承諾。整體來說，會感到，研發的人力與能力是有的，但對成員，對業務，對新的市場需求，無人承諾。
其實，研發組織需面對業務的擴張，業務模式的改變(產品導向變成客戶導向，多量少樣轉成少量多樣，功能導向變成成本導向等等)，及市場產品與技術的改變。我認為，研發組織需滿足以下特點: 擁有資源調度彈性，對業務給予專注與承諾；有效分享既有技術與能力，並能開發新技術能力；發展研發人力質量，給予肯定與成長。
抓個重點: 說不清楚，交接不清楚，感覺事情進展不可靠，不踏實，比較偏向跨部門溝通與流程的問題。反之，覺得對人的無力感，無人出面，無人承諾，忙者越忙，勞逸不均，能力不足，就偏向是組織的問題。以這個粗估，佐證上述較細的症狀，就可以產出一個方向。
驗證假設，如果是流程或溝通問題，通常在流程敘述，訓練，文件稽核，審核與溝通紀錄，並不確實，也有實質的困難。如果是組織問題，看組織圖(就像線路圖)會找不到負責人，兼差複雜，少權多責，或有權無責，而人員訓練，績效考核，晉升等重大權責，也不是研發主管可以決定。
流程改善，要形成跨部門團隊，加以解決。請參見此文。
組織改組，要先選定研發負責人，由其依據以上對業務面，對人員與對技術能力面的目標需求，提出規劃。再面對相關跨部門與下屬得到支持，最後得到老闆的許可。而後推行。
一個組織設計，必須是該主管決定，否則難以負責。
要知道，手段與目的不同。研發組織改組是一個手段，是研發負責人的權責；但研發組織的目的，要符合業務面，人員與能力的需求。業務面的需求，由各相關部門提出，當然，配合度，彈性，專注，有能力，甚至低成本，都是需求。但是要分成 Top Line (希望) 與 Bottom Line (需要)。 Bottom Line 下限必須要滿足，上限則看情況。
研發組織的目標設定，必須符合執行長的需求。但是改組的手段與設計，必須是研發主管的決策。就像網球國手對球拍與球鞋的決策，必須自己決定。
我在統寶時，組織改組原則上做了四個決定:
一。將中央廚房與模組設計分開。研發組織與工廠組織有一致性。中央廚房必須嚴謹。而模組設計依不同事業部的客戶需求配置。產生專注性，甚至命運共同體。
二。研發資源配置，依照由上而下的事業部的策略比例分配。避免過度搶案子，爭資源。也讓業務單位珍惜可用的研發資源，再度確認其命運共同體。
三。研發人員的績效考核與升遷，由人事單位的大鍋飯政策，拉回研發主管依績效分配，再由相關事業單位主管與研發最高主管共同裁決。也就是矩陣評核。
四。專案組織設定回研發單位，開案時與業務共同討論，規劃時程後成為研發單位的承諾。"承諾"是一個關鍵。研發不是配合業務，是承諾於專案的目標。當然不會百依百順，但是答應了就會全力以赴。
舊的經驗不足以適應新的狀況，但是有邏輯，有目標的組織設定，可以用很久，同時滿足公司的擴充，人員的成長與流動，與能力的進步。
如果把組織的問題，以對的方式解決，不僅是績效改善，成員滿意度都會提升。
沒有留言:
張貼留言