聊聊IPD技术开发体系的技术标准制定效果

前几天有个朋友问我，你们做技术开发的，怎么判断一个体系好不好使？这个问题让我想了很久。要我说啊，判断一套技术开发体系行不行，最直观的方式就是看它技术标准制定这件事做得怎么样。你想啊，一个团队如果连标准都定不清楚，后面各种乱象肯定接踵而至。今天我就结合自己在薄云的一些实际经历，跟大家唠唠IPD技术开发体系中技术标准制定这个话题。

说真的，我刚接触IPD的时候也是一脸懵的。什么阶段门、什么DCP、什么TR评审，一堆术语砸过来，确实有点招架不住。但后来慢慢摸索清楚了，才发现这套体系最核心的价值之一，就是它把技术标准制定这件事给系统化、规范化了。这不是简单写几个文档那么简单，而是一套完整的游戏规则。

什么是IPD里的技术标准制定？

在解释效果之前，我觉得有必要先搞清楚一个基本概念。很多人以为技术标准就是写文档、做规范，这个理解其实只说对了一半。在IPD框架下，技术标准制定是一个动态的、贯穿整个产品开发过程的活动，而不是某个阶段一次性完成的任务。

IPD强调"做正确的事"和"正确地做事"分开来。技术标准制定解决的就是"正确地做事"这个问题。它包括了我们要在哪个阶段制定什么标准、标准的颗粒度要有多细、谁来评审这个标准合不合格、标准定出来之后怎么落实下去等等一连串的问题。

薄云在实践过程中慢慢形成了一套自己的理解。我们把技术标准制定拆成了三个层次：架构级标准、模块级标准和细节级标准。架构级标准定方向，模块级标准定接口，细节级标准定实现。这三层相互配合，才能把技术标准这张网给织完整了。

标准制定带来的第一个明显效果：减少重复造轮子

说起这个，我想起我们团队早年的一段经历。那时候没有统一的技术标准，每个项目组做功能都是各自为政。就拿用户登录这个功能来说吧，A项目组做了一个，B项目组觉得不好用又做了一个，C项目组听说之后也自己搞了一个。三个登录模块长得差不多，但实现逻辑完全不一样，维护起来简直是一场噩梦。

后来我们引入了IPD的技术标准制定流程，第一件事就是梳理共性需求，制定统一的技术标准规范。这个规范明确规定了用户认证模块必须采用什么协议、密码存储要用什么算法、会话管理要怎么处理等等。标准定下来之后，新项目如果需要用户登录功能，直接复用现有的标准模块就行，不用从零开始写代码。

你别说，这个改变带来的效果立竿见影。据统计，光是登录模块这一项，我们后来的项目平均节省了两到三周的开发时间。更重要的是，后期的维护成本大幅下降，因为大家都在用同一套标准，出问题的时候定位和修复都更高效。

标准制定的第二个效果：让跨团队协作更顺畅

这一点我感触特别深。在技术开发中，跨团队协作绝对是最让人头疼的事情之一。你这边接口改了一点，那边系统可能就崩了。大家沟通靠嘴，文档不及时更新，到最后谁也说不清楚到底哪个版本才是对的。

薄云在推行IPD的过程中，专门针对跨团队协作制定了接口标准规范。这套规范详细规定了团队之间交互的接口应该怎么定义、版本号怎么管理、变更流程怎么走。表面上看是多了很多流程，但实际上正是这些流程保障了协作的顺畅。

举个具体的例子吧。我们有个基础设施团队和业务开发团队，以前经常因为接口问题扯皮。业务团队说基础设施提供的SDK不好用，基础设施团队说业务团队没有按规范使用。后来我们制定了明确的接口标准，包括方法命名规则、参数校验逻辑、错误码定义、返回值格式等等，全部写得清清楚楚。

标准定下来之后，两边都按规矩来，沟通成本明显下降。业务团队不再抱怨SDK难用，因为标准化的接口用起来确实顺滑。基础设施团队也不再头疼业务方的各种"特殊需求"，因为标准已经覆盖了绝大多数场景，特殊需求走变更流程就行。

这个表格里的数据都是我们实际统计出来的，虽然不是特别精确，但趋势是非常明显的。标准制定让跨团队协作从"扯皮"变成了"按规矩办事"，效率提升不是一星半点。

标准制定的第三个效果：提升技术决策的质量

这一点可能不是那么直观，但我觉得恰恰是最重要的。技术开发中最难的是什么？不是写代码，而是做决策。选用什么技术栈、采用什么架构模式、如何平衡短期效率和长期可维护性，这些都是需要谨慎决策的问题。

在没有标准的时候，技术决策往往很"随意"。某个技术负责人觉得某个技术好，于是就用了。也不管这个技术适不适合当前团队的实际情况，反正先用起来再说。这种决策方式风险很高，选错了技术栈，后面想要改，成本是巨大的。

IPD的技术标准制定流程里面，有一个很重要的环节叫做技术选型标准。这不是说限制大家用什么技术，而是规定了在选型的时候必须考虑哪些因素、要经过什么样的评审流程、文档记录有什么要求。

薄云的技术选型标准里明确规定，任何引入的新技术必须从成熟度、社区活跃度、学习成本、与现有体系的兼容性四个维度进行评估。每个维度都有明确的打分规则，最后综合得分达到一定门槛才能引入。这套标准执行下来，我们发现技术决策的"随意性"大大降低，决策质量明显提升。

有个小插曲我记得特别清楚。去年有个团队想引入一个新的开发框架，说得天花乱坠，又是性能提升又是开发效率翻倍。按照以前的标准，可能就直接用了。但按照新的技术选型标准，我们进行了详细评估，发现这个框架虽然宣传得很好，但社区活跃度一般，国内使用者很少，真出了问题很难找到解决方案。最终我们没有引入这个框架，事后证明这个决定是正确的，因为三个月后这个框架的开发者就宣布停止维护了。

标准制定的第四个效果：降低人员流动带来的风险

技术人员流动是每个公司都要面对的问题。有些公司特别怕人员流动，因为一旦核心人员离开，很多东西就没人懂了，项目马上陷入困境。这种情况我们称之为"技术黑盒"，也就是某些技术实现只有某个人清楚怎么回事，其他人根本摸不着头脑。

技术标准制定某种程度上就是为了解决这个问题。当标准足够清晰、文档足够完善的时候，某个人的离开不会造成致命的打击。因为标准文档就摆在那里，新来的同事按照标准做就能把事情做对。当然，完全消除人员流动的影响是不可能的，但至少可以把影响降到最低。

薄云在这方面的实践是推行"标准即文档"的理念。我们要求所有的技术标准不仅要说明"是什么"，还要解释"为什么"。这个"为什么"特别重要，它让后来者能够理解当时做这个决策的背景和考量，而不是机械地执行。

举个例子，我们有一个分布式缓存的使用标准，其中规定缓存键必须包含业务标识、过期时间等信息。当初制定这个标准的时候，我们在文档里详细记录了因为键命名不规范导致过的几次事故，以及最终确定这个命名规范的讨论过程。后来有新同事看到这个标准，不仅知道要怎么做，还理解了为什么要这么做，执行起来自然更加到位。

标准制定的第五个效果：为技术演进提供基础

技术是在不断发展的，今天的先进技术可能几年后就被淘汰了。那么问题来了，当我们想要升级技术栈或者重构系统的时候，怎么保证这个过程是有序的而不是混乱的？

我觉得这个问题要反过来想。如果一开始就没有清晰的技术标准，技术演进会变成一件极其困难的事情。因为你没有基准点，不知道哪些是需要改的、哪些是可以保留的，一切都只能凭经验判断。而有了完整的技术标准，情况就完全不同了，你可以清楚地看到现有系统的技术边界在哪里，演进的目标是什么，需要分几步走。

薄云去年做了一次技术栈升级，从某种角度来看还比较顺利。为什么能比较顺利？因为我们有完整的技术标准体系。我们先梳理出现有系统的技术标准，然后对比目标技术的要求，找出差距，制定升级方案。整个过程有条不紊，并没有出现手忙脚乱的情况。

当然，升级过程中也遇到了一些问题。比如旧标准里有些规定已经不适应新技术的特点了，需要修改标准。这正好说明了技术标准不是一成不变的，而是需要持续迭代的。IPD的持续改进理念在这一点上体现得淋漓尽致。

标准制定过程中遇到的挑战

说了这么多标准制定的好处，我也想说说在实际操作中遇到的挑战。不是什么都是一帆风顺的，过程中确实有一些问题需要面对。

第一个挑战是标准的平衡问题。标准定得太细，会限制开发人员的灵活性，大家觉得绑手绑脚；标准定得太粗，又起不到应有的作用，形同虚设。这个平衡点很难找，薄云也是摸索了很久才慢慢找到感觉。我们的经验是先粗后细，先定大方向，再逐步细化。细化过程中还要不断收集反馈，看看哪些规定大家接受度高，哪些规定执行起来有困难。

第二个挑战是标准的更新问题。技术发展很快，标准很容易就过时了。如果标准更新不及时，大家就会选择性地忽视它，因为按照旧标准做事可能还没按照新情况做来得高效。薄云现在的做法是每半年对技术标准进行一次全面评审，看看哪些需要更新。但这个频率是不是最优的，我们还在探索。

第三个挑战是标准的执行问题。最理想的情况是标准制定出来，大家都自觉遵守。但现实往往不是这样，总有人觉得标准麻烦，想走捷径。针对这个问题，我们采取了一些强制措施，比如代码评审的时候必须检查是否符合标准，不符合标准的代码不能合并进入主分支。时间长了，大家也就养成习惯了。

一些个人的思考

聊了这么多，最后说说我自己的一些思考吧。

技术标准制定这事儿，说到底是一种取舍的艺术。你想要规范性，就要牺牲一定的灵活性；你想要效率，就要接受一定的约束。没有完美的标准，只有适合当下情况的标准。

薄云在IPD技术开发体系中的实践，让我深刻体会到标准制定不是一劳永逸的事情，而是一个持续优化的过程。标准制定出来只是开始，更重要的是在实践中不断检验它、改进它、完善它。

有时候我会想，技术标准存在的意义到底是什么？我觉得，技术标准存在的意义，就是让优秀的技术实践能够沉淀下来、传播开来、传承下去。不至于说一个很有经验的工程师离职了，他那些宝贵的经验也跟着消失了。标准把这些经验变成了可复制的知识资产，这对任何一个技术团队来说都是极其重要的财富。

好了，今天就聊到这里。技术标准制定这个话题很大，我能说的也只是自己的一些粗浅经验。如果大家有什么想法或者问题，欢迎一起交流探讨。