这是一个三部曲系列文章的第二部分，探讨所有初创公司都会面临的从融资路演到可用产品之间的“阻抗失配”问题。
本文第一部分搭建了背景，并粗线条地勾勒出了“分而治之”这一范式。
这一部分专门讲述那些你今天就能加以利用、大小不一且自成一体的“乐高积木”。这是一篇动手实践型的技术读物，但它至关重要，我相信它值得你付出的每一分钟。
这是一份并不详尽的常用资产清单，你在流程早期无疑会用到它们，因此即便未来仍然模糊不清，你也可以放心地开始着手实现它们。
完成的定义（DoD）
注意：我以 DoD 作为清单的开头，是因为其他示例都会引用到它，而不一定是因为它的排序更靠前。
DoD 是各公司或明或暗都会建立起来的、无法回避的框架之一。你可能在 wiki 中有一份正式的白皮书，或者你的团队已经在遵循一系列不成文的约定。请以书面形式将其正式确定下来。
我的 DoD 包含前端、后端、UI/UX 和项目管理几个部分。你可以描述一个典型 React 组件的文件结构、应遵循的术语，并提供一个示例。我通常会推荐一些 IDE 插件，它们能根据我提供的模板生成所需的文件夹和文件，并附带相应的样板内容。点击一下即可搭建出骨架，然后填补空缺即可。
告诉我一声，如果你想一窥我在 Notion 或 Obsidian 中典型的 DoD，我很乐意分享。
一份典型 DoD 的示例。作者：Malik Alimoekhamedov。公司知识管理
信息与知识管理并非小事，如果公司内部没有一位专门负责把关的推动者，那么每个人随意的贡献就会汇成一堆彼此脱节的碎片，无法拼凑成完整的图景。
上面提到的 DoD 通常存放在公司的 wiki 中。我们都会做笔记，但每个人都有自己的方式。只要不需要协作，这也没问题。
如今大多数工具都允许你连接远程资源（例如共享文件夹），并将它们与工具内所做的笔记一并展示。有一点是确定的：你需要一个集中的知识库，以便在为新人做入职培训时，或当有人提出一个你知道早已回答过的问题时，能把大家都指引到那里。
注意：个人知识管理（PKM）是我热衷的领域。如果你想以高效且结构化的方式梳理清楚你自己以及你初创公司的信息，我为此写了一份新闻通讯。
《知识管理的机制》是我关于知识工程的免费每周新闻通讯。malikalimoekhamedov.substack.com。法律与会计类资产
条款与条件、cookie 政策、保密协议（NDA）、雇佣合同、发票模板等等。如果你身处某个孵化器，或拥有自己的人脉网络，就不要重复造轮子；至少在早期阶段，去索要现成的模板。
组件驱动开发（CDD）
CDD 非常适合用来构建复杂的解决方案：将它们拆分成更小、可复用的部分。每个元素只负责整个产品中相互隔离的一部分。理想情况下，这一部分应当小到不会承担过多职责，同时又大到值得我们把它单独打包。
前端
你很可能会需要按钮、滑块、模态窗口等 UI（用户界面）令牌。在这种情况下，建议编排一套与上下文无关的 UI 套件。在隔离环境中进行创建，以保证你的组件能够在移动/Web 应用、落地页或可打印的融资路演材料等各种环境中复用。
为了省时间，你现在可以先把它“内嵌”进去，之后再把必要的部分抽取出来。然而，如果这些视觉资产在其他地方被复用的可能性很高，那么现在慢一点、以便日后更快，就是一个明智的选择。尽管传统的初创圈子总爱唱高调，也不要害怕延迟满足。
Monday.com 提供的 CDD 示例。来源：Storybook.js.org。我通常最先引入的东西之一就是 Storybook。这是一个帮助前端开发者在隔离环境中创建组件的工具。渐渐地，一个装满弹性十足、自成一体、坚不可摧的组件的“袋子”会被逐步填满。在开发早期引入这个工具，起初会让你的进度稍微放慢一些。但只要你有足够的耐力熬过最初的爬坡阶段，它就会以指数级的方式加快你的节奏。
为每个 Web 组件配备一个专用的 Storybook 文件，是 DoD 的一部分。如果一个元素在隔离环境中无法正常工作，那它就不算真正能用。
后端
云原生初创公司另一块富有弹性的“乐高积木”是基础设施即代码（IaC）。它以代码的形式描述无服务器架构的所有构建块，这些代码可以进行版本控制、协作，并只需按一下按钮就能部署或销毁。
如果你想在同一云服务商内部迁移，或者进行我所说的“数字流浪”——初创公司一旦用完少数几家巨头慷慨提供的免费额度就立刻另投他处——你的基础设施将由此获得可移动性。
我的 IaC 主要使用 Amazon Web Services（AWS） CDK v2，用 TypeScript 编写。如果你想一睹为快，我很乐意分享。 联系我。
其他
CDD 的原则同样适用于 npm, Inc. 的包、Ruby gem 或 Java bean。它们既可以公开存储，也可以放在私有维护的制品仓库中。这值得去实践。
项目管理框架与工具
你可以在项目管理变得相关时，选定你将要使用的工具和模板。你既可以在 DoD 中描述未来的运作方式，也可以预先配置好你未来的系统。
官方网站与落地页模板
你需要一个网站。此外，许多类似 Lean Startup Co. 那样的实验会在各自专用的落地页上运行。你需要一种能够快速创建这些页面的方法，最好不必把这项工作压在开发团队肩上。理想情况下，这些页面会与你的 CRM 紧密集成。 HubSpot 就是一个例子，它提供付费扩展，让你能够生成落地页、追踪互动情况并收集潜在客户线索。
另一个可用于对你的商业假设进行 A/B 测试的实用武器是 Google 的 Optimize，或者 PostHog 的 A/B 测试。如果你以 React 作为主要的前端驱动，它的集成会有一些小怪癖，但这份前期投入是值得的。
联系我，如果你想看看我的实现方式。
用户账户管理系统
你希望拥有大量用户，而你需要将他们安全地存储在一个用户池中。我见过有些公司用明文来管理用户信息。别成为它们那样。
你将无法访问密码，这会使未来对用户池的修改更加耗费资源。我强烈建议你尽早为你的业务确定安全性与便利性之间的适当平衡。一家加密货币初创公司与一个在线计算器的用户管理需求并不相同。
支付处理
既然每一家企业的目标都是赚钱，那你就必然需要一种收取顾客钞票的方式。因此，你不必等到支付网关集成变得迫在眉睫时才动手。现在就一头扎进它的文档，甚至可以先在隔离环境中把它实现出来。
它或许能为你的工程决策带来宝贵的提示。
举例来说，Stripe 会以某种货币的最小单位来表示所有金额，而不是通常的本地化格式。不再有小数点、逗号和可疑的近似值。这使得处理没有任何小数值的货币（例如日元）与处理有小数值的货币（例如欧元）完全一致。这样一个数据建模上的小妙招，为我们的数据工程团队省去了无数换算上的烦恼。
伟大的艺术家善于“偷师”。
设计系统模块
对统一的企业视觉标识和语气基调的需求，几乎在公司成立的那一天就出现了。这样一套系统就像一组护栏，每位员工都应遵循，以避免引入任何不一致之处。配色方案、排版、图标体系以及整体观感，都是其中的组成部分。
如今的工具让你能够以 CDD 的方式管理设计令牌，将更小的模块重新组合成更高阶的视觉资产。至于语气基调，你可以使用来自 Grammarly。
搭建好你的工具，并立即创建几个在公司整个生命周期中都会用到的独立项目：一个全局可复用的设计令牌库、UI 套件、Web 应用、移动或桌面应用、融资路演材料，以及社交媒体资产。
测试框架
质量保证是产品制造过程中一个奇怪的方面：似乎人人都明白它的重要性，可总体而言，投入其中的资源却往往不足，甚至根本没有。除非你笃信 TDD（测试驱动开发），否则你可能连一个测试框架都没有。
对一类测试进行初始搭建和自动化并不是一笔巨大的投入。通过摘取那些唾手可得的成果——冒烟测试和快照测试——你就能收获诸多好处。我把它们作为 Web 组件和云基础设施 IaC 构件的一部分来实现，并作为 CI/CD 的一环，在每次代码提交时执行。它们同样是 DoD 的一项要求。
开发自动化
把开发者的舒适度置于面向客户的功能之上，这种优先级排序总是很难说得通。大多数人都教条地认为，客户价值应当压倒绝对的一切。但事情并非非黑即白。
价值必须在合理的期限内交付，达到一定的质量水平，且不至于耗尽资金。而如果身处一家技工们不得不跨过一堆胡乱堆放的工具的车间里，这一切都无法实现。锤子在哪儿？我们没有摇柄；等乔来吧，让他扶住发动机，我们好从下面把螺丝拧下来。不知为何，这类情形在初创公司创始人听来却不觉得那么荒唐。
以下是我认为任何现代且高效的技术团队都离不开的几样东西：持续集成与持续部署（CI/CD）、Git 钩子、代码检查（linting）、格式化、私有 Git 仓库和代码制品库，以及自动化文档生成。
你的工具集是什么？我们在评论区一起来聊聊技术吧。
业务分析模块
每个人都忽视了这项至关重要的资产。它是我最先着手的交付物之一，即便我被聘来是做别的事情。如果我因此被解雇，那也只能说明我本来就没进对公司。它就是那么重要。
我构建这项资产的方式颇具争议，因为我使用的是那些老牌大公司典型的工具集。许多初创公司创始人对它们不屑一顾。但到目前为止，在用图表描绘整个业务或其局部方面，我还没有找到比统一建模语言（UML）更好的东西。
一个用 StarUML 绘制的 UML 用例图示例——就跨平台友好的业务分析交付物而言，这是我迄今为止找到的性价比最高的工具。这类分析中的关键部分包括 ERD（实体关系图）、用例图、状态机、时序图、流程图和数据流图。UML 的范畴要宽泛得多，但我必须运用帕累托法则，因为我很少只扮演分析师这一个角色。
如果你知道有更现代、更赏心悦目的建模方式，请告诉我。我已经找了好一阵子了。
数据分析
你需要一双眼睛。
你只能改进你能够衡量的东西。尽早搭建好 Google Tag Manager。在实现基础追踪时，不要让开发者成为瓶颈。他们的工作不会因此停下，但这会开箱即用地释放出大量价值。
CRM 与 ERP
你需要一颗心脏。
它是客户关系和企业资源的唯一可信数据源。如果对营销和销售漏斗毫无可见性、任由员工离职时把自己名下的所有客户一并带走，而公司高层对此都无所谓，那你就进错了公司。
非技术人员期望技术人员以结构化的方式工作。但这是双向的。像“进行了很多有趣的对话”这样的每周汇报会显得像个大笑话，你也会因此失去别人的尊重。
把 CRM 拿给我看。结论
这份清单很长，但远谈不上完整。我的目标是与你分享那些最基本、最核心的东西。具体效果可能因业务性质的不同而有所差异。
最后一部分将聚焦于如何把一个更大的整体切分成更小、大小相等的同质化块。
有没有哪些具体的构建块是你有兴趣了解的？
特别鸣谢
这篇文章的成文，在很大程度上仰赖于以下各位细致入微的审阅：Lilian T. 、 Farouq Aldori、Teppo Hudsson、Jarek Owczarek、Nickolay Tsybulyanko 以及 Jason Collins。
