Читать книгу Маленькая красная книга руководителя - Сергей Павленко - Страница 4

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

Неделя 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: Внедрите одно решение. Зафиксируйте результат через две недели.

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