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