[Re: Work] 谷歌研究影响团队效能的5大要素，发现心理安全居然那么重要！

介绍

Google 以及许多组织中完成的大部分工作都是由团队协作完成的。团队是实际生产发生的分子单位，是构思和测试创新想法的地方，也是员工体验大部分工作的地方。但人际关系问题、不合适的技能和不明确的团队目标也会阻碍生产力并导致摩擦。

继Google 的“氧气计划”研究取得成功之后，人员分析团队研究了如何成为一名优秀的管理者，Google 研究人员应用了类似的方法来发现 Google 高效团队的秘密。代号为“亚里士多德计划”——致敬亚里士多德的名言“整体大于部分之和”（谷歌研究人员认为，员工一起工作比单独工作可以做更多的事情）——目标是回答以下问题：“什么是整体？”让团队在 Google 变得高效？”

阅读《纽约时报》了解这项工作背后的研究人员：Google 从其构建完美团队的探索中学到了什么

定义什么是“团队”

回答“什么构成高效团队？”这个问题的第一步就是问“什么是团队？”实际上弄清楚所有一起工作的个人的成员资格、关系和责任不仅仅是一种存在主义的思考练习，这很困难，但对于提高团队效率至关重要。

团队一词可以有多种含义。存在许多定义和框架，具体取决于任务的相互依赖性、组织状态和团队任期。在最基本的层面上，研究人员试图区分“工作组”和“团队”：

工作组（work group****）的特点是相互依赖性最少。它们基于组织或管理层次结构。工作组可以定期召开会议以听取和分享信息。

团队（team****）是高度相互依赖的——他们计划工作、解决问题、做出决策并审查特定项目的服务进度。团队成员需要彼此才能完成工作。

组织结构图只能说明部分情况，因此 Google 研究团队将重点放在具有真正相互依赖的工作关系的群体上，这由团队本身决定。亚里士多德计划研究的团队成员从三人到五十人不等（平均九人）。

定义“效能”（Effectiveness）

一旦了解了谷歌团队的构成，研究人员就必须确定如何定量衡量有效性。他们查看了编写的代码行数、修复的错误、客户满意度等等。但最初推动客观有效性衡量标准的谷歌领导层意识到，每一项建议的衡量标准都可能存在固有缺陷——更多的代码行不一定是好事，修复的错误越多意味着最初会产生更多的错误。

Read More

Why Do Clients and Bosses Think There’s No Result Despite Hard Work?

Today, let me introduce you to the EOOI model to improve communication and cognitive thinking.

What is the EOOI Model?

The EOOI model is an acronym that stands for:

• Effort
• Output
• Outcome
• Impact

Let’s Use Making Coffee as an Example

Today, you took out two cups, boiled a pot of water, and ground 30 coffee beans 100 times. This represents how regular employees and frontline technical staff communicate, focusing only on their work effort. Unfortunately, bosses and clients don’t recognize this—they feel you haven’t produced anything of value.

So, what did all these actions produce? A cup of drinkable coffee. This is the tangible working result, the output that your boss and clients care about. They don’t care about the intricate details, right?

Now, having a cup of coffee, what does it achieve? Drinking it helps to stay awake and alert. This is the effect behind the output. The greater result brought by the output is called the outcome.

And what value does staying awake and alert bring? Perhaps your client or boss has an important business event or meeting where they need to stay sharp. This is the larger value behind it, known as the impact.

Summary

From effort to output to outcome and then to impact, the scope of value increases, and the level of cognitive thinking elevates. Communicating in this way, how could your clients and bosses not appreciate you?

深度探索我在驾驭大语言模型（LLMs）中学到的策略

庆祝这一里程碑 — 真正的胜利在于宝贵的学习经历！

2023年11月，我非常荣幸地在新加坡政府科技局（GovTech）组织的首届 GPT-4 提示工程大赛中脱颖而出，这场比赛吸引了超过 400 名杰出的参与者。

提示工程是一门将艺术与科学巧妙融合的学科 — 它不仅关乎技术的理解，更涉及创造力和战略思考。这里分享的是我在实践中学到的一些提示工程策略，这些策略能够精准地驱动任何大语言模型为你服务，甚至做得更多！

作者的话： 在写作本文时，我特意避开了那些已经广泛讨论和记录的常规提示工程技巧。相反，我更希望分享一些我在实验中获得的新洞见，以及我个人在理解和应用这些技巧时的独到见解。希望你能从中获得乐趣！

本文涵盖以下主题，其中 🔵 代表初学者友好的技巧，而 🔴 代表高级策略：

1. 🔵 借助 CO-STAR 框架构建高效的提示
2. 🔵 利用分隔符来分节构建提示
3. 🔴 设计含有 LLM 保护机制的系统级提示
4. 🔴 仅依靠大语言模型分析数据集，无需插件或代码 — 实际案例分析 Kaggle 的真实数据集

1. 🔵 借助 CO-STAR 框架构建高效的提示

在使用大语言模型时，有效的提示构建至关重要。CO-STAR 框架，由新加坡政府科技局数据科学与 AI 团队创立，是一个实用的提示构建工具。它考虑了所有影响大语言模型响应效果和相关性的关键因素，帮助你获得更优的反馈。

CO-STAR 框架 — 作者提供的图像

如何应用 CO-STAR 框架：

• (C) 上下文：为任务提供背景信息 通过为大语言模型（LLM）提供详细的背景信息，可以帮助它精确理解讨论的具体场景，确保提供的反馈具有相关性。
• (O) 目标：明确你要求大语言模型完成的任务 清晰地界定任务目标，可以使大语言模型更专注地调整其回应，以实现这一具体目标。
• (S) 风格：明确你期望的写作风格 你可以指定一个特定的著名人物或某个行业专家的写作风格，如商业分析师或 CEO。这将指导大语言模型以一种符合你需求的方式和词汇选择进行回应。
• (T) 语气：设置回应的情感调 设定适当的语气，确保大语言模型的回应能够与预期的情感或情绪背景相协调。可能的语气包括正式、幽默、富有同情心等。
• (A) 受众：识别目标受众 针对特定受众定制大语言模型的回应，无论是领域内的专家、初学者还是儿童，都能确保内容在特定上下文中适当且容易理解。
• (R) 响应：规定输出的格式 确定输出格式是为了确保大语言模型按照你的具体需求进行输出，便于执行下游任务。常见的格式包括列表、JSON 格式的数据、专业报告等。对于大部分需要程序化处理大语言模型输出的应用来说，JSON 格式是理想的选择。

CO-STAR 框架的实用示例

这里有一个 CO-STAR 框架为何有用的现实案例。假设你担任社交媒体经理，需要草拟一条 Facebook 帖子，用以推广公司的新产品。

Read More

一、超越传统开发方式

传统的开发方式由单一专业职能团体组成，反馈环延迟甚至薄弱，使用预言性质的计划和从分析到测试流程，这在变化无常的当今世界中成效甚微。由于直到开发后期才会有真正可工作的软件，这种方式会延迟反馈、学习，以及潜在投资回报。从而导致透明度不足、改进能力缺失、灵活度减少、商业和技术风险增加。

取而代之的是跨专业职能团队与迭代开发，这种方式也存在了几十年，但并不如传统模式那样被广为使用。

Scrum把已被证实的产品开发概念打包到简单的框架中，包括:真正的团队、跨职能团队、自管理团队、短迭代全周期反馈环、降低变动成本。这些概念提升了敏捷性与反馈、使提早实现投资回报成为可能并降低风险。

二、概述

Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周(最常见的是两周)，并且无间歇地相继进行。 Sprint是受时间盒限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由 Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。在每个Sprint的初始，跨职能团队(大约7名成员)从排好优先级的列表中选择事项(客户需求)。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。在Sprint过程中不可以增加新事项，Scrum在下 一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团 队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint 中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、 完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。其中的主要角色、工件和事件如 图表1所总结。

图1 Scrum概述

Scrum中的一大主题就是“检视并调整”。因为开发工作不可避免地包含学习、创新和意外事件， Scrum强调进行小步骤开发，同时检验最终产品和当前实践的功效，然后调整产品目标与过程实践。 周而复始。

Read More

大家都讲敏捷（Agile），这个词的不等于单纯的快，而是灵活适应，快速响应变化的意思。

那么，哪些因素可以提高组织敏捷性呢？这里提出一个基于风险ROI的模型，讲各种因素统一融合起来。

$$
ROI=\frac{Impact*p%}{Cost}
$$

（p%=概率或确定性，Impact=影响程度或收益程度，Cost=成本）

风险偏好心理补偿作用：对不确定和犯错的容忍

由于心理对变化和不确定性的恐惧，而影响到ROI临界值的判断。

旧版

（摘要）

[TOC]

自动化测试的价值

开发者应该编写自动化测试，以便当发现回归问题时就使构建失败。而且，测试先行的编程风格已有大量的专业研究，使用自动化测试不仅是保护回归，而且是帮助设计，在编写代码之前就指出代码的期望行为，从而在验证实现之前先验证设计。

来认识一下小马。小马是著名的编程奇才，两年前刚毕业，然后加入了本地一家投行的IT部门，为银行开发用于在线自助服务的web应用程序。作为团队中最年轻的成员，起初他保持低调，集中精力学习银行的领域知识，熟悉“这里做事的方式”。

几个月后，小马注意到团队的工作很多都是返工：修复程序员的错误。他开始关注团队修复错误的类型，发现单元测试可以轻易地捕获到其中大多数。当他感觉到哪里存在特别容易出错的代码时，小马就对其编写单元测试。

测试帮助我们捕获错误。

一段时间以后，团队其他人也开始到处编写单元测试。Marcus已被测试感染 (test-infected) 了，他碰过的代码几乎都具有相当高的自动化测试覆盖率。除了在第一次时犯错，他们不会再花费时间修复过去的错误，待修复缺陷的总数在下降。测试开始清晰可见地影响着团队工作的质量。

自从小马编写第一个测试，已经过去近一年了。团队的测试覆盖率在近几个月快速提高，达到了98%的分支覆盖率。小马曾认为他们应该推动那个数字直到100%。但过去几周，他打定了主意——那些缺失的测试不会给他们带来更多价值，花费更多精力来编写测试不会带来额外的收益。许多没有测试覆盖的代码，只因所用的API要求实现某些接口，但小马的团队并未用到它们，那么何必测试那些空方法桩呢？

100%测试覆盖率不是目标

100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了，不论程序的行为是否满足要求。与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。

后来，高级软件架构师老赛加入了自助服务团队，并快速地成为了低级成员的导师，包括小马在内。小马习惯于先写代码，在提交到版本控制系统之前再补充单元测试。但老赛的风格是先写一个会失败(很明显是这样)的测试，再写足够使测试通过的代码，然后写另一个失败的测试。他重复这个循环直到完成任务。

与老赛共事，小马意识到自己的编程风格开始转变。他的对象结构不同了，代码看起来稍微不同了，只是因为他开始从调用者的角度来审视代码的设计和行为了。

测试帮助我们针对实际使用来塑造设计。

想到这些，小马觉得好像明白了一些道理。当他试图用语言表达出他的编程风格是如何改变的，以及收到了哪些效果时，小马明白了他写的测试不仅仅是质量保证的工具，或是对错误及回归的保护。测试作为一种设计代码的方式，提供了具体的目的。编写使失败测试通过的代码比以前的方式简单多了，而且该做的也都做了。

通过明确地指出所需的行为，测试帮助我们避免镀金。

主人公小马的经历正如许多爱好测试的编程人员一样，在不断地认识和理解测试。我们经常因为相信单元测试有助于避免尴尬、耗时的错误而开始编写它们。随后我们会学到，将测试作为安全网只是等式的一部分，而另一部分——或许是更大部分——其好处是我们将测试表达为代码的思考过程。

大多数人同意说编写一些测试是不费脑筋的。但随着我们接近完全的代码覆盖率，我们不那么确定了——我们差不多已经为一切都编写了测试，而剩下的没有测试的代码是微不足道，几乎不会破坏。这就是某些人所谓的收益递减。因此，

编写测试的最大价值不在于结果，而在于编写过程中的学习。

（略，请阅读正版原书）

何为优秀与代码坏味道

可读性、可维护性、可信赖性…

单元测试代码的可读性

原始类型断言

断言应该表达某种假设或意图。它们应该声明代码的行为。基本断言的问题在于它们缺乏意义，因为断言的基本原理和意图隐藏在看上去无意义的单词和数字背后，造成它们难以理解，并且难以验证断言的正确性。

下面例子展示了一个**全局正则搜索(grep)**程序的测试。grep程序其实就是逐行处理某种文本输入，在处理时可以包括或排除掉含有特定子串或模式的文本行。测试应当是你的对象所提供功能的具体例子，那么我们来看一看这个测试是否说清楚了grep程序该做的事情。但愿这个测试没有受到原始类型断言的折磨！

1
2
3
4
5
6
7

@Test
public void outputHasLineNumbers() {
   String content = "1st match on #1\nand\n2nd match on #3";
   String out = grep.grep("match", "test.txt", content);
   assertTrue(out.indexOf("test.txt:1 1st match") != -1);
   assertTrue(out.indexOf("test.txt:3 2nd match") != -1);
}

这个测试在干什么？首先，我们定义了文本字符串content来表示一段输入，然后调用grep程序，然后对grep结果输出中的某些东西进行断言。这些东西就是问题所在。断言的目标并不清楚，因为断言过于基本——它与测试的其他部分说着不同的语言。

具体来说，我们在这个断言中是要计算输出结果中的另一个文本字符串的索引，并将其与-1进行比较；如果索引为-1，那么测试失败。测试的名字叫做outputHasLineNumbers，显然，对于在代码中grep()的具体调用，输出结果应当包含正在进行逐行查找的文件名，后面加上行号。

不幸的是，我们不得不经过这个思考过程才能理解为什么我们要计算索引，为什么查找test.txt:1而不是其它东西，为什么与-1进行比较，当索引是-1或不是-1时测试是否会失败？这无需火箭科学就能找到答案，但却是我们大脑的不必要的认知工作。

Read More

你可能没有意识到，但是当你购买敏捷教练（特别是企业级教练）时，你所购买的是他们带来自己方式、他们的理智、他们的自制、他们的意义建构、以及他们的人性。正是由于很少人能带来那些东西，所以你值得付出—————金钱，以及（暂时性）的迷失方向和一定程度的不舒适，而这些将最终转化为舒适。你购买的是种子，这些种子会为你的组织赋予人性。

“You may not realize this, but when you pay an agile coach (especially an enterprise coach), you’re paying for the way they bring themselves, their consciousness, their self-mastery, their sense-making, and their humanity to your organization. And because it is so rare for people to bring these things, it’s going to cost you - both in terms of money, and in terms of (temporary) disorientation and a certain discomfort, which will eventually turn to comfort. You’re paying for the seed to humanize your organization.” - Posted on LinkedIn by Oluf Nissen

背景

德国的敏捷专家 Den Sunny 在2020年发起了一个全球性的签名运动，网站 http://remove-scrum-from-safe.tilda.ws/。

我们喜欢 Scrum。我们反对 SAFe（规模化敏捷框架）创建和推广的对 Scrum 的误解。

理由主要在在于规模化敏捷SAFe官网对Scrum、Scrum Master等概念的描述与Jeff Sutherland 和 Ken Schwaber 制定的《Scrum指南》有多处出入，造成误解和误用。

…像 SAFe 这样的框架 … 与 Scrum 指南不一致，并且编纂了可能削弱团队多年的功能障碍。

– 杰夫·萨瑟兰(Jeff Sutherland), Co-creator of Scrum

呼吁和诉求

我们呼吁 SAFe 的所有者尊重个人和组织，停止承诺可以在 SAFe 中使用 Scrum 和 Scrum Master 角色！

许多组织相应地实施规模化敏捷 SAFe，并具有各自的角色和流程。由于当前 SAFe 描述中的陈述，他们可以合理地期望能够在此结构中使用 Scrum。相反，SAFe 角色和流程迫使他们使用****大量 Scrum 反模式并造成严重的功能障碍。

然而，这些组织认为这正是 Scrum 框架，他们在此基础上了解 Scrum。它引入了对 Scrum的完全错误的理解，并剥夺了组织实现目标的机会。

此外，对于决定在 SAFe 中培养 Scrum Master 技能的人来说，这会导致重大的职业损失. 他们学习了错误的理论并采取了功能失调的行为。之后，他们很难理解真正的区别，以便能够有效地帮助组织正确采用 Scrum。

Read More

（原文由博主mebusw于2009年发表于现已不在的桌游论坛BGC。”Race For The Galaxy” 策略类卡片桌游是一种很好地团建方式，节奏快，时间段，易上手，寓教于乐，特别适合于敏捷团队，笔者于2007年开始尝试这种方式带团队，收到很好的效果。今日偶然翻到这篇旧文，忆往昔DIY的日子，唏嘘不已。）

随着空间跃迁知识的传播，一个古代种族开始蠢蠢欲动，而另一个种族需要逃离行将灭亡的恒星。银河帝国的力量不断增长，导致了更加严重的叛乱和佣兵的出现。在这个面临战争的银河系里，你能建立起最为繁荣强大的国家么？

简介

本扩展里加入了新的起始星球和新的游戏卡牌，为第五玩家准备的行动卡牌和VP筹码，以及银河竞逐的目标卡。此外这里还提供了一个独立的单人游戏，一种轮抽玩法以及一些空白卡牌，以便玩家自己设计星球和开发设施牌。

Read More

本文是之前为Scrum Gathering 2013敏捷大会准备话题时总结的一些想法，又在台北RSG2022大会进行了重制。更多是从内部做ScrumMaster和敏捷教练时的体会。重点是：对齐目标 收服人心，用魔戒甘道夫作比喻，借假修真地阐述敏捷教练打造敏捷团队的秘诀，最主要的能力就是”填坑”（Fill the Gap）。

点击观看幻灯片演讲实录：

对齐目标 收服人心——魔戒甘道夫用“血泪”填坑 | 打造敏捷团队的秘诀 敏捷教练借假修真

（关于Scrum Master与Agile Coach的区别，笔者认为不大，SM也不只是懂Scrum就够了。其实可以从团队级和组织级来区别工作范围，而不是纠结名字）

SM是新的角色，很多时候定位不是那么清楚。The Scrum Master is primarily responsible for “How” - using Scrum the right way.

Read More