我明白你说的从企业的角度来看,甚至从强调速度,但是如果你的人一个新的开发人员第一年,你还在大学或某种类型的培训项目的学习代码,他们需要知道low-code没有代码,和我们认为它会如何影响他们做的工作,寻找明年或明年甚至五年从现在做什么?
杰弗里•哈蒙德:我认为它将要做的一件事是我们之前的一项预测 ， 它可能会改变我们组织软件开发团队的方式 。
在典型的IT企业中 ， 所有的开发人员都在IT组织中 ， 他们会去找CIO ， 他们可能会从业务部门获得需求 ， 或者每隔几周就会去找业务赞助者 ， 但这是一个非常孤立的组织 。
正如我们所看到的 ， 越来越多的组织大规模地采用了敏捷 ， 他们开始将产品负责人放到这些团队中 ， 这些产品负责人可能来自业务部门 ， 但他们在技术上仍然是自组织的 。
当您开始看到越来越多的业务开发人员通过低代码参与开发时 ， 我认为您可能会看到更多的混合团队 ， 在这些团队中 ， 开发人员可以通过矩阵管理嵌入到业务组织中 ， 甚至可以与这些组织联合或分配到这些组织中 。
想象一下这样一个世界 ， 不是业务用户给你一个草图 ， 或者一个需求文档 ， 作为一个开发人员 ， 你必须解释它 。想象一下 ， 一个开发人员可能正在做一些线框图 ， 或者一个业务用户正在做一些UI 。
因为我倾向于发现 ， 企业真正关心的是像素 ， 他们关心这些像素是如何工作的 ， 他们关心这些像素是如何流动的 。他们不关心api是如何构造的 。他们不关心Kubernetes集群是如何建立起来的 。他们不关心函数是如何自动伸缩的 ， 他们只关心它是否有效 。
所以我认为作为一个专业的开发人员,这意味着的一件事就是,我们也许开始关注的技术品质系统一点,我们得到一点帮助业务的功能和价值,我们必须提供,甚至一些比较或线框图我们不得不解释过去 。
你甚至可以看到,从少low-code世界,当我们开始看到越来越多的组织讨论设计系统,在那里他们表达系统如何应该和行动,还有小一点的工作负载从发展的角度对我们的前端 。
所以它会完全说 ， “不需要前端开发人员” ， 绝对不会 。英雄 ， 移动应用程序 ， 面向客户的应用程序 ， 你仍然需要关注细节并在那里寻找启示 。但也许对于一些面对应用程序的员工 ， 我们可以用这些混合团队做更多的前端工作 。明白了吗?
3.跨职能团队将成为规范 ， 需要新的管理方法和工具比尔:是的 ， 是的 。这是报告中另一个预测 ， 也就是跨职能团队 ， 协作工作管理 。请更详细地谈谈这个预测 。
我和应用开发组织的人交谈过 ， 他们描述的是同样的事情 。在我20年的科技生涯中 ， 我个人就像钟摆一样来回摆动 。
所以说一下这个 ， 它似乎就像你说的 ， 回到“嘿 ， 我们要嵌入开发者 。我们将使他们更接近最终用户 ， 而不是这些独立的IT组织的一部分 。
但对有些人来说 ， 这不是一个容易的转变 ， 对吧?它需要一些不同的技能 。我的意思是 ， 我记得在学校和工程学校上学的时候 ， 那更多的是 ， “好吧 ， 你是一个工程师 ， 你要去工作 ， 然后……”
那时我的专业是工程数学和计算机科学 。那就是 ， “你要自己工作 。你不会有一个真正的大团队 。也许你会从其他组得到一些信息 ， 但它会是你 ， 它会……”这就是- - - - - -
杰弗里?哈蒙德:把他们放在办公室里 ， 给他一罐可乐 ， 然后把披萨塞到门缝下面 。这就是你所需要的 ， 对吗?
比尔·戴特韦勒:就是这样 。但那是完全的 ， 完全的…这是不同的 。但仅仅五年之后 ， 情况就不一样了 。教授们在这里来来回回地推来推去 。我在和自己约会……60年代 ， 70年代和80年代 ， 仍然有这样的心态 ， 80年代出现的一些新人 ， 现在我们到了90年代 。
所以说第一点 ， 对跨职能团队的预测 ， 开发人员应该真正考虑的是如何进行过渡 ， 开发应用程序开发负责人 ， 以及他们如何确保员工成功过渡?
推荐阅读
- 运维人员常用的 Linux 命令汇总
- 雨水过大淹没车门车主应该 车被水淹了怎么处理
- 办公人员喝什么茶最好,夏天喝什么茶叶最好
- 柴犬的价格应该是估计 柴犬价格为什么这么贵
- 打了小孩应该注意什么
- 阴阳师阎魔的御魂应该如何选择
- 天冷了是不是不应该遛狗 冬天遛狗最佳时间
- python 目录结构的规划，应该先建立好
- 做数据分析应该掌握的5个SQL数据清洗方法
- Java开发人员必知的常用类库，这些你都知道吗？