EN version of this blogpost is here

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

Для начала стоит прояснить, что такое “здоровый конфликт”. Здоровый конфликт (далее “конфликт”) - это противостояние двух противоположных интересов для достижения результата между ними где-то посередине, и при этом участники конфликта не переходят в прямую конфротацию. Люди понимают, что конфликт нужен для достижения результата и не переходят на личности.

Люди понимают, что конфликт нужен для достижения результата и не переходит на личности.

Конфликты в айти

В айти-проекте конфликт присутствует между заказчиком и командой-исполнителем, куда включаем и проектного менеджера. Заказчик хочет сделать как можно больше задач за как можно меньшие деньги. Команда же хочет работать меньше и получить больше денег. Где-то посередине достигается баланс ресурсов и объема работ, что в итоге и разрабатывают исполнители. Проектный менеджер в этом противостоянии встает на сторону команды. Его задача — объяснить, почему они не сделают больше объема работы за те же или меньшие деньги. Менеджер мониторит метрики прогресса команды, проводит переговоры и закрепляет документами договоренности. Умелый менеджер использует числа и показатели, чтобы они становились весомым аргументов в переговорах.

Внутри команды разработки также присутствуют конфликты:

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

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

Тестирование доказывает, что продукт не работает так, как нужно клиенту. Чем больше багов тестировщики найдут, тем лучше. Тестировщику не должен нравиться продукт, над которым он работает — всегда есть то, что можно улучшить еще и еще. Тестировщики — это не один из уровней Quality Gate для деплоя на продакшн, они не говорят: “Подтверждаем качество”. И без тестировщиков разработчик скажет, что продукт готов к деплою. Если тестировщик соглашается во всем с разработчиком, значит тестировщик делает свою работу неправильно.

Чем больше багов, тем лучше и тем эффективней работает тестировщик.

Тестировщик ищет как можно больше багов, оформляет их в багрепорты и записывает в тикет-систему, присваивет уровни критичности. Чем больше багов, тем лучше и эффективней работает тестировщик. Во время деплоя проектный менеджер решает, где наступает тот самый баланс между качеством продукта и усилием команды над его выпуском. Менеджер изучает найденные баг-репорты и присваивает им приоритет исполнения: какие фиксим в первую очередь, какие - откладываем вниз бэклога.

Конфликт между репозиторием и разработчиками

Разработчик хочет написать как можно быстрее фичу и перейти к следующей задаче, но репозиторию важно качество заливаемого в него кода. Техлид как представитель репозитория настраивает правила приемки нового кода в дефолтовую ветку таким образом, чтобы разработчику было как можно сложнее залить некачественный код: с нарушением стилей, с зафейленными юниттестами, без понятной и поддерживаемой архитектуры. Для этого настраивают пайплайны Continious Integration и декларируют правила код-ревью.

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

Репозиторий кода — не друг разработчику, он хочет получать только качественный код от них. Задача проектного менеджера заключается в том, чтобы проследить за правильной настройкой репозитория и пригласить, например, независимого техлида для этого.

Конфликт между проектным менеджером и командой

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

Проектный менеджер настраивает взаимодействие между участниками процесса таким образом, чтобы проект доставили заказчику вовремя и в должном объеме.

У проектного менеджера для этого пользуется разными наборами инструментов и практик:

  • собирает встречи для оценки сложности задач,
  • настраивает тикет-систему так, чтобы видеть необходимые отчеты и показатели,
  • мониторит метрики прогресса команды и отдельных ее участников,
  • проводит оценку 360 и performance review,
  • закрепляет договоренности в документах и письмах.

Хороший менеджер отличается от плохого тем, что он свое мнение подкрепляет цифрами и фактами.

Почему важно не забывать о конфликте

Люди как участники команды разработки проекта понимают, что их общая задача — это доставка проекта заказчику. Однако часто забывают, что у каждого из них свои цели для достижения общего результата. И еще чаще эти цели находятся по разные стороны баррикад.

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