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

Это называется заморозкой продукта.

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

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

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

Исходное состояние

В нашей небольшой команде было: три разработчика, аналитик, проектировщик, тестировщик и менеджер разработки.

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

0. Выдохните

Какой бы злободневной не была новость о заморозке, не торопитесь вносить её в команду без подготовки (ну или в панике).

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

Подумайте над примерным планом действий, который вы сможете транслировать в команду. Сейчас главное — снизить градус тревожности. Подумайте, как показать, что ситуация под контролем, что у вас есть понимание, как её разрулить, и что мир не рухнул.

Сначала выдохните. А затем действуйте.

1. Подумайте, как подать новость команде

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

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

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

2. Дайте выговориться и расскажите, что дальше

Сразу после объявления соберите команду на встречу, где вы сможете обсудить услышанное в безопасной атмосфере: проговорить все страхи, выразить негодование, погрустить вместе. Расскажите команде, что будет дальше, понизьте уровень неопределенности будущего. Вы ведь классный менеджер, который взял тайм-аут, чтобы подготовить хотя бы примерный план, в который можно будет посвятить команду, правда?

Мой план был таким:

• Довести до релиза задачи, которые сейчас в разработке.

• Четко определить, что значит «продукт на поддержке».

• Перекопать бэклог и решить, что мы успеем сделать до того, как команда будет распределена на другие проекты.

• Организовать процесс поддержки: кто и как будет чинить баги, если команда будет занята на других проектах.

• Найти предложения по новым проектам для команды.

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

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

3. Вовлекайте команду

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

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

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

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

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

4. Помогите найти новый проект

В Контуре множество продуктов, поэтому всегда есть возможность найти другую команду.

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

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

5. Не бойтесь просить о помощи

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

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

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

Или дождитесь мою следующую статью, где я расскажу про основные шаги!

Итоги

Мы успешно заморозили проект за один месяц. Эти сроки мы в команде поставили себе сами. Я сообщила руководству о нашем плане и о сроках этого плана — в итоге всё получилось так, как было задумано.

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

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