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

Февраль, 2017

#Тезисы

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

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

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

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

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

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

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

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

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

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

Можно задать вопрос по другому. Почему разработчики сами не могут сделать все по ходу разработки? Безусловно могут. И делают. Они часто даже не знают, что можно по другому и поэтому соглашаются. Многим даже кажется, что это вопрос вкуса – проектировать или сразу разрабатывать.

Проработать технически проект означает:

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

Получить документацию на все системы, с которыми предстоит интегрироваться. И проверить. Да, прямо написать код, вызывающий ключевые методы API платежного сервиса.

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

Связать интерфейс приложения с внутренними компонентами. У разработчиков не должно быть вопросов, откуда взять данные для вывода на форме или какой метод бизнес-логики вызвать при нажатии на кнопку.

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

Долго? А недолго переписывать целиком систему, когда в конце проекта выясниться, что API не поддерживает выбранный вами режим? У меня тут очередная картинка про машины. Разными цветами обозначены типы метала в конструкции кузова. Хотите, чтобы рабочие на конвейере выбирали какой метал взять? И это я еще про эргономику и электронные системы внутри ничего не сказал.