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

Меня зовут Юлия Затонская, я проджект-менеджер в Surf. Расскажу, как мы на протяжении полугода пилили один из наших любимых проектов. И всё было бы круто, если бы не тот факт, что… за полгода не состоялось ни единого релиза. 

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

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

А что такого-то? Ну нет релизов — в чём проблема?

Давайте сначала определим, что такое релиз. Релиз — это предоставление пользователю новых возможностей продукта. В нашем случае — технических возможностей, фич. 

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

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

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

Минусы отсутствия релизов

Вернёмся к истории с проектом. Изначально релиз запланировали на ноябрь 2020 года. Мы с командой подготовили приложение к оговоренной дате публикации, но заказчик дату перенёс. Важно, что останавливать проект никто не планировал: мы продолжали развивать его фичами из бэклога. 

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

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

1. Демотивацию и выгорание команды.

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

Как избавиться от минусов и получить плюсы

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

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

1. Работать по спринтам

Даже если у проекта уже нет цели успеть к сроку, рекомендую делить бэклог на спринты:

1. Выбирать удобный размер спринта для проекта и дату дедлайна. По нашему опыту, оптимальная длина — 2–3 недели.

2. В соответствии с длиной спринта декомпозировать задачи и определять скоуп на спринт.

Круто, если вместе с командой в приоритизации задач и определении скоупа на спринт участвует заказчик.

Плюсы работы по спринтам:

• Задачи не кажутся растянутыми на вечность. У каждой таски есть границы выполнения.

• Можно отследить, на каких фичах команда засиживается и затягивает сроки. Когда некуда стремиться, такая «прокрастинация» вполне возможна. Расписание и чёткие цели помогают держать команду в тонусе.

2. Готовить демо для заказчика после каждого спринта

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

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

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

Плюсы частых демо:

• Повышение прозрачности перед заказчиком.

• Уверенность, что заказчик знает, какие обновления внедряются в его продукт.

• Команда получает дополнительную цель, ради которой стоит трудиться.

3. Получать ревью от коллег

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

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

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

Плюсы:

• Сбор мнений реальных пользователей без публикации приложения.

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

• И снова — появление дополнительной цели, ради которой стоит трудиться.

4. Проводить альфа- и бета-тестирование

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

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

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

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

• Подогреть интерес аудитории. 

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

Плюсы:

• Проверка работы приложения в реальных условиях.

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

• Сбор мнений от реальных пользователей.

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

• Реальный релиз и счастье для команды <3

5. Проводить ретроспективы и one-to-one

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

• Ретро лучше устраивать не реже, чем раз в месяц-полтора.

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

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

• Важно хвалить ребят и отмечать их рост.

Пять инструментов, которые помогут поддерживать боевой дух команды, работающей «в стол»

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

1. Спринты: вместе с заказчиком разбиваем на части фичи из бэклога, устанавливаем дедлайны.

2. Демо для заказчика: после каждого спринта презентуем все изменения на личной встрече (онлайн или офлайн).

3. Ревью от коллег по компании: показываем плоды трудов коллегам, они выступают в роли пользователей и дают ценный фидбэк.

4. Альфа- и Бета-тесты: собираем желающих поучаствовать, проводим тестирование среди них. Это уже почти как реальный релиз, и всем хорошо.

5. Ретроспективы и one-to-one с командой: следим за настроениями в команде, узнаем о проблемах и вовремя предотвращаем катастрофу:D

Profit! А потом — рано или поздно — приложение таки будет опубликовано, и наступит настоящее счастье от круто проделанной работы.