什麼是「敏捷思維」?
敏捷的議題這幾年來快速地興起，然而敏捷這觀念及方法不只是應用在軟體開發上，我們上期也提到了許多敏捷的跨界應用，如目前熱門的精實創業（Lean Start-up）、或上一期介紹的敏捷行銷（Agile Marketing）。雖然敏捷的好處很多，但若是你打算將敏捷開發的好處推廣給你的團隊、甚至完全沒聽過敏捷且非軟體背景的高階管理者，該如何做會比較有效呢？可先從敏捷思維的建立做起。
「敏捷思維」是一種mindset，一種認知，一種文化，它讓團隊成員對敏捷精神及作法有基本的認識，當團隊成員都有了較一致的想法，自然形成一個團隊文化。我們上次提到了一些敏捷開發的幾個重要精神及原則，本文我想特別說明這一點─「使用者參與並盡早取得回饋」，若能讓公司管理階層及團隊所有成員都能明白了解它的精神，並在每日的工作內容中不斷地提醒自己或團隊成員實踐，定能有事半功倍之效，自然就會培養團隊成員的敏捷思維了。
使用者參與並盡早取得回饋 – 如何培養以使用者為中心的思維
這點是大多數團隊常常忽略的，關在辦公室中「想像」 使用者的需求，或是由工程師的觀點，自己認為使用者要什麼，筆者提出幾種團隊可以練習的方法，這些作法很適合在團隊一開始要導入敏捷前，先讓全員都能上的訓練課程，你們可以在公司內部訓練時去演練，再逐步內化到每日的工作中，讓團隊成員能以使用者為中心的思維。
1.邀請真的使用者來說明使用產品的心得，然後多問為什麼
邀請真的使用者來現身說法，類似的作法有focus group，focus group的執行是比較花工夫的，但是在訓練課程時，可以讓使用者來說說使用產品的好及不好的經驗，在詢問時，盡可能多問為什麼，以下舉個例子：
產品經理：「請您自由地說說我們產品哪些地方設計得不好」
使用者會說：「我覺得這產品UI設計的不好用」
請馬上再問：「為什麼你覺得UI不好用？」
使用者回答：「這上面的選單容易按錯」
再追問：「為什麼容易按錯呢？」
使用者回答：「因為選單很密集，很容易按錯」
由上述例子你可以發現，多問為什麼，才能幫助你找到root cause，得到真正的insight，而不是表面的現象，這才有助於你後續的改善。
2.試著讓團隊成員輪流當客服
當產品上線或服務正式營運後，若初期能讓產品開發團隊成員輪流排班當客服，包括產品經理甚至 programmer，真實聽聽使用者對於產品的使用經驗，不論是好的，壞的，因為在第一線你會聽到真切的使用者遇到之問題，他們是如何操作你的產品，甚至也可以從對話過程中找出使用者真正的pain point，通常你會意想不到各種五花八門的答案，甚至有些是你們團隊從來沒想過的需求。
在一個大型的企業中，通常客服是由另一個部門來執行，雖然客服也會定期整理report給產品團隊以了解使用者回饋，但在於時效性較難即時，通常產品或服務剛開始營運，初期的使用者聲音是很重要的，再來若是報告的整理是由客服人員的角度所做出來的，可能已經過濾掉許多重要的資訊，你會因此喪失在產品營運初期有機會可以更敏捷地回應及改進，身為敏捷信仰者要不斷從feedback 中精進你的產品。
3.只產出對用戶有價值的東西，減少浪費
「浪費」在敏捷的精神及思維中蠻關鍵的，但浪費這個字眼在軟體開發上不是很容易從字面上理解，在此舉一些浪費的例子及可能的解法 （這沒有正確唯一解，視團隊狀況都有所不同）
「那些不能為用戶帶來價值的功能，但你們團隊還是把這個功能放上去了」。 可能解法 : 在時間及資源有限的狀況下，先做Priority最高的功能，而不是什麼都做。
「做了對使用者、開發團隊都沒有參考價值的文件或報表，只有你自己看再也沒有人看」。 可能解法：只做需要的文件／報表，該文件／報表最好還可以從系統自動動態產生。
「過度計畫 - 一個全新且還沒能很確定用戶需求的產品，身為PM的你還沒執行就花了三個月做一個漂亮的紙上報告」。 可能解法 : 先從小計畫開始，有了初步的計畫就可徵得stakeholder的支持，先行透過一個短循環試行你的小計畫，再行修正。
「半製品 – 花了三個月時間做了一個會動的prototyping，才發現沒人要」。 可能解法 : prototyping不一定要真的寫出來，也可以是畫出來的UI草圖、一個簡單的動畫可以向使用者說明產品概念。
「一個工程師花了不少時間寫了一個元件，最後發現有現成的API可以用」。 可能解法 : 在每日立會時，詢問同仁有無相關的實作經驗，以減少自行摸索時間。
身為敏捷團隊的成員，可透過每日立會時，隨時提醒大家，我們這樣做是不是一種浪費? 有沒有更好的作法? 透過這樣的反覆思考及互相提醒的默契，定能事半功倍並減少浪費。
4.建立可以持續且即時取得使用者回饋的機制
取得使用者回饋的方式很多種，以微軟的Visual Studio產品為例，我們在線上blog及使用者論壇（forum） 會收到許多使用者的使用問題，這類的問題收集會是一個很好的改版參考。
另外像微軟 User Voice 網站，會了解使用者最想要的功能，並開放給使用者來投票，票選最想要的功能，身為PM或是產品團隊成員會依據使用者回饋、優先順序及目前資源狀況，來決定下一個改版。
另外一點是，要讓使用者很容易地可以隨時反應問題或回饋，例如：Visual Studio 2013 版本，在使用的過程中有遇到問題，或是建議，可直接在功能選單中用文字的方式回報，也可讓使用者選擇是否自動貼上screenshot讓產品團隊了解使用產品發生問題當下的畫面，這些都是取得 user's feedback 的機制。
若是透過Focus Group定期取得使用者的回饋也是一種方法，當然這比較花時間，但若是一個新產品上市的產品定位設計，就是一個很好的方法取得代表性使用者的使用經驗。
培養敏捷的思維如何開始，本文僅說明「培養以使用者為中心的思維」，你們可以在公司內部訓練時去練習看看，進而融入在日常工作中，希望本文對你們的專案管理及產品開發工作有所幫助。