Краткая история моих факапов или как перестать терять деньги в мобильной разработке?

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

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

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

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

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

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

В 2014 году издательский дом Коммерсантъ стал единственным российским СМИ, чье приложение (разработанное нами) вошло в число ведущих новостных приложений в мире по версии Google — наравне с New York Times, CNN и BuzzFeed. Но что стояло за таким результатом?

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

Когда мы впервые задумались о проектировании, мы решили строго за рамки разработки вынести только проектирование интерфейса. Сценарии же, по которым пользователь взаимодействует с интерфейсом приложения, были только у дизайнера в голове. Работая над приложением «Коммерсанта», у нас за плечами уже были версия для Windows Mobile (помните такую?) и планшетная версия для iPad. Проекты были непростые, в процеccе многое пришлось переделывать, поэтому когда мы взялись за версию для iPhone и Android, мы решили учитывать свои же ошибки и сразу все делать правильно. Мы сделали навигационную модель приложения, нарисовали прототипы большинства экранов и показали клиенту. Клиент сказал OK, ему все понравилось. Тогда с чувством выполненного долга мы нарисовали дизайн и даже снабдили его пояснениями для разработчиков. Мы думали, что все позади.

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

Чтобы понять всю трагедию момента, нужно представить, что компоновка всех частей интерфейса уже сделана, более того, сама навигация между материалами в приложении тоже согласована и организация экранов была сделана, опираясь на эту навигационную модель. Иными словами, взять и сделать «панельку» заголовка больше нельзя, разъедется все вокруг. Боже!

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

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

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

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

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

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

Объем функциональности приложения был большой и первую внутреннюю версию приложения мы увидели через несколько месяцев, а представление руководству состоялось через 7 месяцев после начала проекта, когда мы считали приложение готовым к релизу. На следующий день мы получили то самое письмо. Из письма следовало, что приложение руководству не понравилось, что буквально через несколько недель запланирован официальный анонс и что нам нужно очень поторопиться, чтобы все исправить. Что именно исправить, сказано не было. Занавес!

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

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

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

Конечная цель проекта — сделать мобильное приложение, которое будет приносить пользу клиенту. Об этом легко забыть, когда начинаешь бороться с проблемами в проектах. Начинает казаться, что главный враг — клиент. Чтобы проект технически состоялся, должны быть соблюдены определенные условия и ясно озвучены требования, и в большинстве случае клиенту их нужно помочь сформулировать.
С другой стороны — наше проектное бюро все-таки решает технологические задачи. Даже когда мы занимаемся проектированием пользовательских сценариев и интерфейсов, все равно речь идет про оптимальное решение уже поставленной бизнес-задачи. Именно так родилась схема, когда между клиентом и нашим проектированием появляется компетенция по аналитике — поиску и формулированию бизнес-требований и метрик. Метрики позволяют в дальнейшем оценить, насколько проект достиг своих целей. После объединения с AGIMA.mobile мы остановились именно на такой схеме — когда проект идет по эстафете от клиента через бизнес-аналитику к проектированию, и только после этого к разработке.