看見全貌

.

專案開始之初,首重看見全貌。

一旦;當你把眼光投注在哪一個要項的時候,實際上你就只看到那一部分,你的思緒將被那一部分的內容所牽動,很難再看見其他的事…

所以我們要退後一步,

不! 有時要退後很多步,才能比較清晰地看見全貌。

(好有趣喔! 退遠了卻反而看得更清晰)

所以要調整範圍,試圖把我們在意的事放進視線可及之處,

淡淡的審視它,不帶一點情緒,就是這樣,我們看見了全貌。

.

開發團隊被抱怨開發速度太慢的案例層出不窮…

0054.png

軟體影響開發速度的因素

其實當你努力的去改善開發環境還有程式,祈求開發速度能夠跟上需求時,其實;還不如從提升需求的業務價值來著手改進會快上很多,請參考"需求分析的設計模式“一文。

.

一旦你看見全貌之後,要怎麼做呢? 

一種全貌.png

演講內容:  DevOps 教战守策:三步工作法 ,內容 PPT 的全貌( XPS展示)

首先;把它畫下來。畫下來不論對自己或閱讀的人都是一種極具價值的事。(上面81張slides的內容如下圖)

.

0002_8

將演講內容整理成 圖示 (演講: DevOps 教战守策:三步工作法 )

畫出來;可以具像化(產生 Avatar)的整理出資料的脈絡,告訴學員運用圖示來回憶上課的內容,當遇到有疑惑的地方時再去細看 PPT的內容會效果會更好。

.

see the whole
整理出來的心得

.

運用工具來協助你看見全貌

系統思維(麻省理工Jay Wright Forrester先生的 System Thinking)能夠協助你以CLD圖式較抽像的方式看見全貌。坊間流行的影響地圖(impact mapping, by: Gojko Adzic )是用來尋找影響路徑,還有著名的是用戶故事地圖(user story mapping, by: Jeff Pattorn 用來記錄陳列需求)則都是用來記錄分析需求的有用工具,但基本上還是屬基於以客戶為導向的開發工具, 這二者還是離不開描述個別客戶的情境示意圖,對看見全貌而言反到狹窄了視野,它記錄的是專案運行下的各個需求分類,已經自我設限而失去了真正的全貌,反倒能夠協助收斂思維便利施工作業,而非全貌探索。

 

.

註:

  • 拉遠原則 (Pulling principle) 

就是在更大的範圍內觀察事物。我們可以試著將一個產品放置在更大的背景環境中去考慮,這樣可以避免見樹不見林的現象。(例如: 坊間一些書籍的試讀軟體,就有這種效果。) 雖然我們這麼去觀察,但還是只看到它的外觀,好的作品,設計者的品味(taste) 卻還是能隱然呈現,尤其是那些優秀的產品。至於內涵的部分,就需要細細的去品味了。

.

發表迴響

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

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s