Неочевидные острые углы проекта: как распознать и обойти

Хоть ChatGPT и не руководил ни одним проектом, он прекрасно знает возможные проблемы и сложности внутри проектного жизненного цикла. В коротком ответе на соответствующий вопрос он сразу же выдал и нехватку ресурсов, и плохое планирование, и недостаточную коммуникацию, и ряд других очевидных пунктов. «Важно отслеживать прогресс проекта, решать проблемы и искать способы улучшить процессы», – бодро рапортует ИИ. Однако на практике распознать и вовремя обойти острые углы оказывается не так просто. Есть такие проблемы, которые на первый взгляд кажутся незначительными, а в итоге могут впустую сжечь бюджет и ресурс команды. Поговорим об этом подробнее.

Коммуникация

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

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

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

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

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

Ресурсы

Говоря о ресурсах, хочу, в первую очередь, поговорить про ресурсы людей-специалистов (бюджет и инфраструктура – тоже ресурсы, но я хочу остановиться именно на людях). Нехваткой нужных кадров обычно объясняется большой спектр проблем: сорванные сроки, качество продукта, количество ошибок. Когда я спрашиваю, где источник проблемы на проекте, то мне часто отвечают – «у нас не хватает ресурсов». Однако, когда я присматриваюсь чуть пристальнее, то обнаруживаю, что ресурсы у проекта есть, просто их неэффективно используют.

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

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

Планирование

Есть известный мем «с самого начала у нас была какая-то тактика и мы её придерживались». Этот мем отлично отражается ситуацию с планированием. Почему-то именно планирование – самый откладываемый вопрос на многих проектах.

Пару лет назад я наблюдала ситуацию, когда планировочная сессия сдвигалась семь или восемь раз, пока руководитель направления не удалил ее вовсе. «Ну все же знают, что им делать», сказали нам. Здесь можно было ответить, перефразируя другой известный мем: «на самом деле, что делать, никто, конечно, не знал». В самом экстремальном варианте отказ от планирования так и выглядит – «прихожу на работу и не знаю, что должен делать».

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

Небольшой итог

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