目录

合作生命周期

每个合作项目都会经历四个阶段：

  • 受理。同事或客户按照“如何让 FDE 参与”中列出的信息提出需求。这些信息足以让我们进行范围界定。
  • 界定范围。我们随后对合作类型进行分类，估算工作量，并在项目形态需要时提供报价。产出是一份简短的项目简报，供客户在我们承诺之前确认。详情见下文。
  • 执行。我们进行实际动手工作：埋点、数据建模、迁移、集成、仪表板以及参考实现。我们在过程中沉淀可长期复用的成果。
  • 收尾。我们确认交付物已交付并获得批准，然后将客户关系交还给销售和客户成功团队。我们记录下任何值得为下一个客户保留的内容，以及任何需要反馈给产品团队的经验教训。

界定合作范围

在交付开始之前，每个合作项目都需要一个可衡量的成果、一个大致的时间线，以及对“完成”的共同定义。我们将其写成一份简短的项目简报，并在承诺之前发送给客户确认。范围要小：扩大一个紧凑的范围，比撤销一个松散的范围成本更低。

在界定范围时，我们始终会问：所描述的问题是否暗示着更深层的模式？理解真正的问题空间，以及我们识别出可能导致长期问题的结构性问题的能力，是决定合作成败的最关键因素。

成本是多少

定价取决于项目形态、工作量和商业背景，因此具体数字在 FDE 计算器和商业参考文档中，而不是在这里。其理念是：

  • 合作之前的探索和范围界定时间是免费的，且有严格的时间限制。
  • 定价按里程碑交付物报价，而非按小时计费。交付物范围翻倍意味着重新报价，而不是非正式的延期。

切勿当场编造具体数字。如果客户询问，请告知他们一天内会收到报价，并通过客户负责人进行流转。

客户还可以在有合理客户层面收益的前提下，酌情将预付额度用于 FDE 合作项目。这需要 Simon 的批准（Ben B 作为备选）。

原则

这些是我们在每个合作项目中秉持的默认原则，旨在为客户带来令人满意的成果。

  • 价值的基本单位是可衡量的客户成果。而不是一份文档、一个建议，或一个合并的 PR。我们以客户发生了什么变化来衡量合作，并在开始之前就商定好衡量方式。
  • 解决客户的真实问题，而不是最容易开成工单的那个问题。最有力的做法往往是纠正客户的认知模型，而不是完全按照他们要求的内容去构建。在深入之前，先问清楚：实际上是什么决策依赖于这个答案，以及“足够好”对该决策而言是什么样子。
  • 从 MVP 开始。动手之前先明确最小答案是什么。今天给出一个简短的清单，通常胜过下周才交出一份冗长的分析。做超出问题所需的东西不是严谨，而是浪费。对每一个“我们要不要顺便……”都要敢于说不。
  • 优先使用 PostHog 自身的基础能力。优先选择 PostHog AI 和平台内置功能，而不是定制开发。产品已经支持的最简单路径通常是正确的，而且也是我们离开后客户能够自行维护的路径。
  • 沉淀可复用的成果。当我们为某个客户构建的东西能帮助其他客户时，把它转化为示例、模板或产品改进。让你的工作可见，这样我们才能基于可见的工作及其结果进行复盘、发现改进空间。
  • 以实质内容为先。在与客户的沟通中，先说你发现了什么、你打算怎么做，绝不要只说“产出物已经存在”。“报告已经写好了”读起来就像套话。要说清楚里面写了什么。
  • 贴近产品工程。我们是真实客户使用与产品路线图之间最快的反馈回路，所以要充分利用这一点。

判断力重于产出量

当 AI 承担越来越多的生产工作时，FDE 的价值不再在于能产出多少，而在于他们所贡献的判断力。当生成变得廉价时，稀缺的技能正是模型无法替你提供的那些：

  • 做好优先级排序。知道十件合理的事情中该先做哪一件，以及哪些根本不该做。
  • 找出真正的问题。阅读模糊或过度指定的需求，找到其背后真正的问题。
  • 选择最简单可行的方案。在能胜任时用简单方案，只有在能防止真实回归问题时才用稳健方案。
  • 让工作产生复利。决定现在做、推迟还是委派，但要构建工作结构，使你现在所做的也能降低不确定性、产出证据，或推进更大的项目里程碑。

我们据此招聘和培养人才，并给人们留出发挥判断力的空间，而不是让他们照本宣科。

改进循环

做事和改进做事方式是同一项活动。每一次项目交付都会教给我们一些东西：一个反复出现的问题、一个被验证有效的模式、一个流程偏离的地方。我们记录这些，对经得起验证的加以把关，并将其提升到合适的通用层级：一个客户问题变成主题参考，一个跨客户的模式变成经验教训或 playbook 条目，一条来之不易的规则变成标准。

其结果是一个随时间不断增值的团队知识库，让每一次新项目的起点都更高。

复利式工作

我们先为某一个客户把事情做对，从而赢得让工作产生复利的资格。

这意味着我们专注于解决单个客户的问题，并尽快为他们交付真实、可衡量的价值。只有当方案在真实世界中验证有效后，我们才会考虑将其推广到 N 个客户。我们不会在早期就试图让方案对所有客户通用或可扩展，因为过早泛化通常意味着谁的 problem 都解决不好。

在实践中：

  • 立即交付价值。不断追问下一步需要做什么才能推动客户目标的实现。
  • 让工作可见。记录你所做的、学到的、修复的和发现的内容，以便他人查找和使用。
  • 在实际工作中学习。通过真实的客户工作来暴露实际问题，而不是试图提前对所有问题进行建模。
  • 优先为当前客户解决问题。只有当工作给出证据表明某件事值得规模化时，才进行泛化。
  • 带回我们学到的东西。解决方案可以保持针对特定客户，但有价值的发现不应如此。

Sprint

FDE 团队以两周为一个 Sprint 进行工作，从周一持续到下一周的周五。站会在周一和周三举行，时间为英国时间下午 2:30 / 美国东部时间上午 9:30。

在 Sprint 结束的那个周五，GitHub Action 会自动关闭当前 Sprint 的 issue，并为下一个 Sprint 创建新的 issue。FDE 团队成员需要在 Sprint 启动会（在周一站会上进行）之前填写好该 issue。

团队协作

作为一个团队，我们仍然很新，正在边做边摸索。为了确保每个人都朝着正确的方向努力、避免重复工作，我们：

  • 一旦工作可能影响团队、客户或共享系统，就让它可见。我们遵循 PostHog 的惯例，优先使用 pull request 而非 issue 和 Slack 讨论。RFC 仅在你想邀请讨论时使用，并保持少用。
  • 在现有工作基础上构建。在开始新的解决方案之前，先检查是否已有相关工作正在进行，然后复用它、改进它，或明确解释为什么需要单独的方法。
  • 利用同伴反馈来完善方案。尽早提出替代方案，以便我们共同考虑并就最佳路径达成一致。
  • 创建可维护的团队资产。避免构建只有某一个人才能操作的工具或工作流程。
  • 追踪客户成果，而不仅仅是工作产出。

总体而言，在 PostHog，我们倾向于尽早分享尚不完善的工作，让同伴帮助塑造工作的方向，而不是等到一切完美就绪后才让团队看到。