透過範例瞭解疊代流程

如同敏捷，疊代流程也是能讓我們自動聯想到工程團隊的詞之一。但大多數團隊都以某一、兩種方式進行疊代，而使用疊代方法可有助於減少風險、管理效率，並且以更靈活、更動態的方式處理問題。

若您想嘗試一番疊代流程，本文就是為您準備的。我們會為您介紹如何定義疊代流程，以及如何在您自己的團隊中實施此流程。

什麼是疊代流程？

疊代流程即組建、調整和改善一項專案、產品或計劃的實際作法。運用疊代開發流程的團隊會進行建立、測試和修改，直到對結果滿意為止。您可以將疊代流程看作是一種試錯方法，可以讓您的專案逐步朝目標靠近。

疊代流程是精實方法論和敏捷專案管理的基本組成部分，但任何團隊都能實施這些流程，而不僅限於敏捷團隊。在疊代過程中，您會不斷改進您的設計、產品或專案，直到您和您的團隊對最終的專案交付項目滿意為止。

什麼是非疊代流程？

在非疊代流程中，您和您的團隊需要合作完成一個最終產品，而不必在過程中嘗試新構想。一般而言，非疊代流程在概念化和建立階段需要更多時間，讓一切能夠在測試階段如預期進行。

瀑布模型是最常見的非疊代流程。在瀑布模型中，您和您的團隊需要在專案開始前定義專案階段。每一個階段都會在上一個階段全部完成時再開始。專案開始前，要求與資源通常都會固定，團隊也會儘可能避免變更專案計劃。

例如，假設您正在與一家設計機構合作創作一本電子書。您首先需要提供電子書的所有文案。然後，設計機構會得到這些文案並進行設計。最後，您的內部團隊需編輯設計後的電子書文案，確保一切完善。這是瀑布模型的一個範例，每個階段都需依賴上一步 (即，您不能在設計電子書之前對其進行文案編輯)。

依您所在的團隊和您執行的專案類型，非疊代流程可能會極具挑戰性，因為這些流程並非即時組建，以供您的團隊進行疊代和持續改進。工程中有太多的未知和意外，工程團隊尤其傾向於使用疊代流程而不是非疊代流程，但任何團隊都能從中受益。

漸增設計是否與疊代流程相同？

大多數團隊會交替運用漸增設計和疊代流程，而實際上，兩者往往並行不悖。不過兩者之間仍有一些差異。

在疊代流程中，您的團隊會依據回饋或新資訊來完善和改進您的專案。疊代流程的關鍵在於反覆試驗：專案會因為這些變動而持續完善。

在漸增設計 (有時稱為漸增開發) 中，您需在第一個版本或交付項目的基礎上增加新功能並組建更完善的內容。要進行漸增設計流程，團隊需有目的地產生出最終專案交付項目的基礎版本，以便儘快推出 (如同 Facebook 的古老格言：快速行動，打破常規)。然後，團隊需透過建立包含比初始版本更多功能的漸增版本，以此疊代和改進初始版本。他們需要持續如此，直到交付項目具備所需的全部功能。

大多數使用疊代流程的團隊也會使用漸增設計，反之亦然。好的疊代流程同時也是漸增式的，這樣您就可以持續完善您原有的交付項目。好的漸增設計同時也是疊代式的，因為您需要做到回應客戶回饋，並且依據需要進行調整。

疊代流程範例

工程

許多工程團隊運用疊代流程來開發新功能、實施錯誤修復，或進行 A/B 測試新策略。通常來說，工程團隊會建立幾個他們認為效用同等的疊代，然後與使用者一起進行測試。他們會記錄痛點與成功之處，然後持續組建出經過測試後表現最佳的疊代。

產品開發

您可能會驚訝地發現，大多數產品開發都是要疊代進行的。回想您曾經為自己購買的各種個人高科技產品，在您購買之前已有一個舊版本，之後可能也會有新版本。想想看手機近年來的發展，喇叭變得越來越輕巧便攜，甚至同一品牌的冰箱也因應新型家庭的需求而不斷變化。這一切都是疊代流程。

行銷

某些行銷團隊會採用疊代流程，而某些則不然。但在一定程度上，很多行銷都是疊代進行的。例如，一些行銷團隊可能會測試不同的廣告文案，瞭解哪一種能獲得更好的參與度，或者傳送兩個版本的電子郵件新聞，比較其點閱率。或者，品牌行銷團隊可以使用疊代設計流程來確定最適合目標受眾的圖像。

銷售

雖然大多數銷售團隊面向客戶的工作並非疊代式，但其中某些任務仍可從疊代流程中獲益。例如，銷售團隊可運用疊代方法傳送冷郵件。他們可能會讓其代表傳送幾種不同的電子郵件主旨列並分析其結果。然後，團隊可以實施其中最成功的主旨列。

疊代流程的 5 個步驟

疊代流程可在專案生命週期期間提供協助。在疊代流程的幾個步驟中，您的目標和要求應作為專案的起點。然後團隊需運用測試、原型設計和疊代，以期實現最佳結果。以下介紹方法：

1. 規劃與要求

在疊代流程的這一步驟中，您需要定義專案計劃，並且與您的整體專案目的維持一致。您需要在此階段列出所有硬性要求，即專案成功所必然達成的事項。若無此步驟，您就會面臨疊代過後卻無法實現目標的風險。

2. 分析與設計

在這一步驟中，您與團隊需專注於業務需求以及專案技術要求上。如果說第一步是列出目標的過程，第二步則是針對最終可實現目標的設計進行腦力激盪。

3. 實施

在第三步驟，您的團隊需要建立專案交付項目的第一次疊代。此次疊代需以您的分析與設計為依據，且應符合最終專案目標。此次疊代的細緻程度與您投入的時間需依專案而定。

4. 測試

擁有一次疊代後，您需要以最合理的方式進行測試。例如，若您正在進行網頁改進，您可能會需要針對目前的網頁進行 A/B 測試。若您正在設計新產品或功能，請考慮邀請潛在客戶進行可用性測試。

除了測試以外，您也應該與專案關係人進行確認。請邀請他們評估疊代內容並提出回饋。

5. 評估與審查

進行測試後，您的團隊需評估疊代是否成功，並且對任何需要變更的事項進行調整。此次疊代是否實現了專案的目標？原因是什麼？若有任何事項需要變更，您可以重新啟動疊代流程，回到第二步以建立下一次疊代。請記住，在所有疊代中，您的初始計劃與目標都應維持一致。繼續在上一次疊代的基礎上進行建構，直到獲得滿意的交付項目為止。

若您重新啟動疊代流程，請確保每個人仍與專案目標維持一致。疊代流程可能需時數以週計或數以月計，取決於您要進行多少次疊代。每次重新啟動疊代流程時，將疊代集中於專案目的之上，可有助於確保始終朝著目標發展。

疊代流程的優勢與挑戰

疊代模型未必適合每一種團隊或每一個專案。以下介紹適用於您團隊的疊代流程的優點與缺點。

優點：

• 提高效率。由於疊代流程中包含反覆試驗，因此與非疊代流程相比，通常可以幫助您更快獲得所需的結果。

• 增加協作。您的團隊不再按照事先確定的計劃和規範工作 (它們也需要花費大量時間來建立)，而是一起積極地工作。

• 增加適應性。在實施和測試階段學習新事物時，您可以調整疊代，以利實現您的目標，雖然這意味著要做一些您在疊代流程開始時不曾想到會做的事情。

• 更具成本效益。若您需要變動專案的範圍，只需在此流程中投入最少量的時間和精力即可。

• 可併行作業。與瀑布模型等其他非疊代方法不同，疊代不一定依賴於之前的工作。團隊成員可以併行處理專案中的多個元素，這樣可以縮短整體時間。

• 減少專案層次上的風險。在疊代流程中，可在每次疊代中識別和處理風險。不要在專案開始和結束時處理大型風險，而應始終努力處理低層次風險。

• 更可靠的使用者回饋。當您擁有一個使用者可以與之互動或查看的疊代時，他們就能夠向您提供回饋，告知您對他們來說何者有用，何者無用。

缺點：

• 增加範疇潛變的風險。由於疊代流程的反覆試驗特質，您的專案可能會以您意想不到的方式發展，並且超出您的原始專案範疇。

• 規劃與要求欠缺靈活性。疊代流程的第一步是定義您的專案要求。在疊代流程中變更這些要求可能會中斷您的工作流程，且導致您所建立的迭代與專案目的不符。

• 時間軸模糊不清。因為團隊成員需建立、測試和修改疊代，直到得到令人滿意的解決方案為止，所以疊代時間軸無法明確定義。此外，對於不同增量的測試，時長可能會有所不同，這也會影響整個疊代流程的時間軸。

嘗試、試驗，再嘗試

最終，每個團隊都可以從疊代流程中學到一些東西。如果可以的話，請以不害怕犯錯的反覆試驗的心態對待工作。感到不確定時，請靈活處理並進行協作。此外，無論您是否實施疊代方法，都應努力在工作中持續改進。

若想獲得更多提示，請閱讀 25 種基礎專案管理技能。