Привет, Хабр! Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу такое каждый месяц на работе:

«Зачем нам QA? Разработчики сами протестируют.»
«Зачем менеджер? Мы сами разберёмся, мы же взрослые.»

Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает.

Что будет, если убрать дирижёра

Уже пробовали

Вообще, оркестры без дирижёра - это не фантазия. В Москве в 1922 году скрипач Лев Цейтлин создал Персимфанс (Первый симфонический ансамбль) - оркестр без дирижёра. Идея красивая: равенство, никаких иерархий, все решают вместе.

И знаете что? Они реально играли хорошо. Получили звание «Заслуженный коллектив Республики», давали 70+ концертов в сезон. Дирижёр Отто Клемперер назвал их исполнение «Патетической» Чайковского «самым совершенным». По их примеру создавали оркестры в США и Германии.

Но была цена:

Репетиции отнимали в разы больше времени - камерно-ансамблевые методы, бесконечные дискуссии по интерпретации.
Роль дирижёра всё равно частично выполнял концертмейстер - сидел на возвышении лицом к оркестру.
В 1932 году ансамбль закрыли (по политическим причинам, но это отдельная история).

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

Оркестр = команда разработки

Я для себя тогда в зале нарисовал такую табличку (мысленно, конечно):

Оркестр	IT-команда
Музыканты	Разработчики
Ноты	ТЗ / спецификация
Дирижёр	Менеджер (PM / Team Lead)
Слушатель	Пользователь
Репетиция	Спринт
Концерт	Релиз
Фальшивая нота	Баг
Музыкальный критик	QA

Аналогия кривоватая, конечно, но суть ловит. Скрипач видит только свою партию. Гобоист - свою. Каждый играет хорошо. Но кто слышит, как всё звучит вместе? Дирижёр.

В IT то же самое. Фронтендер написал красивый компонент. Бэкендер - чистый API. А вместе оно не работает, потому что формат данных не совпадает. И кто это заметит? Точно не тот, кто писал свой кусок.

«Разработчики сами могут тестировать» - и другие дорогие заблуждения

Я такое лышу постоянно. И каждый раз хочется спросить: «А вы когда-нибудь свой текст вычитывали сразу после написания? Много опечаток нашли?»

Слепота автора

Мозг дочитывает за вас. Написали «привте» - глаз видит «привет». Это не лень, так мозг работает.

С кодом всё один в один. Разработчик знает, как функция должна работать, и тестирует именно этот сценарий:

// Разработчик написал:
function divide(a, b) {
  return a / b;
}

// Разработчик проверяет:
divide(10, 2)  // 5. Работает, ок

// А QA проверяет:
divide(10, 0)     // Infinity. Упс
divide("abc", 2) // NaN. А валидация где?
divide(10)        // NaN. Забыли аргумент

Разработчик проверил то, что задумал. QA проверил то, что может пойти не так. Разные задачи, разный взгляд.

Эффект IKEA

Есть такой психологический баг (да, у людей тоже баги): вам нравится то, что вы сделали сами. Собрали шкаф из IKEA - он для вас шикарный, хотя дверца не закрывается и одна полка кривая.

С кодом то же. Разработчик подсознательно ищет подтверждение, что всё работает. QA ищет подтверждение, что что-то сломано. Разный настрой, если хотите. Кто-то должен быть тем самым занудой, который говорит: «А если вот так?»

Стоимость бага

Когда нашли	Цена исправления	В терминах оркестра
При написании кода	x1	Музыкант сам заметил на репетиции
На code review	x3	Коллега поправил
QA нашёл	x10	Дирижёр остановил генеральную репетицию
На стейджинге	x30	Заметили на пресс-показе
В проде	x100	Фальшивая нота при 2000 зрителях

Точные множители зависят от проекта, но порядок подтверждается исследованиями IBM Systems Sciences Institute и NIST. Баг в проде - это не просто «пофиксим». Это откат, хотфикс, ночная смена, злые пользователи и пост в Twitter.

Из практики: на e-commerce проекте я нашёл баг в расчёте скидок. При определённой комбинации товаров скидка удваивалась. Разработчик тестировал с одним товаром - у него всё ок. Я добавил три товара с разными акциями - и привет, бесплатная доставка + двойная скидка. Если бы это ушло в прод, компания теряла бы деньги каждый день, и никто бы не понял почему.

«Зачем менеджер? Мы сами разберёмся»

Ага. Давайте посмотрим, что дирижёр делает на самом деле (спойлер: не просто машет палочкой).

Дирижёр	Менеджер
Выбирает, как интерпретировать произведение	Расставляет приоритеты - что делаем, что нет
Задаёт темп	Контролирует скорость спринта
Синхронизирует 80 человек	Синхронизирует фронт, бэк, QA, дизайн
Слышит общую картину - баланс звука	Видит общую картину - как фичи связаны
Разруливает конфликты между секциями	Разруливает конфликты между людьми
Общается с организаторами	Общается с бизнесом и заказчиком

Ничего из этого - не «перетащить таск в Jira». Но почему-то именно так многие представляют работу менеджера.

Три сценария без менеджера (все реальные)

«У нас нет блокеров»

Дейли. Все говорят «всё ок». Через неделю оказывается, что бэкенд сделал API с одним форматом дат, а фронт ожидал другой. Две недели работы коту под хвост. Менеджер бы это увидел на уровне задач ещё в понедельник.

«Мы же договорились»

Обсудили на кухне. «Давай сделаем так.» Через месяц: «Мы такого не обсуждали.» Н��т менеджера - нет фиксации решений. В оркестре это как если бы музыканты договорились «играть побыстрее», но один ускорился на 10%, а другой на 30%.

«Мы сами расставим приоритеты»

Один разработчик хочет рефакторить. Второй - попробовать новый фреймворк. Третий - закрыть техдолг. Все по-своему правы. Но бизнесу нужна конкретная фича к пятнице. Без менеджера команда делает то, что интересно, а не то, что нужно.

А как же самоорганизация?

Да, работает. Но с нюансами.

Камерный квартет - 4 музыканта - прекрасно обходится без дирижёра. Они видят друг друга, слышат друг друга, реагируют мгновенно. Играют вместе годами.

Что нужно	Камерный ансамбль	IT-команда
Размер	3-5 человек	3-5 разработчиков
Опыт	Виртуозы, играют вместе годами	Сеньоры, работают вместе давно
Понимание целого	Все знают произведение целиком	Все понимают продукт и бизнес
Коммуникация	Зрительный контакт	Сидят рядом, постоянно общаются
Сложность	Небольшой репертуар	Стабильный, понятный проект

Но когда квартет вырастает до оркестра - всё ломается.

Есть формула Брукса: число каналов коммуникации = n(n-1)/2. При 3 людях это 3 канала. При 12 - уже 66. При 20 - 190. Попробуйте синхронизировать 190 каналов без координатора. Удачи.

QA - не «тот, кто кликает кнопки»

Знаете, кто в зале самый внимательный слушатель? Музыкальный критик. Он сам не играет. Но он слышит то, чего не слышат музыканты: тромбон чуть опоздал, баланс между секциями поплыл, в третьей части темп уехал.

Музыканты этого не замечают - они внутри процесса. Критик слушает со стороны.

QA делает то же самое. Разработчик внутри кода. QA смотрит снаружи, как пользователь. И видит то, что изнутри не видно.

Случай из практики

На проекте перед релизом все были уверены: готово. Unit-тесты зелёные, code review пройден, каждый разработчик свой модуль проверил.

Я сел проходить E2E-сценарий. Зарегистрировался, выбрал курс, начал урок, дошёл до теста... и приложение легло. Причём падало только при определённой последовательности: именно этот курс, именно после этого урока, именно при первой попытке теста.

Ни один разработчик это бы не нашёл, потому что каждый тестировал только свой кусок. А пользователь проходит весь путь целиком.

Антипаттерны, которые я видел лично

«QA подключим в конце»

Дирижёр приходит на каждую репетицию, а не за час до концерта. В IT почему-то нормально подключить QA в последний день спринта: «Мы всё сделали, проверь до пятницы.» И потом удивляются, что релиз уезжает.

QA нужен с самого начала. Подход называется Shift Left:

Плохо:Требования → Разработка → [в конце] QA → Релиз

Нормально:
Требования [+ QA] → Разработка [+ QA ревью] → Тестирование → Релиз

Когда QA читает требования на старте, он ловит противоречия до того, как написана первая строчка кода. Я так однажды нашёл, что два пункта в ТЗ друг другу противоречили - разработчики обнаружили бы противоречие только при мерже.

«Менеджер = надзиратель»

Плохой менеджер: «Почему задача не закрыта? Где отчёт? Обновите статус.»

Нормальный менеджер: «Вижу, что задача залипла - я поговорил с соседней командой, они разблокировали. Делайте спокойно, я разберусь с бизнесом.»

Разница - как между дирижёром, который тычет палочкой в каждую ошибку, и дирижёром, который ведёт за собой.

«Каждый сам себе QA»

Когда разработчик тестирует свой код, он:

Пропускает edge cases (слепота автора, помните?)
Торопится - «да я и так знаю, что работает»
Проверяет реализацию, а не поведение

Unit-тесты отлично. Но это не замена QA. Как разминка не заменяет саму тренировку.

Когда QA и менеджер реально не нужны

Я не фанатик. Бывают ситуации, когда можно обойтись:

Без QA:

MVP, хакатон, прототип
2-3 сеньора с хорошей культурой тестирования
95%+ покрытие автотестами и зрелый CI/CD
Внутренний тул, который видят 5 человек

Без менеджера:

Команда из 3-4 человек, которые давно вместе
Понятный, стабильный скоуп
Нет внешних заказчиков
Все в курсе, зачем делают то, что делают

Но таких команд мало. Как камерных квартетов в мире музыки - единицы. Большинство проектов - это оркестр.

Как это выглядит, когда всё работает

На том концерте был один момент, который я запомнил. Переход между частями симфонии. Тишина. Пауза секунд пять. Потом дирижёр медленно поднял руки - и 80 человек вступили одновременно. Вот прям в одну долю секунды. Мурашки по коже.

Никакой магии. За всем стоят координация , доверие и понимание, кто за что отвечает.

В IT я видел такие моменты тоже. Когда перед дедлайном все синхронизированы: бэкенд готов, фронт подключился, QA проверил, менеджер согласовал с бизнесом. И фича уходит в прод без единого бага. Редко, но бывает. И бывает только когда каждый делает своё дело.

В оркестре	В IT	Что делает
Дирижёр	PM / Team Lead	Синхронизирует, расставляет приоритеты, разговаривает с бизнесом
Музыканты	Разработчики	Создают продукт, знают своё дело
Критик	QA	Оценивает качество, ищет проблемы до релиза
Зритель	Пользователь	Ему всё равно на ваши процессы. Ему нужен работающий продукт

Вместо итогов

Команда без QA - это как оркестр, где никто не слушает общее звучание. Каждый играет свою партию хорошо, но вместе звучит так себе.

Команда без менеджера - это как оркестр без дирижёра. Можно, если вас четверо и вы вместе 10 лет. Но если вас 15 и проект сложный - будет каша.

Не потому что музыканты плохие. А потому что музыка - больше, чем набор правильных нот.

Если было полезно - плюсуйте. Расскажите в комментах, как у вас: есть выделенный QA и менеджер, или «сами справляемся»? Интересно послушать разный опыт. Следующая статья будет про System Design для QA.

Почему оркестр не играет без дирижёра, а команда — без QA и менеджера