交付架構師工作指引

作者：yeedomliu

非常重要，非常必要，甚至來得有點晚。

介紹

為什麼寫

1. 公司在往產業網際網路方向轉型（僅3-4年），公司在這方面沉澱較少，交付架構師變動又比較大，專案在交付中碰到很多問題，導致在專案上交付困難
2. 在交付專案上，專案經理大多不懂技術，架構師不懂專案管理，因此會導致專案經理和架構師在交付專案上不能形成有效合力，專案失敗的可能性會大大增加。
3. 交付架構師除了需要學習專案管理，還需要學習一些其它角色的技能，能極大提高專案成功交付的可能性

技能要求簡述

1. 如果用格鬥來比較，散打、摔跤、拳擊是不同的專案中不同的角色，交付架構師則是綜合格鬥MMA，既需要熟練掌握各門派知識，又需要融匯貫通使用各項技能。但在工作中很容易會認為這個職位跟其它職位一樣，是單技能的一個職位
2. 在專案交付時交付架構師需要和專案中各種角色（從前到商務、後到運營）溝通，因此具備各個角色的專業知識是溝通暢通、專案順利進行的有效保證
3. 在專案交付是很困難的，一是面對眾多ISV，二是面向眾多角色；專案交付難度略等於『ISV數量』*『角色數量』

職責

專案交付工作流程安排

第1周

主要了解專案各方面情況，透過了解或收集以下資訊能快速瞭解一個專案概況

相關方

相關方很重要，專案往往是死在被忽略的相關方手裡，必須識別出來所有可能影響到專案的所有人，並且對它們採取合適的管理手段

諮詢專案經理PM獲取相關方資料，如果沒有需要催促PM製作『相關方』表格

除了有相關方登記表格外，還需要按照影響力、態度、影響階段整理相關方

1. 影響力（權力/Power）：無（0），弱（1），中（2），強（3），極強（4）
2. 態度（利益/Interest）：抵制（-2）、反對（-1）、中立（0）、支援（1）、推動（2）
3. 影響階段：I啟動、P規劃、E執行，C收尾：（可多選）

WBS工作分解結構（需求、範圍、交付清單）

範圍儘快確定是非常重要的事，只有確定了後續UI、開發、設計等工作的開發。需要催促產品或PM儘快落實

幾點注意事項

1. 所有需求有客戶書面確認（需求確認書）
2. 有詳細的進度計劃、並且有強烈的時間觀念
3. 經常跟相關方溝通

時間管理

進度計劃

里程碑

時間估算

專案上工期常常需要評估時間，這塊也是個挺頭疼的問題，不同經驗的開發對於同一個功能評估差距巨大，可以使用『三點估算』法進行快速準確的評估

比如專案上一個例子

最開始A合作伙伴評估了36天工作量

在評審會上，對接過的B合作伙伴說10天能做完

經過各方溝通後，A合作伙伴把工期從36天壓縮到預計19天

根據『三點估算』法計算

最悲觀：36天 樂觀：10天 正常：19天

三點估算：10+19*4+36=122/6=20.3（天） 標準差：36-10=26/6=4.3（天） 就是說系統在20-25天之間屬於安全時間（能開發的時間）

交付矩陣（資源、專案管理、技術管理、責任）

瞭解各個合作伙伴負責哪塊功能

專案管理矩陣

技術管理矩陣

責任矩陣

明確相關方、系統之間的責任，也可以從快速瞭解整體專案

瞭解潛在風險

溝通機制

像日會、週會、月會、專題會、覆盤會等溝通機制需要明確下來，並在專案執行過程中嚴格執行，專案中80%的問題都是可以透過溝通解決的

雲資源評審

第2周

業務架構圖

DevOps

DevOps是開發運維提效非常有用的工具，是專案成敗的關鍵因素之一

雲原生（容器化、Service Mesh、API閘道器）

容器服務化、微服務

Service Mesh是服務治理的利器，提供了非常強大的功能，如安全、可觀察性、呼叫鏈追蹤、故障注入、灰度釋出等功能

API閘道器

敏捷專案管理Scrum

Scrum框架不僅對於開發的效率提升非常有效，對於其它環節的節目管理也是非常具備借鑑價值的，需要架構師重點考慮把該方法應用於專案交付中

tapd管理

使用tapd對需求、迭代、bug進行統一管理。這是儘量避免合作伙伴使用多個tapd，造成大量重複工作量

第3周

技術架構圖

對架構有個整體理解

部署圖

部署圖有利於後期開發、運維人員對故障進行快速定位、排障

架構決策表

對每項架構決策過程做詳細記錄

風險管理

首先了解和識別現有風險，可以使用的方法有

1. 頭腦風暴法，注意不要讓專家參與（專家比較顧及別人意見）
2. 德爾菲法，親自拜訪徵集和彙總專家意見
3. 瑞士乳酪原理：瑞士乳酪有很多氣泡，但是不會出現一塊乳酪氣泡連通在一起，如果發生了一定是小老鼠光顧過，一定能找出一連串原因
4. 魚骨圖：找出問題根因

魚骨圖

流程變更

第4周

日誌

監控/告警

安全

主機安全、安全運營中心、Web應用防火牆、DDos高防包、雲防火牆、堡壘機、資料安全審計、SDP零信任安全接入系統

擴容方案

容災方案

第5周

灰度釋出

為了使生產環境系統正常穩定執行，我們採用灰度上線的方案，按照一定百分比逐步切換流量到灰度版本，觀察一段時間系統正常穩定執行後，再切換更大的流量給灰度版本，從而完成灰度版本的上線，讓系統升級更加穩定

灰度採用加灰度請求頭部資訊 GRAYSCALE=release 的方式進行驗證

在服務網格具體切換流量的操作辦法

團隊培養

專案交付不是一個人在戰鬥，需要大家齊心協力，共同完成。同樣也需要人才梯隊，向他們灌輸正確有效的理念，讓他們在你沒在場時可以正確、快速地執行下去

文件管理

文件不僅在專案收尾時需要，在專案過程中也是需要收集的，在專案管理中叫組織過程資產，強調的是過程中收集，不是事後才收集