Любой цифровой продукт — это живой организм, со своими жизненными циклами. Чтобы он развивался и оставался полезным, нужна обратная связь от тех, кто им регулярно пользуется. Но как именно отдельный комментарий превращается в удобную функцию, полезную сотням других пользователей?
Мы решили заглянуть за кулисы разработки платформы «Цифровое управление строительством» (ЦУС) и подробно разобрать путь пользовательского запроса на всех жизненных циклах цифрового продукта — от идеи изменения ЦУС до релиза.
Содержание:
- Этап 1: Обработка обратной связи: выявить проблему
- Этап 2: Концепция и ТЗ. Рождение решения
- Этап 3: Приоритизация и разработка
- Этап 4: Тестирование и обкатка. Проверка изменений ЦУС на практике
- Этап 5: Релиз и информирование об изменениях ЦУС
- Кейс из практики. Как родились статусы в ГПР: решение неочевидной проблемы
- Обратная связь — это топливо для развития
Этап 1: Обработка обратной связи: выявить проблему
«Цифровое управление строительством» (ЦУС) — облачный веб-сервис для совместной работы всех юридических лиц, участвующих в работе над строительным проектом. Платформа изначально создавалась с учетом логики бизнес-процессов в строительстве. Но во многих компаниях порядок работы выстроен по-своему, поэтому в некоторых случаях необходима адаптация продукта или добавление новых возможностей.
Все начинается с пользовательского опыта. Пользователи делятся с нами обратной связью: это может происходить через техподдержку, руководителя проекта внедрения или менеджера продукта.
Как мы ранжируем поступающие запросы?
- Высокий приоритет: «Без этого функционала я не могу выполнить ключевую рабочую задачу». Такие запросы всегда берутся в проработку в первую очередь.
- Средний и низкий приоритет: «Хотелось бы удобнее» или «Сделайте, как в Excel». Эти пожелания для комфорта мы тоже учитываем, но их реализация зависит от загрузки команды и общего видения продукта. Также обязательно смотрим на масштабируемость решения — то есть насколько эта доработка будет полезна для всех пользователей.
Главное — докопаться до сути проблемы. Пользователь часто предлагает обобщенное или привычное ему решение (условно говоря, «табличка на 500 строк»). Наша задача — спросить: «А что вы хотите сделать с этой табличкой? Какой конечный результат вам нужен?».
Рассказываем в коротких письмах о 7 реальных кейсах цифровизации: опыт из жизни
Пример технического решения. Вместо того чтобы слепо копировать Excel, мы выясняем, что на самом деле пользователь хочет контролировать важные показатели и видеть их перед глазами. Мы предлагаем виджет на главном экране с ключевыми цифрами из этой «таблицы». Так мы решаем не симптом, а причину, предлагая решение, которое лучше встроено в логику ЦУС.
Василий Сонин, менеджер продукта:
Мы стараемся сделать так, чтобы доработки не носили случайный эпизодический характер. Иначе система будет представлять собой монстра Франкенштейна из нестыкующихся сущностей. Поэтому каждую доработку мы стремимся, во-первых, вписать во внутреннюю логику системы, и, во-вторых, сделать ее универсальной, полезной для максимально большого количества клиентов.
Этап 2: Концепция и ТЗ. Рождение решения
Когда мы видим ценность запроса, к работе подключается менеджер продукта. Его задача — преобразовать разрозненные пожелания в четкий план действий с учетом жизненных циклов цифрового продукта. Здесь два ключевых этапа:
- Формирование видения. Менеджер продукта анализирует, как новая функция и изменения ЦУС впишутся в существующую архитектуру системы. Есть ли похожий функционал в других модулях? Можно ли использовать его как основу?
- Создание технического задания (ТЗ). Готовится детальный документ, который описывает, как функция будет работать. Прописываются алгоритмы, логика, формулы (если они нужны) и даже цветовые решения.
Это творческий процесс. Речь не о слепом выполнении запроса, а о поиске оптимального способа решить проблему пользователя в рамках философии продукта.
Этап 3: Приоритизация и разработка
Мы смотрим, насколько задача критична для бизнеса клиентов. Если есть несколько запросов на такую доработку, или пользователю она принципиально необходима, приоритет повышается.
После согласования задача передается разработчикам, которые ставят ее в бэклог — очередь задач и воплощают описанное из ТЗ в код.
Этап 4: Тестирование и обкатка. Проверка изменений ЦУС на практике
Сделанный функционал не сразу попадает к пользователям. Сначала все изменения ЦУС проходят многоуровневое тестирование:
- Внутреннее тестирование: тестировщики проверяют функционал по чек-листам и критериям приемки из ТЗ.
- Проверка в тестовой среде: менеджер продукта и тестировщики проверяют, все ли работает так, как задумано, на специальных тестовых базах.
- Обкатка на проекте заказчика: если функцию запросил конкретный клиент, тестирование часто проходит в его среде. Это помогает убедиться, что все работает корректно в реальных условиях.
Найденные ошибки возвращаются на доработку, и цикл повторяется до стабильного результата.
Этап 5: Релиз и информирование об изменениях ЦУС
После успешного тестирования функционал включается в очередной релиз и появляется у всех пользователей на продуктовой среде (Prod). На этом работа не заканчивается. Технические писатели готовят обновление руководства пользователя. Маркетинг и обучающая команда рассказывают о нововведении: пишут статьи, снимают видеообзоры и обучающие ролики.
Кейс из практики. Как родились статусы в ГПР: решение неочевидной проблемы
Мы рассмотрели полный жизненный цикл работы над изменениями цифрового продукта и как эти изменения реализуются в ЦУС. Рассмотрим, как это происходит на практике.
Проблема. Пользователи жаловались, что в огромном графике производства работ на тысячи строк непонятно, что идет по плану, а что нет, так как с задачами может происходить разное: они выполняются в сроке, выполняются не в сроке, согласно плану или не согласно плану. График — это тысячи строк, и просматривать их все в поисках отставаний очень тяжело. Но прямого запроса «сделайте статусы» не было. Было ощущение неудобства и сложности с анализом.
Лучший график — это график, которого нет, но из которого идут данные. Ценность графика не в его наличии или аккуратном ведении, а в инсайтах, которые он дает: мы видим, что реально происходит на площадке.
Анализ. Мы узнали, что некоторые клиенты вручную выгружали график в Excel и вручную подкрашивали строки, чтобы отслеживать опережения и отставания. Это был «костыль», отнимающий время.
Решение. Мы поняли, что нужно не добавлять еще одну таблицу, а дать наглядный инструмент внутри системы. Так родилась идея статусов по срокам и объемам. Мы разработали сложную статусную модель (12 статусов по срокам и 7 по объемам). Пользователь продолжает работать как раньше (вносит планы и факты), а система автоматически подсвечивает ему проблемы. Как светофор: красный — тревога, зеленый — все хорошо.
Статусы по срокам и по объемам: каждый статус имеет свой цвет, что помогает быстро сориентироваться в ходе выполнения задач
Результат. Пользователи получили возможность мгновенно фильтровать отстающие работы, не выгружая данные в Excel и не усложняя себе жизнь: не нужно отдельно настраивать сложные фильтры, отщелкивать чек-боксы, выгружать файлы, все сразу видно. Это сэкономило время и повысило наглядность работы с графиком, решив изначальную проблему удобства. Подробнее о контроле работ с помощью статусов читайте в статье «Как планировщику строительства контролировать график работ».
Обратная связь — это топливо для развития
Мы ценим все сообщения от пользователей. Только благодаря обратной связи мы видим, что происходит на разных жизненных циклах цифрового продукта. Чем больше вы делитесь с нами своими трудностями и идеями, тем лучше мы понимаем, что для вас действительно важно.
Хотите предложить улучшение? В системе есть кнопка «Сообщить о проблеме» — она есть внизу почти каждой страницы. Через нее можно не только сообщить о баге, но и отправить свое предложение. Это прямой канал связи с командой развития продукта.
Мы постоянно работаем над тем, чтобы наладить процесс сбора обратной связи еще лучше, создавая единый «банк гипотез», где ни одно ценное предложение не будет потеряно.
