1、前言
本文是揭秘大厂系列的第一篇，技术专项落地的全流程，接下来会陆续给大家带来研发流程、稳定性机制、动态化方案、研发效能、面试官修养、工作体验等多维度多方面的详细介绍，有技术专题，也不止于技术，希望可以给你带来有"原来如此"也有"不过如此"的认识和理解。如果大家有想了解其他方面的，也欢迎提议。
下面开始正文。
2、什么是技术专项
技术专项通常是指对某一特定领域技术的研究、开发和应用，简称技改。
技术专项是以技术为主导的需求，通常规模大，涉及业务多，影响范围广，对稳定性和性能要求高。
技术专项通常分为两个方向：
- 面向过去：主要是治理和优化，比如解决技术负债、性能优化、脚手架升级、SDK升级等等；
- 面向未来：主要是探索和布局，比如跨平台、云开发，以及当下热门的人工智能等等；
在大厂，通常对技术专项都是有一定占比投入的。做技术的同学都知道，时间一长，再好的代码也会腐化，而且架构也需要不断的演进来更好的支撑业务增长，所以，技术专项的投入和落地是意义重大的。
3、技术专项落地的挑战
作为专项的负责人，遇到技术难题要冲在第一位，除了要做技术攻坚以外，在很多方面也都是要亲力亲为，比如你要自己写文档拉会、盯进度、控风险、发灰度、复盘等等，简而言之，整个交付链路的各个环节，你都要主导和跟进，要投入更多的时间和精力。而写代码之外的事情，是很多程序员并不擅长或者没经历过的，也就导致容易在一些环节上出现问题。
比如在跨团队协作上，可能会遇到以下问题：
- 其他团队的同事不鸟我怎么办?
- 其他同事没有排期怎么办？
这些都是常见且易发生的问题。
接下来就介绍下完整的交付链路，以及技术同学在技改项目中的各个环节需要做什么和注意点。
4、交付链路
大致可以分为三个阶段：规划阶段、执行阶段、交付阶段。
4.1、规划阶段
4.1.1、项目立项
项目立项是项目管理过程中的一个关键步骤，它标志着项目的正式开始。
在开始之前，先跟领导通个气，重点在收益和风险上达成一致，获得领导的认可和支持。
在确定要做之后，着手开始写文档。
文档包括多个子项：
- 需求分析：交代背景、明确目标、确定范围、ROI分析以及评估优先级。
- 可行性分析：做好方案调研，纵向对比+横向对比，从技术、业务、合规等多角度评估项目可行性和需要的资源。
- 制定计划：基于需求分析和可行性分析的结果，制定出项目的初步计划，明确团队分工和职责边界、各业务接口人、项目里程碑等。
- 风险评估：技术风险、进度风险、合规风险等。
- 执行和落地：包括怎么开发、怎么测试、怎么发布等环节。
在目标的设定上，不要过早纠结于技术实现的可行性，只要是有价值有意义的，任何人都可以是你的协调资源。
我自己在职业生涯早期就过早纠结于技术能否实现，从而忽略了需求本身能给业务和技术带来的真正价值。遇到问题解决问题，很多技术难题也不一定非得从技术上才能解决。
在大多数公司，要业务先起飞，才有技术的可为之处。
4.1.2、需求评审
文档写好之后就开始摇人，拉会，参与的人以及他们的领导。
拉领导虽有为项目保驾护航的意思，但也是人情世故，调用其他团队的资源不打声招呼总归是不合适的，也是在领导们面前露脸的好机会。
在评审前，要反复斟酌你的文档，站在参与人的视角来看，是否能看明白，是否清楚的知道自己需要在什么时间做什么事以实现什么样的目标。
一些细节的点可能在评审的时候不用深入，但是也要体现出来，比如一些资料、参与人员列表、甚至分支命名等。
一般大的技改项目可能一次还评不完，比如有遗漏的地方，记好待办项，完成之后再拉二次评审。
改动较多的情况还会有拆分的子项，周期较长的情况也会拆分一阶段二阶段等，这些就自己看项目把控了。
4.2、执行阶段
4.2.1、开发
需求评审完之后就是进入开发阶段了，这个阶段没啥好说的，基本就是无情编码，以技术实现为主，注意代码质量和进度把控。
遇到问题及时抛出来，不要让自己成为卡点，方案行不通的地方拉大家一起讨论。
4.2.2、联调
联调是指自己的这部分开发完成之后，跟上下游、接口进行调试的过程，一般会提前定义好协议、字段、参数、调用姿势等。
4.2.3、提测
开发联调结束之后就是提测，一般大的项目还会有一个专门的提测文档，明确影响面和测试范围，以及对应的开发人员、测试人员和测试进度，为了避免混乱，最好找一个测试同学来统筹跟进大家的进度。
测试同学也会根据变更和影响面来写测试用例，然后拉开发同学一起补充完善。
除了常规测试之外，还会有性能测试、兼容性测试、压测、风险预案测试等等，不一定全要，按需即可，同时验证降级开关和监控埋点的有效性。
4.2.4、跟测
提测之后难免会有bug，这个时候就需要开发同学来fix了。
一般会选一个单独的bug空间或者统一标题，方便查看还有哪些问题。
为了把控问题的修复进度，一般也会不定期拉会或者站会一起过进度，以及讨论问题的解决方案、历史问题的处理等。
4.2.5、CodeReview
CR一般在提测之后和集成之前进行的，由开发来主导，测试打辅助。一般围绕着代码的质量、安全性和可维护性来展开的，学习谈不上，主要是大家一起看更容易发现潜在问题。
变更较多的情况下，考虑到效率，不会一行一行的去看，会把大致的流程过一遍，保证结构和逻辑正确。
现阶段用AI来CR目前只能是辅助，比较单点，全局性的逻辑问题还是需要人来check。
4.2.6、集成
测试完成之后就要开始集成了，就是把代码从feature分支往release分支合并的过程，变更多的情况下可能耗时较长，搞一天都是常事，提前预留好充足的时间。
要注意解决好冲突，避免代码合丢的情况。
4.2.7、回归
集成之后会基于release分支打包，然后测试同学再进行一次整体的回归，比如验证各业务线的核心链路等，也是避免测试范围评估有遗漏的地方。
4.3、交付阶段
4.3.1、发布
一般要发布的时候也会拉大家一起看，比如怎么灰，是特定圈选还是按比例，另外有发布依赖的话也要确定好发布顺序。
4.3.1.1、灰度发布
回归没有问题就准备在窗口期进行灰度了，灰度节奏也需要在文档中明确列出来，一般大的技改的灰度周期会相对长一些，3-5天不等，每次灰度的量也要同步出来，方便大家一起观测稳定性指标。
如果灰度期间出现问题，优先通过回滚或降级来止血，再定位根因，然后增发fix版本，继续灰度，继续观测。
4.3.1.2、正式发布
一般大的技改会走独立的灰度版本，灰到一定量就不灰了，当然也不排除跟全量版本一起的情况，这时候灰度量会增加，但是灰度周期不变，比正常版本的周期长一点，便于观测和修复问题，没问题的情况下就开启全量，即正式发布。
有的问题会在达到一定量之后才暴露出来，所以在发布期间要做好指标观测，必要时拉上下游一起观测。
4.3.2、复盘
全量之后用户量慢慢就上来了，这时候各项指标就趋于一个正常合理的水位了，不会因为基数少而导致指标较高或较低的情况。
就可以着手写一个复盘文档了，目标达成还是不符合预期，都诚实的写出来。
目标已达成的情况下，要做归因，因为做了什么事提升了多少，总结成功经验。
目标未达成的情况下，也要归因，定位问题环节，总结失败经验，并制定好二期优化方案。
顺便把各项数据指标的提升提炼成一段简介的概述，大家写总结的时候也用得上。
不要担心犯错，及时纠正也是能力的体现。
Author：yechaoa
4.4、风险把控
纵横全局的风险把控策略。
4.4.1、延期风险
怎么保证项目不延期？
首先，多人多团队的情况下，项目整体的进度其实是不好把控的，一方面是大家都有自己的主线事情要做，而且在大厂，琐事也比较多，难免会耽误开发进度，另一方面是大家也会有一些私事要处理，所以在排期上就要预留一些buffer空间出来。
其次，整一个表格出来，明确各项事情的时间节点，加强大家的时间概念。
最后，如果有多个上下游依赖、接口依赖的情况，也有必要搞一个站会，每天拉大家快速过一下进度和遗留问题，也避免某一个节点的卡壳导致整个项目的进度延误，有PMO最好，没有就自己担了。
记得定期把项目的进度同步给各个业务方和领导。
4.4.2、技术风险
假设项目上线出问题了怎么办？
对内：
- 要有快速降级止血的方案，比如预留开关或者代码回滚。
- 要有全链路日志供排查解决问题，在方案设计的时候要考虑清除需要在哪加开关、加埋点，这些都要明确的列出来。
- 为预防大面积问题，都会先灰度，这也需要提前搭好监控大盘，以及告警配置。我个人一般还会单独写一个排障指南，会列一下常见的问题以及解决方案和操作指南、以及错误码表示什么意思等。
对外：
- 提前联系好客满团队进行布防，第一时间把问题流转到技术团队，避免问题升级。
- 提前联系好运营团队，必要时需要触达告知用户如何自己解决问题。
5、总结
技术专项的落地，不仅是技术实力的体现，也是管理能力的试金石，有机会还是建议争取并把握好露脸的机会。
本文涵盖了技术专项落地的全流程，提供了一份从"知道"到"做到"的路线图，希望对你有帮助。
6、常见问题
其他同事不配合怎么办？
不配合的本质是因为你无法决定他的绩效，所以得从能影响他的绩效因素方面下手：
- 上升：通过他的领导，拉会拉群都带上他领导；
- 合作共赢：跟他讲价值，让他觉得这事大有可为，是可以成为绩效的亮点；
- 利他就是利己：平时在这种事情上也积极配合其他同事些；