Peter Bogart-Johnson 谈产品管理、诗歌与倾听

Ron Minsky 介绍了 Jane Street 项目经理 Peter Bogart-Johnson。他参与过许多跨团队项目。在讨论这个岗位之前，Minsky 先问他如何从一个不太传统的背景进入技术行业。

Bogart-Johnson 学习过戏剧和英国文学，后来在纽约攻读创意写作和诗歌研究生课程。晚上上学的同时，他在服务低收入家庭的非营利组织从事倡导、筹款和项目开发，也编辑文学期刊 Lit。

一位在 D. E. Shaw 工作的编辑同事把他介绍给了公司。Bogart-Johnson 加入了 D. E. Shaw Research，这家公司为生物分子模拟开发超级计算机。他与其他作家、音乐家和艺术家一起工作，最初从事与核心技术工作相邻的事务。

Minsky 问公司是否有意招聘诗人来组织项目。Bogart-Johnson 说，公司为并非严格技术性的岗位寻找有才华和创造力的人，希望他们带来对抽象和整体思考的熟悉，即使他们最终可能离开、从事创作事业。

据他观察，这种做法效果很好。工程师可以专注于技术问题，其他同事则负责运营、项目管理及周边工作。一些从这些岗位起步的人，包括他自己，逐渐喜欢上这个领域并留了下来。

Minsky 问，这种价值来自创作工作中学到的技能，还是仅仅来自不同的视角。Bogart-Johnson 认为两者都有作用。一首诗和一个项目都可能有约束、受众，以及开头、过程和结尾；两者都涉及人们创造某种东西。

外部视角能帮助团队以不同方式看待自己的工作。但 PM 待得越久，自然会学到越多术语和背景。Bogart-Johnson 努力在获得有效工作所需知识的同时，保留不同视角之间的一些距离。

他仍然写诗，尽量每天写作，也参与纽约的写作社群。他曾组织朗读活动、编辑期刊，并与其他作家交流作品。他感兴趣的领域包括纽约诗派，以及圣马克教堂的 Poetry Project 等机构。

Minsky 解释，Jane Street 在很长一段历史中都没有独立的 PM 专业角色。公司只有三四十人时，工程师可以坐在用户旁边，从头到尾考虑软件，不需要专门的协调岗位。

随着公司增长到 2,000 多人，项目涉及的团队和用户越来越多。协调优先级、理解需求变得更难。例如，一个语言功能可能还需要编辑器集成、库修改和重构工具；遗漏某项依赖就可能延误交付。

更大的项目还会跨越开发者工具、服务器管理和交易软件。Jane Street 开始把组织工作本身视为一门专业，但引入 PM 也意味着组织和新员工双方都要学习如何共同工作。

在这一早期阶段，一位前同事加入 Jane Street，而他所在的初创公司也接近被收购，Bogart-Johnson 因此加入了公司。帮助建立一项新实践的机会吸引了他。2020 年疫情期间，他首次与公司交流。

他的第一个团队是网络团队。它距离公司的交易活动隔着几个层次，却是交易的基础。两座数据中心正在建设，一个大型研究计算集群同时需要在它们之间迁移。这项工作涉及多个团队和许多相互关联的部分。

眼前需要有人把工作组织起来，明确需求，确保参与者对最终状态有共同理解。长期目标则是让未来的项目能够持续推进。与此同时，他必须了解 Jane Street，而团队也要学习如何与 PM 合作。

早期的一个缺口是缺少统一的位置来跟踪复杂工作。项目信息分散在表格、PM 工具、邮件和聊天中。建立一个入口，减少了理解项目及其依赖关系时所需的上下文切换。

Minsky 问，新人如何充分理解现有工作流，才能改进它们并说服人们改变。这些工作流可能是被动应对问题逐渐形成的，但也反映了真实需求和人际关系。Bogart-Johnson 说，建立信任需要时间，第一步是从团队现状出发。

PM 完全可能一来就强制推行完整的敏捷框架、冲刺和故事点，却没有了解团队。他建议只借用真正有帮助的做法。把一个小型初始版本交到用户手中获取反馈，可能比一套庞大的官僚流程更有价值。

渐进式变化会随着时间推移展现价值，并建立信任。Minsky 更愿意从具体经历和做法中学习，而不是全盘采用一种方法论。Bogart-Johnson 将这项工作称为人类学式的：在尝试改变团队之前，先了解其行为、实践和关系。

理解这些细节需要几个月，而且随着人员加入或离开，这个过程还会继续。即使很小的变化，也可能随着时间影响团队文化。对 Bogart-Johnson 来说，关注这种演变正是工作的乐趣之一。

远程入职让学习更困难。他在 Brooklyn 的餐厅里与相对少量的同事互动，试图通过视频通话理解一个大得多的全球组织。在最初的九到十个月里，他很难感受到公司的整体文化。

2021 年第一次进入办公室时，他看到了来自公司其他部门、自己不认识的同事，也重新有机会在午餐时或办公桌旁自发交谈。大家对他很欢迎，让他更真切地体验到此前只是听说过的文化。

Minsky 说，这些偶然相遇能体现同事通常愿意提供帮助。Bogart-Johnson 同意，并指出 PM 工作很依赖人际关系：走过去讨论问题、共同理解情况的机会，在远程入职时受到了限制。

两人转向远程与混合办公工具。疫情初期，Jane Street 同时使用常规视频会议软件和一款最初为游戏设计的低延迟音频工具。两者各有用途，但使用不同系统的人仍需要相互沟通。

公司构建了一个桥接工具：用户可以将低延迟音频与会议系统的视频结合，并将后者的音频静音。日历集成让设置更简单，人们也可以根据对话需要切换工具。

回到办公室并没有让这些工具失去价值。Minsky 指出，远程工作也改善了纽约、伦敦和香港办公室之间的沟通。目标是在支持不同地点工作的同时，保留这些收获。

团队开发了更轻便、可移动的版本，聘请外部开发者制作 iOS 应用，并为办公桌配备设备、麦克风和摄像头。开发者和用户可以坐在一起讨论逐渐成形的方案，并在推广给更多人时加以完善。

Minsky 观察到，这比 Jane Street 传统的内部交易软件更像消费产品：可能有数百人甚至上千人使用。组织需要学习如何收集反馈，并为更广泛的用户群体构建产品。

截止日期起到了帮助。大批人员即将返回办公室，团队需要一个最小可行版本。为了尽快提供可用的东西，团队最初优先保证性能，而不是完全打磨设计，接受了尚非最终形态的体验。

发布前，团队邀请来自技术、交易和公司其他部门的人进行测试。团队无法定期采访所有人，因此寻找了解各自群体需求的代表性用户。此后团队继续迭代了一年半甚至更久。

支持不同设备也需要取舍。Bogart-Johnson 描述了一个 Android 版本：发布时虽然还没有达到团队期望，但已经可用，之后再逐步改进。这种灵活的做法让团队在实际使用中学习的同时交付价值。

Minsky 欣赏组织能够在两种模式之间切换：谨慎可靠地改进现有系统，以及在紧急情况或机遇出现时快速行动。疫情、洪水或新的市场机会，都可能要求组织改变优先级并接受不同的妥协。

Bogart-Johnson 说，Jane Street 经常依赖共识和讨论，这可能需要时间；但公司也能围绕紧迫问题迅速集结并行动。据他的经验，组织达到这样的规模后还能同时保持两种能力，并不常见。

他认为文化的保留是有意且渐进的。引入新做法时，公司会从多个角度思考。PM 岗位本身就是一个例子：最初他有时觉得自己更像工程团队的外部资源，而不是完整的团队成员。

三年间，多学科团队越来越多地包含工程师、PM，有时还有设计师。通信工具项目结合了内部开发者、外部公司、PM 工作和发布说明。每一种贡献都影响了最终体验和采用情况。

Minsky 说，一些工程师担心 PM 会从其他组织引入无益的做法，或者挡在开发者与用户之间。Jane Street 重视工程师与用户的直接联系，以及他们从头到尾理解问题的责任。

Bogart-Johnson 同意，PM 不应在构建者与产品或用户之间增加层级。目标是让团队更专注、更了解用户，并采用足够轻量的流程，使其即便在 PM 离开后仍然有用。

Minsky 补充，开发者也需要理解 PM 的贡献：确定要构建什么、组织工作并帮助团队交付。Bogart-Johnson 说，这种关系归根结底依赖相互尊重和学习如何共同工作。

一个挑战源自积极的动机：人们愿意答应请求并帮助同事。随着请求增加，这种意愿可能侵蚀专注力。重大紧急情况出现时，同时推进二十项工作的团队可能很难在事后全部重新捡起来。

如果延迟可以接受，告诉同事两周或一个月后再提供帮助是可以的。这样可以保护当前重要工作的时间。Bogart-Johnson 说，公司在这类选择上有所进步，但仍有改进空间。

Minsky 将过度承诺称为调度问题。把人分配到许多项目，可以缓解面对请求时的焦虑，却可能让每个项目都进展甚微。只有当东西能够运行并交到用户手中时，用户才会获得价值。

他见过团队通过让三个人一起专注于一两个项目，而不是每人同时做六个项目，来改善交付。友善是好的基础，但不是计划：组织必须比较选项并选择把精力投入何处。

招聘 PM 时，Bogart-Johnson 特别看重同理心，以及从团队现状出发的意愿。经验和领域知识有帮助，但倾听、观察流程并成为建设性的变革推动者，比强加解决方案更重要。

基本技能仍然重要：候选人应能拆解工作、让进展可见、跟踪进度和风险、关注交付、从项目中学习，并与技能不同的人合作。面试还需要探索不那么容易量化的特质。

面试官会提出问题，观察候选人如何调查，以及如何了解团队希望怎样共同工作，而不只是看他们是否给出答案。Minsky 将其与模拟协作的工程面试相比，而不是只考察背熟的算法。

双方都关注候选人的倾听、解释、识别不确定性，以及在新信息改变问题时调整判断的能力。如果情况已经变化，候选人仍然坚持同一个答案，可能说明错过了倾听和适应的机会。

Bogart-Johnson 把写作既看作沟通，也看作思考方式。总结问题能帮助 PM 完善叙述、界定项目范围并发现解决方法。好的写作不是思考完成后才产生的一份报告。

Minsky 问 PM 需要多少技术背景。在开发者工具领域，他认为直接经验有助于理解用户。Bogart-Johnson 说，无论起点如何，仔细的入职培训和学习机会都能帮助 PM 建立背景知识。

Jane Street 的 OCaml 训练营也向非工程师开放。Bogart-Johnson 完成了自学版本，这帮助他理解工程师的工作流和发布周期，尽管他并不每天编程。他认为，同理心和学习意愿仍然不可或缺，技术背景的候选人也不例外。

对话回到技术债。Minsky 描述了永无止境的请求队列带来的压力：如果团队从不改进平台或偿还技术债，摩擦就会增加，未来的交付也会变慢。PM 可以帮助团队为这项工作留出空间，同时不忽视用户需求。

Bogart-Johnson 所在的存储团队大约每六个月举行一次为期两周的减少重复劳动冲刺。工程师整理反复出现的运营任务，开发小型自动化工具，从而有更多时间处理集群、工具和其他实质性工作。

公司内部一些重要工具就是从这些工作中产生的。它们也增进了团队情谊：同事可以消除每天都会遇到的烦恼。PM 可以发现项目之间合适的空档，帮助团队为此预留时间。

Minsky 不愿仅把它描述为照顾团队而不是服务客户。工作体验愉快固然重要，但减少手工劳动也能提升团队为组织其他部门交付的能力。工程师的时间本身就是宝贵资源。

Bogart-Johnson 同意，并强调要做出选择。与其清除二十个互不相关的小烦恼，团队识别反复出现的主题，解决两三个更深层的问题，可能收获更多；这些问题既影响团队自身，也影响用户。

Minsky 介绍近期一次 GPU 基础设施扩张。Jane Street 的研究转向深度神经网络，需要更多训练和执行能力、本地硬件、云资源、网络，以及能够向 GPU 输送数据的存储。

从 Bogart-Johnson 所在核心服务团队的视角看，最初的信号是有人购买了更多 GPU，需要数据中心空间。团队很快意识到，不能只是被动响应单个请求，还要理解这些采购所服务的更大目标。

研究、核心服务和其他团队之间的讨论梳理了本地与云资源、任务调度和网络硬件等选择。Bogart-Johnson 说，PM 可以让相关人员参与这些决策，而不只是等决定做完后接收指令。

这样一来，互动就变成了伙伴关系。团队能够理解工作的时间线、范围和目的，也能识别必须推迟的其他承诺。清楚知道紧急项目为什么重要，同样会影响团队士气。

Minsky 重视让请求者解释他们试图达成什么，而不只是说出自认为需要的具体设备或功能。提出的方案可能交货周期很长，也可能没有解决根本问题；共享背景能让其他人提出替代方案。

Bogart-Johnson 建议，在购买大型专用系统之前先测试较小的版本。例如在存储方面，团队可以先用现有存储配合较小的联网 GPU 配置，了解工作负载真正需要什么，再决定是否投入强大的新集群。

Minsky 将其概括为优化学习速度，而不只是追求预先确定的最终状态。硬件和机器学习模型都在快速变化，因此团队需要一边构建、测试和调整基础设施，一边了解实际需求。

这种方式也意味着接受错误。网络等基础设施团队以可靠系统为傲，但做出完全加固的方案需要时间。不确定而紧迫的工作需要明确地做出押注，也要允许人们尝试尚未达到生产标准的东西。

Bogart-Johnson 说，实验失败不应自动意味着团队必须像稳定服务故障一样放下所有事情。人们需要共同预期和信任，才能在一起学习时接受一定程度的不确定性。

具体来说，PM 可以把关注点不同的人带进同一个房间：网络工程师可能关心稳定设计，研究人员则关心 GPU 能运行哪些模型。团队需要共同的最终目标，并理解各项决策如何相互影响。

PM 的角色是维持这一共同框架、揭示假设，并帮助人们记住大家正在朝同一个结果努力。Bogart-Johnson 认为，有人真正重视这种协调很有价值。