管事是技術管理的另一個一個專業項目，大部分的技術組織雖然有PM的角色，但技術管理者仍然會需要管理工作項目，尤其是跟技術相關的事項。管事的最後一個主題，想討論「敏捷思維」的概念。
近幾年敏捷的概念非常的熱門，到處都可以聽到各種「為什麼要敏捷」或是「導入敏捷的方法」。老闆可能會以為敏捷就是可以更快做出東西然後到市場上賣，然而當他聽到敏捷不能加快軟體開發速度的時候，又會覺得敏捷沒有用。
敏捷的心態
事實上，敏捷應該是一種心態。敏捷的心態是：我先來試試看，在試的過程中，再來調整與改善。而與敏捷相對的心態就是：我一定要有 ABCDEFGHI…… 這些功能後，才能推出市場。後者其實是我（在組織裡）還蠻常見到的心態。舉例來說：
我一定要有這個功能才能上線
我一定要有完整的規格書才能開發
我一定要有自動化的系統才能推廣
…族繁不及備載
矽谷的科技公司大多都是以敏捷的心態在做生意的。舉個例子來說，AirBnb 一開始是創辦人看到舊金山辦展覽的時候，旅館房間一位難求，因此他試著將他自己的房間放上網路，用氣墊床的方式分享給其他人，藉此收了第一筆租金。這個方式完全不自動化，甚至也沒有網路的付款方式，一且都是現金交易，但經過多次的迭代後，成為了現在市值 1000 億美金的生意。
因此，敏捷並不能讓 ABCDEFGHI…… 這些功能一夜之間就完成，但可以先提供核心價值讓客戶使用，獲取客戶回饋後，持續迭代改善。
什麼「不是」敏捷
在我的經驗中，跑敏捷的團隊會歪掉，通常是因為誤解了敏捷的意義：
以為跑 Scrum 就是敏捷，花了很多時間開 Scrum 的會議，而心態上仍然是要一包功能都完整後才開始面對市場。
如果真的要一包功能完整後才開始面對市場，用瀑布式的開發會更適合，但相對看到的可能問題是這個產品可能沒有核心價值，跟市面上競品差異不大，才會導致需要一整包功能都完成之後才能面對市場。當遇到這樣的狀況時，可能需要重新從商業模式畫布上，討論提供給客戶的核心價值。團隊溝通上不以客戶回饋、數據作為支撐：即使每天有站立會議、用看法方法來管理，但執行的方法仍然是以「簡單好作」或「團隊想法」為優先，當產品推出市場的時候，一旦客戶不買單，則整個產品就需要作大幅度的修改，之前所有投入的資源都無法產生效益，這也不是敏捷的作法。
客戶沒有回饋之前就調整：常見的 OverDesign 狀況，假裝自己是客戶，為了客戶設想了很多情境，做了很多優化，但客戶可能是完全沒有感覺的。這些投入的資源也都是無法產生效益的。比較好的方式是，做好假設後，一件一件事情進行並分別提供給客戶來給回饋，不要一次一整包功能。
以為敏捷方法就能夠作對的事情：如果沒有溝通或者溝通的方式不透明，只說明功能需求而不是說明想要提供給客戶的價值，最後產生的結果不會比較好。作產品可能有 70%~80% 的時間都是在溝通，如果是溝通不順暢，用敏捷方法並不會改善。
敏捷方式只注重客戶：這句話這樣講正確也不正確。例如架構的重構，最終仍然是影響客戶，因為重構後讓維護更簡單，因此能更快的提供價值。但這邊的價值可能比較不容易直接量化出來，這裡我建議可以參考之前分享的《提供目標客群最大價值》。
敏捷宣言
因此，敏捷軟體開發的價值觀，可以用敏捷宣言1來總括：
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
敏捷的方法是用來讓以上的價值觀更容易被實踐，若團隊已經信仰並在日常工作中實踐這樣的價值觀，無論有沒有用 Scrum（或看板或任何敏捷的 buzzword），其實已經是敏捷團隊了。
接下來，固定每週一會推出一篇文章，如果你對技術管理也有興趣，歡迎按下面的按鈕來訂閱電子報喔！
並不是後者不重要，而是前者可以幫助團隊做出真正有用的東西（而不是合約上的東西）
技術管理之二(6)：敏捷思維