Перевод статьи молодого греческого программиста «Why I bill hourly»
Недавно ко мне обратился мой первый потенциальный клиент, который хотел добавить несколько возможностей в небольшое приложение на Django. Я огласил свою часовую ставку, чем крайне его шокировал — он-то хотел услышать фиксированную цену за нужные ему доработки. Что из этого получилось? Мы работаем вместе, он очень доволен как результатами, так и суммами, которые он на них тратит, а я не поступился своими принципами оплаты. Вот аргументы, которые я использовал в защиту мнения о том, почему почасовая ставка лучше для всех заинтересованных сторон — может быть, они помогут кому-то еще.
Я люблю сравнивать разработку программного обеспечения с возведением здания, начиная с пустого земельного участка. Процесс выглядит примерно так:
Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?
Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?
Я стою XX $/час. Я могу потратить 2-3 часа бесплатно на оценку того, что вы хотите получить. После этого я начну брать деньги, даже за пятиминутный телефонный разговор. Правило простое: если я делаю что-то, чего я не делал бы, не будь вашего проекта, вы за это платите.
Мой клиент был в ужасе. Первое, что он сказал — XX $/час — это слишком много! Потом он напомнил о других разработчиках, которые потратили его время и деньги и не сделали ничего полезного. В чем-то он был прав — откуда он мог знать, что может мне доверять? На это у меня тоже был готов ответ.
XX $/час кажутся большой суммой, но а) я чертовски хорош и б) я работаю быстро. Если я сделаю за час то, на что другому понадобится три, в итоге вы заплатите меньше.
Я пользуюсь таймером и точно замеряю время, потраченное на работу. Серьезно. Я нажимаю «start», когда запускаю редактор, и «stop», как только делаю коммит. Стоит мне отвлечься больше чем на 30 секунд — и я ставлю таймер на паузу. Ежедневные отчеты (автоматические, разумеется) позволяют клиенту отслеживать стоимость и планировать расходы.
Я благороден и не стану завышать цену. А ведь я мог бы! Я владею знанием предметной области, и могу утверждать, что провел за работой два часа, хотя сделал ее за час. Я мог бы втиснуть дюжину лишних часов каждый месяц, но игра не стоит свеч. Моя репутация ценнее, чем любая одноразовая сумма денег. Довольный клиент даст мне рекомендации и посоветует меня своим знакомым, и любое подозрение в нечистоплотности эту перспективу разрушит.
Прежде чем начинать любое задание, я дам вам оправданную оценку его трудоемкости. Если в какой-то момент я пойму, что задание займет больше времени, чем я предполагал, я предоставлю вам полную информацию о вариантах действий и вы примете решение. Вам не нужно беспокоиться о скрытых расходах: я буду держать вас в курсе о предстоящих работах, и позволю вам решать и расставлять приоритеты. Я не исчезну на месяц, чтобы вернуться с готовым проектом и потребовать плату за месяц.
Оценка каждого задания будет не больше 4 часов. Это самое сложное: если я подозреваю, что что-то займет больше 4 часов, я ставлю «неизвестно». Представьте, что вас попросили покрасить комнату неизвестного размера — любая оценка потраченного времени будет случайной. В случае с программированием мне нужно будет потратить некоторое время на планирование и обдумывание решения до того, как оценить его трудоемкость — и за это время вы тоже платите.
Данный конкретный клиент понял это очень быстро, и теперь он дает мне очень подробные спецификации, описания данных, даже макеты интерфейса. Таким образом он сокращает свои расходы и следит за тем, чтобы насаждение возможностей не погубило его проект. Последнее очень важно — любой клиент мечтает о большом будущем для своего приложения, и он будет все время требовать новых улучшений под предлогом того, что их необходимость следовала из его набросков. Если вы назвали фиксированную цену и даже написали детальное техзадание, вам придется на каждом шагу бороться с ним, доказывая, что вот этого в задании не было! С почасовой оплатой вы можете сказать «ок, давайте я оценю, во сколько это вам обойдется» — а там пусть клиент сам решает, стоит ли оно того.
В процессе разработки любого продукта почти наверно возникнут непредвиденные проблемы, не заложенные в изначальную оценку работ. Есть два пути их учета — закладывать их стоимость в бюджет с самого начала (и либо клиент переплачивает за что-то ненужное, либо разработчик живет в постоянном страхе превышения бюджета), или же быть честным с клиентом и позволить ему принимать решения, чтобы он платил больше только когда это действительно необходимо.
Ключевые элементы моего подхода — ежедневные результаты, постоянное общение и доверие. Я верю, что это позволяет клиенту получить лучшие результаты за минимальные деньги, а мне — уверенность в том, что я не буду работать за еду из-за неудачной оценки бюджета проекта.
Я тоже так хочу!
P.S. Главное, не давайте читать эту статью своим знакомым стоматологам…
Недавно ко мне обратился мой первый потенциальный клиент, который хотел добавить несколько возможностей в небольшое приложение на Django. Я огласил свою часовую ставку, чем крайне его шокировал — он-то хотел услышать фиксированную цену за нужные ему доработки. Что из этого получилось? Мы работаем вместе, он очень доволен как результатами, так и суммами, которые он на них тратит, а я не поступился своими принципами оплаты. Вот аргументы, которые я использовал в защиту мнения о том, почему почасовая ставка лучше для всех заинтересованных сторон — может быть, они помогут кому-то еще.
Я люблю сравнивать разработку программного обеспечения с возведением здания, начиная с пустого земельного участка. Процесс выглядит примерно так:
Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?
Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?
Я стою XX $/час. Я могу потратить 2-3 часа бесплатно на оценку того, что вы хотите получить. После этого я начну брать деньги, даже за пятиминутный телефонный разговор. Правило простое: если я делаю что-то, чего я не делал бы, не будь вашего проекта, вы за это платите.
Мой клиент был в ужасе. Первое, что он сказал — XX $/час — это слишком много! Потом он напомнил о других разработчиках, которые потратили его время и деньги и не сделали ничего полезного. В чем-то он был прав — откуда он мог знать, что может мне доверять? На это у меня тоже был готов ответ.
XX $/час кажутся большой суммой, но а) я чертовски хорош и б) я работаю быстро. Если я сделаю за час то, на что другому понадобится три, в итоге вы заплатите меньше.
Я пользуюсь таймером и точно замеряю время, потраченное на работу. Серьезно. Я нажимаю «start», когда запускаю редактор, и «stop», как только делаю коммит. Стоит мне отвлечься больше чем на 30 секунд — и я ставлю таймер на паузу. Ежедневные отчеты (автоматические, разумеется) позволяют клиенту отслеживать стоимость и планировать расходы.
Я благороден и не стану завышать цену. А ведь я мог бы! Я владею знанием предметной области, и могу утверждать, что провел за работой два часа, хотя сделал ее за час. Я мог бы втиснуть дюжину лишних часов каждый месяц, но игра не стоит свеч. Моя репутация ценнее, чем любая одноразовая сумма денег. Довольный клиент даст мне рекомендации и посоветует меня своим знакомым, и любое подозрение в нечистоплотности эту перспективу разрушит.
Прежде чем начинать любое задание, я дам вам оправданную оценку его трудоемкости. Если в какой-то момент я пойму, что задание займет больше времени, чем я предполагал, я предоставлю вам полную информацию о вариантах действий и вы примете решение. Вам не нужно беспокоиться о скрытых расходах: я буду держать вас в курсе о предстоящих работах, и позволю вам решать и расставлять приоритеты. Я не исчезну на месяц, чтобы вернуться с готовым проектом и потребовать плату за месяц.
Оценка каждого задания будет не больше 4 часов. Это самое сложное: если я подозреваю, что что-то займет больше 4 часов, я ставлю «неизвестно». Представьте, что вас попросили покрасить комнату неизвестного размера — любая оценка потраченного времени будет случайной. В случае с программированием мне нужно будет потратить некоторое время на планирование и обдумывание решения до того, как оценить его трудоемкость — и за это время вы тоже платите.
Данный конкретный клиент понял это очень быстро, и теперь он дает мне очень подробные спецификации, описания данных, даже макеты интерфейса. Таким образом он сокращает свои расходы и следит за тем, чтобы насаждение возможностей не погубило его проект. Последнее очень важно — любой клиент мечтает о большом будущем для своего приложения, и он будет все время требовать новых улучшений под предлогом того, что их необходимость следовала из его набросков. Если вы назвали фиксированную цену и даже написали детальное техзадание, вам придется на каждом шагу бороться с ним, доказывая, что вот этого в задании не было! С почасовой оплатой вы можете сказать «ок, давайте я оценю, во сколько это вам обойдется» — а там пусть клиент сам решает, стоит ли оно того.
В процессе разработки любого продукта почти наверно возникнут непредвиденные проблемы, не заложенные в изначальную оценку работ. Есть два пути их учета — закладывать их стоимость в бюджет с самого начала (и либо клиент переплачивает за что-то ненужное, либо разработчик живет в постоянном страхе превышения бюджета), или же быть честным с клиентом и позволить ему принимать решения, чтобы он платил больше только когда это действительно необходимо.
Ключевые элементы моего подхода — ежедневные результаты, постоянное общение и доверие. Я верю, что это позволяет клиенту получить лучшие результаты за минимальные деньги, а мне — уверенность в том, что я не буду работать за еду из-за неудачной оценки бюджета проекта.
Комментарий переводчика
Я тоже так хочу!
P.S. Главное, не давайте читать эту статью своим знакомым стоматологам…
