Почему подрядчик срывает сроки, хотя на старте всё было согласовано
«Мы всё обсудили» ещё не значит «мы одинаково всё поняли»
Мне кажется, это одна из самых частых проблем.
На созвоне обсудили задачу. Вроде все согласны. Подрядчик говорит: «Да, понятно».
Проходит несколько дней — получаешь результат и понимаешь, что ожидала вообще другое.
И начинается:
— А мы думали, это не нужно. — А этого не было в задаче. — А мы поняли немного иначе.
Причём никто специально ничего не саботировал. Просто каждый вышел со встречи со своим пониманием результата.
Поэтому сейчас я стараюсь важные договорённости фиксировать письменно: что делаем, какой результат должен получиться, кто отвечает и к какому сроку.
Это банально. Но работает лучше, чем «ну мы же это обсуждали».
Большой дедлайн без промежуточных точек — риск
Допустим, подрядчику дали две недели.
Можно договориться: «Через две недели жду готовый результат».
И две недели практически ничего не видеть.
А накануне дедлайна узнать, что возникли сложности.
Поэтому мне спокойнее разбивать работу на этапы.
Не обязательно контролировать человека каждый день. Я вообще не сторонник сообщений в духе «ну что там?» каждое утро.
Но контрольные точки нужны.
Например:
первый вариант → проверка → правки → финальная версия.
Тогда проблема становится видна не за день до запуска, а гораздо раньше.
Иногда подрядчик действительно не успевает. И это нормально
В проектах случаются задержки.
Появилась более сложная техническая проблема. Заболел специалист. Потребовались дополнительные данные. Что-то оказалось сложнее, чем предполагали на старте.
Для меня сама задержка не всегда главная проблема.
Гораздо хуже, когда о ней сообщают в последний момент.
Если человек заранее говорит:
Здесь возникла проблема. К пятнице не успеваем. Нужны ещё два дня.
с этим уже можно работать.
Можно поменять приоритеты, подключить другого человека, перенести часть задачи или предупредить заказчика.
Когда о проблеме узнаёшь в день дедлайна — вариантов намного меньше.
Бывает, что подрядчика тормозим мы сами
И про это тоже легко забыть.
Например, подрядчик ждёт текст.
Или доступ.
Или согласование макета.
Или ответа на вопрос, без которого не может продолжать работу.
Формально задача у него. Но фактически несколько дней она стоит на нашей стороне.
А потом наступает дедлайн и звучит: «Подрядчик опять не успел».
Поэтому я стараюсь смотреть не только на исполнителя, но и на зависимости: есть ли у него сейчас всё необходимое, чтобы двигаться дальше?
Ещё одна причина — приоритеты
У подрядчика почти никогда нет только одного клиента.
Сегодня наш проект для него главный. Завтра появляется срочная задача у другого заказчика — и сроки начинают ехать.
Мы не можем полностью управлять чужой загрузкой.
Но можем раньше замечать проблему.
Если задача критичная, мне важно не просто услышать «сделаем к пятнице», а понимать, на каком этапе она находится до этой пятницы.
Особенно если от неё зависят следующие работы.
Поэтому я перестала воспринимать дедлайн просто как дату
Для меня сейчас срок — это не запись:
«Готово 15 сентября».
Это скорее цепочка:
задача → ответственный → промежуточный результат → проверка → правки → финальный результат.
И если где-то эта цепочка начинает тормозить, лучше увидеть это сразу.
Потому что когда подрядчик пишет за день до запуска: «Мы немного не успеваем», управлять сроками уже поздновато.
А вот заметить проблему за неделю и что-то с ней сделать — это уже нормальная работа с проектом.
И, наверное, главный вывод, который я для себя сделала: контроль подрядчика — это не постоянное «как дела с задачей?». Это создание процесса, в котором проблема становится видна раньше дедлайна.