身處「功能工廠」而不自知嗎?功能工廠的12項特徵

December 3, 2020
Design Management

本文翻譯自 John Culter 的 ”12 Signs You’re Working in a Feature Factory“。

「功能工廠」是本文的作者用以描述一個軟體公司像無頭蒼蠅一樣一昧打造新功能,不顧長期目標與產品策略,最後不僅一事無成,還累垮工程師的奇異現象。

儘管聽來獵奇,但在軟體、網路相關產業工作幾年之後,我發現這樣的現象並不少見。功能工廠非常糟糕,且並不單單對於工程師。一個流於功能工廠狀態的公司對所有人都是有害的。

注:為求文意通暢,譯者在不影響主旨的前提下,對於本文進行了修飾性的增刪。

以下正文開始:

(這篇文章寫在2016年,我最近在2019年寫了另一篇關於從那之後學到的事情的文章

過去兩年裡,我曾在許多研討會上使用過「功能工廠」這個詞。我之所以開始使用這個詞彙,是因為一個軟體工程師朋友有一次向我抱怨,他「就只是坐在工廠裡,捶打出一個一個功能,然後放上生產線出貨了事」。

要如何知道自己正在功能工廠裡面工作呢?

1. 不衡量成果

開發團隊並不衡量他們的工作成果。或者,就算衡量了也是產品團隊關起門來自己進行,並且只跟特定的人分享。工程師根本不知道自己的工作有用或沒有。

2. 頻繁改組的團隊與項目

團隊並不關注長期的目標與計畫,只處理功能與項目的小型事項,並且長期處在身兼多職、過度負荷的狀態。

3. 功能「上線」時上演「成功劇場

(譯者按:「成功劇場」指專注在成功的表象,而非更加努力去迎來真實的成功,或檢討不足。可見作者的另一篇文章)上線時大舉慶祝,但不去討論實踐過程中的缺陷與對新功能對產品的潛在負面影響。你可以輕易的從一個組織慶祝什麼看出這個組織真實的樣貌。

4. 功能與專案很少失敗(至少很少「被承認」失敗)

衡量成功的主要因子不是實際成效,而是上線的功能數量。上線的功能鮮少因為數據與指標而被棄用。通常團隊缺少能夠承認錯誤的安全感。

5. 與關鍵指標沒有共鳴

團隊幾乎不討論客戶或是商業上的理想成果。團隊無法將自己的工作產出與客戶滿意度或是商業成果連結起來。每次產品迭代都無法和產品的核心價值、戰略目標產生連結。

6. 產品經理並不復盤

產品經理並不會定期執行項目回顧、檢驗他們的決策品質,他們並不衡量功能的預期成果與實際成果的差距。工程師們的產出都需要經過測試,但產品經理的並不需要。產品經理錯誤的只把他們工作的「速度」以及「產出量」作為衡量自己工作的關鍵指標。

7. 死板的迭代計畫

嚴格的規定團隊需要遵守敲定的功能開發順序,但從不檢討開發順序的制定是不是正確的。迭代計畫只為了滿足內部的項目計畫,照表操課只為了讓各相關單位感到「一切都在軌道上」。過度關心一切按照計畫來,不留任何調整的餘地,就算數據顯示功能優先順序需要調整也一樣。產品路線圖只顯示一長串的功能清單,而不是在每個階段,產品的核心目標與成果是什麼。

8. 沒有調整、沒有優化

只要工作「完成」了,團隊就立刻著手開始進行下一個「項目」,完全不留時間去依據數據,對功能進行迭代優化。

9. 扭曲的「交付」文化

開發團隊並不直接參與到需求的研究、問題探索、實驗與驗證。只要功能上線了,開發團隊就與後續的支持部門、客戶經理、銷售部門風馬牛不相干。

10. 臃腫肥大的需求

公司對於大型的產品需求不進行分階段的測試,所以需求就以臃腫肥大的姿態一次性的交付到開發團隊。你可能還是以「衝刺」為單位來工作(對對對我們是「敏捷團隊」),但因為需求過大,因此你會發現幾次衝刺之後,還是沒有新的功能上線。(編者按:敏捷開發的單次衝刺通常以兩週為單位,以穩定、小量為原則進行產品迭代。)

11. 追逐短期的獲利

為了眼下的生意而開發功能。雖然這無可厚非,但這樣做的經濟收益常常微薄不堪(如果有收益的話),而且還會為產品的複雜度帶來飛躍性的增長。公司可能因此達到了季度目標,但卻需要花好幾倍的時間去償還技術債。這樣的行為再一次印證了功能的數目是團隊的成功衡量單位、產品決策缺乏充分的成本效益考量。

12. 追逐閃閃發光的東西

系統重構、解決技術債是不會被看見或重視的,對於提高工作效率的努力也沒有人管。就像之前所提到的,團隊衡量成功的指標是產出的功能數目。相對於閃閃發光的新功能,產品或是系統健康根本沒有人在意。除此之外,團隊也不會注意到新功能對於現有產品的可用性、系統複雜性、延展性的負面影響。

我還寫了以下的文章,量詳細解釋這個問題,看一下吧: