Это произошло в несколько этапов. Поначалу я, как и любой нормальный фрилансер, чертыхался клиентских комментариев и не любил вносить правки в результаты работы. Это было связано с тем, что мои прототипы и эскизы были не подготовлены к тому, чтобы их править.
Я прочувствовал на практике, сколько теряю из-за этого времени и тут же внёс несколько изменений:
не ленился и давал осознанные и последовательные названия для разделов и элементов, чтобы потом можно было легко найти нужный;
использовал мастера и компоненты везде, где можно (чтобы редактировать их в одном месте, а изменения применялись бы сразу во всех);
использовал единые стили и ограничивал их выбор.
Затем я понял, что, чем больше сил вложил в тот или иной участок работы, тем морально сложнее вносить в него правки. Например, продумал досконально каталог и карточку товара — и отрисовал все их возможные состояния, потому что было приятно работать над этой задачей. И довольный несёшь результат клиенту. А он даёт какой-нибудь комментарий, который слегка изменяет одно из базовых решений, — и из-за этого нужно переделывать всё то, что уже так детально проработал.
Чтобы избавиться от этой проблемы, я приучил себя не углубляться в детали до тех пор, пока не будут согласованы базовые решения. И вместо детализации одного конкретного раздела, который мне нравился, я тратил время на поверхностную проработку остальных. Это не было так весело и интересно, зато позволяло избегать ситуаций, когда надо страдать, переделывая большой участок работы.
А ещё я перестал показывать клиентам большие участки работы. Я в какой-то момент сам побывал на месте клиента и понял, насколько сложно проверить и дать обратную связь по макетам, которые кто-то клепал в течение недели, не получая никаких подтверждений того, что работа идёт в верном направлении. Во-первых, их много, а, во-вторых, в них обычно столько неприятных моментов, что даже непонятно, с чего начинать давать обратную связь. Так что я стал демонстрировать промежуточные результаты чуть ли не каждый день.
Наконец, после нескольких десятков проектов, я осознал, что мне всё равно придётся править результат своей работы. Что с первого раза я в любом случае не сделаю идеальный вариант, который понравится клиенту. А даже если и сделаю, то вероятность этого не настолько высока, чтобы делать ставку на подобный исход.
Это привело к тому, что я стал менее серьёзно и ревностно относиться к результатам работы. Кому-то может показаться, что это не очень хорошо. Это что же, я теперь не особо заинтересован в том, чтобы у меня был крутой результат? Вовсе нет! Как раз спокойное отношение и позволило мне развиваться быстрее в профессиональном плане. Я был нацелен не на тот результат, который должен нравиться мне, а на тот, который удовлетворит клиентов. А для этого приходилось постоянно развиваться, смотреть на лучшие практики и методы, а ещё учиться вытаскивать из людей информацию о том, что они считают достойным результатом и почему.
И вот проекты стали выполняться быстрее, клиентов становилось больше, они были довольны и звали новых. И это привело к тому, что я и к работе относился спокойно, и результат мне нравился.
И так я полюбил работать с правками:
специально готовя свои прототипы ко внесению этих правок с первых минут работы;
не вдаваясь в детализацию до тех пор, пока основные моменты не будут согласованы;
не предоставляя клиенту объёмных результатов, а разделяя работу на короткие последовательные итерации;
ориентируясь не на собственное ощущение качества, а на потребности клиентов, и снизив для себя важность происходящего.
Кстати, можно сократить эти выводы до «не делать лишней работы и в настоящем заботиться о себе в будущем». Сколько раз я говорил себе: «Спасибо, Егор, что ты не поленился и потратил лишнюю минуту на то, чтобы запихнуть постраничку в мастер». Или: «Спасибо, что не стал прорабатывать раздел, пока не получил от клиента обратную связь. Сейчас бы пришлось всё переделывать».
Такой подход к делу перекочевал из проектирования интерфейсов во всё, чем я занимаюсь.
TooBigBigs
Чтобы избавиться от этой проблемы, я приучил себя не углубляться в детали до тех пор, пока не будут согласованы базовые решения.
Есть ощущение, что зачастую базовые решения невозможно найти, не проработав все до деталей. И уж тем более заказчик не должен выносить здесь каких-то решений, откуда у него такие компетенции?
Для меня вполне комфортна ситуация, когда сделав работу на 90%... начинаешь всё сначала, потому что только теперь ты понял, как на самом деле надо было.
Я был нацелен не на тот результат, который должен нравиться мне, а на тот, который удовлетворит клиентов.
Сочувствую! Наверное, это зависит от психотипа, но для меня такой подход решительно неприемлем. Я совершенно определенно ценю свой труд выше, чем чьё-либо мнение о нём, поэтому просто перестал работать с теми, кого надо удовлетворять; а всем оставшимся изложил эти свои принципы и поднял ценник.
Ekamelev Автор
Заказчик не должен выносить решений. Он должен согласовать решения, которые я ему предлагаю. Или дать обратную связь, которая может на эти решения повлиять.
Кстати, прекрасно понимаю. К сожалению, я упустил этот момент в заметке. А звучит он так: зачастую, увидев, что базовое решение не верно, я сразу начинаю переделывать проект с нуля (что-то вроде мягкого перезапуска). Поэтому я вдвойне заинтересован в том, чтобы не углубляться в детализацию там, где не надо. А поначалу старался спасать неверные решения огромным количеством костылей, что приводило к ещё более плачевным результатам.
Сочувствовать не стоит. Я действительно получаю удовлетворение от результата работы, когда вижу довольного клиента. В конце концов основная задача моего этапа работы — формализовать потребности клиента и перевести их на язык разработчиков. Если я эти самые потребности как-то не так интерпретирую, то кому тогда нужен результат моего труда? Но без конкретных примеров что моё, что ваше высказывания крайне субъективны и абстрактны.