前言
過去我們談敏捷文化、敏捷式開發流程，多數是在談產品開發&交付(Delivery)如何提升效率，例如如何透過Scrum模式管理Product Backlog、如何透過sprint planning / Daily Scrum / retrospective meeting來快速交付開發項目，但較少提到產品探索(Discovery)這個流程如何加速。
這可能有幾個原因，因為很多團隊的敏捷開發法，其實都是應用在專案管理/專案開發方面，而產品管理與專案管理之間一個很大的區別就是，產品管理更加著重在「要開發甚麼產品/功能」，產品團隊要能夠定義產品問題、探索能解決客戶問題並具備擴展性的解決方案。相較之下，專案管理更專注於如何「如質如期如預算」地交付，雖然實務上還是極難避免scope creepy，但它在範疇管理上是遠比產品管理要來得容易的(產品管理具有迭代的本質，基本上難以訂出範疇)，也因此，它所使用的敏捷，通常都是指敏捷交付。
看到這裡，你可能會覺得「到底是敏捷探索還是敏捷交付」其實是個假議題，無論如何，結果論就是快點產出結果來做驗證不是嗎?
這個說法有隱藏的前提，就是「產品探索是產品交付的前置工作」。
在這篇文章中，我將說明產品探索與交付工作之間有何本質上的差異，而我們又要如何統合兩者才能達到最有效率的軟體開發流程管理。
產品探索與產品交付的本質不同
在Marty Cagan的講座與著作中，多次談到這兩個產品團隊工作間的本質性差異，簡單來說，產品探索是「Do the right things」、產品交付則是「Do the things right 」；一個是透過學習、驗證價值/易用性/技術實行性/商業可行性4大風險，確保打造的是對的產品/功能；一個則是確保打造出來的產品/功能具備穩定性/可擴展性/高效能/可維護性/多語系5大品質標準，兩項工作間的目標、思維、做法非常不同。
做產品真是哭夭難！ — Marty Cagan 演講 70 分鐘中文逐字翻譯（附贈 YouTube 錄影）
Marty也直言不諱地說，大多數產品團隊其實都不是真正的產品團隊，而是他戲謔稱之為傭兵團隊的「功能團隊」(Feature Team)，只負責像兵工廠一樣產出功能(output)，而不問對實際用戶能產生甚麼成果(outcome)或影響(Impact)。
這個常見的問題，其實能夠從一個產品團隊平時如何做產品探索一見端倪。
探索與交付的常見誤解
Marty在講座與著作中都強調了探索與交付兩種不同工作是同時進行並且需要取得平衡的，但卻並未深入說明執行方法為何。我們可以從他的一篇部落格文章，進一步了解他與Jeff Patton(他就是<使用者故事對照>一書的作者)一起研究出來的產品開發方法:Dual-Track Agile(雙軌式敏捷)。
在很多宣稱敏捷的產品團隊中，我們發現他們其實只是把瀑布式開發流程縮小規模後塞進每一個為期2週的敏捷衝刺，人員的協作方式仍然依循著產品經理定義規格、設計師做設計切版、工程師開發完成、測試工程師驗收的程序，也就是先完成產品探索，再接著做產品交付。
在Jeff Patton的知名文章<Dual Track Development is not Duel Track>裡，他舉出了大多人在理解敏捷開發流程時的常見迷思與誤解:
迷思1：探索是敏捷開發之前的流程。不應該是這樣子的。
產品探索是產品開發的必要部分，雖然它的目標與產品交付工作有所不同，但在實踐上，它和開發工作採用同樣的敏捷和精益原則。
過去我們在專案管理、瀑布式開發中，講究產品經理(或專案經理)要明確訂好需求規格及範疇，分析師完成系統分析規格書與系統設計規格書後，再交由設計師撰寫設計介面、工程師依規格開發、最後由測試工程師依驗收準則測試，過程中的每一道關卡的工作及必要文件都被詳細規範，雖然這在責任歸屬上非常明確，但它的假設基本上違反了軟體開發的本質，亦即「開發規格是能夠定義得清清楚楚的，在整個開發過程中能夠保持不變，因此我們能夠用流水線的方式接力完成整個開發工作」。
在真正的敏捷流程中，事情恰恰相反，儘管我們會盡可能確保最終的探索內容與品質，以供開發和交付，但我們仍保持著解決方案變更的彈性，以因應我們在持續探索中的隨時學習調整。
迷思2：所有的工作都是從探索流向開發。不應該是這樣子的。
如果我們正確的進行探索工作，很多的想法會有巨大的變化或是被捨棄。
這個部分顯而易見地，實踐相當困難，因為投入成本考量，很少團隊的產品探索結果會被真正地放棄，通常會被視為「說不定未來哪個客戶專案上會用到」而保留下來；或是拉長探索期間，勢必要為這些想法找出一套解決方案；也可能會檢討提出想法的人，一開始為何將這些註定失敗的項目納入探索工作、是否在產品策略規劃階段就有問題。
上述種種，都來自於錯誤地把放棄視為產品探索的一種失敗，然而，這卻是產品迭代中學習的必經過程，及早放棄沒有價值的想法、不夠完善的解決方案，才能避免團隊過度投入造成浪費，也能讓團隊專注在更有價值的項目上。
迷思3：探索團隊和開發團隊是不同的團隊。不應該是這樣子的。
通常探索工作由產品經理、設計師和資深工程師主導，但是最好還是盡可能讓整個團隊成員都能參與。持續的進行探索工作以及讓整個團隊可以可視化進度。
這項同樣也是實務上不易實踐的，在一些規模不是很大、團隊人數少的公司，由於人力吃緊，探索工作基本上還是由產品經理一人獨力完成，包含驗證價值/UX易用性/技術可行性。而在較大規模、分工細化的公司裡，因為採取功能性(Functional)編制，勢必需要打破穀倉將設計師、工程師拉入產品團隊，與產品經理一起進行探索工作；這個又牽涉到個人的工作觀念(ex.有些工程師喜歡更純粹的開發編碼工作而非開放式的探索工作)、組織文化(傳統的人力管理仍傾向讓人員在團隊內各司其職)、績效管理(敏捷式開發比瀑布式開發更需要類似OKR的績效衡量方法)等等。
迷思4：一旦探索工作流向開發工作，探索工作就完成了。不應該是這樣子的。
通常探索工作由產品經理、設計師和資深工程師主導，但是最好還是盡可能讓整個團隊成員都能參與。持續的進行探索工作以及讓整個團隊可以可視化進度。
這和上一點有些雷同，有時專業分工反而會形成壁壘，而去除壁壘的方式，除了持續培養組織的產品思維文化以外，更要從績效管理方面著手，透過績效指標來凝聚團隊，當績效指標是瞄準產品成果與影響、而非訂定在工單/程式碼的數量時，才能夠真正做到團隊的賦權與當責，也比較不會讓人員有「完成了規格/設計/開發工作後其他的就不關我的事了」的觀念。
同樣地，探索等同於學習，不會因為產品交付就結束；而是透過持續的量測和學習，不斷的從用戶回饋中吸取動力、迭代創新產品。
怎麼樣可以同時加速探索與交付?兩者間如何平衡?
根據Marty在SVPG部落格的一篇文章中的附圖(如下圖)，我們嘗試細部定義雙軌式敏捷的做法:
Dual-track Product Development, SVPG
- 在產品開發流程中，分出兩個同時進行、相互影響的軌道:產品探索流程(Product Discovery)與產品交付流程(Product Delivery)。
- 有兩種產品待辦清單(Product Backlog)，一是產品探索的待辦清單，一個是產品交付的待辦清單；前者用於概念/創意的發掘與驗證，後者則是以準備好開發/發布的項目。我們會將概念/創意的使用者故事(User Story)保留在探索的待辦清單中，直到其完全定義(包括使用者體驗、設計和開發擴展的相關解決方案、規格)。因此，當使用者故事進到交付待辦清單中時，開發人員可以立即開始實作。
- 在產品探索流程中，我們會定期從機會池中依照優先序取出產品建議項目(Product Backlog items)，初步作機會評估(Opportunity Assessment)來決定是否要放入探索衝刺中深入研究，這階段可能就會丟棄掉一些想法了。接下來在探索衝刺中，我們會透過「發想-原型-測試-調整」的循環，找出可行的解決方案。這裡所謂的可行，就是指通過用戶價值、UX易用性與技術實行性風險評估的項目。
- 承上，這些成功通過探索衝刺的項目，會進到產品團隊的產品需求表(Release Backlog)，再依照優先序排入工程團隊的開發衝刺當中，也就是圖中產品交付流程中的多個Sprint。仔細觀察可以發現，每個開發衝刺結束後並不一定會立即發布，這是由於實務上我們會依照開發原則，將原先較大的使用者故事切分為適合團隊快速進行開發/測試驗證的規模，這個規模並不是在E2E測試中真正能為用戶帶來業務價值的足夠規模(有關使用者故事的3種不同規模的描述，有興趣的話，推薦閱讀<使用者故事對照：User Story Mapping>)所以可能會累積幾個Sprint之後才Launch產品/功能。
Dual-track Product Development
上圖中其實還有一個重要細節未被闡明:探索衝刺和開發衝刺的次數、頻率如何安排?
理想上，產品經理會希望有足夠的時間完成足夠完善的解決方案探索&打磨，訂出一個品質盡可能萬無一失的規格，一方面這會花太多時間，提出需求的利害關係人通常無法等產品經理這麼久才告訴他解法，另一方面這也表示花了太高的成本在學習，不符合我們快速迭代的目標。
因此，在我們公司的作法是平時就會把四面八方來的需求透過工單管理系統彙整，產品經理會初步判斷，把優先序高的項目揀選出來放入未來四週的衝刺週期裡進行探索，不會要求一次把解決方案完善到百分之百，但要求一週內要提出第一版解決方案出來供團隊成員(設計師、工程師、測試員)評估，這是我們控管產品探索時長的方式。
而在產品經理花費時間探索的同時，設計師、工程師也正在他們自己的設計/開發衝刺裡，此時他們所處理的項目，正是來自更早之前的探索衝刺裡、產品經理評估可行的解決方案。
結論
在這篇文章中，我們快速回顧了產品團隊的探索&交付工作本質，並且透過圖片詳細闡述了Dual-Track Agile是如何進行、並且有效加速團隊交付與學習的。
當然，沒有十全十美的產品開發流程，在我們公司裡雖然成功地進行了雙軌式的敏捷開發，成功加快了整個處理需求的流程，然而這個速度背後的代價是可觀的設計債與技術債(當然一定程度上過度設計可以說是工具型產品的原罪)，我們也仍然在努力的路上，在產品迭代速度與產品品質之間取得一個更好的平衡，共勉之!
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11–20 個拍手；
如果想看更多影評相關的文章，請盡情長按拍手讓我知道 👏🏻
想要持續追蹤我的最新文章，請記得追蹤！
(本文同時發布於Medium和Vocus)
