分析技术决策

0. 前言

作为一个工程师，经常会做的就是技术方面的决策和编码，所以今天喝点啤酒跟 AI 一起讨论下我们如何去做技术决策~看下 AI 和人的分析有哪些不一样，下面我们大概分 4 个题目进行分析，首先无脑跟 AI 提一个问题。

1. 为什么要做技术决策？

从自身角度上来说，我们的技术决策一定要与组织和业务发展相关，这是一个必须的前提。我们做技术决策主要还是为了以下几个方面（概念 AI 谈了一些，这里谈一下为什么？）

优化资源利用对于业务上最非人文主义的是 ROI，业务目标更多关注的是钱和人，只有当资源合理的使用了，ROI 才是最大的。所以很多时候我们的管理目标是会与“效率”相关，管理是违背人性的，但是管理的发起者是人，人就应该保持乔布斯所说的科技与人文的十字路口要做出正确的判断和引导方向；那么跟我们的技术决策关系是什么呢？就是我们的技术决策是要能直接或者间接影响资源使用率的问题，这样目标下的技术决策应该是比较好量化的。
保障业务和技术团队的可持续发展。这个如何理解呢？业务的心思是比较前端的，对于技术团队来说，自身的价值其实是一个挑战，如果只是在需求程度上去满足业务目标，那么反馈会是支持不错。我们的技术决策要在业务拿结果和实现目标的过程中起到影响。这里举一点实际方式：

(1) 一个工程师的技术决策有延续性，如果能满足业务目标的情况下，这样的技术决策是很良性的。因为具有延续性的决策是可沉淀的，在决策实施过程中会加上时间的系数，让我们的决策成果能够更好的在团队中沉淀下来，逐渐形成团队的技术基因或者说技术决策依据。那么我们思考第一个问题：如何做一些延续性的决策呢？。

(2) 一个工程师的技术决策有突破性，这样的决策一般会出现在资深的工程师上，有着不一样的技术直觉和技术积累。突破性的决策更多适用于开始和维护期业务、较新或者较成熟的团队（中间阶段团队其实不太合适）。突破性决策能够让团队焕然一新并且可以向更多维度的目标去前进或者说能够跟随环境发展趋势。第二问题：我们如何做一些突破性的决策呢？。

2. 技术决策有哪些依据？

跟随上面为什么得到了 2 个目标：

如何做延续性的技术决策？
如何做突破性的技术决策？

我们先看看 AI 对于我们题目的生硬回答（-,- 不行了吧，AI 宝宝）。其实自己也没有做到太多，以下更多是思考。

如何做延续性的技术决策？

首先技术决策要具备延续性有很多影响因素：

业务具有一定延续性，至少某一个业务子目标是较长期的；
技术决策人具有一定稳定性，每个人的想法不同，换个人的视角可能就变了（关注点和经历）；
技术决策最后能落地到抽象业务上，在相似 Context 下能满足业务发展；（Context 更好表达）；

所以在做延续性的技术决策的时候，需要首先看下多个业务目标是否可以抽象到一个 Context，最后能够拉长周期是统一的方向。这个时候就可以在实现类似业务目标的时候选择延续性偏重更多一些，能够帮助组织和业务做一些长且深的方向去做出成绩，即使业务失败了，那么我们因为技术延续性高，肯定会有一些可复用的零件可以使用。所以软件的可复用性与延续性是有一定关系的（暂无数据分析）。

另外就是延续性的技术决策落地是否好，一是决策人是否稳定，二是团队人员的技术经历和背景是否相似。更相似的技术背景会拥有更多的技术味觉和偏好，更容易在决策上达成一致并且说明原因。决策人要做的是完成技术架构调研和 DEMO 上，还要与成员一起探讨出为什么要做这个决策以及这个决策能带来什么，在管理初期自己犯得最多的错误就是这个目标是“你”的，而不是大家的，会议的意义之一就是要统一决策，所以在做决策的时候，一定要开一个“会”，这个会可能已经不是双向沟通了，是一个传达和一致，双向沟通更多是放在过程中。

这里回顾下做延续性技术决策方式：

抽象业务的能力，识别业务与技术的关系；
与团队相关人员开好一个一致决策会议；

如何做突破性的决策？

影响突破性决策能想到的因素：

组织的容错性；业务的容错性更多还是看组织；
技术决策人的性格，是否擅长做突破性决策，还是更多是保守型决策；
团队承受力，团队人员是否愿意去实施突破性带来的不确定性；

所以我们很多时候希望一个事情带来突破性的改变，其实是蛮难的，从上面写文章想到的一些因素来看，人的占比其实更高，突破与风险关系是一直在的。那么我们有哪些方式能够做呢？

做的前期应该做更多目标相关性的培训和了解，用于规避一些小的突破技术带来的风险。形式上可以是技术分享，也可以是小业务的低成本技术尝试等等；
招聘有成功案例的专家，用于方向的突破，用案例经验去填补不确定性；
不断学习和实践总结，时刻关注技术和行业的发展，要做决策的时候采集和调研范围一定要广，然后才是深。因为可能下一个技术方案更好，只是自己不知道。

这个要求太高了...先聊到这，但是根据经验作为突破性决策人，广度比深度更重要。深度应该是选了方向后再发力，也就是所谓的力要用到刀刃上以及我们的转弯成本控制。

3. 如何去衡量技术决策做得正确？

那么我们说了这么多做决策的事情，我们到底做得好不好需要一个判断，这个主要是来源于你得对决策负责，也要更加客观的评定。AI 这个回答比较广泛，我们有一些方面可以分析。

技术决策直接与业务目标挂钩，比如能够完成用户回流率 98%，以前是 80%，数字的背后其实就是技术的支持带来的影响，能解释这个影响的关键在于前后对比；
技术决策直接与大组织目标挂钩，比较适合有独立职能型的组织，大组织的目标在与业务挂钩，形成一个间接的关系；比如赋能横向业务，提升相似业务效能 50% 等实际的指标；
技术决策与经营成本挂钩，主要适用于 IT 部、运维部、经营过程业务，有部分业务是只要在他就是成本，并且可能具有边际成本。这个可以设置一些与钱更相关的指标；

这里可以看出，技术决策的衡量一定挂钩的 2 个因素：

业务完成情况，然后由业务与背后的数字做间接挂钩；
直接与钱挂钩，产出看得见摸得着的价值；

但是这个更多会存在于大一点的目标，拆解下来的更多小目标可以从以下方面来看：

负责业务所分到的业务数字目标；
所在团队的效能目标、横向支持业务完成目标；
技术负债与业务发展的一些关联数字；

从评定上转化成量化目标其实是不舒服的，但是他是客观的。

4. 有哪些常见的技术决策维度？

从上面分析，其实我们也需要一些技术决策的讨论或者分析维度。每个技术人的经历不一样，关注点可能不太相同，不能单方面去看决策是否好，而是在我们一个大的 Context 下去分析是否合适。AI 基本就是一些通用性回答了。

如果从架构师角度来看可以用以下一些维度去做：

是否真正能帮助解决业务问题（这里更多是识别业务问题的分析，之后文章再做一些方法介绍和分析，其实还是有一些方式可以去分析出问题的）；
技术架构是否符合当前业务和团队情况，如果要做这个决策，那么我们的目标是什么，怎么关联业务；
什么时候去做这个技术决策；
我们该如何去验证自己的技术决策（涉及一些验证软件设计）；

最后有一些通用职能的经验：

技术决策可以一起讨论，但是决定一定要独立做；
技术决策是否违背一些通用软件方法论，如果违背是否有风险；