[翻譯]12 個你正在「功能工廠」(Feature Factory)上班的表徵

Toki Kanno
4 min readAug 16, 2020

--

原文是 @johnpcutler在 Nov17, 2016 發表的 ”12 Signs You’re Working in a Feature Factory”。本文是本人爲了強迫自己多看點文章所以進行的個人翻譯,本人不擁有原文版權,也不保證翻譯的 100% 正確性。

過去兩年,我在數個研討會的演講上開始使用「功能工廠」(Feature Factory)這個詞彙。我開始使用這個詞彙是因爲有在軟體業工作的朋友向我抱怨他日常的工作根本是「坐在工廠的產線裡,把功能(feature)按照需求製造出來,然後再把它們(feature)送出產線」

那麼你該如何知道你正在一個功能工廠上班呢?

  1. 從不測量。你的團隊從不測量他們的工作造成的影響(Impact)。或是這個測量的確有人在做,但卻只由產品的管理階層執行、並且只會選擇性的分享給開發的團隊。你從來不會知道你的工作是否是有效的。
  2. 經常性的重組團隊或是專案成員。團隊通常是被分配到功能或是專案的開發、而不是因爲令人信服的說明或是自主判斷。並且成員長期會有身兼 多職和被過度分配任務的問題。
  3. 成功劇場(我猜作者是想說公司的近期專案發表會之類的場合)的主題總是圍繞著「功能上線」而不是帶來的影響(Impact)。你可以從一個組織通常會慶祝什麼來很好的理解一個組織的本質。
  4. 很少宣佈失敗/作廢功能。不曾移除功能。組織主要用推出了多少功能(delivered features)來衡量你的工作是否成功,而不是你的工作帶來了多少產出(outcome)。工作很少因爲研究過後被取消。通常團隊並不會預留承認失敗或是誤判的空間。
  5. 功能和核心數字缺乏關聯性。很少討論到顧客或是商業上需要的產出。團隊的工作通常對於關鍵的顧客/商業數據沒有連結。也無法漸進的連結到「什麼才是最重要的」(what matters most)。
  6. 沒有關於 PM (Product Manager)本身的回顧。產品經理本身,對於他在產品上的決定、以及這些決定預計帶來的好處與實際帶來的好處的差異,並沒有進行一個經常性的回顧。開發人員的產出必需被測試,但是產品經理的並不需要。產品經理只會把(功能開發的)速度和交付當作 他的 KPI 項目。
  7. 癡迷於決定優先次序(prioritization)。優先次序(prioritization)指的是決定你現在要先做什麼。驗證(validation)指的是你現在做的是否是正確的事,但是它們經常被混爲一談。(譯者個人解讀:有些事被排定優先要做、但不代表它是現在真正被需要做的)產品路線圖上會列出功能列表,而不是要關注區域或是實際要獲得的產出。(另外中間有一段很難翻譯,建議去看一下原文,但這段大意是指功能工廠通常都無法保留時間與彈性、來根據新獲得的資料調整與優化功能項目,因爲它已經被先決定好的優先次序塞滿了)
  8. 不進行後續調整。當一項功能上線了,團隊立刻會開始執行下一個「專案」。並不會保留任何時間進行質或量的調整。
  9. 如何承接與交付專案。在專案真正開始前,就會有一些研究先被進行,所以專案一開始的狀態就是「準備進工程開發階段(ready for engineering)」。開發團隊並不會參與研究問題、探索問題、實驗解法以及驗證解法的階段。並且在專案一上線後,開發團隊後續也不太會參與客服、顧客滿意、實際銷售狀態等結果的追蹤。
  10. 整批上線。在無法獲得許可以實驗的方式進行驗證的情形下,功能通常就會採用一次整批上線的方式來發佈,而不是漸進式的發佈。你可能還在某個專案的 sprint 開發期間(嘿,我們很「敏捷(agile)」的),但是每次的 sprint 後你再也不會針對這個功能發佈任何新東西給你的客戶了(譯者個人解讀: 因爲要上線的項目都決定了)。
  11. 追求眼前利益。功能通常被設計出來只爲了追求特定的新訂單。當然這並不是錯的。單憑財務方面的評量,你很難評估某個功能對於產品內部複雜度的增加程度(你可能因爲新的功能賺了2毛5,但是你後續要爲這個功能付出更多的2毛5來維護它)。並且,這也讓評估新功能帶來的價值時,會更偏向這些財務面的衡量。在產品的決策方面,也會缺乏非財務面的聲音。
  12. 重點項目。重構或是還技術債的項目在組織內的受重視度偏低。就像上面所述,組織主要用來衡量成功的標準是完成了多少新的功能。去調整產品本身的體質這件事、相對於開發閃亮亮的新功能來說,並不會得到太多的重視。而新功能對於產品本身在可用性、易維護性以及可擴充性方面的影響,自然也不會受到太多的討論。

--

--