1) Тиражная разработка

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

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

При этом сам продукт может быть как мегаприбыльным так и мегапровальным для компании, которая выводит его на рынок. С одной стороны эти провалы программистов не волнуют, с другой стороны и прибыли им не перепадают.

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

2) Индиразработка

Программист общается с сообществом и разрабатывает программу сам или очень ограниченными коллективом.

Требование к ПО формируется сообществом и личными вкусами программиста, большинство таких разработок остаются где-то на свалке, но некоторые (вспомним Майнкрафт) выстреливают, становятся хитами и приносят известность и богатство авторам.

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

3) Почасовка

Именно этот вариант описывает топик-стартер. Программист работает, а заказчик оплачивает эти работы по мере потребления ресурса, ресурс высчитывается в часах работы потраченных на проект.

У этой схемы есть несколько минусов:

1. У программистов разная квалификация, стек технологий, если один человек будет работать над задачей 5 часов, то другой может потратить 2 часа. И какой-то точной "линейки", которая поможет сравнить двух программистов, её просто не существует.

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

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

Несколько небольших поворотов не туда, долгий и упорный труд разработчика и ПО начинает развиваться куда угодно, но только не в сторону достижения результата.

3. Требуется высокий уровень доверия. Как ты не отслеживай свои работы, как не веди трекер, есть у заказчика два неубиваемых аргумента:

- а почему эти работы заняли 2 часа? Вот тут написано "сделал то и вот это, а мой муж/сват/брат говорит, что на это максимум полчаса нужно!

- я смотрел, ваш программист был подключен ко мне всего час, а мышкой тыкал так и вовсе полчаса, почему я должен оплачивать 3 часа работы? полчаса я готов, а три это грабёж!

Как правило в такой ситуации очень помогает высокая документированность:

• переписка через почту

• записи телефонных разговоров

• трекинг задач

• надзор руководителя

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

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

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

И рано или поздно такой путь приводит к потере клиента - просто приходит конкурент, который за тот же объем услуг, с той же квалификацией может выставить меньший счет (просто более современные методы, знания, платформа для разработки, выше квалификация и эффективность работы, лучше организованы процессы - выберите любой пункт) и у клиента наступает прозрение - как так, я столько лет платил ХХХ руб. за это, а мог бы платить ххх рублей! От такого почти невозможно отпетлять или отмазаться.

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

4) Типовые услуги

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

В таком случае на помощь приходит типовой портфель услуг. Просто знаешь и заявляешь, что:

• работа А - стоит 1 000 руб.

• работа Б - стоит 2 000 руб.

• работа В - стоит от 5 000 до 10 000 руб.

• и т.д.

Вот плюсы:

1. Сколько там внутри часов работы программиста - клиенту пофиг. Он платит за конкретную услугу и получает конкретный результат.

2. Клиент может сравнить эту услугу с конкурентами - включаются рыночные механизмы.

3. Исполнитель может эффективно монетизировать свой опыт и квалификацию - если ты выполняешь работу А за 1 час, потом набрался опыта и уже за полчаса - ты стал эффективней в 2 раза и получаешь за это достойную оплату, а при почасовке - ты или должен поднять часовую ставку (при этом работу Б и работу В ты как делал 2 часа и 8 часов, так и делаешь) или должен брать меньше за работу А, ведь ты выполнил её быстрее! Но это крайне нелогично!

   Повышать свою эффективность при типовом портфеле услуг - это естественное желание исполнителя!

4. Клиенту проще согласиться со счетом в котором перечислены конкретные выполненные услуги, чем абстрактные 20-30-50 часов работы.

5. В стоимость услуги разработчик может спокойно заложить контрольные мероприятия и риски превышения трудоёмкости. Например если "работа В" требует 1 час руководителя отдела на код-ревью или на взаимодействие с менеджером/заказчиком - их можно спокойно заложить в себестоимость не раскрывая структуру себестоимости клиенту.

Кстати, если клиент видит структуру себестоимости и он достаточно въедливы, поверьте мне, он доебётся (а по другому не скажешь) до каждой строчки!

Минусы? Они тоже есть.

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

5) Проектная разработка

Именно тут происходит самая дичь. Я лично видел оценку работ, которую мои специалисты могли выполнить за 100 000 руб. с некоторым запасом на форсмажор, а другой участник рынка оцени эти же работы в 400 000 руб. и при выполнении превысил бюджет.

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

В свою очередь "рыночная сила" формируется из положительного имиджа, вложений в маркетинг и отраслевого опыта и специфики.

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

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

Самый дорогой проект который мы выполняли в сумме 800 тыс. руб. При этом я всё проклял что ввязался в это дело, заказчик систематически развивал требования, и, несмотря на то, что мы вместе с заказчиком готовили довольно подробное ТЗ, постоянно расширял разрабатываемый функционал. Были провалы и с нашей стороны в виде сдвигания сроков вправо и слабой коммуникации.

Эту работу мы довели до конца, но осталась взаимная неудовлетворённость.

Уверен, заказчик считает, что мы раздули смету и взяли с него х2 денег от первоначальной стоимости.
Я считаю, что за такой уровень отклонения от ТЗ и мозгоклюйства надо было брать раза в полтора-два больше.

А в целом в нашей отрасли стоимость проектов (с учетом оборудования, ПО и работ) колеблется от 200 тыс. до сотен миллионов руб.

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

Анализируем системную часть для себя

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

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

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

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

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

// Начало документа

Почасовая работа программиста

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

Ставка в час: 1500 руб.

Рабочие часы в неделю: 40 часов, в месяц 160 часов.

Итого в месяц: 1500 x 160 = 240 000 руб.

Поэтому сейчас так все стремятся стать программистами, тратят много денег на курсы, а уж про конкурс в технические ВУЗы и говорить не приходится. Спрос на специалистов в этой сфере огромный.

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

Мое предложение состоит в следующем:

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

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

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

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

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

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

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

Пример таблицы с отчетом по времени

В примере отражена схема работы с предоплатой на неделю за 10 часов работы. Этого вполне хватает, чтобы плавно вести проект. Тут заказчик платит 15 000 руб. в неделю или 60 000 руб. в месяц.

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

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

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

// Конец документа.

Да это получилось продающее коммерческое предложение. Отсюда клиент узнает выгоды, которые он получает за свои деньги. Многие возражения снимаются. Вроде описаны очевидные вещи, но магия случается именно тогда, когда эти очевидности перечисляются по пунктам и стороны принимают их.

Вывод

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

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