В разработке часто встает вопрос о том, как сбалансировать скорость, качество и бизнес-цели. С одной стороны, бизнесу нужно быстрее выйти на рынок, с другой — пользователи ожидают удобного и стабильного продукта. Найти баланс между техническим долгом и пользовательским опытом получается не сразу. В этой статье мы расскажем, как в компании «Квантум» принимаем решения, используя в качестве примера  разработку приложения для поиска мастеров.

Технический долг – неотвратимый путь самурая 

Согласно неофициальным опросам, многие разработчики принимают  технический долг как одну из причин профессионального выгорания. Исправление ошибок воспринимается признаком некомпетентности. Но проблема зачастую не в недостатке навыков, а в изменении требований и условий, в которых развивается проект  — это закономерный процесс. 

Баланс между техническим долгом и пользовательским опытом не всегда про выбор между «плохим» и «хорошим». Это поиск оптимального решения и расставление приоритетов в условиях ограниченных ресурсов. Накопление долга может быть оправдано, если оно позволяет быстрее достигать бизнес-целей и удовлетворять потребности пользователей. 

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

С самого начала мы понимали, что успех приложения для поиска мастеров зависит от того, насколько быстро и легко пользователи смогут создавать заказы и находить исполнителей. Поэтому на начальном этапе сосредоточились на оптимизации пользовательского опыта. Но обо всем по порядку. 

Фокус на пользовательском опыте: от идеи до реализации 

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

Проведя анализ аналогичных приложений, мы обнаружили, что для выполнения действия «Создание объявления» пользователю требуется пройти в среднем 8 шагов. В результате нам удалось сократить этот процесс до 5 шагов, при этом сохранив ключевые уточнения о требуемой услуге. Пользователь должен был всего лишь:

1. Выбрать категорию услуги.
2. Написать название услуги.
3. Указать время получения услуги.
4. Указать локацию получения услуги.
5. Нажать кнопку «Опубликовать заказ».

На основе проведенных исследований мы определили ключевые точки взаимодействия и приоритеты разработки:

• Создание заказа: не более 8 шагов.
• Поиск мастера: мгновенный и выборочный.
• Повторение заказа: одна кнопка без необходимости вводить данные заново.
• Рейтинг и отзывы: учет интересов обеих сторон –  мастеров и клиентов.

Такие требования подразумевают максимальное удобство на стороне пользователя, но как показывает практика, простота и интуитивность зачастую  приводит к усложнению логики приложения. Мы столкнулись с этой проблемой на этапе проектирования. Упрощение интерфейса необратимо приводило к увеличению технического долга.

Технический долг: скрытая цена простоты

Разработка данного проекта осуществлялась небольшой командой разработчиков в условиях ограниченного времени. Важно было четко продумать порядок взаимодействия и планирования. В компании «Квантум» у нас уже сложилась эффективная система работы, которая отвечает потребностям всех членов команды. Мы применяем Agile-методологии, что позволяет гибко адаптировать процессы под текущие потребности проекта. В этом случае команда приняла решение сразу приступить к разработке дизайн-макета без предварительного прототипирования. Мы разбили процесс разработки на этапы и корректировали планы, избегая затрат времени на функции, которые могли оказаться невостребованными.

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

1. Упрощение архитектуры: вместо сложной системы фильтрации мастеров были использованы базовые алгоритмы.
2. Минимальная валидация данных: для ускорения процесса создания заказа было решено сократить количество проверок вводимых данных.
3. Отложенные улучшения: некоторые функции, такие как возможность фильтрации мастеров по более сложным критериям, были отложены на более поздний этап разработки.

Мы не избегали технического долга, но старались минимизировать его влияние:

• Прежде всего, согласовали с заказчиком выпуск минимально жизнеспособного продукта (MVP) и сосредоточились на основных функциях, напрямую влияющих на пользовательский опыт. Все функции с низким приоритетом, такие как дополнительные настройки и интеграции, были отложены.
• Документировали все упрощения и временные решения.
• Планировали регулярные рефакторинги.
• Использовали метод прогрессивного раскрытия функциональности: основной экран был максимально простым, а дополнительные функции, такие как подробная информация о мастере или чат, открывались по запросу пользователя.

Как мы принимали решения: алгоритм компромиссов

Каждое принятое решение основывалось на четкой оценке рисков. Мы постоянно задавали себе ключевые вопросы: «Как это повлияет на пользовательский опыт?» и «Каковы долгосрочные последствия для архитектуры приложения?» Это помогло нам принимать более взвешенные решения.

Вот что стало основой нашего подхода:

1. Использование MVP: мы выпустили минимальную версию продукта, чтобы быстро получить обратную связь и понять, что действительно важно для пользователей.
2. Определение ключевых метрик успеха: мы сосредоточились на количестве успешных сделок, времени, проведенном в приложении, и уровне удовлетворенности пользователей.
3. Оценка влияния технического долга: мы осознавали, что накопленный долг может замедлить разработку в будущем, но на начальном этапе это было оправдано.
4. Понимание критических потребностей пользователей: мы провели исследования и выяснили, что для пользователей важнее всего скорость поиска мастера и простота создания заказа.
5. Итеративный подход: мы выбрали итеративный подход к разработке, что позволяет нам создавать и тестировать небольшие части функциональности, быстро адаптируясь к изменениям и отзывам пользователей. Поскольку приложение продолжает развиваться, мы можем постепенно добавлять новые функции, минимизируя технический долг.
6. Коммуникация с заказчиком: в «Квантум» мы придерживаемся важного принципа — заказчик является полноценным членом проектной команды. Его участие на всех этапах разработки и присутствие на ежедневных встречах с командой позволяют эффективно управлять ожиданиями и совместно находить оптимальные решения. Такой подход способствует более глубокому пониманию задач и повышает качество конечного продукта.

Заключение

В процессе разработки важно учитывать долгосрочные последствия. В случае разработки приложения для поиска мастеров для нас ключевыми решениями стали использование MVP и регулярный рефакторинг. Кроме того, выбор технологий и инструментов, которые будут легко масштабироваться и обновляться, поможет нам адаптироваться к изменяющимся требованиям рынка и запросам пользователей. В результате, в совокупности это обеспечивают не только успешную реализацию текущих задач, но и закладывают основу для устойчивого развития приложения в будущем.

Если вы сталкивались с похожими вызовами, поделитесь своим опытом в комментариях. Давайте обсуждать и учиться друг у друга