https://cygnusyang.github.io/collections/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/技术 × 产品 × 机器人Hugo 0.160.1 & FixIt v0.4.6-20260517062719-ed8ec5c2zh-CNruohuyang@163.com (Cygnus Yang)ruohuyang@163.com (Cygnus Yang)Sat, 23 May 2026 00:00:00 +0800https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/00-%E6%80%BB%E7%BA%B2/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E5%BA%95%E5%B1%82%E9%80%BB%E8%BE%91/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/00-%E6%80%BB%E7%BA%B2/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E5%BA%95%E5%B1%82%E9%80%BB%E8%BE%91/<p>如果说研发的本质是把不确定性问题，通过探索、验证和工程实现，逐步转化为可靠能力，那么研发绩效要回答的是另一个更根本的问题：</p> <p><strong>什么样的研发工作，应该被认为是高绩效？</strong></p> <p>这件事不能简单等同于“交付多”“上线快”“没有延期”。这些当然重要，但它们只是表层结果。研发绩效真正难评价，是因为研发工作经常处在不确定性里：问题不确定、路径不确定、依赖不确定、结果滞后、风险隐藏。</p> <p>所以，研发绩效的本质不是单纯评价结果，而是评价团队在不确定性中管理方向、节奏、风险和长期能力的能力。</p> <h2 class="heading-element" id="一句话总纲"><span>一句话总纲</span> <a href="#%e4%b8%80%e5%8f%a5%e8%af%9d%e6%80%bb%e7%ba%b2" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p><strong>研发绩效 = 方向正确性 × 推进节奏 × 风险控制能力 × 长期能力。</strong></p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/01-kpi%E4%B8%8E%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88/02-kpi%E4%B8%8E%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E5%85%B3%E7%B3%BB/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/01-kpi%E4%B8%8E%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88/02-kpi%E4%B8%8E%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E5%85%B3%E7%B3%BB/<p>讨论 KPI 和研发绩效的关系之前，要先回答一个更基础的问题：</p> <p><strong>研发到底是什么？</strong></p> <p>如果把研发理解成“接需求、写代码、按期上线”，那 KPI 似乎天然适合研发管理：需求按期交付率、缺陷数、代码行数、工时利用率、上线次数、版本达成率，都可以被量化。</p> <p>但这个理解太窄了。</p> <p>研发并不是简单的任务执行。更准确地说：</p> <p><strong>研发是把不确定性问题，通过科学验证、工程方法和系统实现，逐步转化为可交付、可复用、可规模化能力的过程。</strong></p> <p>这里面至少包含三个环节：</p> <table> <thead> <tr> <th>环节</th> <th>解决的问题</th> <th>典型活动</th> </tr> </thead> <tbody> <tr> <td>探索</td> <td>问题和方向是否成立</td> <td>识别问题、提出假设、寻找路径</td> </tr> <tr> <td>验证</td> <td>方案是否可行</td> <td>原型、实验、测试、评审、数据验证</td> </tr> <tr> <td>实现</td> <td>能力是否可靠交付</td> <td>工程开发、质量保障、上线、沉淀复用</td> </tr> </tbody> </table> <p>写代码只是其中的实现环节。研发真正的价值，很多时候发生在更早的探索和验证阶段。</p> <p>这也是 KPI 和研发之间产生张力的根源：<strong>KPI 通常是提前制定的，而探索和创新的价值，往往是在过程中逐渐显现的。</strong></p> <p>提前制定的 KPI 更擅长衡量确定性执行，却很难完整反映探索和创新两类工作：</p> <ol> <li>探索阶段，目标本身可能还需要被重新定义；</li> <li>创新过程，技术路线可能需要反复试错；</li> <li>关键价值，可能来自一次突破，而不是稳定产出数量；</li> <li>重要结论，可能是证明某条路线不成立，从而避免更大浪费。</li> </ol> <p>所以，讨论研发绩效时，如果直接从 KPI 开始，就会把问题带偏。</p> <p>因为 KPI 不是研发绩效本身。KPI 只是绩效体系中的一种表达形式，是用来观察和校准的指标，而不是用来替代判断的答案。</p> <h2 class="heading-element" id="一个基本判断"><span>一个基本判断</span> <a href="#%e4%b8%80%e4%b8%aa%e5%9f%ba%e6%9c%ac%e5%88%a4%e6%96%ad" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p><strong>KPI 不等于研发绩效。</strong></p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/02-%E5%88%9B%E6%96%B0%E6%8E%A2%E7%B4%A2/03-%E5%A6%82%E4%BD%95%E5%81%9A%E5%88%9B%E6%96%B0%E6%8E%A2%E7%B4%A2/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/02-%E5%88%9B%E6%96%B0%E6%8E%A2%E7%B4%A2/03-%E5%A6%82%E4%BD%95%E5%81%9A%E5%88%9B%E6%96%B0%E6%8E%A2%E7%B4%A2/<p>创新探索不是“想点新东西”，也不是“做一个 Demo”。从研发绩效角度看，创新探索要解决的是：</p> <p><strong>在目标和路径都不确定时，如何用最小成本找到可能成立的方向。</strong></p> <p>因此，创新探索不是没有管理，而是要用不同于确定性交付的方式管理。</p> <h2 class="heading-element" id="创新探索的本质"><span>创新探索的本质</span> <a href="#%e5%88%9b%e6%96%b0%e6%8e%a2%e7%b4%a2%e7%9a%84%e6%9c%ac%e8%b4%a8" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>创新探索至少包含三类工作：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/03-%E5%B7%A5%E7%A8%8B%E4%BA%A4%E4%BB%98/04-%E5%A6%82%E4%BD%95%E5%81%9A%E5%B7%A5%E7%A8%8B%E4%BA%A4%E4%BB%98/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/03-%E5%B7%A5%E7%A8%8B%E4%BA%A4%E4%BB%98/04-%E5%A6%82%E4%BD%95%E5%81%9A%E5%B7%A5%E7%A8%8B%E4%BA%A4%E4%BB%98/<p>创新探索解决的是“方向是否成立”，工程交付解决的是“方案能不能可靠落地”。</p> <p>很多研发绩效问题，并不是团队不会探索，而是探索之后无法稳定交付。Demo 能跑，产品不能用；功能能上线，质量不可控；项目能完成，后续维护成本很高。</p> <p>所以，工程交付不是简单地“把功能做完”，而是：</p> <p><strong>把经过验证的方案，做成可靠、可维护、可复用、可规模化的系统能力。</strong></p> <h2 class="heading-element" id="工程交付的核心问题"><span>工程交付的核心问题</span> <a href="#%e5%b7%a5%e7%a8%8b%e4%ba%a4%e4%bb%98%e7%9a%84%e6%a0%b8%e5%bf%83%e9%97%ae%e9%a2%98" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>工程交付至少要回答五个问题：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/04-%E4%BC%81%E4%B8%9A%E7%B1%BB%E5%9E%8B%E4%B8%8E%E5%88%9D%E5%88%9B%E5%9B%A2%E9%98%9F/05-%E5%88%9D%E5%88%9B%E5%9B%A2%E9%98%9F%E5%A6%82%E4%BD%95%E8%AE%BE%E8%AE%A1%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/04-%E4%BC%81%E4%B8%9A%E7%B1%BB%E5%9E%8B%E4%B8%8E%E5%88%9D%E5%88%9B%E5%9B%A2%E9%98%9F/05-%E5%88%9D%E5%88%9B%E5%9B%A2%E9%98%9F%E5%A6%82%E4%BD%95%E8%AE%BE%E8%AE%A1%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88/<p>前面几篇讨论的是 KPI、研发绩效和方法论。但如果真正落到企业实践，会遇到一个更现实的问题：</p> <p><strong>不同价值创造方式，绩效管理逻辑是不一样的。</strong></p> <p>确定性运营、探索性创新、以及两者并存的双元混合，对绩效的要求并不相同。如果不区分价值创造方式，直接套用某一家大公司的绩效制度，很容易把团队带偏。</p> <p>尤其是初创团队，更不能简单照搬大厂。大厂的绩效体系往往是在组织规模、业务成熟度、管理层级和人才密度都已经发展到一定阶段后形成的。初创团队如果过早引入复杂考核、强制分布、重流程和重汇报，反而会削弱最重要的东西：方向判断、快速验证、真实反馈和团队战斗力。</p> <h2 class="heading-element" id="先区分三种价值创造方式"><span>先区分三种价值创造方式</span> <a href="#%e5%85%88%e5%8c%ba%e5%88%86%e4%b8%89%e7%a7%8d%e4%bb%b7%e5%80%bc%e5%88%9b%e9%80%a0%e6%96%b9%e5%bc%8f" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>从绩效管理角度，与其说企业可以被绝对分成几类，不如说不同业务、不同阶段有不同的主导价值创造方式。</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/06-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E6%96%B9%E6%B3%95%E8%AE%BA/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/06-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E6%96%B9%E6%B3%95%E8%AE%BA/<p>前面两篇分别讨论了 KPI 与研发绩效的关系，以及研发绩效的底层逻辑。核心前提是：研发不是简单任务执行，而是把不确定性问题通过探索、验证和工程实现转化为可靠能力。</p> <p>接下来要回答的是：如果要在组织里真正落地，应该怎么设计一套研发绩效体系？</p> <p>一个可用的研发绩效方法论，不能只是一张指标表。它至少要解决五个问题：</p> <ol> <li>当前研发工作处在哪个阶段；</li> <li>这个阶段应该评价什么；</li> <li>用什么证据评价；</li> <li>如何设计 KPI；</li> <li>如何把评价结果用于奖惩和改进。</li> </ol> <h2 class="heading-element" id="step-1先判断阶段"><span>Step 1：先判断阶段</span> <a href="#step-1%e5%85%88%e5%88%a4%e6%96%ad%e9%98%b6%e6%ae%b5" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>研发绩效设计的第一步，不是选 KPI，而是判断阶段。</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/07-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E7%AE%A1%E7%90%86%E6%A1%86%E6%9E%B6%E4%B8%80%E9%A1%B5%E7%BA%B8/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/07-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E7%AE%A1%E7%90%86%E6%A1%86%E6%9E%B6%E4%B8%80%E9%A1%B5%E7%BA%B8/<p>这一页用于把前面几篇文章压缩成一个管理框架。它不是完整论证，而是方便讨论、评审和对齐。</p> <h2 class="heading-element" id="1-总体框架"><span>1. 总体框架</span> <a href="#1-%e6%80%bb%e4%bd%93%e6%a1%86%e6%9e%b6" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><pre><code>graph TD A[目标层&lt;br/&gt;我们要解决什么问题？&lt;br/&gt;业务问题 / 用户问题 / 技术问题 / 组织问题] --&gt; B[阶段层&lt;br/&gt;当前研发工作处在哪个不确定性阶段？&lt;br/&gt;0-&gt;1 探索 / 1-&gt;10 验证 / 1-&gt;100 规模化] B --&gt; C[绩效层&lt;br/&gt;方向正确性 × 推进节奏 × 风险控制 × 长期能力] C --&gt; C1[验证&lt;br/&gt;控方向] C --&gt; C2[里程碑&lt;br/&gt;控节奏] C --&gt; C3[质量&lt;br/&gt;控风险] C --&gt; C4[沉淀&lt;br/&gt;建能力] C1 --&gt; D[证据层&lt;br/&gt;数据指标 / 技术评审 / 验证结论 / 风险清单 / 复盘记录] C2 --&gt; D C3 --&gt; D C4 --&gt; D D --&gt; E[KPI 层&lt;br/&gt;观测工具，不是控制工具] style A fill:#e1f5ff style B fill:#fff4e1 style C fill:#f0e1ff style C1 fill:#ffe1f0 style C2 fill:#ffe1f0 style C3 fill:#ffe1f0 style C4 fill:#ffe1f0 style D fill:#e1ffe1 style E fill:#f5f5f5</code></pre><p>核心顺序：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/08-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E9%98%B6%E6%AE%B5%E6%80%A7%E6%80%BB%E7%BB%93/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/08-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E9%98%B6%E6%AE%B5%E6%80%A7%E6%80%BB%E7%BB%93/<p>讨论完 KPI、研发绩效逻辑和方法论之后，可以先做一个阶段性总结：真正要解决的不是“要不要 KPI”，而是“我们到底想用绩效体系驱动什么样的研发行为”。</p> <p>如果绩效体系只奖励短期完成率，团队就会倾向于选择容易完成、容易汇报、容易量化的事情。如果绩效体系只看结果成败，团队就会回避不确定性高但真正重要的问题。如果绩效体系只强调速度，质量和长期能力就会被不断透支。</p> <p>所以，KPI 不是问题，问题是我们把 KPI 用错了。</p> <h2 class="heading-element" id="核心结论"><span>核心结论</span> <a href="#%e6%a0%b8%e5%bf%83%e7%bb%93%e8%ae%ba" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p><strong>KPI 是观测工具，不是控制工具。</strong></p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/06-%E7%BB%84%E7%BB%87%E4%B8%8E%E4%BB%B7%E5%80%BC%E8%A7%82/09-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%B8%8E%E4%BB%B7%E5%80%BC%E8%A7%82/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/06-%E7%BB%84%E7%BB%87%E4%B8%8E%E4%BB%B7%E5%80%BC%E8%A7%82/09-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%B8%8E%E4%BB%B7%E5%80%BC%E8%A7%82/<p>前面几篇讨论了 KPI、研发绩效逻辑、方法论、企业类型和初创团队实践。到这里还需要补上最后一层：</p> <p><strong>价值观。</strong></p> <p>价值观看起来像一个很软的话题，但在研发绩效里，它其实是很硬的一层。因为研发工作面对大量不确定性，KPI 不可能提前定义所有正确行为，流程也不可能覆盖所有复杂判断。</p> <p>当指标不够用、流程没有答案、结果还没有出现时，团队靠什么判断一件事该不该做、该怎么做、做到什么程度？</p> <p>答案就是价值观。</p> <h2 class="heading-element" id="为什么价值观重要"><span>为什么价值观重要</span> <a href="#%e4%b8%ba%e4%bb%80%e4%b9%88%e4%bb%b7%e5%80%bc%e8%a7%82%e9%87%8d%e8%a6%81" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>在研发绩效体系里，KPI 和价值观解决的是两个不同问题。</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/10-%E5%8F%8C%E8%BD%A8%E7%AE%A1%E7%90%86%E4%B8%8E%E5%88%9B%E6%96%B0%E5%BE%AA%E7%8E%AF/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/10-%E5%8F%8C%E8%BD%A8%E7%AE%A1%E7%90%86%E4%B8%8E%E5%88%9B%E6%96%B0%E5%BE%AA%E7%8E%AF/<p>前面的体系讨论了 0-&gt;1、1-&gt;10、1-&gt;100 的线性过程，但真实的产品生命周期往往不是线性的，而是循环的：</p> <pre><code>0-&gt;1（探索）→ 1-&gt;10（验证）→ 1-&gt;100（规模化）→ 新的 0-&gt;1（下一代探索）</code></pre><p>当一个业务进入规模化阶段后，如何启动新一轮创新？如何同时管理成熟业务和新业务？这就是双轨管理要解决的问题。</p> <h2 class="heading-element" id="为什么需要双轨管理"><span>为什么需要双轨管理</span> <a href="#%e4%b8%ba%e4%bb%80%e4%b9%88%e9%9c%80%e8%a6%81%e5%8f%8c%e8%bd%a8%e7%ae%a1%e7%90%86" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>规模化成功后，组织很容易陷入一种状态：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/11-%E6%8A%80%E6%9C%AF%E5%80%BA%E5%8A%A1%E9%87%8F%E5%8C%96%E7%AE%A1%E7%90%86/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/11-%E6%8A%80%E6%9C%AF%E5%80%BA%E5%8A%A1%E9%87%8F%E5%8C%96%E7%AE%A1%E7%90%86/<p>技术债务不是一个新话题，但在研发绩效体系里，它经常被忽视或简化。前面的体系提到了技术债要被看见、被记录、被评估、被偿还，但缺少具体的操作方法。</p> <p>这一章我们讨论：如何量化技术债？如何管理偿还计划？如何让技术债进入绩效评价？</p> <h2 class="heading-element" id="技术债务的本质"><span>技术债务的本质</span> <a href="#%e6%8a%80%e6%9c%af%e5%80%ba%e5%8a%a1%e7%9a%84%e6%9c%ac%e8%b4%a8" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>技术债务不是&quot;代码写得不好&quot;这么简单。更准确地说：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/12-%E4%B8%8D%E5%90%8C%E5%9B%A2%E9%98%9F%E7%B1%BB%E5%9E%8B%E7%9A%84%E7%BB%A9%E6%95%88%E6%9D%83%E9%87%8D/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/12-%E4%B8%8D%E5%90%8C%E5%9B%A2%E9%98%9F%E7%B1%BB%E5%9E%8B%E7%9A%84%E7%BB%A9%E6%95%88%E6%9D%83%E9%87%8D/<p>前面的体系建立了通用的四维绩效结构（验证、里程碑、质量、沉淀），但不同类型的研发团队，工作性质差异很大，不能用完全一样的权重。</p> <p>这一章我们讨论：如何为算法团队、工程团队、平台团队、硬件团队等不同类型的团队设计差异化的绩效评价方式。</p> <h2 class="heading-element" id="为什么需要差异化"><span>为什么需要差异化</span> <a href="#%e4%b8%ba%e4%bb%80%e4%b9%88%e9%9c%80%e8%a6%81%e5%b7%ae%e5%bc%82%e5%8c%96" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>不同团队做的事情不一样，评价重点自然也不一样：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/13-%E5%9B%A2%E9%98%9F%E7%BB%A9%E6%95%88%E5%88%B0%E4%B8%AA%E4%BA%BA%E7%BB%A9%E6%95%88/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/13-%E5%9B%A2%E9%98%9F%E7%BB%A9%E6%95%88%E5%88%B0%E4%B8%AA%E4%BA%BA%E7%BB%A9%E6%95%88/<p>前面的体系主要讲了团队和项目的绩效，但一个实际的问题是：团队成功了，如何评价每个人的贡献？如何把团队目标拆解到个人？</p> <p>这一章我们讨论：团队绩效和个人绩效的关系、如何识别不同类型的贡献、如何避免搭便车、如何给个人提供反馈。</p> <h2 class="heading-element" id="团队绩效与个人绩效的关系"><span>团队绩效与个人绩效的关系</span> <a href="#%e5%9b%a2%e9%98%9f%e7%bb%a9%e6%95%88%e4%b8%8e%e4%b8%aa%e4%ba%ba%e7%bb%a9%e6%95%88%e7%9a%84%e5%85%b3%e7%b3%bb" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>首先要明确一个原则：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/14-%E5%A4%B1%E8%B4%A5%E5%88%86%E7%B1%BB%E4%B8%8E%E5%A4%8D%E7%9B%98%E6%96%B9%E6%B3%95/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/14-%E5%A4%B1%E8%B4%A5%E5%88%86%E7%B1%BB%E4%B8%8E%E5%A4%8D%E7%9B%98%E6%96%B9%E6%B3%95/<p>前面的体系多次提到：要惩罚低质量行为，而不是惩罚经过验证后的失败。但如何区分&quot;高质量失败&quot;和&quot;低质量失败&quot;？如何从失败中学习？</p> <p>这一章我们讨论：失败的分类、如何复盘失败、如何从失败中沉淀经验。</p> <h2 class="heading-element" id="失败不是洪水猛兽"><span>失败不是洪水猛兽</span> <a href="#%e5%a4%b1%e8%b4%a5%e4%b8%8d%e6%98%af%e6%b4%aa%e6%b0%b4%e7%8c%9b%e5%85%bd" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>首先要明确一个观点：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/15-%E8%B7%A8%E5%9B%A2%E9%98%9F%E5%8D%8F%E4%BD%9C%E7%BB%A9%E6%95%88/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/15-%E8%B7%A8%E5%9B%A2%E9%98%9F%E5%8D%8F%E4%BD%9C%E7%BB%A9%E6%95%88/<p>现代研发很少是单一团队能完成的，往往需要多个团队协作——前端、后端、算法、测试、产品、设计、供应链……跨团队协作已经成为常态。</p> <p>但前面的体系主要讲单一团队/项目的绩效管理，没有专门讨论跨团队协作的绩效如何设计。这一章我们补上这块内容。</p> <h2 class="heading-element" id="跨团队协作的常见问题"><span>跨团队协作的常见问题</span> <a href="#%e8%b7%a8%e5%9b%a2%e9%98%9f%e5%8d%8f%e4%bd%9c%e7%9a%84%e5%b8%b8%e8%a7%81%e9%97%ae%e9%a2%98" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>跨团队协作中，最常见的问题有：</p>https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/99-%E8%90%BD%E5%9C%B0%E9%81%BF%E5%9D%91%E6%8C%87%E5%8D%97%E4%B8%BA%E4%BB%80%E4%B9%88%E9%81%93%E7%90%86%E9%83%BD%E6%87%82%E4%BD%86%E5%81%9A%E8%B5%B7%E6%9D%A5%E6%95%88%E6%9E%9C%E5%B7%AE%E5%BE%88%E5%A4%9A/Sat, 23 May 2026 00:00:00 +0800ruohuyang@163.com (Cygnus Yang)https://cygnusyang.github.io/posts/03-%E7%A0%94%E5%8F%91%E9%82%A3%E4%BA%9B%E4%BA%8B/01-%E7%A0%94%E5%8F%91%E7%BB%A9%E6%95%88%E4%BD%93%E7%B3%BB/05-%E6%A1%86%E6%9E%B6%E4%B8%8E%E6%A8%A1%E6%9D%BF/99-%E8%90%BD%E5%9C%B0%E9%81%BF%E5%9D%91%E6%8C%87%E5%8D%97%E4%B8%BA%E4%BB%80%E4%B9%88%E9%81%93%E7%90%86%E9%83%BD%E6%87%82%E4%BD%86%E5%81%9A%E8%B5%B7%E6%9D%A5%E6%95%88%E6%9E%9C%E5%B7%AE%E5%BE%88%E5%A4%9A/<p>前面讲了完整的研发绩效方法论——从研发本质、三阶段模型、KPI 定位、价值观边界，到双轨管理、技术债管理、不同团队绩效、个人绩效、失败复盘、跨团队协作……</p> <p>但很多人会有一个疑问：<strong>&ldquo;这些道理我都懂，但为什么做起来效果千差万别？&rdquo;</strong></p> <p>这是一个非常深刻的问题。本章我们就来讨论这个话题——不是给你更多新道理，而是帮你避开落地过程中的常见坑。</p> <hr> <h2 class="heading-element" id="根本原因知道和做到之间有巨大鸿沟"><span>根本原因：&ldquo;知道&quot;和&quot;做到&quot;之间有巨大鸿沟</span> <a href="#%e6%a0%b9%e6%9c%ac%e5%8e%9f%e5%9b%a0%e7%9f%a5%e9%81%93%e5%92%8c%e5%81%9a%e5%88%b0%e4%b9%8b%e9%97%b4%e6%9c%89%e5%b7%a8%e5%a4%a7%e9%b8%bf%e6%b2%9f" class="heading-mark"> <svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path d="m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z"></path></svg> </a> </h2><p>我们可以把&quot;认知&quot;分为四层：</p>