Маленькая красная книга руководителя

Конфликт разработчиков и тестировщиков

Неделя 1. Понедельник. 9:47

Максим Соколов вошёл в переговорку и сразу почувствовал напряжение. Оно висело в воздухе, как перед грозой. Слева сидели три разработчика – Игорь, Денис и Катя. Справа – двое тестировщиков, Олег и Марина. Между ними был стол. И пропасть.

– Максим, мы больше не можем так работать, – начал Игорь, не дожидаясь приветствий. – Мы сдаём код в срок, а они… – он кивнул в сторону тестировщиков, – они находят какие-то мелочи и возвращают всё обратно. У нас дедлайн через неделю!

– Мелочи? – Олег выпрямился. – Ты называешь «мелочью» то, что форма оплаты падает при вводе спецсимволов? Это критический баг! Клиенты не смогут оплатить!

– Это граничный случай! – взорвался Денис. – Кто вводит знак доллара в поле «Имя»? Нормальные пользователи так не делают!

– А ненормальные делают, – спокойно ответила Марина. – И потом мы получаем жалобы в саппорт. Вы хотите, чтобы я пропустила баг, а через месяц заказчик устроил скандал?

Катя, единственная, кто молчал, устало потёрла виски. Максим видел: она на грани. Ещё немного – и она напишет заявление. Третье за месяц.

– Стоп, – Максим поднял руку. – Давайте по порядку. Что именно произошло?

Игорь открыл ноутбук и ткнул пальцем в экран:

– Вот таска. Мы закрыли её в пятницу, отправили на тестирование. Сегодня утром Олег вернул её с пометкой «Не принято». Причина: «Недостаточно тест-кейсов». Максим, мы написали код! Это их работа – писать тесты!

– Нет, – Олег качал головой. – Наша работа – проверять то, что работает. А вы сдаёте код, в котором даже базовая валидация не реализована. Мы не волшебники.

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

– Хорошо, – он сделал паузу. – Давайте встретимся завтра. Я подумаю, как нам выйти из этого.

Разработчики вышли, громко хлопнув дверью. Тестировщики ушли молча. Максим остался один в переговорке, уставившись в свой ноутбук.

«Я не справляюсь», – подумал он. Три недели назад его назначили руководителем проектного офиса. Тогда это казалось повышением. Сейчас – капканом.

В обед к нему зашла Лена, аналитик компании. Они вместе учились в универе, и она была одним из немногих людей, с кем Максим мог говорить откровенно.

– Видела твоё совещание через стеклянную стену, – сказала она, ставя на стол две кружки кофе. – Разработчики против тестировщиков?

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

Лена задумалась.

– Ты пытаешься решить конфликт между людьми. А может, проблема не в людях?

– То есть?

– Слушай, я недавно эксперементировала с ChatGPT. Не для того, чтобы он за меня думал, а чтобы структурировать собственные мысли. Попробуй подойти к проблеме как к системе, а не как к двум группам обиженных людей.

Максим скептически поднял бровь:

– ChatGPT? Серьёзно? Я просто попрошу его: «Реши мой конфликт»?

– Нет. Ты попросишь его помочь тебе увидеть то, чего ты не видишь. – Лена открыла свой ноутбук. – Знаешь теорию про пять измерений деятельности? Функция, процесс, материал, структура и время. Любая проблема управления – это конфликт в одном из этих измерений. Или сразу в нескольких.

Максим вспомнил: что-то такое он слышал на тренинге по системному мышлению. Но тогда это казалось абстракцией.

– И что мне с этим делать?

– Опиши ChatGPT ситуацию и попроси разобрать её по этим измерениям. Не как конфликт личностей, а как конфликт в системе деятельности.

Вечером, когда офис опустел, Максим открыл ChatGPT. Он чувствовал себя немного глупо, но альтернатив не было. Он начал печатать:

«У меня конфликт между командой разработчиков и командой тестировщиков. Разработчики обвиняют тестировщиков в том, что те придираются к мелочам и срывают дедлайны. Тестировщики обвиняют разработчиков в том, что они сдают сырой код и не хотят нести ответственность за качество.

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

Он нажал Enter и откинулся на спинку кресла. Через несколько секунд на экране появился ответ:

Анализ конфликта по пяти измерениям деятельности:

1. ФУНКЦИЯ (для чего существуют команды)

Противоречие: У разработчиков и тестировщиков разные понимания своей функции.

– Разработчики считают, что их функция – «написать код, который выполняет требования». Они измеряют успех количеством закрытых задач.

– Тестировщики считают, что их функция – «защитить заказчика от багов». Они измеряют успех качеством того, что попадает в продакшн.

Обе функции правильные, но не согласованы на уровне системы. Никто не определил: что важнее – скорость или качество? Или как их балансировать?

2. ПРОЦЕСС (как протекает работа)

Противоречие: Процесс передачи кода не формализован.

– Разработчики сдают код, когда считают, что «он работает». Критерии «работает» не определены.

– Тестировщики не знают, что именно должно быть реализовано. Они проверяют всё подряд, включая граничные случаи, о которых разработчики не думали.

Нет единого понимания «Definition of Done» – когда задача считается готовой.

3. МАТЕРИАЛ (люди и их состояние)

Противоречие: Люди находятся в состоянии стресса и взаимных обвинений.

– Разработчики чувствуют, что их работу обесценивают.

– Тестировщики чувствуют, что их не уважают.

Обе стороны защищаются, что усиливает конфликт.

4. СТРУКТУРА (как организовано взаимодействие)

Противоречие: Команды физически и организационно разделены.

– Разработчики сидят в одном углу офиса, тестировщики – в другом.

– Взаимодействие происходит через таск-трекер, а не напрямую.

– Нет общих встреч или совместной работы.

Структура создаёт эффект «мы против них».

5. ВРЕМЯ (операционное vs историческое)

Противоречие: Разработчики работают в операционном времени (дедлайны, спринты), а тестировщики пытаются войти в историческое (долгосрочное качество продукта).

– Разработчики думают: «Надо сдать сейчас, потом поправим».

– Тестировщики думают: «Если сдадим плохо, потом будет ещё хуже».

Максим читал текст и чувствовал, как что-то переключается в его голове. Он видел этот конфликт как спор двух людей – Игоря и Олега. А это был конфликт системы. Функции не согласованы. Процесса нет. Структура разделяет. Время конфликтует.

Он снова написал в ChatGPT:

«Что мне делать? С чего начать?»

Ответ пришёл быстро:

«Начните с согласования функции и процесса. Проведите совместное совещание, где обе команды ответят на вопросы:

1. Какова общая цель? (Например: «Сдать заказчику продукт, который работает и не вызывает жалоб»)

2. Что значит «задача готова»? (Definition of Done)

3. Как мы передаём код друг другу? (Процесс, чек-лист)

После этого работайте со структурой: создайте кросс-функциональные пары (разработчик + тестировщик работают вместе над задачей).»

Неделя 1. Среда. 10:00.

Максим снова собрал команды в переговорке. Но на этот раз он подготовился.

– Коллеги, – начал он, – в понедельник мы пытались выяснить, кто прав. Сегодня мы будем выяснять, что сломано в нашем процессе.

Игорь скрестил руки на груди. Олег смотрел настороженно.

– У меня вопрос к вам обоим, – продолжил Максим. – Какова наша общая цель? Не цель разработки и не цель тестирования. А общая.

Повисла пауза. Потом Катя неуверенно сказала:

– Сдать заказчику продукт, который… работает?

– И не вызывает жалоб, – добавила Марина.

Максим записал это на доске:

«Сдать продукт, который работает и не вызывает жалоб».

– Хорошо. Теперь второй вопрос: когда задача считается готовой? Игорь, по-твоему?

– Когда код написан и проходит базовые тесты.

– Олег?

– Когда код проверен на всех граничных случаях и соответствует требованиям.

Максим кивнул:

– Видите? У вас разное понимание «готовности». Давайте создадим общее. Это называется Definition of Done.

Он открыл ноутбук и вывел на экран список, который подготовил с помощью ChatGPT:

Definition of Done (DoD):

– Код написан и соответствует требованиям задачи.

– Код покрыт базовыми unit-тестами (разработчик пишет сам).

– Код прошёл code review коллегой.

– Тестировщик получил список того, что должно работать (чек-лист от разработчика).

– Тестировщик проверил функционал по чек-листу + граничные случаи.

– Баги категории «критический» и «высокий» исправлены до релиза.

– Это не final version, – сказал Максим. – Это draft. Давайте обсудим и допишем вместе.

Следующие полчаса они спорили, дополняли, вычёркивали. Но это был другой спор – не обвинений, а совместного создания правил.

В конце Игорь сказал:

– Окей, если у меня будет чек-лист от тестировщиков ещё до того, как я начну писать код, я смогу учесть граничные случаи сразу.

Олег кивнул:

– А если вы будете писать базовые тесты сами, я смогу сосредоточиться на сложных сценариях.

Максим почувствовал облегчение. Что-то сдвинулось.

– Ещё одно, – добавил он. – Со следующей недели мы создаём пары: один разработчик + один тестировщик работают над задачей вместе. Не передаём через таск-трекер, а обсуждаем вживую.

Денис нахмурился:

– Это ж замедлит работу?

– Или ускорит, – возразила Марина. – Я сразу скажу, где могут быть проблемы. А не через три дня, когда ты уже всё написал.

Неделя 3. Пятница.

Максим сидел за своим столом и смотрел на дашборд Jira. Количество возвратов задач с тестирования упало на 40%. Время цикла «разработка → тестирование → готово» сократилось на 2 дня.

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

Максим открыл ChatGPT и написал:

«Спасибо. Сработало».

Нейросеть, конечно, не ответила на благодарность. Но Максим понял: инструмент – это не тот, кто решает за тебя. Инструмент – это то, что помогает тебе увидеть систему, когда ты видишь только людей.

ПРАКТИЧЕСКОЕ ЗАДАНИЕ ДЛЯ ЧИТАТЕЛЯ

Упражнение: Анализ вашего конфликта через пять измерений

Вспомните недавний конфликт в вашей команде. Откройте ChatGPT (или другую нейросеть) и используйте этот промпт:

«Проанализируй конфликт между [Сторона А] и [Сторона Б].

[Краткое описание ситуации – 3—5 предложений].

Разбери проблему по пяти измерениям:

1. Функция – какие разные цели у сторон?

2. Процесс – где ломается взаимодействие?

3. Материал – какие люди вовлечены, что они чувствуют?

4. Структура – как организовано взаимодействие?

5. Время – есть ли конфликт между текучкой (операционное время) и развитием (историческое время)?

Предложи 3 системных решения».

Шаг 1: Запишите ответ нейросети в блокнот.

Шаг 2: Ответьте себе честно:

– Согласны ли вы с анализом?

– Что вас удивило?

– Какое из трёх решений вы можете внедрить на следующей неделе?

Шаг 3: Внедрите одно решение. Зафиксируйте результат через две недели.

Помните: нейросеть не решает за вас. Она помогает вам мыслить структурно, когда эмоции мешают увидеть систему.

Мотивация умирает в тишине

Неделя 3. Среда. 14:32

Максим вернулся с обеда и увидел на столе белый конверт. Такие конверты в «СофтГраде» означали только одно – заявление об увольнении.

Он открыл. Имя в шапке документа заставило его сердце пропустить удар: Антон Ковалёв. Senior-разработчик. Лучший архитектор в команде. Человек, который знал кодовую базу лучше, чем кто-либо другой. Человек, без которого проект может просто встать.

Максим схватил телефон и набрал Антона. Тот ответил со второго гудка:

– Максим, я знаю, зачем ты звонишь. Давай сразу начистоту: я всё обдумал. Решение принято.

– Антон, подожди. Давай встретимся. Хотя бы поговорим. Пятнадцать минут.

Пауза. Потом тяжёлый вздох:

– Ладно. Приходи в переговорку на третьем. Я там.

Антон сидел у окна, глядя на серое небо над Москвой. Максим закрыл за собой дверь и сел напротив.

– Антон, что случилось? Зарплата? Конкуренты переманивают?

Антон покачал головой:

– Зарплата нормальная. Даже выше рынка. И конкуренты не звонили.

– Тогда в чём дело? Проект тебе не интересен?

– Проект интересный. – Антон наконец посмотрел на Максима. – Просто… я не понимаю, зачем я здесь нужен.

Максим растерялся:

– Как «зачем»? Ты лучший разработчик. Ты делаешь архитектуру. Без тебя проект…

– Максим, – перебил Антон, – в прошлом квартале я получил премию двадцать тысяч рублей. В позапрошлом – сорок. В этом – десять. Я спросил у HR: «За что конкретно?» Мне ответили: «По итогам работы». Какие итоги? Я закрыл больше задач, чем кто-либо. Я провёл рефакторинг критического модуля. Я обучал двух джунов. А получил меньше всех.

Максим вспомнил: да, премии начислял финансовый директор на основе «общих показателей команды». Конкретных критериев не было.

– Антон, я понимаю…

– Нет, не понимаешь. – Голос Антона стал тише, но жёстче. – Знаешь, что я чувствую? Что моя работа – это лотерея. Сегодня я получу премию, завтра нет. И я не знаю почему. Я не знаю, что мне делать, чтобы меня ценили. Поэтому я ухожу туда, где правила понятны.

Максим молчал. Он понял: проблема не в деньгах. Проблема в том, что Антон не видел связи между своими действиями и результатом. Он работал в темноте.

– Дай мне неделю, – сказал Максим. – Одну неделю. Если я не исправлю ситуацию – уйдёшь без претензий.

Антон долго смотрел на него. Потом кивнул:

– Неделя. Но я не верю, что что-то изменится.

Вечером Максим сидел в опустевшем офисе и смотрел в экран ноутбука. Проблема была глубже, чем он думал. Он открыл файл с премиями за последний год. Суммы скакали хаотично. Никакой логики. Никакой системы.

Он вспомнил разговор с Леной про нейросети. Тогда это помогло с конфликтом. Может, поможет и сейчас?

Максим открыл ChatGPT и начал печатать:

«У меня проблема с мотивацией команды. Мы платим премии, но люди не понимают, за что они их получают. Один из лучших сотрудников уходит именно по этой причине – он не видит связи между своей работой и признанием.

Стандартные KPI (количество закрытых задач) не работают, потому что они не учитывают качество работы, помощь коллегам, обучение джунов и другие важные вещи, которые невозможно измерить цифрами.

Я читал про компанию «Простые решения», которая внедрила систему мотивации «4+" с элементами самооценки. Помоги мне разработать похожую систему для IT-команды из пятнадцати человек. Критерии: прозрачность, связь между действиями и результатом, учёт не только количественных, но и качественных показателей».

Он нажал Enter и стал ждать. Через несколько секунд на экране появился длинный ответ. Максим начал читать:

Разработка системы мотивации «4+" для вашей команды:

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

Принцип «4+" означает:

Раз в квартал каждый сотрудник оценивает себя по 4 критериям. Максимальная оценка – 5 баллов по каждому критерию. Плюс (+) означает, что есть комментарий – что конкретно человек сделал.

Для вашей IT-команды предлагаю следующие 4 критерия:

1. Результативность – выполнение задач в срок и с нужным качеством.

– 5 баллов: все задачи закрыты в срок, нет критических багов

– 3 балла: были задержки или доработки

– 1 балл: задачи не выполнены

2. Качество кода – техническое совершенство работы.

– 5 баллов: код проходит code review с минимальными замечаниями, покрыт тестами, читаем

– 3 балла: есть замечания, но в целом приемлемо

– 1 балл: код требует значительных доработок

3. Командность – помощь коллегам, менторство, вклад в общую культуру.

– 5 баллов: активно помогает джунам, проводит code review, делится знаниями

– 3 балла: помогает по запросу

– 1 балл: работает изолированно

4. Инициативность – предложения по улучшению процессов, инструментов, продукта.

– 5 баллов: предложил и реализовал улучшение (автоматизация, оптимизация)

– 3 балла: предлагал идеи

– 1 балл: не проявлял инициативу

Процесс оценки:

– В конце квартала сотрудник заполняет форму: ставит себе оценку по каждому критерию + пишет комментарий (что конкретно сделал).

– Руководитель читает самооценку и проводит встречу 1-on-1 (15—30 минут).

– На встрече обсуждают:

– Что получилось хорошо (конкретные примеры)

– Одну главную точку роста

– Задачу на следующий квартал

– Премия рассчитывается по формуле: (Сумма баллов / 20) × Базовая премия.

Важно: Это не экзамен. Это диалог. Если сотрудник поставил себе 5, а руководитель видит 3 – обсуждают, почему восприятие различается.

Максим дочитал и почувствовал облегчение. Это было не идеально, но это была система. Понятная. Прозрачная. Справедливая.

Он снова написал в ChatGPT:

«Помоги конкретизировать критерии под Антона. Он Senior-разработчик, архитектор. В последнем квартале он: закрыл 23 задачи (больше всех в команде), провёл рефакторинг критического модуля платежей (сократил время обработки на 40%), обучал двух джунов, проводил code review для всей команды. Как бы ты оценил его работу по новой системе?»