Управление проектами при разработке мобильных приложений

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

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

Всегда помните, что если в одном месте у вас что-то сработало, не факт, что сработает в другом. И наоборот, если вы где-то что-то попробовали, но не получилось, в следующий раз придите и попробуйте еще раз.

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

Я достаточно давно уже в ИТ, начинал разработчиком, был тимлидом, занимался разработкой под заказ и тиражными решениями. Достаточно долго работал в фирме «1С». Сейчас помогаю другим командам выстраивать процессы разработки, работать с проектами.

Делюсь интересной информацией и опытом в своем телеграм-канале, публикую шаблоны, подходы.

Кейсы будут про компанию CarMoney. Это финтех, лидер на рынке займов под залог автомобиля. На текущий момент кредитный портфель компании превышает 4 млрд руб., и те два мобильных приложения, которые мы разработали под Android и iOS, сейчас дают 75% всех продаж в этой компании.

Немного статистики

Начнем с цифр.

• На январь 2021 года количество смартфонов в мире уже превышает количество людей на планете. Это связано с тем, что у одного человека больше одного телефона – 2 или 3. У меня, например, 3.

• Вторая интересная цифра – на текущий момент около 60% населения земли имеют доступ к интернету.

Эти два факта подтверждают, что направление мобильной разработки достаточно современное, перспективное, и этим стоит заниматься.

Продуктовый менеджер vs менеджер проекта

Часто слышу вопрос, чем роль продакт менеджера отличается от роли менеджера проектов.

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

• Менеджер проекта отвечает за состав работ, тактические задачи и сроки, когда конкретно это будет сделано.

Их работу оценивают по-разному:

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

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

Мне нравится еще сравнение, что продакт менеджер отвечает за ту точку на карте, куда мы идем, а менеджер проекта – это человек, отвечающий за оптимальный путь, по которому мы дойдем до этой точки.

Хотя когда я пришел в компанию CarMoney, моя должность не называлась продакт менеджер или менеджер проекта – я работал со всеми задачами, которые требовалось выполнить. И в общем-то неважно, как называется позиция, самое главное – двигать направление и давать результат.

Lean Canvas vs реальность

В 2017 году, когда я пришел в компанию, это был однолетний стартап. Но уже тогда был сайт, сам финансовый продукт и понимание, кто наша целевая аудитория.

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

Есть замечательная модель Lean Canvas, рекомендую присмотреться к ней. Это некая кристаллическая решетка, вокруг которой строится продукт. Если совсем коротко, на листе А4 описывается:

• какие боли клиента мы решаем;

• какие альтернативные пути есть у этого клиента, и сколько они для него стоят;

• как мы будем решать эти боли;

• сегментация клиентов.

Все это собирается на один лист, чтобы контролировать, что все принимаемые решения по продукту соответствуют этой модели кристаллической решетки.

В тот момент у меня не было Lean Canvas, но сейчас мне хочется, чтобы вы в своих проектах использовали этот подход и строили решения на нем.

Команда разработки

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

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

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

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

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

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

Также мы не забыли и про поиск внутри ИТ-команды компании. Нам помогла внутрикорпоративная реклама нашего проекта, как нового направления в компании. Мы нашли сильного специалиста, который заскучал на своем участке и перешел к нам на бэкенд-разработку. Отсюда тоже рекомендация: опросите специалистов своей компании, возможно кому-то будет интересно прийти именно к вам на проект.

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

Этот отдельный набор экспертизы позволил нам отобрать подрядчика для разработки мобильного приложения на iOS. Разработку под Android мы делали своими силами, потому что 75% наших клиентов были клиентами Android-приложений и только 25% пользовались iOS.

На Android мы проводили эксперименты, оттачивали UX и UI, а затем для iOS уже ставили четкое ТЗ, давали реально работающее приложение на Android и просили «сделать то же самое, только на iOS». Таким образом разработка под iOS хотя и немного отставала от Android, но велась при скромном бюджете.

Профиль клиента

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

Аватар нашего клиента – молодой предприниматель по имени Иван, 33 года, живет в городе Железнодорожном, занимается продажей цветов. Телефон у него на Android, ездит на Ford Focus 2012 года, кредитуется два раза в год по 250 тысяч рублей.

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

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

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

Заинтересованные лица

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

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

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

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

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

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

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

Требования и приоритизация

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

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

• Кроме того, задач всегда больше чем ресурсов. Поэтому без приоритизации никуда. Методов приоритизации по задачам достаточно много. Мы использовали свою скоринговую модель оценки приоритетов, где в т.ч. любую задачу сразу же анализировали с точки зрения трудозатрат. Были оценки – 2 дня, неделя, месяц и больше месяца. Такими крупными мазками разработчики давали нам понять, стоит ли надеяться, что мы это реализуем в ближайшее время или нет.

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

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

  • После того как выдвигается гипотеза, делается MVP (минимально жизнеспособное решение) и проверяется, насколько эта идея правильная. Либо проводятся А/В-тесты.

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

Спецификация vs прототип

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

Как мы делали у себя?

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

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

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

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

Основная цель – продукт должен быть понятен как заказчикам, так и команде разработки. И охватывать целиком всю задачу.

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

Работа над двумя версиями App

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

Таким образом у нас разработка шла в два потока: и по одному приложению в два потока, и по второму приложению в два потока.

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

Метрики и аналитика

Метрики – это те ориентиры, которыми должен оперировать продуктовый менеджер.

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

В CarMoney мы взяли за ориентир:

• количество лидов – сколько раз скачали мобильное приложение;

• количество заказов – сколько подали заявок на кредит;

• и сколько реально выдано кредитов.

Эти базовые метрики мы завели в мобильное приложение, и было очень удобно сравнивать каналы:

• столько продается через мобильное приложение;

• столько по телефону,

• столько через сайт.

Это были разные каналы продаж, но единая метрика для сравнения.

Есть универсальные метрики для мобильных приложений:

• дневное количество пользователей;

• месячное количество пользователей;

• удержание.

Их тоже можно завести.

И обязательно подумайте, как вы будете собирать аналитику в мобильном приложении. Даже если на первом этапе у вас не хватает ресурса сделать аналитику, об этом стоит подумать.

У нас получилось так, что мы торопились, запустили мобильное приложение, первую версию выпустили, потом подумали про аналитику. И оказалось, что нам с технической точки зрения нужно вносить правки. Мы потом 2-3 недели меняли техническую архитектуру приложения, чтобы можно было встроить и собирать аналитику.

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

Мы в свое время попробовали разные инструменты, которые есть на рынке, но в результате остановились на Арр-метрике от Яндекса и всю аналитику смотрели там: во-первых, она бесплатная, во-вторых, она кроссплатформенная.

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

Неважно, какой инструмент вы возьмете, главное – используйте только его. Как только вы начнете сравнивать, например, метрики от Яндекса и Google Analytics, доверие упадет и к одному, и к другому, и где правда, будет непонятно.

Поэтому выберите один и ориентируйтесь на относительные числа.

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

Документация

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

Проблема всех менеджеров в том, что люди смертны. И обычно это происходит внезапно. В литературе встречаются «фактор автобуса», «фактор кирпича», неважно, как это называется. Это тот момент, когда ключевые знания о продукте, проекте, приложении уходят вместе с ключевым сотрудником. Чтобы такого не случилось, нужно все вовремя документировать.

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

• документация пользователя;

• новое в релизе.

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

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

Дорожная карта и релизы

Обязательно нужно помнить, на каком языке общаться.

• Если мы общаемся с бизнесом, то мы говорим про какие-то календарные даты, можно в PowerPoint готовить презентации и говорить о каких-то крупных блоках.

• А если вы разговариваете с разработкой, эти крупные мазки с карты надо трансформировать в какие-то конкретные эпики из бэклога, в планы на спринт и график релизов.

Советы

Советы самому себе в прошлое, если бы я мог вернуться назад.

• Не бояться брать на себя ответственность. Неважно, как называется твоя должность: продакт, проджект или просто руководитель направления.

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

• Если ваше решение будет ключевым для компании, то искать ребят в штат. Какие-то дополнительные сервисы вы можете поручить подрядчикам. Но с подрядчиками очень аккуратно.

• Если вы пришли на проект с нуля и еще непонятно, кто ваш клиент, рекомендую использовать фреймворк Jobs To Be Done. Он позволяет сегментировать пользователей и оценивать, какую работу этот потенциальный клиент собирается делать с помощью вашего приложения. После того как вы сегментируете пользователей, опишите по каждому сегменту профиль клиента. Этот профиль клиента нужно поддерживать в актуальном состоянии на протяжении всего проекта.

• И важный момент – управление ожиданиями заинтересованных лиц, их отслеживание. Люди приходят и уходят, и надо понимать, как с ними работать.

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

• Согласовывать задачи с заинтересованными лицами в виде прототипа – это позволяет работать в два потока: прототип и техническая реализация.

• Самые лучшие метрики – бизнесовые. Но продумайте, как будет строиться аналитика.

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

• И правильно выбирай язык общения: дорожная карта – для бизнеса, а фичи, релизы, спринты – для команды разработки.

Главное, чтобы вы начали двигаться. У серийного предпринимателя Оскара Хартманна один из подходов к жизни – предпринять как можно больше попыток что-то сделать.

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

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

Вопросы

1. Вы отдельно разрабатывали Android-приложение и отдельно iOS-приложение? А почему не использовали платформу 1С? Там же можно конвертировать как в Android, так и iOS одновременно.

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

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

У менеджера проекта есть отдельная большая работа по планированию коммуникаций на проекте – какие проводить активности, как работать с заинтересованными лицами.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.