У меня в подчинении был один руководитель проектов, который никогда не собирал совещания. Он был немного хикки и обладал исключительным перфекционизмом (насколько это возможно для ПМа), что выражалось в стремлении всё происходящее фиксировать в почте. Письма были очень детальные, на несколько страниц: содержали все нужные описания, в них фиксировались все обещания, сроки, хотелки, большое внимание уделялось договорённостям и упрёкам в безответственности исполнителей. В общем, идеальные письма, последовательно излагающие ход событий, — хоть книгу по ним пиши.
Но проект шёл медленно: надо же написать письма, потом дождаться ответа и снова написать. Поскольку он был длинным, было ярко заметно, как на третий месяц начали накапливаться задержки и технический долг. Мой коллега продолжал писать письма, фиксируя каждое обязательство и каждый косяк и регулярно перенося сроки. Ситуация накалялась.
Я регулярно просил его собирать руководителей команд, работающих над проектом (инженеров по железу, разработчиков и так далее). Исходя из моего опыта, проблема, скорее всего, была в том, что команды не менялись информацией между собой.
Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.
Задержки продолжили копиться.
Спрашиваю, зачем он так делает. Он: «Хочу, чтобы в почте оставались следы». К моменту разборок, когда проект будет сорван, чтобы каждый знал, как так вышло. У него всё понятно, в какой момент какие исполнители какие обязательства нарушили.
В конечном итоге мне пришлось снять его с этого проекта и поставить нового ПМа, имеющего опыт «длинных забегов» и потребность к общению. Старый руководитель проектов покинул компанию, ему удалось найти себя в коротких проектах на месяц-два, где как раз важнее всего чётко формулировать требования. В длинных же проектах много что меняется и двигается, поэтому любой план рушится. И задача руководителя проекта — сделать так, чтобы это всё двигалось. И очень важный навык — обеспечивать обмен информацией между всеми участниками и выстраивать взаимоотношения.
Это прямо критично для больших проектов.
Управление коммуникациями
Одна из компетенций хорошего ПМа — это управление коммуникациями. Это официальное название ситуации, когда каждый знает, что происходит и зачем нужен его кусок работы. И на что он влияет. Может показаться, что обычному линейному инженеру такое знание не нужно, а обычный линейный разработчик должен писать код, но на деле всё это важно и прямо влияет на проект. Потому что вместе со знанием о движении передаются смысл, эмоции и обсуждаются разные нежданчики. А любой проект во многом состоит из нежданчиков и трений между командами. Если бы все были телепатами, мы бы уже выращивали яблони на Марсе.
Вторая иллюстрация: я узнаю о проекте, где полгода как по срокам уже всё должно быть сдано, а работы на площадке остановились и не идут. Оказывается, там мы несколько месяцев согласовываем сметы на допработы, всё чётко по процедурам заказчика. Команда в полной уверенности, что получим деньги и тогда начнём работать. ПМ говорит: мол, сложно, мы залезли в чужой конкурс, проектная документация не годится, нас не любят, продавец, не надо было подписывать этот договор». Иду к сейлз-менеджеру, который отвечает за общение с заказчиком. Он говорит: «А чего вы этого РП ещё не уволили? Ничего не двигается, мне перед заказчиком стыдно». И почти сразу от заказчика приходит претензия вместо согласования смет — мол, давайте платите штрафные санкции, а потом будем договариваться, как будете доделывать.
На проект поставили ПМа, имеющего опыт выстраивания взаимоотношений. Налаживание коммуникаций с новым руководителем начали с юридического отдела — пришлось. История была в том, что заказчик формально общается, не хочет нас видеть в качестве подрядчика, а мы не замечаем подвоха, наивно ждём денег, а денег с той стороны платить никто не собирается. В итоге синхронизировали данные о проекте на паре больших встреч и доделали. Прибыль была, но куда меньше ожидаемой.
Почему важно собирать эти чёртовы собрания?
Три причины: широкий канал, подготовка к встрече и более короткие итерации. Почта не даёт возможности ответить мгновенно. Обычно ответ приходит в тот же рабочий день или на следующий. Можно сократить сроки итераций проектными чатами или мессенджерами, что существенно переломит скорость разных согласований и обсуждений, — и это очень хорошая практика.
Но нашего хикки это не спасло бы, потому что это только полдела. Вторая половина — сделать так, чтобы команды менялись информацией по широкому каналу, то есть не только в рамках вынужденной минимальной необходимости, но и чуть больше, со всем бэкграундом. В этот фон входят эмоции, приоритеты, задачи и ещё много всего, но главное — много деталей, которые позволяют всем понимать, что делать и как. Практика показывает, что это важно для хода любого длинного проекта. Собственно, все методологии вроде Agile/SCRUM/Холакратии и так далее — они именно про это.
Минимальные итерации и постоянный обмен информацией. Реально, если у нас не разработка и команда не сидит в одном помещении, то совещание, по сути, единственная возможность для руководителя проектов замотивировать команду и отдельных участников на результат, снять все надуманные и явные препятствия и отмазки исполнителей на пути к результату. Опять-таки в силу широкого канала.
Вот яркий пример того, как бывает, когда обмен информацией вжимается в минимальный канал. У нас был проект — руководитель подготовил план, согласовал со всеми участниками от нас и отправил заказчику. Чтобы не получалось, что заказчик не в курсе, что происходит. Каждую неделю отчёты. По этому плану он и отчитывался. Вроде нормально всё. Думал, что всё хорошо. Поехали на совещание через три недели. Приходим и говорим: мол, как вам нравится всё? И тут они берут и достают свой план. У них, оказывается, есть совершенно другие пожелания по тому, в каком порядке и что делать. Наш они даже не смотрели. Писать про это не хотели, потому что вроде работы идут, всё хорошо. Но непонятно. А когда непонятно, местами неудобно говорить «я не понял». Или просто лень. Или просто всё окей, ну и не надо трогать. И только в устной коммуникации удалось понять, что мы по-разному всё видим. Пошли по их плану, пошло взаимодействие, появились проблемы, вопросы, обсуждения и решения. Мы каждую неделю понимали, что делаем то, что надо, и заказчик в этом участвует.
Это тоже очень важно.
Задача ПМ — обмен информацией, чтобы инженеры знали, что они делают и кому о чём сообщать; заказчик знал, что происходит, когда ожидать результатов и какими будут результаты; архитектор знал про ограничения, в рамках чего проектировать и с кем общаться. У всех много вопросов. Один из методов — статусные совещания. Рассказать, что за неделю сделано и что планируется в ближайшее время. В принципе, его можно и не делать — можно докладывать не еженедельно, а когда будут результаты, в зависимости от интенсивности и объема работ по проекту, или можно отзваниваться. Зависит от того, какое решение примет ПМ — или каждому письмо, или всем один раз, или обзвонить, или звонок на толпу. Привычная практика у нас — статусное совещание. Потому что к нему надо ещё и готовиться, что, к тому же, позволяет человеку самому собраться, найти всю нужную информацию, поделиться с командой, а не пускать что-то на самотёк.
Ну и, конечно, устно куда проще и быстрее сформулировать что-то, потому что не все люди могут письменно выразить свою мысль абсолютно свободно. Статусное совещание — это всего один час в неделю на один проект. Минимум времени, никакой испорченной информации из третьих рук, междусобойчиков, слухов, интерпретаций, догадок и повторного обсуждения ранее принятых, но не обнародованных должным образом решений. Руководитель проектов доносит и фиксирует информацию, а участники только слушают, понимают и задают уточняющие вопросы.
Если так не делать, нас ждёт системная переделка. Продавец хочет знать, куда двигается команда. Заказчик выдаёт замечания разным людям — если ему не рассказывать. Кого поймает, тому и выскажет. Когда к инженерам приходит замечание от разных людей с разных сторон, они недовольны, и конфликты начнутся сразу, когда не станет общего видения.
Когда работать над проектом-то?
Вот план по одному из проектов:
Как видите, эта схема обеспечивает синхронизацию информации у всех на проекте. Но при этом она очень требовательна к ресурсам ключевых людей. В понедельник день оказывается разбит одним совещанием (и к нему надо готовиться), во вторник — тоже.
С этими издержками надо мириться. Для того чтобы минимизировать их влияние на проект, каждый раз нужно выбирать минимально возможное число участников. Например, архитектор не таскает за собой инженеров, тимлиды доносят информацию до команд сами, и так далее.
Второй вопрос — не провоцирует ли такой частый обмен информацией с заказчиком изменения в ТЗ? Провоцирует. Если ТЗ было плохо сформулировано, то будет меняться чаще. И это хорошо, потому что цель — сделать то, что надо, а не что заказали и сформулировали. Чем раньше обнаруживается необходимость изменения, тем дешевле и быстрее оно реализуется. Крайне редкий случай на проектах, когда ТЗ сразу хорошее и нужно просто сделать чьими-то руками. Тогда будет минимум изменений, тогда и пойдёт стиль руководства через письма, описанный выше, но только если команда замотивирована на результат, а это большая редкость в наших реалиях, когда мы не запускаем фалконы. И крайне редко заказчик хочет сделать по ТЗ, а не как надо, — это, скорее, область юридически сложных проектов. Обычно же задача — сделать так, чтобы проект подходил. Но про это хорошо написал мой коллега в посте про то, что делает руководитель проектов.
Автор: Олег Закурин
