以人為中心的管理模式

這陣子打算在團隊中引入敏捷開發,在推進過程中受到了些阻力,確實也是些不同的觀點值得參考,整件事背景源自於某個產品忽然人都被抽調走,由原本的 8 人剩下 2 人,試想原本 8 人的工作變成兩人來承接該怎麼辦?

先來看看原本 8 人的配置方式,每個功能指派給 1 個人負責,把整個系統拆成 8 大功能,好處是任何功能出錯了都可以立即找到對應的人,對於每個人都有長期可延續的事,並且也可以開始學習規劃自己的產品;看似非常棒,並且這模式也跑了 2 年之久,但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。

產品主從關係沒了,每個功能負責的人都認為自己是主,就像一場電影中每個人都不顧劇情一直搶鏡,其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來,可以想像觀眾的感受是如何,當然這也可能是種特色,但這種特色作為個長期的產品來看簡直無法想像,首先影片好不好看完全取決於角色,如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向,確可能造成因為人的能力不同,某些淺在重要功能就這樣被搞砸而造成走偏。

KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫,站在管理角度也很好打分,然而管理者放任這種發展就是對產品的不負責,變為以產品開發者為中心,好聽點叫由下而上的工作模式,實質造成產品發展與人強關連,並且產品功能間不互通,某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。

收回原本的問題,產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半,然後還是一樣各幹各的,頂多是出現重要緊急的事才會有合作的時候出來,產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責,由一個人來規劃產品,可以讓每個人盡量做相同方向的事,但優先級是以整個產品來思考而非單一功能,以用戶需求唯出發點而不是以功能該如何支持用戶。

每個產品需求新增的同時必須來思考如何刪除,尤其是容易跟業務掛勾上的產品,業務邏輯隨時在變,然而一個不小心可能產生大量歷史業務邏輯在系統中,長期下來就形成了技術債,嚴重的話就會變成系統重寫。

屁話一堆...簡單總結就是
 1. 產品的走向應該統一規劃,而不是依賴每個人負責一小部分,管理者必須把產品功能、開發流程疏理清楚
 2. 傾聽用戶的聲音,明確產品定位,業務邏輯必須抽離主架構中
 3. 上新功能前先想好如何刪除,確保產品核心功能不受影響