Ruddy Lee 分享空間

Emergent Design 演化設計

Posts Tagged ‘系統思維

聚焦使用者價值為核心原則的系統思維

leave a comment »

.系統思維_systemThinking.png

以使用者價值為核心的系統思維

.

聚焦於專案開發的敏捷只是部份的敏捷

早期的敏捷化把重點整個放在專案的開發上頭,一直到 DevOps 的出現才喚醒大家的全貌性考量;其實產品不是只有開發階段需要關注,開發完成後還有維運(對敏捷而言似乎沒有開發完畢這回事)工作,再往前看去則是產品部門所負責的產品定義問題(也就是需求的產出、排序)。另外;從市場的角度來看,就是從新創公司的層面來看產品開發,早期是以獲取最高利潤的產品設計為導向 ,現在則是以使用者為導向的需求規劃與開發。聚合這二種理念便成了一種以「聚焦使用者價值為核心原則的系統思維」。上圖中,若以系統思維全面化的考量來看DevOps的話,似乎還少了「產品定義」及「業務規劃」的部份才稱的上是真正的敏捷化。所以企業在實行敏捷化的時候,若是我們仍然只以開發部門或維運部門來進行改革而不是讓整個企業都運行敏捷的話,便會落入了所謂的Water-Scrum-Fall的部份敏捷化,而結果便是業者經常質疑的:『為何我已經實施這麼久的敏捷化了,卻沒有太大的成果呢?

.

看見全貌

看見全貌是個抽象的東西,以系統思維來作詮釋時,其實我們是自己先設定了系統的邊界,才去試著看到它的全貌,是先預設了立場才去追尋全貌的,事實上系統是沒有邊界的,那又那來的全貌呢?一切都是我們自以為是的。因此我們在探索全貌時必需先設定問題(先將解決的問題系統化),接著再讓問題的範圍去形成自然的邊界,然後試著看到所要分析問題的全貌,如此而已。

.

》系統本無邊界,邊界是我們自以爲是的。所以進行系統思維時,需要先給「問題」,讓問題去形成自然的邊界。然後再視我們的需求來調整「問題」。聽起來很繞舌,但這不就是持續改善嗎!(這就是左上角系統思維後面那個提問的符號所要表示的)

 

繼續閱讀文章 »

廣告

Written by ruddyllee

2017 年 12 月 05 日 at 22:11:00

實踐 DevOps 三步工作法的金幣理論

leave a comment »

.

金幣應該放在高業務價值的專案或是高優先順序的需求上。

當業務價值大於開發工作時,大家都會很高興;

當業務價值低於開發工作時,開發部門就會受到責難。

– 金幣理論

.

 

金幣.png

金幣理論的運作圖示

.

金幣理論 – 讓你善用資源的解題方案

基於供需問題的前提考量下,並為了將DevOps三步工作法實踐在真實世界的軟體公司裡,思考運用玩遊戲時最常接收到的即時回饋方式,也就是金幣的方式來描述整個企業在產品營運開發的資源(就是金幣)上,如何善用資源的運作方式。具體說明如下: 企業在由業務部門聆聽到市場及用戶的心聲後,向業主爭取資源,由企業決定要投入多少資源來進行產品的開發投資,業務部門將從市場獲取的概念搭配足夠的資源委託專門作需求設計的產品部門去設計產品的功能,讓抽象的產品概念逐漸擁有較清晰的輪廓,接著產品部門再將資源分配給開發部門進行需求的溝通以進行開發作業的研發行為,開發部門接著投入開發人力來製作出可供市場接受的產品的開發作業後,再交由維運部門來配置給客戶使用,隨後再經由客戶取得產品使用後的回饋,透過市場傳遞回給企業,使得企業在獲取市場訊息、學得經驗及獲得利潤後,重新運用資源將所學到的經驗,再投入到產品開發的改善及設計上而形成一種持續改善的循環。

.

什麼時候用金幣理論呢?

》當PO/PM不願意區分需求的優先順序時;

》當開發部門人力不足,但PM確堅持所有專案都一樣重要的時候;

這個時候;給他比需求數目大1的金幣數,讓他無法平均分配,或是給他二倍數目再加一的金幣數,請他把金幣放在專案或需求前,代表投入的資源多寡,此時優先順序就出來了!

.

金幣理論.png

金幣理論運作模式

.

為什麼用金幣呢?

這是為了替專案區分優先級別、為需求制訂優先順序的作法。例如: 有三個專案需要同時進行的時候,而你手上握有四枚金幣,不可能作平均式的分配,此時決定孰重孰輕、該多做投資在哪一個專案,便成了必然要作的抉擇,完整不可切割的金幣成就了這種自然形成的強迫性抉擇(透過衡量的抉擇),目的是要求專案的執行者能夠對專案進行衡量的作業,而不是盲目地作資源的平均分配。由於金幣是完整的不可再作細化的,這樣規定可以避免專案執行者將所有專案都一視同仁的錯誤作法(就如同PO將所有的需求都設定成相同的重要性一般,這是最糟的抉擇)。

 

不是開發的太慢,而是產出的業務價值不夠高

科技進步的實在太快了,越來越少有團隊在開發速度上受到肯定的。當開發團隊遭到抱怨開發速度太慢的時候,管理階層通常首先會想到的便是增加人手,用加人來解決產品部門及業務部門的埋怨,這個現象幾乎已經是擁有開發團隊企業的常態。但加人的措施真的能解決開發速度太慢的問題嗎? 這一點請參考《人月神話》書裏頭所謂的沒有銀子彈的理論(註2)。

 

{書名所謂的「人月」(man-month),是指在做管理專案時,用來計算投入的人力時間的單位(或「人年」),一個人做一個月,就是一個人月。而人月的計算方式實在是一種迷失,因為人月是不能用線性的方式來計算的。例如: 專案落後了三個月,那麼找一個人來補進去,是不是三個月後就能追上進度了。哪麼假設找三個人進來加入專案,是不是一個月就能趕上進度了,順理推論是不是找10個人來加入專案 3天以後就可以追上進度了。《人月神話》的作者Brooks正是要糾正大家這種用人月來計算專案進度的迷失,議題是: 專案來不及了,增加人手有沒有用。}

 

供需的問題 Supply and Demand

當想要開發完成的需求多過現有人力資源所能完成的工作,這個時候便出現供需不平衡的問題了。我們用存量與流量(stock and flow)的系統水管圖示來簡化所要描述的供需問題。

存量.png

簡化供需問題的流量與存量圖示

.

供給和需求是一個經濟學模型,它被應用作決定市場均衡價格和均衡產量。需求指大眾因需要一件產品而產生的購買要求;而供應就指企業響應大眾的購買需求而提供的產品供給。如果以系統思維來分析上面圖示,當水龍頭注入的水量與塞子漏水的流量趨於一致時,就達到了一種系統平衡的現象。

 

企業經營的目的在追求利潤

企業經營的目的在追求利潤,所以這個供需系統不在平衡,而是在追求更大的相對利益,因此專案開發的速度跟數量並不是最關鍵的因素,開發的產品對使用者是否具有高的使用價值才是重點,也就是說;開發部門應該以開發高業務價值的產品為圭臬,相對的開發的需求必須具有較高的業務價值才值得去開發。在這個DevOps 興起的時代,追求快速開發成了顯學,大家都被這一波快速成長的科技潮流壓得喘不過氣來,幾乎所有開發部門都被埋怨開發速度太慢,但實質上是我們開發的業務價值不夠高所致,是業務的方向需要正確,是產品需要真正具有競爭力,是開發團隊是否能及時讓產品上架才是問題,這是一個環環相扣的系統。這是一場團隊的競賽,而不是單一部門是否能盡到它們的職責所致。因此當我們在埋怨開發速度不良的時候,應該以系統思維的角度去觀察市場的全貌,運用數據收集與智能化來協助我們探索全貌,這也正是DevOps開始第一步強調系統思維的目的。

 

這裡談「供需理論」是為了取捨

我們都知道拍照時,你不能把全景都拍下來,那樣就完全沒有焦點了,你必需有所取捨,用局部來代表全部。把當下要傳達的故事聚焦化,先懂得捨才能取(所以拍照常常被稱為減法的行為)。專案開發也是如此,開發團隊的人力資源往往是固定的,但業務單位總是提出一大堆想要的需求,問它們的重要性,回答常是都重要。該如何做抉擇呢? 敏捷的精神告訴我們,以小的增量作依據,運用小迭代來換取經驗然後持續修正它,在資源固定的情境下當然是務實的選擇有把握而投資報酬率又較高的項目來做抉擇,在取得客戶足夠的滿意度後終止開發作業,而不是把所有的需求都作完,相反的;敏捷開發是遺留下來越多需求時則表現得越敏捷。

 

試著回想一下,我們在玩電動遊戲的時候,過關則獲得金幣(還有哪令人聽得興奮不已的音效)回饋,沒過關則可能被消滅必須重新來過。試想我們是怎麼過關的,即便是電玩高手也往往要透過失敗來獲取經驗,習得改進的策略後再來通關。所以經由實驗改進策略來獲取勝利似乎是玩電玩再單純不過的原則了。在玩電玩的時候;通常的結局都是明確的,回饋更是立即的,所以我們可以很快的學到訣竅,很快的就能再試一次,學到技巧了自然能夠過關,所以我們願意一玩再玩,即便是明明知道
沒有戰勝遊戲的機會,但是這種樂趣就已經足以支撐我們玩上幾個小時不會放棄了。軟體開發則有著異曲通功之妙,只是真實世界裡的成敗與回饋都來的好慢,時間延遲的效應無處不在,很少能有快速又明確的回饋現象,但這並不代表我們就不能依樣畫葫蘆。敏捷開發的做法是採用小作小錯的學習模式,運用小的增量來減少花大功夫,然後依循著小的迭代時間,來快速的學到經驗,採用務實而持續的改善模式來達到終點。每一次的小迭代都會換來一次的抉擇,你都在做取捨,你也都有重新修訂方向的機會,你要盡快弄清楚方向,並做好抉擇。這一點是 DevOps 理論出現後,最被在意的一件事,也就是說快不是唯一重要的事,方向要對了快才有意義。換成軟體開發來說;需求的業務價值要夠高,真正滿足了用戶的需求才是開發的重點,開發團隊做得在快、完成再多需求,如果沒有滿足到用戶的需求,一樣意義不大。

 

三步金幣理論.png

金幣理論是用來實踐三步工作法

.

結論

金幣理論是看著資源不足的開發團隊,卻把所有專案視成一樣重要的行為,所激發出來的處理方法。人們習慣均勻的去分配資源,沒有通過數據化的衡量來做為決策時的依據,但在真實世界裡;幾乎所有的事情都具有優先順序,只是我們偷懶了,沒有去收集數據就直接做決策,犯了胡亂猜測的錯誤,試想;今天如果有三個專案,但我們有四個金幣可以使用來提供支配資源的時候,依照過去的習慣,我們在每一個專案都押下一枚金幣,試問多出來的一枚金幣要給誰呢? 我們是要依據業務場景跟開發週期來作判斷呢? 還是依據專案對企業的重要性來作抉擇呢?不管你做什麼樣的決定,該依據什麼準則來做衡量的標準,應該才是重點。前提是任何衡量總比不作衡量就直接以平均分配的方式來得合理。基於這個理由,所以我才會想到金幣理論。其實使用點數或百分比也可以進行重要性的區分,但獨獨金幣具有不可分性,所以才會逼得你去衡量,再依靠衡量後的數據作較合理的抉擇。這是產品經理人該學會的技能,衡量(3.)

 

想解決的問題

金幣理論的目的在解決長期以來專案及需求被視為一樣重要的問題。設法觸發專案及需求進行數據收集式的衡量行為。簡化企業在部門與部門之間的供需問題。做到符合DevOps 的放大回饋訊息,加強單項工作的意義。促進三步工作法的第三步、加速實驗、學習持續改善的迴路。

 .

所有的需求都一樣重要?所有的專案都一樣重要?

問題不在專案或需求是否一樣重要,而是在有限的資源下,我們該如何善用。

.

拍照

將專案開發與拍照相提並論

.

註1. 典型系統中使用的特性/功能

只有20%的功能是使用者經常會使用到的,有將近 45%的功能用戶一被子也不會用到。

2. 《人月神話》書裏頭所謂的沒有銀子彈的理論

The Mythical Man-Month: Essays on Software Engineering是由IBM System/360系統之父佛瑞德·布魯克斯所著經典文集。

沒有銀子彈是布魯克斯所出的經典論文集之一。

3. 參考 如何衡量萬事萬物作者: Douglas W. Hubbard

.

Written by ruddyllee

2017 年 11 月 29 日 at 09:34:02

看板的系統思維

leave a comment »

.

DevOpsDays 2017 Taipei 演講資料

.

看板的危機

當看板貫穿在各個理論之間時,不禁讓我們擔心容易被誤導的全貌。

.

系統思維 就是把認識對象作為系統,從系統和要素、要素和要素、系統和環境的相互聯繫、相互作用中綜合地考察認識對象的一種思維方法。系統思維以系統論為思維基本模式的思維形態,它不同於創造思維或形象思維等本能思維形態。系統思維能極大地簡化人們對事物的認知,給我們帶來整體觀。

–        Wiki

當你看不見全貌時,就容易;講不明白、說不清楚,然後學習的時候快不起來。

 

看板為什需要有系統思維?

實踐看板可以讓你看得見流程,讓你看見了自己原來在工作上有這麼多浪費,但其實它是排除了許多細節資訊,讓你的目光能專注在大的工作事項上。這是一種消除浪費的方式,也就是所謂的看見浪費,就能消除浪費。但其實讓你能看見限制才是它真正的目的(要在透過分析前置時間來捕抓最大產能)。但這麼做是有風險的,因為看板太容易讓人落入線性的思維方式了

 

舉個例子; 當我們看到專案在時程上有來不及的現象時,你很容易就會想那就多放幾個工程師進去,就能多吃幾張工作單(Tasks)到開發的欄位裡去了,這樣開發的速度不就能相對的變快了嗎? 這便是一種單純的線性思維方式,一種「基於一分耕耘,一分收獲的思維」方式,那二分耕耘是不是就應該有二分收獲了呢?如果你這麼想;你就會認為解答就是多投入幾個人力來消化工作單不就成了嗎。但這是一種錯誤的做法!

 

請務必變換個思維方式,因為在真實的世界裡,產能是不能用等值累加的方式來計算的。事實是;當你增加人手時;產能反而會因為增加人手的初期先行下降(因為新加入的人員需要透過時間來學習才能像其他人有所產能,在這段新人需要熟悉環境、學習新技能的時間裡 (所謂的;前置時間) 你反而必須浪費最熟這個系統的人來擔任老師,負責教會新手,因此初期產能反而會不升反降),產能要經過一段時間後產可能上升。

 

 .

 

專案來不及時,不要急著增加人手,先弄清楚真正的問題點在哪?

–        人月神話

 

因果回饋圖 + 提問

問對問題可以提供我們正確的思維路線,也能夠觸發自己反思的機會。無疑的;它會讓我們看得、想得更清楚。但;我們要如何來避免落入線性思維呢? 系統動力學之父 Jay Forrest 為此發明了因果回饋圖(CLD: Casual feedback Loop Diagram)來解決這個問題。

 

運用正向因果回饋圖來判定系統的滾雪球效應。用負向或稱之為平衡回饋圖來判定造成系統平衡的因果元素。再加上時間延遲的考量因素,讓我們得以分析並思考問題的解決模式。這便是採用因果回饋圖模式來進行系統思維的分析工作。

.

解題前應該作的系統思維

我作顧問的時候,經常會駐足在團隊後方,遠遠的看著他們進行站立會議。一旁也偶而會有主管來詢問,這麼作的目的。不走近的原因是表達對 Scrum Master 的信任,而採用遠觀的目的則是想更客觀的來思考一些問題。因為看板很容易讓人落入線性思維,因此想再退一步來查看全貌。通常我在想的是…

》是否別被表象所迷惑了

   跟自己說,看到的只是冰山的一角,宛如薩提爾女士的冰山理論所言,人們被觀察到的外部行為,只是冰山浮出水面的一小部份,隱含在水面下的才是內在的應對、情緒、觀點、期待、渴望及真正的自我。而系統思維最有意思的一部分便是他會隨著時間變化而有所改變,他可能成長、停滯、衰退、震盪甚至隨機的改變進化。因此時時的收集資訊,鑑古知今,便成了探索系統結構的基本動作,現在的人都稱這種行為為大數據分析。

》在非線性的世界裡,不要用線性的思維模式

   這是我們依據看板來做決策時最容易陷入的麻煩之一,就是用一種線性的思考模式來研判問題,例如:在土壤裡施100磅肥料,收成可增加10斗;如果施加200磅肥料,收成是不是可以增加20斗呢? 那,300磅肥料,收成便可增加為 30斗呢? 結論當然不是這麼回事。真的這麼做了,甚至可能會徹底破壞土壤的有機質,以至於什麼再也長不出來了! 在真實世界裡,事情往往是多方牽連的,也就是非線性關係的,也就是說我們必須用因果關係來推論反饋的原因和現象。此時;好的提問以及採用因果回饋圖可能是避開線性思維的最佳方法。

》恰當的劃定邊界

   有所取捨,確實最複雜的地方經常都會出現在邊界上,但這些個邊界其實都是人為的定義,是我們將系統硬做區分的,這是簡化的來源也是基礎,看板便是這樣的一個系統,我們簡化了許多資訊,讓實體看板可以剛剛好顯示足夠的訊息,這樣做可以讓我們看得更清楚,但也預作了假設,因此必須恰當的劃定邊界。

 

》看清各種限制因素

   我們通常以單一的原因會引發單一的事件來進行思考。現在這個問題,可能就是先前我們那樣做所引發的後果。這是我們眼界的淺短性所致,但是現實的生活裡,往往是多個原因一同引發多個結果的複雜現象,因此挑選相關因子並做好衡量的工作,就成了決策成敗的一大依據了。這一點在近代的AI人工智能上也可能會有重大突破。但前題依然是我們要掌握正確的因素,才足以問對問題,否則再好的人工智能也很難給出好的回答。

》無所不在的時間延遲

    在系統中每個存量都是一個延遲,這是我在凝視看板時最害怕的一件事了,那便是「時間延遲」,在真實世界裡處處都是時間延遲,延遲時間的長短可以徹底的改變整個系統的表現。但我們在看板上因為它無法受控制,所以通常只是輕易的給上「紅、黃、綠燈」來做依據判斷便是了,因為它可能帶來風險,所以Mark 它是一個風險,實在是一種神話級的處理方式。進行「衡量」可能是較好的一種處理方式(因為這樣便有了機率的依據了)。但究竟該或不該花時間去做衡量可能才是關鍵的困難點。

 

》有限理性

   我們都想做出理性的好決策,但先期的決策,不說你也知道它隱含著大量的不確定性,因此通常可以稱它為猜測。因此盡量的收集資訊,做到自以為合理的決策便成了努力要達成的目標。敏捷Agile在處裡這個問題的方法是迭代持續改善,若能越改越好自然可以逐漸趨近目標,反之;則應該討論是否是認知太貧乏了,便需要一種跳脫的思維模式來支撐了。

 

結論

系統思維的目的是在透過對系統進行分析之後,依靠尋找到的槓桿點來進行事半功倍的解題

.

槓桿點.png

.

作為一位專業的顧問,經常是在開發團隊出狀況的情況下才被請來解決難題的。人們總以為顧問是請來解決問題的,但實質上;身為一位資深顧問,必須跟你們說:「顧問只是請來讓問題比較容易被解決的」。也就是說;真正解題的人還是要靠你們自己,顧問只是用較客觀的角度,用經驗來協助大家解題罷了。而我們經常的解題方式,便是去尋找問題系統的「槓桿點。一種讓我們能夠正確的施力,並換來巨大成效的做法罷了! 其實任何組織平常就應該培養這種解題的能力。上圖是我的建議,最重要的三點是: 1)制定簡單的規範,讓團隊經常做到自我管理,2)形成一個自組織的團隊,3)並善用交互及外來的回饋。讓訊息能夠快速地在組織內流動,它便能經常可以化大問題成為小問題,讓小問題成為生活的插曲罷了。

 

 

.

Written by ruddyllee

2017 年 09 月 03 日 at 18:12:17

看板的系統思維

leave a comment »

.

TOC

.

看板的 why

.

看板的 System Thinking.png

.

devOps 看板

.

Kanban 知識體系 _1.png

.

系統思維

.

系統三要素

.

6 障礙

.

對待

.

衡量看板.png

.

AI 問對問題.png

.

決策看板

.

幹桿點.png

.

衡量說明

.

 

 

Written by ruddyllee

2017 年 06 月 22 日 at 10:19:53