发布于 2026-01-06 10 阅读
0

为什么为A轮融资公司构建身份识别程序(IDP)没有意义

为什么为A轮融资公司构建身份识别程序(IDP)没有意义

你是A轮融资公司的CTO?在继续阅读之前,先给自己一个大大的赞。你和你的团队迄今为止所取得的成就绝非易事,所以,你们真的很棒!

但现实情况是,这项工作远未完成。未来还有许多规模化和增长方面的决策需要做出,而且可能存在的问题比明确的答案更多。

你或许会想提前采用各种工具和流程,为工程团队未来的潜在增长做好准备。但本文将解释,为什么与其盲目采用新流程或花哨的内部开发者平台,不如继续坚持让你走到今天这一步的现有方法,这样更有可能取得成功。

打好基础

A轮融资的公司通常充满活力,往往会有相当数量的新人加入,流程日益标准化,整体而言,公司内部正逐渐走向成熟。这种希望提升工程团队成熟度的初衷可以理解,但却并不明智。

再成熟的技术水平或再精湛的工具也无法弥补产品市场契合度(PMF)的不足。在这个阶段,验证不同市场的PMF应该是重中之重。尽管PMF难以捉摸,但实现它的最佳途径是保持敏捷、快速交付并维持紧密的反馈机制。

规划未来的可扩展性或许很有吸引力,尤其是在平台工程热潮涌动以及现成的内部开发者平台 (IDP) 解决方案层出不穷的当下。然而,至关重要的是要了解为什么这些方案可能并不适合您目前的实际情况。让我们深入探讨一下,为什么 IDP 并非您认为所需的变革方案。

平台工程

什么是境内流离失所者?

身份提供商 (IDP) 是构建在组织基础设施之上的自助服务层,它使开发团队无需深入了解基础设施或依赖传统基础设施工程师的帮助即可部署和管理应用程序。随着组织的成长,IDP 旨在通过标准化工作流程和环境,提供一致性、自动化和速度。

可以将身份提供商 (IDP) 视为由 DevOps 或平台工程师维护的内部产品,他们主要服务于自己的客户群,也就是您的开发团队。要理解为什么对于 A 轮融资的公司来说,采用 IDP 可能会适得其反,首先必须了解 IDP 最初出现的原因。

随着公司规模的扩大,其工程团队也会随之壮大。在大型企业中,如果运维团队无法跟上步伐,就很难维持代码质量、满足基础设施需求并保持部署速度。身份提供商 (IDP) 的设计初衷就是为了摆脱对传统运维团队的依赖,转而依靠一个能够积极演进以满足自身需求的平台。

这里需要指出几个重要的假设:

您有能力维护一个全新的产品(身份提供商)。您可能没有。

你已经扩展了工程团队的规模,现在需要优化它。但你可能还没有优化,而且也不需要优化。

图1

A轮融资公司应该关注什么?

在讨论你不应该关心哪些类型的工具和流程之前,让我们采取更积极主动的方式,专注于真正能带来改变的事情。

合适的团队

你需要一支能够自我管理、具备自动化基础设施相关任务专业知识、并且乐于在灵活而非过于标准化的组织架构中工作的团队。他们应该能够提出变更建议,并在需要时予以实施。

寻找和验证原发性骨髓纤维化(PMF)。

到了A轮融资阶段,你肯定已经嗅到了产品市场契合度(PMF)的气息。不要松懈,快速发布产品,并与目标受众密切沟通,验证你的市场假设。仅仅发现市场空白是不够的,你必须填补它。保持开发速度,不断扩大你所发现的市场空白。

保持敏捷性和灵活性

与公司内所有团队一样,工程团队也应明确地朝着一个主要目标努力:助力业务发展。工程团队处于一个紧密而高效的反馈循环的核心,该循环涵盖销售、功能构思、功能开发、部署和反馈收集等环节。理想情况下,销售团队全力以赴,客户服务团队与客户保持密切联系。为了履行其职责,工程团队必须保持灵活敏捷,随时准备快速响应其他团队的反馈。

图2

只专注于面向客户的产品

尽管我们之前已经提到过,但还是要强调,身份提供商 (IDP) 是一个功能齐全的产品,需要不断创建、维护和演进,以满足内部开发人员不断变化的需求。专注于这类内部产品可能会分散您对面向客户的产品的关注和资源,而这些面向客户的产品最终会让您更接近产品市场契合度 (PMF) 和客户满意度。

构建正确的文化

这一点不容忽视。无论公司处于哪个发展阶段,演进始终是一个动态的过程。目标一致的文化、健康的沟通原则以及对共同目标的关注,是构建架构、工具和流程定义等讨论的基础,而这些讨论又能推动演进。只有建立起真正意义上的共同文化,才能实现集体的认同。

A轮融资的CTO不应该考虑什么?

人们常常会说,从糟糕的管理者身上学到的东西比从优秀的管理者身上学到的东西更多。这是为什么呢?因为知道什么不该做,有时比知道什么该做更重要。

不要维护内部产品

任何没有及时处理产品和销售团队以及客户请求的时间都是浪费时间。

任何与提供比竞争对手更好的体验无关的时间投入都是错误的。

避免组建大型工程团队

公司其他部门在发展并不意味着工程团队也必须以同样的速度扩张。那些赞扬保持工程团队规模精简能够带来巨大效益的人,他们的观点不无道理。

在这个阶段,当你可能正在引进你的第一批 DevOps 工程师时,要确保他们融入一个精简的、以开发人员为中心的团队,并由一位领导者领导,以避免不必要的管理层级,从而实现开放的沟通和快速的决策。

别追求完美。

快速发布产品并持续改进是打造最终赢得市场份额并满足客户期望的产品的最佳途径,这一点您应该很清楚。那么,扩展工程团队的规模又怎会例外呢?过早地尝试构建内部开发者平台恰恰违背了这些原则。虽然将来您肯定会构建这样一个平台,但请让这个过程循序渐进地进行。在此期间,您还有其他更重要的事情需要关注。

你走对了路。

完成A轮融资并非任何人的最终目标,你们还有很大的发展空间。产品市场契合度(PMF)很可能尚未完全确定,偶尔出现的技术瓶颈也需要逐个案例进行解决。现在正是巩固优势、不断提升客户识别能力和用户满意度的最佳时机。

将来或许会有机会审视内部并改进内部工程流程,IDP 也可能在未来发挥作用,但就目前而言,你有限的工程产出应该集中精力保持精益化。

过早推出无法直接推动业务发展的内部产品,可能会造成严重后果。大约35%的A轮融资初创公司会在B轮融资前倒闭,这其中利害攸关。

不过不用担心,你已经走到这一步了,不要因为害怕错过平台工程的机会而放弃,埋头苦干,继续做你一直在做的事情,因为它是有效的。

我们很想听听您的想法,您认为一个组织在什么情况下才真正准备好制定内部发展计划(IDP)?


如果您喜欢我们的内容并想支持我们完成这项使命,我们非常感谢您能在GitHub上给我们一颗星 ⭐️ 。

吉夫

⭐️ 在 GitHub 上给我们点个星 🙏

文章来源:https://dev.to/glasskube/why-building-an-idp-for-series-a-companies-doesnt-make-sense-36d4