Nursa 向每位员工提供 AI 开发工具：首批原型变成了实际产品

Nursa 帮助需要填补班次的医疗机构管理者与合格临床人员对接。创始人 Curtis Anderson 和 Lovable 营收负责人 Lauren Rhode 讨论了 Nursa 各部门人员都能开发软件后发生的事情，其中包括没有工程背景的员工。Lovable 是此次会议的创始合作伙伴。

Rhode 问在场有多少人不仅尝试过 Lovable，还将应用投入生产、连接数据并让其他人使用。她认为，“氛围编程”早期带来的兴奋，与交付能够支持业务的软件这项更困难的工作之间存在差距。

她并不想否定早期阶段：它揭示了非软件工程师开发和交付产品的需求。Rhode 说，Lovable 客户越来越希望将这些原型进一步投入生产。

Anderson 说，Nursa 最初主要用 AI 制作内容。他也把工具交给自己的孩子，观察他们如何使用。在工作中，公司留出时间和资源来测试这项技术能做什么。

大约六个月后，Nursa 的产品负责人 Nenad 在尝试 Lovable 的一项新功能并制作出一个新产品后给他打来电话。公司让 Nenad 探索一款独立产品和一条新业务线，而不是立即在现有工程流程中全面依赖这些工具。

目标用户是需要在医疗机构完成临床实习时长的护理学生。Nursa 曾考虑帮助他们对接这些机会，但没有认为这个想法迫在眉睫。Anderson 说，该产品后来成为公司扩张的一部分，15 个月前还不存在，如今已有数千名学生用户。

在这次经历之后，Nursa 向所有人开放了 Lovable。Anderson 说，这个约有 160 人的组织中，每位员工后来都开发过东西，产生了数千个项目。他认为，对于不熟悉代码的人来说，这个工具提供了一个容易上手的实验空间。

Rhode 描述了两种采用方式：管理层可以将工具交给所有知识工作者，也可以由团队从个人问题出发，再将成果向上反馈。她说，无论哪一种，组织都需要可见性和治理机制，以识别最好的想法并为投入生产做好准备。

在 Lovable，一位客户经理创建了 Catalyst 的首个版本，这是销售和面向客户的团队使用的内部工作空间。Rhode 说，它汇集了原本分散在多个应用中的信息；营收运营团队随后加固了初始版本。

Anderson 介绍，Nursa 的一位会计开发了一个工具，用于管理佣金并连接客户关系系统中的信息。它与 Lovable 的例子相似，但由了解 Nursa 工作流程的人围绕公司自己的流程开发。

Nursa 的一位退休假释官也开发了资质审核应用的初版。公司需要快速核实临床人员资质，有时距离班次开始不足一天。Anderson 说，后端工程师未必会为首个版本感到骄傲，但它加快了公司现已使用的解决方案的诞生。

Anderson 认为，速度以及贴近客户的人所掌握的上下文都是优势。他说，Nursa 在 15 个月内削减了超过 100 万美元的非人员运营开支，并将对第三方供应商的依赖降低了 80% 以上。这些数字是他对 Nursa 经历的描述。

Dell 问，一款由非工程师开发的应用要在生产环境中支持业务，需要具备哪些条件。Anderson 提到愿意容忍不确定性的文化、获取相关上下文的权限，以及保护开发环境的治理机制。

他让团队考虑实际最坏情况和潜在收益。他说，对 Nursa 而言，这种思考方式帮助人们克服了对实验的普遍恐惧。开发者可以访问哪些信息，仍然是一个治理问题。

随着实现成本降低，Anderson 认为，更多实现工作可以交给了解客户问题的人。在他的描述中，早期的产品和设计流程有助于论证为什么要使用稀缺的工程时间；他认为，尝试某些想法的成本已经发生变化。

Anderson 说，作为一名高管，他现在交付的代码比 Nursa 成立第一年之后的任何时候都多。他认为，领导者需要亲自使用这些工具，才能理解团队能够做什么，以及组织正在如何变化。

招聘时，他会询问候选人处理不确定性以及在困难处境中坚持不懈的例子。他强调已经展现出来的意志力和对不确定性的容忍度，再利用工具和其他支持弥补不足。

Rhode 说，成功的组织会让更多人有能力开发，同时保留防护措施、结构和优先事项。围绕领导层明确提出的具体问题举办黑客松，可以发掘实习生或在某一主题上有深入了解的资深员工的想法。

她说，Lovable 也在开发一些方法，帮助领导者看到重叠项目，并将有前景的工作变成全公司使用的应用。目标是将组织边缘的实验与选择和完善成果的机制结合起来。

一位观众问，让每个人都成为开发者的另一面是什么：产生的材料会大量增加，人们也可能假定越多一定越好。公司如何防止大量新增内容淹没删减所能带来的价值？

Anderson 说，Nursa 增加了七条收入线，并将开发扩展到整个组织，由此产生了协调问题。他以设计系统为例：如果没有共同的基准，不同贡献者可能反复修改同一个按钮，破坏一致的体验。

他认为，分散式开发需要结构，同时也看到了用更有针对性的产品服务较小群体的价值。Rhode 再次提到人员、流程和技术：更多人需要获得工具和支持，但领导者也需要方法来整理和引导想法。

Rhode 说，Lovable 观察到，用户在开发出承担关键任务或已交付生产的产品之前，平均会制作 4.7 个一次性应用。她说，这一观察来自超过 7000 万个项目。她的解释是，练习和自由实验可能先于更持久的成果出现。

她介绍了可能推出的产品功能，帮助人们找到相关工作、识别共同主题，或避免重复开发已经存在的应用。她说，问题不只是阻止实验，而是为组织提供管理实验的工具。

Dell 区分了数量与质量。在他看来，制作许多东西可以帮助人们练习，但团队仍需要反映自身工作的标准、结合专业知识的能力，以及足够容忍不确定性、从而能够学习的组织环境。

另一位观众问，在演示和黑客松之后，如何帮助那些仍然抵触工具的人。Rhode 指出，即使是热情的组织，对于“每个人都是开发者”这一想法应推进到什么程度，也有不同看法。

Anderson 描述了他和 Nenad 开发出新产品后 Nursa 的转型。他说，预期到传统工程思维会带来阻力，于是他调整了团队分工和优先事项，并清空六个月的日程，与团队并肩工作。

他说，第一天有四人辞职，告诉他他们不希望职业生涯朝这个方向发展。第二天，一位产品经理制作了一个应用，显示火焰以及团队认为不可能完成的截止日期倒计时。

在一次全员大会上，Anderson 将这一变化描述为一项承诺，尽管不确定哪些具体改变会持续下去。他请员工提供帮助，无论他们对公司感到乐观、认为公司需要重启，还是认为需要更激烈的干预。

Anderson 说，六周内组织几乎没有交付任何东西。随后产出增加，他表示，规模最小的团队在六个月内交付的代码比此前七年还多。他将此归功于愿意在艰难转型过程中持续参与的员工和领导者。