為什麼你有許多架構師，專案依然延期並各種問題

為什麼許多專案的技術方案高、大、上，具體實現卻種種問題，程式碼慘不忍睹？ 

 

一、架構師欠缺深入程式設計的一線工作經歷，容易泛泛而談

許多架構師自身並沒有長時間的深入程式設計工作的經歷，在技術上的沉澱不足，導致對於軟體工程的理解、目標沒有清晰的認識。在做架構設計時，非常容易泛泛而談，並且給出的方案，太過高屋建瓴，缺乏對具體實現的理解和把握。許多架構設計方案，僅僅停留在PPT上，具體的落實完全依靠一線開發人員。

二、技術選型階段：技術選型不是出於專案需要，而是個人喜好

在技術選型階段，較好的團隊第一件要做的事情，通常並不是侷限在技術本身，而是深入的理解業務，搞清楚自己要做的到底是什麼，並且明確的給出期望的技術指標。

在此基礎之上，團隊會開展多次頭腦風暴，共同探討業務流程中可能會涉及的技術細節，以及可選的方案並制定客戶認可的技術指標，這一點相當重要，在專案中不能單純的追求高技術指標，而是權衡時間成本，人力成本，以及專案經費，制定合理的技術指標。

在這一階段，許多架構師在技術的選型上，往往更傾向使用自己並不熟悉的，甚至完全沒有用過的技術，藉此機會提高自己，充實自己的簡歷。他們可能會選擇更新，更激進的方案，不管專案是不是真的需要；也不太懂得權衡技術與成本，不願意選擇看上去好像落後一些但更穩定，更可靠，綜合成本更低的技術，片面追求高大上，到了實施階段，就非常容易出現種種不可控的技術因素影響專案的進度及品質。

三、實施階段：缺乏對開發團隊強有力的管理，存在技術斷層

這一點幾乎在所有的專案中都存在，架構師在設計好方案或搭建好開發框架之後，團隊的開發工作與進度管控完全由專案經理控制，架構師不參與團隊管理，大部分時間埋頭寫文件或自己研究技術，這種情況的專案，幾乎必然會出現許多技術上的問題並影響專案進度及品質；很多專案的方案非常漂亮，但是具體實現和程式碼編寫卻慘不忍睹，就是架構師失職的重要體現。

架構師除了前期技術選型及框架搭建，最重要的工作，以及架構師這一職位的根本意義，我認為在於對整個團隊的傳、幫、帶。

架構師要能夠放低姿態，對整個團隊進行必要的技術培訓，對程式碼實現的質量擔負第一責任，必要時對開發人員進行手把手的幫扶與指導，關於這一點其實沒有什麼技巧與方法好總結，只能以我自己的經驗來說，過去我帶過一個全部由工作經驗一年以下的小朋友組成的團隊，雖然他們的經驗和能力有所欠缺，但是好在都很好學，在專案的前兩個月中，我每天要花大量的時間用筆、用紙教他們具體怎麼分析怎麼實現，然後再去Review他們的程式碼，剛開始的時候所謂的Review，基本是兩個人做在一起，看著我重寫，這種方式他們進步的非常快，慢慢的在Review的過程中只需要我少少改一部分內容。不用一個月，整個團隊的編碼風格、程式碼品質就已經高度一致（注意我說的是高度一致，不是高水平，但這就夠了）。

四、缺乏與專案經理的通力協作

與上一點所談的問題相輔相成，大多數專案的開發階段專案經理是主要話事人，架構師不參與團隊管理。而理想的情況應該是兩個人協同共管、架構師做為司令員，主管開發品質，技術建設，專案經理做為政委，主管專案方向、進度、人員問題及部門協調、客戶溝通。

專案經理要有一定的包容心，能夠容納一個架構師與己分權，要給予架構師一定的人事權利，甚至是團隊人員績效考評的第一考評人，沒有任何權利的管理工作是很難落到實處的。

關於這一點，大概需要一點緣分。