проект Вадима Митякина

Engineering Design:
Как мы проектируем мобильные приложения

Февраль, 2017
#Тезисы
В нашем проектном бюро мы выясняем, что должно делать приложение и как будет выглядеть, а потом прорабатываем внутреннее устройство. Только потом переходим к разработке. Мы это называем Engineering Design.
Обычные ребята получают заказ на разработку мобильного приложения, тут же оценивают бюджет и начинают разработку.

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

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

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

Сначала я собираюсь рассказать, что это вообще значит. Потом расскажу, почему это так важно. А потом расскажу как это влияет на все остальные части проекта.

Но начну я с того, что значит сначала проектировать в принципе.

Проектирование и разработка

Это значит сначала думать, а потом делать. Это значит, что в начале проекта никто не знает, сколько будет стоить проект и сколько он продлится. Это значит, что сначала нужно заплатить за  роектирование, а потом за разработку.

Что значит проработать внутреннее устройство

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

Я говорю, после того, как вы разобрались с тем, что нужно клиенту, необходимо разобраться как именно это сделать. Фото поможет понять, что я имею ввиду.
Клиент хочет красивый автомобиль, всего два места, мощный мотор и старт до сотни меньше 4 секунд. Ну что, этих требований достаточно, чтобы можно было сказать, сколько будет стоить его производство?

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

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

Почему важно решить все технические вопросы до разработки

Можно задать вопрос по другому. Почему разработчики сами не могут сделать все по ходу разработки? Безусловно могут. И делают. Они часто даже не знают, что можно по другому и поэтому соглашаются. Многим даже кажется, что это вопрос вкуса – проектировать или сразу разрабатывать.
Проработать технически проект означает:
Выяснить все подробности среды, в которой будет работать продукт. Например, если это банк, важно сразу узнать топологию серверов, ограничения по операционным системам, языкам. Узнать – значит проверить, клиент может не знать точно.
Получить документацию на все системы, с которыми предстоит интегрироваться. И проверить. Да, прямо написать код, вызывающий ключевые методы API платежного сервиса.
Спланировать архитектуру системы. Когда будете это делать, обязательно нужно помнить о квалификации разработчиков, ожиданиям по срокам и бюджету разработки. Удачная архитектура позволяет сэкономить кучу сил в проекте и облегчить поддержку после запуска.
Связать интерфейс приложения с внутренними компонентами. У разработчиков не должно быть вопросов, откуда взять данные для вывода на форме или какой метод бизнес-логики вызвать при нажатии на кнопку.
И конечно же описать логику работы каждого компонента, из которых состоит система. Описать все? Да, все. А что, разработчики будут по ходу дела решать, как должна вести себя система в случае ошибки системы бронирования, с которой вы интегрируетесь?
Долго? А недолго переписывать целиком систему, когда в конце проекта выясниться, что API не поддерживает выбранный вами режим? У меня тут очередная картинка про машины. Разными цветами обозначены типы метала в конструкции кузова. Хотите, чтобы рабочие на конвейере выбирали какой метал взять? И это я еще про эргономику и электронные системы внутри ничего не сказал.
Такой подход выглядит дороже обычного, будто бы мы к разработке прибавляется еще один этап. На практике большая разработка разделяется на период поиска решений (проектирование) и производства (программирования). С учетом того, что не теряется время на ложные пути, простои и долгую стабилизацию в конце, проект получается быстрее и дешевле.
Мы из разработки вынули часть работы и перенесли его в проектирование
Мы избавились от простоев разработчиков, когда целая команда вынуждена ждать, когда один из разработчиков переделает свой компонент, от которого зависит все остальное в системе
Разработчики сразу планируют задачи в оптимальном порядке, заранее зная, что именно им нужно сделать
Сама разработка кстати тоже становится быстрее и проще, потому что:

Неожиданные приемущества, которые получаются при таком подходе

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