Тренер в аренду: как работать с менеджером на аутстаффе

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

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

Мы в Ratio работаем без офиса — все сотрудники удалённые, включая менеджера Ольгу Бочарову. В Беларусь ей ехать не пришлось, но она всё равно столкнулась с последствиями протестов: в первые дни продуктивность разработчиков упала в три раза.

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

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

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

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

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

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

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

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

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

В итоге сервис запустился и пока работает в закрытом режиме (около 300 клиентов-фотографов). Vigbo продолжает разрабатывать новые версии.

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

Дальше я расписываю каждый шаг гайдлайна подробнее — с советами и примерами нашей работы над проектом Vigbo.

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

Мы начали менеджерить «Клиентские галереи» Vigbo 16 июля. По плану запуск должен был состояться уже в начале августа, то есть через две недели. Срок откровенно нереалистичный. Соответствовать старым ожиданиям было невозможно, поэтому менеджеру пришлось создать новые.

Мы разобрались с ожиданиями в два этапа:

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

Всего получилось четыре столбца: дизайн, бэкенд, верстка, интеграция. Мы посчитали время с учётом выходных дней и параллельной работы над вёрсткой и бэкендом. Также заложили в оценку риски через коэффициент. Тогда взяли x1,25, но если бы знали о протестах, легко выставили бы x2-x3.

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

Чтобы не затягивать старт, мы решили отказаться от некоторых функций в первом релизе и начать с MVP-версии. Дата релиза сместилась на конец сентября.

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

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

Мы взяли Slack, Jira и Zoom — все три инструмента давно применялись в Vigbo, поэтому проблем не возникло. Когда этого инструментария стало не хватать, начали дублировать информацию в другие сервисы, но сотрудники всё равно пользовались старыми приложениями.

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

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

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

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

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

Раз в неделю гендир получал подробный разбор: роудмапы по релизам и MVP, отчёт по выработке и информацию со всех утренних созвонов.

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

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

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

Сроки затягивались, иногда интернет отрубался полностью и работа вставала совсем. Так мы на своём опыте узнали, что в плане продуктивности протесты находятся где-то рядом с новогодними праздниками.

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

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

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

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

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

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

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

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

Они самостоятельно тестировали функции и сравнивали их с описанием. Вопросы появлялись, но не очень часто.

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

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

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

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

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

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