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/技术 × 产品 × 机器人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/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/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>