Engineering Culture Podcast：David Hussman與您探討有效產品發現和Dude公式

這裡是Engineering Culture Podcast，由InfoQ.com以及QCon大會共同呈現。\

在這期播客中，InfoQ Culture \u0026amp; Methods的主編Shane Hastie對話DevJam及CardBoard It!（一款故事對映工具）的創始人David Hussman。\

關鍵內容

• 把價值放在首位：這不是為了創造更多的產品，而是為了保證我們可以因人而異建立正確的產品 \
• Dude公式：價值 = 為什麼這麼做/如何來做 \
• 評估產品對於人的生活產生的影響 \
• 使用最簡單的方式和“最精簡的可行學習”來最小化複雜度 \
• 完成有意的發現：使用交付節奏來加快學習週期，緊密耦合地設計和交付sprints \
• 僅僅“完成”是不夠的，當物品經由真實客戶的驗證之後才能提供價值 \
• 驗證可能會在發現和交付的時候發生

這裡是原文中的音訊連結\

筆記

• 1分09秒 重點從構建產品轉移到構建正確的產品\
• 1分41秒 介紹“Dude公式”：價值 = 為什麼這麼做/如何來做\
• 3分02秒 考慮產品開發的意圖，而不是過程\
• 3分17秒 專注於產品，而非過程。考慮開發產品的意圖，確定產品將產生的影響\
• 3分30秒 大的“轉變”往往是永無止境的，而且不會非常成功；成功的產品可以影響到一個人，可以讓他過得更幸福\
• 4分00秒 宣佈一本正在籌劃中的新書，書名叫《產品\u0026gt;過程》\
• 4分28秒 我們正在努力，拒絕“敏捷”的過度使用\
• 4分40秒 一個有價值的產品總能找到團隊、產品及技術之間的正確對映\
• 5分00秒 “一個團隊、一種技術、一個產品”的簡單觀點在當今複雜的世界中並不現實\
• 5分27秒 外推到一個產品多個團隊時面臨的最大挑戰是，基於大型“系統”的組織的產品不清晰可見\
• 6分02秒 意外複雜性（引用自Fred Brooks）或“偶然的複雜性”\
• 6分35秒 克服複雜性的技術，如MVP和小的產品分割。將客戶旅程視為“最精簡的可行學習”\
• 6分43秒 複雜的問題是可以解決的，但是複雜性是不能解決的\
• 7分08秒 探索最精簡的可行學習的想法：消除不確定性\
• 7分37秒 人們經常過度複雜化MVP，卻不把它當做一種技術來學習\
• 7分55秒 即使尚未投入生產，使用故事對映等技術可以最小化進行真實人物驗證的\
• 8分35秒 學習於生產之外，但不要重複九十年代的錯誤，把原型開發當成“交付不成熟的程式碼，並在此基礎上疊加”\
• 8分50秒 現在我們使用的工具都是高質量的，並且發展迅速，可以幫助實現有意的發現-交付週期\
• 9分09秒 通過實時原型、A-B測試、客戶訪談等技術縮小交付之外的不確定性\
• 9分25秒 更多的軟體開發人員需要轉變為產品開發人員，瞭解人們的需求，並在程式碼之外驗證其中的一些需求\
• 9分54秒 解決誤解的方法是提前進行大設計\
• 10分00秒 不同之處在於用於設計和發現上的時間比\
• 10分08秒 以設計sprints為標準，規劃交付sprints，降低設計sprint中的不確定性，確定交付sprints中學習到的內容，將新的不確定性反饋給設計sprints，儘量使用潮水式方法處理事件，避免使用序列化方式處理事件\
• 11分08秒 “完成”和“已驗證”之間的區別\
• 11分25秒 從使用驗證過的想法轉向測試驅動產品\
• 11分40秒 “產品影響驅動開發”的觀點：在開始構建之前先確認衡量它的影響的方法\
• 11分55秒 在發現階段的早期進行驗證，或是在交付階段驗證產品\
• 12分07秒 產品已完成通常代表著“我已經做完了這個產品”，但並沒有評估交付的價值；產品管理應該從驗證開始，而不僅僅是單純地構建產品\
• 12分50秒 期望產生的影響很大，但是積壓的專案太多需要處理難以達到期望的影響\
• 13分10秒 有少數小型的團隊已經在採用這種方法，但是大多數的組織仍然在學習這些概念（例如Netflix）\
• 13分35秒 Netflix之所以可以用資料來左右產品設計，是因為其有堅實的技術基礎\
• 14分10秒 從一個團隊，一個技術棧的組織發展到多個團隊同時在更大、更復雜的環境上搭建一個產品，有很長的路要走\
• 14分35秒 找到讓團隊獲得更大成功的起始點\
• 15分15秒 只要不受一些不必要的限制，找出起始點並不是很複雜的事情，但是它可以取得的成果是非凡的\
• 15分30秒 我們需要向交付團隊之外的人展示工作方式的價值\
• 16分30秒 在複雜的組織中，“產品”的想法並不明顯，所以我們需要幫助IT從業人員從專案的思維中轉型到產品的思維\
• 17分44秒 在許多大型組織中搭建環境的複雜技術棧導致了技術和團隊之間的分離\
• 18分13秒 通過確定驗證過的服務或產品的重要性來了解端到端的價值\
• 18分40秒 在開發產品的同時對不同元件進行存根，我們並沒有很好地使用到技術棧\
• 19分00秒 通過細化交付、多次驗證我們可以處理好技術棧的複雜性\
• 19分30秒 使用發現方法儘早驗證學習，避免構建出錯誤的產品\
• 19分40秒 研究如何在數字空間中應用實驗設計，清楚地瞭解正在使用的引數後再開始實驗

上述提及

• DevJam\
• Fredrick Brooks\
• 故事對映\
• Netflix\
• Ted演說：如何運用資料做出一個爆紅的電視節目 \
• Nassim Taleb “獲得成功”

關於我們的播客

你可以通過我們的RSS feed獲得最新的播客，通過SoundCloud和iTunes收聽我們的播客。在這個頁面上，你可以點選筆記旁邊的時間快速連結到播客音訊的那一部分。\

檢視英文原文：Engineering Culture Podcast: David Hussman on Effective Product Discovery and Dude’s Law