«Бесконечные» правки на фрилансе

Рассказ о том, как клиенты сначала мучили меня правками, а потом я такой взял — и поправил свои процессы так, что стал получать от правок удовольствие. А заказчики начали сразу получать тот результат, который им нужен.

В начале хочу сделать важную ремарку. Статья, которую вы прочитаете ниже, — это глава из книги, читатели которой уже погружены в контекст. Контекст того, что автор — это проектировщик информационных систем, который предоставляет сложную, дорогую и растянутую во времени услугу. Не всем подойдёт такой способ ведения дел. А теперь поехали:

Самый страшный враг на свете — это правки от клиента,
Видишь правки — защищайся. Ты — эксперт, тебе видней!
Если это не поможет — правь всё молча, с грустным видом,
Чтоб заказчик сразу понял, как он был с тобой неправ.

Один из своих первых заказов на фрилансе я делал пару недель. Приступил к задаче с небольшой задержкой, основной объём выполнил ближе к концу срока. В последний день резко ускорился, наводя беспорядок в исходниках. Тогда мне и в голову не приходило, что так я создаю себе много дополнительной работы.

Клиент получил результат и со словами «ознакомлюсь на выходных» пропал на несколько дней. Я с нетерпением ждал обратной связи, ведь от неё зависел финальный платёж, а мне как раз нужны были деньги. И вот письмо с комментариями наконец пришло.

Открывал я его с большим оптимизмом, так как считал, что отлично справился с проектом. Но когда увидел объём текста, одновременно и расстроился, и разозлился. «М-да… не видать мне оплаты в ближайшее время!» — подумал я, вчитываясь в десятки замечаний.

Я собрался с силами и уселся за правки. Многие из них были очень простыми и занимали всего несколько минут. Некоторые были посерьёзнее и требовали больше времени. А с какими-то не хотелось соглашаться просто потому, что на их внесение могло уйти столько же часов, как на создание всего проекта. Такие комментарии я отложил «на потом» и решил обсудить их отдельно во время следующей демонстрации.

Больше всего меня злило то, что я сам сильно усложнил себе работу, не наведя порядка в исходниках. Часть элементов назвал так, что спустя некоторое время сложно было разобраться, что конкретно имелось в виду. А ещё не использовал символы (или мастера). Это такие элементы, которые используются во многих местах интерфейса и при этом их можно отредактировать все разом, внеся изменения лишь в один из них.

С горем пополам за несколько дней я справился с правками и вдруг получил ещё одно письмо с перечнем комментариев. Клиент сопроводил его коротким сообщением: «Нашёл ещё несколько моментов, которые хотелось бы поправить».

Тут я совсем приуныл. «Сколько же можно меня мучить?.. И когда это закончится?» — думал я, продолжая работу на последних остатках силы воли. Мне казалось, что клиент, который представлялся совершенно адекватным в начале сотрудничества, превратился в монстра и решил таким образом обесценить проделанную работу и свести меня в могилу.

Во время демонстрации я защищал свою работу, как лев. Больше всего хотелось сделать так, чтобы заказчик принял мои аргументы и отказался от многих правок. В некоторых случаях он действительно соглашался, и я, радуясь маленьким победам, защищался ещё сильнее. В какой-то момент это превратило наш диалог в настоящее сражение, где на кону стояло не качество проекта и удовлетворённость заказчика, а количество часов, которые придётся потратить на правки.

Стоит ли говорить, что перед началом работ я настолько скудно описал их состав в приложении к договору, что никак не мог заявить: «Мы о таком не договаривались!». И получилось, что, с одной стороны, я придерживался позиции «Клиент всегда прав и я доведу работу до конца, не запрашивая дополнительных денег», а, с другой, своим поведением на переговорах всячески намекал ему, что он неправ и что пора бы отпустить бедного фрилансера на свободу.

Но клиент не сдавался, и тогда я включил другую тактику: стал молча применять все правки, даже самые спорные, без обсуждений и возражений. Выглядело это, конечно, смешно. Я из специалиста превратился в «карандаш» в руках заказчика, которым тот рисовал, что хотел. Получалось криво, и, посмотрев на результат своего труда, он попросил откатить многие изменения назад. В этот момент я понял, что не сохранял некоторые промежуточные версии, поэтому придётся проделать очередную дополнительную работу, чтобы вернуть всё как было.

В конце концов клиенту всё это явно надоело. Сначала он вытянул из меня те правки, которые сумел, потом почувствовал мою апатию и бесполезность в качестве специалиста по интерфейсам (ведь я всё делал «под его дудку») и не стал больше тратить сил и времени на такое общение. Сделал финальный платёж, поблагодарил за работу и больше никогда ко мне не обращался. Я обрадовался завершению этой «каторги», не догадываясь, что навсегда потерял хорошего клиента.

Чему эта история меня научила: браться за работу пораньше, чтобы не делать всё в последний момент, заранее готовить исходники к большому количеству правок, а также сохранять промежуточные результаты, чтобы можно было легко откатиться назад.

Благодаря такому подходу я стал меньше бояться комментариев, а значит, и стал меньше защищать свои решения, обращая внимание теперь не на свои рабочие часы, а на то, что же именно клиенты в результате хотят увидеть. В какой-то момент я понял, что раньше общался с заказчиками, находясь с ними «по разные стороны баррикад», а теперь мы вместе мирно решали, как справиться с общей задачей.

В лучшую сторону изменились и договоры. Теперь в приложениях я описывал работы таким образом, чтобы и обезопасить себя от переработок, и дать клиентам определённый «коридор вариативности», в рамках которого проект мог быть реализован тем или иным образом. Нельзя слишком ограничивать вариативность, поскольку это не позволит получить результат, который точно понравится клиенту. Нельзя и оставлять её слишком высокой, так как можно взяться за один проект, а на выходе получить другой.

Со временем я побывал на месте клиента и ужаснулся, во многих моментах вспоминая себя в начале фрилансерского пути.

Как заказчик я получал объёмные результаты работ в самый последний момент и вынужден был тратить часы на их изучение и обратную связь. За один подход не успевал всё проверить. Приходилось отправлять комментарии порциями, что создавало впечатление, будто я специально заваливаю фрилансера правками. Тут-то я и понял, что сделал неверные выводы о своих первых заказчиках. Они не хотели заваливать меня правками, я сам ставил их в такие условия.

Частенько из десяти комментариев исполнители отрабатывали семь-восемь, а остальные пропускали то ли из-за невнимательности, то ли в надежде на то, что я не замечу.

Они спорили со мной и бились за каждую правку, а в какой-то момент сдавались и начинали бездумно исправлять всё подряд, как бы показывая, что я победил в сражении, но проиграл в войне.

Наконец в какой-то момент меня огорошивали фразой: «Вы исчерпали лимит правок, все дальнейшие комментарии только за дополнительную плату».

Я изумлялся, расстраивался и быстро учился. Я понял, что никому не нравится плодить бесконечные комментарии, все хотят результат, который устроит. Осознал, что многие исполнители стараются угадать желания клиента вместо того, чтобы спросить его напрямую и зафиксировать в начале работ. Тогда не пришлось бы исправлять с помощью бесконечного количества «костылей» то, что неверно в своей основе.

А ведь я и сам частенько занимался угадыванием, мало времени затрачивая на сбор всех необходимых сведений о проектах и желаниях клиентов. Проблема заключалась в том, что периодически мне везло (с первой попытки делал то, что нужно) и поэтому я поумнел не так быстро, как если бы каждый раз сталкивался с клиентами, разочарованными в результате.

В итоге я пришёл к тому, чтобы не ограничивать клиентов в количестве правок, а получше работать над причиной их возникновения.

• Приступать к работе пораньше и сразу демонстрировать промежуточные результаты, чтобы быстрее «синхронизироваться» с клиентом и в конце работы уже иметь одинаковое видение.
• Не предоставлять заказчикам объёмных результатов, требующих нескольких дней на изучение, а дробить их на части, с которыми можно ознакомиться за один подход.
• Изначально готовить исходники к будущим доработкам. Свести к минимуму трудозатраты на правки, чтобы не бояться их.
• Сохранять промежуточные результаты каждый раз, когда в проект вносятся крупные изменения, чтобы иметь возможность откатить работу до прежней версии.
• Записывать все комментарии, даже самые незначительные, чтобы ничего не упустить. Если список предоставил сам клиент, то проработать все его пункты без исключений. Он не обратит внимания на 19 выполненных пунктов из 20, но запомнит именно тот, который фрилансер почему-то не сделал.
• Не бояться переделывать базовые решения. Это гораздо эффективнее, чем пытаться спасти изначально неправильное видение с помощью большого количества «костылей».
• Не ограничивать клиентов в количестве правок.

Коллеги не одобряли моего решения не ограничивать клиентов в количестве правок. Они исходили из того, что заказчики обязательно будут пользоваться такой возможностью мне во вред: бесконечно плодить комментарии, пока не замучают несчастного фрилансера до потери сознания. Однако я сам рассуждал по-другому. Я понимал, что в мире существует слишком мало людей с садистскими наклонностями, чтобы у меня был шанс столкнуться с ними. Клиенты хотят получить тот результат, которым будут довольны, а мешают им в этом в первую очередь рабочие процессы, выстроенные фрилансерами. К моменту написания этой главы я поработал с более чем тремя сотнями заказчиков, и ни один из них не воспользовался возможностью «бесконечных» правок. Мы короткими итерациями приходили к нужному результату и заканчивали работу на позитивной ноте.

Бывают ситуации, когда заказчику трудно выбрать из двух вариантов, и он начинает метаться туда-сюда, перескакивая с версии на версию. Обычно фрилансеры реагируют на такое поведение негативно, им не нравится неуверенность клиента, приводящая к дополнительной работе. Однако тут всегда можно выбрать из двух подходов: «Решайтесь уже скорее либо платите больше денег за новые варианты» или «Давайте попробуем вместе определиться с выбором и с тем, на чём он будет основан (чтобы в следующий раз проще принимать такие решения), и пойдём дальше». Я для себя выбрал второй.

Разумеется, случалось и такое: клиенты, получившие именно тот результат, который хотели, смотрели на него и понимали, что его можно улучшить. И это совершенно естественный процесс. Если мне показать прототипы, над которыми я закончил работать несколько месяцев назад, то у меня тоже появятся по ним хорошие идеи. Но, занимаясь бесконечными улучшениями, никакого проекта до конца не доведёшь.

Когда клиенты выходили за рамки требований к проекту, ситуация могла развиваться двумя путями. Если правки были незначительными, и их можно было легко внести без ущерба для себя, то я ничего не говорил заказчикам и вносил их в проект. Я поступал так для того, чтобы не заставлять их нервничать из-за того, что они вынуждают меня делать дополнительную работу бесплатно (ведь они не в состоянии оценить трудозатраты в незнакомой им отрасли). Когда я сам заказывал услуги фрилансеров и они сообщали, что проделали для меня что-то просто потому что такие хорошие и ценят своих работодателей, я испытывал дискомфорт. Я чувствовал, что становлюсь участником несправедливой сделки, в которой мне отведена роль эксплуататора. Поэтому сам стал использовать такой принцип: «Сделал больше, чем нужно, — не хвались этим, если не планируешь получить за это вознаграждение». Если это имело значение для клиента — он сам заметит. Если нет — не надо набивать себе цену за счёт того, что он не оценит.

В этом месте хочу обратить пристальное внимание читателя: не нужно стесняться рассказывать о проделанной работе во всех деталях. Это поможет клиенту увидеть больше ценности в результате. Но не стоит говорить об этом в контексте «Я сделал больше, чем вы просили», потому что это означает лишь то, что сделка была несправедливой.

Второй сценарий, по которому могла развиваться ситуация с правками, возникал, когда клиент просил сделать то, что заняло бы у меня много времени и сил, причём это не было прописано в договоре. Тогда я сразу сообщал заказчику, что эта работа не входила в наши договорённости, но я готов описать её в дополнительном соглашении и сделать за отдельные деньги. И дополнительно объяснял, что это также повлияет на уже согласованные сроки выполнения проекта. Чаще всего клиенты в таких ситуациях соглашаются с моими аргументами и вежливо отказываются от подобных правок. А иногда, наоборот, просят добавить эти работы в список «на будущее» и вернуться к нему после завершения текущей итерации (что и действительно происходит на деле в половине случаев).

Здесь важно продемонстрировать, что, несмотря на неготовность бесплатно проделывать дополнительную работу, я очень внимательно отношусь к таким пожеланиям, всё записываю, ничего не упускаю и с радостью поучаствую в дальнейшем развитии проекта.

В итоге я остановился на следующих правилах, защищающих от бесплатных переработок:

• Прописывать перечень работ в договоре достаточно детально, чтобы не возникло желания нагрузить фрилансера задачами сверх договорённостей.
• И при этом не настолько детально, чтобы у клиента был «коридор вариативности», с помощью которого он мог бы получить тот результат, который его полностью устроит.
• Те правки вне договорённостей, которые займут много времени и пойдут в ущерб фрилансеру, фиксировать и предлагать оценить отдельно в дополнительном соглашении.

Прочитать «Книгу нормального фрилансера» можно бесплатно на сайте. Присоединяйтесь и к Телеграму, я там тоже много всякого полезного пишу.