На чужом опыте: 5 проблем и 5 решений при аутсорс-разработке мобильного приложения на примере Nullgravity и Altel

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

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

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

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

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

Вывод: предлагайте простое и наглядное решение — кликабельный прототип — которое легко воспринимать и гораздо быстрее реализовывать.

Проблема: Если идея крутая, профит очевиден, создание нового продукта всегда встречается всесторонней поддержкой. А вот анализ требований и их формализация знаменуется тем, что каждый вспоминает о личных целях и KPIs своего отдела. Product management команда отвечает за управление продуктом и они готовы подать большой список требований к приложению. У саппорта другие цели: надо снизить нагрузку на центр поддержки пользователей, а значит нужно сделать внутри продукта FAQ. Отдел продвижения продукта хочет иметь внутри приложения много новых аналитических сервисов, ну и чтобы как конфета был! Так кто из них прав?

Решение: Все очень просто. Решает тот, кто делает компании профит. Нет, речь не о топ-менеджменте. Я говорю о пользователях! Приложение нужно создавать, исходя из их желаний. Тогда и будет конкретный результат: увеличение прибыли. Nullgravity стали не просто подрядчиком Altel для поставки аутсорсинг-разработки. Мы стали полноценными партнерами, погрузившись в их бизнес и наконец-то определив, что нужно пользователю. Не СТО, не СМО, не СОО. Пользователю.

Вывод: любой запрос на изменение вектора проходил через фильтр простого вопроса: «Какую проблему клиентов Altel решает эта фича?». Будьте Product Owner'ами на проекте!

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

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

Вывод: предлагайте готовые решения, пока клиент размышляет, будьте проактивными.

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

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

Главный офис Altel расположен в Алматы. Мы с командой — в Киеве. И пускай скайп-звонки помогали синхронизации, этого было недостаточно. Мы пригласили ребят из Altel в Киев: организовали встречи, рассказали о процессах и подходах. Head of Design презентовал методологии разработки UI/UX, Development Team Lead рассказал о роли Agile в компании, портфолио-менеджер рассказал о стратегии презентации приложения на рынке. Была и часть «без галстуков» — экскурсии по улицам и маленьким барам, встречи на ужин и обед. В результате мы стали больше чем просто представители заказчика и подрядчика. Мы лучше поняли мировоззрение друг друга. Так рождается доверие, а отношения наравне возможны лишь с ним.

Вывод: старайтесь проводить личные встречи в формальной и неформальной обстановке. Рассказывайте о своем подходе в бизнесе.

Проблема: За неделю до релиза мы были в максимальном стрессе. Команда работала на последнем выдохе, последний месяц — практически без выходных. Был сильный риск «выгорания» команды. Что делать?

Решение: Главный «заряд» для команды — это вовлеченность всех в создание продукта. Личная встреча с командой Altel стала дополнительной мотивацией во что бы то ни стало отдать продукт вовремя. Продукт стал нашим. Команда понимала — идем до конца. И речь не о том, что мы кого-то подведем — в первую очередь мы подвели бы себя, ведь продукт стал своим. Проджект-менеджер всегда выходил с командой на работу на выходных и уходил с работы последним, чтобы команда оставалась командой. Scrum-мастер собирал фидбек ребят, и в нужный момент говорил: «Стоп, завтрашний выходной — будет выходным», чтобы дать команде передохнуть. Командный дух — не слова, а процесс, где каждый несет долю ответственности. И если им не пренебрегать, можно преодолеть любые вызовы.

Вывод: не пренебрегайте командным духом, потому что в крайне стрессовых ситуациях это то, что вытащит проект.

За 2,5 месяца Altel получили полнофункциональный продукт, на разработку которого в обычных условиях нужно полгода. Требования стейкхолдеров были учтены и имплементированы, требования пользователей — тоже. Приложение помогло Altel представить своим клиентам новый уровень сервиса. Просто, удобно, интуитивно. Altel рискнули, отдав нам разработку приложения с такими сроками. Мы тоже рискнули. И риск оправдался для обеих сторон.

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