我通过两人团队 + AI完成了整个项目交付周期，可是我却不想再来一次。

背景

我们尝试在AI的协助下缩小团队的规模。针对这次项目投入了两个人人力。一个后端开发，一个前端开发。

后端开发兼职产品、前后端开发、测试、项目负责人。前端兼职前后端、开发、测试。

这艘小船就这样向着目标出发了。

总体感受

我承认这会是将来的主流工作模式，而且无比坚信。但是现在我不想再来一次了。原因总结以下几点：

• 
  

  AI可以帮你做工作，却无法让你拥有专业能力：让AI画原型，AI一会就完成。但是他无法在和客户直沟通提取用户的需求。
  
  更无法确认最终原型是否满足。这是产品经理的专业能力，AI无法让你瞬间拥有这些能力。短时间内单个人效的提高是用流程环节专业能力降低、最终交付结果质量降低换来的。
  
  这种置换是我们能接受的吗？

  
  


• 
  

  职位边界模糊，但职位的工作量没有减少：上面的专业能力通过学习可以弥补，接下来面对的是一个人的工作精力问题。
  
  产品不只是画原型，产品是一个头尾贯彻的职位，在开发，测试，甚至上线环节都要处理事情。处理不合理需求的改动、需求方遗漏的功能补充、优化。
  
  开发也不只是开发代码，测试环节需要改代码，下一版本功能计划，上线问题解决。
  
  测试团队最晚介入工作，但是负责对产品最终的把关。重要性更是不言而喻。
  
  如果你恰巧还是项目负责人，那么你还要对最终质量，项目进度进行把控、上面所有环节进行把控。

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  阶段	产品沟通	代码开发	测试及bug修复	项目上线
  项目负责人	√	√	√	√
  产品	√	√	√	√
  开发		√	√	√
  测试			√	√

  
  

  上面的表格可以清楚看到每个角色参与的开发周期，也就是说岗位职责越往后工作内容是越多的。如果多个环节集中在一个人，导致原本分散在多人身上的时间、工作冲突，
  
  随着项目周期越深入，集中在一个人身上的工作责任就越多。有能同时承担这些的人吗？ 我肯定的回答有，但是工作状态高负载，不可能持续下去。最终的结局一定是压垮身体或者离职导致人才流失。

  
  


• 
  

  流程之间的互相检查能力变弱：需求评审、测试用例评审是一个容易让大家诟病的环节。以前总是吐糟需求评审问题太多，现在发现这是对产品质量的保证。评审多发现一个问题，后面就会少一个问题。
  
  节省出大量返工的时间。人多检查更细致，更全面。小团队覆盖范围小，返工的可能性更高。人力成本付出也就更多。有些东西失去了才觉得珍惜。我现在才发现产品的质量保证不在于产品原型多好、开发代码质量多高，测试多么细致精准。而是团队人员的一次次发现问题、讨论解决问题保证的。

  
  


• 
  

  时间悖论：节省了团队内信息同步，沟通的时间。却增加了返工风险带来的时间成本，甚至是产品质量问题（我认为这是底线，无法保证质量所有改动都是扯淡）。
  
  后续消耗更多的时间弥补。这算是节省时间吗？

  
  


• 
  

  项目周期抗风险性降低，韧性大大降低：相对于上面而言，这是我最看重的问题。我始终认为团体肯定是大于个人，而且也是有韧性的。一个环节或者人出问题，有另外人补充。团队人员越少，无人补充，就会放大影响。一共就两个人，我能一个人干两个人的活吧。
  
  下面是在相同开发周期下，大团队和小团队对突发情况的适应能力：

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  意外情况	请假	方向错误	加需求	问题解决	开发内容	沟通成本	上游环节验证
  团队	√	√	√	√	√		√
  两人						√

  
  

那么问题来了，面对上面如此多的问题，为什么之前我还是坚定不移的相信这是未来的主流。原因很简单，人是一定具备思考、抽象、构建、创造能力于一体的生物 —— 而且很会解决问题。

大多数人都能够选择出当前最好的选择。那既然都能选择出最好的，为什么最终的结果却是有好有坏呢。很简单 —— 就是做选择时大家掌握的信息是不一样的。

AI也一样，它最终的输出结果的好坏，也与人们输入的内容有关。那么我们怎么保证每次我们给AI的输入内容是最好的呢。请注意一个关键词 —— 每次。

只要是人，多次做一件事情也会存在偏差。所以说想要解决每一次就要通过系统解决或者工作流。

我们做系统是在干什么呢，不就是把一些繁琐、容易出错、消耗人力的工作抽象成一个系统化、流程化的逻辑，然后构建出一个系统吗？

只不过现在这些繁琐、容易出错、消耗人力的变成了我们的工作内容而已。比如画产品原型、写代码、写测试用例等等。我们要对这些进行思考，进行逻辑抽象，然后构建出一个与之匹配的工作流。

借助AI的超强的生成能力，逐步解放人力。有一点就是我们规定好了输入输出的格式，那么程序就会按照格式输出。帮我们解决了上面提到的每次的问题。

听说阿里已经有这样的工作流了，可惜一直没有时间研究，但是我相信在未来，这个工作也会越来越多。会逐渐地进入到大多数人开发者的视野，甚至不是开发者的视野，让大家使用能够构建自己的系统，自己的产品。

这样的话，复杂的沟通成本、各个流程之间的影响都会通过工作流标准的输入输出的问题得到缓解或者解决。只需要我们在一开始的输入中保证信息给全，让AI在这些信息中都可以选出当前最好的选择。

所以说，将来需要的不是会写代码的人吗，也不是如何将代码写好的。而是给AI说清楚，说全面信息的人。

以上说明的发展方向依靠思考、抽象、构建、创造能力。正是我们作为人的优势，也是发展的核心动力。这让我相信上面所述在未来会实现。

那我们等待工作流的出现不就好了，就先之前有java我用java，有spring我用springai，有springboot我再用springboot —— 有什么我用什么不就行了。

那么又有老铁说了，我们只需要等待工作流的出现，到时候我们使用它就可以了。我们干嘛还要拼命啊。

我只能说，你错了。现在虽然不支持团队很少人承担全部工作。但是却允许团队中出现少数的摇摆人。

摇摆人：可以负责两个及两个以上岗位职责的人。虽然团队并不能减少到极端的人数，但是团队中出现几个这样的人还是可以的。

而且，你如果想成为上面那种工作流的老手，这一个环节是不可避免的。

因为你想要构建和使用工作流的前提就是你必须要熟悉各个环节要做的事情以及交付的标准。

所以说，当下依然有我们能做的事情，而且是通往最终目的的必经途径。

总之，未来很遥远，但是我们却比大多数人更早的接触。是选择停滞不前，还是提前踏一步，选择尽在于你。