{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

От эффективности до карго-культа один шаг: как обесценить проектные ритуалы

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

Директор проектного офиса 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 формально и ходить на них, потому что все так делают.

Ритуалов, которые мы не осветили, существует ещё очень много. Кроме этого, есть ещё и кастомные ритуалы: ваши, командные, внешние. Не надо бояться пробовать, внедрять и отказываться от устаревших.

0
3 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
KODE
Автор

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

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда