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

Как-то раз я познакомился с командой, которая уже 5 лет пилила внутренние проекты силами 4 человек. У них был довольно уютный технический мир, в котором разработчики занимались исключительно кодом, без погружения в цели и "бизнес"-составляющую. И надо сказать, очень много правильных вещей делали: классная архитектура, вылизанный код, подробные тикеты!
Вот только все критичные знания о проекте были в голове овнера и тимлида, а фидбэк от пользователей был максимум в ключе "какого фига не работает?".

Как водится, были и розовые очки: на всём этом висел лейбл "девопс" (ведь ci и iac есть!), а рабочий процесс назывался "гибкой методологией". Гибкая методология в понимании овнера — это когда все его слушаются.

Вот только почему-то когда раз в месяц релизился огромный релиз — пользователи тупо игнорировали нововведения.

Как? Почему? Может пользователи плохие?

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

- Подтолкнуть команду больше общаться с пользователями, помогать решать прикладные проблемы и отвечать на крики о помощи. Можно даже ввести "дежурства по ответам на вопросы". Команда сделает много открытий для себя ("они что, НАСТОЛЬКО не понимают проекта?") и каждый из разработчиков сам по себе начнёт глубже понимать продукт.
- Вовлекать команду в обсуждения с овнером, чтобы хоть капелька информации попадала в поле их внимания.
- Попытаться договориться с овнером и командой, о том, что надо сместить фокус внимания с доставки новых фич на внедрение этих фич. И вместе сформулировать, как именно это можно сделать.
- В идеале, конечно, добиться от овнера, чтобы он сам начал общаться с пользователями — сначала "продавал" идею будущих изменений, чтобы было ожидание, а затем трекал внедрение.

Я думаю, что если замыкать на себя экспертизу — ни к чему удивляться, что тебя и твои задумки не понимают и не принимают.