你是否遇到过那种令人难以应对的项目，被要求从零开始构建自定义CRM，心想"这根本不可能"？两年前我就经历过这个时刻，一个客户需要在短短14周内完成他们的CRM。不是典型的时间表。但这里的关键是：使用我们的5阶段方案，这不仅是可行的，而且过程出人意料地顺利。Stack Overflow和Postman是我每天的伙伴。而且，我确实学到了不少经验教训。
第1阶段：发现与范围界定（第1-2周）
大多数CRM项目在写一行代码之前就已经失败了。我是认真的。失败发生在会议室里，通常围着一块白板，当每个人都点头同意模糊的需求而没人提出难堪的问题时，失败就发生了。
对于这个项目（伯明翰一家中型物流公司，约80名员工），我在前两周几乎什么都没做，只是在听。研讨会、录制的Zoom通话，以及一个共享的Notion文档，利益相关者可以在其中列出他们希望CRM处理的每个工作流程。该文档增长到47页。其中有很多相互矛盾的地方。这实际上很好，发现文档中的矛盾是免费的；在第11周发现的矛盾会让你损失一个冲刺周期和一个客户关系。
你实际在映射的内容
发现阶段的目标不是捕捉每一项功能。而是要绘制数据关系图和用户角色，这些将决定后续所有的架构决策。我在这个阶段使用 Whimsical 来制作流程图。快速、易于分享，客户可以直接评论，无需创建账户。
到第2周末，你需要锁定四项交付物：
- 一份优先级排序的功能清单，分为 MVP 和上线后的功能
- 一份实体关系大纲（还不是完整的数据模式，只需列出名词：联系人、交易、销售管道、任务）
- 用户角色定义，权限级别用简明英文说明
- 一份签字生效的时间表，明确里程碑，而不是含糊的阶段
最后一点是不可协商的。"第2阶段完成"没有任何意义。"联系人导入和基于角色的访问权限在第28天上线到测试环境"才是有意义的。
---
第2阶段：架构和技术栈决策（第3周）
只有一周。我只为这个阶段分配这么多时间，因为我见过团队陷入架构讨论一个月而什么都没交付的情况。
这个项目的技术栈是：后端用 Node.js 和 Express，数据库用 PostgreSQL，前端用 React，整个应用部署在 DigitalOcean 的 Kubernetes 托管服务上。我们选用 Prisma 作为 ORM，因为数据库架构需要快速迭代，而 Prisma 的迁移工作流对此确实很友好。
说实话，技术栈的重要性被人高估了。更重要的是：
- 项目里的每个开发者都能快速上手这个栈，不需要陡峭的学习曲线吗？
- 架构能否支撑你在第 1 阶段设计的权限模型？
- 你能在第 10 周不重写认证层的情况下，添加一个新的实体类型（比如"供应商"）吗？
第 3 点是我之前吃过亏的地方。回到 2021 年，Seahawk 有个 SaaS 项目在第 9 周才匆忙加上多租户功能。改造花了四天，本来应该是第一天就决定的事。再也不干这种事了。
在认证方面，我默认使用 Auth0，除非有非常充分的理由不用。它处理了那些让初级开发者头疼的边界情况（密码重置、多因素认证、社交登录）。
---
第 3 阶段：核心开发冲刺（第 4-9 周）
六周时间。这是项目的关键阶段。如果你前面的范围界定做得扎实，这个阶段其实是整个项目中最直接、最顺利的部分。
我把这个分成了两个三周的小冲刺，中间有一次硬性的内部评审。
冲刺 A：数据层和 API（第 4-6 周）
在 API 契约达成前，任何东西都不能碰前端。句号。我在写控制器之前会在 Postman 里文档化每个端点，听起来很乏味，但能省下大约两周的"等等，这个端点到底返回什么？"的讨论时间。
数据库模式在这里迎来第一次真正的审视。对于 CRM，总是被低估的表是活动日志表和自定义字段表。每个客户都想要自定义字段。从第一天就正确构建一个灵活的 custom_field_definitions 表大约需要四小时的工作。在第 11 周临时拼凑它就是噩梦。
冲刺 B：前端和工作流（第 7-9 周）
用 React 搭配 TanStack Query 来管理服务器状态。我在 2022 年的一个较小项目上试过用纯 useEffect 和本地状态。再也不会这样对待自己了，TanStack Query 以一种不需要特技就能让 CRM 界面感觉敏捷的方式处理缓存、后台重新获取和乐观更新。
对于 UI 组件层，我们在这个项目上用了 shadcn/ui。它不是传统意义上的组件库；代码你自己拥有，这意味着你可以真正自定义它而不用和库对抗。对于有管道视图、联系人表和任务看板的 CRM，这种灵活性很重要。
这个冲刺中一贯遗漏的一件事：空状态。一个没有数据的 CRM，如果你没有为零状态屏幕设计，看起来就像坏了。早点构建这些。客户用空数据库给利益相关者演示，第一印象是持久的。
---
第 4 阶段：集成和数据迁移（第 10-11 周）
这正是大多数代理商低价报价和规划不足的地方。我每次都看到这种情况。
伯明翰物流客户需要与他们现有的 Xero 会计系统和一个他们正在迁移的较旧 Salesforce 实例集成。两周时间听起来很紧张。确实很紧，但我们做到了，因为我们在第 3 阶段就已经初步确定了集成要点。
对于 Salesforce 迁移，我们使用了他们的 Bulk API 2.0 来提取数据，然后通过一个 Node 脚本来映射他们的字段结构到我们的结构。脚本花了一天时间编写，三天时间迭代，因为 Salesforce 数据几乎永远不会像客户认为的那样干净。为数据清理留出预算。始终如此。
在宣布一个集成"完成"之前，我会检查几件事：
- 失败处理：当第三方 API 宕机时会发生什么？
- Webhook 幂等性：你能否安全地处理同一事件两次而不会重复记录？
- 速率限制：在现实负载下，你是否在限制范围内？
Xero 开发者文档实际上还不错。OAuth 2.0 流程文档完善，他们的沙箱环境运行可靠。
---
第 5 阶段：质量保证、强化和交接（第 12-14 周）
三周的QA测试听起来很充裕，直到你真正进入其中。
第12周是结构化测试。我给客户一个ClickUp看板，每个测试用例都写成一个任务，他们进行测试、标记结果，如果有问题就附加一个Loom录屏。这让真实用户点击真实的流程，总会发现开发者自己测试时漏掉的东西。有人会尝试在"备注"字段里粘贴4000个字符。有人会导入包含智能引号的CSV文件。你希望现在就发现这些问题。
第13周是修复冲刺。不做新功能。只做bug修复和性能优化。我针对每个关键页面运行Lighthouse测试。我还对API运行k6负载测试，不是因为客户要求，而是因为在第13周时就在50个并发用户下找到慢查询，比在上线后才发现要好得多。
第14周是交付和上线前准备。
我提供的交付文档涵盖：
- 基础设施概览（什么在哪里运行，如何扩展）
- 数据库备份和恢复流程，已测试和验证
- 如何在不修改代码的情况下添加新用户角色
- 已知局限性以及我们推迟的待办项
最后一点很重要。诚实地说出什么没有完成。客户会尊重这一点，而且能为下一阶段的工作奠定良好基础，而不是留下隐性债务来困扰合作关系。
关于上线的最后一点
错开发布。我们在第92天向10个用户进行了软启动，用Datadog监控日志48小时，然后向全部80人的团队开放。那48小时的窗口捕获了两个在管道阶段转换中的边界情况，这些在测试中没有出现过。没什么灾难性的，但如果我们一开始就全力推进，这种问题会在第一天产生15张支持工单。
上线不是终点。它只是真实用户行为数据开始到来的时刻。
---
常见问题
像这样的定制CRM通常要花多少钱？
说实话，差异很大，但14周的项目、以这个规模来看、由小团队负责（两名后端开发人员、一名前端开发人员、一名项目负责人）通常在£60,000到£120,000之间，取决于集成和数据迁移的复杂性。如果你看到有人报价低于£30,000来做完整的定制构建，要硬着头皮问清楚到底是真的在构建什么还是只是在配置现有模板。
能在WordPress上构建定制CRM吗？
可以，但我不会在超过大约500条记录或20个并发用户的情况下这样做。WordPress的数据层并不是为关系型CRM工作负荷设计的。在Seahawk，我们为较小的客户在WordPress上面构建了联系人管理层，但对于任何严肃的项目，正确的做法是使用拥有关系型数据库的专业后端。
团队在CRM构建中最常犯什么错误？
权限模型不够细致。大家都专注于功能特性，却忽略了一个80个用户的CRM在写第一行API代码之前需要回答"谁能看到哪笔交易？"这个细致的问题。到了第10周才改造基于角色的访问控制是一种痛苦，这种痛苦很难描述，除非你亲身经历过一次。
你总是使用这个确切的技术栈吗？
不是。我描述的这个栈适合这个项目的团队和约束条件。我用过Laravel和Vue开发过CRM，用过Django和React，还有一次用Next.js全栈设置开发过，我对它持怀疑态度，但它实际上表现很好。架构原则保持不变。工具可以灵活调整。
最后，这个自定义CRM项目不仅是一个挑战，更是一次启示。那个紧张的14周窗口？它迫使我们创新、适应和交付。事实证明，约束可以成为创意的催化剂。谁会想到截止日期能教会我们这么多关于自己手艺的东西？正是这样的项目提醒我为什么要共同创办Seahawk Media。