關於"敏捷方法"在網上、書中有非常多非常詳盡的教學和案例，很多公司也開始意識到其重要性，並試著將團隊轉化為敏捷團隊。當然因為"只緣身在此山中"的緣故，多數團隊依靠自身力量是無法達成一個有效轉化的，不過這也就是我這種"敏捷教練"存在的價值和意義了。
今天我要分享的是用敏捷思維幫助團隊做的一個小例子，同時也是我自己在"敏捷方法"之上提出的一個簡單模型。之所以拿這個來說，是因為在我之前從沒有人提過這個模型——換句話說這是我首創的，所以感覺更能體現我對于敏捷實踐的深度挖掘能力。
如果你也在快速發展的網際網路團隊工作，尤其你面對的又是一個各種生產力工具層出不窮、團隊本身更迭也很快（天天有人離職有人加入能不快麼）的環境，ICPO 模型對於你快速與團隊建立起流暢的工作流就尤為重要了。
I：Input，輸入。你所屬環節/職位所需要的前置資源和依賴，同時是你前一個環節/職位的輸出成果
C：Comprehend，理解與掌握。是你圍繞需求/任務能夠有效理解其需要和含義
P：Process，處理與執行。是在理解需求/任務的基礎上在你環節所進行的有效處理
O：Output，輸出。你所屬環節/職位的輸出成果，同時是你下一個環節/職位所需要的前置資源和依賴。
其中 I/O 是標的，而 C/P 是行為。
這個模型的誕生原因我可以用以下幾個工作中經常遇到的"糾紛"來引出：
開發對設計：你把 icon 傳到 iconfont 上去啊。
產品對老闆：你這個想法的業務來源和背景是啥？業界裡我找誰能快速了解需求根源？
設計對產品：這裡的頁面跳轉關係是啥？有沒有個靜態交互圖？
產品對開發：測試包連結呢？
這些問題在流程規範健全的大公司裡根本不存在，而在流程規範缺失嚴重的小公司裡卻會帶來相當多的內耗。如果從需求源-產品-設計-開發-測試這個流程來看，每個前後相關的環節之間每天用於溝通這類問題的時間將會在你的迭代中佔據相當一部分。更嚴重的是，成員的精力會被不斷分散、情緒不斷負面，導致剩餘的有效工作時間內的工作效率也會降低，結果可想而知。
為了解決這個問題，我並不打算自己整理一份"你們應該這麼做"的流程規範去讓團隊遵守並執行，因為我認知中的"好"對於不同環境中的成員並不見得就是好的，這樣也不符合敏捷精神中的"自組織"期望。所以我提出這樣一個模型依據，而把具體的討論和結論放給成員自己去做。
這個模型的概念就是：每一個環節要和自己前後環節通過對工作習慣和交付標的的充分溝通、相互兼容，來達到環節之間交付標的的相對標準化。
case 1：從產品經理到設計師
設計師的輸入是產品需求（文檔或者原型），有的設計師只需要一個低保真線框圖，因為產品經理輸出高保真原型可能對 ta 產生先驗影響，導致自己的用色、風格等受到影響；而有的設計師可能就需要高保真原型，因為 ta 在理解需求的基礎上也想看看產品經理的具象概念是怎樣的，從而使得自己的設計會更加符合產品經理的預期。
這時候進行充分溝通，產品經理表達清楚自己出具高保真/低保真原型的原因是什麼、ta 是怎麼想的；設計師表達清楚自己希望接收到的是高保真/低保真原型，原因是什麼。雙方確認最終交付標的——文檔、線框圖、原型、交互圖，抑或口頭表達就足夠了——達成一致後，成為此兩個環節之間的 API，無多餘、無不足。
case 2：從設計師到開發
有的前端開發只需要 PSD 文件就可以了，因為 ta 自己會切圖；而有的前端開發不具備 PS 知識，ta 覺得用 Zeplin、藍湖 等工具會更方便而且可以統一管理。有的設計師習慣用 Photoshop 而有的設計師 習慣用 Sketch。為了優化資源體積，icon 一般又會放到 iconfont 這類平臺上使用。這些因素都會因為各個公司的員工習慣而產生差異。
這時候需要設計師跟開發進行充分溝通——你覺得我交付怎樣的標的物你最方便，但是你說的這種又不是我會用的工具，我們找一個能滿足我們雙方的工具是不是更好，等等。達成一致後，成為此兩個環節之間的 API，無多餘，無不足。
產品經理跟開發之間就更不用說了，你以為一個輸出一份版本號、發布時間、功能調研、相關數據、測試用例的需求文檔的產品經理就是一個優秀的產品經理，可開發並不需要看那麼多廢話，ta 只想知道功能點和各狀態及對應結果；測試也只想看測試用例，並不需要知道開發這個功能點的用戶調研數據是什麼。至於老闆要求這樣——那我覺得你可以換一個更好的老闆，而不是按 ta 的標準輸出一份 ta 自己都根本不看的標的物。
至於 C，則是對於所有環節/職位都必須對整個工作流負責的要求，這是一個跟交付標的的量化標準無關但是跟一致性有關的事情——任何一個參與任務的人，都必須要充分了解和掌握這個任務的根源、現有資源、含義和目標。只有如此，才能保證你的 P 是有意義的，如果不了解需求，你做也是盲做，做出來的結果也往往南轅北轍。很多人喜歡追求"結果正確"，我的思路恰恰相反——如果過程正確了，結果就不可能錯到哪兒去；如果你只追求結果，過程中遇到任何一個意料之外的問題都可能會把你打回原形，任務推翻重做，在不確定性高的業務上的需求更是如此——想想你是不是有過痛徹心扉的經歷？
在現在的團隊中我的角色更像是一個過程觀察者和輔助角色，只在成員遇到困惑或者鑽牛角尖的時候才會根據自己的經驗進行點撥——而且每次我依然會強調，我的經驗只是給你一個參考，鑑於你可能沒有過相關的經歷和認知，而我需要的是你在此基礎上能夠想出來屬於你自己的方法，把我的東西忘掉。
敏捷是一個不斷精進和遞歸的過程， ICPO 模型可能是我目前為敏捷方法提供的第一份貢獻，希望以後還會有更多，這才使我本身也更符合敏捷宣言的倡導——我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。它也是開源精神——自由、分享、尊重價值——的一種體現。
PS：本篇文章通過 iPad Pro gen3 with Apple Pencil & 羅技 K380 編輯而成，這一周中 iPad Pro 已經完全替代了 MacBookPro 作為我的日常辦公工具，對於不用寫代碼、無需本地編譯的工種——尤其以 碼字、項目管理、學習、設計、圖片編輯等工作為主的——已經完全可以無縫切換到 iPad Pro。它只是另一種形式的生產力工具，和 Laptop 不論高低，各有優勢。