倒置

软件团队过去将大部分时间花在执行上: : 介于基础和审查之间。随着中间部分被强大的人工智能所吸收,人类的影响力转移到末端:上游的标准更加清晰,下游的判断更加密集。这在结构上是积极的,但对于那些手艺处于中间的人来说,在情感上却很难。

人类的倒置
倒置

在软件开发的大部分历史中,人类大部分时间都在中间度过。

将过程分为三个部分:

  1. 基础:任何功能之前的市场研究、定位和角色定义;控制界面构建方式的设计系统和约束;架构标准和编码约定塑造了工程甚至可以考虑的内容。
  2. 执行:将这些基础变成实际的工件:规格变成设计,设计变成代码,代码变成交付的软件。
  3. 回顾:打磨、测试、确保生产出来的产品真正符合标准、真正适合使用它的人的艰苦工作——而且最重要的是,学习可以更新你的先验知识,为下次打下基础。

团队围绕中间组织。产品人员编写规格。设计师将规格作为设计来实现。工程师将设计实现为代码。即使是精益方法论,明确地试图将瀑布折叠成更具协作性和跨学科的东西,仍然无法将大多数人从中间空间中拉出来。

交接是承重的。协调是承重的。顺序依赖是承载的。设计师可以在产品规格最终确定之前进行一些探索性工作,工程师可以在设计锁定之前进行一些研究,但实际的工件(已发货的工件)需要前一学科的输出基本完成,然后下一学科才能做好工作。

这对双方都有影响:

**基金会得到了剩下的一切。**市场研究是在编写规范的实际工作之间的边缘完成的。设计系统是被动构建的,是在事后根据屏幕上出现的模式整合在一起的。编码标准存在于维基百科中,没有人阅读,架构决策也以部落知识的形式积累起来,因为没有人有时间把它们写下来。基金会是杠杆存在的地方,但执行力吞噬了日历,所以基金会得到了幸存的所有关注。

审查的待遇更差。 如果你幸运的话,QA 是冲刺结束时的一个阶段,如果你运气不好,QA 就是某人积压工作中的一张票。设计评审是一个 Slack 线程。代码审查是一种针对吞吐量进行优化的仪式,而不是为了捕捉真正重要的事情。将软件与令人愉悦的软件区分开来的细节在时间线的最后 10% 中得到了处理,这正是每个人最累、交付压力最大的时候。

这不是团队做出的选择。这是经济强加的均衡。当执行成本高昂时,你就必须安排执行人员,这意味着基础和审查将获得剩余的时间和注意力。瀑布和精益最终并不是次优的,因为团队选择忽略它们。他们的流动性受到限制。

然后人工智能改变了经济。

中间部分——文物的实际生产——是人工智能和强大的安全带现在真正发挥作用的地方。您不需要产品人员编写规范,不需要设计师将规范转化为设计,也不需要工程师将设计转化为代码,每次交接都需要花费数天的同步会议和上下文翻译。你需要一个知道什么应该存在的人以及一个可以产生它的模型。

执行成本崩溃了。虽然不是一直为零,也不是在每个领域都一致,但足以使人类工作发生的重心发生移动。

基础设施随着经济的发展而变化。临时模型是人在环:每个执行步骤的中心都有一个人,触发每个动作,检查每个输出,保持节奏。正在出现的是代理循环:运行代理的服务器连续异步工作,由人类设定方向并审查结果,而不是驱动每一步。人机交互将人们置于中间。循环代理就是在系统级别吸收中间部分。

人类现在已经走到了尽头

在基础方面:

  • 产品可以把时间花在产品工作本来应该做的事情上:深入的市场研究、认真的定位、经过验证的人物角色、仔细思考哪些保证和利益重要以及为什么重要。不是编写规范,然后转化为设计,再转化为代码。
  • 设计可以将时间花在设计系统、约束和跨领域决策上,这些决策决定了未来一百个屏幕是否会协调一致。不是将 Figma 中的像素交给工程师。
  • 工程人员可以花时间研究架构标准、确定哪些类别的错误是可能的以及在结构上排除哪些错误的原则、以及多年来将复杂化的平台决策。不是将票证转换为拉取请求。

在审查方面,每个学科都可以花更多的时间来解决始终重要但很少得到仔细回答的问题:

  • 这实际上解决了用户的问题,还是解决了模型错误推断的问题?
  • 这是否真的适合设计系统,还是一次性的会造成不一致?
  • 这段代码是否真的尊重架构约束,或者它是一个复合的快捷方式?

各个表面的审查负载不均匀。对于大多数代码,彻底的审查可以提高质量。在失败是灾难性的领域——加密基础设施中的桥梁代码、临床决策支持、航空航天控制、支付轨道——审查端成为管道中限制速率的三分之一,承载着大部分质量负载。该架构仍然适用;体重发生变化。

这是相反的:**人类在末端,人工智能在中间。**现在,末端是杠杆差异化的地方,因为执行的“成本”正在成为赌注,尽管其“质量”仍然决定着审查端的工作有多努力。以前我们只是无力承担适当的人员配备,因为执行力吞噬了所有人。

这样说来,这种倒挂听起来像是纯粹的上行趋势。更多的时间用于基础,更多的时间用于审查,更少的交接摩擦,更少的协调税。它是有好处的——巨大的好处,是软件团队这一代人所见过的最大的生产力转变。

从内部来看过渡感觉如何

该架构是净积极的。穿越它的经历并不总是如此,任何对反转的诚实描述都必须说明处于其中心的专家实际上发生了什么。

那些以执行技巧为特征的人——那些以编写良好的代码、制作干净的设计、起草严格的规范而闻名的人——正在看着他们被雇佣的目的被吸引。这些技能并没有变得毫无价值。判断力、品味、领域知识、系统直觉、简单性便宜和昂贵的本能——这些都还没有自动化,而且大部分都不会很快实现。

但让他们进入房间的“认证”技能正在萎缩。剩下的东西在短期内对市场来说更难定价,因为市场还没有发展出独立于它过去所依附的执行而对其进行估值的词汇。

这会以特定的方式表现出来。人工智能团队中的职业中期工程师越来越多地询问他们是否应该转向产品管理——不是因为 PM 工作是他们的热情,而是因为 PM 是一个由判断和沟通定义的角色,而判断和沟通是不会萎缩的技能。移动的方向通常是正确的。它在对话中的表现形式是——“我的工作已经无关紧要了,所以我可以变成一名产品经理吗?” ——是对难以辨认的转变的理性反应,而不是对新角色的纯粹热情。

相反的困惑也同样常见:人们倾向于人工智能刚刚变得容易获得的技能,而不是它变得稀缺的技能。

这种倒置并没有使有这种感觉的专家无效。如果有的话,这取决于他们——基础和审查是新架构的杠杆点,两者都完全基于执行时代专家花费十五年积累的判断和品味。

所需要的是改变这种判断的方式,无论是对专家本身还是对试图评估它们的组织来说。市场还没有良好的词汇来评估独立于过去与执行捆绑在一起的判断力。通过标题、通过新的评估标准、通过诚实地讨论现在的角色实际上是什么,建立词汇表是过渡如何停止感觉像损失并开始感觉像杠杆的一部分。

首先执行自动化。判断则不然。本系列的大部分内容是关于一旦执行不成功,如何正确地安排人员和组织判断。

旧组织没有的问题

当执行处于中间位置并且人类在学科之间传递工件时,协调是通过工件本身进行的。该规范迫使产品经理和设计师保持一致,因为设计师必须阅读它。设计审查迫使设计师和工程师保持一致,因为工程师必须根据设计审查进行构建。中间是跨学科背景传播的地方,因为翻译是在人类实际一起生产东西时实时发生的。它缓慢而令人沮丧,并且充满了交接浪费,但它做得很好:它使学科与彼此的现实保持联系。

把中间的部分去掉,接触就随之消失了。

在最后工作的专家不会自动理解彼此的工作:

  • PM 的定位文档对于工程师来说难以辨认。
  • 设计者的约束文件对 PM 来说难以辨认。
  • 建筑标准对于设计师来说难以理解。

每个学科都会产生基础工件,在旧模型中,这些工件永远不需要交叉可读,因为中间的人正在实时进行翻译。现在中间已经没有人了。中间有人工智能,它非常擅长生产工件,但并不能从本质上解决过去通过会议和交接解决的跨学科紧张关系。

因此,本系列的其余部分必须回答的问题是:异步并行专家工作如何实际运行而不陷入不连贯?哪一层取代了中间所承担的协调作用?谁创作了共享上下文,以及它如何随着时间的推移保持可信度?

索赔

这是我将在接下来的三篇文章中提出的答案,坦率地说,以便可以测试:

不围绕倒置进行重组的团队在十八个月内看起来会变得更加糟糕,并且大多数团队不会重组 - 不是因为技术转变很难,而是因为文化转变比任何人目前所意识到的更难。

文化转变需要大多数组织感到真正不舒服的东西:

  • 高管们撰写的业务准则历来故意保持模糊。
  • 专家通过品味和判断而不是执行技巧来寻找自己的专业身份。
  • 放弃目前作为团队协调可见证据的会议,并信任没有人拥有多年经验的异步机制。
  • 招聘的触发方式与许多投资者和操作手册目前认可的触发方式不同。

这一切都不是不可能的。其中一些已经发生。但首先解决这个问题的团队将获得复合优势,而延迟的团队则无法轻易关闭,因为复合发生在基础层和审查层——这些层总是被认为是最重要的,而大多数团队永远无法正确配备人员。

能够很好地驾驭这一过程的团队也将承认这种转变对于处于其中心的专家来说是多么不舒服,而不是假装这种不适不是系统的一部分。对组织有利的转变不会自动让处于组织中间的人感觉良好,而将这种差距视为态度的失败而不是结构特征,这就是原本正确的架构失去其最需要的人员的原因。

下一篇文章是关于招聘触发因素的。您什么时候真正将人员添加到由人工智能处理执行的团队中?答案并不是当前初创企业智慧所暗示的那样,而犯错是这一转变中最昂贵的错误。

9 最小阅读量AI
分享