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

Вадим Митякин, руководитель отдела проектирования AGIMA.mobile/Gals:

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

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

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

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

Симптомы

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

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

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

«Это же очевидно!»

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

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

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

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

— А как будет выводиться длинный заголовок статьи на этой маленькой панельке?
— Но ведь дизайн был OK?
— Да, но это же очевидно!

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

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

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

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

The app was not found in the store. :-(

Go to store Google websearch

«Вы сделали не то, что я хотел!»

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

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

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

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

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

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

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

Что в итоге

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

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