黑先生

【透過需求探索找到產品連結與認同感】 團隊成員對於自己開發的產品 總是 無感? 試試先讓成員多些理解需求的WHY，為何要做這需求、需求的由來。進一步共同創造需求，設計需求、探索需求。漸進轉變，從做功能、做需求、做產品到做市場，一步一步把產品變成團隊的事，價值也會自然提升。 團隊第一個面臨的困難應該是時間成本的投資? 如果要團隊8人左右，一起來發想、創意需求，花上以天為單位，八小時以上的時間做設計衝刺、設計思考，獲得一個活動方案，通常團隊自己就會是最大的瓶頸。 一來是捨不得投資時間成本，尤其是產品還在相對穩定狀態，更是不願意額外花費時間。 二來是不熟悉團體討論模式和方式，導致每次的討論都又臭又長沒結論。會議的意願也因此降低。 假如，團隊成員包含著老闆層級，對於時間的付出和效益，更要精打細算控制。如何在有限的時間內，獲得還不錯的共識方案進行原型驗證，將會是一大考驗。 那我們該如何讓團隊討論會議有效率且順利產出方案呢? 這時候，有目的性、經過設計、規劃的引導，就顯得非常重要。 大致步驟： ●理解團隊成員狀況、前置作業與授能 ●瞭解目前產品的屬性、需求與目標 ●可用資源的應用(空間、軟硬體、時間、物品.....) ●選擇合適的思考工具(影響地圖、使用者旅程地圖、同理心地圖、焦點討論法ORID、人物誌PERSONA、KJ法、GROW成長模型、六頂思考帽、價值流程圖、大型白板+便利貼.....等等) ●理出要進行設計的方向 ●各自發想，整合創意 ●原型製作 ●使用者驗證 盡可能的把時間拆分運用，分成每次會議2小時左右。團隊精神注意力集中，會議也較有效率。 降低開會時間最有效的方式，就是多點 事前準備 。 為了讓會議中保持有資訊、內容可以團隊討論，要先做會議前的資訊、數據搜集。 原則 - 線上合作、線下分工。 簡單介紹一下團隊討論每個階段的幾個重點。 ※理解成員、產品、資源、目標 每個會議都要訂目的和目標，確定後，設計引導流程，讓團隊能做有效的思考和討論，發揮最大的時間成本。 -成員 成員要確保四種角色的存在： 推動者、反對者、跟隨者、旁觀者 。 每個角色都要有，也要平衡。人對了，討論的氛圍就成功一半，場域自然會產生創意摩擦與火花。假如團隊真的缺少某個角色，會議前可以指某位成員為該角色。成員的個性也會決定討論的品質好壞。 -產品 成員的產品思維和觀點也需要進行改造，改變原有的工程...

【部門漸進式轉型敏捷團隊】 大家都有觀念也知道要漸進式變革，提高轉型成功的機會，尤其轉型面對的人數越多時，越是要一步一步踏穩前進，否則容易滑倒受傷。當然，如果已經到了生存關鍵時刻，那就需要大破大立進行變革。當然，這樣做的副作用也相對大。 雖然都知道要漸進，但要如何做呢?先簡單點，從同一個部門的層級開始思考就好。 假如，同一個部門近30人要轉型敏捷，你會怎麼漸進變革呢?或者是痛一次大轉型? 如果要一次大轉型，可能要先評估一下，部門會經歷的效能降低、幅度和成本，能不能承受的起?失敗的風險和轉型過渡期能不能接受? 以團隊發展模型來看，可能會有一段期間，團隊的效能降低50%，轉換成產出的話，價值可能會降低一半。 真的需要的話，可以參考規模化敏捷SAFe、NEXUS、LeSS...等等。這算是有系統、模式的變革，重要的是已經有前人的經驗為基礎，相對的也提高成功率。如果可以的話，最好是有經驗的顧問或教練帶著轉。因為就算是這些已經有一定方法、流程的大規模敏捷，還是有一定的前置準備要先進行。 像是，可能還要多個幾位敏捷教練或SM的輔助，角色、編制、組織多少都會影響，準備好後才能順利轉型。相對的，所付出的成本也會多些。 如果不要規模化，又該如何漸進變革呢?有哪些關鍵歷程必需經過呢? 如果沒有急迫性，又不必一次到位轉型的話，我們可以先從" 需求源頭 "轉型敏捷。再來進行執行開發層面的敏捷轉型，提供幾個其他想法參考。 情境說明：一個部門可能有30人左右(開發和營運)，想要進行敏捷嘗試。 步驟一：看板導入 先讓團隊習慣敏捷的一些文化和習慣，像是站立會議和回顧會議。不一定要一口氣全部導入，視團隊狀況選擇性加入，通常先針對團隊目前現有問題點去加強改善。 譬如說，團隊的開發狀態總是很混亂，在看板就可以引入回顧會議，持續追蹤改善項目。同時間，優化目前現有開發流程和工具。先把體質調整好，才能靈敏的動。 工作模式的轉變，有一個比較有趣的改變是， 過去大多是單人作業，敏捷元素加入後，多人合作的模式開始曾加，溝通的機會也變多。最常遇到的是大家不知怎有效的表達、理解。例如，Daily講不到點、Retro.痛點模糊說明，更不用說Planning一開始就要用Story來講需求了。 互動與溝通，也是需要點時間來練習、磨合，團隊在一致的頻道上，才能理解雙方的語言表達。 這階段可能會花個6個月左右...

【為何要敏捷?】 通常引入敏捷、對敏捷有興趣，大多是團隊已經遭遇到痛點或瓶頸。不知怎解決來嘗試一下，或是做了很多努力，但就是沒改善，所以來試試敏捷。 痛點可能如下圖，每個人都是自我為中心，每個部門可能都是一座座獨立的穀倉。只有「我」的概念，沒有「我們」的信念。 回想一下，目前是不是有這種狀況 ●一件小事，等了好久，繞了一大圈才收到回應? ●一堆事都忙不完了，還有一堆事懸在那，只能自己一直做? ●事情變來變去永遠做不完、做不對? ●重複、無聊的工作一直做，消耗了原本對工作的熱情? 可是.......， 敏捷不是解藥 。引入後，只會把目前痛點的現象更加確定、聚焦範圍。 至於要不要處理，能不能處理、有沒有辦法處理，則決定在於人身上。也就是說，敏捷有沒有效果是取決於人員有沒有決心、意願去動手改善。 為了解決這現象，敏捷刻意把團隊拉在一起負責、當責。同時也創造團隊成員許多時間來"認同"自己做的事情、"認同"自己的團隊、"認同"自己的產品。 當自己認同團隊後，瓶頸和問題就會主動的去想辦法克服解決。 當團隊認同任務後，效能和產能就會想辦法提高。 當團隊認同產品後，產品價值自然就會被提升。 這也就是從 「我」蛻變成「我們」的過程。 每個人腳下的圈圈已經消失，變成同一個團隊，變成一個大黃金圈。 每個人開始有不一樣的動作，不一樣的行動，多了份熱情。 事情不再只是被命令，而是我們自己決定。理解完市場和目標後，再決定怎麼做。 不過，這個過程需要點代價，對應到"塔克曼Tuckman團隊發展模型"，會經歷一段陣痛期，我通常稱為體質調整期。因為原本團隊的體質或習慣或文化，可能本來就有些壞味道。養成新習慣或方式時，產生的不適、排斥感，多多少少都會讓人想放棄或覺得無效。 如果能有個客觀中立的角色來協助、引導、點出盲點，就能縮短調整期時間和幅度，也就是所謂的教練或SM。想想小時候學騎腳踏車時，是不是也有個教練在身旁呢? 【結論：為何要敏捷?】 就我目前理解、觀察到的，肯定不是為了要有效率、創新、做對的事情、把事情做好、持續改善.......等等。大多是為了先解決"人員關係"問題，穀倉效應。都有著很明確很有效率的分工，卻沒有整合一起改善的意願，如同下圖。 老闆或主管大多是以One Team、「我們」先為出...

【團隊多元性雕塑】 一個團隊組成，假如成員個性上越是多元越能展現、激發創意，也就越有機會產出意想不到的產出價值。不過這樣的多元性有個困擾，那就是個性上的差異，在協作或合作中磨擦發生頻率較多，時間也較長，需要花較多心思注意成員彼此互動狀況。 常見狀況， 個性直接講話直率的成員，總是很有效率和善於分析。但當遇上個性溫和且思考謹慎的成員，兩方的溝通，由於直率者習慣於快速、精簡表達，常讓對方接不到話或者會錯意，造工作上的認知落差與做錯'方向的浪費。 又或者熱情且多想法的人，遇上較為冷靜旁觀的分析者，就會直覺對方都沒在用心參與的錯覺。 不同個性成員可以為一件事情帶來不同的角度和視野，更能全面檢視目前專案狀態，彼此也都能互相提醒和互補，好處遠大於壞處。如果可以的話，盡量在一開始組成團隊成員時，挑選或刻意分散組成。 當然，團隊剛組成時，我們可以做些小活動，提前避免或減緩未來的衝突。只要團隊知道目前團隊組成與樣貌，彼此都有心理預期，未來可能會和對方有所磨擦，需要彼此多些包容。 活動的重點，要讓團隊眼睛看見而不是想像。所以我們要視覺化團隊樣貌，帶個簡單小活動讓團隊彼此看見。 使用時機，團隊組成一開始時或者發生衝突時： ※流程 ●每人一張A4紙，寫下自己工作上的個性(直率、要求、效率、邏輯、仔細、慢條思理、被動、配合、努力、理性、感性、愛挑戰、負責、彈性、細心、碎唸、獨立、要求.....) ●如果有座右銘也可以寫下 ●每個人唸出自己手上的個性文字說明 ●唸完後，各自檢視自己個性是否與他相反。 - 如果是的話，站在對方的對面。 - 如果跟對方個性類似的，在站旁邊。 ●輪流唸完，站到相對應位置(薩提爾的雕塑概念) ●讓大家看見目前團隊組成樣貌，誰跟誰是對面、旁邊，未來合作上可能需要留意的 ●過程也會讓彼此了解工作習慣與個性(周哈里窗)，成員多一分認識、交集，合作上會更愉快、舒適有效率 ●可以請團隊反思一下，目前這樣組成的好處與壞處 ※結論 很少有團隊一開始就完美的融合、組成，透過小活動的潤滑有助於團隊正向發展。我們可以多多留意團隊目前發生的事件，找出最合適的活動，幫助團隊自己發現問題，不用急著介入解決現象的問題解。像這次活動，個性直率有效率的人，就自己提醒自己未來要再說清楚點。讓團隊自己發現、自己提出方案解決，永遠是最有效的方法。

【我們該如何讓Retro.回顧會議聚焦問題產出行動方案?】 平常工作場域中，常常看到會議是以檢討為主，要求要有結論為這次的執行的過程加上註解，強調的是結果，反而沒仔細檢視過程中哪些環節造成錯誤的結果。大多是在處理症狀解而非根本解，然後無限惡性循環。 所以，回顧會議一不小心也很容易被當成"檢討會議"，一種帶著濃濃指責意味，且指向大多是對著別人，你怎樣....你如何...都是你....等等。因為這樣的回應對大腦來說最輕鬆，沒什麼成本。也因為都是指向對方，彼此不會有交集、共識，更不用說行動方案的產生，問題持續存在。 從以上來看，不難看出會議中會面臨到的問題，一般有兩個議題要去面對， ●一個是問題容易延伸出更多問題，問題發散找不到有效的解決方案 ●另一個是問題變成情緒問題，彼此都站在對立面，沒法進一步思考下一步該怎做 針對這些現象，可以在會議開始前，先訂好回顧會議準則，引導成員應該要如何描述問題的情境。敘述的方式不同，就會讓成員有不同解讀去思考、回應問題。假如用的都是"你"開頭的句子，就容易引來不同立場的對戰。 反之，只要先訂好準則，不僅會更聚焦問題，也會讓接下來的問題情境描述容易進入反饋。 而這個準則就是以" 我 "或" 我們 "開頭，並且在講完問題後，也提出自己的想法、解法，不管有沒有用都可以嘗試提一下。我們通常要的不是"答案"，而是要讓大家習慣先思考問題，而非停在問題。這樣會有助於在執行任務時，即使面對問題，也會自己先思考如何解決。 當然，可以搭配團隊當下情況，找到合適的 思考框架工具 ，讓問題自然依循架構發展出答案。這種模式通常會再經過三、四次的回顧會議後，團隊開始習慣且正面、理性思考的情況下使用。 再來說說相對難處理的情緒問題， 回顧會議中出現情緒反應大多是好現象，表示大家願意、認真的正視問題的存在，不再漠視。只要出現這狀況，通常經過好的引導後，團隊大多會有驚人的成長與轉折。如果因此解決的話，整個團隊士氣會大增，也更有凝聚力，願意投入變革，行為也會變得積極主動。 大多想要引進敏捷做變革，無非有二個因素， 想要更好 或者 正面臨痛點 。大概7.8成以上是後者，一種不得不的變革。所以，在現有團隊、組織不變的情況下進入敏捷，在初期的幾次回顧會議可能會充滿著情緒發言。至少大...

【關於 使用者故事(User Story)的實際運用】 先從敏捷宣言切入，其中 個人與互動  重於  流程與工具 可用的軟體  重於  詳盡的文件 換言之，可用的軟體是互動、討論出來的，不是由企劃獨自規劃寫出。 剛接觸敏捷的人，可能會有些誤解與想像，會以為是不是就不需要規格書就可以進行開發? 當然不是，取而代之的是"溝通"，而 中間的溝通媒介就是"故事" 。 講一個故事絕對比描述一個需求來的吸引人。如果使用的故事會讓人想追問為什麼，這絕對是個好故事，而這一來一往的問答，就是溝通的開始。 故事應用在軟體開發，為了能更聚焦討論，我們會以"使用者"作為起點。 以使用者的角度出發，故事就有所依據和標準界定，描繪出更貼切、更合理的情境描述。 因為，只要不合理，一下就會被質疑，他真的會想要這功能嗎? 所以，在提出這個US前，要以這角色去蒐集更多數據來佐證，加強功能的合理性與價值。 使用者故事：我是誰___(角色)，我想要_____(功能)，因為______(利益/價值)。 在使用上有沒有種經驗，雖然格式簡單，但真的實際運用卻好像渾身不對勁?不知道要怎進行? 分享我的經驗讓大家參考，有二種使用情境， 一種是，PO/企劃   獨自準備好US、AC需求來跟團隊討論；另一種是，一群人的需求討論。 ● PO/企劃   獨自準備好US需求，準備好背景故事 可以把US當作"摘要"，拿來濃縮整個故事情境脈絡。也就是說，不能只單單寫下US，還要把上、下文表達清楚，而不是只丟一句US格式的文字，就想讓整個團隊對它非常有想法進而拆解出任務。 一句話的背後，上下文、數據、情境、流程圖、草稿圖..等，都會透過表達、呈現讓團隊知道，最後歸納出的US，會在Planning meeting時讓團隊來想像、發問、溝通、理解。 如果真的只有US一句話就給團隊，那跟 許願/隕石/命令 沒什麼差別。 ●一群人的需求討論，拿來收斂使用 團隊會先經過大量討論和探索需求，在團隊互動過程中，可能會畫出線稿，也可能會做競品蒐集、分析與討論。團隊經過一段時間發散、共識溝通，最後的收斂就會使用US來呈現與確定先前的討...

【敏捷前，先做好一件事】 檢視 千萬別被scrum看起來簡單的框架誤導，以為scrum的活動(Planning、Daily、Review、Retro)有進行，就代表敏捷了。而是要以當初進行敏捷的痛點或改善為指標，到底有沒有被解決掉，而非活動有沒有執行為依據。 以"為何而做"為依據，最好敏捷啟動前的檢視。 ※基礎檢視 細拆scrum可以分成四個面向，執行、驗證、需求、市場。以漸近變革過程的話，一步步把四個面向依序做好，先學會把事情做好，回頭檢視下做的對不對，會比較容易切入。再以工程來檢視執行面，要先確定是否有足夠穩定的開發基礎來支撐整個敏捷活動。 ※初衷檢視 有沒有在錯誤的出發點下套用敏捷?以為痛點用敏捷就能解掉? 舉個案例， 曾經輔導過團隊，想利用scrum來解決每個人工時不準確的狀況，甚至期望多幾次Sprint後，Task單上的工時就會準確。主管把每個人每個衝刺的總工時精算後，用任務單填滿，更鼓勵工時精確度頒發獎勵。 看別人的案例總是覺得很不可思議，再回頭想想自己，有沒有犯了同樣的錯呢? 敏捷不是解藥，它只會不斷的把有問題的現象加大反應、突顯出來。 在於有沒有能力去主動解決。敏捷前的心態、能力養成，是個很重要步驟，也很容易被忽略。 ※團隊層面檢視 ●如果還沒成立團隊， 要先檢視上、下層有沒有共識、支持、資源，否則就算進行敏捷，只是換個開發方式而已，體質沒變的話，可能會讓事情變更糟糕。一般來說，成員的第一個感受絕對是會議時間變多，沒時間執行，導致慢慢排斥、參與度低然後失敗收場。 ●如果是現有團隊， 要先確定一下目前 團隊的成熟度 ，到底禁不禁的起過渡的變革時期的低潮，撐不撐的過去，或者，目前團隊適不適合。 敏捷團隊的期待是，不需要其它單位的資源或協助，就能夠在團隊內完成所交付的事。假設不是這狀態的話，請先調整後再進行。 敏捷團隊的期待是，大家都能自主完成事情。這通常也表示，團隊成員有一定的成熟度和經驗，都知道自己該做些什麼。在執行過程中，可能會和別人互相影響、配合什麼工作，大致都能提早辨識出來。 反之，假如團隊成員經驗都相當資淺，現實面來說，就要考慮是不是真的要敏捷。有可能在Planning meeting時，成員就規...