Качество конечного продукта напрямую не связано с качеством процессов и ритуалов управления проектом. Но косвенная связь есть, и не учитывать это проджект-менеджеру нельзя. Если команда разуверится в ритуалах, то менеджер лишится многих инструментов, которые помогают ему управлять проектом.
Директор проектного офиса KODE Вадим Кузенков и менеджер портфеля проектов Елена Гика предлагают пройтись по некоторым ритуалам и посмотреть, как можно сделать их качественнее.
Какие проектные ритуалы мы используем
Качество процессов управления — это место, где ПМ может и должен приложить максимум усилий и затащить проект даже с очевидно слабой командой, заодно прокачав и команду.
Мы умышленно не будем касаться ритуалов или процессов, которые нацелены на повышение качества самостоятельной работы каждого отдельного члена команды — разработчика, дизайнера, аналитика и так далее. Акцент — на процессах управления.
Для статьи мы выбрали самые популярные ритуалы и расскажем, как они успешно обесцениваются.
Кик-офф или установочная встреча
Дейли митинг или стендап
Ретроспектива
One-on-one (О3)
Кик-офф или установочная встреча
Кик-офф — это первая встреча участников проекта. На ней обычно обозначают цели проекта, определяют основные роли в команде и обсуждают, как будет выстроена работа.
Итак, вы стартанули проект и, как водится, собрали кик-офф. Что может пойти не так?
Забыть позвать аккаунта или сейлза. Эта роль в разных командах называется по-разному, но именно аккаунт на старте проекта лучше всех знает заказчика и бизнес-цели и может правильно, без помех передать это команде. Пропустите этот этап — получите от команды невовлечённость и формальное закрытие тасков.
В команде новый человек. Что, опять кик-офф? Да, причём и бизнесовый, и профессиональный. Новый человек со временем почувствует правила игры и примет их, но может пройти много времени, а за это время команду может изрядно «поштормить» — вспомните про Такмана и его модель формирования команд.
Забить на онбординг. Может случиться такое, что на старте у вас не будет всей команды, и люди будут подключаться постепенно. Прекрасный повод, чтобы в какой-то момент вообще забить на погружение людей в проект. На самом деле, это триггер для следующей оптимизации. Самое время сделать страницу с онбордингом, например в Конфлюенс, которая может частично заменить очный кик-офф.
Обычно на странице онбординга перечислены все цели, понятия, источники знаний, доступы, архитектурные и технические решения — всё по проекту. Если у вас уже есть паспорт проекта, то он тоже подходит, только уберите оттуда чувствительную информацию: рейты, суммы, первоначальные оценки.
На крупных и долгоживущих проектах вполне могут быть отдельные технические онбординги для тестировщиков, разработчиков, дизайнеров и прочих функциональных ролей в команде. Со временем проект обрастает большим количеством технологий, решений, часто спорных и неочевидных, — и это необходимо фиксировать.
Онбординги помогают новичкам быстро погрузиться в проект, а в будущем — напомнить о зафиксированных правилах. У нас в KODE на долгоживущих проектах больше одного онбординга: общий и технические для разных функциональных ролей.
Дейли или стендап
Самый, пожалуй, распространённый ритуал в скрам-и-не-только командах. Ещё этот ритуал чаще других подвергается сомнению со стороны команды. Бывало ли у вас такое, что в какой-то момент команда говорила: «Зачем их проводить так часто, давайте пару раз в неделю!». Это один из признаков того, что у вас плохие дейлики.
Здесь многое может пойти не так.
Обсуждать проблемы прямо на дейли. Обычно это только затягивает встречу. Фиксируйте проблемы и обсуждайте в рамках рабочих встреч («скрамов») с более узким составом участников. Помните, что фокус внимания у людей очень мал — 15 минут. Старайтесь уложиться.
Превращаться в менеджера-снежинку. Если ваш модный дейлик становится похож на селекторное совещание, это верный путь к тому, что команда перестанет видеть ценность этого ритуала. Помните, вы не начальник, вы — часть команды, другая командная роль, фасилитатор, клей, слуга.
Менеджеру тоже важно говорить, как у него дела и какие проблемы. Поверьте, команде очень интересно, что вы там делаете.
Люди забывают, что сделал ≠ делал. Это критически важно. Слушать про то, что Виталя уже второй день делает вёрстку, максимально неинтересно. ПМ-ов это должно триггерить, потому что глагол «делать» не говорит ни о чём конкретном. Это может значить, например, что Виталя вчера весь день обновлял какую-нибудь библиотеку в вашем проекте — это в рамках задачи, но это не вёрстка. Любому члену вашей команды всегда есть чем похвастаться или, наоборот, на что-то пожаловаться, если, конечно, он вообще работал.
Люди говорят скучно. Это и про смысл, и про интонацию. Глупо требовать оскароносных речей от вашей команды. А вот просить говорить интересно вполне можно. Бремя ответственности за живость дейлика ложится на ПМ-а. Склеивайте встречу, не давайте ей протухнуть, добавляйте переходы, короткие комментарии, шутки. Только не перебивайте.
Ретроспектива
Это один из лучших ритуалов командной работы. Он прямо влияет на качество проекта и процессов в нём, потому что его основная цель — увеличить эффективность работы команды через её комфорт и улучшение процессов. Есть и второстепенная — порефлексировать и выплеснуть эмоции. Для многих одно то, что они высказались и их услышали, уже сработает позитивно и улучшит командную динамику.
Запороть ретроспективу очень легко. В отличие от дейлика этот инструмент довольно много требует от фасилитатора, которым часто выступает менеджер.
Итак, как провалить ретро.
Обсуждать отсутствие решений. Есть множество форматов проведения ретро, но во всех в той или иной форме составляют списки проблем. Эту часть очень легко испортить. Люди с большим трудом формулируют мысли в виде проблем, чаще всего дефолтный паттерн — «отсутствие чего-либо».
Если оставить как есть, ухудшится качество генерации решений — тяжело придумать альтернативу тому, что лежит на поверхности.
Придумайте себе несколько вариантов вопроса «в чём проблема»: почему это проблема, где болит и так далее.
Потерять доверие команды. Чтобы команда открылась и стала честно давать обратную связь, сотрудники должны быть уверены, что будут услышаны и что проблемы не спустят на тормозах. Хоть раз кинете фейспалм или скажете разработчику: «Да Петь, это же чушь, ты просто видишь проблему однобоко» или «А кто-то ещё считает это проблемой?» — и вернуть доверие будет крайне сложно. Инструмент просто перестанет работать для вас.
Забить на регулярность. Можно не проводить ретро, потому что «сейчас не получается», «скоро релиз» и «это же столько времени всей команды». Профит от ретроспективы сложно измерить в деньгах, а вот затраты на неё, к сожалению, очень легко. Всё, что связано с людьми, очень косвенно конвертируется в деньги, чтобы это можно было легко сравнить с костами.
Заканчивать ретро лозунгами. Легко закончить ретроспективу со списком лозунгов «за всё хорошее, против всего плохого». Это не сработает и не улучшит ваши процессы, а будет похоже на выкрики со сцены: «Завтра я заработаю свой первый миллион!!!». Эффект от такого ретро улетучится уже на следующем, когда вы поймёте, что проблемы остались теми же. Задачи формулируйте по принципу SMART-ready и следите, чтобы не все из них падали на менеджера.
One-on-one (O3)
One-on-one — один из любимых ритуалов, который мы используем в своих проектах. Мы наблюдали появление встреч один на один с момента, когда это было неофициально: менторы просто предлагали совместную прогулку или обед и узнавали, как дела у коллеги. Сейчас люди приходят в компанию и ожидают формальный O3. Это хорошо, потому что это регулярная встреча с известными правилами, и на ней можно раскрыться.
Тем не менее O3 очень легко испортить и свести к нулю все выстроенные отношения с членом команды, с которым вы проводите встречу.
Опаздывать и формально относиться. Приходить вовремя и не сидеть со скучающим видом — это правило любого общения. И O3 не исключение.
Отвлекаться на телефон. Телефон — это табу на one-on-one. Лучше вообще не брать его на встречу. Если без телефона тревожно, пусть он лежит экраном вниз.
Обесценивать проблемы. Не говорите «не переживай», «ничего страшного» и не называйте проблемы человека ерундой. Так вы только потеряете доверие, а проблема не исчезнет.
Допускать панибратство. Дружеское похлопывание по плечу под запретом, если вы не проверенные товарищи. Жесты должны быть только с тем человеком, который, вы уверены, нормально это воспримет.
One-on-one — это отдельное пространство, чтобы поговорить с менеджером по душам, и люди этим пользуются.
Любой управленческий ритуал — это инструмент. Если не знать и не учиться им пользоваться, в какой-то момент вы обнаружите себя забивающим гвозди пассатижами. Держаться будет, но конструкционную прочность ваш «проект» потеряет.
Вот наш топ вредных советов для менеджера:
Забивать на кик-офф и онбординги — команда сработается со временем сама, да и новички разберутся.
Проводить скучные дейлики, на которых вы подробного разбираете проблему каждого сотрудника.
Не тратить время на ретроспективу.
Относиться к one-on-one формально и ходить на них, потому что все так делают.
Ритуалов, которые мы не осветили, существует ещё очень много. Кроме этого, есть ещё и кастомные ритуалы: ваши, командные, внешние. Не надо бояться пробовать, внедрять и отказываться от устаревших.
