主管的敏捷工具 – 信任與責任模型

誠信

By: Niel Nickolaisen

.

命令與控制型文化

要帶領一群工程師最簡單的方式便是採取命令與控制的方式。從小學的時候開始,我們就被教導如果你做了幹部,就是要學會如何下命令讓同學們去完成工作。卻很少有導師會主動的教學生要如何的讓團隊負起責任來,自行完成工作,把該做的事做好,而不是只把自己該做的事做好。大家好像都忘了,各級幹部也是團隊選出來的,其實與團隊共進退的領導模式才是王道。因此我們從小就習慣於主管就是要負責發號司令的人,做主管就是學會如何發號司令,而且誤以為主管就該什麼都懂,而忽略了真正做事的是我們自己,而做得好壞就看自己怎麼做了,主管只是要負最後的責任罷了。

 

Niel Nickolaisen 覺得應該把信任與責任攤開來談,用視覺化的方式,才能讓大家更清楚的看到這種關係。因此運用了二維的圖示,縱軸(信任)領導或業務流程對團隊或員工的信任度,越高就是主管與團隊之間的信任度越高,越低就是主管採用命令式的控制模式越大。橫軸(責任)團隊或個人對工作所做出的承諾也就是自己認為對事情(工作/任務)的責任感與所有權。敏捷的團隊對任務工作的表現只有在團隊完全承諾下來時,透過盡心盡責的情境下才會擁有活力與創新的表現。上面那張圖太理想化了,下面這張圖比較像真實的世界,信任與責任往往都不會那麼明確的,尤其是四個象限的邊界應該總是模糊的,加上的虛線部分則是過去自己所顧問的團隊所必經的過程路徑(當然有很多團隊一直無法到達活力與創新的區塊,我們不能把責任完全歸咎於主管,但他們其實可以做得更好些,這也是本文的目的)。Niel 的視野並未侷限在專案開發,而是普遍指向主管與團隊之間的領導問題,這裡我的解釋則狹隘的偏向專案開發上。

 

  1. 失敗(藍色) : 指的是長官完全信任團隊,但團隊對自己的工作並沒有哪麼在意。這種現象通常是團隊對自己所開發的東西沒有認同感所致(對自己該做什麼一旦不夠了解時,便會如此),接到任務後認為成敗是主管或是公司的事,我只是奉命行事而已(工程師認為我已經盡力而為了),在這種情境下專案自然會有較高的失敗率,即便成功了效果也相當的侷限,而在與其他團隊協作時便常常會有穀倉效應的Silo現象出現。此時要從團隊培養對需求真正的認同感開始(在陳述需求時運用影響地圖Impact Mapping的工具可能是一種好的方法)。
  2. 命令與控制(黃色) : 長官由於擔心團隊無法自行完成任務,因此將所有權收回,放棄讓團隊自我組織,回到一個口令一個動作傳統的waterfall式的命令與控制狀態,等於正式宣告敏捷轉型失敗。如果團隊依然採用迭代式的開發方式,便是所謂的假敏捷(此時;由每日的站立會議就能觀察出來),此時除了開發效能不彰之外還會造成偏高的離職現象。常見的情境是公司聘請的敏捷顧問離開之後,接手的主管採用了自己熟悉的命令與控制模式來帶領團隊,便會將敏捷顧問所辛苦建立的自組織團隊打回原形。這是一種低信任與低責任感的工作環境,優秀的工程師當然不會有所眷戀而輕易求去。
  3. 衝突(紅色) : 低信任感與願意負責的團隊。團隊具有高度的責任感但容易與長官之間有不同的意見而常常引起爭執(衝突)的現象,這是自組織團隊的必經過程。一種現象便是Scrum Master 們經常請主管退後一步的原因,就是不希望團隊與主管之間產生衝突,並運用團隊逐漸加強的責任感,企圖用團隊的好表現來增加主管的信任感。當發生這種情境的時候,一般都不會真的產生劇烈的衝突現象,取而代之的是彼此偶而會互潑冷水或扯後腿的現象,這是彼此之間缺乏信任感所致(當主管有很多措施都沒跟下屬做解釋或進行充分溝通就自行發布的時候,就容易產生這種類似衝突的現象),起因是彼此不相信對方可以把工作做好,又覺得對方不夠敬業,因此即便團隊開發的很辛苦卻成效始終不彰。是一種團隊逐漸產生自組織的過渡期間,此時主管的誠意表現將決定團隊向上產生活力與頻增創意所能達到的境界。
  4. 活力與創新(綠色) : 命令與控制的現象完全消失,團隊以自組織的方式工作,只要在目標夠明確之下,團隊總是清楚自己應該怎麼做,主管也能充分信任團隊,團隊以致力於交付滿足客戶需求的價值為主,好的工作氛圍讓創意與活力頻頻出現,這個時候團隊將擁有最高的效能。表徵是: 工程師即便收到好的挖角Offer也不太會想要離開團隊。

.

誠信_real.png

邊緣模糊化了的信任與責任模型

圖上的虛線路徑代表了團隊在組織環境下的表現,許多互動的因素會左右誠信與責任模式,基本上它是動態、模糊而難以維持的,我們常說在現今這個 VUCA 的時代下,一切都在變,到底要如何來面對呢? 敏捷的文化認為我們可以運用迭代的方式來面對模糊性(Ambiguous),用行動與學習(Action Learning)來提升明性確性,至於不穩定性(Volatile) 則可以運用目標建結果OKR,以設定明確目標與關鍵結果來對應,至於複雜性(Complex) 才是我們帶領團隊時最難面對的問題,必須先建立起領導與團隊之間的誠信,然後在團隊能夠體會到責任與權利的義務時,再用自組織來克服內部的複雜性,使團隊產生足夠的自適應性來應對外部的複雜環境。

 

權力與自由的可貴

上圖中,左下角的命令與控制象限看起來是團隊效能處於最低的狀態要盡快脫離,應該用力實施各種改善措施來促使他做轉變,但 Niel 提醒我們,適當的控制模式可以讓團隊處於較高的穩定性狀態(團隊要處在穩定的狀態下,才容易轉型成功),因此當我們想讓團隊進化到右上象限時,適當的以命令的控制方式來進行操作反而最為有效,因為減少自由與權利反而會讓人們更去珍惜它。

.

工程師不夠敬業

在職場上普遍存在著主管們認為工程師沒有我敬業的想法。因為團隊總是在遇到棘手的問題時才向主管請救,這種情形很容易讓主管誤以為團隊缺乏責任感,其實大部分的時候,團隊只是抱著尊重大於解決問題的意味向長官請救,團隊也知道大可開個會一起思考如何解題就搞定了,但資深的成員總覺得此時應該尊重長官才是,畢竟如果我們搞砸了到頭來倒楣的人可是他。反之;

 

老闆應該都知道組織現在該做什麼

這種相互誤解的場景其實是溝通不良所造成的。員工總以為老闆應該隨時都知道組織現在該做什麼才對,但其實Toyota的精實文化很早就告訴我們了,現場的領班才是最清楚狀況的人,所以大部分的抉擇應該是當事人才最適合做決定的(前提當然是你要夠專業),而老闆所做的決定往往是較少的那一部分。反過來看;中階的主管自以為我什麼都懂,我知道該做些什麼。這才是最危險的事,信心滿滿是好事,但真相是只有第一線的工程師才知道所有的細節,若只憑過去的經驗作決定其實是一種錯誤,而他該做的則是發揮身為一個領導者該有的作用才是,而不是自以為是地借助以往的經驗來下指導棋。

.

解決誤解的方式,是建立一種主管與團隊之間的互信模式。

.

信任得來不易

主管與團隊之間的信任得來不易,尤其是在職場上更加困難,因為人們總是會戴著不同的面具去上班,深怕全然的坦承會帶來沒有必要的副作用。朋友之間也是如此,通常要一直到有了足夠的互動之後,才可能慢慢的建立彼此之間的互信。與主管之間的信任則是建立在誠意上頭,這是因為大部分的主管很難有機會和下屬產生互動,因此主管所展現的誠意則可取而代之,成為建立互信的基礎,雖然沒有友誼做支撐但依靠組織架構,也足以獲取某種程度上的信任了。子曰:「人而無信,不知其可也。」指的就是人若不講求信用,在社會上就無立足之地,什麼事情也做不成了。提供一個工具協助大家思考,那就是Niel Nickolaisen所發明的信任與責任模型(Trust – Ownership)。

.

責任.png

責任的內涵;簡單的說就是一個人有沒有擔當

.

結語

敏捷轉型實質上就是組織文化流程的改變。主管與團隊之間的誠信與責任劃分描繪出了團隊成長的路徑。敏捷宣言與原則則指導了流程上能夠符合敏捷的規範。如果想要擁有一個高效的開發團隊嗎? 就得先弄好領導與團隊之間的信任與責任關係。 Niel Nickolaisen 的信任與責任模型 Trust–Ownership,目的是;提供一個用來提升團隊效率的分析工具,進而避免本來是團隊責任範圍內的工作,反倒跑到主管身上去了,造成主管累的不行而團隊又被責怪沒有盡力。這個工具是屬於主管或領導階層的工具。主事者需要觀察目前團隊的現狀,試著評估自己對團隊的信任度與團隊在接收任務後所表現出來的負責程度,是落在哪一個區間,進而思考自己該採取什麼樣的作為來改善它。一本參考書《敏捷文化》The Agile Culture是 Pollyanna Pixton、Paul Gibson與 Niel Nickolaisen 2015 所合著,全書的基礎就是架構在「信任與責任模型」上頭 (youtube 上 作者的親自說明如下)。

.

交付工作是誠信的入口,務必先詢問再要求承諾,

強制交付日期的專案,則是誠信最好的破壞者。

.

廣告

卡普曼戲劇三角 – 心理學界的系統思維

.

如何一窺團隊成員的心理?

卡普曼戲劇三角.png

心理學界的系統分析法

.

卡普曼戲劇三角,首次發表於1968年,是一個用呈現人際互動溝通方式的理論模型,

由美國的精神病醫生斯提芬·卡普曼提出。

.

自組織團隊

我是在閱讀敏捷大師Mike Cohn解釋「自組織團隊」的文章時,為了追根究底,不慎落入心理學的範疇裡的,這期間我一直有一個疑惑,那就是「研究敏捷需要了解心理學嗎?」。Mike Cohn的文章裡提到二種協助形成自組織團隊的方法,一個是 CDE法 (CDE是Container容器 – Differences差異- Exchange交換,源自Glenda Eoyang的博士論文《Facilitating Organizational Change: Lessons from Complexity Science》)這是目前最被scrum master 們廣為採用的方法,另一是Philip Anderson 的企業演化七槓桿(在這裡《The Biology of business》這是JOHN HENRY CLIPPINGER與幾位作者共同出版的書,Philip Anderson負責第六章 Seven Levers for Guiding the Evolving Enterprise. 1999。

 

這段尋根的歷程有些漫長,但幸運的是我遇見了卡普曼戲劇三角這個心理學的系統思維工具,他被TA (人際關係理論之父 Eric Berne) 戲稱將會影響人際關係學200年的佳作,也讓我有機會盡速的從這段旅程跳脫出來,肯定的說研究敏捷是需要了解人際關係的。為了珍惜這段回憶,以下是自己做成的紀錄,如果你也有興趣走一遭的歡迎參考。

.

Whole story.png

.

我的心得是:『信任與責任才是團隊最大的武器。』

.

什麼是戲劇三角形

這個概念是來自於TA人際關係溝通分析學派的理論,認為在團體中的人際關係,(我們)會因為環境的因素被迫扮演成三種角色,分別是: 迫害者Victim受害者Persecutor以及拯救者Rescuer,而這樣的衝突關係會一再的發生,這三種角色也會經常替換。美國心理學家卡普曼正是運用這三個角色來解釋社會上各式各樣糾紛的形成方式。由於非常精準有趣因此被berne 戲稱為卡普曼戲劇三角,也因此而成為它的正式名稱。由於它可以拿來分析人際關係的紛爭原由,因此又被稱為心理學的系統思維。

.

敏捷最終也都是在處理人的問題.

.

卡普曼發現,每個人心中都經常會上演一個由三個角色構成的三角戲劇game:

  • 迫害者:貶低別人,把別人看得較低下、不好。
  • 拯救者:也是把別人看得較低下、不好,但他的方式是從較高的位置提供別人幫助,他相信「我必須幫助別人,因為他們不夠好,無法幫助自己。」
  • 受害者:則自認自己較低下、不好。有時受害者會尋求迫害者來眨抑自己,或是尋找拯救者提供幫助,而肯定自己「我無法靠自己來解決。

範例: 夫妻之間的卡普曼三角分析,場景是這樣的: 妳下班後接到先生電話,說要和幾個朋友吃飯喝酒,不回家吃飯了。你想到有幾張折價卷快要到期了,就說要去賣場買些東西,不去了。(註2.)

晚上九點多,你提著重重的一堆東西走出商場,給先生電話,想問他能不能來接你。聽電話裡傳出的聲音,那邊正喝得酣暢,顯然是接不了你了。這時候,天正下著雨,一時很難叫到車子,站在濛濛細雨中,你很生氣。一會兒氣他為什麼喝酒不能來接你,一會兒又氣自己為什麼這麼多年就是不肯自己學會開車。在這種種惡劣的心情中,折磨了自己一個多小時,直到上了一輛計程車。

計程車向前開著,車廂裡很安靜,你突然意識到類似的事情似乎發生了好幾次。比如,你明明知道這個時間在那個賣場周圍根本叫不到車,可是還是這個時間去了這個賣場,這樣折騰已經好幾回了。明明知道老公晚上會喝酒,接不了我,可還是抱著幻想給他打電話,這種情況也已經好幾回了。明明知道這樣做是自找麻煩,知道還是這麼去做,不是自討苦吃嗎?

在這件事情當中,當你很辛苦地提著一堆東西,站在雨中,渴望先生像平時一樣來接你,這時老公就被你當成那個幻想中的【拯救者】。而當他因為自己的事情不能來時,先是失望,繼而生氣,瞬間你就變成了【受害者】;而他在卡普曼三角戲劇中頓時變成了害你這麼沮喪這麼生氣的【迫害者】。

設想,接下來,如果回到家你繼續指責你老公,你就變成了一個【迫害者】;他如果很無辜很內疚,你可能又會感到過份而安慰他,搖身一變,你成了【拯救者】,而當他是一個受我情緒失控影響的【受害者】。

※ 上面的範例是一個人同時在三個角色中轉換,卡普曼的詮釋是在角色的轉換時會不經意地扮演成所謂的欺騙者的第四個角色。也就是說卡普曼三角最初是設計成四個角色的,後來畫的時候把欺騙者的角色用箭頭取代了。這也就是說當人們再轉換角色時會很容易出現不經意撒謊的現象,但這個角色稍縱即逝。(這種我們自以為無傷大雅的謊言,正是人們在做角色轉換時所最容易出現的說詞)

範例二、都是你害的!心理遊戲

“你看啦!你把我害成什麼樣子!要不是前幾天你給我出的什麼鬼主意,我今天也不會把自己搞得這麼慘……”看到這種對話,你一定會發現這個“都是你害的”的心理遊戲,開始時是向他人求助,因為在這段對話中的主角是向別人求助,當他會欣然接受對方給他的意見,而且他回去之後也會照著對方給他的建議去做,但是,當他失敗時,他就會把所有的過錯都推到那個好心給他意見的人身上。

※ 所以,經常玩這種心理遊戲的人必須一個人承擔責任時,他的內心會有巨大的擔心和恐懼,因此,在他的人生裡,他會縱容自己一次又一次地去玩這個心理遊戲,而到最後卻又將所有的過錯都推到別人身上,只因為這樣子他可以不必為自己的所作所為負起責任。他始終認為自己是無辜的。

.

從遊戲中脫離

這個三角色扮演的遊戲,我們每個人每一天,都在內心中不停地上演著,但是沒有人能夠察覺我們可以同時身兼多職變幻莫測,而且樂此不疲,上演著生活中的一幕又一幕的悲喜劇。這類情境會造成生活中的痛苦和衝突,因此卡普曼戲劇三角是一個負面的遊戲。當我們了解之後,就應該設法來脫離遊戲。所以首先;我們應該要能夠辨識遊戲的形成,然後讓自己避免落入這三種角色(一個正向的解法: TED書在這裡)。

 

卡普曼在《人間無遊戲》的書裏頭提供了健康的解法: 擺脫遊戲的三步驟:

第一步、識別遊戲和進入三角形的邀請。

第二步、學會提供高質量的關係。

第三步、我們要學會一個絕對可靠、不可抗拒的方法管理關係衝突。

就是:  提出它 BIU – 談論它 TIU – 結束它 WIU

 

結語

溝通是敏捷化的基礎,但溝通有形部分: 透過語言的方式進行面對面的交流。以及;無形的方式: 也就是心理層面的溝通。一般我們都聚焦在有形的方式,敏捷認為;面對面 + 站在白板前面形成一種最佳清晰又有紀錄的溝通模式,但無形的方面,也就是心理層面的溝通,才更是不能忽略的部分(便於引導與回顧)。卡普曼戲劇三角正好可以讓我們拿來分析參與遊戲者所扮演的角色和心態,然後以此為依據設法改善團隊成員的心理感受,這也就是所謂的心理溝通模式。這是身為Scrum master 或是主管所必須具備的本質學能,只有熟知團隊成員正在為什麼所苦,才可能給予適當的協助。

.

  • 有形的溝通;面對面 + 站在白板前面形成一種最佳清晰又有紀錄的溝通模式。
  • 無形的溝通;團隊中角色的扮演,屬於心理層面的溝通,它難以被察覺,但卻更容易造成痛苦跟傷害。

.

 

對心理學而言,遊戲的定義;是藉著與人進行一系列的曖昧溝通(表面上可能看起來像互補溝通),而達成一個可預期的負向感受的結果。在社會訊息看來像是一個很合理的互補溝通,但其中隱藏的心理訊息終將導致一個可預期的負向感受,所以它是負面的。在卡普曼戲劇三角提出之後,因為它是一個負面的方法,因此引起各界想出各種方式來掙脫它的負面效應。

.

Berne 的遊戲公式.png

識別遊戲的公式(Eric Berne)

如何識別遊戲呢? Eric Berne博士把遊戲的過程以六個階段來描述,並提出一個著名的公式(如上),當缺少任何一個因子就不構成遊戲。

最基本的解法就是識別遊戲,然後迅速脫離遊戲。這裡收集了幾種處裡遊戲的方法: 離開現場 暫時保持沉默或延遲反應 注意餌,避免上鉤 注意自己的漠視或自主驅動力直接給予正向安撫運用成人自我狀態來分析現象分析心理遊戲的過程 、在轉換時移向親密

 

———

向TA之父伯恩Eric Berne博士的致敬;他創立TA時制定了三條規則:

  • 對於不能用圖表達的內容就不要出現。
  • 簡潔的就是最好的。
  • 使用8歲以上小孩或者美國西部農民聽得懂的語言。

對想要用文字表達心裡變化的人士而言,它應該是被嚴格遵守的紀律。(與大家分享)

———–

 

 

註1. 《人間無遊戲》 A Game Free Life

出版於2014年,這是向人際關係之父Eric Berne 致敬(Berne 於1996年所著的《人間遊戲》Games People Play.

書

註2. 範例:參考自夫妻之間的卡普曼三角分析

註 3. 賦能三角.

賦能三角.png

.

協助工程師Breakdown Task 的方法

.

ipo breakdown

IPO breakdown法: 將工作描述成輸入-處理-輸出三個區塊

.

掌握了流程,就掌握了時間。將作業流程劃分的越細,工作內容就越明確,思路就更清晰。

-倍速心得

.

當你發現下午的辦公室特別吵雜時,原來是團隊成員在透過一上午的程式開發後有了很多疑問需要釐清的,因此在午餐之後便引發了討論潮,這種現象是好事,也能增加團隊協作,但一旦頻率偏高的時候就變成是一種浪費了(辦公室過分吵雜是一種浪費),你會疑惑為什麼有這麼多問題沒有在 Refinement 或 Planning meeting 時被提出來呢? 答案是:「因為有很多細節通常需要做了才會發現。」敏捷不像傳統開發需要有冗長的系統分析階段來弄清楚細節,因此就變成做到的時候在來解決的方式 ,但其實當需求明確到不會在變化時,就是可以開工的時候,仔細的分析是不能少的,上面這個方法是我被委派去帶領加速團隊開發速度時所常運用的工具。

 

因為描述需求的使用者故事對工程師Breakdown成Task的協助太少了,使用者故事擁有足夠的抽象度來涵蓋客戶的需求,向上沒問題(對確認需求而言)。也運用問答的方式來協助工程師了解要開發的功能。但在將故事 Breakdown成為任務(Task)的過程就沒有太多幫助了(向下,細節分析的部分)。以下是一個運用結構化思維的古老方法,它不但對開發工作有幫助,對一般追求效率的人士也很有用(註1)。

.

二倍速的開發速度 – IPO Breakdown

IPO是一種結構化的分析方法,它的理念是來自IBM系統360的功能描述文件(IPO: Input-Process-Output,在加入階層式的功能說明,就叫做 HIPO了,整個360的文件都是這麼寫的),IPO的優點是運用把輸出入分離,用很簡單的圖表描述了某個特定模塊內部的處理過程和輸入/輸出關係(即便沒有實做任何文件,這種IPO的思考方式也具有弄清楚程式功能結構,降低事後溝通的功能)。如上圖,首先將功能區分成三個區塊來考慮,把process 的區塊看成是黑箱,先把輸出入弄清楚了,再來考慮怎麼做細節處理,這是典型的結構化思考模式(將資料與流程分開考慮),步驟是這樣的:

.

資料】的部分

從介面開始,由定義輸入端是什麼資料格式開始,先從會拿到什麼樣的資料格式開始考量,再接著思考要轉成什麼樣的格式做輸出,弄清楚呼叫來源(上游)是誰,輸出的承接者是誰,把IO先搞定。

邏輯】的部分

考慮完I/O的邊界之後(分開來的介面部分),就比較容易去界定程式模組的範圍,也就是預估出程式應該具有那些功能模組,如果還是太大,應該在區分成那些更小的功能區塊呢,大小如何?

—-

程式結構化的基礎,是讓任何程式邏輯僅有一個輸入與一個輸出,這時候程式的邏輯「結構」便可以簡化成:循序(sequence)、選擇(if-then-else)與重複(do-while)。當程式太過複雜時就用階層的方式再呼叫下一層模組的方式來降低複雜性(這便是著名的 HIPO,也就是階層式的IPO了)

.

hipo-chart

範例1. function diagram + IPO chart

—–

接著需要考慮動態的部分,要考慮進來的資料速度嗎?需要Queue嗎? 有同步處理的要求嗎? 該如何處理額外的錯誤(exception)呢?等等細節考量。

.

服務】的部分

考量我是不是需要呼叫到外部的服務,萬一它出現錯誤時怎麼處理呢?如果它沒有回覆時,又該如何處理呢?

.

填寫完這份資料表時就等於思考好如何寫這個功能的框架了,接著便是實做它了(當然不能忽略簡單的原則,別忘了總是可以在簡單一點)。一般在處理較單純的功能時,工程師會隨意的畫個草圖就開始開發工作了,但一旦遇到較複雜的功能時,就會發覺他們認真的做起分析文件的作業,這時候二倍的效能便誕生了。為什麼?

 

因為,減少了頻繁的溝通,來來回回的詢問變少了,速度就變快了,由於事先運用了結構化分析的動作,有不清楚的問題已經在填表的時候問完了,減少了頻繁的溝通這才是快起來的主要原因。我稱它為「IPO Breakdown法」。

WIP.png

運用WIP(半成品)的理念來消除瓶頸

.

打破學習瓶頸: 以Task為單位作回饋,快速學習

Scrum 的回顧會議已經成為五大會議中最重要的會議了,原因是它提供了團隊共同學習的效果,價值非凡。我們可以從會議中檢討出好的行為(繼續保持),不好的行為,拿來做為改善的依據。這是團隊學習持續壯大的最好的時機。但對於個人而言,當做完一個任務的時候,測試人員的回饋,正是最適合檢討的時機,也是個人學習的最好時機點。當你希望一個開發團隊在同一個專案之下越跑越快的時候,最好的做法便是每天都作一次回顧,讓成員快速的講一下自己今天做了什麼,學到了什麼? 下來要怎麼作,把細節說出來,學到了下回就不會在犯了,有成長自然越作越快了,團隊也自然越來越堅強了。(這不正是code review嗎? 是的;是加了驗證的code review)

 

打破起步慢的瓶頸: 讓工程師以完成較大的工作進行規劃,而不是每天作規劃

目的是工程師不用每天都重新規劃工作,而是持續的投入工作,這會讓每天的起步工作都快上許多。讓工程師養成還沒來到辦公場所就已經清楚自己準備從哪裡開始做起了。這會養成一種持續的思維方式,也能避免受到不經意的誘惑而偏移了目標,跑去做其他的事。

 

.

結論

如何增加開發速度呢?若以精實的原則來考量,就是找到「瓶頸」的地方然後消除造成浪費的障礙(瓶頸:就是流量障礙,它讓流量值減緩,造成效能下降。IPO Breakdown是用來協助開發人員在開始工作前先弄清楚一些規劃上的細節,以減少開始工作時的頻繁溝通而產生浪費的方法,不是作文件也不是要求作文件,雖然它是製作敏捷文件的好方法,但不要忘了我們的初衷,增加開發速度。

如果你的團隊經常在每日的站立會議裡追加工作單,在 Sprint 中甚至追加的工作量超越了原先的計劃中的工作量,那表示你的 Breakdown 出了問題,明顯的你需要多花一點時間作分析工作。但最簡單的作法是在進行Breakdown作業時,先把輸出入寫下來,好好的弄清楚。

.

捨棄不作來加快工作的起步速度。

-最快的加速法

.

 

註:

所謂的結構化分析與設計,基本上是將資料與流程分開來考慮,主要可分成三大部分:資料塑模、流程塑模與使用者介面塑模。

  • 資料塑模主要是針對資訊系統的知識子系統;
  • 流程塑模主要是針對問題處理子系統;
  • 使用者介面塑模主要是針對資訊系統的使用者介面子系統。

這三種塑模活動並沒有一定的進行順序,也就是說任何一種塑模活動均可視需要而先進行或以其他塑模活動交互進行。

 

 

註1. 《從此不加班的 IPO工作術》 by: 清水久三子

註2. HIPO

HIPO(hierarchy plus input-process-output)

是IBM公司於70年代中期在層次結構圖(structure chart)的基礎上推出的一種描述系統結構和模塊內部處理功能的工具(技術)。

 

誰在團隊搞破壞

.

我做敏教練十多年了,常常會遇到公司有一些服從性絕佳的人士,

忠心耿耿對公司的貢獻有目共睹,但對敏捷轉型而言卻充斥著破壞力,

長久以來都不知該如何應對這件事,這本書給了我解答。

.

這是一本2016年12月出的書,這些戰術乍看起來真是十分的八股,但如果因為這樣你就把書放下來沒有在繼續看下去,那就損失掉從不同角度去認清「團隊是如何失去效能」的機會了。更可貴的是作者在描述完每一個戰術之後都用了問題解答 的方式給出了解決這些造成團隊效能不彰的策略,真是很棒! 老實說;這些解法一點也不新奇,但是換用敏捷的角度來檢視它,那就像閱讀 斯坦利·麥克格裡斯特將軍的《赋能》一樣的精彩(不要罵我老古板,實在是你應該要用心去閱讀),這二者採用了不同的方式來達到了敏捷的效果。

.

讓團隊能達到敏捷化的方法很多,而Scrum則是一種少見的簡潔作法

.

Manual.png

簡單破壞實戰手冊的八大戰術

.

(接下來;我要開始破梗了,想保持閱讀新鮮感的人士,先去看書吧!)

.

第一招、凡事都要問主管 – 服從也會變破壞

這是我最喜歡的一個章節,它讓人回想到孩子們要初進職場時父母親的叮嚀,當你進入一家公司工作時,你必須: 「遵守規則、確認你的工作程序能夠正常進行、要參與團隊一起做決策,多聽少講,要溫和而適當的表達出你的意見。」這些行為都是職場上的潛規則,它們已經是職場文化的一部分了,每家公司可能也多多少少有一些差異,而你就是要盡快地去融入它,而依循公司規範的尺度到底要到哪裡呢? 套句書裡的話,不要耍蠢就可以了。

這一章在描述如何識別在團隊裡誰在扮演破壞者或是違規者的角色。而你看完之後,除了能看清事實之外,更要試著去思考當自己身處在這樣的情境時,你會怎麼做呢?先設身處地的思考自己在哪裡後,才去看作者是怎麼建議(解題策略)的。二者相較之下,就能隱約看到書裡頭敏捷的影子,原來這麼做也能達到。

.

鐘形曲線檢測法

.

你是哪一種人?如果是你會怎麼做決策呢?

》故事一: 你是一位旅館的櫃台經理,你有權力給入住旅客升等房型,你能夠決定是否給旅客升等,也可以不給。旅館有規定已久的指導原則,但行事在你。如果我們讓員工輪流來擔任這個職務,並將給跟不給升等的次數做成紀錄,它可能就會是上圖的鐘形曲線(常態分布),曲線中間是代表我們對破例次數的期望值,右側是違反指導原則提供太多升等次數的人員( ==違規者)。左側是遵循指導原則很少提供升等次數的人員( ==破壞者)。違規者會造旅客被升等產生愉悅的感覺但升等房間被濫用了,破壞者會造成旅客因為沒被升等而感受不佳(下回可能就不來了),但升等房間卻被保留下來。如果是你會偏向哪一側呢?

故事二: 你是一位業務員,代表公司跟廠商洽談一筆大生意的簽約事宜,廠商代表要求你在會議桌上做些小幅降價就會把案子給你,但是公司曾經下達業務人員不得自行答應客戶降價的規定,一定要透過主管授權。而主管碰巧出差,他的職務代理人又一直連絡不上。如果是你要降價嗎?

.

在職場上這樣的情境屢見不鮮,想一下你個人會怎麼處理? 再想一下如果換成你是他的主管要怎麼教他來應對這種狀況呢?

(書裏頭有建議)

.

敏捷怎麼說

對於違規者;這是一種顯而易見的犯錯事項,要當面告知,並修正他的行為規矩,只要重申或修改一下規範便可以有效的降低違規了。至於對破壞者而言,就比較嚴重了,這是一種很不敏捷的事。對組織來說是一種隱藏著的傷害者,管理者必須花較大的力氣來發現、改善、增加他的敏捷性,如果他本身也是主管的話,那就更麻煩了,需要花更大的力氣才有可能作改變。

.

【延伸議題】實踐DevOps三步工作法的第三步、持續學習與實驗原則。談這個好像有些風牛馬不相干的味道,但它給我的聯想是:

 說明: 上面陳述的現象都屬於經驗法則,當你遇到過了就會累積下來成為經驗,一旦有經驗可以依循時就會做出較正確的抉擇,因此組織可以刻意的製造出這種情境來進行模擬式的教學。讓團隊成員透過範例的練習來取得經驗,事後開個檢討會議讓整個團隊都獲得共識。這種實驗式的情境教學,正是一種安全的嘗試錯誤safe to fail 的模式,拿來實踐第三步的持續學習與實驗原則再好不過了。

.

如果沒機會做到,那要如何獲得實戰經驗呢?

.

ps. 如何評估企業文化呢? 你對成員要求的標準差(1~3) 決定曲線的範圍。

偏頗組織.

需求排序

.

弄清楚需求的目的才是王道

需求可能多也可能少,可能是給一個5~9人的團隊用的,也可能是大到要給10幾個團隊用的,可能是個別團隊就能完成的也可能需要多團隊協作的,可能是一次性的也可能要持續作個幾次才能作完的。不一樣的情境就會要採用不同的思維模式,有時候你會很想往前去追問當時寫下這個需求的人,實在很想問問他到底要的是什麼? 因為要花大家那麼多時間來討論,之後又要花團隊更多的時間、精力去開發,可千萬別作錯了方向,這是討論需求時務必先弄清楚的前題 (花太多時間去弄清楚需求,會不會就不敏捷了呢? 其實這裡所指的是時機點,一旦錯失了提問的時機,放到一個月之後再問,感覺上就不像是在弄清楚需求,而是不想做的樣子. 所以第一個聽到客戶需求的人要付起這個責任,就是盡力的去追問「why? Who?How?What?」)如果沒弄清楚就開始運用各種技巧工具去開始解題,即便再好的工具用再多的技巧也不會讓你作對的。

.

估算時最怕的是,過份樂觀。

進行需求排序時最怕的是,沒弄清楚需求。

.

需求.png

實行DevOps之下的需求

工具:

  • 用戶旅程地圖: 使用者與業務人員最感興趣且必須弄清楚的部分。
  • 影響地圖: 能讓我們視覺化需求,知道為何要作它。
  • 用戶故事地圖: 能讓我們看見需求的全貌,知道目前的進度在哪裡。

上面這張圖在強調「需求」是企業實施 DevOps 串接 SD-PD-RD-OD 的主要實物(可以讓敏捷走出開發部門),而公司的管理文化則是影響著決策的無形力量。

.

(這是一篇很長的文章,慎入)

.

需求的排序問題,在各個領域都非常的重要;尤其在軟體開發的領域,哪些工作需要先做,哪些工作要排在後面做,這是影響企業交付產品價值及進行開發作業快慢上最重要的一個因素,也是一個最容易引起爭議的話題。如果只是簡單地說「重要的工作要先做」,這個原則大家都很容易理解也容易達成共識,但實在是沒什麼幫助,也就是說缺少了可操作性,在只有少量需求時我們可以僅僅依靠幾支紙筆就能順利完成排序的任務了,但當遇到需求量稍大的情況下就很難不依靠工具來判斷到底是孰輕孰重的問題。所以我們不僅要有指導的原則,更需要有一個可以量化的工具,使我們在操作上更容易進行調整與排序。這不是一件簡單的事,所以我們先按部就班來看敏捷怎麼說。

.

敏捷怎麼說

(這裡節錄了二個定量的方法: 一個是 Scrum.org 裡收錄 Mike Cohn 的「主題法」。另一為Scaled Agile Corp.的Dean Leffingwell所創的「延期成本法」。)

對敏捷團隊而言,對需求作優先順序的排序,是產品負責人PO的責任。對PO來說,根據市場的商業價值(business value業務價值)來確定優先順序是在明確不過的事了,但說起來容易,到底業務價值又要如何定義、如何評估和測量呢?Mike Cohn的建議是對“主題”先來進行優先順序的排序。

(囉說一下,雖然PO要負全責,但是把所有的責任跟壓力都放在一個人身上則顯然是不對的,因此這個責任又落到整個敏捷團隊應該要支援PO來做需求優先順序的排序。)

Mike Cohn 建議將單獨的用戶故事或要需要完成的功能(feature)放到一些個 主題 中,而這些主題都能分別獨立地定義一組對使用者或客戶有價值的功能。這樣,對主題進行價值的確認便更為容易了。他從四個方面作考量:

  1. 經濟價值。 2. 所需成本。3. 學習和獲取知識的重要性和數量。4. 風險

前二個是投資報酬,在來是考量到團隊是否可以學到東西(如作MVP之類),最後是這麼做的風險。只針對風險和經濟價值之間的關係來排定優先順序是一個難題,不能單獨的考慮追求價值或是以回避風險而進行優先順序排序。因此借助了風險和價值的關係來做說明 (Risk-Value),也就是借助風險-價值矩陣圖示來做分析。

.

risk_value_1

風險-價值矩陣(加入度量數據)

.

  • 高價值-高風險的功能:優先處理,即考慮到優先獲得高價值回報,最好儘早進行處理以消除顯著的風險。
  • 高價值-低風險的功能:提供價值相當,但由於風險較低,可以稍晚進行。
  • 低價值-低風險:排在第三位,放棄他們對產品總價值影響較小,風險也很低。
  • 低價值-高風險:顯然最好是避免開發,或盡可能推遲這上面的工作。

.

risk_value_0

風險-價值矩陣處理順序

.

風險與價值

—————–

風險值是通過概率乘以影響計算的風險成本的估計值。

Risk = Probability × Impact

範例: 一個花費 $100,000 的專案,若有15% 的失敗機率. 風險值為?

risk = 100,000 × 0.15 = $15,000

—————

結合對知識學習和風險的考慮,產品負責人可以與團隊一起坐下來評估及調整。針對風險-價值矩陣,還需要持續監督,因為價值和風險隨著專案進行是會動態變化的。

.

另一種考量方法: Safe 的反向解,延期成本法 Cost of Delay

著名的 Scrum大型架構 SAFE 的創始人 Dean Leffingwell 以反向以終為始的思維方式,不以客戶的利益為導向,反過來以萬一延遲了要付出多少代價來作預估,創新了另一種排序的依據,簡稱為 WSJF: Weight Short Job First直接翻譯就是”加權最短作業優先法”(參考自百度,《敏捷轉型》),用專案如果延持(delay)的時候要付出的代價來作加權數據的估算,公式如下:

wsjf

.

延期成本 = 商業價值 + 時機關鍵性 + 減低風險或增加機會的可能性

延遲的時候要付出的代價 Cost of delay;一般認為延期成本由三個因素組成:

一、基於用戶的商業價值

  • 我們的用戶是不是真的非常想要這個?
  • 這個對我們業務的收入有什麼影響?
  • 如果延誤我們會收到什麼樣的懲罰和其他影響?

二、時機關鍵性

  • 這個有確定的deadline嗎?
  • 用戶會為此等待我們還是會轉移到其他的解決方案上去?
  • 有其他關鍵里程碑會被我們的延期影響嗎?

三、降低風險/增加機會的可能性

  • 這個能幫助我們降低未來發佈的風險嗎?
  • 它能幫助我們開啟新業務領域的機會嗎?

WSJF = (User Value + Time Value + RROE Value) / Job Size

其中的RROE值 (減低風險或增加機會的可能性) 從 1 到 10的加權值。

(Risk Reduction& Opportunity Enablement)

即所謂的降低風險 – 機會啟用價值 Risk reduction-opportunity enablement value.

.

WSJF_table.png

採用類似故事點的估算列表

.

WSJF_sample.png

範例:用藍色陰影區域表示每種情況下的總CoD值。

(參考自: https://zhuanlan.zhihu.com/p/29588386)

.

以上是敏捷一般的通解

.

真實世界的需求排序問題

運用 Mike Cohn 所建議的「風險-價值矩陣」,將需求置入某一主題後,然後填入相對應的象限中,這種做法能很輕易地拿來判斷需求是孰輕孰重,但問題往往就發生在對需求應該填在哪一個象限的認知上頭會出現爭議。怎麼辦?

.

———-[  Action Learning  ]————–

當團隊裡出現意見相左時,訴諸仲裁(表決式、建議流程式)是合理的解決方式,但在進行表決之前,能依據行動學習的解題模式,先進行提問後再進行討論的方式,最後才是訴諸仲裁表決,如果在時間允許的情況下,這麼做可以獲得較佳的學習效果。

————————————–

.

》以下是如何量化需求的幾種著名方法

(包括: 由狩野紀昭 Noriaki Kano 和 Fumio Takahashi 發明的 KANO模型、由 Intercom 公司所創的 RICE 計分分析法、波士頓矩陣 BCG Matrix唯一的定性分析法)

 .

KANO模型

KANO模型是以分析需求對用戶滿意度的影響為基礎,體現了產品性能和用戶滿意之間的非線性關係。

.

CANO.png

又稱為 狩野模型

.

狩野模型 Kano Model是一個非常有創意的品質表示模型,一般也稱為二維品質模型。所謂二維(Two-dimension)即是包括兩個維度,其一為從顧客觀點的滿意程度,屬於客戶主觀感受,另一為從產品品質觀點的提供,屬於客觀的產品機能或功能。

二維品質是相對於一維品質(One-dimension)所提出之擴展模型,其中一維品質是說,當產品品質越好或是需求越受到滿足時,則客戶滿意度越高,兩者呈現是線性的關係。從一維品質觀點出發,會得到增加品質則客戶越滿意結論。

.

用戶反映列表.png

量化的數據表

.

用戶反映列表_1.png

需求落點圖示

.

RICE 分析 by: Intercom 公司所創

RICE:產品經理的需求優先順序排序法

評估優先順序的四大因素;到達範圍 Reach,影響力 Impact,信心度 Confidence和努力值Effort。

.

rice_0.png

https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

.

  • REACH 到達範圍

為了避免出現主觀需求的偏差,我們應該評估每個專案在既定時間內會影響多少人。對於我的團隊來說,就是“在一個季度內,這一個專案將會影響到多少客戶?”它是衡量每個時間段內產生的用戶數或活動數。也許會是“每季度客戶數”或者“每月交易額”。盡可能使用產品指標中真實的測試資料而非虛構的資料。

  • IMPACT 影響力

關注會直接影響結果的資料,評估獨立個體的影響程度。就是“當有客戶接觸這個專案,它能夠提供多少轉化率?” 也可以用其他有意義的指標來取代,比如“提高使用率”或者“最大化用戶滿意度”。

影響力很難精確的衡量,所以設定了幾個加權選項:3:重大影響,2:高度影響,1:中度影響,0.5:低度影響, 輕微影響:0.25代表。這些數字將作為權重值與各項評分相乘,加權得出評估結果。

  • CONFIDENCE 信心

為了遏制對於概念不明的想法的盲目熱情,需要把評估的可置信水準也考慮進來。如果你認為一個專案本來可以有巨大的影響力,但是並沒有足夠的資料來支撐這樣的看法,這時你對該專案的掌控度源自於你的“信心度”。

信心度是一個百分數,用一個有多項選擇的量表來輔助避免決策癱瘓。100%:高信心程度,80%:中等,50%:低。

  • EFFORT 努力值

為了能夠快速發展並用最少的努力獲得影響力,從團隊的所有成員出發,去評估一個專案需要的時間總量,包括產品、設計和工程。努力程度的評估是以“人-月”(一個團隊成員一個月的工作點數)為單位對努力程度進行評估。

》綜合四個因素得出 RICE分數,四個因素:

  • 到達範圍:多少人會受到影響?
  • 影響力:對每個人的影響大小?重大= 3x,高= 2x,中= 1x,低= 0.5x,輕微= 0.25x.
  • 信心度:你對於你的評估有多少信心?高 = 100%,中 = 80%,低 = 50%
  • 努力值:需要多少“人-月”?

把這些因素綜合成為一個單一的分數,這樣你就可以一目了然地比較項目了。

參考: RICE分數代表了“每個工作時間的總影響力”(為極大值)。

.

波士頓矩陣(瘦狗金牛)

波士頓矩陣也並非一開始用來排列互聯網產品需求優先順序排序用的,而是拿來判斷企業如何選擇更有前景的產品市場用的分析工具。但後來被改為將原有坐標更成適用於產品需求優先順序判斷。瘦狗金牛方法運用類比手法,也將需求進行分類,包括4類:問題型需求、明星需求、金牛需求和瘦狗需求。瘦狗金牛方法的核心思想:瘦狗需求需要過濾掉,明星需求優先順序最高,金牛需求和問題需求則根據產品生命週期及產品定位等因素有先後。相對於KANO模型定量分析,而瘦狗金牛方法則是一種定性的分析

(BCG矩陣BCG Matrix是布魯士韓德森於1970年為波士頓諮詢公司BCG設計的分析圖表手法,我們可以根據市場的成長率和自家公司產品的市占率,來判斷公司產品在不同的生命發展周期必須採取的市場定位策略。根據 BCG矩陣 ,產品周期可以分為4種,分別為「問題小孩」Problem Child、「明星」Star、「現金牛」Cash Cow、「老狗」Dog,不同的產品生命周期有不同的對話測試方式。)

第一階段、問題小孩事業

產品仍處於較高成長的階段,但市場占有率較低,此外,相較於其他事業體的資金營收創造能力,問題小孩事業的資金營收創造能力較低,但市場需求也高了許多。問題小孩事業的產品通常具有投機性或話題性,且帶有較大的市場評估風險,這些產品或服務的利潤可能很高,但因為是利基市場,所以占有的市場份額很小。

第二階段、明星事業

產品具有高成長率及高市占率,這時產品已經發展成具有競爭優勢與擴展機會的策略性事業,也是企業長期成長與獲利的最佳機會。不過,當產品處於快速增長的市場並且占有支配地位的市場份額,公司卻不一定能立即產生正的現金流,這是因為公司必須投入更多資源於產品,來支撐品牌在市場的心占率。

第三階段、現金牛事業

產品往往擁有低成長率與高占有率,一般而言,相對市場占有率高的事業,能夠創造的現金比需要投注的資金來得高。然而,雖然現金牛事業的產品能夠產生大量現金,但其未來的增長前景有限。

第四階段、老狗事業

產品已經進入生命周期的尾聲,不僅成長率低,占有率也低,因而對公司來說已經沒有太大貢獻。既然老狗事業的產品不能產生大量現金,所以企業主也不需要投入大量現金,一般而言,這類業務往往是微利、甚至是虧損的,但大部分老狗事業仍存在是基於感情上的因素。這個時期也能用技術債多到無力償還做判斷的基準。

.

bcg_1.png

用波士頓矩陣進行產品分析

.

這是一種根據產品生命週期做判斷的類比手法,是一種定性分析。

.

運用看板來進行 OnePBI 排序的會議

kanban_sorting

二種仲裁方式: (一) 執行者接受建議抉擇方式、(二) 獨裁者仲裁方式。

.

結論

為什麼要量化需求呢? 因為當你有一大堆需求需要排出優先順序時,千萬別再依靠直覺和記憶了,請參考一下這些工具,挑一個適合的用用看,這樣作會比較合理。如果你只有少量的需求需要排序,我會建議你不如把時間用在好好了解它上頭,這會比花時間去做這些評估還要重要許多。

上面陳列了二種敏捷常用的方法和二種以客戶價值為導向的著名量化分析方法,為了避免遺漏,最後陳列了一個定性的評估方法(BCG Matrix)。我個人偏好使用 Kano 模型,雖然每次使用時,也會對那些主觀的給值方式感到不安(當我感到困惑時,運用雷達圖可以增加參考因子,就比較不會擔心自己太主觀的偏向一二個觀點。註3.),所以就經常提醒自己,第一、得到的數據值(優先順序)是相對的,不是絕對的,他們只有在拿來做比較時才有意義。第二、不應該執著於那些運算結果,盡量用機率的概念來看分析結果。因為那些量化計算所得來的結果(數據)只是供作參考比較用,最後還是得要交給真正負責的人(負責人或團隊)來做仲裁(註2.),因此機率的意義實質上要更大些。

.

問題:我們需要對所有的需求的Backlog(所謂的 OnePBI )排出唯一的先後順序嗎?

答: 如果你夠敏捷的話,就知道需求的變動是無法避免的,雖然我們可以通過以上介紹的方法,來對需求進行排序。然而,只有必要對那些排在頂部的需求下功夫盡力去了解它,你可以排定3個月或是一季的需求(一個星期review一回),其他的需求將隨著持續地開發作業,繼續改變他們的優先順序,過早去進行排序只會是一種浪費。

.

(因為不想讓找資料的人再到處去尋覓,所以就忍住把一大堆東西都放進來了)

.

註:

  1. Intercom 創立於 2011年 的三藩市,是一個社會化客戶關係管理平台,目的是致力於説明公司可以更好地與客戶進行交流。目前的Intercom有 30,000多付費客戶,包括 Expensify、Trunk Club、Rackspace、IBM、Heroku、Hootsuite、雅虎、Perfect Audience、ZenPayroll、Shopify 和ly 等。
  2. 有一則廣為流傳的購車寓言,它描述一對夫妻在買車前做足了評估作業,對價格、性能比、外觀,一一作了評估,並作了量化的表格,然後選出投資報酬最優的車款,但在最後買車時卻選擇把評估表拋到腦後,直接購買了妻子心中喜歡的車款。(我也曾做過這件傻事,雖然花了些時間,但夫妻一起做會很有趣,可以分享很多常識,可以增進共識,很值得的)
  3. 運用雷達圖可以增加考慮因子: 需求雷達圖
  4. 敏捷轉型by 王明蘭
  5. WSJF : https://www.jianshu.com/p/71d97e777267
  6. RICE: https://zhuanlan.zhihu.com/p/20672278
  7. BCG Matrix: https://wiki.mbalib.com/zh-tw/%E6%B3%A2%E5%A3%AB%E9%A1%BF%E7%9F%A9%E9%98%B5
  8. Mike Cohn 主題法: http://blog.sina.com.cn/s/blog_150cf1c670102wn5b.html

.

敏捷管理

.

有一個機會跟一群管理者講敏捷的課程,只有100分鐘,你會怎麼講呢?

.
敏捷管理

Fig 1. 敏捷管理示意圖

.

思維過程

首先, 我把想要表達的元素列了出來,然後稍微整理成心智圖,看著看著心智圖…,就嘗試著把它們畫成一張圖示,試著增加抽象的程度來加大看見的範圍,試著運用極度抽象的方式來解題。最外圍我用了圓形把二代精實的五個原則圈起來並標示了順序,然後是做任何事都必須持續落實的敏捷思維方式: 透明、檢核跟調適,我用了三角形把它們放在三個角落上改變一下字形,最後是明確的跟主管們說出來其實你只有一招而已,那就是在這個時代下管理者的僅有工具 – 引導, 我把它放在正中間,便構成了這張圖,一張基於敏捷管理者需要會些什麼,怎麼作的圖示。

 

對著圖看了一會兒;突然間意識到,這些東西都是技能,那 “心" 到那裡去了呢? 便把開放 Open Minded 放到了引導的上面,心態便好像活起來似的。這就構成了上面這張圖。

 

要怎麼說出來呢;試著用一句話來描述它:

.>>>

管理者要擁有開明的思想,並以精實原則為依歸,運用引導的方式來落實 透明 – 檢核 – 調適的循環.

.>>>

》其實;想談一點組織的行為科學;因為學員都是要管人的人,怎能不知道屬下為什麼會有這種反應呢? 怎能不知道這種態度是如何形成的呢?

. 如何形成「反思」在形成「認知失調」時促成改變正確化「投射」projection形象

態度 的構成因素: 態度是由"認知“、"情感“、"行為“互相影響的。(參考自 Stephen P.Robbins所著的"組織行為學" 16版。)

.

對人類行為的理解在很大程度上決定了管理者的管理效能.

.

》其實;想談一點 Scrum 的五大會議;還有三個角色所賦有的職責及如何檢視團隊衝刺後的產出物。

.

》其實;想談一點問對問題的力量;一直問問題就能找到真正的目標(要講 impact Mapping 嗎?)。

.

》其實;想談一點 OKR 目標關鍵結果;它能讓你整個團隊、組織有聚焦的動力。

.

》其實;想談一點Action Learning行動學習;讓主管善用組織力量,又能邊做邊學習順便解決棘手的問題。

.

》其實;想談一點如何在 授權 後 賦能 的方法.

我把「開放」擺在中間,除了它是圖裡頭唯一不是技術層面的東西之外,記得雷·達里奧在《原則》一書中說道:「我認為要實現夢想,你得清除自我設障、思維開放、下定決心、富有勇氣和做事不找藉口。」​其實很多時候,當我們無路可走時,並不是被現實的牆所圍住,而是被思維的牆所困惑。而「開放」,正足以拆掉這堵思維的牆。因此管理者首先要擁有的是一種開放的思維。易經有所謂不易、變易與簡易,簡單的說: 遇狀況;當有選擇時~逢凶化吉,沒選擇時:把不好的想成好的(要樂觀),更勝者;把不好的變好,也就是展現膽識、魄力和執行力。

管理者必須經常承受下屬有認知失調的現象發生(認知失調;就是人們有時候表現出來的態度會與你對他的認知有一些偏差,讓人覺得這與他給我們的觀點、價值觀或態度上不符),有一點衝突感,就稱之為認知失調(費斯汀格教授所提出的cognitive dissonance theory)。這是一種瞬間的不平衡,也是形成態度或行為轉變的前提,這是運用引導的良好時機點,管理者要試著引導出正確的行為,引導他朝向良性的方向去發展。

.

引導」Facilitate;好喜歡它的字面意義: 「讓事情變得容易」要真能這樣就好。它是管理者最強大的武器。要對他做說明,還不如用另一個詞彙來做說明,更能清晰的詮釋它的意義。那就是;引導師或引導者Facilitator他是一個幫助團隊理解他們的共同目標,並協助團隊擺脫各持己見的討論之下,能夠共同做出行動計畫並實現計畫的工具人。主管有時必須扮演這樣的角色,目的只是要幫助團隊理解他們的目標,接下來才好思考如何進行的過程中幫上忙?所以主管的任務實質上是要大過引導師許多的。但要切記;引導總在思考到職責時消失,不要被你必須為這件事負責成敗的責任,就選擇了直接介入的方式破壞了自組織的成形,管理者應該始終擁有開放的心靈,選擇相信團隊能夠做到,相信引導的回報(那便是最難能可貴的信任與自組織的團隊)。

.

一種以透明、檢核、調適為行事依歸的循環.

管理可區分成對人跟對事二個部分。首先;行事之前要先看見全貌,知道下屬都在做些什麼?現在的進度在哪裡?這是事的部分,在看板上都可以看得到,這是它的基本功能,若是有看不懂的地方,記得一定要追問下去,一直到弄清楚為止,這是運行看板方法的基本要求(不應該有隱藏的工作或其他事項)。透明化的進度讓團隊時時都知道自己的進度在哪裡,也知道自己是表現得好還是不好,這是人的部分,一種因為視覺化後所衍生出來的共識,也是看板最有價值的地方。因此,透過看板可以讓管理者可視化團隊的工作進度及成員們各自的表現。它是管理者與團隊中間的一個溝通橋梁。所以管理者與下屬對看板的行為務必有相同的詮釋,才不至於產生上、下之間的隔閡。

 

接著;是檢查是否達到符合客戶價值的標準,要有數據,這也可區成二種,一種是明確化的數據,它來自運行看板時自動獲得的可度量數據。另一是共識型的數據,它是我們運用OKR的目標關鍵結果,由人跟人所公同商議之後取得的數據化結果。它們的目的是對工作者產生激勵作用與取得回饋。

 

在獲取檢核的數據之後就是進行調適了,有了依據才好進行持續調整。如果檢視者在判斷流程中的某些部分有超出了可以接受的範圍時,而且在這麼作下去會造成不良後果時,就必須調整當下的流程或工作方式。這種調整必需越快越好來避免未來產生更多的偏差。

.

精實思想概述為:

1. 是精確地定義特定產品的價值;2. 識別出每種產品的價值流;3. 使價值不間斷地流動;4. 讓客戶從生產者方面拉動價值;5. 永遠追求盡善盡美。清楚地瞭解這些原則,然後將這些原則一起加以實踐,管理人員就可以充分利用精實技術,保持穩定的發展。

 

1.定義價值 Value

我們在做決策時的關鍵出發點是價值,而價值只能由最終客戶來確定。價值只有在由具有特定價格、能在特定時間內滿足客戶需求的特定產品(商品或服務,而經常是既是商品又是服務的產品)來表達時才有意義。價值是被生產者創造出來的,而不是由客戶說出來的,所以我們必須以客戶的視角站在它的立場來定義所謂的價值。

 

2.識別價值流 Value Stream

價值流是使指商品和服務兩者的結合。因此在從概念產生開始,通過細節設計與工程開發的全過程中我們藉由解決各種問題到完成任務;便是全部的價值流,關注這一流程往往會暴露出大量的、錯綜複雜的浪費,然後予以消除。

 

3.流動 Flow

一旦精確定義了價值,企業便能完整地制定出了某一特定產品的價值流圖,然後藉由消滅了種種的浪費步驟,讓價值創造的各個步驟流動起來,也就是Value Stream。這一步當然是產生價值當然是越快越好。這一點剛好與DevOps 三步工作法的第一步相同。

 

4.拉動 Pull

從看板上可以看出每一個工作步驟的流動作業都是一種拉動的形式,它強調的是即時的單工作業,減少了多工作業(multitasking)時的轉換工作時所產生的浪費。精實系統強調半成品數越少越好,但這需要不斷持續的改善以達到能夠即時的滿足客戶需求為目標。

 

5.盡善盡美 Perfection

這是一種持續改善的理念,強調的是藉由精確地定義客戶要的價值、識別出整個開發的價值流、使得為特定產品創造價值的各個步驟連續流動起來,並且讓客戶從企業方面拉動價值時,能夠達成它的需求目標。然後在克服這一定目標後,再去設定更高的目標去達成,一種以追求無止境地不斷減少付出的努力、時間、場地、成本和錯誤率的過程。看起來好像是一種妄想、不可能達成的事,但追求改進本就是人類的本性。

.

如果有足夠的時間的話 …

 

敏捷管理_not one.png

.

 

如何處理固定上線日期的專案

固定上限日期

敏捷團隊以考量客戶價值為主,再將成本、日期和範圍視為限制

.

以客戶價值為考量

敏捷團隊如何處理固定上線日期的專案(Fixed-Date Release Project),正名一下;我們面對的是如何進行Fixed-Date Release Planning 的交付計畫,有關Release Planning在敏捷開發裡頭是一個比較敏感的字眼,因為乍聽起來它給人很Waterfall的感覺,但不可否認的還是有存在的價值(有興趣的人可以參考Mike Chon的說法) 。這裡我們先依據 Kenny Rubin (《Essential Scrum》作者)的建議,分成6個步驟來處理:

第一步、首先確定版本開發會Run多少個sprint。假設所有衝刺長度是相等的,就變成簡單的數學計算了,因為您知道第一個sprint何時開始,並且您知道交付日期。

第二步、通過創建細項需求,估算產品待辦事項(Product Backlog Items)的大小和優先級來確定產品一直到足夠完成發布的深度。也就是你需要有足夠的PBI來計劃到固定的發布日期 (在Essential Scrum的第6章中有關產品待辦事項的更多說明)。

第三步、測量或估計團隊的開發速度作為範圍的依據(見Essential Scrum第7章估算和計劃:)。

第四步、通過將團隊的開發速度中最慢的數值乘以衝刺的數量來畫出一條開發產能的低標線(Slowest, 橘色線條)。 並將該數量的點數畫入產品需求累積圖中。

第五步、是通過將團隊的開發速度中的最快的數值乘以衝刺的數量來畫出一條開發產能的高標線(Largest, 紅色線條)。將該數量的點數畫入產品需求累積圖中。

第六步、是比較產品需求累積圖中的最小可發布功能(MRF;Minimum Releasable Features) 的可能性。如果所有必須完成的需求(Must Have)都落在橘色線內,那麼你的狀態很好,表示可安全過關(Good, 最左邊圖形)。 若是落在中間區域: 則表是有可能完成。如果是落在紅線下面的區域外,則表示團隊即使是用最大產能的速率來進行開發作業也不可能把必須完成的需求(Must Have)全數做完,也就是說你必需另外做打算了。

註: Ken寫道;如果你的專案範圍比完成日期更重要的話,則建議採用“固定範圍發布計劃”Fixed-Scope Release Planning

.

敏捷估算

參考自Innolution網站

.

真實世界的固定上線日期專案

在真實世界裡總有著各式各樣的理由,讓你非得在時間內(Fixed-Date)完成專案的交付。有可能是時節的緣故;例如月餅的銷售就得在中秋節前完成才有意義或是雙11的改善作業,哪就得在11月 11日以前完成才有意義。當然也有可能是多家公司上下游的聯合開發模式,你就是硬生生的被卡在中間的位置,而上下游的開發作業都沒有採用敏捷迭代的方式進行開發作業。在這些情況下如果參考上面所談到的敏捷式的解題方式,給人的感覺就不是很真實了,這6個簡單的步驟雖然很容易理解也好像很合理,但總覺得好像少了什麼? 是不是有什麼重要的因素漏掉考慮進來了呢?

1234

專案開發總是有很多我們不會知道的事

這是敏捷開發的一種典型解題模式「小增量迭代」的觀念在作祟,它的目的是為了避開Big Design Up Front (BDUF)也就是在專案還沒開始時就過度設計的問題(這是一種一直以為可以透過完善的設計來達成任務,如果失敗了就是因為我的考慮不夠周詳,是典型Waterfall式的思維方式),而敏捷開發就不會花太多時間去把所有的需求都做估算然後再做成統計上頭,而會尋求從重要的需求先確認後便快速開工的方式。相較之下,上面的估算方式就會給人一種好像過度簡單的感覺,但我們就稱之謂敏捷化

>>>

》老闆與工程師的對話:

「你專注起來做事還滿可怕的,六親不認、生產力奇高無比,而且連測試的部分也沒有偷懶,做出來的品質也都還不賴!要是能每天都能像這樣就好了!」老闆調侃的說著…。

「吼!我也知道啊!可是像這樣每天閉關工作十幾個小時,很累人的!怎麼可能每天這樣啦!會死人的好嗎?」

「接下來的連續假期我一定要出去走走,好好放鬆一下,實在是受不了!」

– 固定上線日期的專案

PM與工程師的對話(開發團隊坐進戰情室後,PM坐在門口)

工程師:「我要去上個廁所,手機可以還我了嗎!」

PM:「好的,五分鐘夠不夠?」

– 戰情室情節

>>>

所謂的戰情室工作法;就是把負責開發的團隊成員,全部關進同一個房間裡,目的是盡量減少他們受到外部的打擾(所以請在進入房間以前交出手機),讓它們專注的去完成任務。這是IT部門遇到固定日期專案超過他們的產能時所常用的手法,正可以拿來呼應上面的二句對話。它實質上雖是可行的,但不能長期如此,原因是會造成團隊與其他團隊之間的脫勾無法進行協作,而且工程師在長期承受過大壓力下,離職率會上升,身心也會較不健全,是一種開發作業的短期解

.

POsaleTechLead

以大家能形成共識為前提

.

前提是讓業務、PO及Tech Lead形成共識

工程師不喜歡固定上線日期的專案,這是一種先入為主的感覺,即便分析結果上線功能落在產能的低標線內,工程師還是普遍覺得壓力太大,即便只是聽到自己即將參加一個固定上線日期的專案時心理頭就會自然浮現出一種無形的壓力,會自動想像加入這樣的專案,就好像要被關進戰情室一般(也就是所謂的戰情室工作法),開發工作像是在跑百米衝刺一樣,企圖在很短的時間內透過高度聚焦來完成預期不可能的任務一般(敏捷式工作法則比較像是採用均速跑法的長距離馬拉松)。這是一種普遍的錯覺,但一旦形成這種先入為主的觀念,就很難去改變它了。因此針對這種非固定上線日期的專案,團隊對專案的共識才是重點。也就是要形成業務端、需求規劃者PO及負責開發團隊的Tech Lead能形成共識才是關鍵,大家能齊心處理專案。要能夠回歸到一種正常化的工作心態才是重點。而秘訣就是要能統一目標統一行動統一價值觀。要讓這三位負責不同面向的人士擁有一致的觀點才好導正大家對固定上線日期的專案的偏見。這是一種文化層面的問題,因此解題方式也必須從根源來著手,也正是所謂的長期解。

.

企業文化

.

建構企業文化來面對這個棘手的問題:

目的: 讓業務端、PO需求規劃者及Tech Lead開發團隊技術領導者能形成共識。

作法: 讓三者都能正視到一線的需求,沒有透過轉述,並經過意見的交換溝通。

※ 執行規則: 建議是透過制定簡單的規範,讓企業形成一種處理這類事務的文化理念,並能堅持以恆。三位執行者的處理準則則是解題於 (1) 專注於主要功能。(2) 階段式的達成目標。(3) 關注於實務的細節,並取得認同。

.

要奉勸正準備拍胸脯與客戶達成上線日期協議的老闆,

先打個電話回去問問你的開發部門主管再作決定吧,

你這麼作不會有任何損失的,反而會換來對方的尊重!

.結論

為什麼需要三位一體,讓他們(業務、PO及 Tech Lead)有一致面對客戶的機會呢?這不是很花時間嗎?但這能夠所代表的是企業的文化,當我們需要團隊的工程師犧牲自己的精力為組織效命時,這是我們最起碼可以作到的,也就是讓業務部門確認了客戶真的有這個需求嗎?而身為產品負責人的PO也有機會向客戶陳述並有機會詢問所有待開發的需求確確實實都是有必要的嗎?最後再由與工程師站在同一陣線的Tech Lead把所有功能鉅細彌遺的攤開來讓使用者確認那些是他一定要使用到的功能。以及向客戶解說那些功能團隊能夠輕鬆完成或是必須花費一番功夫才能作到的地方,讓客戶也能意會到我們的苦勞及願意付出的誠意。

公司承接任何專案,絕對不僅僅是開發單位的事,其實向外包括業務人員,向內則包括專案規劃人員及負責開發的團隊成員大家都是必然的共同責任承擔者,都必需為成敗負責,所以任何人都有必要弄清楚這麼趕的專案真正的需求邊界是什麼,一定要作到的範圍,也才知道到底自己是在為何而戰,也才足以齊心協力一起來克服困難。

快樂客戶.png

.