8 дорогих ошибок в разработке приложений, которые малый бизнес повторяет снова и снова

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

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

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

Ошибка 1: начать разработку, не доказав, что это кому-то нужно

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

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

Ошибка 2: расползание объёма под маской амбиций

Любое приложение начинается стройным и аккуратным. Потом начинается «раз уж мы всё равно этим занимаемся». Раз уж мы делаем экран бронирования, может, он заодно обработает и подарочные сертификаты? И бонусные баллы? И реферальную систему? Каждое дополнение по отдельности звучит разумно. Вместе они тихо утраивают сроки и счёт — и отодвигают запуск так далеко, что первоначальный импульс угасает.

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

Ошибка 3: нет письменного брифа — только общая картинка в головах

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

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

Ошибка 4: выбирать разработчика неправильным способом

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

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

Что на самом деле проверять

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

Ошибка 5: заложить бюджет на разработку, забыв про всё остальное

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

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

Ошибка 6: проектировать для себя, а не для пользователя

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

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

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

Ошибка 7: делать нативные iOS и Android, когда этого не требовалось

Есть рефлекс с первого же дня делать «настоящее» приложение и под iPhone, и под Android, полностью нативно, как делают крупные бренды. Для большинства малых компаний это двух- или трёхкратная стоимость и сложность ради выгоды, которую ваши пользователи никогда не заметят. Хуже того, вы теперь навсегда сопровождаете две отдельные кодовые базы, удваивая каждое будущее исправление.

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

Ошибка 8: считать запуск концом работы

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

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

Как обойти все восемь разом

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

1. 1
   Докажите спрос до разработки

   Прототип, лендинг или ручная версия. Получите реальное доказательство, что это кому-то нужно, прежде чем задействовать бюджет.
2. 2
   Напишите бриф и список версии два

   Несколько ясных страниц, понятных каждому, плюс парковка для каждой идеи «раз уж мы всё равно», чтобы она не пустила под откос версию 1.
3. 3
   Выбирайте разработчика по послужному списку, а не по цене

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

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

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

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

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