Ольга, руководитель отдела управления проектами.
Я видела много проектов, где всё шло не по плану. И почти в каждом случае — виноваты все, но крайним хотят сделать исполнителя. Потому что он ближе. Потому что проще ткнуть пальцем в подрядчика, чем признать, что внутренняя команда не прислала данные в срок, забыла согласовать макет или не отвечала на письма две недели. Если вы ведёте проекты, особенно в автоматизации, ИТ или консалтинге — вы точно это узнаете.
И вот здесь возникает простой, но болезненный вопрос: как действовать, чтобы потом не отдуваться за чужие просрочки?
Факт — это ваш лучший друг
Самое главное в любой спорной ситуации — это документальные факты. Нет переписки, нет фиксации — считай, ничего не было. Устные договорённости, даже самые подробные, даже если заказчик кивал, а вы записывали голосовое на диктофон — ничего не значат. Факт — это когда у вас есть письмо, в котором вы:
— обозначили, что ждёте от заказчика действия к определённой дате;
— предупредили, что без этого шага работа остановится;
— напомнили о просрочке, если она наступила;
— зафиксировали отклонение в статус-отчёте.
Причём делать это нужно в спокойном, уважительном тоне. Без пассивной агрессии, без «мы вас предупреждали». Просто по факту. Хронология событий — это не драма, это аргумент.
Подробнее о наших курсах — на сайте
Переписка важнее звонков
Созвоны удобны, но опасны. Вы обсудили всё, вроде бы обо всём договорились, разошлись довольные — а потом заказчик забывает половину, а вторую половину интерпретирует по-своему. А доказательств у вас нет. Поэтому:
— Всё важное обсуждаем в почте или мессенджере.
— После звонков фиксируем краткое резюме: «Итоги сегодняшней встречи: вы берёте на себя... Мы, со своей стороны...»
— Если договорённость родилась «на лету», тут же её подтверждаем письменно. Иначе в какой-то момент вам скажут: «Мы этого не обсуждали».
И не стесняйтесь напоминать. Системно. Лучше выглядеть занудой, чем крайним.
Если вы ищете надёжную систему для автоматизации вашего бизнеса — обратите внимание на «Внедрение 1С:ERP» на базе 1С.
Подробнее на сайте.
Протоколы, статус-отчёты, письма: не для галочки
Есть компании, где всё это ведётся «для галочки». Статус-отчёты делаются, но их никто не читает. Протоколы пишутся, но не согласовываются. И тогда, конечно, толку от них мало.
А надо, чтобы каждый статус был рабочим инструментом. Простой, без бюрократии, но с фактами:
— что было запланировано на неделю;
— что сделано исполнителем;
— что не сделано, потому что отсутствует вход от заказчика (и тут обязательно пишем: «Ожидаем от клиента», с датой и ссылкой на письмо).
И эти отчёты нужно не просто слать, а просить подтверждения: «Коллеги, подтвердите, что информация корректна». Это неформальный способ дать понять: мы фиксируем, что происходит. И если кто-то из заказчиков знает, что отчёт идёт на архив — он трижды подумает, прежде чем игнорировать дедлайны.
Напоминать — это не докучать
Очень часто я слышу: «Ну мы же им уже сказали». Да, но если это было однажды и устно, через две недели все забудут. И когда проект встанет — вспомнят только, что это вы ничего не делаете.
Поэтому напоминания — это не назойливость, а часть вашей защиты. Как только приближается дедлайн, вежливо напоминаем. Как только наступил — фиксируем факт просрочки. И снова корректно сообщаем: «К сожалению, от вас не поступил материал, поэтому мы не можем перейти к следующему этапу». Всё. Без эмоций.
Главное — не ждать, что все вспомнят сами. У заказчика может быть десять параллельных проектов. Не будет лишним быть тем, кто держит сроки в фокусе.
Почему всё это нужно делать заранее
Самая частая ошибка — начинать фиксировать что-то только тогда, когда уже пахнет конфликтом. Когда письмо начинается словами «в связи с многочисленными нарушениями...» — это уже поздно. Потому что всё до этого момента не документировалось, и доказывать что-либо вы будете в десять раз дольше и с меньшим шансом на успех.
А вот если вы вели переписку с самого начала, если отчёты у вас раз в неделю, если по каждому отклонению у вас есть письмо с датой — это уже серьёзная аргументация. И даже если дело дойдёт до спора или суда — вы спокойно откроете архив и покажете, что сделали всё, что должны. А заказчик — нет.
Что ещё можно сделать
Если проект идёт с постоянными нарушениями со стороны клиента, и вы чувствуете, что пахнет системной проблемой — предложите провести аудит проблемных мест. Это может быть встреча с куратором, сессия ретроспективы, что угодно. Но важно, чтобы вы инициировали улучшение, а не просто фиксировали сбои.
Ещё один приём — завести журнал рисков и отклонений. Очень просто, в Excel или Confluence: дата, суть отклонения, последствия, уведомление клиента (ссылку на письмо), статус. Раз в две недели — отправка клиенту с просьбой подтвердить, что он ознакомлен. Это тоже защита.
И напоследок
Вся эта история не про то, чтобы обвинять. А про то, чтобы беречь свою команду, проект и репутацию. Бывают сложные клиенты. Бывают отличные, но перегруженные. А бывают те, кто просто не хочет брать на себя ответственность. И если вы системно фиксируете, что происходит — у вас всегда будет чем себя защитить.
Вы не обязаны быть юристом. Но обязаны быть аккуратным менеджером. Не для протокола, а чтобы в нужный момент не пришлось объяснять, что вы не виноваты. Лучше иметь всё под рукой — и продолжать спокойно работать.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Про курсы на нашем сайте https://1solution.ru/services.