關於教練這件事，這是個人第4版MVP | IDCF

時間 2021-06-18

標籤微信併發框架工具學習測試優化職業規劃 spa 設計欄目職業生涯简体版

原文原文鏈接

關於教練這件事

冬哥最近在學教練，這件事反覆在說。一方面是由於本身在學，因此意圖與注意力都聚焦於此；另外一方面也是廣而告之，給本身打上專業教練這個標籤。微信

最近給FDCC羣作了幾場教練對話，過程當中有同窗問，你是怎麼一路走過來的。當時沒有直接答覆，那麼這篇文章以教練這件事爲例，說說冬哥是如何作的以及計劃如何走的，看成是對這個問題的回答。併發

簡單說說什麼是教練

教練與客戶在一個發人深省、充滿創意的對話過程當中合做，最大限度地激發他們我的和職業的潛能；框架

教練支持人們發展自我和績效，明確他們的目的和願景，實現他們的目標，發揮他們的潛能；工具

教練經過問詢、有目的的探索和自我發現來提升覺察和責任感，目標是客戶的行爲改變；教練經過提出有效的問題，開放式問題幫人們本身找到答案；學習

教練是一面鏡子，讓對方經過鏡子看到本身；教練相信人們像一顆橡樹種子，蘊藏着全部成長爲大樹的潛質。測試

教練這款產品的研發階段

教練有不少流派以及門類，冬哥學的是埃裏克森的教練體系。四個模塊學下來，在課上也作過多場教練對話練習，課下也有參加集訓營與教練同窗互練。因爲你們都學習過教練，對教練是什麼、作什麼、有什麼流程，都有統一的認知，因此預期比較容易達成一致。優化

這個就像給敏捷教練解釋什麼是敏捷，給DevOps工程師介紹什麼是DevOps，雙方對於敏捷/DevOps都在一個水平線上。但若是你給領導解釋什麼是DevOps，給業務聊持續交付是個啥，或者給客戶介紹爲啥要作轉型。這就有點雞同鴨講，對牛彈琴，對方以爲你沒說人話了。職業規劃

但敏捷和DevOps圈子以外的人，纔是你真正的受衆，纔是會爲此買單的人，不管是做爲上級或同僚承認你的價值和付出，仍是做爲客戶承認你的服務與工具。這個羣體纔是外面真實的世界，只有可以向他們解釋清楚，或是讓他們感覺到DevOps的價值，你纔算真正上道了。spa

因此若是教練這件事對於冬哥來講是一款產品的話，此前的學習階段以及與教練同窗之間的互練，都只能算是這款產品的研發階段。而進入真實世界，找到真實客戶，接觸真正最終教練的人羣，越早讓他們感覺教練過程，進行教練對話，而且最關鍵的是要「說人話」，就能越早獲取反饋。這些信息，對於當下的學習，以及對將來的應用場景的判斷，以及對自我狀態的感知，都會極具價值。設計

這個過程，也就是冬哥教練產品從研發階段走向發佈的階段。那麼該如何發佈這款產品呢？既然冬哥的老本行是DevOps，固然就以DevOps的方式來作啦。簡單地講，就是小步快跑，堅持持續發佈MVP、持續獲取反饋、持續優化迭代。

MVP入門123

MVP用1句話講，即最小可行化產品。

MVP基於2個基本假設：價值假設，意味着用戶真實地使用這個產品或服務，對用戶是有價值的；增加假設，是指實現產品快速增加的一種手段，也須要不斷驗證。

MVP分爲3步對上述兩個基本假設進行驗證：定義最小的功能集，聚焦最核心的用戶；數據收集和測度，與預設指標進行比較；經過快速學習和迭代，不斷實現對認知的深化，不斷逼近一個真實的解決方案。

（關於MVP詳細的內容，能夠學習Eric Ries的《精益創業》一書，或是IDCF那本著名的《敏捷無敵之DevOps時代》，有一個章節總體介紹精益創業與MVP。）

第1版MVP

如何把大象裝進冰箱，比較簡單，須要三步。如何把冬哥教練這款產品，發佈給真實客戶，會複雜不少。

「聚焦最核心的用戶，肯定數據指標，定義最小的功能集，快速迭代演化」，這些都是須要在每個MVP版本考慮的問題，而基本思考的順序也大體如此。

首先須要考慮人羣，既然教練有其知識背景，因此爲了最大程度地下降發佈門檻，冬哥決定第一個MVP選擇教練同窗做爲發佈羣體。

發佈的目的，就是從有背景預設的教練同窗的角度，看看冬哥教練這款產品，是否有吸引力，是否可以爲真實客戶所理解和認同。因此想要收集的信息，是你們對此的反饋。

最小的功能集，這個此前就考慮過，一篇招募的文案是投入產出比最高的。

基於上述思考，冬哥用幕布寫了一篇招募文案，併發到關係比較好的一個教練同窗羣，裏面大概有10人上下，並很快得到了反饋。

收到反饋後立刻抽空修改，發佈了第二個版本，從反饋看，文案基本受到教練同窗的承認。

第一個MVP從策劃到兩次的發佈，先後歷時1天，即需求到交付前置時間Lead Time。

第2版MVP

接下來考慮下一步的發佈人羣，教練同窗並不是是要招募的客戶人羣，冬哥須要找真實客戶。而這類客戶，最好對冬哥較爲熟悉，不須要在介紹「啥是教練」的同時，還得回答「冬哥是誰？！」的問題。因此IDCF的學員羣體是不錯的選擇，而其中FDCC羣體是認同感最強的，因此肯定先行在FDCC羣裏發佈。

那麼這個版本採用什麼數據指標呢？既然是客戶招募，最直觀的指標固然就是招募來的客戶數量了，因此選擇客戶與話題數做爲本階段MVP的衡量指標，用行話說就是拉新數量。

產品功能也想好了，招募是一個入口，海報結合金數據報名，是冬哥最常使用的方式，目的純潔，功能清晰，流程順暢，分工明確。

接下來就是海報產品的開發。冬哥是業務方，負責提需求；同時冬哥是金數據表單的開發者，而小柒是海報的開發者；海報與金數據（二維碼）的集成測試以及海報質量驗證，由冬哥和小柒結對完成；海報的發佈和後續運營，也是冬哥負責。這就是所謂的「功能清晰，流程順暢，分工明確」。

題外話

在其中一場教練過程當中，有學員提到本身作DevOps最終的目標，是可以支持研發組織隨時起一個項目，那麼上述的過程就是一個參考：

你須要儘量的全棧工程師：冬哥兼任需求、開發、測試、發佈、運營數職；同時若是審美足夠，能夠製做海報，就不須要等待小柒的檔期，也能夠節約相互溝通和來回修改所花費的時間。

你須要權責明確的分工體系：作海報這種事情，冬哥知道應該找小柒，而小柒也不會辭讓。可是海報的主題和內容具體寫啥，確定是冬哥須要搞定的事情。

你須要明確的輸入輸出標準：需求轉開發，開發轉測試，測試轉發布，每一個階段的輸入和輸出，即DoR和DoD，都相對明確；而且最終的驗收人是需求方，即冬哥，而發佈後的業務結果也是冬哥負責，所謂管殺也要管埋，不存在責任推諉。

你須要有趁手的工具和平臺：幕布是冬哥進行內容製做的平臺，金數據是報名平臺，稿定設計是海報製做平臺，微信羣是發佈平臺。

因此若是你要打造的是一個DevOps平臺，可使能團隊即插即用即走，須要考慮的是人員能力、平臺能力，以及流程銜接。更重要的，是團隊協做的文化和氛圍，以及團隊內部彼此之間的信任。

回到正題，通過快速兩輪的微調，隨後的海報的正式發佈版本以下。發佈到FDCC微信羣，當天就收到了8個話題提交，仍是很受歡迎的，本輪的MVP超出目標預期！Lead Time，2天。

第3版MVP

客戶和話題都有了，接下來就是如何交付教練對話。考慮到是首輪的真實客戶對話，從提交話題中選擇了相對適合教練對話的職業規劃方向，恰好提交的有幾個。

本輪須要發佈的MVP就是首輪的教練對話交付，目標人羣鎖定在2-3位職業規劃方向的FDCC同窗。考察指標有兩個方面：第一是客戶滿意度，這個相當重要，畢竟教練的目的，是能夠支持到客戶的話題；其次是我本人對教練過程的滿意度，例如完整度、教練能力體現、我的短板覺察等。相對來講都是非量化指標，但兩個滿意度均可以感覺到，能夠給本身打分，以這種方式考量，在本階段也能夠接受。

發佈交付以前，須要的前置活動（也就是開發的工做量），主要是對話題的準備。這個過程主要作了三件事情：

首先，本身進行了梳理，對職業規劃的話題，能夠用到的框架和模型，能夠從哪些方面進行探索；
其次，找了三位老師，分別諮詢了TA們對本話題的建議；
最後，我本身做爲客戶，找了教練同窗，針對本話題進行了三場教練輔導，但願經過不一樣的教練過程，從不一樣的角度對同一個話題進行探索；每個教練的風格以及創造體驗的方法都不一樣，而每一次我本身對於這一話題的認知程度也都不一樣；經過三場教練對話，但願將這個話題打穿。

上述的準備工做以後，我的感受已經達到了交付的程度，因而安排交付了三場對話。每一次都用到了不一樣的模型，並根據每一次的交付感覺和反饋，進行了適當的調整。

兩個指標的考覈結果：客戶滿意度，一場70-80分，另外兩場90-100分，總體超出預期；我的滿意度給本身打70分，整體仍是有不少須要優化的方面，尤爲是三場的教練時間都較長，抓核心要素，創造覺察的能力有待增強。

第3版的MVP也算順利交付經過，自海報發佈到完成三場教練對話交付，Lead Time一週。