Знакомо ощущение, когда идешь на дейлик с разработчиками, и испытываешь разные чувства для разных команд?

1️⃣Вариант: Заходишь - а там ребята уже в теме. Ты только рот открываешт, а в ответ: «Мы тут уже подумали, как это можно сделать. Смотри, есть нюанс с API, но мы нашли обход. А если вот так изменить формулировку, выйдет быстрее и без костылей». Глаза горят. Они уже «взяли» задачу, как свою. Чувствуешь себя частью экипажа звездолёта, где все вместе ищут путь сквозь астероидное поле. Со-творчество. Общая цель. Они заряжены не меньше тебя.

2️⃣Вариант: Заходишь - тишина. Презентация требований напоминает защиту диплома перед строгой комиссией. Вопросы не «как нам это лучше сделать?», а «а вы точно уверены?», «а если передумаете?», «этого не было в ТЗ». Чувствуется невидимая стена. Кажется, что по ту сторону ждут не успеха продукта, а твоего косяка, чтобы сказать: «Мы же предупреждали».

Работа превращается в матч по пинг-понгу: ты кидаешь требования через сетку, они возвращают оценку. Никакого звездолёта — только договорные обязательства. И не дай бог поменять курс, хоть на 10 градусов.

Почему так происходит? Дело не в «плохих» или «хороших» разработчиках, а в прошлом опыте, процессах и уровне доверия: ☢️ Травмы прошлого: если команду десять раз обжигали резкими сменами курса «по прихоти бизнеса», они строят оборону.

☢️ Процессы как стена: когда общение только через Jira-тикеты, а живого обсуждения нет, рождается отчуждение.

☢️ «Чёрный ящик»: бизнес не делится контекстом «зачем», разработка не делится нюансами «как».

Что делать, если попал во второй вариант?

1. Делиться контекстом. Не «что сделать», а «зачем это нужно пользователю и бизнесу». Какие проблемы и задачи мы решаем. Как наш продукт приносит реальную пользу людям. Приглашать на обсуждения с пользователями.

2. Признавать их экспертизу. Спрашивать: «Как вы видите реализацию? Где подводные камни?» С самого начала.

3. Вместе идти в риски. Не скидывать ТЗ и не сбегать, а сказать: «Ребята, тут гибкая тема, давайте пробовать итеративно и смотреть на данные».

4. Честно про изменения. "Да, я был не прав, данные показали иное. Давайте вместе перегруппируемся" или "Да, бизнес поменял требования, но это связано действительно с изменившимися контекстом". Это снимает напряжение.

В идеале мы стремимся к первому типу. Где команда не исполнитель, а партнёр. Где разработка - главный двигатель продукта, который подхватывает идею и реализует её.

Я видела разных продактов и разные команды разработки, и точно могу сказать, что партнёрство и работа с мотивацией людей - лучшая стратегия.

Да-да, снова продакту надо поработать с чьей-то мотивацией. Ну а кто, если не ты? 😉

А у вас какой опыт? Чаще сталкиваетесь с первым типом или вторым? Что помогло сломать стену?