👉看目录
1 为什么开发者需要懂项目管理
1.1 项目管理是“通过别人做成事情”的能力 1.2 项目管理能输出个人影响力 1.3 项目管理对个人生活也有价值2 开发者在项目管理中会遇到哪些问题 2.1 开发者的痛点 2.2 怎么衡量项目管理的“好/坏”? 2.3 开发者需要哪些能力3 开发者怎么做好项目管理 3.1 如何做好进度管理 3.2 如何做好质量管理 3.3 如何做好风险管理4 总结本文由腾讯MoonWebTeam团队的赖文辉、蔡卓伦、刘冬、陈长吉协作完成装修工期长,涉及各种材料购置。一次性购置材料会阻碍工人干活,分批购置,又怕丢三落四忙不开;等师傅进场再买,又担心延误工期。除此之外,装修还需要与各类工种打交道,要合理安排各工种工作排序、工期管理。在装修中,能不能少花点钱,就看一个人“成本管理“做得怎么样;能不能快点住进新房子取决于一个人的“进度管理”;而能不能住的安心,就要看“质量管理”有没有做好。 |
|
原则 | 含义 |
两天原则 |
拆解之后的单个任务不能太长。太长的话,就会存在工作量评估不准确、整体项目难以把控的问题。同时也不利于工作的合理分配,不能更好地利用人力资源。如果时间太短,就会导致工作交付的频率过快,开发者的工作之间也会存在着一定的耦合。拆解的粒度太小,会增加一定的沟通成本,得不偿失。 最好工作拆解的粒度为一至两天。 |
成果作为导向原则 |
任务拆解应该以可交互的结果作为导向,并且一定要有输出。这个输出应该是完整的,不然这个拆解就拆解得不够透彻,或者说不算一个任务。 |
责任到人原则 |
拆解之后的任务项,有且只能有一个负责人。即使许多人都可能在其上工作,也只能由一个人负责,其他人只能是参与者。 |
任务分层原则 |
任务拆解的过程也是一个解耦的过程,避免多个任务之间有耦合。拆解的过程应该是自上向下的,从一个大的任务,按照其特性进行任务拆解,不断地拆解成子任务,直到拆解到一至两天的工作量,并且是一个可交付的工作项。 |
事项 |
解析 |
自顶向下,逐层拆解 |
通过 WBS 的工具,对项目进行拆解。为保证任务拆解之后的完整性,应将整体的项目自上向下,逐层拆解。这有利于排查项目开发的各个阶段是否有遗漏。按照项目的研发流程进行拆解任务,再将各个任务进一步细分到所需时间为两天。 |
落实负责人,确认拆解是否合理 | 将每个任务落实到该任务负责人,负责人能够从自己的角度出发,进一步思考该任务的拆解是否合理,同时也能够明确自己所负责的任务需要和谁对接,更能够了解联调的成本。 |
总体复盘,确认有无遗漏任务 | 最后大家根据开发经验,梳理整体流程有无遗漏,如单元测试,埋点开发,联调,代码的 mr 等。 |
估算模式 |
解析 |
自上而下 |
自上而下的估算方式是以项目总体为估算对象。这对于有类似项目经验的工程师来说较容易评估。方法是将工作结构从头部向尾部依次分配、传递工作量,直到到达WBS 的最底层。其特点是:
|
自下而上 | 自下而上的估算方式是,先估算各个工作项的工作量,再自下而上的将各个工作量进行汇总,算出总的工作量。其特点是:
|
解决方法 | 解析 |
明确责任人和交付时间,避免模糊 |
这是第一步。当一个事情出现多个负责人的时候,责任的边界就会模糊,就容易互相推诿的情况,这就是责任分散效应。三个和尚没水喝的故事就是一个典型案例。 因此对于每个依赖项,我们需要明确其责任人,并沟通明确每个人对应依赖的交付时间,把责任人和交付时间提前确定清楚,可以减少很多争议和推诿。当项目涉及很多团队的时候,可以使用资源依赖列表,当遇到问题时,可以快速查找负责人及其应当交付的时间点。 例子:云游 XX 活动的资源依赖列表 |
形成信息对齐机制 |
确定了接口负责人后,如果不及时进行信息对齐,也会出现跑偏的情况。 反面案例: A 项目依赖外部的 sdk的 某个升级版。在最初的对齐方案中,sdk 方承诺不会修改原有的接口调用方式。而实际联调中才发现不仅接口调用方式发生了巨大变化,还有部分被依赖的接口直接在新版本中移除,导致A方需要花费大量时间进行兼容。如果提前对齐而不是等到联调阶段才介入,就能规避上述问题。 关于信息对齐方式,有以下几种:
在里程碑等关键节点通过面对面、电话、企业微信等方式进行信息对齐。对齐内容包括:开发进度、依赖事项进展、技术方案变更等,对于一些关键性的结论,最好有文字落地以用于回溯。
如定期晨会机制。在会议上对齐项目进度,可以提前发现可能存在的风险。记录会议纪要并通过群消息/文档/邮件的形式通知到项目的相关干系人。
应当确定一个项目 owner,对项目整体负责,把关整体节奏,负责组织会议。把相关信息进行整合,并同步给项目的相关干系人。 |
求同存异,达成共识 |
作为项目组的成员,大家的核心目标应是一致的,就是让这个项目能够如期保质上线。但在实际执行中,各个依赖方因为各自的问题,会出现一些偏差。只要能核心目标是一致的,相关的问题就可以通过沟通解决。 案例:春节活动需求变更 PK 作为最重要的传统节日,很多业务团队都会针对春节这个时间节点运营、上线活动,作者曾经遇到过在临近提测时,活动仍在被提需要大量变更的情况(运营人员要叠加功能,设计人员则提出更多特效的要求),开发人员如果接受了大量变更,不仅意味着不断加班,更可怕的是会由此带来很大的质量风险,一旦出现严重问题,会得不偿失。 最后只能是开发人员联合测试人员,跟运营和设计进行了沟通,研发侧认可变更对于提升活动效果有作用,同时也对变更可能带来的延期,以及影响线上质量等风险进行了全面分析评估。双方基于共同的目标做出了协商和让步(既保证活动效果,同时也保证活动正常安全上线)。 |
情感账户,软性推动 |
当项目依赖某个外部团队的人员支持,而这个事情并不是对方当前工作范围内的,并不是对方第一优先级的工作,该怎么办? 大部分情况,有些开发者会在沟通未果的情况下,通过上升到leader去推动事情落地,这是一种解决方案。更优的方案是建立相关依赖方的“情感账户”,借助“情感账户”去软性推动。 大家都知道银行账户就是把钱存进去,作为储蓄,以备不时之需。“情感账户”里储蓄的是人际关系中不可或缺的信任。经营好「情感账户」,也是经营好一个人与合作伙伴的信任关系。 在日常工作中多吃亏,让自己的「情感账户」适当“存储”。例如自己曾经抽出休息时间帮助合作伙伴解决问题,当需要对方协助的时候,相信也能得到积极的响应,这也是常说的“吃亏是福"。 |
|
评估高优需求的工作量,以及影响当前项目的程度。 如果在 0.5 天以内,没有被依赖的下游时,再评估对排期影响不大的情况下是否可以快速响应。并第一时间反馈风险,确保各干系人都有一个心理预期;如果大于 0.5 天的需求,则建议反馈给项目干系人来安排其他人来解决。 |
|
|
阶段 | 事项 | 是否通过 |
提测前 |
根据前期编写的测试用例进行整体自测 | |
根据埋点文档验证埋点,确保埋点中的事件和维度不多报、不漏报、不错报、不重复报、报的时机正确 | ||
根据设计稿叠图并截图(2+测试机),确保无视觉问题 | ||
确保分支的代码 CR 通过 | ||
确保代码已发布到测试环境,并确认页面能够正常访问 | ||
确保创建了提测单,提测单包含测试用例地址、测试范围、测试入口和二维码、终端环境、埋点文档地址 | ||
确保需求单状态扭转到增量测试中 | ||
bug修复后 |
涉及到功能、逻辑、埋点、样式和交互变更:重新走本次需求逻辑部分的自测、涉及样式的叠图、CR 和发布测试环境流程,确保全流程无误 | |
确保bug单状态扭转到已处理,并通知测试同学验证,保证在 1D 之内扭转到已关闭 | ||
确保需求单状态扭转到待发布 | ||
发布前 |
确保产品体验、设计走查、测试都通过 | |
确保所有代码(功能+bug 修复)都已经通过 CR,合入 master | ||
确保正式环境配置文件中的配置都是正式环境的配置 | ||
如图片有新增和修改,确保图片已经进行过压缩 | ||
确认接口监控的数据正常,业务错误码屏蔽正常,不误报 | ||
上线前和产品运营确认线上配置是否正确,涉及运营资源是否到位 | ||
和后台、终端确认好发布顺序,并确保按照约定顺序发布 | ||
确保在群里进行发布周知,提交的发布审批通过才能进行发布 | ||
发布后 |
待 CDN 生效后,用非公司 wifi 访问页面,确保页面正常,同时确保所有的资源都是正式的 CDN 地址 | |
关注告警群消息,关注告警监控平台流量监控是否有较大波动,JS 报错、接口错误率是否有上涨,关注是否有告警 | ||
发布出现问题,及时在群里周知并回滚,通知leader,并寻求团队成员协助定位排查 | ||
发布外网后需要留守至少 30 分钟 | ||
确保需求单状态扭转到已交付和已接受 |
隔离方式 |
解析 |
分层架构 |
分层架构的一个重要原则是每层只能与其下方的层发生依赖。由于各层间松散的耦合关系,使得开发者可以专注于本层的设计,而不必关心其他层的设计或本次变更会影响到其它层,只需保持本层的接口稳定。大型系统中推荐使用 DDD (领域驱动设计),将系统拆分成展现层、应用层、领域层、基础设施层。 |
组件化设计 | 组件化可以比喻为积木。其工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化,使它具备完整的局部功能,再通过自由组合来构成整个产品。 |
特性开关 | 目前最为常用的隔离方式还是特性开关。这种方式隔离较为彻底,如果某种场景不需要该特性,直接关闭开关即可,缺点在于代码中可能会存在许多开关逻辑。 |
资源隔离 | 从物理上隔离变更导致的影响,通常使将其以服务、静态资源、网络、内存、进程等方式进行隔离,通过使变更带来的影响在可控范围内,隔离其对其他资源的影响。 |
|
类型 | 指标 | 案例 |
脚本问题 | 页面js错误、接口错误、页面白屏、资源加载错误 等 | 页面 JS 错误 xx is not defined |
性能问题 | 首屏耗时、首屏可见耗时、接口平均耗时、接口成功率 等 | 检测到近 5 分钟领取礼包接口接口成功率下降触发告警 |
业务问题 | 流量下跌、核心链路转化率下跌、特定业务错误上升 | 云游戏用户排队耗时提高导致用户流失,需要额外开启设备 |
合理日志的要素 | 解析 |
日志时间 | 日志作为事件的表述,事件发生的时间是一定要具备的。 |
日志级别 | 应该根据日志的重要性或严重程度划分等级,常用的日志级别有:DEBUG、INFO、WARN、ERROR,只有合理定义日志级别,才能避免日志混乱。日志级别也是日志告警的关键条件。 |
业务标识 | 用来区分日志属于哪块业务,因为日志都是跟业务相关联的,通过该部分内容便于按业务进行日志归类聚合。 |
日志内容 | 根据不同的日志等级,在日志内容上会有不同的侧重点,尽量描述清楚。 |
异常堆栈 | 堆栈异常信息有助于程序异常的排查定位,但这部分信息的记录输出,对系统性能有一定的影响,应该酌情考虑,如果记录异常信息足够定位异常,就不要打印整个堆栈。一般是 ERROR 打印异常堆栈,WARN 不打印,还有就是通过日志框架打印,避免用 printStackTrace 方法打印。 |
追踪 ID | 对于单次用户行为需要一个唯一的ID 贯穿全链路日志,方便对用户行为进行追踪,错误信息也能够查询到用户行为的上下文,方便定位日志。 |
日志记录的时机 |
解析 |
程序流程 | 记录程序的流转分支,在关键代码逻辑的执行前后进行相应的日志输出,有助于代码调试。但要避免不必要的日志输出,比如一般只在循环体前后记录日志,而不在循环体内重复记录,过多的日志反而会影响阅读。 |
远程调用 | 远程调用也属于程序流程的一部分,但第三方远程调用的日志信息级别,应该与一般的调试日志区别对待,因为涉及到外部系统的交互,在出入口处记录请求响应的信息,这相当重要。 |
系统初始化 | 系统初始化需要依赖一些关键配置参数,这些参数决定系统的启动状态,应该把这些系统初始化信息记录起来。 |
核心业务操作 | 系统用户进行核心业务操作的行为,也应该进行记录,便于进行操作审计。 |
可预期的异常 | 这类异常应该有效记录起来,通过警告方式反馈给相关人员加以关注,避免频繁发生,最终演化为不可控的错误。 |
预期外的错误 | 这类异常发生时,要有详尽记录,并通知相关人员介入处理,并预留时间作出响应,因为这种错误已经影响系统的正常使用。 |
风险如鬼魅在深渊潜藏,它可能出现在项目中任何一个环节,在未来的某个时刻出现,对开发者负责的项目产生破坏性的影响。 |
风险具备以下特征:
日志记录的时机 |
解析 |
客观性 |
风险是客观存在的,不以人的意志为转移,项目中存在风险是常态 |
不确定性 |
风险是否造成损失,以及损失的程度,是不确定的 |
可观测 |
单一风险存在不确定性,但是总体来讲是有规律的,有办法预测的 |
可变性 |
风险会随着应对措施的进行而消失,不会一层不变 |
风险识别方法 | 解析 |
头脑风暴法 |
一些人聚集起来,进行头脑风暴,通过彼此的沟通交流,想法、建议、意见进行碰撞,一起发现问题。 |
专家调查法 |
由相关领域的专家组成风险小组,通过征求专家的意见,然后开发团队综合汇总整理,再反馈给专家,再次征求专家的意见,反复进行 4~5 轮,最终专家们的意见会趋于一致,达成共识。 |
情景分析法 |
识别关键影响因素,基于该因素可能发生的场景,进行场景内容的分析,进而发现风险可能造成的后果。 |
核对表法 |
将项目范围、目标、成本、质量要求、进度、类似项目成功或失败的原因等列在一张表上,进行一一核对。这种方法可以识别到进度风险、成本风险、质量风险等。 |
流程图法 |
需要建立项目的全链路流程图以及各子域流程图,这些流程图可以涵盖项目的整体流程以及分支细节。通过将实际情况与流程图一一对比,便可识别风险。 |
|
方法 | 说明 | 例子 |
规避风险 |
消除风险因素进而规避风险的产生 | 1、 改变项目目标包含的范围2、 投入更多的成本(人力、资金) |
转移风险 | 将风险转移给第三方 | 购买保险 |
减轻风险 | 降低风险发生的概率或受影响程度 | 1、 将鸡蛋放在不同篮子2、 兜底策略 |
接受风险 | 对即将发生的风险,不采取措施 | / |
风险 |
解析 |
进度方面的风险 |
因为外部依赖、需求变更或者高优需求插入,带来项目延期风险。这里在进度管理章节,已经重点介绍了如何管理依赖,如何跟产品人员沟通需求变更,以及如何管理好自身的排期。 |
质量方面的风险 |
主要是在项目研发环节中会产生质量问题,如自测不充分导致提测期间 bug 数过多,在质量管理一节中也介绍了对应的解决方案。 |
成本方面的风险 |
降本增效是最近两年的主题,大家对成本的关注越来越多。成本也是一项重要风险,特别是大项目,但因为不是开发通点,本文不展开讨论。 |
|
|
|
|
如喜欢本文,请点击右上角,把文章分享到朋友圈
如有想了解学习的技术点,请留言给若飞安排分享
因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读:
架构师作者:MoonWebTeam:赖文辉、蔡卓伦、刘冬、陈长吉
来源:腾讯云开发者
版权申明:内容来源网络,仅供学习研究,版权归原创者所有。如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
我们都是架构师!
关注架构师(JiaGouX),添加“星标”
获取每天技术干货,一起成为牛逼架构师
技术群请加若飞:1321113940 进架构师群
投稿、合作、版权等邮箱:admin@137x.com