随着团队的人数的提高与成员的技术水平不断提高，同时业务的发展也对团队/个人提出了更高的要求，所以也要不断向技术方向进行努力探索，“动如一人” 是我们始终坚持的团队理念，个人能力强弱并不能决定整个团队的研发效率水平，只有大家都有了体系化的思考能力，才能让团队形成向上的技术氛围驱动力，促使每个成员都对开发技术有更高的追求。目前我们后台团队采用的是java技术栈，技术虽然稳定，但是使用的中间件工具始终在更新迭代，越来越多新的特性，新的使用姿势都是后台开团队需要作出完整的规划去适应与挖掘。
综上所述，为业务提供更好、更快的发展支撑、促使形成良好的团队技术氛围、技术发展的趋势都是驱使我们需做好技术规划的重要原因。
首先，我们先理解下什么是规划？
规划，意思就是个人或组织制定的比较全面长远的发展计划，是对未来整体性、长期性、基本性问题的思考和考量，设计未来整套行动的方案。
基于规划的三个特性我们可以将其与技术相关联，那我们需要考虑哪些方面呢？
**整体性：技术规划一定是对现有系统有体系化的思考，得出一个全面整体的改进方案，不在停留在某些具体优化点之上；**比如现在我们这边的后台都是领域服务为主，每个领域服务需要单独进行流量/授权的管控，我们就在想能不能接入统一网关，对流量、授权等管控，这就需要进行架构、领域、系统之间的总体考虑；
**长期性：技术规划一般周期都在在季度、半年度甚至年度，这就意味着这件事情是比较长期稳定的，需要持续推进的；**某些方向或者方案确定下来，就需要进行长时间的“运营”，比如引入一个新的中间件工具，就要遵从从可行性分析->使用->优化改进，需要像“版本迭代”的概念。
**方向性：技术规划需要针对某个方向，提出一个较为长远的目标，设计全面的发展计划和行动方案；**技术方向往往是多样的，如研发效率，后台架构性能等多个方向，这里需要我们进行优先级的划分，比如下一阶段需要承载大流量，那我们就把架构性能优先级调高。
团队中有新有老，成员的开发水平参差不齐，而且每个人对研发的整体架构与流程的理解也不一样。所以在做技术规划前，我们需要让大家都对目前的后台的研发架构与体系规范有较好的理解。以我们团队的后台业务架构为例，当前业务的主要应用场景是在校园/企事业的素质教育、组织宣传、家庭共享等，具体的业务架构如下图所示。
目前按照技术研发的三个阶段”开发、编译&部署、线上运行“，我们梳理了每个阶段涉及到的技术组件/工具，在开发阶段分为组件/中间件/业务工具/代码&文档规范/协作等技术点，形成技术全景图，方便大家对后台技术栈有个清晰的认识。
根据我们现有的支撑业务、部门职责、部门的资源等实际情况，可分为业务支撑/系统架构性能/技术氛围建设/研发质量/技术规范/研发效等六大技术方向。其中每个技术方向应该考虑一些情况：
业务支撑方向：业务支撑始终是作为技术规划的重中之中，一切都是都是为了给业务提供更好、更快、更高效的后台服务，这个方向需要考虑到产品规划支撑(新业务/新产品线需要的技术要求)、第三方的项目对接(数据对接/项目管理)、 整研发流程优化;
系统架构性能方向：服务可用性（SLA指标）服务并发性能（QPS/TPS) 可伸缩性（考虑扩容方案）安全性（安全架构/数据保护/审计）开放能力（开放接口/领域能力）运维能力（问题排查/FAQ场景支持)等;
研发效率方向：这里主要是大家写少些重复代码，能共用的部分提取出来，将重复编写代码的时间用在框架的理解上；关注业务工具优化、CBB共用组件建设、新工具/框架/语言等方面;
研发质量方向: 质量是产品的生命，主要考虑单元测试覆盖率，自动化测试工具，如何提升测试效率，压力测试等方面；
技术规范: 主要是为了提高整个团队的，从开发、文档、运维等过程中提炼出一套标准的行为准则，类似于“阿里开发手册”，这个在我们团队是很看重的，既避免了重复踩坑，又能进行团队的技术积累，并进行最佳实践，一举多得;
技术氛围建设: 主要是让大家共建一个学习成长的技术氛围，让成员对技术、效率、质量有更高的追求。
3.2.1 目标来源
技术规划目标的来源主要由产品规划、业界对标等等，比如产品规划里面的下半年需要拉新50w，日活要100w+，qps要达到3000+，设备日活要达到6w+，瞬间峰值要支持10w+QPS等等性能指标，还比如需要支撑新的业务场景，如拓展其他行业的业务场景就考虑是否需要组织架构基础信息的中台建设。目前做业界对标是比较难的，特别是我们做2B业务的，主要是考虑到产品与业务形态差异性非常大，单纯地对比指标其实是没有多大意义。
3.2.2 目标设定
技术目标的设定需要满足SMART原则，即是具体的（Specific）可衡量的（Measurable）可以达到的（Attainable）必须和其他目标具有相关性（Relevant）有明确的截止期限（Time-based）。举一个栗子：例如制定了一个“提高系统的可用性”目标，显而易见这个目标是完全不符合标准的，可以改成这样，“H2(下半年)-Q3(第三季度)-7(月份) 设备领域服务xxxx接口可用性要达到99.9%以上 （目前是99.5%)”
将每个大的目标拆分为小的目标，有助于分析目标的合理性，目标分解的越具体，目标的可达成率越高。目标分解后可作为每月的技术规划目标放入个人/团队的目标管理中，有目标就有输出物， 最小输出物粒度应该是可运行的系统或具有结构的文档。
这是跟目标紧密相关的，每个关键行动都是为了围绕实现技术目标而展开的，其中的关键行动也以个人的周/日工作计划相关。关键行动同样强调输出总结，应把握好节奏。
我们围绕目标/目标分解/关键行动/责任人等使用了简单文档进行管理，如下表所示，其中的的事项是以提升系统架构性能的方向作为一个例子。
规划方向
目标
目标分解
关键行动
状态
责任人
系统架构性能
H2-Q3(下半年Q3季度目标): 提高xx领域服务的QPS到xxx+
Q3-M7(7月份目标):xxx领域服务的a接口的QPS达到xxx+
Q3-M8:xxx领域服务的b接口的QPS达到xxx+
Q3-M7-W1(7月份第一周):搭建压测环境，进行压测;
Q3-M7-W2:根据压测结果调优，将a接口的qps优化到xxx
@xxxx
要想行动一致，落地有力，达成全员共识是非常重要的事情。技术规划从第一版到最终确定行动，起码需要两周的时间，期间我们会去召开多次讨论或会议，并结合商务、产品、项目管理、前端、硬件等不同的协作方的建议与想法，对每一个方向的每一个目标进行反复斟酌。最后有个“收尾”仪式，像启动项目一样，让大家都明白这个规划的重要性。
我们后台成立了差不多三年，技术规划已经做了两年了，但是实际落地效果还算不错，总结出来是需要有一套强有力的检查机制，通常情况下我们会指定了两位团队成员作为技术规划落地的“监督员”， 详细检查机制如下：
1.每周周六监督员会在群里发出进度截图与链接，并@到每个人。
2.每个月14号，29号监督员会在群里发出进度截图与链接，并@到每个人。
3.每个月15号，30号监督员会召开约会议室进行总结，并@到每个人参加。
本篇主要是对近期在团队中做技术规划的过程总结，阐述了团队的技术规划的重要性，针对技术规划中的方向、目标、目标分解、关键行动，以及规划落地过程中的注意事项、检查机制等问题，向大家展示了我们的一些实践经验，希望大家能在技术规划中带来一定的启发。
作者：代码的色彩
链接：https://juejin.cn/post/6844904201160491016
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
