infoq
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nhumble：在演講中，我引用了 douglas hubbard為cto雜誌寫的一篇文章，douglas hubbard是優秀著作「how to measure anything
」的作者。「即使專案中有著非常不確定的開發成本，我們也沒有發現這些成本對投資決策有著重要的參考價值……唯一重要的未知因素是專案是否會被取消。次重要的是系統的使用，包括如何快速推出系統和究竟是否有人在使用系統。」我們陷入這種局面是因為度量成本相對比較容易，而商業價值（根據 roi、生命週期利潤度量，或者任何你在意的產品度量值）則更加的困難。
\u0026#xd;\n\u0026#xd;\n
不能充分理解的是，無關緊要的初始開發成本有哪些。對於乙個成功的產品，不斷的開發和維護成本將會消耗初始開發成本（企業通常會花費70-80%的 it預算來保持正常生產和擴大現有系統的產能。）對於乙個不成功的產品（大部分是他們這種產品），這是一種沉沒成本。不幸的是如果專案取消或者產品沒有使用，企業往往不會評估開發成本並將其作為限制不利因素的方法。如果他們這麼做了，他們就能更好地開發原型，與實際使用者一起驗證產品的假設，而這正是精益創業（遵循數十年的良好實踐，從 winston royce的原創「瀑布式」**開始）提倡的。
\u0026#xd;\n
infoq：更重要的是我們如何擺脫它，專注價值而不是成本。對此您有什麼好的建議嗎？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nhumble：我認為從根本上來講，你需要確保客戶會為你解決的實際問題買單——要麼錢要麼時間。許多產品——包括內部 it系統——在這方面做得非常不好。內部 it的標準化常常讓問題變得更加的糟糕——人們被迫使用沒有考慮他們需求的設計系統。作為乙個行業，我們應該發現需要解決的實際問題，從而更認真地考慮使用者體驗，然後決定有效解決問題需要的最小工作量。jeff patton討論了最小化輸出和最大化成果。
\u0026#xd;\n\u0026#xd;\n
infoq：您提到對工件的共識非常的有價值。您能舉例說明一下嗎？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nhumble：在敏捷方法中，使用者故事卡片是經典方法中的乙個方法。正如之前 ron jeffries指出的，故事卡片被設計成一種令牌，用於交流的提醒。令牌不是規範文件——交流產生的共識才是。任何文件都不能取代共識——需求文件從根本上是抽象洩漏（leaky abstraction）（這並不是說他們沒有用，他們只在擁有共識的情況下才能發揮作用）。影響地圖也一樣——影響地圖練習的關鍵是通過行動產生的共識，這種共識不是由影響地圖產生的，它只是我們交流的一種提醒令牌。
\u0026#xd;\n\u0026#xd;\n
有觀點認為交流和共識是重要，但會讓很多人產生焦慮，尤其當你要大規模處理構建時。需要建立共識的通訊頻寬將以指數方式增加團隊規模。解決方法不是建立更多流程——文件不能取代共識，相反，應該精心架構（包括系統和組織）從而減少更小、跨職能團隊之間的依賴。分布式系統的興起更加暴露解決這個問題的急迫性，分布式系統架構對組織架構有很多重要啟發，但是許多組織仍然沒有重視這些啟發。
\u0026#xd;\n
infoq：您能解釋一下當你不知道你的客戶真正需要哪種特性時，就會產生浪費?
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n
infoq：您能舉例說明如何以低廉的代價快速發現客戶需求？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\n隨著產品的發展，與科學一樣，設計優秀試驗成了最難的部分，但是它為快速挖掘偉大的產品提供了最好的機會。然而，這些仍然沒有普遍實行或者可以在商學院學到，人們仍然感覺非常的難以做到，可能是因為它需要創意而不是執行千篇一律的過程。
\u0026#xd;\n
infoq：您在演講中提到了改進kata的概念。您能簡要介紹一下它，並展示如何使用它實現持續改進？
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n\u0026#xd;\nhumble：改進 kata是用於工藝改進的一種科學的試驗方法，是一種反映產品開發的試驗方法。在 mike rother的著作 toyota kata書中有詳細描述，在他的**上有許多免費可用的創意共享材料和練習手冊。rother花費了很多年的時間研究 toyota如何通過製造比對手速度更快，更便宜，但是質量更高的汽車，從而持續保持市場領先地位。
\u0026#xd;\n\u0026#xd;\n
他發現 toyota管理者不會告訴員工如何開展工作。相反，組織內的人們共同努力，建立乙個長期挑戰（明確定義的可度量指標）。然後，在專案或者團隊層面，他們從記錄目前的工作過程開始，然後為過程設定短期可度量的目標，這個目標可以幫助他們完成挑戰。管理人員的重點工作是當員工嘗試試驗完成目標時提供支援幫助。
\u0026#xd;\n\u0026#xd;\n
改進 kata的關鍵在於將過程改進工作作為每個人日常工作的習慣性的一部分。rother指出，如果我們不能一直努力改善我們的過程，他們就會逐漸僵化——尤其是在面對我們組織變化狀況時。有效風險管理是一種需要持續努力評估和改進過程的活動能力，這不能通過指揮和控制的方式有效完成。相反，操作過程的人必須擁有嘗試改進的權利。
\u0026#xd;\n\u0026#xd;\n
在我寫新書的時候最打動我的是， 精益企業也發覺到用於工藝改進的試驗方法與企業比如 amazon開創的用於產品開發的試驗方法的相似之處。他們都提供了一種實現高彈性和適應性強的大規模塊織的方法——這是瀑布式或者當前敏捷擴充套件框架的替代方案，實際上他們幾乎不能破壞如今在許多企業盛行的高度封閉的、指揮和控制資訊流和決策。
\u0026#xd;\n
檢視英文原文：moving fast at scale
大規模快速發展
infoq humble 在演講中，我引用了 douglas hubbard為cto雜誌寫的一篇文章，douglas hubbard是優秀著作 how to measure anything 的作者。即使專案中有著非常不確定的開發成本，我們也沒有發現這些成本對投資決策有著重要的參考價值 唯一重要的未...
Facebook 如何實現大規模快速發布
不久前有篇關於縮短 facebook 發布流程的文章，闡述了將 投入生產的靈活方法。這篇文章著重講述了他們在一年之內如何從 cherry picking 公升級到 push from master 策略。早些時候，facebook 也 分享了他們部署過程的細節。作者 chuck rossi 是 fa...
Facebook 如何實現大規模快速發布
不久前有篇關於縮短 facebook 發布流程的文章，闡述了將 投入生產的靈活方法。這篇文章著重講述了他們在一年之內如何從 cherry picking 公升級到 push from master 策略。早些時候，facebook 也 分享了他們部署過程的細節。作者 chuck rossi 是 fa...