Менеджмент проектов на удаленке. Что изменилось

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

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

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

Мир раньше

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

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

Новая эпоха — как начать проект с нуля удаленно

В апреле прошлого года мне посчастливилось формировать команду для fixed price проекта (когда бюджет на разработку проекта и сроки его сдачи утверждаются перед стартом и остаются неизменными).

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

Небольшое отступление. Я занимаюсь йогой около 10 лет и с искренним интересом изучаю работу нашего мозга. Давненько для себя уяснила, что мозг человека ленив и всегда ищет способы, как бы упростить задачу и потратить как можно меньше ресурсов. Формирование новых нейронных связей возможно, только если мы приложим усилия и заставим мозг, буксуя и протестуя, сделать что-то по-новому. Либо если случиться какое-то неожиданное событие, которое заставит мозг включить «режим выживания и поиска новых решений».

Именно такое событие случилось у меня, и речь не о пандемии. За пару дней до запланированного удаленного kick-off звонка у меня умерла мама. (Ой, у нас же не принято очень открыто о таком говорить и тем более писать об этом в статье о работе). Я пришла на встречу, имея предыдущий опыт работы только с архитектором, остальные члены команды видели меня впервые в жизни, и сказала:

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

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

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

Считаю, что ключевым фактором «успеха» были бОльшие инвестиции в общение членов команды, так как намного больше рисков недопонимания во время удаленного шторма. Что же нам помогло:

1. Четкое описание ролей и зон ответственности на старте.

2. Во время kick-off встречи договориться с командой, какой способ коммуникаций подходит для какого рода вопросов, например:

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

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

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

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

6. Любую работу над документами (особенно если это обязательный результат работы проекта) организовывать итеративно (то есть небольшими отрезками времени), чтобы «петли обратной связи» были достаточно небольшие. Это позволяет вовремя услышать коллег и заказчиков и внести изменения в документ.

Расширение команды удаленно, когда «ядро» работает вместе годами

Ближе к осени несколько заказчиков запросили рост команд. Стоит отметить, что все эти команды не находились изначально в одной локации (например, Киев). В основном они распределены минимум между двумя локациями (Киев- Хьюстон) или даже тремя (Киев-Днепр-Хьюстон).

При этом все они в свое время уже прошли классический storming и находились на стадии norming\performing. До эпохи пандемии одна из команд даже ездила к заказчику в Хьюстон в полном составе, также ребята приезжали друг к другу в Украине.

Таким образом у нас был «костяк команд» (core team), который давно работал вместе, они знали друг друга лично, а не только фотографию на экране Zoom. И перед нами стояла задача запустить в команды «молодую кровь» и сделать это так в новых условиях работы, чтобы и не пожирать много времени у существующих членов команды, но и чтобы новички не чувствовали себя брошенными на произвол судьбы.

Решения и инструменты, чтобы смягчить погружение новеньких в проект

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

1. Заказ учетных записей для работы с ресурсами клиента сразу после принятия оффера.

2. Инвестиции в документацию по проекту:

• наличие вводной информации про компанию и заказчика в одном месте;
• инструкции по настройке окружения проекта;
• описание процессов проекта (где это возможно).

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

4. Постановка конкретных целей (согласованных с заказчиком) на первые три месяца (далее тоже важно конечно, но это отдельная история).

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

В то время как очень сеньорный разработчик 3D с первых дней на проекте получил задачу в ближайшие три месяца быть посредником между двумя командами (временным прокси продакт-оунером), чтобы разобраться со спецификой продукта и со временем забрать функционал в нашу команду.

5. Мониторинг настроения новичка на регулярной основе с помощью проведения 1:1.

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

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

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

7. Работа с заказчиком по получению обратной связи про новичка.

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

8. Упражнение Mind Map (можно с miro.com), с помощью которого у каждого члена команды есть возможность рассказать что-то личное (про увлечения, мечты или семью). Понимая, что техлид тоже любит кататься на велосипеде (например), новичку-разработчику намного легче начинать small talk, и коммуникации естественным путем становятся менее напряженные.

9. Культивирование внутри команды практики knowledge sharing. Например, в одной из команд началась серия воркшопов по 3D-разработке, чем я безумно горжусь. Данные воркшопы — это кастомная разработка нашего идеолога 3D-разработки. Ему самому в кайф делиться знаниями, а покуда у проекта есть запрос на большее количество экспертов данного направления, наш идеолог создал программу и помодульно проходиться по ней со всеми желающими разработчиками проекта, независимо от сеньорности.

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

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

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

Скажу очевидное: мы так соскучились за личными встречами за кофейком или просто прогуливаясь на улице (да, я так часто проводила 1:1 встречи ранее), что сейчас каждая возможность увидеть члена команды лично вызывает детский восторг. Возможно, нам всем дан этот новый этап в развитие общества, чтобы мы научились ценить такие простые радости.