РШСД и инженерное проектирование

Вместе с Русской Школой Сервисного Дизайна (РШСД) мы начинаем совместную историю про важный аспект создания продуктов – техническое проектирование. Я буду вести это направление в Facebook-группе школы. Вероятно через некоторое время мы подготовим мастер-класс по техническому проектированию.

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

— Понять, что собственно делает пользователь, используя приложений или сервис (составление Customer Jorney Map, привязанный к внутренним процессам на стороне заказчика)
— Подобрать оптимальный набор экранов, для выполнения функций приложения

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

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

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

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

Мы назвали такой подход Engineering Design. Подход, объединяющий функциональное, интерфейсное и техническое проектирование вместе.

Мы считаем, что это важно. И вот почему.

Лучше жизнь для заказчиков:

• По итогу проектирования у разработчиков достаточно информации, чтобы сделать точную оценку, не нужно ждать окончания проекта, чтобы узнать фактический бюджет и сроки
• В начале проекта можно установить границы по срокам и бюджету и в результате проектирования понять, какой действительно продукт можно получить
• Можно быть уверенным, что при разработке не возникнут неожиданные проблемы, из-за которых продукт будет нельзя выпустить
• Документация всегда совпадает с продуктом, в любой момент можно продолжить разработку внутренней командой
• Можно публиковать приложение после каждой итерации разработки, если функций в нем достаточно, т.к. каждый релиз — протестированная финальная версия
• Следить за ходом проекта глядя не на формальные отчеты, а на готовое приложение с новыми функциями

Лучше жизнь для разработчиков:

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

Неожиданные надежды для дизайнеров:

• Есть ясные технические требования, не нужно ничего угадывать за разработчиков на этапе дизайна
• По ходу проекта не придется много раз переделывать дизайн интерфейса в ответ на замечания от разработчиков
• Можно выполнять авторский надзор во время разработки в рамках отдельных функциональных разделов интерфейса, входящий в текущий релиз

Почитать еще: