越看越像

Sept. 05 17:40~19:05

 

這一陣子因為和APP跨界交流協會、台灣創意設計中心、ezScrum團隊合辦了「我們都是設計師：跨界敏捷工作坊」活動，所以花了點時間讀了幾本和「創新」、「設計思考」有關的書，也把Agile UX Design和敏捷遊戲開發給複習了一下。Christopher Alexander在《The Oregon Experiment》這本書裡面，也提到了一種「跨界開發」的模式，雖然跨界開發的標的物是建築，但是也很有參考價值（Teddy一直認為，Alexander的很多做法，後來都可以在敏捷方法中看到類似的影子。所以把Alexander的模式理論學好，對於軟體開發與設計有著無形但是莫大的幫助）。這些知識，目前在Teddy的腦海中，都還屬於獨立的孤島，要說這幾座島之間有通道，恐怕也只是「流籠」或是「索橋」這種危險的交通工具。隨著跨界活動的舉辦，慢慢地經過一段時間的沉澱之後，應該可以把這些東西全部參混在一起在做成幾座「跨海大橋」…XD。

在跨界的目的之下看了這堆書之後，慢慢覺得敏捷精神不只在軟體開發上有用，對於產品與服務的創新設計也適用（也許這是各種不同領域互相影響的結果，大家互相學來學去，到後來也分不清楚誰學誰）。Teddy在《決定未來的10種人（The Ten Faces of Innovation）》這本書裡面，就看到很多和敏捷方法類似的作法。例如：

• 用最低成本的方式快速做出prototype （這一點應該在各行各業都適用）。
• 組織跨職能的團隊。
• 強調fail fast以及從錯誤中學習（失敗越多，成功越快）。
• 培養企業具備持續改善與創新的文化。
• 提供客戶真正需要的東西。
• 開放的心胸與願意合作的態度。
• Inspection和adaptation。
• Simple design。

***

鄉民甲：那又怎樣？

在教導創新思考的書籍中，比較強調「發想」、「如何觀察使用者」、「如何設計出創新的解決方案（可能是新產品、流程改善、使用者經驗提升）」。Teddy姑且把這些全部歸類為「需求（問題）分析」。如同《決定未來的10種人》這本書所說的：「我們公司跟客戶的公司一樣，解決問題的高手多如過江之鯽。但你必須先知道問題是什麼，才能談解決。」

在敏捷開發中（廣義的說，所有的軟體開發），也談需求分析，但往往卻比較偏向「技術面」的問題。例如：

• 需求要用什麼形式撰寫。Use case、scenario，還是story？
• 如何管理需求的相依性？
• 每一條需求之間的關係是什麼？（想到 use case  之間的包含、擴充關係，就頭大…Orz）。
• Traceability的問題。
• 等等等…XD。

當然做軟體的人也談「如何才能得到使用者真正的需求」，但是對於「如何用比較創新的角度，來思考使用者所遭遇的問題」這方面就談的比較少。

鄉民甲：然後呢？

但是做軟體的人，對於如何把需求做出來的「過程（流程）」，就談得比較多。所以如果可以結合「創意發想方法」再加上敏捷開發法的實務做法與快速回饋以及持續改善的精神，這樣應該有機會把整個產品或是服務開發流程（暫時還是先以軟體開發為主）串接起來（從問題發想到交貨）。

***

至於使用者經驗（介面）設計師要如何與軟體工程師在Scrum框架下合作，這禮拜六就知道了…XD。

***

友藏內心獨白：為什麼人類學家的照片，旁邊一定要站著黑人呢？