黑先生

先說說"觀點"這件事，觀點來自於自己過去的生活經驗累積，久而久之固定下來的慣性思維。大腦的反應時間最有效率也不會累，這樣子利於用來快速應對發生的事件，尤其是緊急事件，這樣才能提高自己的生存率。 想像一下，如果一杯水放在桌上，你第一眼和第一個想法是什麼，通常就是你習慣看事情的方式。也因為固定或者太習慣到無意識，所以也通常不容易改變。 如果想改變觀點的話，可以怎麼改呢? 心理、勵志類的書籍中，都會有很多激勵人心的語句，讓你讀起來特別有共鳴，心中會有很多莫名的舒壓療癒的感覺。尤其是搭配許多生動故事情境，這些情境都很生活化，甚至是常常發生在你我身邊，這就讓這本書感覺起來就是為自己寫的，開始與書本產生了共鳴和連結。 不過有點可惜的是，因為太療癒了，大腦就輕鬆了起來忘記思考，然後讀完書就就沒了，過個幾天就忘的差不多，遇到同樣的事情還是用一樣的觀點來面對，進入了解不開的循環。如何讓這類的書籍生活化的運用呢? 通常別人的說的話如果要能進入你的心，首先，他要先讓你感覺到你們是一夥的，站在你的角度同理你的心，說出你想說的話後，才給你實際的建議或行動。也就是說，先同理了你，再來談談你腦中複雜的思緒/事情。這樣也容易接收新觀點，改變自己固有的觀念，提高了改變的意願，進而做出行動。 最後再來說說怎運用金句來改變自己的觀點。先來看看這本書的標題，書名本身就定的很有哲理，讀完後，我試著把他重新拆解書名。與書的內容做個呼應，這樣閱讀書的內容也會比較有主軸可以對應。 如果拿裡面某個金句來呼應的話就是， 也就是說，你自己經驗產生的觀點，很容易限制你對事件的看法和行動，如果太局限的話，通常也得不到太好的決策和結果。 這時後就可以借助閱讀的力量，讓金句融成自身的經驗和觀點，提高做決策的品質。 這本書要怎麼運用呢? 書中提的故事走向似乎都是自己有個困境走不出來，那我們自我回想一下，過去的自己在面對困境時，當時是怎麼克服過來的。列出過去自己的困境點， 翻翻書中的金句，對應到每個困境點上，如果當時有人跟你說這句話，你會不會有什麼新的發現，有沒有可能做出不同的行動。讓書本的知識連結到自身的經驗，透過自我對話或互相交流內化，過程中會慢慢轉換成自己的新觀點。 以上為本書的操作，希望對大家有幫助囉~ 黑先生的FB

本書提供了63個模式，讓你能在擁抱改變路上不再孤立無援，用前人累積的經驗演化成"模式"，提供你在遇到阻礙時，可以對應嘗試處理。每個模式都簡單易懂，搭配著故事情境閱讀，很容易可以想像與運用。 不過，畢竟是組織變革或工作上的情境，難免讓一般人在閱讀時，比較不容易轉換成生活上的應用。所以，取其模式讓大家連結到自身過往的經驗。用個問句當做開頭： 人 生 難 題 路 上，你 都 怎 麼 做 計 劃 / 選擇 ? 反思一下，自己是不是都拿自身經驗產生的一些法則或應對，來面對與處理事情。 這樣其實很危險，因為會被局限，也容易產生盲點，做出主觀的行動，而非客觀了解問題後的行動。既然我們大多是靠自身經驗，閱讀也是種經驗，只要能擴充自己知識的視野，相對的自身經驗法則也會擴大，同時也變得更可靠、更多選擇來處理面對。 每本書裡其實都有個中心思想/主軸，主軸會有很多模式(故事)來支撐與繪出書本的輪廓，然後靠讀者自身經驗補上的想像來完成一本書的內容。同一本書，不同人讀起來可能就會有不同的想法，也會看見不一樣的觀點，強調的重點在每個人心中都不太一樣。這都來自於讀者的背景、當時的情緒或正遭遇到的事件，讓同一本書有不同的樣貌。 讀書會就是藉由不同的人不同的背景和觀點，透過互相的分享，試著找出書本想要表達的主軸。但其實更多時候是在藉由書和自己的故事/經驗，結合起來分享交流給其他人，擴大自己的經驗法則。 回到本書，書本直接整理、提供了明確的模式，讓我們可以直接使用，較不用費太大的心思找尋。那模式是什麼? 模式是許多相似的問題歸納整理出一套有規則可循的方法，可以套用在類似的問題情境上，產生類似的預期結果。簡單的問題容易用一個模式處理，那如果是複製的問題呢? 沒錯，就用很多模式來處理，看看書本的範例， 最後，要怎讓本書可以結合生活來運用呢? 只要把63個模式做成牌卡，當面對到事情時，一張張看看這些模式能不能幫你解決，會不會產生其它靈感，讓你能有所依據的面對、處理。如果有需要，也可以邀請非當事人，說明你的問題，通常對方會較客觀的給出較符合的模式牌卡。 試試以下問題，選擇你目前正在經歷的困難，翻翻模式，行動嘗試，與其卡住，不如試試~ 黑先生的FB

這幾年常常做工作坊與大量閱讀，開始對於工作坊有些心得，最近開始試著把過去看過的書籍做成迷你坊，大約1~1.5小時。 時間分配， 25%，講解。       拆解書本架構和文意講解，剛好自己過去工程師的邏輯派上用場，大多用上分類、歸納、演繹。 75%，互動。       從敏捷和團隊中嘗試了很多互動活動，再加上偶爾去外面讓自己保持新鮮，看看其他老師怎做工作坊，用了哪些技巧和工具，應用在工作坊的互動裡。 工作坊開始有了明確的定義： 把每本書拆解成，能夠讓大家分組實際應用、交流、互動。 有了課程後，當然就要找機會或者自己創造機會來實踐。剛好從敏捷《從1到100用心求變》一書中得到靈感，其中一個策略【自帶午餐】找到破口。開始利用中午時間，邀請大家透過書本創造交集，進行交流與互動。 有趣的是，在這樣時間與空間的工作坊，參與的成員大致可以分為三種 一、交流。中午空閒想多多認識其他同事，通常越陌生的人，有時會帶來新的觀點、火花，從別人那獲得自己的盲點。 二、學習。平常就喜歡閱讀，現在有了額外的機會多看一本書，算是不錯的投資。 三、解決。期望這本書能夠解決自己目前的某些困惱，不管是工作還是生活上遇到的。 儘管每個人的動機都不同，但參與的意願都是主動與自願的，都有著開放的心。只要大家能抱持著開放的心參與，基本上對於說書的人就不會太有壓力。 壓力在於講書的人自我要求，要怎麼同時間讓這三種人獲得一定的滿足呢? 剛好又從「 學思達 」中找到可以嘗試的方法。 學思達教學上課基本流程五步驟：自學→思考→討論→表達(以上皆是「學生」為主體)→統整(老師為主體) 因為只有中午速食時間，所以做了順序上的調整，但核心原則與學思達一樣。就是， 統整→思考→討論→詮釋(表達) 流程如下： 由說書人先統整、解構文意→提取書中幾個能夠讓人反思的觀點當做問句或演繹→分組討論、運用操作，連結過去自身經驗→過程中建立自己的觀點與模式。 最後，我把目前講過的書分成三大類，因為要能夠讓大家"操作"，所以選書也很重要。當然，有可能經驗越多，每本書都能夠操作，像樊登《讀懂一本書》說的，每一本書都自帶使命。既然都是作者用心創作有使命的書，花點思心應該還是找的出操作點的。我相信，教室的教課書都能用學思達翻轉，外面的書應該也都可以囉! "操作"有可能是  體驗、...

  【營運敏捷 Part 2 - 型式】 以營運為主的敏捷，會更著重在整個團隊要 找出對的事情 來做，每個人都相當清楚這個需求、活動怎麼來的，做了會產生怎樣的價值假設。 要這麼強調是因為大多數的組織分工都相當專業，也因為這個專業認知的框架，會不自覺的把非自己領域外的成員框在外面，貼上講太多也不懂的標籤，畫地自限了團隊的創意可能性。然後又不自覺的各自成了各自的穀倉，總是在應付資訊的同步和溝通，而不是討論產品該有的價值表現。 慢慢地變成了各自的事.....但有趣的是，到了最後面的產品上線後表現，竟然變成三不管地帶，沒有任何人的事，都是別人的事.... 以上的困擾，營運敏捷把這些都拉成同一個團隊的事，自己親手催生出來的活動需求自己做。開始有了化學變化，當營運有了開發的全力支援，能更夠迅速、精確得到上線後數據，即時做調整，成了一個正向循環。開發也因為共同參與了探索階段，所以都能夠正確的埋點，讓數據呈現更全面。 說穿了，其實就是每個人也都擔負一點點PO的職責，開發不僅僅只接收US聽故事，更是一起創造故事的角色。 運作的流程大致如下： 前面探索階段，是 數據驅動 中間設計階段，是 設計思考 後面執行階段，是 DevOps 最後持續改善階段，是 數據+系統思考 看起來很威?? 其實都是在每個階段有這些觀念、概念就好，至於需要多深入，端看產品和團隊的實際狀態。畢竟每深入一點，花的時間成本就會多一些，剛剛好就好，取適合要用的元素慢慢加入。最好的判斷加入點就是，當某個 現象 反應後，再去加入可以解決的元素就好。 舉例來說，我們第一次衝刺其實是著重在 設計階段 ，加入些設計思考的元素。當團隊都很滿意自己發想的活動沒有如自己想像的熱烈，或者不知道為何好或不好，不知道有沒有打中要的TA。這時候，就會開始把 數據驅動 加入，也就是要驗證、衡量活動的價值。 ※結論 我們的教育讓我們對於 解決問題 很厲害，但很少教我們怎麼 定義問題。 可能會變成我們總是不斷的在花時間證明它的對錯，而不是花時間思考它的價值。有很多做事的經驗，而不是很多創意的想法。如果團隊有一定成熟度的話，不要框住他們的潛力，只要告訴他們魚有多好吃，團隊自己會想出方式補魚的，連釣竿都不用給。只要有安全信任、允許失敗的環境，他們會自己長出價值的翅膀。 下一篇： 營運敏捷 Part 3 - 營運地圖

【營運敏捷 Part 1 - 準備】 ●建立安全信任、大膽嘗試、允許失敗的環境 ●以數據迭代持續改善 是進入營運敏捷前的基石。 開始前，我們得先承認、認清一件事實，我們面對的是VUCA市場，絕對不會有完美100分的策略、需求。再說"分數"也是在過程後才打得出來，不會一開始就能判斷分數，需要上線驗證，由玩家、消費者來評斷。 既然不能期待有完美需求，至少也要程度以上，風險相對小。如 上一篇 描述，會希望由團隊一起釐清、探索出高品質的需求，共同面對VUCA的市場，而不再只是一位PO決策。期望利用團隊多元觀點的特性，一起探索、設計，定義出團隊都認同的需求。 PO其實可以是一位角色或者是一個代表團隊，代表團隊意思是，PO跟另外一群人一起討論、決策。當然，如果一位PO很厲害的話，會大大降低討論的時間成本，不過相對的，PO會間接承擔較多的產品成敗責任。這感覺很奇怪，既然都已經是自我組織的敏捷團隊，那由團隊整體來承擔會合情合理些。 通常，PO給的需求越精確越仔細，團隊其他成員就越覺得產品不關我的事。 在營運敏捷，我們同樣也會有一位PO，但主要是定市場方向不是需求，團隊會一起不斷探索、討論、驗證、修正這條方向。團隊一起承擔需求品質，如同要求產品品質般。有些不同的是，需求的品質較難以在事前精確的衡量判定，有時需要帶點創意，才有機會創造出新價值。 所以， 團隊安全信任的環境是首要、必要的。 沒有人會因為做出錯誤的決策而受到懲罰，只要能不斷精進改善。 沒有人會因為承認錯誤、提出問題或提出新想法而讓大家感到尷尬或受到懲罰。 你在裡面會很自在的發揮自己的所有能力、甚至超過。 先安全信任，才能合作創新。以它為基礎，就會有意願大膽嘗試。而嘗試後允許失敗，團隊才能從經驗中激發創新。 當環境具備後，方法就能發揮該有的效果。從滑板車演進滑步車，"迭代"演進是大家熟悉的觀念。 那具體的方法、內容，到底是以什麼為演進的依據呢? 不斷的修正需求?怎修?市場回饋?不好怎修?下一個方向? 不可能一直試錯迭代，畢竟資源是有限的。背後使用的方法，除了大家較熟悉的Review meeting，這個會議算是執行後的結果。另一個是事前規劃，以" 數據驅動 "為基礎發展出的需求。事前、事後搭配使用，才能有效試錯，讓資源運用最大化。 如果說，產品開發階段是用...

【營運敏捷 Part 0 - 前言】 為何我們既然面對的是VUCA市場，卻相信只要一位PO的專業就能看清市場變化Do the right things? 為何我們沒有懷疑PBI的優先序與價值?PO決定好需求，就期待團隊能Do the things right? 為何我們會認為PO描述、解釋US完後，就期待團隊能理解與認同需求的價值?然後開始有想法?對產品有了連結? 為何我們大多是在關心產品的品質而非需求的品質? (如果團隊成員對於需求的理解還是僅止於這是PO的需求，這現象是不會消失的。) 敏捷團隊角色中雖然有一位PO專責在跟利害關係人和市場變化、需求，但也因為這明確職責界線，讓其他成員有時太過相信或依賴PO的決策。 好一點的Planning meeting，可能會在多講一些需求US的WHY；更好一點的會再帶入數據背景；通常大多是看到產品現象後，PO依據經驗判斷，需求這樣做有機會改善。 如果PO的能力與經驗夠專業，產品發展大多不會有太大的問題，就是快速迭代驗證、持續改善。但這樣的PO可遇不可求，有這樣的PO在團隊內，公司上面層級大多也都是信任授權，讓團隊照自己的方式去發展產品。 (敏捷團隊成立後，不同階段有不同的課題) 更多的團隊PO可能是企劃為主的專案管理，對產品也是有一定的理解，但對市場的掌握可能就沒那麼熟悉。這時，如果能加入營運的元素在敏捷中，像是一些營運常用的指標DAU、MAU、ARPPU、次流、回流、持續、新增...等，當作需求的原因或驗證，團隊也會有追求達標的依據。 如果套用US的格式來看的話，我是___我想要___因為___，其中的"因為__"可以用數據來表達。 更重要的是，團隊能更理解為什麼要做這些需求，更理解與認同產品，自然而然的在開發執行上就會更積極主動。 既然敏捷團隊的最終是自我組織，除了對於產品的品質負責之外，更需要要對需求的品質負責。 最理想的狀態是，需求發掘、定義是由團隊成員一起投入、參與，而非只有一位PO。PO放入的重心、比重會多，但其他人絕對不能是消化需求而已，進一步要理解WHY，更要利用團隊多元特性，一起挖掘、探索需求的盲點。 (團隊越成熟越有機會一起面對需求、市場，進化成商業思維) 好的需求品質才會有好的產品品質、價值。 要如何有好的需求品質呢? 設計思考、數據驅動加入在Planning meeting或需求源頭...

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