22 KiB
Конфликт в команде разработки: негативные факторы и план стабилизации
Роль автора: руководитель проекта (вступление в команду на активной фазе)
Стадия проекта: разработка и тестирование функционала; договор с заказчиком подписан; работы идут по план-графику
Команда разработки: два старших разработчика (мидл–сеньор, авторы архитектуры, давно на проекте) и один младший разработчик (недавно в команде). Помимо них в проекте участвуют аналитики и тестировщики
Ниже — разбор рисков для поставки и климата, пошаговый план вмешательства и отдельный регламент взаимодействия, чтобы не решать подобные вещи снова «по сарафану»
Оглавление
- Краткое резюме
- Негативные факторы для проекта и команды
- План по устранению негативных факторов
- Регламент взаимодействия в команде
- Соответствие критериям задания
Краткое резюме
Проект в работе: тесты, дефекты, ожидания заказчика — всё на виду. Двое старших, которые держат архитектуру и давно «свои», публично обсуждают, что младший им не нравится: мол, не понимает задачи, косячит, ещё и «где-то подрабатывает», раз медленно, ну, а что еще подумать?. Эту картину они разносят по чатам и кулуарам. Аналитики и тестировщики смотрят на другую реальность: задачи младшему ставят в его зоне, сроки выдерживаются, претензий к результату у них нет. С младшим вы говорите отдельно — он не подтверждает подработку, но чувствует холод и давление.
Команда распадается на лагеря не по фактам, а по лояльности. Если руководитель молчит, старшие читают это как мандат, младший — как предательство сверху, заказчик в итоге не получает не только код, но и срывы на ревью, скрытые переделки и внезапный отпуск кого-то из ключевых людей. Ниже — факторы риска и план, где есть место и жёсткой стабилизации, и измеримым данным, и формальным правилам общения.
Негативные факторы для проекта и команды
Сводная таблица
| № | Фактор | Что бьёт в первую очередь |
|---|---|---|
| 1 | Токсичная коммуникация и «трибуны» вне процесса | Доверие, фокус на релизе |
| 2 | Расхождение картины мира (старшие vs аналитики/тесты) | Качество решений по людям и задачам |
| 3 | Риск моббинга и юридических/HR-последствий | Люди, репутация компании |
| 4 | Подмена фактов слухами (подработка, «тормозит») | Справедливость, метрики, отток |
| 5 | Срыв передачи знаний и саботаж в невидимых зонах | Код, архитектура, сроки по договору |
| 6 | Политизация вместо инженерной дисциплины | План-график, тестирование, договор |
| 7 | Слабая позиция руководителя как прецедент | Вся команда и следующие конфликты |
Ниже — по смыслу, не одной строчкой.
1. Токсичная коммуникация и эрозия доверия
Жалобы «на человека», а не на конкретный артефакт в тикете, в общих каналах — это уже не обратная связь, а реклама неприязни. Через две недели половина команды знает версию старших, но не знает ни одного номера задачи с дефектом. Доверие к процессу проседает: непонятно, кто вообще решает, что «хорошо», а что «плохо».
2. Раскол нарратива между ролями
Старшие разработчики говорят про «непонимание и плохое качество», аналитики и тесты — про адекватность задач и сроков. Если это не свести к данным, вы как РП будете принимать решения на основе того, кто громче — а это лотерея. В худшем случае перераздадите работу в пользу «своих», а зона младшего останется недогружена — и вы сами создадите реальный провал, которого до конфликта не было.
3. Моббинг, дискриминация по уровню, HR-риски
Два человека с сильной позицией и общей историей против одного новичка — классическая асимметрия власти. Если обвинения в «подработке» идут без доказательств, это не только морально грязно: при фиксации фактов в переписках у работодателя появляются вопросы к культуре и к руководителю, который «не видел». Текучка и больные отпуска в разгар тестирования — не абстракция.
4. Решения по людям на слухах, а не на метриках
«Медленно» без определения единицы измерения — спор не про скорость, а про симпатию. Пока нет согласованных критериев (lead time по типам задач, дефекты после merge, переделки), любая оценка уровня младшего остаётся мнением. Так вы кормите конфликт бесконечностью: доказать «негатив» можно только отсутствием правил игры.
5. Скрытый саботаж в зонах влияния старших разработчиков
Код-ревью, «сложные» участки кода без документации, ответы в чате раз в сутки — всё это может стать инструментом давления без единого грубого слова. Архитекторы знают, где больно. Итог — рост дефектов на границе модулей, сдвиг сроков по договору и объяснения заказчику, которых можно было избежать.
6. Оттягивание ресурса с поставки на «войну»
Сейчас фаза разработки и тестирования: время уходит на обсуждение личностей, встречи «на эмоциях», перепроверку всего, что сделал младший разраб, из принципа. План-график держится на том, что кто-то всё ещё честно закрывает задачи. Перегрев снимает с критического пути человеко-часы — это прямой риск по контракту.
7. Прецедент для остальных: «так можно»
Если руководитель не обозначает границу, команда запоминает не orgchart, а факт: сильный клан задаёт тон. Следующий конфликт будет ещё дешевле эмоционально для инициаторов — и дороже для проекта.
План по устранению негативных факторов
План из четырёх шагов (больше трёх по критерию оценивания); каждый шаг — цель, действия, ответственный, срок, артефакт.
Шаг 1. Стабилизация и остановка токсичного тиража
Цель: снять эскалацию «в эфир», зафиксировать жалобы как рабочие гипотезы, а не как сплетню.
Действия: отдельные встречи 1:1 (кто как называется, 1t1 или f2f) со старшими и с младшим разработчиком; публично (в команде) обозначить: оценка людей и обвинения в недобросовестности без фактов в общих каналах не ведутся — обсуждение идёт через РП и по процессу. Попросить старших разрабов в письменном виде (кратко, по пунктам) сформулировать претензии: задача, ожидание, факт, ссылка на артефакт. Младшему разработчику — безопасная формулировка: вы разбираете ситуацию, а не «ищете виноватого в чате».
Кто: руководитель проекта; при необходимости — подключение HR как нейтральной стороны (если в компании принято).
Срок: 2–3 рабочих дня с момента принятия решения.
Артефакт: короткий протокол 1:1 (для себя или в корпоративном инструменте), письменные тезисы претензий от старших, зафиксированное устное правило по коммуникации (до утверждения полного регламента).
Шаг 2. Сбор фактов и выравнивание ожиданий по уровню
Цель: заменить «нам не нравится» на измеримые показатели и согласовать, какой уровень от младшего ожидается на его задачах.
Действия: выборка по трекеру за последние спринты/итерации: задачи младшего, lead time, переделки после ревью, дефекты после тестирования, сравнение с похожими по сложности задачами у других (если есть). Отдельно — интервью с аналитиками и тестировщиками по фактам приёмки. Совместная сессия РП + старшие: «какие задачи мы считаем junior-уровнем на этом проекте» — и список типов задач, где нужен мидл+.
Кто: РП ведёт; старшие дают экспертизу по архитектуре и сложности; аналитики/тесты подтверждают приёмку.
Срок: 3–7 рабочих дней.
Артефакт: таблица метрик и вывод «ожидания vs факт»; список типов задач для младшего с явным уровнем сложности; при расхождении — решение РП по перераспределению или по плану развития (менторинг), а не по «голосованию двух против одного».
Шаг 3. Фасилитированная встреча и договорённости
Цель: перевести конфликт из личного в рабочий: правила ревью, эскалации, формулировка замечаний.
Действия: общая встреча с повесткой (без сюрпризов): факты из шага 2, правила общения на ревью, запрет персональных ярлыков. Договориться: как эскалировать расхождение «не принимаю ревью» к РП за ограниченное время; как фиксируется недостаток компетенций — через план обучения, а не через унижение в чате.
Кто: РП модерирует; при высокой эмоции — внешний фасилитатор или HR.
Срок: одна встреча 60–90 минут + при необходимости доп. короткая итерация.
Артефакт: протокол с договорённостями; входные данные для регламента (ниже).
Шаг 4. Внедрение регламента и контрольная точка
Цель: закрепить правила в документе, проверить эффект через 2–4 недели.
Действия: публикация регламента (см. следующий раздел) в доступном месте; на контрольной дате — короткий опрос 1:1 или мини-ретро: изменилось ли поведение, есть ли новые инциденты, нужна ли корректировка. При повторении токсичного паттерна — индивидуальный план с HR по старшим, отдельно — поддержка младшего.
Кто: РП; HR по эскалации.
Срок: регламент — в течение недели после шага 3; контрольная точка — через 2–4 недели.
Артефакт: актуальная версия регламента; запись решений после ретро.
Регламент взаимодействия в команде
Ниже — новый регламент (мини-документ для команды проекта; утверждает руководитель проекта, согласовывает с руководителем разработки / HR по политике компании).
1. Критика и обратная связь
- Замечания по работе формулируются по задаче и артефакту: ссылка на тикет, конкретное требование, что не выполнено или выполнено с дефектом.
- Публичные каналы (общий чат команды) не используются для обсуждения добросовестности, личной скорости «вообще» и версий о подработке. Это эскалируется к руководителю проекта с фактами или остаётся в 1:1 с РП.
- Срок ответа на запрос уточнения по задаче в рабочие часы — по договорённости команды (например, до конца следующего рабочего дня для несрочного), срочное — по метке приоритета в трекере.
2. Оценка работы младшего (junior) разработчика
- Критерии годности берутся из типа задач и метрик (сроки, качество после ревью и тестов), а не из «общего ощущения» старших коллег.
- Участие старших — как экспертов по архитектуре и ревью; итоговое решение о соответствии уровня задачам проекта и о плане развития принимает РП на основе данных и обратной связи аналитиков/тестировщиков.
- Пересмотр зоны задач младшего (расширение или сужение) фиксируется письменно в трекере или в минимальном приложении к регламенту, чтобы не было споров «мы ему не доверяем» без изменения формальных правил.
3. Code review и менторинг
- Ревью выполняется по правилам проекта: обязательная конструктивность — что изменить, зачем, с примером или ссылкой на стандарт.
- Назначается наставник из старших (один основной контакт) на срок, оговоренный с РП; вторая линия — архитектурные вопросы ко второму старшему по разделению модулей.
- Частота 1:1 младшего с наставником и с РП — не реже раз в две недели на период адаптации; далее по ситуации.
4. Эскалация конфликтов
- Если спор по ревью не закрывается за один цикл правок и обсуждения в тикете, стороны эскалируют к РП с кратким резюме позиций; РП принимает решение или назначает парное разборное совещание.
- Повторяющееся давление, оскорбления, распространение непроверенных обвинений — немедленная эскалация к РП и в HR по процедуре компании.
5. Сводка «ситуация — действие — срок»
| Ситуация | Что делаем | Срок / ритм |
|---|---|---|
| Негативная ОС вслух по человеку | Остановить, перенести в 1:1 / тикет с фактами | В день инцидента |
| Спор по качеству без критериев | Сверка с типом задачи и метриками | В рамках шага 2 плана |
| Конфликт ревью | Эскалация к РП | После одного неуспешного цикла |
| Риск повторения токсичности | Ретро + при необходимости HR | Через 2–4 недели после внедрения |
Соответствие критериям задания
| Критерий | Как закрыто в документе |
|---|---|
| Негативные факторы (макс. 7 баллов) | Описано семь факторов с последствиями и сценариями; есть сводная таблица. |
| План (макс. 5 баллов) | Четыре последовательных шага с целями, действиями, ответственными, сроками и артефактами. |
| Регламент (макс. 2 балла) | Отдельный раздел «Регламент взаимодействия в команде» с новыми правилами и таблицей эскалации. |
Замечание на полях
Реальная жизнь всё равно подкинет «но он реально тупит» — иногда это правда, иногда это не совпадение ожиданий с грейдом. Разница в том, что без метрик и регламента вы управляете слухами; с ними — рисками проекта и договором.