cai

最近，我和一位朋友聊天。他提到，他们公司遇到了一个很常见的开发者生产力瓶颈：公司强制要求团队从单体架构和单体代码库迁移出去，但技术迁移进展非常缓慢。 为了加快迁移，负责基础设施的团队决定停止维护旧的单体架构，转而专注于新的服务化环境。两年后，工程师们开始陆续离职，只为避免在迁移过程中同时承受两套系统…

你经常会看到一些杂乱无章的想法被贴上“战略”的标签。即使这些文档内容很多，也往往很难读懂。这也是为什么很多工程师会说，他们所在的公司没有清晰战略。 不过，根据我的经验，所有公司其实都在遵循某种战略，只是这种战略未必被明确写成文档。对于工程管理者和技术负责人来说，真正的挑战不是“有没有战略”，而是如何…

完成战略探索之后，下一步就是进行战略诊断。所谓战略诊断，是指理解这项工程战略必须面对的限制条件、现实约束和关键挑战。尤其重要的是，在充分理解问题的细节、背景和边界之前，不要急着寻找解决方案。 如果你很想跳过诊断阶段，直接进入方案设计，那么你也许需要先意识到一点：我见过的所有失败战略，几乎都源于诊断过…

软件研发效能指标，是衡量团队交付效率、工程能力和业务价值流动的重要依据。近年来，“软件研发效能”成为行业热词，频繁出现在各类技术会议、工程管理讨论和企业实践中。许多科技企业和追求更高交付效率的团队，都在围绕研发效能建设平台、体系和方法论。 与此同时，一个核心问题仍然没有被彻底解决：什么才是合适的软件…

管理层往往热衷于各种指标。他们的想法大致是：“我们需要一个数字来衡量工作表现。数字能让大家聚焦，也能帮助我们判断是否成功。”这种初衷并没有错，但以数字为核心的管理方式，往往会诱发一些问题行为，最终损害项目和组织的整体目标。 在软件交付和敏捷管理中，指标管理尤其需要谨慎。指标本身并不是坏事，问题在于它…

过去几个月里，关于技术债务出现了一些讨论，也引发了一个问题：哪些类型的设计缺陷应该被归为技术债务，哪些不应该？对于研发团队来说，理解技术债务象限，有助于更准确地识别代码质量问题、评估重构优先级，并与非技术管理者沟通技术债务的真实成本。 一个典型观点认为，混乱的代码并不等同于技术债务。其理由是：如果混…

知识工作者的生产力很难量化，而且往往与直接业务成果脱节。缺乏这种认知，会导致组织不断发起各种所谓提升开发者生产力的举措，造成技术支出膨胀，并做出并不恰当的投资选择。技术领导者，尤其是 CTO，需要避免陷入这种困境。他们需要构建一张能够洞察工作如何影响业务的网络，将团队产出与直接影响及下游影响关联起来…

初创公司在早期阶段，会不断寻找合适的产品—市场契合点。一旦找到契合点，企业通常会转向快速增长，这一阶段也常被称为“规模化阶段”。此时，公司会在多个维度上迅速扩张：收入增长、客户数量增加、员工规模扩大，组织复杂度也随之上升。 在过往实践中，海外某些技术团队曾与许多处于规模化阶段的公司合作，重点帮助它们…

软件项目，是当前软件开发中最常见的资金投入和组织方式之一。它通常根据商业论证中预估的收益获得资金支持，并以临时团队的形式组织工作。这些团队往往只负责开发，项目结束后便随之解散。 与之不同，产品模式采用长期稳定的产品型团队。这类团队负责从构思、开发到运行的完整过程，并持续围绕某一业务问题或业务能力开展…

在软件开发项目中，人们经常会争论一个问题：时间究竟应该花在提升软件质量和代码质量上，还是应该用来发布更多有价值的功能？现实中，交付功能的压力往往占据上风。于是，许多开发者会抱怨：他们根本没有时间关注架构、内部质量和代码质量。 有一条著名的“贝特里奇标题定律”说：任何以问号结尾的标题，通常都可以用“否…