Реальные сроки разработки приложения: от идеи до запуска

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

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

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

Почему оценка, которую вам дали, скорее всего, неверна

Цифра в шесть недель — не совсем ложь: это время, которое нужно, чтобы построить ту часть, которую все себе представляют. Экраны. Кнопки. То, что можно показать. Чего эта цифра тихо не учитывает — это всё вокруг видимого приложения: решения, данные, интеграции с инструментами, которыми вы уже пользуетесь, тестирование, проверку в магазине приложений и неизбежный раунд «а вообще-то, может оно ещё и вот это?»

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

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

Этап 1. Исследование и определение объёма (1–3 недели)

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

Сделанное хорошо, исследование — это в основном разговор и трудные вопросы. Кто этим пользуется и на каком устройстве? Что то единственное, что приложение должно делать блестяще? Что может подождать до второй версии? Хороший партнёр будет здесь возражать, и вы должны этого хотеть — каждая функция, которую вы отсекаете сейчас, это недели, которые вы возвращаете. Результат — обычно короткий письменный объём работ и черновой каркас, нечто, что можно взять в руки и сказать да, вот оно.

Этап 2. Дизайн и прототип (2–4 недели)

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

Этот этап на вес золота по одной причине: изменить дизайн дёшево, изменить собранное ПО дорого. Передвинуть кнопку в прототипе — пять минут. Передвинуть её после того, как функция написана, протестирована и подключена к вашим данным, может занять день. Так что это момент, когда стоит быть придирчивым, показать это нескольким реальным клиентам или сотрудникам и поймать проблемы вроде «ой, этого никто не поймёт», пока их исправление ещё безболезненно.

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

Этап 3. Сборка (6–12 недель)

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

Этот ритм важен. Вы хотите реагировать на настоящее, работающее ПО рано, а не на отчёт о статусе. Когда на четвёртой неделе вы сможете реально воспользоваться потоком бронирования, вы заметите вещи, которые ни одна спецификация не смогла бы уловить, — и исправить их на четвёртой неделе гораздо дешевле, чем на десятой. Хороший процесс сборки делает приложение видимым для вас непрерывно, а не только в конце.

Что тихо растягивает сборку

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

• Каждая внешняя интеграция добавляет дни, иногда недели — закладывайте их в бюджет явно, не считайте, что они бесплатны.
• «Всего одна маленькая функция» — безусловно самая частая причина сорванной даты запуска.
• Реальные данные запутаннее тестовых; планируйте время на крайние случаи, которые ваша таблица тихо терпела.
• Учётные записи, платежи и уведомления обманчиво глубоки — они всегда обходятся дороже, чем выглядят.
• Согласования и контент, который вы должны команде (логотипы, тексты, юридический текст), могут остановить сборку так же надёжно, как баг.

Этап 4. Тестирование и исправление (2–4 недели)

Вот этап, о существовании которого забывают, а потом досадуют, когда он всплывает. Как только приложение собрано, его нужно прогнать через испытания — на разных телефонах, при плохом интернете, людьми, которые его не строили и сделают то, чего никто не предвидел. Тестирование — не формальность. Это разница между приложением, которому ваши клиенты доверяют, и тем, что они удаляют после первого сбоя.

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

Этап 5. Запуск и ожидание магазина приложений (1–2 недели плюс проверка)

Запуск — это не столько единый момент, сколько аккуратное развёртывание. Если это веб-приложение, вы полностью контролируете время — щёлкаете переключателем, когда готовы. Если оно идёт в App Store от Apple или в Google Play, часть графика вы передаёте им: их процесс проверки может занять от дня до более чем недели, а иногда они вернут его с чем-то на исправление. Это стоит знать заранее, чтобы оно не застало врасплох дату запуска, обещанную клиентам.

Умный способ запуска — это не громкое раскрытие перед всей клиентской базой. Это сначала тихий релиз для небольшой группы — горстки доброжелательных клиентов или собственных сотрудников, — чтобы поймать проблемы из реального мира, прежде чем их увидят все. Затем вы открываете дверь шире. Запуск, который ощущается скучно-будничным, — это запуск, прошедший хорошо.

1. 1
   Тихий запуск для небольшой группы

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

   Часы проверки контролируют Apple и Google, а не вы. Подавайте с запасом, чтобы медленная проверка или отклонение не подорвали обещанную дату.
3. 3
   Пристально следите за первой неделей

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

   Приложение никогда не бывает 'готовым' к запуску. Договоритесь заранее, кто займётся неизбежными мелкими правками и первым раундом обратной связи.

Складываем весь график воедино

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

Сложите это — и станет видно, почему от трёх до пяти месяцев — честный диапазон для настоящей первой версии и почему те, кто обещает шесть недель, тихо переопределяют, что значит «приложение». Это не пессимизм — это разница между датой, которую вы действительно выдержите, и той, за которую будете извиняться весь проект.

Как по-настоящему это ускорить (и как нет)

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

Самый главный — безжалостный объём. Чем меньше и яснее ваша первая версия, тем раньше она запустится — а запущенное приложение, которое окупает себя, научит вас за две недели большему, чем ещё два месяца планирования. Добавить можно всегда. Нельзя вернуть месяцы, потраченные на функции, которые, как выяснилось, никому не были нужны.

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

Частые вопросы