Управление проектом: Важность словесной коммуникации

Эта статья о важности в большом проекте коммуникация посредством живого общения. Ее написать меня подтолкнул мой знакомый, с компанией которого я сейчас иногда сотрудничаю на кризисных или рисковых проектах. Полгода назад он обратился ко мне за помощью вытянуть один из его проектов, я сказал, что естественно не против, но помощи советами возможно будет мало, скорее всего нужно действовать и быстро, поговори с руководством. Через пару дня руководитель компании связался со мной и после почти часового диалога дал добро на мое участие. Основной болью проекта было то, что предыдущий ПМ требовал писать подробные письма и делать регулярные обновления статус-отчетов. Проект грозился провалить все сроки и риски. Моей задачей было, как минимум снизить нерентабельность. В свое время я тоже с таким столкнулся, когда был тимлидом, поэтому ситуацию знал изнутри. Первое что было сделано – собрано скайп-совещание с руководителями всех причастных к проекту команд и объявление о новом подходе к работе по моей любимой методологии Scrumban. Проект оказался спасен. Удалось выдержать сроки установленные во второй рисковой группе (их было три). Я получил предложение об удаленном сотрудничестве на подобных проектах.

[sendpulse-form id=”278″]

Немного истории

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

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

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

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

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

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

На вопросы почему он так делает. Он отвечал: «Хочу, чтобы в почте оставались следы. К моменту разборок, когда проект будет сорван, чтобы каждый знал, как так вышло. А у меня всё понятно, в какой момент какие исполнители какие обязательства нарушили.” Нужно было что-то делать причем быстро.

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

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

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

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

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

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

Еще немного истории

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

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

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

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

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

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

Еще одна история.

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

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

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

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

Вместо заключения

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

В следующей статье я рассмотрю о роли ПМ и что он делает на проекте.