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

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

1) Некорректные вопросы во время знакомства с компанией

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

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

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

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

Вопросы, которые стоит задавать:

• В чем вы видите просчеты и недостатки?
• Насколько проект важен для вашей компании?
• Какова продолжительность проекта?
• Как осуществляется управление проектом?
• Как относитесь к просьбам что-либо изменить?

2) Неверная оценка бюджета

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

Целесообразнее спросить о начальной оценке бюджета

Проект можно разделить на три этапа: прототипирование, создание дизайна и разработка.

Более точную оценку стоимости можно будет дать только по окончании первого этапа.

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

3) Отсутствие обсуждений бизнес-целей (или вовсе отсутствие целей)

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

Попытайтесь ответить на следующие вопросы и затем обсудить их с агентством:

1. Почему вы занимаетесь этим проектом? Какая у вас мотивация?
2. На какие основные метрики необходимо обратить внимание? Доход, база пользователей, время, потраченное на приложение, монетизация, узнаваемость бренда или другое?
3. Каковы критерии успеха? Как нужно будет измерять успех по прошествии года?

Важно понимание еще одного нюанса: агентства опасаются, что вы свернете проект, если он не оправдает ожиданий.

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

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

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

Существует несколько шагов, которые необходимо выполнить прежде, чем переходить к этапу разработки:

1. Завершить макеты (UX). Охватить все статусы (ошибки, сообщения, микрокопии и т.д.)
2. Прототипирование макетов.
3. Пользовательское тестирование ключевых действий, относящихся к UX.
4. Создание экранов.
5. Создание прототипов.
6. Анимация.
7. Пользовательское тестирование дизайна.

4) Пользовательское тестирование

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

По завершении этапа UX и UI обычно привлекаются как минимум 6 внешних пользователей, и с их помощью проверяются различные сценарии. Но прежде в течение недели проводится внутреннее тестирование с участием порядка 30 пользователей (оптимальный план: по 6 человек в день).

Если на этапе дизайна не было никаких промахов, разработка пройдет как прогулка в парке, без каких-либо сюрпризов и проволочек.

5) Понимание работы, связанной с бекендом и API

«У нас есть внутренняя команда. Они этим займутся». Такое часто можно слышать от клиента. С другой стороны, никто лучше внутренней команды не разбирается в логических операциях, базах данных, серверах. Чтобы сделать все это доступным, от агентства требуется определенная работа. Но сотрудники агентств не хотят месяцами разбираться в сложностях внутренних систем клиента.

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

Работа с API

В идеале никакие работы, относящиеся к клиентской части системы (мобильные приложения или даже веб-приложения), не должны проводиться прежде, чем будет готов и протестирован API. Но на практике так бывает далеко не всегда, обычно все происходит параллельно.

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

Помогите нам помочь вам

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