黑先生

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

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

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