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

Меня зовут Юлия Затонская, я проджект-менеджер в 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! А потом — рано или поздно — приложение таки будет опубликовано, и наступит настоящее счастье от круто проделанной работы. 

Комментарии (10)


  1. amarao
    28.01.2022 15:19
    +7

    Команда, занимающаяся обсерваторией "Джеймс Вебб" не делала релизов 14 лет, а потом сделала один-единственный деплоймент. Успешный.


    1. gleb_l
      28.01.2022 16:25
      +1

      Все правильно - цельным и самодостаточным людям фантики для мотивации не нужны. У них другие мотиваторы.


    1. zatonskaya
      28.01.2022 16:47

      Это сильно!


    1. WraithOW
      28.01.2022 16:59
      +2

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


      1. amarao
        28.01.2022 17:01

        Конечно. Но релиз у них был один.


        1. AzIdeaL
          28.01.2022 17:28

          "... и наступит настоящее счастье от круто проделанной работы. (- точка: жирная))


          1. zatonskaya
            28.01.2022 22:38

            Точка вместо улыбочки, чтобы проверить, кто дочитает до конца :)


  1. funca
    28.01.2022 16:20
    +1

    Но бывает, что продукт создан вовремя, а заказчик переносит релиз

    Из рассказа не очень понятно, были ли реализованы все хотели заказчика в срок и какого тогда рода задачами занималась команда ещё пол года? С какой целью заказчик стал оплачивать работу команды в этот период?


    1. zatonskaya
      28.01.2022 16:54
      +2

      Привет!)

      Да, это была MVP версия и все обговорённые хотелки мы реализовали в срок. И релиз отменился из-за желания заказчика получше подготовиться к выходу его продукта в паблик (короче, налаживал свои внутренние процессы)

      Заказчик хотел развивать приложение, поэтому мы брали задачи из бэклога. Сам же бэклог у нас был сформирован ещё до старта разработки - это те фичи, которые не вошли в MVP версию


  1. 0x4eadac43
    29.01.2022 13:52

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