Быстрая разработка приложений и сайта

Денис Гордиенко, генеральный директор Bright Mobile, о скоростной разработке проекта.

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

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

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

Конечный результат можно развивать и дорабатывать дальше уже в режиме новых версий.

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

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

Как ускорить разработку, когда времени осталось мало?

Начнём с приложения. ТЗ у вас, предположительно, уже есть. С этим ничего делать не нужно. Рассмотрим самый плохой вариант, когда кроме него ничего и не осталось.

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

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

По согласованию всех прототипов можно начинать готовить и согласовывать дизайн, а после завершения работы над сервером (даже не закончив админку) можно переходить к мобильному приложению. При классической разработке не принципиально, в каком порядке делаются сервер и админка, но при скоростной важно сначала сделать серверную часть, дойдя примерно до 80% от общего объёма работы, и только после этого приступать к мобильному приложению. Затем оставшаяся работа по разработке админки будет делаться параллельно с мобильными приложениями, а попозже присоединится ещё дизайнер, который будет дорисовывать свою часть.

Обычно реализация мобильных приложений на каркасах и завершение дизайна упираются в одну точку с разницей не больше нескольких дней. Этот момент – как раз та ключевая дата Х, когда вы уже можете запускаться. У вас на руках будет MVP-версия, собранная на каркасах: на первых порах для неё дизайн, как правило, не принципиален, достаточно поставить лого на заставку, перекрасить каркасы в его цвета и получить плюс-минус сносный вариант, который (в режиме пожаротушения) можно принять.

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

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

Затем, в самом конце, как полагается, идут тесты.

Ориентировочно подобный скоростной подход разработки экономит 50-70% времени. Естественно, работа будет в пожарном режиме, компания погружается в процесс целиком и полностью, что прибавляет к стоимости примерно 30% в зависимости от функционала.

В данном случае под сайтом я понимаю некий веб-сервис, в виде того или иного стартапа, а не просто классический корпоративный сайт/лендинг/. Например, сервис заказа услуг или товарный маркетплейс. Хотя, в случае агрегатора услуг, выгоднее воспользоваться RTPlatform.

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

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

Из выше сказанного следует, что дизайн запускать одновременно с прототипами можно, но дизайн не полноценный, а «урезанный». Аналогично, согласовав пару экранов дизайна, можно переходить к вёрстке. Главное – чтобы потом к концу разработки дизайн не разонравился: если что-то согласовали, это уже должно быть железно, иначе никакой экономии времени не будет.

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

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

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

При таком раскладе разработка веб-приложения займёт на 30% меньше времени, а за ускорение берут около 10-20% стоимости обычной разработки. Не так быстро, как при разработке мобильного приложения, поскольку в вебе все намного больше зависят друг от друга, и вести процессы параллельно не всегда возможно. Однако когда дедлайн – вчера, даже такое сокращение временных затрат может быть очень полезным.