В марте мы запускаем практический курс Engineering Design по проектированию мобильных приложений и сервисов . А 15 декабря в AGIMA пройдет день открытых дверей, на котором можно будет узнать подробности и пообщаться с ведущими курса лично.
Я расскажу о том как построить процесс проектирования. Дело в том, что команды, выросшие из дизайнерской среды, проектируют мобильные приложения, концентрируясь на пользовательском интерфейсе. У них две задачи:
• Понять, что собственно делает пользователь, используя приложений или сервис (составление Customer Jorney Map, привязанный к внутренним процессам на стороне заказчика) • Подобрать оптимальный набор экранов, для выполнения функций приложения
Прототип интерфейса и функциональные требования рассматриваются в качестве технического задания и передаются на оценку разработчикам. В свою очередь разработчики уже по ходу проекта должны сами:
• Выбрать архитектуру, подходящую требованиям проекта • Продумать внутреннюю логику работы всех компонентов приложения • Найти связь между элементами в интерфейсе и внутренней логикой • Выяснить, как подключить внешние сервисы, например, платежные системы или API на стороне заказчика
При таком подходе важные вопросы проекта остаются не решенными до начала разработки. Точно оценить проект нельзя, уже во время разработки могут выясниться противоречия в требованиях и технические ограничения.
Если проработать технические вопросы еще на этапе проектирования, то разработка становится более предсказуемой. При поиске решений, которые обычно включены в разработку, не требуется многократно переделывать проект. Проверка гипотез идет на технических прототипах, а не реальном приложении. В разработку передаются уже согласованные между собой дизайн и технические задачи.
Мы назвали такой подход Engineering Design. Подход, объединяющий функциональное, интерфейсное и техническое проектирование вместе.
Мы назвали такой подход Engineering Design. Подход, объединяющий функциональное, интерфейсное и техническое проектирование вместе.
Подход уже несколько лет используется в проектах, над которыми мы работаем. По модели Engineering Design были разработаны приложения для Коммерсанта, Связного Трэвел, Моего дела.
Подход Engineering Design создавался с учетом теории ограничений Элияху Голдратта, о котором он написал книгу "Критическая цепь". Как мы подходим к управлению проектами с описанным подходом я расскажу в отдельной статье.
Вам стоит придти, чтобы убедиться, что работа над сложным проектом и счастье – совместимы
Вам стоит придти, чтобы убедиться, что работа над сложным проектом и счастье – совместимы
Лучше жизнь для заказчиков:
• По итогу проектирования у разработчиков достаточно информации, чтобы сделать точную оценку, не нужно ждать окончания проекта, чтобы узнать фактический бюджет и сроки • В начале проекта можно установить границы по срокам и бюджету и в результате проектирования понять, какой действительно продукт можно получить • Можно быть уверенным, что при разработке не возникнут неожиданные проблемы, из-за которых продукт будет нельзя выпустить • Документация всегда совпадает с продуктом, в любой момент можно продолжить разработку внутренней командой • Можно публиковать приложение после каждой итерации разработки, если функций в нем достаточно, т.к. каждый релиз — протестированная финальная версия • Следить за ходом проекта глядя не на формальные отчеты, а на готовое приложение с новыми функциями
Лучше жизнь для разработчиков:
• У разработчиков есть вся необходимая для работы информация, можно оптимально построить план разработки и не терять время на ожидание, когда заказчик, дизайнер или кто-то еще примет решение • Разработчики, реализующие пользовательский интерфейс, имеют подробную информацию, как элементы экрана связаны с внутренними компонентами приложения • Руководитель разработки понимает, какие части системы отвечают за реализацию пользовательской функции, входящей в релиз • Разработчик понимает пользовательский сценарий, в котором используются экраны и методы, которые он разрабатывает
Неожиданные надежды для дизайнеров:
• Есть ясные технические требования, не нужно ничего угадывать за разработчиков на этапе дизайна • По ходу проекта не придется много раз переделывать дизайн интерфейса в ответ на замечания от разработчиков • Можно выполнять авторский надзор во время разработки в рамках отдельных функциональных разделов интерфейса, входящий в текущий релиз