其他
光有技术怎么够？为什么说每位开发者都要懂点项目管理？
The following article is from 腾讯云开发者 Author 腾讯MoonWebTeam
1.3 项目管理对个人生活也有价值
我们的生活很多事情都符合宽泛的“项目”的定义。
工作量评估问题：工作量评估不准确
进度问题：日常杂事或者临时问题打乱排期
外部依赖问题：设计/后台等外部资源延期/需求变更，怎么推动解决？
沟通问题：如何让大家对需求的理解保持一致？
效率和质量平衡问题：怎么既保证开发效率又保证质量？
....
2.2 怎么衡量项目管理的“好/坏”？
3.1.1.1 需求详细方案设计
3.1.1.2 合理拆解，明确职责
3.1.1.3 估算工作，知晓预期
项目初期信息不足，只能初步分解工作结构，很难将最基本的工作详细列出来
估算的精度较差
估算的工作量小，速度快
估算的精度高
估算的成本较大
缺少子工作项之间的工作量的估算
3.1.2 如何做好依赖管理
准备开始开发了，发现设计稿还未就绪；
准备联调的时候，发现我们上下游的技术团队的接口还未就绪；
可以联调的时候，因为上下游的链条很长，出现推诿甩锅
3.1.2.1 明确责任人和交付时间，避免模糊
3.1.2.2 形成信息对齐机制
不定期的非正式的沟通
定期的例会机制
项目owner机制
3.1.2.3 求同存异，达成共识
3.1.2.4 情感账户，软性推动
3.1.3 如何处理意外事项
3.1.3.1 需求的变更
判断需求变更的大小，如果是简单的样式修改等半小时能解决的小问题，可以协助快速调整；如果工作量在0.5天以上，并且还需要依赖于第三方接口，则需要将整体的需求进行重新评估，重新梳理排期，并同步给干系人
先保证核心的业务流程不变，高收益的工作量优先，先保证正常的上线时间，后续有余力再对此功能点进行迭代优化
3.1.3.2 高优需求插入
评估高优需求的工作量，以及影响当前项目的程度。如果在0.5天以内，以及没有被依赖的下游时，在评估对排期影响不大的情况下可以快速响应，同时第一时间反馈风险，确保各干系人都有一个心理预期；如果大于0.5天的需求，则建议反馈给项目干系人安排其他人来解决。
3.1.3.3 不可抗力的因素
如果是一些身体原因，导致办公效率低下，在不影响整体项目交付的情况下，适当的延长完成的时间，若影响到整体项目交付的时间，则应该暴露该风险，进行调整项目计划
如果是完全不能投入开发，应该尽早的将此事情向上级报备，由上级进行统一的人力调整，交由其他人投入开发
3.1.3.4 内部依赖延后
将自身的业务流程跑通，依赖部分通过模拟的方式解决
将联调的时间后移，先开发其他的功能模块
如果已经是最后联调阶段，则需要再次调整交付的时间，同时将该风险同步给相关的干系人
3.2.1 通过流程规范提高质量
3.2.1.1 制定研发流程规范
3.2.1.2 严格执行Code Review
3.2.1.3 制定发布checklist
3.2.2 管理变更影响
3.2.2.1 通过详细设计评审技术方案
3.2.2.2 通过架构设计上隔离变更
3.2.3 功能回归的能力
功能回归能力是通过自动化的回归测试寻找原始设计中没有预料到的错误。
3.2.3.1 有效的测试是设计出来的
3.2.3.2 接入自动化测试平台
3.2.4 发现问题和定位问题的能力
研发阶段我们尽量保证质量，不出现BUG；上线后我们需要确保一旦出现问题，能快速通过告警发现，并快速定位找到原因，从而最大限度降低对现网的影响。
3.2.4.1 利用监控告警发现问题
3.2.4.2 规范日志快速定位问题
3.2.4.2 智能化监控平台
3.3.1 风险管理管的是啥？
3.3.1.1 风险的本质
3.3.1.2 风险的特征和构成要素
客观性：风险是客观存在的，不以人的意志为转移，项目中存在风险是常态
不确定性：风险是否造成损失，以及损失的程度，是不确定的
可观测：单一风险存在不确定性，但是总体来讲是有规律的，有办法预测的
可变性：风险会随着应对措施的进行而消失，不会一层不变
3.3.1.3 风险管理怎么做？
1、风险识别：
头脑风暴法：
专家调查法：
情景分析法：
核对表法：
流程图法：
2、风险评估：
定性分析：根据风险的重要程度和发生概率等指标对风险因素进行排序
定量分析：将体现风险特征的指标量化，以强化对风险因素的认知
3、风险应对：
从“规避风险”的角度，我们可以投入更多的备份人力，或者调整项目目标（如调整上线时间点）；
从减轻风险的角度，我们可以实施分散办公（居家办公），减少项目组成员被“一锅端”的风险
从接受风险的角度，如果项目因为疫情带来的延期是可以接受的，也可以不采纳任何措施；
3.3.2 实际项目我们要关注哪些风险？
3.3.2.1 最常出现的风险
进度方面的风险：
质量方面的风险：
成本方面的风险：
3.3.2.2 性能风险
3.3.2.3 安全风险
在“开发测试阶段”，确认工程是否在流水线中接入“代码扫描工具”；
在“上线阶段”，确认服务是否接入”安全扫描“工具进行扫描；
在“运营配置阶段”，确认相关运营系统的配置是否经过审查测试
涉及数据查询修改，必须有登录态校验
涉及数据修改，必须要有token校验，避免CSRF攻击
所有输入都需要白名单校验，包括从URL获取数据、从cookie获取数据、从表单获取数据等，避免SQL注入、XSS攻击等
涉及福利相关，必须有黑产打击策略
是否有严格的用户权限校验
涉及外部对接时，必须包含加密或验签环节
还存在哪些安全隐患？
是否考虑防安全扫描
3.3.2.4 容灾性风险
系统即将面临的最大流量是多少
需要提前多久跟运维沟通扩容？
系统各个环节能承受的流量压力，哪些环节需要扩容？
如果流量陡增、服务过载时，系统有没有做兜底降级方案?
有没有做多地部署，规避单点风险？
...
数据结构是否变更，如果变更是否考虑老数据兼容？
边界条件是否
运行环境可能存在的兼容性问题？（前端经常遇到）
....