25 年软件开发经验老司机告诉你:如何用生成式 AI 做项目管理!

2024-06-27 18:45:41 浏览数 (1)

作者 | Ken Judy

译者 | 明知山

策划 | Tina

我有 25 年软件开发和领导团队的经验。今年,我重新回到产品和编程相关的工作上,恰逢生成式 AI 助手(如 Claude3、ChatGPT、Llama2 和 MistralAI 等大语言模型)蓬勃发展。它们的出现对我来说非常有价值。

生成式 AI 助手帮助经验丰富的专业人士发挥他们的优势,他们描述他们希望 LLM 可以完成的任务并对结果进行批判性评估。这些工具使我们能够迅速跨越领域语言的鸿沟,将大型重复性任务变成了适合人类完成的有趣的任务。如果使用得当,它们可以从根本上促进人与人之间的互动。

在本文中,我将重点讨论三项这样的活动,以及 AI 助手如何帮助我更好地利用人们的时间,并与他们一起更快地取得成果:

  • 学习和发现;
  • 阐明和理解需求;
  • 与利益相关者保持一致。 学习和发现

开发软件需要快速掌握很多文本内容:对话记录、手册、规范、问题追踪和代码,然后从这些上下文中综合和传达见解。

我充分利用文档协作工具内置的 AI 助手来克服领域特定语言方面的障碍:技术、行业或监管。

在这个例子中,我使用了一个基于大模型(如 ChatGPT 4 或 Claude 3 Opus)的 LLM 聊天工具,它帮助我从一组客户故障工单中提取主题。我这样做是为了了解客户的痛点以及公司在解决这些问题时所面临的挑战。我导出了一份包含 150 个工单摘要的清单,并将其附加到 LLM 聊天中。

在聊天中使用了大约 30 个提示词,我可以从中提取问题类型,按类型总结和分组问题,并将它们与对应用程序流的理解结合起来。据此,我构建了一个顺序图,并确定了客户在该顺序中遇到问题的位置。

我知道 AI 助手是有缺陷的,它会提供不完整的信息,总是想方设法遵循我的提示,并且可能会撒谎。因此,出于责任方面的考虑,我会向专家寻求验证。我会与工程师一起评审顺序图,并征求他们对我的假设和关注点的反馈。

这项工作在半天内就完成了,而如果自己从源文档中吸收并得出见解则需要几天时间。将这项工作带到团队中意味着他们可以专注于澄清和纠正,而不是重复之前的对话。

这项看似枯燥、单调的工作变成了一场对话,文字立即出现在页面上,帮我获得见解。

阐明和理解需求

我作为产品负责人加入了一个活跃的项目,发现现有的待办事项清单为团队圈定了范围,但没有提供优先级或为每个特性提供明确的业务价值描述,因此没有足够的信息来决定如何实现它们。

相反,工程师们基于由非开发人员撰写的产品需求定义(PRD)展开工作,这是一个相当常见的情况。当工程师们接受了任务而没有业务目标时,他们很难充分利用他们创造性解决问题的技能和经验,在时间和资源有限的情况下设计出最有效、可维护和可扩展的解决方案。

结果是工程团队需要重新审视和反思,而这在利益相关者看来是一种时间浪费。利益相关者希望工程师们继续进行他们的工作,而这对他们来说感觉既无力又冒险。

这个问题在于信息传达模糊不清,他们需要更多的信息。如果能够从现有文档中提取相关的上下文信息,你就可以将其从一个领域翻译成另一个领域的语言,而弥合这一差距正是生成式 AI 发挥作用的地方。

我使用 Notion 将 PRD 转化成一个临时的工作待办事项清单。在这个例子中,我将 10 页的 PRD PDF 文档导入到一个 Notion 文档中,然后开始提问:

LLM 从 PRD 中提取工程团队所需的工作描述,并用更符合他们需求的语言来表达。我的提示词引导 LLM 需要提出和详细说明哪些主题。

因为 LLM 已经基于公开可用的用户故事数据进行了训练,所以它知道如何生成看起来和听起来像是一个完整的故事的内容。这些内容可能包含虚构的东西(它会用看起来合理但不真实的东西来填补空白)。我对这些故事进行评审,并根据需要做出修改。最重要的是,我与利益相关者和工程团队一起评审这些故事,并根据他们认为合适的情况做出修正。

因此,这并没有取代人工流程,但它从利益相关者的角度创建文档,并使用 LLM 快速将其翻译成工程团队可理解的东西。然后,与双方进行核实为我节省了数小时的时间。利益相关者可以看到他们的 PRD 被用到了,而工程师们也可以理解他们需要构建什么。

即使没有 AI 助手,我也可以完成这项工作,因为我有足够的经验。但使用 LLM 加快了这一过程,我可以专注于批判性思维和问题,可以专注于有趣的细节。

与利益相关者保持一致

我仍然手写会议笔记,这有助于我集中注意力,并提高我的回忆能力。我甚至会用我喜欢的钢笔,因为那很有趣。不过我也会使用自动转录和摘要功能,无论是视频会议内置的,还是第三方提供的视频会议服务,并让所有参会者知道会议内容正在被记录。我目前更喜欢这些第三方解决方案。

在必要的情况下,我会使用摘要功能,根据我们的待办事项和笔记创建状态更新草稿。像 Notion 这样的文档管理平台内置的 AI 助手将摘要功能作为一个菜单选项,而通用的 AI 聊天工具可以根据提示词生成摘要。

我会重写关键点,然后发给团队和项目利益相关者。它们可以作为我们面对面评审的纲要。通过使用 AI 助手,花在这项工作上的时间被缩短到了 30 分钟,我因此能够专注于获取见解,而不是重复性的摘要工作。

负责任地使用 AI 技术

无论何时何地,使用 AI 助手都不会减少个人对其工作成果需要承担的责任和义务。

作为专业人士,我们必须考虑暴露给 LLM 的内容的隐私性或业务敏感性。我们需要留意 LLM 服务的使用条款和隐私政策。如果可能,选择不被用于训练目的信息共享,在必要时可以使用不会泄露信息的本地模型或保持信息在安全范围内的云服务。

要注意这种技术的功耗、计算时间和成本。作为个人和组织成员,尽量减少不必要的计算。例如,使用低保真度或本地模型。如果可以通过附带文件或检索增强生成(RAG)调用预训练模型,就不要进行昂贵的微调。

使用 AI 来改善人类的生活质量和提高生产力,而不是要取代他们。

例如,我构建了我的第一个 RAG 应用程序来解决一个团队的业务问题。这个团队并没有要求使用 AI,他们是一个支持团队,有一个非常有经验的负责人和两个新成员负责提供支持服务。RAG 成为解决方案的一部分,让这个团队能够从现有资源中获取答案,而无需去寻找它们,或者像通常那样向领导咨询。这让负责人能够专注于解决客户问题,并帮助回答团队其他成员提出的新问题。在我向负责人交付这个工具时,他非常高兴。这个工具还提供了一种编辑和保存答案到规范操作手册的方法。我们希望它能够成为一个活文档,可以记录对常见的客户痛点问题的响应。

如果你在用机器生成内容帮你编写代码和设计文档,要让别人知道,让其他人能够对这些内容的使用、准确性和出处进行监督。

结 论

对于有经验的软件专业人士来说是,如果使用得当,生成式 AI 是一项巨大的资产。它可以帮助我们捕捉、总结和查询大量内容,并迅速将其从一个视角和领域特定术语翻译成另一个。这样可以减少单调的重复工作和返工。我非常依赖它们来加速上下文学习、减少单调工作,并提高输出成果。这有助于我为利益相关者和团队提供支持。它减少了软件开发生命周期中不同参与者之间的摩擦,并增加了我从工作中获得的乐趣。

说明:在本文中,我在示例中使用了 LLM。我还使用 LLM 帮我列出写作要点,但我没有使用 LLM 撰写文章内容。

查看英文原文

https://www.infoq.com/articles/generative-ai-software-project-management/

声明:本文由 InfoQ 翻译,未经许可禁止转载。

0 人点赞