В проектном управлении часто ищут проблемы в технологиях, методологиях или архитектуре. Однако большинство трудностей возникает из-за банального сбоя в коммуникации. Участники проекта обычно по-разному понимают задачи, приоритеты и статус работ, а также имеют разные ожидания.
Проектное управление — это всегда столкновение двух разных миров. С одной стороны находится менеджмент. Это мир бизнеса, где важны сроки, бюджеты, обязательства перед клиентами и коммерческая выгода. С другой стороны находится команда разработки. Это мир технической реальности со своими ограничениями, техническим долгом, рисками и строгой логикой. Конфликт между этими мирами чаще всего носит скрытый характер. Снаружи все может выглядеть цивилизованно: созвоны проходят, карточки в таск-трекере двигаются, статусы обновляются. Но стоит заглянуть глубже, и выясняется, что команда и менеджер говорят на абсолютно разных языках, а стиль управления скорее раздражает команду, чем мотивирует.
К симптомам плохой коммуникации можно отнести следующие:
- постоянные уточнения;
- потерянные решения;
- повторяющиеся вопросы;
- сюрпризы на демо или при тестировании;
- внезапные переносы сроков.
Чтобы проект двигался четко, руководитель проектов должен стать эффективным переводчиком между бизнесом и техническими специалистами. Его главная цель — снижать уровень хаоса и создавать условия, при которых команда может спокойно проектировать плату или писать код, а бизнес — вовремя получать предсказуемый результат. Для этого необходимо детально разобрать три главных источника раздражения в команде и выстроить вокруг них понятные, прозрачные процессы.
1. Задачи-загадки
Такие задачи обычно выглядят так: «надо сделать красиво», «почини форму регистрации», «поправь схемотехнику» или «сделай, как обсуждали». Иногда вместо описания задачи разработчику присылают скриншот из переписки с заказчиком без каких-либо дополнительных пояснений.
Менеджер в этот момент может искренне считать, что он выполнил свою работу. Он зафиксировал потребность бизнеса или клиента и передал ее исполнителю. Но для разработчика такая формулировка несет мало полезной информации. Вместо того чтобы заниматься своей прямой обязанностью — проектированием платы или написанием кода, — специалист вынужден играть в детектива. Он начинает собирать улики, искать контекст, поднимать историю переписок и пытаться угадать, что именно имелось в виду. Чем меньше конкретики, тем больше интерпретаций. А чем больше разработчик додумывает сам, тем выше вероятность совершить ошибку, которая обнаружится слишком поздно.
Любопытно, что если разработчик не угадает истинные намерения руководителя или заказчика, то переделывать работу все равно придется ему. При этом время уже будет упущено, а виноватым в глазах бизнеса останется именно «тот, кто плохо сделал».
Как грамотно описать задачу
Качественное описание задачи — это не бюрократия, а базовая защита проекта от ошибок. Хорошо структурированная задача должна давать четкие ответы на три ключевых вопроса еще до того, как она попадет в спринт:
- Что нужно сделать? Конкретное техническое или функциональное требование к системе.
- Зачем это нужно сделать? Бизнес-контекст. Какую проблему пользователя или компании мы решаем этим изменением? Когда разработчики понимают глобальную цель, они часто могут предложить техническое решение, которое окажется гораздо эффективнее, проще или дешевле первоначальной задумки менеджера.
- Как мы поймем, что задача выполнена правильно? Критерии готовности. Это четкий чек-лист, по которому и разработчик, и тестировщик, и руководитель смогут однозначно сказать: задача готова и соответствует ожиданиям.
Если хотя бы на один из этих вопросов ответа нет, значит, задача еще не готова к работе. Если разработчик, тестировщик или новый человек в команде вынужден спрашивать: «А в чем вообще суть этой задачи?», значит, проблема не в человеке, а в качестве описания. В идеальном процессе вопросы разработчика должны лежать исключительно в плоскости реализации: «Как лучше технически решить эту задачу?» или «Какой вариант решения предпочтительнее?».
Большую часть проблем снимает детальная декомпозиция задач на старте проекта. Разбивая одну большую задачу на более мелкие, важно учитывать указанные выше требования: чтобы было ясно, что делать, зачем и как мы поймем, что работа выполнена правильно. А оценка задачи (в каком бы формате она ни измерялась — в часах, сторипоинтах или в чем-то еще) не должна превышать каких-то разумных пределов. Например, если мы оцениваем задачи в часах, то лучше выделять на выполнение каждой по
Кто должен заниматься разбивкой, описанием и, самое главное, оценкой задач?
Руководитель проекта не должен делать это в одиночку, ведь его основная цель — это довести проект до логичного финала, уложившись в бюджет и сроки. Здесь должен подключиться техлид (или старший разработчик). Его техническая экспертиза поможет грамотно и четко разбить крупные бизнес-требования на мелкие, логически завершенные и понятные задачи и описать их техническую часть. Затем они ВМЕСТЕ с командой разработки должны проговорить каждую задачу, проверить единое понимание ее сути, оценить доступные ресурсы и спланировать загрузку.
Что нужно делать, чтобы задача перестала быть загадкой:
- Дать задаче контекст, декомпозировать.
- Описать, что именно должно измениться.
- Сразу определить, как будет приниматься результат.
- Подключить техлида до старта, а не после пожара.
Да, этот этап требует времени в начале. Может показаться, что декомпозиция тормозит проект и проще «сразу начать делать». Но десять минут качественного обсуждения на старте гарантированно спасают от двух дней дорогостоящих переделок и взаимных обвинений через неделю.
В реальности так бывает не всегда. Например, в команде может отсутствовать техлид, и тогда руководителю проектов придется брать эту обязанность на себя. И даже если все сделано правильно, это не гарантирует, что в будущем не потребуются правки. Но вместо больших переделок команда получает шанс ограничиться точечными изменениями и видеть проблемы заранее.
Впрочем, даже понятные задачи не спасут, если непонятно, кто и когда ими должен заниматься.
2. Хаотичная загрузка
Второй мощный фактор, дестабилизирующий команду — это хаотичная загрузка и отсутствие внятной приоритизации. Типичная картина: в понедельник разработчик приступает к важной и сложной задаче. Во вторник менеджер прибегает с горящими глазами и просит срочно бросить все дела и переключиться на другую задачу, потому что пришел важный запрос от клиента. В среду приоритеты снова меняются, а в четверг руководитель проекта искренне удивляется, почему не готова первая задача, которую начали делать в понедельник. В довершение всего в течение дня на разработчика регулярно сыплются маленькие тасочки на десять минут, которые менеджер считает незначительными.
Команду бесит не сам факт изменения приоритетов. В живом бизнесе требования и внешние обстоятельства меняются постоянно, и разработчики это прекрасно понимают. Бесит то, что они не видят логики в этих изменениях. Когда срочным и критически важным становится абсолютно все, то само понятие «приоритет» теряет смысл. Планирование подменяется импульсивным реагированием на любые внешние раздражители, и проект полностью выпадает из реальности. Возникает опасная иллюзия деятельности: все постоянно заняты, все работают на пределе возможностей, в таск-трекере непрерывно двигаются десятки карточек, но при этом реальный продукт не приближается к релизу ни на шаг.
Как планировать загрузку правильно
Руководителю проекта, разработчику, тестировщику и заказчику важно понимать две вещи: когда мы получим полностью готовый продукт и когда можно будет посмотреть промежуточный результат.
Для заказчика прогресс — это не когда движутся задачи в таск-трекере, а когда он видит демо, отчеты, промежуточные релизы или хотя бы честный статус. И это возвращает нас к первому пункту — к декомпозиции задач. Без нее планирование превращается в гадание. Именно на основе декомпозиции можно построить план, который будет не идеальным, но хотя бы близким к реальности.
Для грамотного планирования загрузки недостаточно просто распределить задачи между людьми. Нужно попытаться ответить на четыре базовых вопроса:
- Кто и чем занят?
- Когда человек освободится?
- Где у нас узкое место?
- Кого мы перегружаем?
Чтобы решить эти вопросы, необходимо сделать загрузку команды абсолютно видимой и прозрачной для всех участников процесса — от разработчика до заказчика. Инструмент реализации здесь вторичен. Это может быть Jira, YouTrack, простая доска в Trello или даже структурированная таблица. Главное — чтобы инструмент был единым источником правды.
Итак, загрузка должна быть видимой для всех, но прозрачность эта нужна не для контроля, а для принятия решений. Команда должна понимать свою загрузку, заказчик должен понимать, когда он увидит результат, а руководитель проекта и техлид должны заранее видеть потенциальные риски, чтобы оперативно на них отреагировать.
Но здесь важно, чтобы договоренности жили не только в головах и чатах. Поэтому далее поговорим об отчетности, коммуникации и документации.
3. Отчетность ради отчетности
Третья вещь, способная быстро накалить обстановку в коллективе — это отчетность ради отчетности.
Разработчиков невероятно раздражает микроменеджмент. Это проявляется в ситуациях, когда от них требуют ежедневно писать детальные письменные отчеты о каждом часе работы, затем повторять то же самое голосом на утреннем дейли-созвоне, отвечать на контрольные вопросы в общем чате в течение дня, а под конец заполнять громоздкие формы в корпоративных системах. Особенно если эта информация никак не используется для решения реальных проблем команды. Такая отчетность выглядит не как управление рисками, а как имитация контроля.
Команда начинает воспринимать менеджмент не как поддержку и защиту, а как помеху, которая мешает выполнять прямые обязанности. Кроме того, избыточный контроль разрушает доверие. Разработчик чувствует, что ему не доверяют как профессионалу, подозревают в безделье и пытаются контролировать каждый его шаг. В такой атмосфере пропадает всякое желание проявлять инициативу.
Близкая проблема, о которой стоит также упомянуть в этом пункте — это избыточная, неэффективная коммуникация. Как ни странно, но при увеличении числа созвонов и чатов реальная управляемость проектом падает. Когда каналов коммуникации становится слишком много, важная информация начинает теряться.
Например команда детально обсудила сложную техническую проблему в мессенджере. Все со всем согласились, приняли решение изменить логику работы устройства и разошлись. Через неделю начинается тестирование, код работает не так, как предполагалось изначально. Менеджер начинает искать виноватых, а разработчик утверждает, что все было сделано, как договаривались. Так что мессенджер удобен для быстрого обмена мнениями, но абсолютно непригоден как источник истины. Попробуйте через две недели найти конкретное сообщение в бесконечном потоке флуда. В итоге устные договоренности забываются, решения стираются из памяти, а проект превращается в набор разрозненных представлений о том, как все должно работать.
Как выстроить коммуникацию и отчетность
Коммуникация, ведение документации и отчетность в проекте необходимы. Особенно это актуально для распределенных команд, где люди могут работать из разных городов, стран, часовых поясов. Но эти инструменты должны служить одной понятной цели: делать так, чтобы важная информация не терялась, риски всплывали как можно раньше, а люди не тратили время на поиски ответов.
Чтобы настроить этот баланс, придерживайтесь следующих правил:
- Информация должна лежать там, где ее ожидают увидеть. Это главный закон эффективного менеджмента. Если решение по задаче принято в ходе устного обсуждения или в чате, руководитель обязан немедленно перенести итог этого обсуждения в саму задачу в таск-трекере или на актуальную страницу технической документации. Должен остаться четкий цифровой след: «Такого-то числа на созвоне приняли решение делать по варианту Б, потому что вариант А увеличивает сроки на неделю». Все. Источник истины зафиксирован.
- Нормальный статус — это не школьное сочинение. Разработчик не должен тратить тридцать минут на описание своего дня. Обучите команду давать короткие, емкие и структурированные апдейты. Идеальный ежедневный статус состоит из трех пунктов: что сделано вчера, что планируется сделать сегодня и есть ли какие-то блокеры (проблемы, которые мешают двигаться дальше).
- Статус нужен для выявления блокеров, а не для допроса. Менеджер должен приходить за статусом не с позицией завуча, который хочет поймать прогульщика. Люди не должны бояться говорить о проблемах и рисках заранее. Они должны быть уверены, что руководитель не отругает, а поможет: «Мне нужен твой апдейт, чтобы понять, не нужна ли тебе помощь, не зависла ли задача и не нужно ли мне пойти к соседней команде или к заказчику, чтобы выбить для тебя нужные доступы или ответы». Когда команда видит, что после обозначения проблемы в статусе менеджер идет и реально решает эту проблему, отношение к отчетности меняется. Она перестает восприниматься как микроменеджмент и становится рабочим инструментом управления рисками.
Подытожим
Четкое управление проектом — это не про бюрократию, отчеты ради отчетов и контроль ради контроля. Это про понятные задачи, прозрачную загрузку, честную коммуникацию и доверие внутри команды.
Разработчиков бесит не сам руководитель проекта, а хаос, который часто приходит к ним через руководителя. Так что его задача — снижать этот хаос: прояснять ожидания, фиксировать договоренности, подсвечивать риски и защищать команду от лишнего шума.
Но важно помнить: Москва не сразу строилась. Процессы нельзя внедрять наскоком, иначе вместо порядка команда получит шок и сопротивление. Изменения нужно вводить постепенно: сначала закрывать самую больную проблему, потом следующую, потом закреплять то, что уже работает. Иногда что-то улучшить не удается. Но хороший процесс — это тот, после которого разработчикам меньше мешают работать, команда меньше тушит пожары, а проект становится понятнее для всех.
Источник: Егор Гуторов, директор компании «Кедр Солюшенс»
