Ruddy Lee 分享空間

Emergent Design 演化設計

看見的力量 – (I) 解題的思維

with one comment

這篇文章;已經梗了我三個多星期了。這期間飛了二次大陸做演講、往返幾個大城市做教授敏捷開發運用在精實創業的課程。教材內容都是簡體的,它們始終沒有機會在國內用上,心理常想著;無論如何我都要把它們翻成繁體中文,雖然國內沒有人找我講這個課程,沒關係。就把它登在大眾媒體,跟大家分享。(哈哈! 寫了幾回草稿,但旅行中杭州的雲霧繚繞還有茶香美景並沒有幫上忙,文章架構依然凌亂,倒不是沒有頭緒而是頭緒太多。最後我決定改用分段的方式來跟大家分享,希望你能接受。)

 

看見的利器

※「看板方法」Kanban Method
可以讓我們看到工作流程,然後依據半成品的理論來持續改善、管理流程。

※「使用者故事地圖」User Story Mapping
可以幫助我們階層化使用者故事並整理出需求的全貌,讓我們知道該從哪裡開始來解題、動手實做專案。

※「影響地圖」Impact Mapping
可以把業務目標跟產品功能串接起來,然後讓客戶、分析師及開發團隊都能看見撰寫的產品功能對業務的影響在哪裡。

好了;這一系列文章就是在談上面這三個東西,三個可以協助我們看清楚需求的工具(方法)。標題似乎可以改寫成: 如何運用這些方法來看見需求的本質。而想談的問題是;藉助視覺化 Visualize的力量來解決專案開發時需求變來變去的困擾。用一張圖示,來說明這幾個工具的運用時機。(一下子;輕輕鬆鬆便可以畫完的圖,但改用文字來描述起來還真是有一點麻煩。我想用如何思維解題,到過程的描述分析,然後在對應到想要完成的目標,最後是拿來輔助的工具來探索它。順序就是依照下圖最左側的那一行【思維 – 過程 – 對象 – 工具】)作為一系列文章的起頭。

 

0 視覺化產品開發中的價值

(Slideshare 上的完整 pptx: 產品開發中的價值)

第一排思維的方式

由「極度抽象」到「抽象」再到「明確」最後寫成程式碼,達到「極度明確」的解題方式。

這是我慣用的一種解題方法。解題;一開始;要先後退個幾步,讓自己跟問題物件的距離先拉遠一點,減少一些訊息數量的干擾,讓自己的視野再加大一些,能看得更全面一點。目的是;設法看見全貌。這可是自己花了好多年的時間才糾正過來的習慣,避免患了一看到問題就急著思考如何解題的習慣,就是俗稱的「工程師的視野」。

 

在抽象與明確之間徘徊解題  –持續優化

想辦法先看到。當你經常受到需求改來改去的殘害時,最好的解決方法便是讓它提前優化,運用paper prototype 或其他成本較低的方式先行對問題的解答進行驗證,針對產品功能是否解決了真正的業務需求進行模擬或假設式的確認。我習慣在這裡來回穿梭,寧可多花一些時間在抽象與明確之間徘徊,也不願意太快進入程式的撰寫階段(你可以先做未來展示時會用的PPT,或就手頭的需求先整理一些Spec,不要急著收斂),這倒不是在逃避寫程式,而是擔心一旦開始寫了些程式碼,要回過頭修正假設錯誤的地方,就要多花一些功夫在修正程式邏輯上頭,這要賠上許多時間,有些划不來。而且程式一旦改來改去,總讓人覺得好像有一種壞味道油然而生(有些不衛生,不幹淨的感覺),還是慢慢來,一次做對比較乾淨舒服些。

 

倒推的方式是最常用的手法。也就是所謂的從最後開始(Start at the End)。先想像你已經完成文件上所陳述的功能了,然後回過頭來看看問題是否真的被解決了嗎? 試著問自己;使用者因此就可以如同用戶故事上所描述的「因為獲得了他想要的功能,從此以後便能獲得這樣的利益了」。(當然,用影響地圖在這裡最為受用,請容我下次再補做說明)

針對較頭痛的問題,我通常會採用寄信給自己的方式,用email藉由時空的延遲隔離,來和自己交談(一種自己給自己的回饋方式),用說交談的方式來進行自我回饋,用這種稍稍客觀的形式來提醒自己,讓時間帶來多一點的資訊獲得,也就是依靠延遲決策的方式(Decide as Late as Possible),讓思維更為成熟一些(哈哈!很難說這種方式會有用,但一經養成習慣,心態便會穩定需多)。

 

明確到極度明確

第一步;先確認文件規格是正確的。我習慣先整理足夠用來做coding用的文件規格(可以用測試案例(Testcase)或是單元測試來當作文件),先把測試的方案開起來做好命名,最後才是建立主程式專案,這裡才是接下來的戰場,這種方式有人就認為是TDD了,但我實際上只是要透過預做準備的動作,來多思考一次也就是擊發二次思維(2nd thought)的動作而已。接著才是興高采烈的進入coding 階段。期許自己能夠一次做對,讓coding 變得更有趣,讓code變得越簡單越好(偵錯)。

 

小結

針對上圖所示,我們先談第一排、所謂的「解題的思維」。解題;它沒有標準,上面是我長期以來一直依據的Mary shaw 抽象解題法的使用心得。提供大家做參考,下一篇就會開始描述處理需求的「影響地圖 impact Mapping」。會這麼做,是害怕自己沒有足夠的時間做長篇大論,就以這種分段描述的方式,盡量抽空來做作功課了。

 

Written by ruddyllee

2016 年 03 月 25 日 於 11:38:01

一個回應

Subscribe to comments with RSS.

  1. […] 本文转自台湾李智桦老师的博客,原文地址 […]


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: