交付架构师工作指引

18bf92d390b8e028478a74e44e7c2ff8.gif

作者:yeedomliu

非常重要,非常必要,甚至来得有点晚。

介绍

为什么写

  1. 公司在往产业互联网方向转型(仅3-4年),公司在这方面沉淀较少,交付架构师变动又比较大,项目在交付中碰到很多问题,导致在项目上交付困难

  2. 在交付项目上,项目经理大多不懂技术,架构师不懂项目管理,因此会导致项目经理和架构师在交付项目上不能形成有效合力,项目失败的可能性会大大增加。

  3. 交付架构师除了需要学习项目管理,还需要学习一些其它角色的技能,能极大提高项目成功交付的可能性

技能要求简述

  1. 如果用格斗来比较,散打、摔跤、拳击是不同的项目中不同的角色,交付架构师则是综合格斗MMA,既需要熟练掌握各门派知识,又需要融汇贯通使用各项技能。但在工作中很容易会认为这个职位跟其它职位一样,是单技能的一个职位

  2. 在项目交付时交付架构师需要和项目中各种角色(从前到商务、后到运营)沟通,因此具备各个角色的专业知识是沟通畅通、项目顺利进行的有效保证

  3. 在项目交付是很困难的,一是面对众多ISV,二是面向众多角色;项目交付难度略等于『ISV数量』*『角色数量』

041e43e8f3b260510ede43c9abe7da8e.png

职责

52044e608927e5eea3d5bebf9dfc12d3.png

项目交付工作流程安排

第1周

主要了解项目各方面情况,通过了解或收集以下信息能快速了解一个项目概况

相关方

相关方很重要,项目往往是死在被忽略的相关方手里,必须识别出来所有可能影响到项目的所有人,并且对它们采取合适的管理手段

咨询项目经理PM获取相关方资料,如果没有需要催促PM制作『相关方』表格

61f45e637b7da23573d28b2829e48dfb.png 1e3d5f8a8ef0d3af5f38ae522a5e5d25.png

除了有相关方登记表格外,还需要按照影响力、态度、影响阶段整理相关方

de20a511bcd0729ea54044e17442102d.png
  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. 经常跟相关方沟通

8204fd3df0f9ceb2d435e88bf0b8abfa.png
时间管理
进度计划
384280cf58fdbad516fa43e453106263.png
里程碑
36637019e8747c65e49224720460bf05.png
时间估算

项目上工期常常需要评估时间,这块也是个挺头疼的问题,不同经验的开发对于同一个功能评估差距巨大,可以使用『三点估算』法进行快速准确的评估

比如项目上一个例子

最开始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天之间属于安全时间(能开发的时间)

07efdab2958962c0db8ddb9699807b03.png
交付矩阵(资源、项目管理、技术管理、责任)

了解各个合作伙伴负责哪块功能

97bde8fe51a1a0ed2c56e4ea096f2474.png

项目管理矩阵

77bed8476d86f18bc85181d60d5b10b1.png

技术管理矩阵

90b41a1a3a4842532c7666a6b2eb2c1c.png

责任矩阵

明确相关方、系统之间的责任,也可以从快速了解整体项目

8fa5acc8725369192bc5ba387393ce3c.png
了解潜在风险
ec44f63e1a830449f28bffe836ca2c9f.png
沟通机制

像日会、周会、月会、专题会、复盘会等沟通机制需要明确下来,并在项目执行过程中严格执行,项目中80%的问题都是可以通过沟通解决的

7ffc1579e51578129259d369a3704461.png
云资源评审
9088e2f81d3519b2617defc73901d67f.png

第2周

业务架构图
cc4eba1ce812cfa547df626a87f88316.png
DevOps

DevOps是开发运维提效非常有用的工具,是项目成败的关键因素之一

bc12338f554c659993d37135869e55bf.png 6d782205912deb6c7de3e417bb9d797e.png
云原生(容器化、Service Mesh、API网关)

容器服务化、微服务

dae3ee9408bd969fc352b00c23773396.png

Service Mesh是服务治理的利器,提供了非常强大的功能,如安全、可观察性、调用链追踪、故障注入、灰度发布等功能

017014554471ae4977c27c19c6c63d6e.png
API网关
76628bcf1ea580b879daf3584bebc4ee.png
敏捷项目管理Scrum

Scrum框架不仅对于开发的效率提升非常有效,对于其它环节的节目管理也是非常具备借鉴价值的,需要架构师重点考虑把该方法应用于项目交付中

3ab56ddadd1f30a75630c14e29cf5240.png
tapd管理

使用tapd对需求、迭代、bug进行统一管理。这是尽量避免合作伙伴使用多个tapd,造成大量重复工作量

a995d2431407b8a5156059fdfa78e706.png

第3周

技术架构图

对架构有个整体理解

edb4fe174da46575d352e32000111913.png
部署图

部署图有利于后期开发、运维人员对故障进行快速定位、排障

3b646338e869f352838cd4e4e6aaff31.png
架构决策表

对每项架构决策过程做详细记录

a4eaf64f9d113c539a34e633391ece8b.png
风险管理

首先了解和识别现有风险,可以使用的方法有

  1. 头脑风暴法,注意不要让专家参与(专家比较顾及别人意见)

  2. 德尔菲法,亲自拜访征集和汇总专家意见

  3. 瑞士奶酪原理:瑞士奶酪有很多气泡,但是不会出现一块奶酪气泡连通在一起,如果发生了一定是小老鼠光顾过,一定能找出一连串原因

  4. 鱼骨图:找出问题根因

bd4ac4350b33790f37ebe2f76c815e3d.png

鱼骨图

0bed4166a2df56db3d90723cece5f2de.png
流程变更
9dd3b6a17c1d7d49ecf86e9450eb18c7.png

第4周

日志
96c093438e27c38a3d2886d4d3e97072.png
监控/告警
8c9a0e191e1393d55d1051e5fb5f6da5.png
安全

主机安全、安全运营中心、Web应用防火墙、DDos高防包、云防火墙、堡垒机、数据安全审计、SDP零信任安全接入系统

扩容方案
1423fcc67237b0137a068e31bd602abb.png
容灾方案
1f65e6f580d41f482c31b985b294ebc7.png

第5周

灰度发布

为了使生产环境系统正常稳定运行,我们采用灰度上线的方案,按照一定百分比逐步切换流量到灰度版本,观察一段时间系统正常稳定运行后,再切换更大的流量给灰度版本,从而完成灰度版本的上线,让系统升级更加稳定

灰度采用加灰度请求头部信息 GRAYSCALE=release 的方式进行验证

fcad696dae5cfe1f0c3325470dd9e237.png

在服务网格具体切换流量的操作办法

5d19a574b729e7c4d2696ba636afff72.png
团队培养

项目交付不是一个人在战斗,需要大家齐心协力,共同完成。同样也需要人才梯队,向他们灌输正确有效的理念,让他们在你没在场时可以正确、快速地执行下去

61dc3be274b3e6700cb8060b080e1534.png
文档管理

文档不仅在项目收尾时需要,在项目过程中也是需要收集的,在项目管理中叫组织过程资产,强调的是过程中收集,不是事后才收集

3728c2a3fee070544604a99fdede4861.png

459f69df443be6a6f614b14518f831f1.png

速抢免费红包封面!

dab119438ef39be5de5143f99367240d.png

猜你喜欢

转载自blog.csdn.net/Tencent_TEG/article/details/122710902