這陣子打算在團隊中引入敏捷開發，在推進過程中受到了些阻力，確實也是些不同的觀點值得參考，整件事背景源自於某個產品忽然人都被抽調走，由原本的 8 人剩下 2 人，試想原本 8 人的工作變成兩人來承接該怎麼辦？
先來看看原本 8 人的配置方式，每個功能指派給 1 個人負責，把整個系統拆成 8 大功能，好處是任何功能出錯了都可以立即找到對應的人，對於每個人都有長期可延續的事，並且也可以開始學習規劃自己的產品；看似非常棒，並且這模式也跑了 2 年之久，但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。
產品主從關係沒了，每個功能負責的人都認為自己是主，就像一場電影中每個人都不顧劇情一直搶鏡，其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來，可以想像觀眾的感受是如何，當然這也可能是種特色，但這種特色作為個長期的產品來看簡直無法想像，首先影片好不好看完全取決於角色，如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向，確可能造成因為人的能力不同，某些淺在重要功能就這樣被搞砸而造成走偏。
KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫，站在管理角度也很好打分，然而管理者放任這種發展就是對產品的不負責，變為以產品開發者為中心，好聽點叫由下而上的工作模式，實質造成產品發展與人強關連，並且產品功能間不互通，某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。
收回原本的問題，產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半，然後還是一樣各幹各的，頂多是出現重要緊急的事才會有合作的時候出來，產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責，由一個人來規劃產品，可以讓每個人盡量做相同方向的事，但優先級是以整個產品來思考而非單一功能，以用戶需求唯出發點而不是以功能該如何支持用戶。
每個產品需求新增的同時必須來思考如何刪除，尤其是容易跟業務掛勾上的產品，業務邏輯隨時在變，然而一個不小心可能產生大量歷史業務邏輯在系統中，長期下來就形成了技術債，嚴重的話就會變成系統重寫。
屁話一堆...簡單總結就是
1. 產品的走向應該統一規劃，而不是依賴每個人負責一小部分，管理者必須把產品功能、開發流程疏理清楚
2. 傾聽用戶的聲音，明確產品定位，業務邏輯必須抽離主架構中
3. 上新功能前先想好如何刪除，確保產品核心功能不受影響
先來看看原本 8 人的配置方式，每個功能指派給 1 個人負責，把整個系統拆成 8 大功能，好處是任何功能出錯了都可以立即找到對應的人，對於每個人都有長期可延續的事，並且也可以開始學習規劃自己的產品；看似非常棒，並且這模式也跑了 2 年之久，但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。
產品主從關係沒了，每個功能負責的人都認為自己是主，就像一場電影中每個人都不顧劇情一直搶鏡，其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來，可以想像觀眾的感受是如何，當然這也可能是種特色，但這種特色作為個長期的產品來看簡直無法想像，首先影片好不好看完全取決於角色，如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向，確可能造成因為人的能力不同，某些淺在重要功能就這樣被搞砸而造成走偏。
KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫，站在管理角度也很好打分，然而管理者放任這種發展就是對產品的不負責，變為以產品開發者為中心，好聽點叫由下而上的工作模式，實質造成產品發展與人強關連，並且產品功能間不互通，某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。
收回原本的問題，產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半，然後還是一樣各幹各的，頂多是出現重要緊急的事才會有合作的時候出來，產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責，由一個人來規劃產品，可以讓每個人盡量做相同方向的事，但優先級是以整個產品來思考而非單一功能，以用戶需求唯出發點而不是以功能該如何支持用戶。
每個產品需求新增的同時必須來思考如何刪除，尤其是容易跟業務掛勾上的產品，業務邏輯隨時在變，然而一個不小心可能產生大量歷史業務邏輯在系統中，長期下來就形成了技術債，嚴重的話就會變成系統重寫。
屁話一堆...簡單總結就是
1. 產品的走向應該統一規劃，而不是依賴每個人負責一小部分，管理者必須把產品功能、開發流程疏理清楚
2. 傾聽用戶的聲音，明確產品定位，業務邏輯必須抽離主架構中
3. 上新功能前先想好如何刪除，確保產品核心功能不受影響
發表文章
