技术标准化实践
# 04.技术标准化实践
# 目录介绍
# 01.技术库架构背景
架构组没有版本⽕⻋，有很⼤⾃由度。怎么把⾃由度利⽤好，有条不紊的把技术架构做好？
⽆规矩不成⽅圆，需要设⽴规范，将这部分⾃由度约束起来，规范化。
技术项是架构⼯作的基本单元，但是⽬前对于技术项⽬的管理，还是⽐较混乱的，导致有很多可以改进优化的地⽅。
# 02.目前存在的问题
对过往做过的技术项做了⼀些总结与思考，总结出⼀系列问题：
- 流程混乱，把关不严：缺乏设计、闷头开发、收益质量得不到保障
- 执⾏质量参差不⻬，需要有标准流程托底
- 约束培养团队的严谨做事⻛格
# 03.受众人群有哪些
主要是针对组内的⼤多数研发同学，如何在成本可控的前提下，给⼤家提供技术深造的机会，同时在进展不理想的时候，能够及时⽌损。
通过这套机制，把⼤家的积极性、激情、学习成⻓的诉求，都调动起来。
对于团队来说，发挥集体的⼒量，集体成⻓，这是⼀种更加健康的⽅式，也是试图通过这套机制实现的。
# 04.标准化的⾥程碑
# 4.1 前期调研
准入：1.核⼼是有业务收益；2.约束是投⼊产出⽐；3.充分业内调研，不重复造轮⼦
准出：1.有可运⾏的原型验证；2.通过原型验证，证明可⾏性和收益逻辑；3.有详细整体技术⽅案，并经过正规评审流程
落地实践：原型符合预期，持续投⼊资源；进⼊研发阶段。原型不符合预期：此次调研结论是暂时不可⾏
要点记录：要点⼀：核⼼是有业务收益。技术项的前提。要点⼆：准出时有可运⾏的原型验证；要点三：调研准出才正式⽴项
# 4.2 开发落地
准入：1.研发规划；2.模块设计
准出：1.符合预期地完成代码开发；2.业务接⼊落地，进⼊可上线阶段；3.有详细模块技术⽅案，并经过正规评审流程
落地实践：详细的排期节点，进度把控，按照自己前期排期去坚决执行
要点记录：落地存在风险，由于技术项⽬的复杂性，落地时遇到困难，项⽬进⼊僵局
# 4.3 红灯阶段
准入：1.问题梳理复盘；2.架构负责⼈介⼊；3.指定纠偏⽅案
准出：1.修改，完成代码开发；2.业务接⼊落地，进⼊可上线阶段；3.有详细模块技术⽅案，并经过正规评审流程
落地阶段：抢救成功执行下一步；抢救不成功则需要复盘反省，总结经验教训
要点记录：针对瓶颈问题，快速给出解法；避免⼲耗，磨损⼼智，消耗时间成本；每次进展不符合预期时，都要复盘
# 4.4 收益回收
准入：1.技术项业务落地；2.⽆⻛险灰度上线
准出：1.完成收益回收；2.产出结论
落地阶段：收益符合预期就结项；收益不符合预期就复盘
要点记录：收益要说清楚，最好有定量指标；这⼀步在⽴项前，原型产出时就应当确定下来
# 05.技术库收益总结
有什么收益：主要是解决了什么问题，给项目带了什么收益。让代码更简洁，让功能更加高效，还是其他？
具有衡量数据：优化了什么，效率对比数据分析，内存优化前后数据对比等等，必须要有具体的衡量数据……
有哪些问题待解决：遗留了哪些问题，为什么，后期是否有排期如何去优化？
# 06.问题公告板记录
维护⼀个公开的公告板（Dashboard），谁遇到问题都可以都可以⽹上写。由管理者和技术负责⼈进⾏维护，举例：
- ⼀个任务，限定某端同学认领，难度评估（根据开发时间来评估，1d、1w）
- ⼀个任务，开放式认领，难度评估（根据开发时间来评估，1d、1w）
同学认领之后，能完成更好，但并不⼀定能⼀次性完成，这⾥应当认可推进的成果，推进包括：
- 任务拆分，将⼀个任务拆解成⼀系列任务组
- 部分解决，完成⼀部分任务的解决
其实，问题公告板，也应该有个像需求那样的机制化，实体化，并且与每一版本相关联。有⼀个模块就是⼀个模块，有⼀个功能就是⼀个功能。这样⼤家也能够维护起来。
