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

Казалось, что мы сделали всё как надо.

• Составили ТЗ по разработке приложения со списком функций, которые должны быть у приложения. Описали внешний вид основных экранов приложения.

• Отобрали потенциальных подрядчиков (компании из топа мобильной разработки в России и несколько компаний из Беларуси, тоже топовых) и разослали им наше ТЗ с просьбой оценить сроки и стоимость разработки.

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

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

• Познакомились с нашим менеджером. Мне показалось немного странным, что на этом не было практически никаких вопросов. Но я подумала, что это крупная известная компания, а приложение у нас, в общем, простое, поэтому, наверное, и вопросов нет. А, может, они появятся позже — и тогда они их зададут.

С того момента прошли год и два месяца. Наше приложение для iOS готово всего несколько месяцев как. В приложение для Android все ещё вносятся последние правки. На моей голове появилось довольно много седых волос. А наш программист, который писал бекенд для приложения и который известен всем как максимально спокойный и бесконфликтный человек, периодически жалуется, что сторонние разработчики временами выводят его из себя.

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

Вот восемь убеждений о мобильной разработке, которые у меня были — и оказались неверными. Погнали!

1. Имя подрядчика — гарантия, что проблем с разработкой не возникнет

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

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

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

И я в ответ начинала предлагать разные варианты обхода, как сделать проще (что было сложно, потому что я хоть и связана с IT, но совсем не программист). Логично, что такие варианты должен предлагать именно менеджер.

2. Если в ТЗ возникнут какие-то спорные моменты, разработчики зададут вопросы

К сожалению, далеко не всегда. В большинстве случаев они просто сделают так, как им проще.

3. Менеджер проекта разберётся во всех деталях нашего проекта

Если разработка приложения будет достаточно долгой, то многое может поменяться. Ваш менеджер совершенно точно уйдёт в отпуск и передаст проект другому менеджеру. А может и уволиться (или его могут уволить). Конечно, все всегда говорят, что передали все детали проекта другому менеджеру.

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

4. Приложение будет работать на всех популярных системах и моделях устройств, в нём будут все базовые функции

Например, вход по отпечатку пальца или Face ID, управление жестами. Все подобные моменты лучше оговаривать в ТЗ. Некоторые компании прописывают это непосредственно в договоре (например, совместимость с версиями ОС). Мы в итоге получили приложение, которое даже протестировать толком не могли.

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

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

5. Поскольку нам составили смету проекта, я знаю, в какую сумму выльется разработка приложения

Есть два формата работы: по фиксированной стоимости и в формате Time & Materials. В первом сценарии вам называют сумму за весь проект. Вы в любом случае платите её. Сколько времени при этом уйдёт на разработку — неважно.

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

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

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

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

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

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

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

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

Тут можно дать два совета.

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

И обязательно напишут об этом в App Store, поставив оценку 1 из-за одного минорного бага. Просто потому, что этот баг их выбесил так, что обо всех положительных моментах они забыли. Если не верите, откройте отзывы о крупных и известных приложениях, которые отлично работают. Мне это, кстати, помогло расслабиться и спокойнее воспринимать подобные отзывы.

7. Сделав приложение для одной платформы, со второй будет намного проще

В действительности над iOS и Android работают два разных разработчика (или две команды разработчиков). Поэтому в приложениях могут возникать разные ошибки. А могут и одни и те же. Если их исправили на одной платформе, это не означает, что их не будет на другой.

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

8. После окончания работы над приложением им можно будет не заниматься

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

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

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

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