<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Collaboration · 仁才德</title>
    <link>https://jared.lynskey.co.nz/zh-cn/tags/collaboration/</link>
    <description>关于软件工程与研发团队领导力的短文——绩效评估、招聘与团队扩张、CI/CD、DevOps 监控、智能体 AI。写于首尔。</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <copyright>© 2026 仁才德</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/zh-cn/tags/collaboration/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>真正落地的技术团队规范怎么定</title>
      <link>https://jared.lynskey.co.nz/zh-cn/posts/2024/2024-05-05-team-norms/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/zh-cn/posts/2024/2024-05-05-team-norms/</guid>
      <pubDate>Sun, 05 May 2024 00:00:00 +0000</pubDate>
      <dc:creator>Me</dc:creator>
      <category>team norms</category>
      <category>collaboration</category>
      <category>leadership</category>
      <description>当上工程经理几个月后，关于技术团队规范的一些思考，还有那项让我相信规范比天赋更重要的 Google 研究（Project Aristotle）。</description>
      <content:encoded><![CDATA[<p>带开发团队几个月，我发现每天要处理的摩擦大多不是技术问题，而是大家对一些没说出口的默契各有各的理解：代码评审多久该回、“完成”到底算到哪一步、在 Slack 上催第二次算不算失礼。谁都没错，只是我们从来没把规则讲清楚。</p>
<p>解决办法有个很无聊的名字：团队规范。<a href="https://www.ccl.org/articles/leading-effectively-articles/the-real-world-guide-to-team-norms/"  target="_blank" rel="noreferrer">Center for Creative Leadership</a> 的定义是“一套塑造团队成员互动方式的规则或运作原则”。听起来像 HR 的表格，其实就是把大家以为不言自明的东西写下来。</p>

<h2 class="relative group">说服我的那项研究
    <div id="说服我的那项研究" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e8%af%b4%e6%9c%8d%e6%88%91%e7%9a%84%e9%82%a3%e9%a1%b9%e7%a0%94%e7%a9%b6" aria-label="锚点">#</a>
    </span>
    
</h2>
<p><a href="https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness"  target="_blank" rel="noreferrer">Google 的 Project Aristotle</a> 研究了公司内部 180 多个团队，想弄清楚好团队到底好在哪。答案出乎意料：团队里有谁，远不如团队怎么协作重要。就算凑齐一屋子高手，要是协作方式一团糟，结果照样平庸。</p>
<p>研究找出了区分强团队的<a href="https://psychsafety.com/googles-project-aristotle/"  target="_blank" rel="noreferrer">五个要素</a>：心理安全感、可靠性、结构与清晰度、意义感、影响力。其中作用最大的是心理安全感——敢问蠢问题、敢承认错误，而且不用为此付出代价。<a href="https://www.leaderfactor.com/learn/project-aristotle-psychological-safety"  target="_blank" rel="noreferrer">相关的数字</a>很难让人无视：解释了 43% 的绩效差异，生产力高 19%，创新多 31%，离职率低 27%。</p>
<p>我最喜欢这份清单的一点是：五个要素没有一个是天生的性格，全都是团队可以刻意建设的东西。而规范就是建设它们的工具。</p>

<h2 class="relative group">日常里的规范长什么样
    <div id="日常里的规范长什么样" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%97%a5%e5%b8%b8%e9%87%8c%e7%9a%84%e8%a7%84%e8%8c%83%e9%95%bf%e4%bb%80%e4%b9%88%e6%a0%b7" aria-label="锚点">#</a>
    </span>
    
</h2>
<p>从会议入手最容易，因为坏习惯最显眼：议程提前发，准点开始准点结束，反驳之前先复述对方的观点。我很喜欢那条不留情面的规则：<a href="https://www.ntaskmanager.com/blog/12-examples-of-team-norms-to-help-you-create-a-high-performing-team/"  target="_blank" rel="noreferrer">没有议程就不开会</a>。</p>
<p>沟通规范更重要，但更难被看见。我的原则归结起来就是：宁可多说也别少说，决策写在所有人都找得到的地方，别让会议成为唯一的渠道。八个人的会上总有人一句话不说，那就直接去问他们。<a href="https://www.focuspeople.com/2024/02/23/building-high-performing-teams-x-strategies-for-success/"  target="_blank" rel="noreferrer">视角多元的团队</a>胜过同质化团队的证据很多，但前提是那些视角真的被说出来了。</p>
<p>至于分歧：先假设对方是好意，跟问题吵而不是跟人吵，去挖对方真正需要什么，而不是纠缠他摆出来的立场。极少数吵不完的架，就请中立的第三方来。</p>

<h2 class="relative group">怎么定规范才不变成官僚主义
    <div id="怎么定规范才不变成官僚主义" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e6%80%8e%e4%b9%88%e5%ae%9a%e8%a7%84%e8%8c%83%e6%89%8d%e4%b8%8d%e5%8f%98%e6%88%90%e5%ae%98%e5%83%9a%e4%b8%bb%e4%b9%89" aria-label="锚点">#</a>
    </span>
    
</h2>
<p>我认可 <a href="https://www.ccl.org/articles/leading-effectively-articles/the-real-world-guide-to-team-norms/"  target="_blank" rel="noreferrer">CCL 推荐的</a>做法：从经验出发，而不是从理论出发。每个人讲讲自己待过的最好和最差的团队，一起挖为什么会那样，再把浮现出来的模式变成针对这个团队的具体行为——讨论出来、达成一致，而不是自上而下发文件。事先说好有人违反了怎么办（包括经理违反的时候），写在显眼的地方，隔段时间回头看看。</p>
<p>我只想补充一条：一开始只定三到五条。规范要变成习惯才起作用，没人能同时养成十个习惯。</p>

<h2 class="relative group">容易垮掉的地方
    <div id="容易垮掉的地方" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#%e5%ae%b9%e6%98%93%e5%9e%ae%e6%8e%89%e7%9a%84%e5%9c%b0%e6%96%b9" aria-label="锚点">#</a>
    </span>
    
</h2>
<p>杀死规范最快的方式，是无视规范的领导。如果我以“太忙”为由跳过议程规则，团队马上就能看穿，整件事立刻变成表演。负责人的言行一致，比任何一条规范的措辞都重要。</p>
<p>另外几个我留意的坑：新人靠口口相传“领悟”规范，而不是在入职时被明确告知；全球化团队把自己的默认当成所有人的默认（把隐含的假设讲明白）；还有把整件事当成走过场的人——对付这种情况，最有效的不是说教，而是拉他们一起来写规范。</p>
<p>知道规范在哪里被强化也很有用。对高绩效团队的研究<a href="https://informedi.org/2024/08/30/new-rules-for-teamwork/"  target="_blank" rel="noreferrer">反复发现同样三个习惯</a>：像样的启动会、定期的一对一、还有回顾会。共识是在这些场合里形成、被检验、悄悄更新的，不是在制度文档里。</p>
<p>我不觉得规范是魔法。但 Google 的数据和我目前的体会指向同一个方向：团队怎么协作，胜过团队里有谁。所以我们的规范会保持简短——几条共识，写在所有人看得见的地方，不符合现实了就改。至于有没有真的落地，半年后再问我吧。</p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2024/2024-05-05-team-norms/featured.jpg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
