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