Три основных процесса разработки приложений

Денис Гордиенко, генеральный директор Bright Mobile, о преимуществах и недостатках разных вариантов выстраивания процесса разработки.

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

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

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

Дизайн рисуется без оглядки на то, как оно работает – только после получения дизайна составляется ТЗ и начинается непосредственно разработка.

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

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

Чем хорош такой подход?

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

Чем плох?

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

Где всё это будет храниться, вообще никто не думал, бывают ссылки на экран, который не прорисован в принципе. Короче говоря, дизайнер не думает, как всё это будет работать. Ему заплатили, он нарисовал – всё готово, на этом его работа закончена.

Редко бывает так, что дизайнер ведёт проект – обычно он попросту выполняет свою задачу и больше не несёт никакой ответственности, которая ложится целиком на основателя проекта. Будьте готовы к тому, что когда вы придёте к программисту, он сообщит, что в дизайне нет того, другого, третьего и десятого, что экраны друг с другом не согласуются, а потому попросит вас всё переделать и уже только потом к нему возвращаться.

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

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

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

Какие у подобного подхода плюсы?

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

Во-вторых, тут всё логично: сначала описали, что должно получиться, в текстовом формате, затем сделали это же визуально, а затем – реализовали всё на практике. И если по ходу действий нет никаких отклонений, вы практически гарантированно получите именно то, что изначально заказывали.

А какие минусы?

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

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

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

И, наконец, третий, мой любимый вариант, который я использую сам. Как и второй, он предполагает наличие ТЗ на начальном этапе; затем рисуются каркасы, иногда их назвают линкованными прототипами.

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

Так за один месяц у нас образуется согласованная позиция, которая не будет нигде не меняться: заказчик уже примерно представляет, как выглядит приложение, внёс все свои мысли и пожелания – можно передавать разработке.

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

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

Чем хорошо?

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

Чем плохо?

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

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

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

На моём YouTube можно найти больше информации по разработке.