Слепые зоны часто появляются там, где все уверены и всё предусмотрено: есть документы, схемы, понятная логика. Особенно, если разработка кастомная: готовых шаблонов нет, UI-референсы не помогут, а поведение пользователей ещё только предстоит изучить. И даже когда кажется, что требования собраны верно, на практике могут возникнуть сложности.
Расскажу, как недавно мы почти с нуля пересобрали целые блоки продукта и превратили потенциальный провал в релиз действительно полезного инструмента.
Узкий домен и его сложности
Последний год мы работаем над проектом для компании, которая занимается организацией MICE (выездных корпоративных мероприятий). Задача – создать систему для менеджеров и логистов, где будут включены все этапы подготовки: от добавления участников до управления перелетами, проживанием и трансферами.
Те, кто работает в тревел- или ивент-индустрии, знают: если меняется одна деталь – это отражается на всем проекте. Поэтому продукт получился гибким и комплексным: взаимосвязанные таблицы, логические блоки и постоянное обновление данных. Но… не таким, как клиент изначально ожидал. И вот почему.
Мне архитектура проекта с самого начала виделась нестандартной: на рынке нет готовых аналогов и «подсмотреть» особо было не у кого. Успокаивал себя тем, что клиент хорошо понимает свой домен и процессы. И честно скажу, когда мы только получили техническое задание, я даже немного обрадовался: клиент проделал огромную работу, гораздо больше, чем мы привыкли видеть на старте. И это было круто.
Как мы сверяли гипотезы с практикой
Ещё на этапе подготовки прототипов стала понятно, что проект будет большим и сложным, поэтому наша дизайнер создала дизайн-систему – библиотеку готовых компонентов и правил, чтобы быстро и одинаково создавать интерфейсы в одном стиле. Спойлер: это решение не раз выручало нас по ходу проекта, так как позволяло быстро адаптировать функционал под изменения и упростило сборку продукта для разработчиков.
Весь функционал согласовывали спринт за спринтом несколькими представителями клиента – они курировали проект и принимали ключевые решения. По мере визуализации их требований, появлялись новые вводные: клиент видел, как то, что работало на словах, нельзя было отразить в интерфейсе. А также возвращался к блокам, про которые забыл на этапе первичного описания.
Когда почти готовый продукт увидели стейкхолдеры, стало понятно: логика интерфейсов не всегда совпадает с тем, как работают процессы на практике. Что-то оказалось излишне сложным, что-то – несогласованным, а часть функций вообще не решала реальных задач сотрудников.
И я понимаю, в чем причина – сам продукт разрабатывался, по сути, в «закрытом режиме». Ни одна из команд, которой предстояло работать с инструментом, не видела его на промежуточных этапах.
Передо мной были два пути. Пойти в отказ и просто «допилить» текущую версию, оставив продукт таким, каким он был в первой версии техзадания (вообще не вариант!). Или пойти навстречу и помочь клиенту доработать функционал. Что мы и сделали:
- Организовали фокус-группы с участием сотрудников-стейкхолдеров из разных подразделений;
- Собрали честную и подробную обратную связь;
- Провели несколько сессий с клиентом для пересмотра приоритетов;
- Переработали структуру продукта на основе реальных сценариев.
Даже в таких условиях мы отлично сработались – и с клиентом, и внутри команды.
Несмотря на то, что часть изначального скоупа ушла в бэклог и нам пришлось делать шаг назад, в результате инструмент стал решать те задачи, ради которых он и создавался.
Что мы посоветуем другим командам
Для меня и команды этот проект стал хорошей проверкой на гибкость. Вот что мы поняли и что советуем другим менеджерам, которые столкнулись с похожими ситуациями или хотят их избежать.
Сократите круг решений, но дайте голос всем
Когда со стороны клиента есть 1-2 человека, которые принимают финальные решения – это сильно упрощает процесс. Но важно не замыкать всю логику продукта только на их видении.
Наши рекомендации:
- Соберите мнения от всех ролей, которые будут пользоваться продуктом – используйте короткие опросы и встречи с отдельными группами целевой аудитории;
- Структурируйте всё, что услышали – заведите таблицу с предложениями, укажите, какой сценарий они улучшают и насколько критичны для запуска;
- Покажите клиенту общие выводы и закономерности, чтобы определить приоритеты в доработках.
Шаг 1. Говорите с пользователями до начала разработки
Даже если клиент сам собрал требования, уточните, с какими данными он работал и кто именно давал обратную связь на промежуточную версию продукта. Часто за «пользовательской экспертизой» стоят только 2-3 человека. А реальные сценарии могут быть совершенно другими. Иногда достаточно короткого опроса широкой группы, чтобы понять, как разные роли взаимодействуют с системой и какие сценарии точно нужно предусмотреть.
Наши рекомендации:
- Проверьте, кто именно формировал требования – если это была узкая выборка, то вернитесь на шаг назад. Короткий опрос или 15-минутные интервью могут дать больше, чем кажется;
- Спрашивайте, как люди работают сейчас – с какими трудностями сталкиваются, где тратят больше всего времени, что вызывает фрустрацию.
Шаг 2. Согласуйте логику до разработки интерфейса
Если вы сразу начинаете с UI, то рискуете сделать красивое, но нерабочее решение. Даже простое прототипирование по техническому заданию клиента может сэкономить десятки часов.
Наши рекомендации:
- Используйте MVP-дерево, схемы и кликабельные макеты;
- Проверяйте логику до старта разработки – хотя бы на примере одного ключевого сценария.
Шаг 3. Заложите часы на пересборку
В нашем случае один из ключевых модулей – блок по трансферам – мы пересобрали за неделю. Хотя до этого он уже был финально согласован. Но реальный опыт показал: он не решает задачи пользователей.
Наши рекомендации:
- Заложите время и ресурсы на переработку 1–2 сценариев – это не лишняя подстраховка, а необходимость;
- Введите внутреннее правило в согласованиях с клиентом – если на демо видно, что функционал не решает задачу – лучше его переделать;
- Обсудите с клиентом еще на старте, как будут приниматься такие решения – по каким критериям вы определяете, что нужно менять.
Шаг 4. Покажите промежуточный вариант фокус-группе
Не тяните до финального демо. Когда базовая логика собрана и есть кликабельный прототип или частично рабочая версия, можно уже проверять продукт в «поле».
Наши рекомендации:
- Соберите небольшую группу будущих пользователей, представляющих разные роли или категории целевой аудитории;
- Дайте пользователям «поиграть» с продуктом – пусть они попробуют пройти свои реальные сценарии и дадут обратную связь.
Даже пара комментариев на этом этапе может спасти от масштабных переделок в будущем. Главное – не воспринимать это как формальность, а как инструмент проверки гипотез на живом опыте.
Шаг 5. Вовлекайте команду
Разработка под закрытые процессы – это всегда риск. Поэтому в таких проектах нужно глубокое вовлечение всей проектной команды.
Наши рекомендации:
- Проводите внутренние демо не только для клиента, но и для команды – чтобы дизайнеры и разработчики понимали, как пользователи будут работать с продуктом;
- Показывайте реальные сценарии использования – например, кто заполняет таблицу, кто вносит изменения, кто следит за статусами;
- Фиксируйте инсайты по ролям – какие действия, какие ограничения, какие ожидания у каждого типа пользователя.
Сбор требований в кастомных продуктах – это не чекбокс. Это постоянный процесс сверки ожиданий, возможностей и реального пользовательского поведения. И здесь вовлечённость и менеджера, и команды критична. Именно вы видите картину целиком, чувствуете, когда логика начинает буксовать, и можете предложить альтернативу, пока это ещё легко поправить.
За любым техническим заданием скрываются только гипотезы. И чем раньше вы начнёте проверять их на реальных сценариях, тем меньше шансов столкнуться с переработками перед финальным релизом.
