技術管理觀點
技術管理觀點
技術管理之二(6):敏捷思維
0:00
Current time: 0:00 / Total time: -4:28
-4:28

管事是技術管理的另一個一個專業項目,大部分的技術組織雖然有PM的角色,但技術管理者仍然會需要管理工作項目,尤其是跟技術相關的事項。管事的最後一個主題,想討論「敏捷思維」的概念。

近幾年敏捷的概念非常的熱門,到處都可以聽到各種「為什麼要敏捷」或是「導入敏捷的方法」。老闆可能會以為敏捷就是可以更快做出東西然後到市場上賣,然而當他聽到敏捷不能加快軟體開發速度的時候,又會覺得敏捷沒有用。

敏捷的心態

事實上,敏捷應該是一種心態。敏捷的心態是:我先來試試看,在試的過程中,再來調整與改善。而與敏捷相對的心態就是:我一定要有 ABCDEFGHI…… 這些功能後,才能推出市場。後者其實是我(在組織裡)還蠻常見到的心態。舉例來說:

  1. 我一定要有這個功能才能上線

  2. 我一定要有完整的規格書才能開發

  3. 我一定要有自動化的系統才能推廣

  4. …族繁不及備載

矽谷的科技公司大多都是以敏捷的心態在做生意的。舉個例子來說,AirBnb 一開始是創辦人看到舊金山辦展覽的時候,旅館房間一位難求,因此他試著將他自己的房間放上網路,用氣墊床的方式分享給其他人,藉此收了第一筆租金。這個方式完全不自動化,甚至也沒有網路的付款方式,一且都是現金交易,但經過多次的迭代後,成為了現在市值 1000 億美金的生意。

因此,敏捷並不能讓 ABCDEFGHI…… 這些功能一夜之間就完成,但可以先提供核心價值讓客戶使用,獲取客戶回饋後,持續迭代改善。

什麼「不是」敏捷

在我的經驗中,跑敏捷的團隊會歪掉,通常是因為誤解了敏捷的意義:

  1. 以為跑 Scrum 就是敏捷,花了很多時間開 Scrum 的會議,而心態上仍然是要一包功能都完整後才開始面對市場。
    如果真的要一包功能完整後才開始面對市場,用瀑布式的開發會更適合,但相對看到的可能問題是這個產品可能沒有核心價值,跟市面上競品差異不大,才會導致需要一整包功能都完成之後才能面對市場。當遇到這樣的狀況時,可能需要重新從商業模式畫布上,討論提供給客戶的核心價值。

  2. 團隊溝通上不以客戶回饋、數據作為支撐:即使每天有站立會議、用看法方法來管理,但執行的方法仍然是以「簡單好作」或「團隊想法」為優先,當產品推出市場的時候,一旦客戶不買單,則整個產品就需要作大幅度的修改,之前所有投入的資源都無法產生效益,這也不是敏捷的作法。

  3. 客戶沒有回饋之前就調整:常見的 OverDesign 狀況,假裝自己是客戶,為了客戶設想了很多情境,做了很多優化,但客戶可能是完全沒有感覺的。這些投入的資源也都是無法產生效益的。比較好的方式是,做好假設後,一件一件事情進行並分別提供給客戶來給回饋,不要一次一整包功能。

  4. 以為敏捷方法就能夠作對的事情:如果沒有溝通或者溝通的方式不透明,只說明功能需求而不是說明想要提供給客戶的價值,最後產生的結果不會比較好。作產品可能有 70%~80% 的時間都是在溝通,如果是溝通不順暢,用敏捷方法並不會改善。

  5. 敏捷方式只注重客戶:這句話這樣講正確也不正確。例如架構的重構,最終仍然是影響客戶,因為重構後讓維護更簡單,因此能更快的提供價值。但這邊的價值可能比較不容易直接量化出來,這裡我建議可以參考之前分享的《提供目標客群最大價值》。

敏捷宣言

因此,敏捷軟體開發的價值觀,可以用敏捷宣言1來總括:

個人與互動 重於 流程與工具 
可用的軟體 重於 詳盡的文件 
與客戶合作 重於 合約協商  
 回應變化 重於 遵循計劃  

敏捷的方法是用來讓以上的價值觀更容易被實踐,若團隊已經信仰並在日常工作中實踐這樣的價值觀,無論有沒有用 Scrum(或看板或任何敏捷的 buzzword),其實已經是敏捷團隊了。


接下來,固定每週一會推出一篇文章,如果你對技術管理也有興趣,歡迎按下面的按鈕來訂閱電子報喔!

1

並不是後者不重要,而是前者可以幫助團隊做出真正有用的東西(而不是合約上的東西)

Discussion about this podcast

技術管理觀點
技術管理觀點
關於技術管理的觀點