假設您必須向應用程序添加新的主要功能。那么將此功能添加到仍在建設中？還是但尚未投入生產的相對較小的應用程序中？還是將其添加到總體質量值得懷疑的，隨著時間推移而增長的大型項目應用程序中是否更容易？毫無疑問，第二項更具挑戰性的任務。但是為什么我們通常會找到最有經驗的開發人員，即軟件工程師，即很酷的人，而大多數人則參與其中，而其他人則常常被埋葬在第二項中？

多年前

很多年前，當我進入負責大型公司的核心系統之一的開發團隊時，我擔任的第一職位是負責遺留部件的應用程序維護（AM）團隊。原因很簡單，也很共同：我是新來的，使用經驗很少的前沿技術，新項目正在快速運行。AM將是我成長的正確場所，而沒有太多壓力。

一旦我積累了足夠的知識和經驗，我就會轉到項目團隊，使用新技術開發新功能的團隊，好人團隊。大約一年后，這種情況實際上發生了，但是我永遠不會忘記AM那個據說不太那么緊張的時期。

　　項目團隊和AM團隊

所有這些都是很多年前的，但是從那以后，我看到了無數次重復的相同模式，常常以更為極端的形式出現。您有一個新的計劃，從項目團隊開始。項目團隊開發體系結構，項目團隊開發功能，項目團隊針對非常樂觀的初始計劃積累延遲，項目團隊開始額外工作，項目團隊開始偷工減料。

質量常常被犧牲在計劃的祭壇上，測試被遺忘，補丁被添加到補丁之上。開發人員開始添加評論“待我們有一段時間后將其重構”。技術債務已經存在，其命運還在增長。

最終，該產品投入生產，然后，在上線之后，項目團隊立即開始向AM團隊過渡。經過一段時間的重疊后，AM團隊將獨自航行。AM團隊通常比項目團隊年輕，經驗不足且實力不足。困難的部分結束了，該項目已經啟動。現在是AM時間，它變得更容易，它的成本也更低，我們可以負擔一個新的初級團隊。

上線一年后

這是一年的緊張工作。錯誤已得到修復，小事情已更改，小事情已添加。該系統最終已準備就緒，可以承受實際的生產負荷，并且代碼庫已經擴展。此時，AM團隊收到了添加新的重要功能的請求。

我們回到了最初的問題。現在添加新功能是否更容易，還是在“項目”模式下添加新功能更容易？

答案很明確：AM團隊的任務要困難得多。的確，AM團隊會隨著時間的推移而積累經驗，但是與此同時，AM團隊需要大量接觸不太穩定的代碼庫，需要避免在沒有適當的測試安全網的情況下引入回歸，需要設計一種在不造成中斷的情況下部署新的主要版本的方法。

AM團隊通常比項目團隊面臨更艱巨的工作。為什么，如果AM團隊的任務更加艱巨，那么所有很酷的人都在項目團隊中，而現在又在其他地方，可能還有其他很棒的事情嗎？

　　可能的答案：項目團隊需要奠定正確的基礎

聘請最有經驗的人來啟動項目的原因之一是，一開始，我們需要為將來的事情打下基礎。我們需要定義架構，并對解決方案的設計做出一些基本決定，因此需要正確的經驗。

但是，與此同時，在項目開始時，通常我們對所要解決的問題的了解有限。在任何重要的項目開始時，都有許多已知的未知數，也有許多未知的未知數。因此，必須始終將系統的體系結構視為可演化的，并且我們需要意識到，許多關鍵的決定不能在一開始就做出，而必須在未知因素開始暴露時做出。

在項目開始時就將架構決策視為一勞永逸的決策通常是一種幻想。在軟件系統生命周期中的任何時候都可能出現關鍵的體系結構問題。在項目開始時做出的關鍵體系結構決策可能必須稍后進行大修，這可能是因為有新的需求，可能是因為出現了新技術，例如Cloud，也許是因為它們只是解決問題的錯誤方法。

所以是的，的確如此，項目團隊必須做出架構決策，但AM團隊也必須做出架構決策，并且必須在更加復雜的環境中做出決策。

　　您根本無法做到相反

在中期，雖然強大的項目團隊的經典模式隨后是一支更初級的AM團隊并不是最有效的方法，但相反的方法也無法解決問題。我們無法想象有一個初級團隊來啟動一個項目，然后將其過渡到一個更高級別的團隊進行維護，這顯然不是一種選擇。

潛意識的情況

也許更多的高級人員使用新的炫酷技術來啟動新項目的一個深刻原因是，他們喜歡用新的炫酷技術來開始新事物，然后隨著時間的流逝，當工作似乎變得越來越重復時，他們只是想應對其他挑戰。

這有利于他們的技術好奇心，也有利于他們的履歷表。但這可能對他們正在構建的軟件系統的長期健康不利。

從項目團隊到產品團隊

2006年，亞馬遜的Werner Vogels首席技術官創造了著名的“您制造，運行”的座右銘，傳達了這樣一個想法，即負責產品的團隊需要從產品開始到運行階段都對其進行服務。運營方面以及演進方面。簡而言之，同一團隊負責產品成功所需的所有階段：設計，構建，運行，發展。

如今，越來越多的人開始認為需要從以項目為導向的組織工作方式轉變為以產品為導向的模型。這是一個復雜的轉變，涉及組織的許多方面，但是對于我們在這里進行辯論的主題，這無疑意味著放棄將項目和AM團隊分開的想法，而創建更穩定的產品團隊。

產品團隊需要由經驗豐富的人，很酷的人以及需要成長的初級人才的合適組合。大三學生與帥哥一起工作，逐漸變得很酷。這樣就可以在不影響團隊質量的情況下控制輪換。

在我們生活的時代，數字時代，當我們聽到諸如“當項目結束時我們將過渡到AM”之類的消息時，我們必須變得可疑。

這并不是說AM不再有空間。仍然有一些舊的舊系統，通常為后勤部門服務，它們的工作非常糟糕，非常穩定，只需要一些維護即可。

但是，在開發新的差異化數字功能時，我們需要遠離AM模型，而要采用面向產品的模型，該模型的設計團隊不僅要負責構建產品的第一個版本，還要負責運行它。 從中進行學習，并隨著時間的推移進行改進，以確保它與最終用戶仍然相關。更多關于項目管理的信息，請繼續關注中培偉業。