Прочитайте это правило, запомните и используйте. Оно принесет вам деньги и счастье. Но никогда не говорите клиенту, что работаете по этому принципу.

Если исполнитель потратил много времени на что-то, что не принесло пользу заказчику — это проблема исполнителя. Трудозатраты исполнителя не влияют на ценность конечного результата. Иначе все бы стали работать медленно, чтобы повысить стоимость работы.

Если исполнитель сделал работу быстро, то это не делает его работу дешевой. Конечный результат не должен из-за этого терять в цене. То есть исполнитель в принципе может (по своей воле) взять меньше денег за работу, но совершенно не обязан этого делать. Маленькие затраты — не значит дешево.

Я сталкивался с разработчиками, у которых болит совесть, когда они взяли за программирование задачи, например, 1000$ и думали, что будут работать 10 дней. Но в итоге смогли выполнить работу за 2 дня.

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

За многие годы я пришел к выводу, что есть 2 типа заказчиков:

• —покажите, что вы делали
• —покажите, что получилось

Иногда они перекочёвывают друг в друга. Но это не важно. Сейчас я напишу, как сдавать проекты каждому из этих типов заказчиков.

Заказчик «Покажи, что делали»

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

Я много раз сталкивался с такими заказчиками. Ты им экспертизу даешь (накопленную годами), быстро внедряешь наилучшее и быстрое решение. Проводишь работу за неделю, еще через неделю подбиваешь первоклассный результат. Но благодарности нет: «Вы тут неделю пару кликов мышкой сделали и хотите взять за это 500$? Ну уж нет!».

Заказчик «Покажи, что получилось»

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

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

Как быть?

Необходимо сразу раскусить клиента. Понять, к какому типу он относится. И отчеты ему делать в его мире. Нужен список работ: присылайте в емейл полотно выполненных задач (дробите их сильнее). Нужен результат: к черту, как вы сильно трудились, присылайте гугл аналитикс с ростом трафика; клиенту пофиг на robots.txt

PS я никогда не встречал клиента, который бы объединял оба типа.

PPS забыл упомянуть, что если вы провалили проект, то первый заказчик выгоден для вас. Он увидит объем работ и скажет: «Ладно, вы старались, тут нет вашей вины в провале». А второй заказчик будет вас наказывать по полной программе.

Если вы напишите коллеге: «Обработай эту картинку и пришли мне сегодня», но ответа на сообщение не получите, то какой вывод сделаете?

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

В голове не укладывается, как с ним работать — я ставлю задачу, ответа нет, но это может означать, и что задача в работе, и что он не увидел задачу.

На просьбу отвечать, что задача получена, он сказал:

— Зачем? Ты начальник, я подчиненный. Ты сказал, я сделал. Я буду делать все, что ты говоришь. И уведомлять тебя только, если это сделать невозможно технически или по срокам. Все остальное время я нахожусь в ожидании задач от тебя. Это моя работа.

По работе столкнулся с программистом (хорошим!). При работе над проектом пришлось привлекать его к работе в смежной сфере: программировать фронтенд CRM.

Скоро у меня начнет дергаться глаз. У этого программиста есть свое мнение по любому вопросу. На все задачи он отвечает: «А вот я не согласен».

• Я: В карточке клиента сверху надо выводить id клиента, чтобы проще было искать.
• Он: А вот я не согласен. ID это лишняя информация для пользователя, захлямляет карточку

• Я: Здесь для редактирования предусмотрено открытие новой страницы, а не модальное окно.
• Он: А вот я не согласен. Корректировка этих полей быстрая, не нужно делать новую страницу. Лучше модальное окно.

Вы может скажете, что стоит прислушаться к нему. Но это большой проект, где много людей. Где есть два UX-специалиста. Где есть несколько дизайнеров. Где все нарисовано и утверждено. Но… я не согласен :)

Что делать?

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

На личном примере. Ванну я принимал по вечерам. С детства так сложилось. Днем игры и учеба, вечером (перед сном) ванна.

Я десятки лет жил по такому принципу. И вот однажды, я принял ванну не вечером. А в час дня. Это было тревожно. Разгар дня — дела надо делать, а не расслабляться. А вдруг кто-то позвонит и надо будет ехать срочно.

В голове устойчиво сидела аксиома: хорошо поработал днем — имеешь право вечером отдохнуть.

Ломалось это тяжело. До сих пор иногда есть угрызения совести, когда в разгар дня я занимаюсь отдыхом. Умом понятно, что есть сутки, на протяжении которых должна быть выполнена работа, и не важен точный срок. До сих пор завидую людям, которые имеют свободный график. У меня есть знакомые, которые в один день могут встать в 4 утра, за два часа сделать работу и опять лечь спать. В другой день они будут работать с 9 до 12, а затем с 20 до 23. И у них нет ни малейшего угрызения совести. Я спрашивал!

К сожалению, такого дзена я пока еще не достиг.

Есть люди, которые пытаются пересмотреть стоимость работ после их начала или завершения.

Два прошлогодних случая.

Первый случай, клиент — стартап. Денег не очень много, но есть внешнее финансирование. Клиенту была предоставлена полная смета с разбивкой по этапам работ. Цена устраивала. После выполнения 25% всех работ клиент нашел (мир тесен, все становится явным достаточно быстро) трех программистов за долю в бизнесе. Естественно решил с нами расторгнуть договор — доля пока ничего не стоит и выгодно ее отдать, чем платить живые деньги.

Мы сделали расчет, что выполнено, что начато выполнятся и какую сумму можем вернуть. Тут и началось интересное. Клиент наотрез отказался принимать наш расчет. Доходило до банального, что надо разработать дизайн сайты из 10 страниц. Раз мы сделали только главную, значит ее стоимость 1/10. Хотя каждый дизайнер знает, что разработка концепции, продумывание дизайна и дизайн главной страницы занимает гораздо больше времени, чем каждая из последующих страниц. У нас временные затраты на главную были 30% от всего объема работ. Но клиент не хотел это понимать.

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

Многие менеджеры проектов скажут вам, что разработчик-перфекционист это очень плохо. Действительно, разработка ПО (особенно заказного) — это коммерческая деятельность. Она должна быть рентабельной. Поэтому негласно действует правило — доводим разработку до 80% готовности. Пилить дальше — это дорого, а часто и невозможно. Ошибки все не исправишь. Есть даже термин — showstoppers — ошибки, которые препятствуют выходу релиза. Например, если вы разрабатываете браузер и он зависает каждые 10 минут — это showstopper. Эксплуатация браузера невозможна. А вот если браузер не умеет распечатать страницу сайта — это не шоустоппер, ведь страницы печатают далеко не все пользователи.

Так вот, перфекционисты вредны на проекте, часто они упираются в какую-то ошибку или еще что-то. Конечно, это хорошо, что ошибка выявлена. Но перфекционист считает эту ошибку вселенской бедой, и не успокаивается, пока не исправит. В итоге проект не развивается, а топчется на месте — программисты вылизывают код, исправляют ошибки и оптимизируют скорость. Всю эту работу обычный пользователь не видит. Видит он, что его ПО не получает новые функции и возможности. И он переходит к конкурентам.

Поэтому грамотный project manager заботится выполнить каждую фичу программы на «чуть более 80% готовности», убрать ошибки-шоустопперы и выкатить новую версию. Затем собрать жалобы пользователей и исправить еще одну порцию ошибок. Грамотный проджект-менеджер стучит линейкой по рукам перфекционистов, когда они слишком закапываются в код.

Полагаю теперь у вас есть понятие о разработке программ. И вот был у меня случай, когда клиент захотел на финальном этапе сильно переработать дизайн сайта. Эта переработка уже выходила за рамки бюджета. Дизайнер уже очень устала от бесконечных правок клиента. Все были на взводе.

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

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

Утром был новый дизайн. Я был счастлив. Перфекционизм дизайнера сыграл мне на руку. Она сделал эти правки в силу своего характера — во внерабочее время и без дополнительной оплаты. Тогда-то я и полюбил перфекционистов. Главное уметь направить их в нужное русло.

В мае 2015 года клиент заказал разработку приложения для смартфона. Наша ошибка была в том, что мы разрешили клиенту самому нарисовать весь дизайн. При этом клиент не понимал специфики разработки приложений и умел лишь работать в фотошопе.

Вторая ошибка — мы взяли слишком мало денег. Мы позарились, что сможем быстро собрать апликейшен с имеющимся дизайном. В итоге оказалось, что проект надо было оценивать в минимум 4 раза больше. Зафиксировали колоссальный убыток. :(

За время выполнения проекта сменили три команды разработчиков. Только с четвертой удалось довести проект до конца.

Но я в целом доволен данной ситуацией. Самое главное решение, которое я принял и которым горжусь — отказаться от дизайна клиента и разработать его самим. Это дало невероятный буст проекту и мы смогли его завершить за 3 месяца от начала и до конца.

Самое главное, что клиент невероятно доволен. Он уже две неделе пишет мне в скайп, как круто работает его приложение и благодарит программиста.