在一定規模的軟體研發團隊內，經常出現的情況是對同一個問題領域，會有多個人或多個者團隊矇頭再重複做系統或方案來解決相同問題。
甚至，在一些團隊內，技術人員為了職位晉升，會通過重複建設相關的系統來展示其能力，併名其名曰面向晉升程式設計。
對於個人來說，重複造輪子其實是人之本性，特別是對於優秀的研發工程師來說，自己的方案和程式碼永遠都是最好的，別人的都是垃圾。
對於研發團隊最高負責人而言，就需要認真思考重複建設的對整個團隊是否是問題，以及問題產生的原因是什麼？
對於中小型團隊，在研發資源有限的情況下，系統的重複建設其實一個比較嚴重的問題，反映出組織內部可能出現了一些不太好的徵兆：
團隊資訊共享機制缺失
例如，組織內 A 團隊在 Q1 構建了一個解決配置資訊管理系統，並且已經自己內部使用的很好了，解決了很多問題，提高其研發效率，6 個月後，另外一個 B 團隊因為需要解決類似的問題，自己又投入資源搞了另外一套系統，還可能會出現 C 團隊，D 團隊等等。
同樣的問題，為什麼出現兩套系統，背後反映的整個研發團隊內部資訊共享機制的缺失。A 團隊在做之前如果可以和整組織內的其他團隊共享一下問題，大家共享問題，共同建設一個共享系統，或者 A 團隊做完的系統使用後，在組織內部做一些宣傳推廣，讓有同樣問題的兄弟團隊來直接使用呢。
好的共享機制和文化，可以減少不必要的重複建設，將節省的研發資源投入到更加重要事情上，從而產生更大的價值。
團隊內部職責不清
從管理的視角看，重複建設的背後是不是因為團隊內部的分工不合理導致。一些可預期的多個團隊都會用到的基礎能力，是不是有獨立的團隊去負責建設這些體系，從橫向上支撐整個研發團隊，這樣來提高整體的效率。
一般上一點規模的研發團隊，都會建立一個共享能力建設的團隊，從研發組織全域性視角去承接一些可複用的研發工作，從而避免團隊各自為戰的情況出現。
常見共享團隊，例如中介軟體團隊，資料團隊，以及去年大火的中臺團隊。
共享基礎設施缺失
如果兩個團隊正在構建相同的基礎設施來解決類似的問題，那麼它應該是一個共享服務或能力。基礎設施的統一建設，長遠看會為組織降低很多成本，同時也會大幅度提升研發團隊的效率。高效統一的基礎設施的好處主要有：
系統層面可以高度複用 專業的團隊解決專業的問題，避免低水平重複建設 可以帶來人員內部的橫向調動學習成本大幅降低
團隊全域性意識不夠
因為兩個團隊針對同一個問題提出了相似的解決方案，這表明團隊中高階別的員工的全域性意識不足。如果做這樣事情的人員還因為或的晉升，這樣會降低團隊的整體的格局。
例如，A 團隊已經做了一個方案，B 團隊的經理至少應該知道這個問題已經是一個共同的問題，應該更高的維度上來考慮問題：
B 團隊在自己做之前應該尋求組織內部的資源，如果已經有了就可以考慮直接使用 或者 AB 團隊共同建設，並推廣到全組織內使用 A 團隊自己使用不錯時候，就可以積極推廣到全組織內，為全研發團隊帶來效能的提升。
總結
從管理的角度看，在一個組織內一些公用的系統能力重複建設，就是對組織資源的嚴重浪費。如果是組織必須的能力體系，最好的解決方案就是從全域性出發，重點投資，投入足夠的資源來建設到位。重複建設不可取，低水平的重複建設更不可取。
輪子小造怡情，團隊內大造輪子就需要慎重考慮了，特別是中小型團隊而言。
對於優秀的工程師個人而言，造一些輪子來自我實現是必須要途徑，如果能在組織內橫向跨團隊推動一批人來一起造一個不錯的輪子，對個人和集體而言都是一個不錯機會。
本組織構建的每個資產管理管道都是浪費精力，本應該在更高的級別進行投資。