Команда, коммуникации, конфликты и мотивация

Предыдущие статьи трека были про работу: как её резать (https://courses.digitable.life/post/project-management/03-estimation-and-planning/), как ей управлять (https://courses.digitable.life/post/project-management/02-kanban-and-flow/), как страховаться от неприятностей (https://courses.digitable.life/post/project-management/04-risk-management/). Эта — про то, что работу выполняет.

Тезис статьи один, и он неприятен:

Пропускная способность команды определяется не суммой квалификаций, а качеством связей между людьми. Квалификации складываются линейно, стоимость связей растёт квадратично — поэтому «добавить людей» почти никогда не является ответом, а «наладить коммуникацию» почти всегда.

Разберём это с первых принципов: сначала физика координации (тут есть арифметика и код), потом психология (тут есть данные и их честная критика), потом конфликты и мотивация — области, где индустрия особенно любит красивые модели без эмпирики. Будем отделять одно от другого.

1. Команда как система обработки информации

1.1. Закон Конвея: структура связей просачивается в код

Мелвин Конвей в 1968 году сформулировал наблюдение, ставшее законом:

«Организации, проектирующие системы, вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций» (Conway, «How Do Committees Invent?»).

Механика простая и не мистическая. Интерфейс между двумя модулями — это договорённость. Договорённость требует переговоров. Если два человека сидят рядом, переговоры бесплатны, и граница между их кодом получается размытой и подвижной. Если они в разных отделах, каждое изменение интерфейса стоит встречи и согласования — и граница затвердевает, обрастает версионированием и обратной совместимостью. Архитектура ПО — это застывший слепок того, кому с кем было легко разговаривать.

Эмпирика у закона есть. Microsoft Research на данных Windows Vista показала, что организационные метрики (сколько инженеров трогало компонент, как глубоко в оргструктуре расходятся их менеджеры, какова доля «пришлых» коммитеров) предсказывают плотность дефектов лучше, чем классические метрики кода вроде цикломатической сложности и покрытия (Nagappan, Murphy, Basili, ICSE 2008).

Практическое следствие называют «обратным манёвром Конвея» (inverse Conway manoeuvre): если вам нужна конкретная архитектура — стройте под неё оргструктуру, а не наоборот. Подробнее об этом — в статье о масштабировании (https://courses.digitable.life/post/project-management/08-scaling-frameworks/).

1.2. Цена координации растёт квадратично

Между n людьми существует n(n−1)/2 парных каналов. Это не абстракция: каждый канал — это чей-то контекст, который надо синхронизировать, чьё-то решение, о котором надо узнать, чей-то код, который надо не сломать.

Формализуем. Пусть каждый человек в одиночку производит solo единиц работы за период, а каждый активный канал съедает link_cost таких единиц. Тогда чистая выработка:

output(n) = n · solo − link_cost · n(n−1)/2

Это парабола ветвями вниз. Максимум берётся из производной: solo − link_cost·(n − 0.5) = 0, откуда

n* = solo / link_cost + 0.5

При solo = 1 и link_cost = 0.14 оптимум — около 8 человек. Число link_cost не универсально: оно зависит от связности задач, зрелости кодовой базы, доли асинхронной коммуникации. Модель нужна не чтобы вычислить «правильный» размер, а чтобы понять форму зависимости: выигрыш от найма линейный, а проигрыш — квадратичный, поэтому кривая обязательно разворачивается вниз.

Теперь добавим второй эффект — закон Брукса: «добавление рабочей силы в опаздывающий проект задерживает его ещё сильнее» (Brooks, «The Mythical Man-Month»). Новичок не просто бесполезен первые недели — он отрицательно полезен, потому что тратит время наставника.

from dataclasses import dataclass


@dataclass
class CoordModel:
    """Игрушечная модель выработки команды с учётом координации и онбординга."""

    solo: float = 1.0            # выработка одного человека за неделю
    link_cost: float = 0.14      # стоимость одного парного канала связи
    onboarding_weeks: int = 8    # сколько новичок выходит на полную мощность
    mentor_drag: float = 0.25    # доля времени наставника, съедаемая одним новичком

    def channels(self, n: int) -> int:
        """Число парных каналов. O(1) по времени и памяти."""
        return n * (n - 1) // 2

    def steady_output(self, n: int) -> float:
        """Установившаяся выработка команды из n человек."""
        return n * self.solo - self.link_cost * self.channels(n)

    def output_after_hiring(self, n: int, hired: int, week: int) -> float:
        """Выработка на неделе `week` после найма `hired` человек в команду из `n`."""
        if week >= self.onboarding_weeks:
            return self.steady_output(n + hired)
        ramp = week / self.onboarding_weeks          # линейный выход новичка на мощность
        productive = (
            n * self.solo
            + hired * self.solo * ramp               # новички работают частично
            - hired * self.mentor_drag * (1 - ramp) * self.solo  # и отъедают наставников
        )
        # координационные издержки платит вся команда сразу, с первого дня
        return productive - self.link_cost * self.channels(n + hired)

    def optimal_size(self, limit: int = 40) -> int:
        """Размер команды с максимальной установившейся выработкой. O(limit)."""
        return max(range(1, limit + 1), key=self.steady_output)


m = CoordModel()
for n in (1, 3, 5, 7, 9, 12, 15):
    print(f"n={n:2d}  каналов={m.channels(n):3d}  выработка={m.steady_output(n):5.2f}")
# n= 1  каналов=  0  выработка= 1.00
# n= 5  каналов= 10  выработка= 3.60
# n= 7  каналов= 21  выработка= 4.06   <- максимум
# n= 9  каналов= 36  выработка= 3.96
# n=15  каналов=105  выработка= 0.30   <- команда занята собой

before = m.steady_output(6)                       # 3.90
for w in (0, 2, 4, 6, 8):
    print(f"неделя {w}: {m.output_after_hiring(6, 3, w):.2f} (было {before:.2f})")
# неделя 0: 0.21   <- падение почти в 20 раз
# неделя 4: 2.08   <- всё ещё хуже, чем было
# неделя 8: 3.96   <- вышли в плюс на 0.06

Читайте результат внимательно. Команда из шести человек наняла ещё трёх — то есть выросла в полтора раза — и через два месяца получила прирост выработки 1,5%. Это не баг модели, это её главный вывод: при уже высокой связности найм окупается годами, а не спринтами.

Что из этого следует на практике:

• Найм — инструмент стратегического горизонта (6–12 месяцев), а не спасения квартального дедлайна.
• Если проект горит, работают только три рычага: срезать объём, снять параллельную нагрузку (см. WIP в https://courses.digitable.life/post/project-management/02-kanban-and-flow/), убрать блокеры. Люди — не рычаг.
• Рост организации должен идти не размером команды, а числом слабо связанных команд: n(n−1)/2 внутри маленькой группы дёшево, а между группами связей должно быть единицы.

1.3. Сколько людей в команде: цифры и их происхождение

Про Данбара стоит сказать отдельно, потому что его постоянно цитируют не по делу. Во-первых, 150 — это оценка размера устойчивого социального круга, а не команды. Во-вторых, сама оценка шаткая: переанализ 2021 года с современными методами дал доверительный интервал от 4 до 520 человек и вывод, что «вычислять число Данбара такими методами бессмысленно» (Lindenfors et al., Royal Society Open Science). Пользоваться «числом Данбара» как аргументом в споре об оргструктуре — плохая идея; пользоваться арифметикой каналов связи — хорошая.

1.4. Социальная леность: почему в большой группе меньше стараются

Эффект Рингельмана: при перетягивании каната восемь человек тянут слабее, чем сумма их одиночных усилий. В командной работе то же самое называют social loafing. Мета-анализ Карау и Уильямса (78 исследований, JPSP 1993) показал, что эффект устойчив, но исчезает при конкретных условиях: когда индивидуальный вклад различим, когда задача воспринимается как значимая, когда группа сплочённая, когда человек считает свой вклад незаменимым.

Отсюда конкретные управленческие ходы, а не абстрактное «мотивируйте людей»:

• у каждой значимой задачи есть один ответственный (не «команда отвечает» — команда не человек);
• вклад виден: авторство в changelog, демо делает тот, кто делал, а не менеджер;
• размер группы, решающей одну задачу, минимален — двое лучше пятерых;
• «размывание ответственности» лечится не контролем, а адресностью.

2. Жизненный цикл команды

Модель Такмана (1965, стадия «adjourning» добавлена в 1977) описывает путь группы через четыре состояния (Tuckman, Psychological Bulletin).

Что здесь важно и что обычно понимают неверно:

1. Стадии не проходят один раз. Любое изменение состава возвращает команду в storming. Уход техлида, приход сильного мидла, смена продукта — всё это перезапуск. Отсюда практическое правило: не меняйте состав команды чаще, чем раз в квартал, если можете этого избежать.
2. Storming — не патология, а работа. Команда, которая никогда не спорила, просто не обсуждала ничего важного. Менеджер, гасящий storming ради «здоровой атмосферы», получает вежливую группу без общих стандартов, у которой конфликт уходит в подполье и всплывает на код-ревью.
3. Модель не валидирована количественно. Такман сделал обзор литературы о малых группах, а не лонгитюдный эксперимент. Стадии — удобный язык для разговора, а не измеримая шкала. Не стройте на них KPI; используйте как диагностический словарь.

3. Психологическая безопасность: единственная хорошо измеренная вещь в этом списке

Эми Эдмондсон определяет психологическую безопасность как «разделяемое убеждение членов команды в том, что команда безопасна для межличностного риска» (Edmondson, Administrative Science Quarterly, 1999). Межличностный риск — это сказать «я не понимаю», «я ошибся», «по-моему, это плохая идея».

Важная деталь из её же исследования: она изучала медицинские команды и обнаружила, что лучшие команды регистрировали больше ошибок. Не совершали больше — регистрировали. Психологическая безопасность не уменьшает число ошибок, она уменьшает число скрытых ошибок. Для IT это прямая связь с постмортемами без поиска виноватых (blameless postmortem) и с честными retro.

Чем психологическая безопасность не является:

Про Project Aristotle. Google в 2015 году опубликовал внутреннее исследование ~180 команд, где психологическая безопасность оказалась фактором №1 эффективности (re:Work, NYT Magazine). Это очень цитируемая, но непрорецензированная корпоративная работа на одной компании; методология и данные полностью не раскрыты. Опирайтесь на Эдмондсон (рецензируемая, воспроизведённая многократно), а Google приводите как иллюстрацию, а не как доказательство. Умение так отличать — часть профессии менеджера.

Как измерять. Эдмондсон использует опрос из семи утверждений по шкале Лайкерта; в командной практике достаточно анонимной формы раз в квартал с вопросами вида:

1. Если я ошибусь в этой команде, это, скорее всего, обернётся против меня. (обратный)
2. В этой команде можно поднимать проблемы и сложные темы.
3. Люди здесь иногда отвергают других за непохожесть. (обратный)
4. В этой команде безопасно рискнуть.
5. Трудно попросить помощи у коллег. (обратный)
6. Никто здесь не станет сознательно подрывать мои усилия.
7. Мои навыки и вклад здесь ценят и используют.

Смотрите не на среднее, а на дисперсию и динамику. Среднее 4,2 при разбросе от 1 до 5 означает, что часть команды живёт в другой реальности, — и это более срочная информация, чем сам балл.

Как строить (порядок важен, это дела менеджера, а не лозунги):

• первым признавать собственные ошибки вслух и конкретно («я неверно оценил срок, вот что упустил»);
• задавать вопросы, на которые вы не знаете ответа, и не наказывать за неудобный ответ;
• отделять человека от решения: «этот подход сломается на пике» вместо «ты не подумал»;
• реагировать на плохие новости благодарностью за раннее предупреждение — иначе следующая новость придёт поздно (это же лежит в основе управления рисками, см. https://courses.digitable.life/post/project-management/04-risk-management/);
• следить, кто молчит на встречах, и давать асинхронный канал тем, кому синхронный некомфортен.

4. Коммуникации: выбирать канал осознанно

4.1. Матрица выбора канала

Главная ошибка — считать синхронную коммуникацию «более качественной». Она более быстрая по латентности и более дорогая по пропускной способности: встреча на час с шестью участниками стоит шесть человеко-часов и вырезает у каждого кусок фокусного времени (реальная цена выше номинала — переключение контекста).

Про якорение стоит помнить и в оценках: первый озвученный срок сдвигает все последующие (см. https://courses.digitable.life/post/project-management/03-estimation-and-planning/).

4.2. Письменная культура: RFC, ADR, decision log

Инженерная организация, которая не пишет, теряет решения. Через полгода никто не помнит, почему выбрали Postgres вместо Mongo, и спор запускается заново — уже с новыми людьми и без исходных аргументов.

Минимальный работающий формат — ADR (Architecture Decision Record), одна страница:

# ADR-014: Идемпотентность платёжных вебхуков через ключ на стороне БД

- Статус: принято (2026-03-11), заменяет ADR-009
- Контекст: провайдер гарантирует at-least-once доставку; повторы вызывают двойные списания.
- Рассмотренные варианты:
  1. Дедупликация в памяти сервиса — отпадает: не переживает рестарт и не работает при N репликах.
  2. Уникальный индекс по (provider_id, event_id) в таблице обработанных событий.
  3. Внешний Redis-лок — отпадает: добавляет зависимость в критический путь платежей.
- Решение: вариант 2.
- Последствия: +1 запись в БД на событие; нужна ретенция таблицы (90 дней);
  при смене провайдера потребуется миграция ключа.
- Кто участвовал: команда payments, SRE (ревью), финансы (согласование ретенции).

Что делает этот документ полезным: он фиксирует отвергнутые варианты и причины отказа. Обычный протокол встречи фиксирует только итог — и через год кто-то предложит Redis-лок снова.

Правило, которое стоит внедрить: никакое значимое решение не считается принятым, пока не записано. Это ещё и лекарство от «решили в курилке» — самой ядовитой формы коммуникации в распределённой команде.

4.3. Совещания: аудит стоимости

Быстрый честный расчёт, который стоит показать команде один раз:

def meeting_cost(participants: int, minutes: int,
                 hourly_rate: float = 40.0,
                 context_switch_min: int = 20) -> float:
    """Полная цена встречи: время в комнате + разрушенный фокус.

    context_switch_min — эмпирическая надбавка на возврат в задачу.
    Точное значение спорно, но оно точно не ноль.
    """
    effective = minutes + context_switch_min
    return participants * (effective / 60) * hourly_rate


weekly = meeting_cost(8, 60) * 52          # еженедельный часовой статус на восьмерых
print(f"{weekly:,.0f} у.е. в год")         # 22,187 у.е. в год

Дальше — не «отменить все встречи», а проверить каждую регулярную встречу тремя вопросами:

1. Какое решение здесь принимается? Если никакое — это рассылка, а не встреча.
2. Кто из присутствующих не влияет на решение? Он приглашён «на всякий случай» — уберите, дайте ему заметки.
3. Что случится, если её не будет один раз? Если ничего — уберите совсем и посмотрите месяц.

Хорошие эталоны: у встречи есть письменная повестка заранее, документ читают в первые 10 минут молча (практика Amazon), решения уходят в decision log, статусы не проговариваются вслух. Как это соотносится с церемониями Scrum — разбирается в https://courses.digitable.life/post/project-management/01-agile-and-scrum/.

4.4. Топология команд и режимы взаимодействия

Книга «Team Topologies» (teamtopologies.com) даёт язык для проектирования коммуникаций: четыре типа команд (stream-aligned, platform, enabling, complicated-subsystem) и три режима взаимодействия — collaboration (плотная совместная работа, дорого, для неизвестной территории), X-as-a-Service (одна команда потребляет продукт другой через контракт, дёшево), facilitating (одна помогает другой освоить область, временно).

Ключевая мысль: режим взаимодействия — это осознанный выбор с ограниченным сроком, а не то, что складывается само. Постоянная collaboration между двумя командами означает, что граница между ними проведена неправильно: их надо либо объединить, либо разделить по-другому.

4.5. Распределённые команды

Три отдельных режима, которые часто путают:

• Один офис. Коммуникация дешёвая и незаметная; главный риск — решения принимаются в коридоре, а отсутствующий (заболевший, в отпуске) выпадает из контекста.
• Одна страна / близкие часовые пояса. Работает почти как офис при условии, что письменная культура заведена явно.
• Разброс более 4–5 часов. Синхронное окно схлопывается, и асинхронность перестаёт быть стилем — становится обязательным требованием. Всё, что не записано, не существует; каждое ожидание ответа стоит полсуток.

Практика для распределённых: «документ первичен, встреча вторична»; у любого треда есть явный адресат и срок; статус пишется в общий канал, а не в личку менеджеру; ротация неудобного времени встреч между регионами, а не «всегда неудобно азиатскому офису».

5. Конфликты

5.1. Три вида конфликта, и только один из них полезен

Это, пожалуй, самое практически важное различение в статье.

Классический тезис «предметный конфликт полезен» надо уточнить. Мета-анализ Де Дрё и Вайнгарт (28 исследований, Journal of Applied Psychology, 2003) нашёл отрицательную корреляцию с эффективностью у обоих видов конфликта — и у личностного, и у предметного. Причина, по-видимому, в том, что предметный конфликт легко перетекает в личностный: обсуждение архитектуры становится обсуждением компетентности автора.

Отсюда рабочий вывод: задача менеджера — не «поощрять конфликты» и не «гасить конфликты», а удерживать спор в предметной плоскости и не давать ему перейти на личности. Инструменты удержания вполне конкретны:

• спорим о вариантах в письменном виде (у варианта нет самолюбия);
• формулируем критерии выбора до обсуждения вариантов;
• «разногласие → эксперимент»: если спор нельзя решить аргументами за 30 минут, договариваемся, какой замер его решит (нагрузочный тест, прототип, A/B);
• явное правило «disagree and commit»: решение принято — публично поддерживаем даже те, кто был против.

5.2. Пять стилей поведения в конфликте

Модель Томаса–Килманна раскладывает поведение по двум осям: напористость (насколько человек продвигает свои интересы) и кооперативность (насколько учитывает чужие) (TKI). Ни один стиль не «правильный» — правильным его делает ситуация.

Читается так: во время инцидента («прод лежит») директивность уместна — обсуждать некогда. При выборе архитектуры уместно сотрудничество — цена ошибки высока, а знания распределены. Из-за цвета кнопки уместно избегание — спор дороже предмета. А при нарушении этических границ кооперативность неуместна вовсе.

Типичная ошибка менеджера — иметь один стиль на все случаи. Всегда-сотрудничающий менеджер парализует команду в инциденте; всегда-соперничающий получает молчаливое согласие и саботаж.

5.3. Эскалация и протокол вмешательства

Фридрих Глазл описал эскалацию конфликта как девять последовательных ступеней от «напряжение» до «вместе в пропасть». Важное свойство модели: на каждой ступени работают разные средства. До определённого момента стороны решают сами, потом нужен посредник, потом — административное решение. Попытка «просто поговорить» на поздней ступени не работает.

Отдельно про последний блок. Терпимость к устойчиво токсичному поведению — самый дорогой вид управленческого бездействия: она обходится не одним человеком, а уходом тех, кто рядом. Правило простое: сначала прямой разговор с конкретными наблюдаемыми фактами и сроком на изменение, затем последствия. Без первого шага увольнение несправедливо; без второго — первый шаг пустой.

5.4. Как проводить медиацию

Две детали, которые чаще всего пропускают. Первая: раздельные разговоры до совместного — без них совместная встреча превращается в первое публичное столкновение, и стороны защищают лицо. Вторая: пересказ позиции оппонента своими словами — почти магический приём, потому что человек физически не может сформулировать чужую позицию, не поняв её, а понятая позиция перестаёт быть угрозой.

6. Мотивация: что известно, что додумано

6.1. Краткая история вопроса

Важное предупреждение. Пирамида Маслоу — самая известная и одна из наименее подтверждённых моделей в этом списке: обзор Вахбы и Бридвелла не нашёл подтверждения ни иерархии потребностей, ни механизма «удовлетворил нижний уровень — активировался верхний» (Organizational Behavior and Human Performance, 1976). Пользуйтесь ей как метафорой в разговоре, но не как основанием для решений.

6.2. Двухфакторная модель: две разные шкалы

Герцберг обнаружил асимметрию: факторы, вызывающие недовольство работой (зарплата, условия, политика компании, отношения с руководителем), и факторы, вызывающие удовлетворение (достижение, признание, содержание работы, ответственность, рост) — разные, а не полюса одной шкалы (HBR, «One More Time: How Do You Motivate Employees?»).

Критика тоже известна и справедлива: результат может объясняться атрибутивным искажением — люди склонны приписывать успехи себе (содержанию работы), а неудачи внешним обстоятельствам (условиям). Метод «критических инцидентов» это искажение усиливает. Тем не менее практический вывод модели подтверждается опытом и согласуется с SDT: повышение зарплаты убирает раздражение, но не создаёт вовлечённость.

Что это значит для менеджера буквально:

• Не пытайтесь компенсировать деньгами скучную работу, сломанный CI или отсутствие влияния на решения. Это работает несколько месяцев, потом человек уходит — с более высокой зарплатой.
• И наоборот: разговоры о миссии при зарплате ниже рынка на 30% вызывают цинизм.
• Порядок действий: сначала «минусы» в ноль, потом «плюсы» вверх.

6.3. Теория самодетерминации: рабочая рамка

SDT (selfdeterminationtheory.org) — наиболее эмпирически прочная из мотивационных теорий. Три базовые потребности:

Обратите внимание: автономия — это про «как», а не про «что». Приоритеты задаёт бизнес — это нормально и не подрывает мотивацию. Подрывает, когда бизнес заодно диктует техническое решение и срок, не спрашивая исполнителя.

Про внешние награды: мета-анализ Деси, Кестнера и Райана (128 экспериментов, Psychological Bulletin, 1999) показал, что материальные награды, обусловленные выполнением интересной задачи, снижают внутреннюю мотивацию к ней. Эффект не универсален (для скучных рутинных задач он слаб или отсутствует), но для инженерной работы — как раз релевантен. Практический смысл: бонус за «закрытые story points» не ускорит команду, а испортит и мотивацию, и метрику разом — классический закон Гудхарта, о котором подробно в https://courses.digitable.life/post/project-management/07-dora-and-engineering-metrics/.

6.4. Теория ожиданий: диагностика «почему не делают»

Врум предложил мультипликативную модель: мотивация = ожидание (смогу ли я это сделать) × инструментальность (приведёт ли результат к обещанному) × валентность (нужно ли мне это). Мультипликативность и есть весь смысл: ноль в любом множителе обнуляет всё.

def diagnose(expectancy: float, instrumentality: float, valence: float) -> tuple[float, str]:
    """Диагностика мотивации по Вруму. Все аргументы в [0, 1].

    expectancy      — вера человека, что усилие приведёт к результату
    instrumentality — вера, что результат приведёт к обещанному следствию
    valence         — ценность этого следствия лично для него
    """
    score = expectancy * instrumentality * valence
    weakest = min(
        (expectancy, "не верит, что справится → нужны навыки, помощь, декомпозиция"),
        (instrumentality, "не верит обещаниям → нужна история сдержанных обещаний"),
        (valence, "не ценит награду → нужен другой разговор о том, что важно ему"),
        key=lambda pair: pair[0],
    )
    return score, weakest[1]


# «Команда не берётся за техдолг, хотя все согласны, что он мешает»
print(diagnose(expectancy=0.8, instrumentality=0.2, valence=0.9))
# (0.144, 'не верит обещаниям → нужна история сдержанных обещаний')

Диагноз в примере типичен: дело не в лени и не в навыках. Команде уже трижды обещали «в следующем квартале дадим время на техдолг» и трижды не дали — инструментальность близка к нулю, и никакая мотивационная речь её не поднимет. Поднимет только одно сдержанное обещание.

6.5. Что реально делает хорошего менеджера

Google Project Oxygen (re:Work) — то же ограничение, что и у Aristotle (корпоративное исследование), но список поведений совпадает с тем, что видно в практике: хороший менеджер коучит, не занимается микроменеджментом, интересуется человеком, ориентирован на результат, умеет слушать и делиться информацией, помогает карьерному развитию, имеет ясное видение, обладает достаточной технической экспертизой, чтобы советовать.

Инструмент №1 из этого списка, доступный сразу, — регулярный 1:1. Что делает 1:1 полезным:

• он про человека, а не про статус задач (статус — в трекере);
• повестку задаёт сотрудник, менеджер приходит со своими 2–3 пунктами максимум;
• частота фиксирована (раз в 1–2 недели) и встреча не отменяется — отмена читается как «ты не важен»;
• есть общий документ с историей: договорённости прошлых встреч видны обоим;
• в нём звучат три вопроса: что мешает работать; чему ты хочешь научиться; что я делаю не так.

7. Знание как актив команды: bus factor

Есть один риск, который прямо вытекает из темы коммуникаций: концентрация знаний. Bus factor — минимальное число людей, чей одновременный уход оставит без владельца больше половины кодовой базы. Его можно не угадывать, а посчитать по истории git.

# Выгрузка: строка с \x01 — автор, дальше идут файлы его коммита
git log --since="12 months ago" --no-merges \
        --pretty=format:'%x01%an' --name-only > /tmp/ownership.txt

from collections import Counter, defaultdict
from typing import Iterable, Iterator


def parse_git_log(lines: Iterable[str]) -> Iterator[tuple[str, str]]:
    """Разбирает вывод git log в пары (автор, файл). O(N) по числу строк."""
    author: str | None = None
    for raw in lines:
        line = raw.rstrip("\n")
        if line.startswith("\x01"):
            author = line[1:]
        elif line and author:
            yield author, line


def primary_owners(touches: Iterable[tuple[str, str]]) -> dict[str, str]:
    """Для каждого файла — автор с наибольшим числом правок.

    Время O(T) по числу пар, память O(F * A_f) — файлы на их авторов.
    Ничьи разрешаются детерминированно: побеждает тот, кто встретился раньше.
    """
    per_file: dict[str, Counter] = defaultdict(Counter)
    for author, path in touches:
        per_file[path][author] += 1
    return {path: c.most_common(1)[0][0] for path, c in per_file.items()}


def bus_factor(owners: dict[str, str], share: float = 0.5) -> tuple[int, list[str]]:
    """Сколько человек надо «потерять», чтобы осиротело больше `share` файлов.

    Жадный алгоритм: O(F + A log A), где A — число авторов.
    """
    if not owners:
        return 0, []
    load = Counter(owners.values())
    total = len(owners)
    covered, critical = 0, []
    for person, files in load.most_common():
        covered += files
        critical.append(person)
        if covered / total > share:
            break
    return len(critical), critical


log = [
    "\x01alice", "core/auth.py", "core/billing.py",
    "\x01alice", "core/auth.py", "core/session.py",
    "\x01alice", "core/queue.py",
    "\x01bob", "web/ui.tsx",
    "\x01carol", "docs/readme.md",
    "\x01bob", "infra/deploy.yaml",
]
owners = primary_owners(parse_git_log(log))
print(bus_factor(owners))   # (1, ['alice'])

Оговорки к метрике обязательны, иначе она превратится в оружие:

• Число правок — грубый прокси владения знанием. Автор, написавший модуль один раз идеально, выглядит слабее того, кто его чинит еженедельно.
• Файлы неравноценны: docs/readme.md и core/billing.py считаются одинаково. Взвешивайте по критичности или хотя бы исключайте сгенерированный код, локали и вендоринг.
• Метрику нельзя показывать в отрыве от контекста и нельзя привязывать к оценке людей — иначе начнутся косметические коммиты в чужие файлы.

Что делать с результатом: парное программирование на «сиротеющих» участках, ротация дежурств, обязательное ревью от второго владельца области, и в первую очередь — записанные решения (см. ADR). Bus factor — это тема риск-менеджмента (https://courses.digitable.life/post/project-management/04-risk-management/), просто с человеческим лицом.

8. Типичные ошибки

1. Найм как ответ на срыв срока. Разобрано в разделе 1.2: в лучшем случае бесполезно, в типичном — вредно.
2. Гашение предметного спора ради «здоровой атмосферы». Спор не исчезает, он уходит в пассивную агрессию на код-ревью и в решения, принятые в приватных чатах.
3. Терпимость к устойчиво токсичному человеку из-за его квалификации. Считайте полную цену: уходят те, кто рядом, и уходят молча.
4. Мотивация деньгами вместо устранения гигиенических проблем — и обратная ошибка, разговоры о миссии при зарплате сильно ниже рынка.
5. Обратная связь только на перформанс-ревью. Обратная связь с задержкой в полгода не обратная связь, а приговор. Правило: неожиданностей на ревью быть не должно.
6. Метрики людей вместо метрик системы. Индивидуальные story points, строки кода, число коммитов — всё это оптимизируется мгновенно и разрушает сотрудничество. Меряйте поток и систему (https://courses.digitable.life/post/project-management/07-dora-and-engineering-metrics/, фреймворк SPACE).
7. Постоянная переброска людей между командами. Каждый переброс — возврат в storming и обнуление контекста.
8. Менеджер как единственный канал между командой и остальным миром. Удобно ему, но создаёт узкое место и лишает команду связанности с результатом.
9. «У нас плоская структура, у нас нет политики». Отсутствие явной структуры не убирает власть, а делает её неформальной и невидимой — что хуже для новичков и для тех, кто громко не говорит.

9. Как это выглядит в проде: неделя менеджера

Календарь, а не декларации, показывает реальные приоритеты. Рабочая раскладка на команду из 7 человек:

Всё остальное — асинхронно. И принципиальный момент: у команды должно оставаться минимум 2–3 непрерывных часа фокуса ежедневно. Календарь, изрешечённый получасовыми встречами, даёт формально «свободные» 5 часов, из которых полезны ноль.

10. Мини-итог

• Стоимость координации растёт как n(n−1)/2. Отсюда — маленькие команды, слабая связность между ними, письменная культура и осторожность с наймом.
• Закон Конвея работает в обе стороны: проектируйте оргструктуру под желаемую архитектуру.
• Психологическая безопасность — самая эмпирически прочная концепция в этом наборе. Она не про комфорт, а про допустимость межличностного риска; измеряется опросом, строится поведением менеджера.
• Модель Такмана — язык, а не метрика. Storming нормален и повторяется при каждом изменении состава.
• Полезен только предметный конфликт, и то лишь пока он не стал личным. Задача менеджера — удерживать плоскость спора, а не подавлять или разжигать.
• Мотивация: сначала гигиена в ноль, потом автономия/мастерство/смысл. Внешние награды за интересную работу скорее вредят. Диагностируйте по Вруму — ищите обнулившийся множитель.
• Знание — актив с риском концентрации; bus factor считается, но метрику нельзя направлять на людей.

Источники

• Conway M., «How Do Committees Invent?», 1968
• Brooks F., «The Mythical Man-Month»
• Nagappan, Murphy, Basili, «The Influence of Organizational Structure on Software Quality», ICSE 2008
• Edmondson A., «Psychological Safety and Learning Behavior in Work Teams», ASQ 1999
• Tuckman B., «Developmental sequence in small groups», 1965
• De Dreu & Weingart, «Task versus relationship conflict…», JAP 2003
• Deci, Koestner & Ryan, мета-анализ внешних наград, Psych. Bulletin 1999
• Herzberg F., «One More Time: How Do You Motivate Employees?», HBR
• Wahba & Bridwell, «Maslow Reconsidered», 1976
• Karau & Williams, мета-анализ социальной лености, JPSP 1993
• Lindenfors et al., критика числа Данбара, R. Soc. Open Sci. 2021
• Self-Determination Theory — официальный сайт
• Team Topologies — ключевые концепции
• Thomas–Kilmann Conflict Mode Instrument
• Google re:Work — Understanding team effectiveness
• SPACE framework, ACM Queue 2021
• Книги без свободных ссылок: Lencioni P., «The Five Dysfunctions of a Team» (практическая модель без независимой эмпирической проверки — полезна как язык); Patterson et al., «Crucial Conversations»; Scott K., «Radical Candor»; Fisher & Ury, «Getting to Yes» (основа медиации из раздела 5.4).

Что дальше

Мы разобрали, кто и как делает работу. Следующий шаг — договориться, что считается сделанной работой, и как она безопасно доезжает до пользователя: Качество, Definition of Done и релизный менеджмент.