交付架构师工作指引
作者：yeedomliu
非常重要，非常必要，甚至来得有点晚。
介绍
为什么写
- 公司在往产业互联网方向转型（仅3-4年），公司在这方面沉淀较少，交付架构师变动又比较大，项目在交付中碰到很多问题，导致在项目上交付困难
- 在交付项目上，项目经理大多不懂技术，架构师不懂项目管理，因此会导致项目经理和架构师在交付项目上不能形成有效合力，项目失败的可能性会大大增加。
- 交付架构师除了需要学习项目管理，还需要学习一些其它角色的技能，能极大提高项目成功交付的可能性
技能要求简述
- 如果用格斗来比较，散打、摔跤、拳击是不同的项目中不同的角色，交付架构师则是综合格斗MMA，既需要熟练掌握各门派知识，又需要融汇贯通使用各项技能。但在工作中很容易会认为这个职位跟其它职位一样，是单技能的一个职位
- 在项目交付时交付架构师需要和项目中各种角色（从前到商务、后到运营）沟通，因此具备各个角色的专业知识是沟通畅通、项目顺利进行的有效保证
- 在项目交付是很困难的，一是面对众多ISV，二是面向众多角色；项目交付难度略等于『ISV数量』*『角色数量』
职责
项目交付工作流程安排
第1周
主要了解项目各方面情况，通过了解或收集以下信息能快速了解一个项目概况
相关方
相关方很重要，项目往往是死在被忽略的相关方手里，必须识别出来所有可能影响到项目的所有人，并且对它们采取合适的管理手段
咨询项目经理PM获取相关方资料，如果没有需要催促PM制作『相关方』表格
除了有相关方登记表格外，还需要按照影响力、态度、影响阶段整理相关方
- 影响力（权力/Power）：无（0），弱（1），中（2），强（3），极强（4）
- 态度（利益/Interest）：抵制（-2）、反对（-1）、中立（0）、支持（1）、推动（2）
- 影响阶段：I启动、P规划、E执行，C收尾：（可多选）
WBS工作分解结构（需求、范围、交付清单）
范围尽快确定是非常重要的事，只有确定了后续UI、开发、设计等工作的开发。需要催促产品或PM尽快落实
几点注意事项
- 所有需求有客户书面确认（需求确认书）
- 有详细的进度计划、并且有强烈的时间观念
- 经常跟相关方沟通
时间管理
进度计划
里程碑
时间估算
项目上工期常常需要评估时间，这块也是个挺头疼的问题，不同经验的开发对于同一个功能评估差距巨大，可以使用『三点估算』法进行快速准确的评估
比如项目上一个例子 最开始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周
技术架构图
对架构有个整体理解
部署图
部署图有利于后期开发、运维人员对故障进行快速定位、排障
架构决策表
对每项架构决策过程做详细记录
风险管理
首先了解和识别现有风险，可以使用的方法有
- 头脑风暴法，注意不要让专家参与（专家比较顾及别人意见）
- 德尔菲法，亲自拜访征集和汇总专家意见
- 瑞士奶酪原理：瑞士奶酪有很多气泡，但是不会出现一块奶酪气泡连通在一起，如果发生了一定是小老鼠光顾过，一定能找出一连串原因
- 鱼骨图：找出问题根因
鱼骨图
流程变更
第4周
日志
监控/告警
安全
主机安全、安全运营中心、Web应用防火墙、DDos高防包、云防火墙、堡垒机、数据安全审计、SDP零信任安全接入系统
扩容方案
容灾方案
第5周
灰度发布
为了使生产环境系统正常稳定运行，我们采用灰度上线的方案，按照一定百分比逐步切换流量到灰度版本，观察一段时间系统正常稳定运行后，再切换更大的流量给灰度版本，从而完成灰度版本的上线，让系统升级更加稳定
灰度采用加灰度请求头部信息 GRAYSCALE=release 的方式进行验证
在服务网格具体切换流量的操作办法
团队培养
项目交付不是一个人在战斗，需要大家齐心协力，共同完成。同样也需要人才梯队，向他们灌输正确有效的理念，让他们在你没在场时可以正确、快速地执行下去
文档管理
文档不仅在项目收尾时需要，在项目过程中也是需要收集的，在项目管理中叫组织过程资产，强调的是过程中收集，不是事后才收集
速抢免费红包封面！
