Как управлять командой проекта

Способы и инструменты, проверенные на практике.

Руководитель до сих пор воспринимается как источник критики и контроля — потому что долгие годы рулила доминирующая система управления. Спустили сверху задачу — распишись, что принял, и исполняй. Я сам, когда начинал работать 16 лет назад, видел, что моё мнение никого не интересует, главное — вовремя сделать, что сказано.

Но за прошедшее время мир изменился. Сегодня продуктивно работать по «технологии кнута и пряника» не получится. Особенно это касается сферы интеллектуального бизнеса. Интеллектуальное творчество не терпит давления и жёсткого контроля.

За 15+ лет у меня накопилось много наработок и инсайтов в командной работе и управлении проектами. Мы включаем в команду исполнителей заказчика, вместе погружаемся в тему, находим и устраняем лишние звенья процессов, «примеряем ботинки пользователя», работаем над точностью постановки задач. Про эти и другие проверенные способы повысить результат командной работы я и расскажу сейчас.

Меня зовут Евгений Ящук. Я работаю директором направления проектного управления Центра компетенций 1С в холдинге Т1 и отвечаю за реализацию проектов на этом технологическом стеке. Мы внедряем у заказчиков решения 1С и Битрикс24, закрывая все потребности в автоматизации бизнес-процессов.

Как мы ускорили процесс разработки благодаря рацпредложению

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

В результате из цепочки взаимодействия исчезло лишнее звено, а мы стали быстрее реализовывать проекты.

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

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

Как только аналитика стали приглашать, он начал видеть результат своего труда и оперативно поддерживать статус задач в актуальном и понятном состоянии без напоминаний.

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

Одна из самых сложных задач руководителя проекта — построение команды.

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

В зависимости от требований проекта в команде может быть и 100, и десять человек. Это функциональные и технические архитекторы, бизнес- и системные аналитики, разработчики, тестировщики, аккаунт-менеджеры.

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

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

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

На других уровнях также поддерживается диалог. И когда люди готовы совместно искать решения, достигаются крутые результаты.

Почему важно, чтобы была единая команда проекта, а не команда заказчика и исполнителя? От этого зависят скорость и качество работы.

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

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

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

Созданию сплочённой команды, способной в заданные сроки показывать классные результаты, способствует внедрение определённых практик.

Поговорим о них предметнее.

Часто бывает так, что разработчик пилит какую-нибудь фичу, а у него нет представления, кому и зачем она нужна. Соответственно, нет и возможности «примерить ботинки пользователя», чтобы понять, насколько хорошо она выполнена, а что можно улучшить.

Часто у сотрудника нет представления о том, чего именно от него ждут и кто может помочь, если что-то не получается.

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

По результатам этой встречи у каждого специалиста должен быть ответ на три ключевых вопроса:

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

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

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

Дополнительно рисуем матрицу распределения полномочий, где указано, какой сотрудник отвечает за результат, какой сотрудник назначен исполнителем, кто участвует в согласовании результата и так далее.

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

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

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

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

В целом такая актуализация задач и планов мощно способствует достижению ожидаемого результата по проекту.

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

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

Однажды я поделился с командой информацией о том, что проект принят, акт подписан. Сотрудники были благодарны: «Спасибо, что сообщил, что проект закончен».

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

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

Все эти примеры подсвечивают, насколько важно честно, открыто и оперативно доносить до сотрудников актуальную информацию, отвечая на вопросы: что с проектом, куда движемся, какие перспективы, что идёт так, что не очень. Не оставлять места домыслам и слухам.

Как руководитель я решаю массу задач. Todo-лист включает такие пункты:

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

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

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

Иногда по сотруднику видно, что есть проблемы, он напряжён, но молчит.

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

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

У меня нет такого понятия, как часы приёма по личным или рабочим вопросам. Любой сотрудник в любое рабочее время может прийти, обратиться, поговорить, если вот прям срочно надо. Но обычно личные встречи планируются: люди пишут, звонят, ловят лично, чтобы назначить на удобное время. Естественно, я сначала спрошу о решении вопроса на уровне руководителя проекта. И если там по каким-то причинам вопрос не решается, каждый сотрудник знает, что всегда есть возможность обратиться напрямую к руководителю направления. И тут он всегда найдёт желание помочь: выслушать, поддержать, направить.

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

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

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

Формальный контроль позволяет отследить количественные показатели.

Качественные характеристики — привилегия нестандартных подходов к оценке эффективности команды и достижений на проекте.

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