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



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

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

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

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

    Задержки продолжили копиться.

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

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

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

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


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

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

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

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


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

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

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

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

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



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

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

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

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


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


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

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

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

    Комментарии 11

      0
      Просто оставлю это здесь:
      Сommunication planning and all aspects of communication with all interested parties

      Communication plan: Showing how all aspects of communication will be handled and managed with all relevant areas and parties involved ...


        +1
        Да даже для недлинных проектов. Личный опыт говорит, что каким бы маниакально- подробным ни было письмо, на том конце обязательно что-то недопоймут, поймут неправильно или попросту не заметят. Обязательно нужно проговаривать еще и голосом, хотя бы по телефону. Живой разговор всегда вскрывает гору мелких недопониманий и отличий в трактовках.
          0
          Зависит от типа восприятия у человека. Кому-то (например, мне) как раз в письме понятнее. В живом разговоре (на техническое темы) обязательно что-то недопоймут, поймут неправильно или попросту не заметят. А то, что поймут, забудут, выйдя за дверь. Четко сформулированное письменное описание всегда вскрывает гору мелких недопониманий и отличий в трактовках.
            0
            Это вам так кажется, что понятнее. Миллион случаев из личной практики, когда люди думали, что им всё понятно. А потом пообщавшись, чесали репу.
            0
            Его все равно потом придется фиксировать письмом, тк через неделю никто уже не вспомнит, что и что обещал
              0
              Вот и наглядный пример письменного недопонимания — у меня было написано "ещё и голосом".
            0
            Самый тупой карандаш, заменяет самую острую память.
              +2
              У меня по опыту сложилось впечатление, что такие проблемы в коммуникациях возникают в конторах с совковым/военным/сильно иерархическом стилем управления (называйте как хотите). Условно когда у тебя есть насяльник и он определяет хороший ты или плохой и какой у тебя бонус и ничего больше в компании на это не влияет.
              Это правится само собой когда в оценку перформанса сотрудника добавляют фидбеки от кого угодно и на уровне культуры компании считается нормально писать фидбеки на любых людей, с которыми ты контактировал по любой задаче, даже если это было полдня. Ну и этот фидбек должен быть реально весомым фактором в результате перформанс ревью.

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

              Возможно еще на это влияет менталитет — работая в разных компаниях с интернациональным составом мне стало казаться что среди свежих людей из СНГ, Китая, Индии процент таких, которые ставят своего лида в копию в каждом письме направленном за пределы своей команды гораздо больше, чем среди людей из чисто западных стран. Со временем почти все такие люди меняются и приходят больше к использованию своего лида как сервиса, нежели как начальника/главного.
                0

                «Совещания совершенно незаменимы, если вы ничего не хотите делать» [Гэлбрейт]
                По-моему опыту 70% совещаний проходят согласно этой цитате. Зато остальные 30% бывают продуктивны. Но именно из-за этих 70% я от них как правило уклоняюсь. Потому как бесполезные совещания в отличии от полезных длятся как правило мучительно долго и 30% в штуках превращается в 5% в часах. (Это по опыту работы в госкомпаниях.)


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

                  0
                  Отличный материал! Всегда приятно почитать истории из практического опыта коллег.

                  Очередное доказательство того, что главное в работе проектного менеджера — это коммуникации.
                    0

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

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое