В нашей компании в любой момент времени проводится от 20 до 25 корпоративных проектов. Около 10% из них идут с отклонениями от сроков и плановых трудозатрат. Мы всегда доводим проекты до конца, чего бы это ни стоило. Однако этот проект стоил нам слишком многого, поэтому я решил рассказать о нем – думаю, это будет полезно.
Я в профессии 22 года : прошел путь от сервисного инженера до руководителя проектов и директора крупной 1С-франчайзи. Курирую многочисленные проекты, в том числе получившие награду «1С:Проект года». Автор статей по управлению бизнесом в сфере 1С, методики управления проектами и продажами в IT-компаниях с помощью системы Atlassian. Также я автор и исполнитель песен в стиле поп-рок и провел пять собственных концертов.
Проблемы формирования команды на старте проекта
Чаще всего, когда мы заходим в большой корпоративный проект, заказчики ожидают, что мы сразу, буквально вчера, выведем сильную команду. Мы стараемся объяснить, что нужно время, чтобы сформировать ядро команды. Иногда удается убедить, но чаще – нет. Заказчики исходят из представления, что существует некая «скамейка запасных», где сидят свободные сеньоры, готовые немедленно выйти на проект. Мы объясняем, что на формирование костяка команды требуется около месяца. Если этого времени не дают, то риски закладываются уже на старте, как и произошло в этом проекте.
Общая численность команды, о которой идет речь, достигала 75 человек в пике. Костяк составляли функциональные и технические архитекторы – восемь человек, распределенных по блокам. Каждый отвечал за глобальную проектировку и координацию команд внутри своих блоков.
Мы рассчитали по статистике, что если на старте проекта ядро команды не укомплектовано, это добавляет 50% к общему сроку проекта, деленное на количество недостающих ключевых участников. В нашем случае вместо восьми архитекторов было шесть, и уже это означало сдвиг сроков примерно на три месяца вправо.
Второй фактор – нехватка специфических компетенций у части ключевых участников. Это не значит, что они некомпетентны, просто не обладали нужными знаниями по специфике заказчика. Такой дефицит добавляет 120% к общему сроку проекта, деленное на количество участников с недостатком компетенций.
Сочетание этих двух факторов уже на старте давало плюс 6,6 месяца к сроку проекта, рассчитанному на 24 месяца. Все проблемы начинаются в начале, а дальше мы только пытаемся исправлять то, что заложили изначально.
Эти выводы мы впоследствии учли и встроили в процессы, чтобы на следующих проектах правильно формировать команды.
Важность постоянства команды и контекста проекта
Вы можете сказать, что мы добавим ключевых участников со временем. Но костяк команды должен быть на проекте с первого дня и до самого конца в постоянном режиме. У каждого проекта есть свой контекст, часто неформализованный, и его нельзя терять. Когда заказчик на первых встречах формулирует цели и ожидания, именно в них заключено главное, ради чего он вообще запускает проект.
В этом случае целей было две страницы мелким шрифтом, но ключевых – всего две-три. О них нельзя было забывать ни на одном этапе, все должно делаться ради их достижения. Постоянство команды – важный залог успеха крупных проектов.
Особенности старта проекта в условиях внешней нестабильности
Конечно, кто платит, тот и прав. «Начинайте сейчас, иначе в проект зайдет ваш конкурент».
Особенность этого проекта в том, что он стартовал в момент начала СВО. Шли переговоры, и я видел в нем много рисков, но это событие ускорило решение. Мы не понимали, что будет с рынком, поэтому пошли на риск и зашли в проект. Возможно, делать этого не стоило, но тогда ситуация сложилась именно так.
Мы пытались объяснить клиенту, что первый месяц можно использовать с пользой – пока формируется команда, есть масса подготовительных задач. Тем не менее, мы начали сразу и приступили к работе.
Ротация участников команды и ее последствия
Ротация участников команды – вторая проблема. По нашей статистике, на 40% проектов примерно треть участников меняется в процессе работы. Проекты длятся по два–два с половиной года, люди выгорают, устают, иногда просто не складываются рабочие отношения. Бывает, заказчик говорит: «У нас с вашим архитектором не получилось химии». Мы стараемся, чтобы все было как лучше, но такие ситуации случаются. Примерно на четверти проектов за время работы меняется около 15% команды.
Данная статистика – это наши наблюдения и опыт, не догма, но тенденция устойчивая.
Меры по снижению влияния ротации
Что мы делаем, чтобы минимизировать последствия ротации?
Мы проводим оценку 360 команды проекта через три месяца после старта и за три месяца до планового завершения. По результатам делаем выводы, в каком состоянии находятся участники команды, насколько они довольны собой, коллегами, заказчиком и характером задач. Это позволяет нам реагировать на проблемы превентивно.
Отчет показывает состояние каждого сотрудника. Если видим, что у кого-то начинается выгорание, можем вовремя заменить.
Также HR раз в четыре месяца проводят индивидуальные интервью с сотрудниками.
Есть анкета из 20 вопросов, чтобы оценить, как человек ощущает себя на проекте.
Мы договариваемся с ключевыми участниками. Люди иногда увольняются – это нормально. Мы неформально обсуждаем, что проект сложный и важный, в том числе с точки зрения репутации компании, и хотим, чтобы человек дошел до конца. При этом договариваемся: если он решит уйти, нужно сообщить об этом заранее, чтобы успеть ввести нового специалиста. Обычно это работает – люди не хотят подводить команду.
Дополнительно используем отложенные проектные премии, концентрируем компетенции, развиваем наставничество. Все встречи с заказчиком записываются: если приходит новый участник, он может за один-два дня просмотреть материалы и быстро вникнуть в проект.
Мы также уведомляем клиента, что ротации возможны. Клиенты часто считают, что команда будет постоянной, но мы не всегда можем это гарантировать. Делать все возможное, чтобы сохранить стабильность, – наша задача, и мы это делаем.
Проблема выгорания на длительных проектах
На больших проектах сотрудники выгорают. Такие проекты длятся по два–два с половиной года – слишком долго до первых ощутимых результатов. Любому профессионалу нужны маленькие победы как можно чаще. Никто не может полгода ждать достижения цели и при этом сохранять мотивацию.
Проект должен быть разбит на мини-проекты с отдельными результатами. Любое большое и сложное можно разделить на множество маленьких и простых задач и назначить их целями хотя бы для ключевых сотрудников.
На больших проектах часто нет удобного момента для отпуска. Мы рекомендуем планировать отпуска заранее и сообщать о графике заказчику. Важно синхронизировать эти планы и донести до команды, что, например, Вася в июле уезжает на две недели – и это решение не меняется. Какой бы ни случился пожар, Вася все равно должен пойти в отпуск. Не отменять, не переносить и не заменять отпуск компенсацией – принцип, которого мы придерживаемся, хотя признаем, что с этим у нас бывают сложности. Я как руководитель понимаю эту проблему и стараюсь постепенно ее решать.
Причины выгорания и меры по их устранению
Причины выгорания на проектах – регулярные переработки. Я рекомендую не допускать переработок свыше 20% рабочего времени в среднем и оплачивать их с повышающим коэффициентом. Переработки негативно влияют на личную жизнь, и об этом нельзя забывать. Сотрудников нельзя воспринимать как ресурс – это люди со своими ожиданиями и желаниями. Если учитывать это, результат будет лучше, а удовлетворенность выше.
Сотрудники устают выполнять одни и те же задачи, работать с одним клиентом, с одной спецификой и командой.
Еще одна причина выгорания – ощущение недооцененности. Нам может казаться, что все в порядке: человек работает полтора года, значит, его все устраивает. На самом деле нужно индексировать зарплаты, повышать грейды и роли, показывать, что мы ценим вклад специалиста. В этом залог успеха.
Проблемы с «звездными» сотрудниками
В наших командах всегда есть топовые специалисты – «звезды». Это люди с высокой квалификацией, большим опытом и широкой картой компетенций. Они умны, амбициозны, хорошо говорят, генерируют инициативы, нередко ведут собственные проекты в своей сфере. Многие из них действительно освещают путь команде, но некоторые лишь «слепят глаза».
Такие специалисты бывают слабоуправляемыми, не всегда командными игроками, не доводят дела до конца, ведут себя вызывающе или токсично. Иногда открыто недооценивают возможности коллег, что снижает мотивацию внутри команды. Не все «звезды» такие, но с такими случаями мы сталкиваемся, в том числе и на этом проекте.
Если у топового специалиста возникают проблемы с софт-скиллами, примерно четверть команды может уйти – на другой проект, в другой отдел или вовсе из компании. Когда «звезда» ведет себя токсично, окружающим дискомфортно, и мириться с этим готовы немногие. Это серьезный риск, с которым нужно работать.
Рекомендации по работе с «звездами»
-
Не соглашайтесь на лидеров с неподтвержденными soft-skills.
-
Тщательно оценивайте soft-skills «звезд» при найме. У нас были проблемы с их оценкой, и я понял, что через внутреннюю HR-службу это сделать сложно. Поэтому мы решили использовать услуги внешних компаний для оценки soft-skills.
-
Будьте аккуратны в обещаниях, если не выполните – «не забудут, не простят». «Звезды» обладают хорошей памятью и запоминают каждое обещание. Если что-то обещаете – делайте,
-
Частая похвала = повышение чувства собственной значимости. Редкая = недовольство. Похвалу нужно давать взвешенно. Она не должна превращаться в постоянный фейерверк «ты молодец, ты лучший». Во-первых, это непонятно остальным участникам команды, во-вторых, формирует у сотрудника привычку получать похвалу вне зависимости от реальных результатов.
-
Выбирайте «звездам» роли, где они реализуют амбиции, иначе «остынут» от рутины. Им неинтересна рутина – им нужны сложные, значимые задачи, участие в ключевых аспектах разработки системы.
-
Если отследили, когда «звезда» стала неформальным лидером – не допускайте «революций». Разговаривайте.
-
Если сотрудник виноват – не избегайте критики, но аргументируйте и добивайтесь понимания. Критиковать нужно, но делайте это индивидуально – не на планерках или митапах проектной команды. Не допускайте публичной критики.
Риски взаимодействия с авторитетным заказчиком
Корпоративные клиенты часто авторитетны и влиятельны. Когда заказчик начинает управлять проектом за вас, это всегда риск. Обычно это происходит, когда что-то идет не по плану: заказчик через призму своих бизнес-целей говорит, что ситуация катастрофическая, и пугает последствиями. Проектная команда с руководителем проявляет излишнюю гибкость.
На этом проекте мы работали по технологии «водопад», но заказчик предложил добавить участников и запараллелить несколько этапов. Команда выросла, управляемость снизилась, скорость не увеличилась – мы начали буксовать, потому что нарушили собственную технологию. Этого нельзя допускать.
В компании должен быть руководитель корпоративных проектов, который понимает, где проходят красные линии – глобальные расхождения, которых нельзя допускать. Он должен обладать железным характером. Без таких руководителей нельзя заходить в крупные проекты.
Необходимо твердо отстаивать позиции на совещаниях и фиксировать решения в протоколах. У нас были ситуации, когда два представителя заказчика с одинаковым уровнем влияния давали противоположные приоритеты. В таких случаях мы возвращаемся к графику, действуем строго по плану, фиксируем это документально и затем выстраиваем взаимодействие с заказчиком заново.
Внутренние процессы управления проектами
В нашей компании мы стараемся не работать вслепую. Мы управляем производственной выручкой и обязательно прогнозируем, сколько времени и трудозатрат потребуется для завершения проекта. Для этого у нас разработана собственная методика оценки и проверки, о которой нужно рассказывать отдельно.
Многие компании, с которыми я общался, таких процессов не имеют и фактически работают вслепую. На корпоративных проектах это недопустимо. Иногда этапы длятся по полгода, и если через три месяца вы не понимаете, где находитесь – в середине пути или все еще в начале, – это отложенный риск, который рано или поздно проявится. Поэтому необходима четкая методика управления показателями прогресса.
Оценка удовлетворенности и управление по контрольным точкам
Мы оцениваем удовлетворенность проектных заказчиков. В сопровождении, где один клиент и одно контактное лицо, опросить, насколько он доволен, несложно. В проектной работе заказчиков больше – обычно около десяти ключевых контактных лиц, и мы ежемесячно собираем оценку удовлетворенности от каждого, чтобы видеть сбалансированность мнений и общий тренд, насколько заказчик доволен. Потому что чаще всего за этим трендом почти всегда стоят конкретные причины. Я верю, что заказчики адекватны, и если они чем-то недовольны, значит, нужно реагировать превентивно. Индекс удовлетворенности оказался очень практичным инструментом – он действительно помогает в проектной работе.
Кроме этого, мы отслеживаем индекс лояльности сотрудников - eNPS, стараемся понимать общие настроения в компании.
Управляем проектами по контрольным точкам: каждая из них отражает ключевые вехи того, как мы движемся по проекту. Если хотя бы одна точка сдвигается, это сигнал о серьезной проблеме, которую нужно решать.
Мы накапливаем опыт и создаем библиотеки знаний. Материалы действительно есть, но не все их используют, и мы стараемся развивать корпоративную культуру, чтобы этот опыт применялся на практике.
Мало придумать что-то хорошее – идея сама по себе ничего не стоит, пока не внедрена.
Краткий итог проекта и уроки
Проект по автоматизации производственного холдинга мы завершили. Сейчас дорабатываем отдельные элементы, исправляем архитектурные недостатки, заложенные в начале. Тогда у нас не было достаточно времени на полноценное обследование, и в проекте осталось много белых пятен.
Первая часть проекта – это, как я называю, конфетно-букетный период. У всех хорошее настроение, заказчик видит, что с ним работают умные и вовлеченные специалисты. Он еще не до конца понимает, что именно происходит, но получает документы, проектные решения, методологию – все выглядит уверенно, и ему это нравится.
Этот период заканчивается, когда система передается в опытную эксплуатацию. Тогда наступает момент истины: всплывают все архитектурные и методологические недочеты, белые пятна обследования и недоработки.
Проект автоматизации – это очень честная вещь. Нужно понимать, что этапы обследования и моделирования делаются прежде всего для нас – чтобы в дальнейшем можно было правильно декомпозировать проект и управлять им совместно с заказчиком. Тогда проблем будет меньше, хотя полностью их избежать невозможно.
Важно прорабатывать максимум вопросов на этапе обследования, не оставлять белых пятен и не позволять руководителям проектов торопиться закрывать этап только ради приемки заказчиком. Обязательно нужно проводить внутреннюю верификацию результатов.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.