Хабрахабр

Управляем большим длинным проектом: почему важно разговаривать словами

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

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

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

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

Он: «Хочу, чтобы в почте оставались следы». Задержки продолжили копиться.
Спрашиваю, зачем он так делает. У него всё понятно, в какой момент какие исполнители какие обязательства нарушили. К моменту разборок, когда проект будет сорван, чтобы каждый знал, как так вышло.

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

Это прямо критично для больших проектов.

Управление коммуникациями

Одна из компетенций хорошего ПМа — это управление коммуникациями. Это официальное название ситуации, когда каждый знает, что происходит и зачем нужен его кусок работы. И на что он влияет. Может показаться, что обычному линейному инженеру такое знание не нужно, а обычный линейный разработчик должен писать код, но на деле всё это важно и прямо влияет на проект. Потому что вместе со знанием о движении передаются смысл, эмоции и обсуждаются разные нежданчики. А любой проект во многом состоит из нежданчиков и трений между командами. Если бы все были телепатами, мы бы уже выращивали яблони на Марсе.

Оказывается, там мы несколько месяцев согласовываем сметы на допработы, всё чётко по процедурам заказчика. Вторая иллюстрация: я узнаю о проекте, где полгода как по срокам уже всё должно быть сдано, а работы на площадке остановились и не идут. ПМ говорит: мол, сложно, мы залезли в чужой конкурс, проектная документация не годится, нас не любят, продавец, не надо было подписывать этот договор». Команда в полной уверенности, что получим деньги и тогда начнём работать. Он говорит: «А чего вы этого РП ещё не уволили? Иду к сейлз-менеджеру, который отвечает за общение с заказчиком. И почти сразу от заказчика приходит претензия вместо согласования смет — мол, давайте платите штрафные санкции, а потом будем договариваться, как будете доделывать. Ничего не двигается, мне перед заказчиком стыдно».

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

Почему важно собирать эти чёртовы собрания?

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

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

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

У нас был проект — руководитель подготовил план, согласовал со всеми участниками от нас и отправил заказчику. Вот яркий пример того, как бывает, когда обмен информацией вжимается в минимальный канал. Каждую неделю отчёты. Чтобы не получалось, что заказчик не в курсе, что происходит. Вроде нормально всё. По этому плану он и отчитывался. Поехали на совещание через три недели. Думал, что всё хорошо. И тут они берут и достают свой план. Приходим и говорим: мол, как вам нравится всё? Наш они даже не смотрели. У них, оказывается, есть совершенно другие пожелания по тому, в каком порядке и что делать. Но непонятно. Писать про это не хотели, потому что вроде работы идут, всё хорошо. Или просто лень. А когда непонятно, местами неудобно говорить «я не понял». И только в устной коммуникации удалось понять, что мы по-разному всё видим. Или просто всё окей, ну и не надо трогать. Мы каждую неделю понимали, что делаем то, что надо, и заказчик в этом участвует. Пошли по их плану, пошло взаимодействие, появились проблемы, вопросы, обсуждения и решения.

Это тоже очень важно.

У всех много вопросов. Задача ПМ — обмен информацией, чтобы инженеры знали, что они делают и кому о чём сообщать; заказчик знал, что происходит, когда ожидать результатов и какими будут результаты; архитектор знал про ограничения, в рамках чего проектировать и с кем общаться. Рассказать, что за неделю сделано и что планируется в ближайшее время. Один из методов — статусные совещания. Зависит от того, какое решение примет ПМ — или каждому письмо, или всем один раз, или обзвонить, или звонок на толпу. В принципе, его можно и не делать — можно докладывать не еженедельно, а когда будут результаты, в зависимости от интенсивности и объема работ по проекту, или можно отзваниваться. Потому что к нему надо ещё и готовиться, что, к тому же, позволяет человеку самому собраться, найти всю нужную информацию, поделиться с командой, а не пускать что-то на самотёк. Привычная практика у нас — статусное совещание.

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

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

Когда работать над проектом-то?

Вот план по одному из проектов:

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

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

Провоцирует. Второй вопрос — не провоцирует ли такой частый обмен информацией с заказчиком изменения в ТЗ? И это хорошо, потому что цель — сделать то, что надо, а не что заказали и сформулировали. Если ТЗ было плохо сформулировано, то будет меняться чаще. Крайне редкий случай на проектах, когда ТЗ сразу хорошее и нужно просто сделать чьими-то руками. Чем раньше обнаруживается необходимость изменения, тем дешевле и быстрее оно реализуется. И крайне редко заказчик хочет сделать по ТЗ, а не как надо, — это, скорее, область юридически сложных проектов. Тогда будет минимум изменений, тогда и пойдёт стиль руководства через письма, описанный выше, но только если команда замотивирована на результат, а это большая редкость в наших реалиях, когда мы не запускаем фалконы. Но про это хорошо написал мой коллега в посте про то, что делает руководитель проектов. Обычно же задача — сделать так, чтобы проект подходил.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть