Если видишь до дедлайна, что не сдашь работу к сроку,
Не спеши писать клиенту и расстраивать его.
Лучше скройся и втихую всё доделай в выходные —
И клиент, поволновавшись, будет рад тебе вдвойне!
По-настоящему управлять сроками можно при соблюдении двух условий. Первое: сроки называет фрилансер, а не клиент. Второе: сроки не зависят от третьих лиц.
С первым всё понятно: исполнитель оценивает, сколько часов ему понадобится на решение задачи, сверяется с календарём, закладывает время на болезни и другие непредвиденные обстоятельства, берёт небольшой запас сверху и только после этого называет срок.
Я сам, когда берусь за задачу, требующую недели, обычно называю не меньше месяца. Если сдам работу раньше срока — никто не расстроится. Поначалу я боялся, что если оценю длительность работы равной месяцу и сделаю её за несколько дней, то вызову много вопросов у клиента: мол, почему он платит так много за такую «короткую» задачу. Но на практике, во-первых, заказчики только радовались, когда получали результат раньше времени, а, во-вторых, это случалось крайне редко. Зная, что впереди у меня ещё много дней на работу, я не торопил события.
Разумеется, это приводило к тому, что я с опозданием садился за задачу и сдавал всё в последний момент, едва-едва не нарушая сроков. С этим нужно было что-то делать, и я стал пробовать разные варианты.
Сначала называл сильно сжатые сроки. Это привело к переработкам, в том числе ночным, а также к нескольким проектам, сделанным с опозданием. Кроме того, сами клиенты часто не могли принимать промежуточные результаты с той же скоростью, с которой я их предоставлял. И тогда им приходилось либо переносить сроки, либо соглашаться на то, что я им показывал. В конечном итоге заказчики оставались недовольными.
Тогда я вернулся к адекватным срокам, но выстроил работу таким образом, чтобы показывать клиенту первый промежуточный результат через два-три дня после получения оплаты. За такой срок заказчик от меня многого не ожидал, поэтому даже если я не мог раскачаться и садился за задачу буквально за несколько часов до демонстрации, этого было достаточно для старта.
Мне понравился такой подход, и я стал назначать промежуточные переговоры чуть ли не каждый день. Это не только спасло меня от избегания работы и двигало вперёд, но и оказалось очень эффективным с точки зрения движения с клиентом к единому видению результата.
Ведь комментарии и обратную связь я получал практически мгновенно, учитывал их на ранних этапах и к концу работы выдавал результат, идеальный с точки зрения клиента.
Со временем я сбалансировал этот подход так, чтобы, с одной стороны, не перегружать клиентов промежуточными переговорами и, — с другой, — не позволять себе отвлекаться от работы на долгое время. И через несколько лет привычка к такому подходу выработалась сама.
Так я перехитрил себя. Поставил в условия, когда невозможно сдавать работу в последний день, но при этом за неё всё так же можно садиться с опозданием, за несколько часов до начала переговоров.
Я не люблю работать с календарём, так как он превращает мою прекрасную свободную жизнь в набор регламентированных событий, ожидающих своего часа. Но когда в работе несколько проектов, без него не обойтись.
Вместо полноценного календаря я пристрастился использовать небольшие заметки, где в хронологическом порядке были расставлены два вида дат: дедлайны (так называются сроки финальной сдачи работ) и переговоры. Такой список выглядел примерно так:
- 06 окт, чт: 15:40, переговоры с Андреем
- 06 окт, чт: 17:00, переговоры с командой по аукциону
- 10 окт, пн: 12:00, переговоры с Игорем
- 11 окт, вт: дедлайн по автомобилям
- 13 окт, чт, 16:00, переговоры с Анной
Этого было достаточно. В моей работе почти никогда не бывало такого большого количества мероприятий, чтобы нужна была система напоминаний. Список рос вниз, в будущее, а когда происходили верхние события, я их просто удалял.
Опоздания на встречи для меня недопустимы. Я действую по принципу «На встречу можно либо прийти заранее, либо опоздать». Как уже писал в главе про первые переговоры, я нахожусь в боевой готовности за десять минут до начала. Оборудование протестировано на работоспособность, подготовлен резервный канал Интернета, я нахожусь в нешумном и комфортном месте. Если используется видеосвязь, я выгляжу аккуратно и слежу за тем, чтобы в помещении был порядок.
Во время живых встреч в офисах я точно так же прихожу заранее и хорошо подготовлен. Для того чтобы не опоздать на мероприятие в большом городе, необходимо закладывать дополнительные риски на пробки, заминки на проходных, погоду.
Иногда я перестраховываюсь настолько, что оказываюсь на месте раньше на полчаса или даже на час. На этот случай у меня всегда припасена книга или работа, которую можно сделать во время ожидания.
Если я всё-таки опаздываю, то понимаю это задолго до самого опоздания. Даже если есть просто небольшой риск, я всё равно звоню клиенту и предупреждаю его о задержке. Я извиняюсь, объясняю причину, если это уместно, а также сообщаю время, в которое точно можно рассчитывать на моё появление.
Такие звонки — крайне неприятное событие. Всегда возникает желание втихую успеть впритык. И ничего страшного, если опоздал всего на шестьдесят секунд. Но для человека, ожидающего на месте, эта минута может оказаться решающей, чтобы принять решение не сотрудничать с неблагонадёжной личностью. Нет ничего страшного в факте опоздания, ведь иногда возникают события, на которые мы никак не можем повлиять. А вот звонок с предупреждением — это зона ответственности опаздывающего, и нет оправданий тому, чтобы держать своего собеседника в неведении.
Точно так же важно предупреждать заранее, если сдвигаются сроки сдачи проекта. Структура предупреждения — та же, что и с опозданиями на встречи: извинение, причина (если это уместно) и новая дата. На самом деле озвучивать причину обычно уместно только в том случае, если клиент сам об этом спросил. Вопрос «Почему так произошло?» не так важен, как «Что будем делать дальше?».
К сожалению, я не знаю способа, как перебороть страх сообщить клиенту об опоздании или переносе. Просто берёшь и делаешь это. В первый раз было очень сложно, затем всё легче и легче. Главное, чтобы с опытом быстрее рос навык оценивать сроки, а не навык безбоязненно сообщать о переносах и опозданиях.
В какой-то момент я стал настолько уверенно сдавать работу в срок, что начал гарантировать это деньгами. Сообщал клиентам, что если нарушу дедлайн, то они получат и результат работы, и предоплату. Тогда мне это казалось очень классным маркетинговым ходом, демонстрирующим, насколько я надёжен и уверен в своих силах. Но, побывав на месте клиента, я взглянул на такое предложение другими глазами. Человек, готовый вернуть предоплату за проделанную (хоть и с опозданием) работу, как будто не очень ценит своё время, причём в случае опоздания может вернуть деньги и оставить клиента с недоделанным проектом. В итоге я отказался от такой формулировки и вернул в договор старую добрую строчку про пени.
Иногда приходилось работать с клиентами, которые сами диктовали сроки. Поначалу я прикидывал свои возможности, решал, что управлюсь, и смело брался за такие задачи. Но почти всегда ничего хорошего из этого не получалось. Дело в том, что клиент, который заявляет, что ему нужен результат к определённой дате, почти всегда будет некомпетентным менеджером, который не понимает, что скорость выполнения работы — это индивидуальный параметр для каждого исполнителя и что оценку своих сил и возможностей такие люди должны делать сами, учитывая другие свои проекты и планы.
Хороший менеджер сначала попросит фрилансера оценить сроки, а уже затем может попробовать как-то на них повлиять, предложив особенно комфортные и выгодные условия. Он не будет сразу требовать результата к конкретной дате.
Менеджеры, которые этого не понимают, не только неадекватны в своих требованиях. Они неопытны и неэффективны в работе. А значит, связавшись с таким клиентом, можно ожидать, что он не сумеет оперативно закрывать возникающие вопросы и принимать промежуточные решения, не замедляя работу. Наоборот, чем быстрее моим клиентам нужен был результат, тем более губительными для проектов были их комментарии.
Иногда мы тратили непростительное количество часов на обсуждение незначительных деталей. Иногда клиенты пропускали промежуточные переговоры, потому что им нужно было тушить какие-то другие «пожары». Бывало и такое, что в день сдачи заказчик пропадал и появлялся через неделю, демонстрируя, что жёсткий дедлайн был, по всей видимости, способом заставить исполнителей работать «быстрее» и «эффективнее».
Мне хватило всего нескольких случаев сотрудничества с такими клиентами для того, чтобы сформировать политику работу с ними:
- Если дела идут хорошо и есть выбор между клиентами, то можно просто отказаться от заказчиков с жёсткими сроками.
- До начала работы я сразу составлял план промежуточных переговоров на весь срок и согласовывал его с пометкой, что в случае нарушения будут штрафы как по времени сдачи, так и по деньгам.
- Я отказывался от своей фирменной гарантии деньгами того, что результат клиенту понравится. В случае же, когда заказчик саботировал работу, делал проект так, чтобы к дедлайну он формально соответствовал функциональным требованиям, а правки оценивал отдельно.
Подведу итоги. В управлении сроками я придерживаюсь следующих принципов:
- Стараюсь перехитрить самого себя и поставить в такие условия, когда нарушить сроки почти невозможно.
- Если вижу, что не успеваю, то предупреждаю клиента сильно заранее, а не в последний момент. Воспринимаю такие ситуации не как неудачи, а как точки роста. Совершив ошибку сегодня, я получаю ценный опыт и спасаю себя от совершения этой ошибки завтра.
- Если жизнь заставила работать в чужих сроках, я сильно ужесточаю условия сотрудничества, чтобы и максимально увеличить шансы на хороший результат для клиента, и защитить свои время, нервы и репутацию.
Следующая глава: «“Бесконечные” правки»