重构团队或应用更好的API之时,BART可以帮忙

When to Refactor Your Team or Use a Better API: BART Will Help

译者注: 关于BART的文章不多。这一篇是偶然看到的,其实也是2016年的老文章了。本文翻译后,请伯薇审校,他提出非常中肯的建议。就让他也写了个介绍。我们也顺道玩了个小游戏。他写了中文,翻译成英文,然后我再翻译。具体的,请见:

BART is one of the very important models in group dynamics. With it, we can see the current situation and mode of dynamics in the group. This article uses the BART model to look at the R&D team, hoping to get a better team structure and communication mode.

BART是团体动力学中非常重要的模型之一。通过它,我们可以发现当前的情况和团体中的动力模式。此文应用BART模型对研发团队进行研究,希望可以得到更好的团体结构和沟通模式。

How are your interactions at work? Chaotic and conflict-filled? Tediously unproductive? The BART system offers an analytical tool to solve stalled interactions — and clarify all sorts of organizational snafus. (And just to get it out of the way up front, no, we’re not talking trains.)

工作中你的互动情况如何?是混乱的而且充满了冲突吗?乏味到没有生产力吗?BART系统提供了分析工具来解决这些停滞不前的互动-它还可以澄清各种组织性漏洞。(事先说明,不,我们可不是在谈论下面这类火车)

No, not that BART. (“Bart Train entering station” by Steve Lambert is licensed under CC BY 2.0.)

BART parses some of the arcane organizational dynamics lurking in the workplace. Even a bit of background on Boundaries, Authority, Roles, and Tasks will help you loosen log-jams during team encounters. Knowing what lurks below allows you to cut through the confusion — and decipher what’s really going on within your group’s hive-mind.

BART解析了在工作场所里蕴含的神秘组织动态。即使对边界、权威、角色、任务有一丢丢背景了解,也会帮助你在团队交锋的过程中缓解僵局。了解隐含的是什么内容,可以让你穿过困惑,破译你的团队内部真正发生了什么。

Boundary Skirmishes

边界小冲突

Let’s first take a look at the idea of boundaries. Bad boundaries are the stuff of pop-culture memes, but the ramifications at work are invariably less amusing. Zachary Gabriel Green and Rene J. Molencamp’s BART theory says work boundaries comprise time, territory, and task. These translate roughly into “when, “ “where,” and “what?”

让我们先来看看边界的概念。坏的边界是那些流行文化备忘录里的东西,但是它们在工作中的影响却总不是那么有趣。Zachary Gabriel Green和Rene J. Molencamp的BART理论说,工作边界包括了时间、地域和任务。这些大致可以翻译为“何时”、“何地”以及“什么”?

Time is easy to grasp. “In everyday life we have deadlines, due dates, and departure times and the like to which we must adhere. Failure to attend to these time boundaries carries consequences, depending on the rigidity of the boundary.” A plane or train leaves when it leaves; if you miss that time boundary, you don’t travel.

时间是很容易把握的。“每一天生活中我们都会有最后期限、到期日期、出发时间以及其它此类我们必须遵守的。没有注意到这些时间的边界会带来一些后果,这取决于边界的严格程度。”飞机和火车离开的时候,如果你错误了这个时间边界,你就无法旅行了。

Consequences can range from very minor (annoyance at having to wait for the next one) to catastrophic: you’re fired for missing a presentation you were supposed to deliver.

// 后果的范围从非常小的(不得不等待下一班的恼怒)到灾难性的:你被解雇了,因为你错过了该做的演讲。

后果可以很轻微,比方说你不得不因为需要等待下一趟公交车而懊恼,也可能非常严重,你因为错过了需要做的演讲被公司解雇。(注:侯伯薇译)

Less dramatic but more ubiquitous: do meetings start and end on time?

没这么戏剧性但是更为普遍的是:会议是否会准时开时和结束呢?

How do you coordinate over global boundaries?

Also straightforward is the geography aspect of boundaries. Most political skirmishes include the high-stakes version of territorial boundary disputes; the Middle East is an obvious example.

同样直观的是地理方面的边界。大多数政治小冲突都包括了高风险的领土边界争端;中东就是明显的例子。

A common work version? Some of your team-members are in Bangalore; some are in San Francisco. How do you coordinate … sans duplication and inconvenience?

普通的工作版本呢?你的一些团队成员在班加罗尔;一些在旧金山。你们是如何协调的……避免重复和不便的呢?

Undefined Task boundaries cause confusion and delays. Does your group claim a particular project, or is it the other group’s? Everyone has been in a work-related “turf war” (whether as instigator, cannon fodder, or hostage). In groups with bad boundaries, territory and task issues combine with frustrating results. For example, does everyone do releases or is there a release engineer? If everyone does releases, whose task is it to ensure the release doesn’t break?

未定义的任务边界会导致混乱和延误。的小组会发布一个特别的项目或者是其他小组?每个人都经历过工作有关的“地盘战”(无论是作为煽动者、炮灰,还是人质)。在边界存在问题的小组中,地盘、任务问题结合在一起会产生令人沮丧的结果。例如,是每个人都做发布还是要有一个发布工程师?如果每个人都做发布工作,谁的任务是确保发布不会存在问题呢?

Formal and Informal Authority and Roles

正式和非正式的权威和角色

Getting “meta” with authority and roles is where big pay-offs are possible. Within the BART system, formal and informal (or explicit and implicit) versions of authority and roles always exist. So, solving organizational conflicts is often a matter of teasing out the tensions between the two levels.

权威角色进行“元化”处理有可能获得巨大的回报。在BART系统中,正式和非正式(或明确和隐含)的权威和角色一直存在。因此,解决组织冲突往往是这两个层次之间的矛盾问题。

Ever met a program manager or engineer who everyone on the team listens to … though they’re not the designated lead? If a team doesn’t authorize the designated leader to lead, the leader — and, thus, the team — will be ineffective. Even if the organization has delegated formal authority by, say, bestowing a title, teams often make bottom-up decisions to follow someone whose vision they trust. That’s how informal authority usurps formal authority every time: trust always trumps a title. Despite workers believing that managers have all the power, it’s actually a two-way street, because a rogue team can negate all a manager’s efforts. Cultivating informal leaders — and their influence — is one way to acknowledge workplace realpolitik.

你曾经见过团队中每个成员都听从的项目经理或者工程师吗……尽管他们不是指定的领导?如果一个团队没有授权给定的领导者领导,这个领导者,以及团队,将是没有效果的。即使组织通过授予头衔等方式授予正式权力,团队也经常自下而上地决定跟随他们信任的人的愿景。这就是非正式权力每次都能取代正式权力的原因:信任总是胜过头衔。尽管工人们认为管理理者拥有所有的权力,但这实际上是一条双向的道路,因为一个失常的团队可以否定管理者的所有努力。培养非正式领导人-以及他们的影响力-是承认工作场所现实政治的一种方式。

Consider all the different roles that comprise a well-functioning team. Explicit roles are engineer, QA tester, and product or program manager. But informal roles are where organizational dynamics are powerfully at play. What if your program manager (explicit role) doesn’t take up the task master role (implicit)? Or what if your tech lead is so busy writing code she isn’t directing the team? Class clowns grow into comedians at work, defusing tensions via a sort of court jester loophole. Who’s the social coordinator? Who’s the unofficial “jerk” or “devil’s advocate” (where ideas go to die)? (Maybe you’re the informal leader?)

考虑到构成一个动作良好的团队的所有不同角色。明确的角色是工程师、QA测试人员和产品或者项目经理。但是非正式的角色是组织动态运转强有力的体现所在。如果你的项目经理(显性角色)不承担任务负责人的角色(隐性角色)怎么办?或者,如果你的技术负责人忙着写代码,而不去指导团队怎么办?班级小丑在工作中成长为喜剧演员,通过一种宫廷小丑的漏洞化解紧张局势。谁是社交协调人?谁是非官方的“混蛋”或“魔鬼代言人”(想法会在哪里消失)?(也许你是非正式的领导者?)

(People get stuck in unofficial roles, too. Does the “giving” type at your office always end up with grungy clean-up tasks or with serving as morale-booster? How long before that person burns out, if their unofficial role is draining — as well as unacknowledged?)

(人们也会被困在非官方的角色中。在你的办公室里,"奉献 "型的人是否总是以肮脏的清洁任务或充当士气助推器而告终?如果这个人的非官方角色让人疲惫不堪,而且不被认可,那么他还要多久才会倦怠?)

Tasks

Official tasks are pretty much what you’d expect: write code, test code, launch products, etc. If you’re schooled in organizational dynamics, you’ll see plenty of unofficial tasks, too. Temporary groups, convened for a finite purpose or task, are sometimes subject to a counter-intuitive dynamic: survival!

官方的任务几乎是你所期待的那样:写代码、测试代码、推出产品,等等。如果你学过组织动力,你还可了解到很多非官方的任务。临时小组,它为了有限目标或任务召集,有时候会受到一个反直觉的动力影响:生存!

The team wants to survive as a team, the start-up wants to survive as a start-up. Group-members start thinking (subconsciously), “I’m important because I’m in this group … so I’d better ensure the group persists.” They become preoccupied with the group’s longevity and health (so their important role as group-member will persist), rather than with whatever putative task they’re supposed to accomplish. When this task takes over, unintended consequences arise … such as the engineer who polishes the same section of code over and over, instead of moving on. Once you know the concept of unofficial tasks, they’re a lot easier to spot.

团队想作为一个团队生存下去,创业公司想作为一个企事业公司生存下去。团体成员开始思考(下意识地):“我很重要是因为我在这个团体……所以我最好确保这个团体持续存在”。他们开始专注于团体的长寿和健康(这样他们作为团体成员的重要角色就会存续),而不是专注于他们应该完成的任何假定任务。当这一任务占据主导地位时,就会产生意想不到的后果……比如,工程师一遍又遍地打磨同一段代码,而不是向前推进。一旦你知道了非官方任务的概念,它们就更容易被发现。

Dysfunctional Dynamics: A Case Study

功能紊乱的动态:一个研究案例

Watching for unofficial roles (vs. going by titles) can help you parse puzzling dynamics.

SCENARIO. Let’s see how this plays out via an IRL example. A senior leader in a large tech company convened a team, thus formally authorizing those selected to participate in the project. The group members were peers (they all reported to this senior leader) as well as experienced managers (they each individually managed their own organizations) but they didn’t understand how to function in a group that needed consensus. They were used to top-down deciding and directing — not collaborating as peers. (Do you see how authority might be an issue here?)

场景:让我们通过一个真实的例子来看看这一点是如何发生的。一家大型科技公司的高级领导召集了一个团队,从而正式授权那些被选中的人参与这个项目。小组成员都是同等地位的(他们都向这位高级领导汇报),同时,他们也是有经验的管理者(他们各自管理自己的组织),但是他们不了解如何在一个需要达成共识的小组中发挥作用。他们习惯于自上而下的决定和指挥-而不是作为同僚合作。(你知道为什么权威在这里会是一个问题吗?)

The group’s task was to set next year’s annual goals, meaning they would make decisions on behalf of the senior leader’s overall constituency — which included their own individual orgs. But this group didn’t formally take up the authority they had been given to stay on-task. Some angled for power. Others showed up to meetings but in between those meetings didn’t execute the actions they’d agreed upon.

小组的任务是制定明年的年度目标,这意味着他们将代表这些高级领导者-包括他们自己的个人组织做出决定。但是这个小组并没有正式接受他们被赋于的这个任务权利。一些人在争取权利。一些人出席了会议,但是这些会议并没有执行他们所同意的行动。

Disagreements arose at several phases, and unofficial roles evolved quickly. One person became the nay-sayer, shooting down every idea. Another tried to grab the crown: I’ll do everything, just let me have it! The group specifically de-authorized the program manager by not taking up his agendas and talking about him behind his back. Another leader became a rationalizer (unofficial role) for the status quo, defending existing decisions and thwarting any evolving visions. The senior leader himself hovered electronically, fretting that the group wasn’t taking more initiative — while group members jockeyed for his approval, rather than getting on with their task.

在几个阶段都出现了分歧,并且非官方的角色迅速发展起来。一个人成为反对者,否定了所有的想法。另一个人试图夺取王位:小组特别取消了对项目经理的授权,他们不接受他的议程,并在背后议论他。另一位领导成为了现状的合理化者(非官方角色),为现有的决定辩护,阻挠任何不断发展的愿景。高级领导自己在电子屏幕上徘徊,担心小组没有采取更多的主动权--而小组成员则争相争取他的批准,而不是继续完成他们的任务。

Step back from group conflict to note unofficial roles

SOLUTION. Once you activate your “double-vision” — the ability to view both levels of role simultaneously — you can diagnose problems early. An immediate scope question should have been, Let’s define the group’s real task. Yes, we need to develop and disseminate the division’s new annual goals. But where were the task’s exact boundaries? Did that mean “just” creating the goals? (Strategy.) Did it include how to get there? (Tactics.) Should they assign specific tasks and responsibilities — back within their own organizations? (Implementation/Management.)

解决办法。一旦你激活了你的 "双眼"--同时查看两个层次的角色的能力--你就可以及早诊断出问题。一个直接的范围问题应该是:让我们定义这个小组的真正任务。是的,我们需要制定和传播部门的新年度目标。但任务的确切界限在哪里?这是否意味着 "仅仅 "创建目标?(战略)它是否包括如何达到目标?(战术)回到他们自己的组织,他们是否应该分配具体的任务和责任?(实施/管理)

Once the group said “this — and only this — is our task” things fell into place. One person finally said, “I’m going to be the leader!” Everyone agreed (thus authorizing him informally.) And the group quashed the person who kept saying, “But to accomplish this, we first have to decide A, B, and C.” (No, the group’s task was solely the goals.) They also needed someone to say “we’re going off-task” and herd them back toward productivity: another unofficial but vital role.

一旦小组说:“这个-只有这个-是我们的任务”,事情就水到渠成了。一个人终于说:“我要做领导者!”每个人都同意(也做了非正式授权)。小组还制止了那个人,他一直说“但是,要完成这个任务,我们首先要决定A、B还有C”。(不,小组的任务仅仅是目标。)他们还需要有人说:“我们要偏离任务了”,把他们赶回到能够产生生产力:这是另一个非官方但是重要的角色。

Cat-herder is one of the most important unofficial roles on a team.

A BART Checklist — Refactor or Better API?

BART检查表-重构或更好的API?

When you see a group unable to accomplish what it has set out to do (i.e., get results!), or people on a team being scapegoated or even being pushed out, step back for a moment. Do you need to refactor? Or do you need to better define the API for the team? Use BART to analyze what’s going on below the surface at workthe unexamined scenarios that control more of our work-life than we recognize.

当你看到一个小组无法完成它所设定的任务(即,获得结果!),或者一个团队中的人被当作替罪羊,甚至被排挤出去,请退后一步。你需要重构吗?或者你需要为团队更好地定义API?使用BART来分析工作中表面之下发生的事情--那些未经审查的场景控制着我们工作生活中更多的东西,而不是我们所认识的。

Here’s a quick checklist to help you begin to analyze problematic dynamics.

这里有一个快速检查表,帮助你开始分析有问题的动态。

Boundaries 边界

  1. Does the team have a deadline it is trying to meet? How does the team respect meeting boundaries?

  2. Are there boundaries that get in the way?

  3. Is the task truly clear? (Can each team-member define its boundaries?)

  1. 该团队是否有一个试图满足的最后期限?团队是如何尊重会议的边界的?

  2. 是否有阻碍的界限?

  3. 任务是否真正明确?(每个团队成员都能确定其界限吗?)

Authority 权威

  1. Who are the named / official leaders on the team?

  2. Has the team authorized the leadership of tech lead, program manager, or manager? Is there an unofficial leader that people seem to be following?

  3. Is there a discrepancy between the official and unofficial leader?

  1. 谁是团队中的指定/官方领导? 团

  2. 队是否授权给技术负责人、项目经理或经理的领导?是否有一个非官方的领导,人们似乎都在追随?

  3. 官方和非官方的领导之间是否存在差异?

Roles 角色

  1. What are the official roles on the team?

  2. What unofficial roles do you notice? (Class clown, slacker, nay-sayer, pollyanna, social coordinator ... )

  3. How do unofficial roles interrupt (or help!) productivity?

  1. 团队中的官方角色是什么?

  2. 你注意到哪些非官方的角色?(班级小丑、懒汉、说废话的人、波利尼西亚人、社会协调人......)

  3. 那些非官方的角色是如何干扰(或帮助)生产力的?

Task 任务

  1. What is the explicit task of the group?

  2. What are some implicit tasks? (i.e. in prior EQ article, can you spot the team who had an implicit task of protect its bad leader?)

  3. Are team-members more concerned with staying on-task ... or perpetuating the group itself (survival)?

  1. 这个小组的明确任务是什么?

  2. 有哪些隐性任务?(例如,在之前的EQ文章中,你能发现有一个团队的隐性任务是保护它的坏领导吗?)

  3. 团队成员更关心的是保持任务......还是延续团体本身(生存)?

After you’ve done the analysis, what’s next? How can you point issues out?

做完了分析之后,你的下一步是什么?如何指出问题所在?

More on this later (in another post), but a quick model for giving feedback is “SBI.”

稍后会有更多的内容(在另一篇文章),这里给出一个回馈的快速模型“SBI”

Situation — What did you observe? (stick to the facts)

情况 - 你观察到了什么?(坚持事实)

Behavior — What was the behavior you saw?

行为 - 你看到的行为是什么?

Impact — What was the impact? (on you)

影响 - 影响是什么?(对于来说)

For example, I want to talk to the Tech Lead about being late to our team meetings. I say, “At our last meeting, you showed up 15 minutes late, and the impact was that the team and I weren’t able to really get started without you.” This touches on time boundaries and that the team doesn’t feel authorized to work without the tech lead ((1a and b, respectively, in the above checklist). This can be a lead-in to tell the TL about his impact and also a way to kick off a discussion about how to fix problems.

例如,我想和技术负责人谈谈他在团队会议上迟到的问题。我说,“在我们的最后一次会议上,你迟到了15分钟,其影响是,没有你,团队和我都无法真正开始工作。”这就涉及到了时间边界,以及团队觉得没有技术带头人的授权就无法工作(分别是上述检查表中的1ab)。这可以是一个引子,告诉TL他的影响,也是一个启动关于如何解决问题的讨论的方式。

最后更新于