技术团队如何做技术规划
3W法则(也叫黄金圈法则)：为什么要做？怎么做？做成什么样？
每个团队都应该有短期、中期、长期的规划，有计划的做事情才不会迷失方向。
如何才能做好技术规划呢？我们需要先沉淀一套方法论作为指导，基于方法论深入的思考得出最终的目标和方向。
分治法
我们需要学会把复杂的问题拆解成每个细小的问题，参考阿里大牛的方法论，把技术规划拆解成图1中的4个层次来看：
当前问题
每个团队在不同的阶段都会遇到不同的问题，有紧急的、有不紧急的。找出痛点，坑点，比如已经严重影响研发效率的一定是需要立马解决的，而且可以快速解决的，经常表现有：
1)代码混乱规范不清晰，每个人一个代码风格，代码质量差，团队协作会很受影响，必须立马解决；
2)线上频繁出现一些小问题，很多都是大意或者太过于自信导致的，这时候必须要借助一套代码审查机制，还有自动化机制了，小问题积累多了迟早会成为大问题。
3)业务跑的太快，当前的架构已经严重无法满足业务发展的速度，比如写活动的同学，如果没有一套无代码平台，会被运营无穷无尽的活动给拖死，每天不眠不休都不一定做的完；
技术领域
这是一个长期沉淀并且不断演进的过程，每个技术团队都应该有自己的一套提升研发效率，保证生产环境稳定性的基础设施，需要能够长期满足业务和团队发展的的需要，好的基础设施一定是能够解决研发效率的同时，又能满足业务的拓宽。比如基础的脚手架、性能监控、自动化测试等等，这些都属于工程化，抽象思维的范畴。
业务领域
这个需要不断和业务方碰撞，特别是制定目标的时候，要真正了解业务方诉求是什么，需要技术未来如何做支撑，我的做法就是和同级或者同级的上级去多做沟通，技术和业务的目标是一致的，任何技术规划都是为了解决业务的完美落地而做的，脱离业务的技术架构就是耍流氓，需要根据业务的特点去做规划，提前做好布局，先做好支撑，然后做赋能。
团队的特色
这个是最难的一个，很多团队能够很好的做好业务的支撑和赋能，但是如何才能把团队的影响力拓宽到公司，甚至整个行业，目前很多团队都是空白的，这就非常考验团队管理者的格局和远见了。
SMART原则
通过分治法先将问题的复杂度降低，然后根据每个层次得出未来的目标和规划，这个需要尊从SMART原则来制定：
S：Specific，指标一定是具体明确的；
M：Measurable，指标一定是可衡量的；
A：Attainable， 指标一定是可达成的；
R：Relevant，指标和目标是有相关性的；
T：Time bound，一定要有明确的截止期限；
我们的目的是：变得更好。
于是乎：“为什么我们就不能使用现在的架构？现在的架构不是挺好的吗？？”
为此，我们只需要尝试回答这么几个问题：项目的编译速度快吗？编写新功能的速度快吗？能满足快速上线的需求吗？多个团队并行开发，会出现问题吗？我们依赖的第三方组件，会出现问题吗？……
嗯，对这个问题就好像，别人在问你，“你有什么不足？”。
怎样做技术规划
从这篇文章的写作过程，及笔者的相应规划步骤来看，可以分为这么几步：
调研技术远景
从社区获得相应的输入
整理潜在的技术方案、架构、技术栈
从利益相关者获得想法
制定相关的实施计划
规划，它类似于技术远景的味道。可一谈到远景，那么要谈论的东西可多了。说不到我们还需要寻找利益相关者——如团队成员、项目领导，了解一下，他/她对于技术团队的一些期望。我们在社区上看到相似的问题，总有一个相似的开头：“我们的领导……。”
谈理想都特别有意思，因为我们不一定会去做。我们有了一个宏大的想法，只是受限于多个因素，我们只能做这么一点。比如说，我们未来想造一个笔记本，那么现在我们可以只选一个螺丝钉。
而在我们获取更进一步方向的时候，需要从这么几个维度来考虑问题：
从业务现状出发。
譬如，在下一年里，我们的团队将从 20 人扩大到 100 人，为了支撑这么大的团队。我们需要拥有培训机制，来应对这样的人员扩张；需要设计一个更好的架构，来实现多个团队的并行开发。
从技术、架构出发。在项目中引入新的技术，改进原有的技术方案。
架构的预研。
提前试用未来可能使用的技术，如 AR、VR。这些往往是一些非必需的规划，但是有了它们会更好。
团队能力规则。谈论到团队规划，我怕是并不是那么擅长。大抵上，哪怕是技术负责人也不是 KPI 的制定者，我们只能谈谈理想，聊聊团队建设的一些建议。有针对性地培养项目的 2nd Tier，至少对方是否能接受，那便不在我们的控制之下。这大抵也是个人发展的好处，可以选择自己感兴趣的内容学习。
当然了，其它相当多的东西，还是要落地的——我们还是得造螺丝钉。只有落地的东西，才能证明它是真正有价值的东西。为此我们要用 SMART 原则制定一个 smart 目标。当然了，如果你还要对领导汇报，请不到忘了你的时间节点。
总之，保持现在，探索扩展，尝试未来。
演进式架构。
是不是我们规划每件的事，都值得去做？是不是我们只做规划的事情？未来是一直在发生变化的。而规划，只针对我们知道的内容提出的。它无法用于我们不知道的领域。它也无法应对未知的事务，如产生了一个新的技术，它提高了三倍的生产力。那么，先前我们设计的一些规划，可能在此被新的技术替代掉了。
我们定好了一个大体的目标，核心的部分，只在真正实现的时候完善。为此，它需要具备一定的可演进式，也因此不会受过去的设计所限制。倘若基于这一点因素考虑，那便是容易得多了。只需要去寻找那些真正可能影响我们的趋势，套上一个模糊的概念，就可以这么轻装上阵。
可是呢，在做这件事情的时候，每个人心里都有了一个答案。事实上，你心底也已经有了一个答案，只是说呢，你不敢、不想直接说出自己的想法——一来，受限于能力；二来，怕做了错误的决定。
程序员如何做好技术规划：体系化的思考能力？
1 前言
随着程序员的经验、资历不断提升，不再满足于日常业务搬砖，也要朝技术创新方向不断努力。对低级别的技术同学来说也许点上面的优化就可以做的不错了，但对于高级别的同学，体系化的思考能力尤其重要，这就需要做好技术规划。
在大前端新框架层出不穷的年代，技术规划似乎约等于轮子大法，不管三七二十一，新出一个框架拿来就尝试一下，例如RN、Flutter这类框架，第一批吃螃蟹的总能获得不错的红利。要是再有追求的，直接另起炉灶自己实现一下，例如Weex就是RN的Vue语言版本，在阿里体系内也是混的风生水起。
但最近几年大前端的新技术趋于稳定，不再有那么多红利可吃，另外很多公司也严禁重复造轮子，作为业务开发的我们如何在日常繁重的业务开发中做好技术规划呢？
2 什么是技术规划
规划，意思就是个人或组织制定的比较全面长远的发展计划，是对未来整体性、长期性、基本性问题的思考和考量，设计未来整套行动的方案。规划是融合多要素、多人士看法的某一特定领域的发展愿景。
-百度百科
从百度百科的定义来看，技术规划相比于日常技术优化有几个特点：
整体性：技术规划一定是对现有系统有体系化的思考，得出一个全面整体的改进方案，不在停留在某些具体优化点之上
长期性：技术规划一般周期都在在季度、半年度甚至年度，这就意味着这件事情是比较长期稳定的，需要持续推进的
方向性：技术规划需要针对某个方向，提出一个较为长远的目标，设计全面的发展计划和行动方案
规划的意义就在于给到一个长远的目标，起到了灯塔的作用，也许一开始并不能马上就找准方向得到理想的结果，但是通过设立规划目标、阶段性的里程碑，不断做有积累的事情，最终就能够得到理想的结果。
3 怎么做技术规划
前期准备
业务分析
技术不是空中楼阁，一定是服务于业务场景，这个需要技术同学加深业务的理解。有句话提到加深业务理解总结下来就是：“站在业务方的视角，在理解业务发展目标、看清业务发展方向的前提下，做出技术和业务的平衡”。
所以技术规划首先要考虑的是业务价值，千万不要为了技术自嗨，为了规划而规划，一定要想想做这件事情最终给业务能带来什么？
业界对标
当你要解决一个问题的时候，要相信你不会是第一个遇到的，也许业界已经有很好的解决方案，所以技术规划时候需要前期做足准备，充分调研看看别人是如何解决的，是否适合你的场景，多比较多对标，再开始动手。
技术同学往往会有自己动手的冲动，往往觉得自己亲自造轮子解决才有成就感，其实如果你能采用成熟方案以最小代价解决问题，这个难道不是更有效吗？
设立目标
一般设立目标的时候遵循SMART(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound)原则，可以逐条对照目标原则看你的目标是否符合。
当然设立目标也需要考虑一些因素：
收益：目标一定是能够获得业务收益的，例如收入、效率、体验，不要设立一个无法明确收益的目标。
技术：从技术层面来看，分为三个层次：现有扩展或者深度挖掘，新方向探索，趋势判断。越往后面的层次约考验技术同学的技术判断能力，这个需要大量的积累。
团队：目标是否是现有团队人力可以承受的？技术能力上团队是否能够支撑？比如做一个移动操作系统可能就不是一个中小公司可以考虑的事情，或许只有华为、阿里这类大型公司才有可能落地实现。
一个技术规划设立目标的例子：
在xxx时间内达到：
xxx系统可用性99.99%
xxx系统线上故障
xxx系统响应时间90线
任务分解
在目标设立好之后，需要进行目标的拆解，形成一份可以执行的计划。在任务分解的过程中需要注意几点：
全景图
任务分解不是没有章法的，这个尤其考验技术leader的技术大局观，必须具备开阔的视野看到整个事情的全景图，才能够在宏观层面更好的进行拆解。
以美团点评金融平台 Web 前端技术体系为例(图片来源：https://tech.meituan.com/2018/03/16/front-end-web-architecture.html)：
我相信在做技术规划的时候，有这张技术全景图对于任务分解会起到非常大的帮助。规划要做的事情可以很容易按照分层图一层层拆分，或者按照不同框架系统进行拆分，同时也可以针对某层或者某个框架模块进行细分目标设定，使得目标更加精确容易衡量。
明确可执行
拆分出来的子任务需要明确可执行，子任务或者子目标也是要遵循SMART原则，同时拆分后更加贴近最终落地的结果，更加容易执行，未来也更容易进行衡量。
执行计划
任务分解后是制定执行计划，这个和做业务需求一样，要把一件事在分解拆细，评估工时，安排到人，进行项目排期。在执行计划上需要注意几点：
设定里程碑
对于一个长期的技术规划项目而言，经过任务拆解后可以能会分为几个子方向或者子项目并行开发，再加上周期漫长，如果要等到全部做完后再验证结果，这时候往往会产生非常大的偏差。里程碑的设立非常重要，一方面可以给到团队阶段性的胜利成果鼓励信心，另一方可以快速验证小步快走，避免出现重大的方向误差。
高风险项目
针对高风险项目，需要采取快速试错的方式，小步快走，前期要分阶段快速出成果。先做demo进行技术验证，再小范围尝试，最终再沉淀为应用。
计划设定
技术设定时候可以前紧后松，项目管理按照时间分阶段，月度计划可以细化到周或者天，长期计划可以细化到月。
任务拆分和估时的颗粒度也要适中，拆分出来的每一件事情都是可以测试验证效果的，但同时不宜太大(1~3天工作量最好)，这样可以提高工作量预估的准确性，而且将来计划调整也比较灵活。
风险评估
执行过程中需要不断评估风险，风险分为两类：技术风险和管理风险。
技术风险：前期需要评估技术可行性，结合团队技能和梯队情况，充分调研业界最佳实践，寻找到合适自己的技术方案，一定要记住不要被“颠覆性”的想法冲昏了头脑。
管理风险：团队人员配备是否充足，是否会因为业务波峰波谷导致技术需求无法持续，这个需要考验技术leader对于未来业务的判断，同时和业务团队充分沟通，针对技术需要留有一些固定比例人力，保证技术项目的长期性。
贯彻执行
执行过程中，项目到了一个里程碑，需要停下来进行总结复盘，看看当前的位置离目标是否越来越近，复盘过程中是否有改善的地方，同时按照当前的状态对计划进行调整和制定改进动作。规划就是为了更好地适应明天的变化。
4 总结
技术规划包括明确目标、任务分解、执行计划、风险评估、贯彻执行这5个环节，每个环节都需要技术leader们认真思考，技术规划不光是表面光鲜高大上的事情，更需要脚踏实的狠抓细节才能落地。最后，大家往往提到技术规划的时候脑中总是飘过各种高大上、酷炫屌炸天的技术，对于那些脏活苦活不屑一顾。但是我们需要仔细思考，回归到技术的本源，任何技术都是为业务服务的，如何选取合适的技术并且体现业务价值才是真正应该值得各位同学好好追寻探索。
