不會扼殺企業的企業轉型專案

專案 Chardonnay

Chardonnay-Corp 是一家生產昂貴物品的知名製造商（我必須含糊其辭！）。他們的收入越來越多來自租賃這些物品，而非販售。租賃是一項深奧且複雜的業務。隨著他們的租賃業務成長，他們的電腦系統也需要成長。這正是我們進場的地方，我們要建構所謂的前端租賃系統。前端租賃系統處理您簽署（或用租賃術語來說，預訂）租賃合約之前發生的一切事務。這包括對出租人進行信用檢查、報價、創建和製作文件。在我們開始之前，這些作業大多充其量只是半自動化。

我們建構的系統將滿足許多技術人員的夢想。它使用所有最新的 Enterprise Java 技術，例如 EJB、JSP 和其他 TLA。當然，重要的是它對業務的影響。它讓 Chardonnay-Corp 能夠合併其辦公室，從多個區域辦公室搬遷到單一辦公室，減少人員數量（同時保留處理的租賃數量），讓流程更一致，並改善循環時間，取得報價過去需要兩天，現在只要 45 分鐘。此外，網際網路的奇蹟讓 Chardonnay-Corp 的經銷商能直接存取系統以取得報價，這有助於讓 Chardonnay-Corp 的產品對客戶更具吸引力

專案 Grenache

Grenache-Corp 是一家大型零售商，在美國每一個無聊的購物中心都有分店，更別提我曾經試圖用肘部開路擠進去的每個時尚購物街。像任何零售商一樣，他們非常關注供應鏈。他們必須從不太富裕的供應商處取得商品，提供給富裕的顧客。他們的倉儲複雜性簡直是一場惡夢。每個 SKU 都有許多不同的種類。

儘管我將 Grenache 視為單一專案，但事實上它是一系列專案，每個專案長達六到九個月，在四年內執行。每個專案都處理特定問題，例如在聖誕節前夕大量貨櫃抵達配送中心，然後在那裡放置好幾天，而人們則努力找出貨櫃中的物品與零售商實際預期的物品之間的關係（答案是「比你想像的少」）。我們使用建構在一般關聯式資料庫上的 Forte 技術建構系統。

專案 Tempranillo

Tempranillo-Corp 出租貨運貨櫃，這些貨櫃從一般的金屬箱到複雜且寬敞的冷藏箱都有。一家航運公司租用這些貨櫃，在世界各地運送一段時間，然後再將它們卸下。電腦在協助追蹤貨櫃所在位置以及何時會被取走方面，可以扮演重要的角色。Tempranillo-Corp 現有的系統不符合 Y2K 標準，而且最初將新系統視為解決此問題最便宜的方法。然而，沒過多久，這就演變成一個轉型企業的系統。我們使用 Forte 開發這個系統（我們過去使用 Forte 進行許多工作）。

專案 St Emilion

St Emilion 看起來很像 Chardonnay，至少專案是如此。大公司、前端租賃系統、配備鈴聲的 Enterprise Java，有很多重疊之處。（是的，有涉及一些重複利用。）差異包括 St Emilion-Corp 非常昂貴的物品在技術上也非常先進，因此它們在開始製造的瞬間就過時了。因此，St Emilion 的一大好處是允許更好地控制庫存，我們透過連接到他們的 ERP 系統來做到這一點。此外，St Emilion-Corp 的租賃業務不如 Chardonnay-Corp 的成熟，因此在制定一致的報價方法方面有更大的好處。讓業務人員在試算表上整理交易很靈活，但會對會計和利潤管理造成混亂。

頻繁交付

如果說有什麼事情讓我印象深刻，認為這是這些專案之間成功與失敗的共同差異，那就是頻繁交付。我經常遇到談論他們目前正在進行的主要企業轉型計畫的人。他們熱情洋溢地談論在執行五年計畫兩年後，事情進行得有多順利。儘管我不是一個具有統計效度的樣本，但我發現，在五年計畫執行五年後，我還沒有遇到這種程度的熱情，這一點很重要。我通常得到的最好說法是「如果...，我們就會成功」。

我們成功專案的共同主題是，在專案的整個生命週期中頻繁交付可運作的軟體。事實上，愈新的專案，我們愈常嘗試交付。Grenache 是較舊的專案，每六到九個月交付一次。雖然這是改造供應鏈的宏偉計畫，但每個專案都是獨立的專案，設計為本身就是可行的業務提案。非正式的說法是，這些專案通常會在一年內為自己帶來兩倍的收益。Chardonnay 是較新的範例，突顯了縮短週期的趨勢。我們每兩到三個月就會部署新的軟體。

這為什麼很重要？首先，這是建立信用的問題。企業並不出名於在對某項計畫投入大量資金時保持耐心。即使你找到願意贊助公司改造計畫的五年計畫的人，那個人也不太可能持續整個五年。通常，龐大的新計畫在三年左右會變成他們的絆腳石。除非有人能在那個階段證明可行性，否則專案會被犧牲，或者贊助人和專案會發現自己無家可歸。

另一方面，交付會建立信用，尤其是如果你看到好處：成本降低、時效性提高，這些比預期的收益重要得多。當人們看到系統實際運作時，他們可以看到它帶來的價值，以及它強制的變更。這種可見性也有助於軟體開發人員的信用。沒有什麼比業務人員哀嘆他們在聽取充滿信心的專案簡報時，卻不知道專案是否在軌道上更糟的了。已部署的軟體是具體的，並清楚說明進度。有時候這並不好，如果事情進行得比預期慢的話。然而，即使在這種情況下，我發現這是有價值的。如果開發速度變慢，你只能隱藏一段時間。最終，現實會以一種難看的習慣追上你。但是，如果人們看到穩定的進度，他們會更了解延遲，或會更早取消專案。這兩種情況對企業來說都比長期的失敗要好。

頻繁交付也讓你能夠從你的開發中學習。對許多人來說，這聽起來像一個奇怪的說法，但我們的經驗是，在進行這種專案時，沒有人真正知道全貌。如果你以前走過那條路線，你會知道要去哪裡，但企業轉型意味著進入一個全新的世界。對客戶和承包商來說都是不可預測的。雖然在聖艾美濃，我們能夠發揮我們在前端租賃軟體方面的經驗（這是我們的第四個這樣的系統），但事實是，在那個規模上，每項業務都有足夠不同的變化，成為一趟新的旅程。

這一點會因企業轉型專案經常涉及非常新的技術（稍後我會說明原因）而變得更為複雜。這種情況下，早期交付應著重於讓技術人員瞭解技術並探索一些高風險領域。這些發現會有好有壞，因此請及早進行，以便您能適時調整計畫。

探索新領域有一種替代方案。那就是在其他人踏上這塊土地之前，不要嘗試企業轉型專案。當然，這樣一來，您會對要去的地方有些概念。當然，這樣做的問題是，當您到達派對時，所有食物都已經吃光了。

當我談論這一點時，我談到交付時是以交付給企業為前提，也就是將軟體投入生產。然而，這個概念可以進一步延伸。即使在幾個月的部署週期內，軟體開發人員也可以在更緊密的週期內建置軟體：短至幾週。雖然您可能不希望將每個這些週期都投入生產，但您仍可以透過這些開發迭代獲得許多學習和追蹤的優點。在過去一年左右，我們已在幾個專案中使用這些類型的短期內部週期，而且隨著我們看到更多成功，我們會越來越常這樣做。

預期驚喜

正如我先前提到的，企業轉型並非可預測的練習。新的業務流程表示您正朝著一個僅略知一二（如果有的話）的領域前進。這些類型的專案會帶來驚喜。其中有些可能是壞驚喜，有些則是好驚喜。只有對它們做出反應，您才能避免壞驚喜造成的損害，並將好驚喜的收益最大化。

Tempranillo 提供了兩種驚喜的範例。壞的一面是關於維修的不愉快發現。在最初規劃專案時，預期追蹤貨櫃維修將是專案的一小部分。隨著專案進行，我們發現大約一半的工作在於追蹤維修。這導致專案的成本和時程大幅增加。在這種情況下，唯一能做的事就是正視問題並重新制定計畫。

我見過另一種替代方案，也就是試著繼續執行，彷彿原始計畫仍然有效，以避免偏離計畫而失敗。這會導致計畫與現實之間出現分歧。您可以維持一段時間，偶爾您甚至可能會因為其他更令人愉快的驚喜而回到正軌。但更多時候，分歧會持續下去，直到差異大到無法再忽視現實為止。後果通常非常痛苦。

對於較為愉快的替代方案，這些方案可以有許多方式。Tempranillo 的專案經理 Greg 講述了一個故事，說明業務人員看到我們現在有一個用於追蹤貨櫃的關聯式資料庫。他們突然意識到，只要一個簡單的 SQL 查詢，就能找出所有在維修貨櫃方面表現落後且尚未付款的公司。存取這些資訊很簡單，卻為 Tempranillo-Corp 省下了可觀的金額。這個好處在專案計畫中被輕易忽略，但最後證明是新系統的一項重大好處，值得花點時間來實現。

Tempranillo 也有更大的範例。Tempranillo-Corp 不僅出租貨櫃，新任執行管理階層決定出售貨櫃出租業務的部分。在執行此項作業時，他們發現要出售的部分是特殊貨櫃，例如大型冰箱。新系統讓這些業務線得以輕鬆分離，這在舊系統中會是一場惡夢。不僅如此，修改系統讓 Tempranillo-Corp 能夠出售「槽罐車」（運輸化學品、食品等）的業務，同時仍使用該系統管理買方的貨櫃，從而從交易的兩端獲利，一點都不困難。再深入的需求分析也無法預測這種變化，因為這是一項重大的業務變革。

面對這種不可預測性，很容易得出結論，認為規劃根本不值得花費心力。畢竟，如果計畫很可能會在專案進行到一半時就被拋棄，它們有什麼價值？但實際上，我們發現規劃在這些不可預測的專案中至關重要。只是規劃的重點不同，特別是它變成一個持續的規劃程序，其中計畫會定期重新制定。在這種環境中，長期計畫既不穩定又粗略，但仍有助於設定方向。短期計畫較為穩定，儘管在需要時仍可調整。

Chardonnay 是此類流程的絕佳範例。當團隊致力於當前兩個月的部署軟體時，分析團隊會找出未來兩個月需要執行的任務。我詢問 Chardonnay 的專案經理 Scott，他對六個月後的任務了解多少。「一串要點清單，我對其中大部分的內容一無所知，而且我也不認為客戶知道。」然而，這個專案持續為 Thoughtworks 和 Chardonnay-Corp. 締造成功。

獲得高層主管支持

這並不令人意外，或至少不應該令人意外。企業流程的重大變革需要企業管理階層的承諾。沒有承諾，一切都不會發生。轉型變革很少受到歡迎，但人類天生偏好已知的魔鬼，而非未知的未來，無論人們如何告訴他們未來有多美好。克服這種天生的抗拒需要領導力，而且要非常充足。

高層領導力也有助於提供對未來的願景。這可能不是非常詳細的願景，但考量到這些專案的性質，這並非必要。它所需要的，是即使計畫正在變更，也能引導進度的內容。這包括設定優先順序，對要做和不做的內容做出艱難的選擇。我們也發現，持續承諾我先前提到的頻繁交付非常重要。通常會有延後部署的誘惑，以便騰出時間加入一些非常棒的功能。但一個很棒的功能會導致另一個很棒的功能，很快地，你就會陷入不交付、失去信譽和學習優勢的陷阱。在此，進行非常頻繁的部署會有幫助。如果 Chardonnay 必須在當前部署中跳過一個功能，只要等兩個月就會有下一個部署。有了這麼短的時間間隔，就能更輕鬆地做出不做哪些事情的艱難決定。

如果你無法獲得所需的高層企業支援，會發生什麼事？我們的建議是：不要費心進行專案。這聽起來可能有點嚴苛，特別是如果你確信該專案對公司有益時。然而，高階主管的注意力有限，沒有高階主管的注意力，企業轉型成功的機率就和在拉斯維加斯將你的薪水押在 15 上一樣。

即使一個專案獲得高階主管的支援，也無法確定專案可以持續獲得支援。在 Grenache，原始領導人已轉往新的領域。這並不令人意外，因為成功的人喜歡迎接新的挑戰。新領導人喜歡不同的方法，依賴 ERP 系統而非自訂軟體。這也是一種自然的人類行為，即使目前的設定運作良好，新人通常偏好採用與前任不同的方法。因此，Grenache 計畫在改造整個供應鏈之前就結束了。頻繁交付再次成為有價值的技術。儘管 Grenache 的整個宏偉計畫尚未實現，但由於所有組成專案都已成功，而且產生了絕佳的投資報酬率，因此企業已從迄今為止的工作中受益。不僅沒有浪費資金，而且投資也獲得了良好的回報。

將業務和軟體開發視為夥伴

在企業轉型專案中，最困難的事情之一可能是確保專案的業務和技術方面之間存在真正的合作夥伴關係。當然，我們會注意到這一點，因為我們與客戶是不同的公司，但您通常也會在內部專案中發現這一點。業務人員和技術人員是具有不同目標和個性風格的不同個性。

即使在內部技術小組中，也強烈希望將安排變成固定價格合約。以下是我們的需求，繼續並建立它，告訴我們您何時完成。但正如我已經指出的，這類專案並非如此 - 其中涉及太多驚喜。我完全同意固定價格合約會更好，如果它能奏效的話。然而，固定價格合約取決於非常明確的一組需求。有一些軟體專案具有這些需求，但您在企業轉型專案中找不到這些需求。因此，需要採取不同的規劃方法 - 以及不同的業務/技術關係方法。

我所談到的合作夥伴關係需要我之前談過的聯合規劃。預期會出現新的需求，業務和技術方面都會出現問題。一旦雙方開始爭論他們同意的事項，專案就會陷入嚴重困境。在這種關係中，您必須依賴信任，如果這種信任破裂，那麼專案也會隨之而去。現在可能會發生這種情況，我確實見過技術供應商沒有交付貨物的案例。在這種情況下，需要終止專案，或至少暫停，直到找到新的供應商。

那麼，您如何找到一個值得信賴的供應商？（我將試著抗拒僅說「呼叫 Thoughtworks」的衝動。）顯而易見的建議是嘗試在內部進行專案。對於一家技術供應商公司的人來說，這是一個奇怪的建議，但冒著讓我們的銷售副總裁中風的風險，我還是會這麼做。有了內部團隊，您就可以消除大量的商業拉鋸戰。事實上，我過去常常相信這類專案應該在內部完成，而不是與我們這樣的技術公司合作。

是什麼改變了我的想法？（除了每月的薪水支票之外。）問題在於許多公司根本沒有資源在公司內部完成這項工作。科技公司可以提供軟體專業人士比大多數企業更廣泛且使用領先技術的有趣專案。他們也提供一個更適合像我這樣的怪咖的自由奔放環境。因此，他們可以獲得更好的怪咖。在企業轉型專案中，你通常需要你能找到的最佳怪咖，所以這是一件需要牢記在心的事情。這並不表示你必須完全將專案交給科技公司。我們做了許多使用由 ThoughtWorkers 和客戶人員組成的團隊的工作，Grenache 和 Tempranillo 都成功使用了這個模式。

重要的是要了解你需要的並不僅僅是一群聰明的怪咖。合作無間的人比一群不合作的聰明人更有效率。所以不要尋找一群聰明的人，而是尋找一個擁有共同文化且曾經合作過的人員團隊。找到也是這種文化的一份子且習慣與這種團體合作的經理和分析師也是件好事。

所以如果你需要外包，你該如何為這種專案選擇你的技術供應商？一個因素是他們人員的素質。確保他們真的有能力完成這項工作。查看履歷通常還不夠。通常一個好方法是找到一個專案，讓他們可以派一些人員進去工作幾個月。在這段期間，你可以評估他們的技能並了解他們的文化。查看他們之前的專案。業務領域在此處較不重要，儘管如果他們之前做過這項業務，當然有幫助。重點是要查看他們是否成功地以這種合作夥伴模式與客戶合作。查看推薦信是顯而易見且明智的步驟。查看他們與其他技術供應商合作的反應。我發現那些試圖擺脫外部人員的公司通常是因為缺乏自信心而這麼做。

當然，一旦你選擇了你的技術供應商，你必須監控事情的進展。雷根的名言「信任但要驗證」浮現在腦海中。你需要進度的具體跡象。一個明確的專案計畫，其中包含你可以驗證的里程碑，是此處的關鍵，而當我重複我頻繁交付的口頭禪時，你也不應該感到驚訝。沒有什麼比工作軟體更能衡量進度了。

也要預期會遇到障礙，並預期技術供應商會坦誠以告。Tempranillo 提供了一個絕佳的範例來說明為何這點很重要。正如我先前提到的，我們距離交付還有四個月時，才發現 Tempranillo 的修復部分比任何人意識到的還要複雜許多。專案必須延後幾個月。公開說明狀況很重要，而評估狀況並同意評估結果的客戶專案經理也很重要。雖然這表示專案比預期的還要晚才能提供完整功能，但它仍然成功，而且透過使用反覆交付，我們仍然能夠出貨部分但仍然有用的軟體。

請注意，這個範例顯示了擁有深入參與專案且因此能夠了解所遭遇問題的業務專案經理的重要性。雖然這並非完全必要，我們也常常在沒有專案經理的情況下進行管理，但這肯定有所幫助。

當然，當事情出錯時，偶爾是我們的錯，畢竟我們並非完美。但重點在於努力找出解決方案。在 St Emilion 專案中，我們犯了一個錯誤，低估了工作的複雜性，最後組成了一個經驗不足的初始團隊。當我們發現這一點時，專案已經陷入困境。雖然我們派了一組準備採取緊急措施的經驗豐富人員來協助，但我們的客戶也透過重新規劃工作來協助，這點也很重要。從一開始，我們就非常公開地說明風險，而這種公開有助於建立必要的信任。最後，St Emilion 專案成功了，但這是我們雙方做出一些犧牲才達成的。

為未來選擇技術

為此類專案選擇技術時，有一個特殊的問題。您無法決定現在最好的技術是什麼，您必須評估在專案全面展開時，也就是幾年後，最好的技術是什麼。隨著技術不斷變遷，這是一個棘手的選擇。

Grenache 和 Chardonnay 在此處形成了有趣的對比。Grenache 在 1990 年代中期開始，並選擇了 Forte。在許多方面，Forte 是一個絕佳的選擇，因為它是一個用於多層式資訊系統的成熟平台。它有許多現今較熱門的平台所沒有的功能。然而，事實證明，Forte 受到 Java 浪潮的衝擊，現在已成為一個沒有未來的技術。在 1995 年，這是不可能預測的（Java 那年才剛開始出現），因此這只是一個以事後諸葛的角度來看才顯得糟糕的決定。

Chardonnay 是做出正確選擇的一個範例。在 1997 年，企業 Java 技術是一個有風險的選擇。工具和技術非常不成熟，遠比 Forte 或已建立的客戶端伺服器工具（例如 Powerbuilder 和 VB）不成熟。然而，事情發展得很好。工具和企業 Java 知識的不成熟，確實讓事情比預期中還要慢，但現在企業 Java 已證明是一個穩定的平台，擁有許多公司支持的未來。

平台選擇不只是工具的長期選擇，它也會影響你可以得到的人員。軟體開發人員通常都很聰明，尤其是優秀的開發人員。因此他們知道使用瀕臨淘汰的技術會限制職涯發展。所以他們會遠離看似前景堪憂的技術。在 Java 世界在技術上真正迎頭趕上之前，要找到願意使用 Grenache 的人員就越來越困難。

面對這個問題，選擇整合策略而非完整的技術平台變得很重要。在 Grenache 中，這從一開始就很明顯，因為組成它的專案是分開進行的。對 Grenache 來說，這個平台是一個關聯式資料庫。每個專案都預期要使用一個共同的關聯式資料庫，作為資料的共用基礎。因此，不同的專案可以在相當程度的獨立性下運作。這種方法也讓 Grenache 有辦法解決 Forte 問題，未來的開發可以使用 Java 進行，儘管修改現有系統仍需要 Forte。

在我們的企業 Java 中，我們廣泛使用 XML 在處理單元之間進行通訊，以及越來越多地使用 Java 平台。除了 Java 的良好前景之外，我們也認為 XML 有潛力可以長期存在。XML 獲得相當多的宣傳，但在企業開發中佔有重要地位。

雖然這與這個主題有點離題，但這是提出一些關於物件導向平台最受吹捧的優點：重複使用，的建議的好時機。多年來，我遇到許多人談論建立可重複使用的架構基礎，他們打算在該基礎上建構下一代應用程式。我幾乎沒有遇到任何成功案例。這甚至沒有考慮到技術平台消失時的問題。問題在於從頭開始建構架構非常困難。Grenache 有個典型的範例：一個複雜的安全架構，花費很長的時間建構，最後變得比必要的更複雜。

有一段時間以來，我的看法，以及許多其他架構設計者的看法是，架構需要作為使用它們的應用程式的一部分來演進。建構幾個應用程式，然後從共用部分收集一個架構。然後，產生的架構是針對已知的需求設計，而不是推測。我必須警告你，這並不簡單，事實上它並不比建立一個初始基礎容易——唯一的差別是它更有可能成功。

人員是關鍵的成功因素

真正讓這類專案成功的，是參與專案的人員以及他們如何合作。最終，這是最重要的因素。技術選擇、方法論、業務波動，這些都只能居於次要地位。一群合作良好的優秀人員，將會找到方法克服難以克服的問題，而一個糟糕的團隊甚至不會嘗試跨越六英尺高的圍牆。因此，如果你負責這類專案，最重要的事情就是找到優秀的人員、留住優秀的人員，並確保他們合作良好。

找到並留住優秀的人員，主要是給予他們適當執行工作的責任。我聽過許多關於授權和管理人員的新方法的討論，但實際上，這似乎很少超越提供免費咖啡。

人們覺得困難的，實際上是退後一步，讓團隊對他們了解的事項做出選擇，並確保做出決策的人員是具備知識做出決策的人員。技術人員需要獲得信任，才能做出技術決策，業務專家需要獲得信任，才能做出業務決策。管理層的角色通常是確保適當的人員做出適當的決策。

管理層的另一個關鍵角色是確保有豐富且定期的資訊流動。尋找組織和實體的溝通障礙，並加以移除。許多方法都很簡單。確保一起工作的人員緊密相鄰而坐。確保有充足的會議室供協作工作使用。投資於團隊建設活動。一個團結的團隊值得投入大量心力來建立。

在此特別重要的是業務專家和開發團隊之間的定期聯繫。Grenache 遵循在專案期間指派一位業務專家全職加入團隊的做法。Chardonnay 擁有一大群 Thoughtworks 租賃專家，他們與 Chardonnay-Corp 的業務專家合作，找出了解 Chardonnay-Corp 業務流程的來龍去脈的主要主管。需要的定期面對面聯繫，通常會發現業務人員和開發人員之間的每日互動。這通常會被忽略為專案成本，因為溝通和信任會中斷。如果業務部門希望專案成功，就必須投入人員。

此安排是否運作良好的關鍵測試是對壞消息的反應。開發人員在現場難免會遇到問題，通常會影響時程。如果管理階層的反應是隱瞞事情或告訴所有人「更努力工作」，那麼你沒有那種能有效運作的管理階層。對問題的誠實反應以及對問題的開放態度對於與開發人員有效合作和成為業務的良好合作夥伴都很重要。

持續學習

在複雜且新的領域工作難免會有所發現。正如我在上面所討論的，處理驚喜的重要事情是從中學習。事實上，長期專案成功的關鍵主題是持續學習的概念。這種學習是關於業務需求、我們使用的技術以及我們執行工作的流程。

軟體開發中常見的發現之一，就是人們在看到系統的早期版本後，會改變他們對需求的想法。這是自然而然的現象，因為系統的存在能為業務人員釐清許多事情。因此，他們能了解自己的需求，以及技術可以提供什麼。頻繁交付的其中一個好處，就是它能加速這個學習過程。業務人員應利用這些交付，以及他們對開發過程的深入了解，作為一個載具，進一步了解軟體開發過程中哪些是有價值的。Chardonnay 和 St Emilion 都從短暫的開發週期中獲益良多，有助於業務人員引導專案，提供最有價值的功能

持續學習也適用於技術。由於企業轉型專案通常會使用較新的技術，因此學習對於最佳利用技術至關重要。當技術很新或快速演進（而且現在有什麼不是呢），許多最佳使用技術的方法在早期並不明確。此外，勢必會有一些隱藏的陷阱，也不會在早期出現。一個好的團隊會檢視他們使用的技術，並隨著專案持續使用技術，調整他們的方法，以最佳方式使用技術。St Emilion 和 Chardonnay 是最早使用企業 Java 的幾個嚴肅專案。這兩個團隊都學到了很多關於如何使用企業 Java 的知識，並讓系統演進以利用這些知識，並從其他 Thoughtworks 專案和大量關於使用 Java 的文章中學習。

通常最容易錯過的學習形式，就是了解開發過程的重要性。定期檢視團隊如何運作，以及團隊思考如何改進，這一點很重要。St Emilion 有許多關鍵的回顧，開發團隊和客戶團隊都會檢視流程，並決定如何改進。這些流程檢查對於將專案從陷入困境的專案轉變為巨大的成功至關重要。另一方面，Grenache 成為其自身成功的受害者，後續專案沒有足夠的演進來利用其自身的經驗，導致在過去一年左右的時間裡效率降低。