Напишу ответ отдельным постом.
Надеюсь мой опыт будет полезен, а так же будет полезна обратная связь.
Дисклеймер: я руковожу компанией, которая занимается заказной разработкой и поддержкой ПО более 10 лет, и встречался со всевозможными вариантами работ, тарификаций, заказчиков, неудачных и успешных проектов .
Я бы выделили пять подходов к работе программистов и их оценке и оплате.
У каждого из этих подходов есть плюсы и минусы, как в сторону заказчика так и исполнителя.
С этим результатом труда программистов мы сталкиваемся чаще всего, большая часть используемых ПП в мире - это тиражные разработки. В них работа программистов и работа пользователей разделены максимально.
Требования к ПО диктует рынок и маркетологи, программисты работают по плану назначенному менеджером, зарплату получают согласно квалификации, востребованности и ситуации на рынке труда.
При этом сам продукт может быть как мегаприбыльным так и мегапровальным для компании, которая выводит его на рынок. С одной стороны эти провалы программистов не волнуют, с другой стороны и прибыли им не перепадают.
В этом случае очень много зависит от того, как компания разработчик видит развитие ПО, какие ставит задачи программистам, как взаимодействует с пользователями.
2) Индиразработка
Программист общается с сообществом и разрабатывает программу сам или очень ограниченными коллективом.
Требование к ПО формируется сообществом и личными вкусами программиста, большинство таких разработок остаются где-то на свалке, но некоторые (вспомним Майнкрафт) выстреливают, становятся хитами и приносят известность и богатство авторам.
Это не коммерческая работа в чистом виде, скорее специфическое творчество. И, как и с творчеством, результат сильно зависит от моды и от личности автора, вовлеченности аудитории и грамотной работе с аудиторией. Благо сейчас есть много краудфандинговых площадок, и талантливый и идейный программист может достичь финансового успеха этим путём.
3) Почасовка
Именно этот вариант описывает топик-стартер. Программист работает, а заказчик оплачивает эти работы по мере потребления ресурса, ресурс высчитывается в часах работы потраченных на проект.
У этой схемы есть несколько минусов:
1. У программистов разная квалификация, стек технологий, если один человек будет работать над задачей 5 часов, то другой может потратить 2 часа. И какой-то точной "линейки", которая поможет сравнить двух программистов, её просто не существует.
2. У программистов разный бэкграунд, что на длительном промежутке времени сказывается на продукте. Я встречал неоднократно такое - вроде и программист хороший, и цена адекватная и сработанность с заказчиком, но за 2-3 года разработки продукт заходит в такие дебри, что проще выкинуть всё и начать заново.
Почему так происходит? Потому что у одного человека работающего в потоковом режиме нет времени, желания, опыта окинуть разработку стратегическим взглядом, а у клиента часто нет системного понимания во что выльются те или иные архитектурные и стратегические решения при разработке.
Несколько небольших поворотов не туда, долгий и упорный труд разработчика и ПО начинает развиваться куда угодно, но только не в сторону достижения результата.
3. Требуется высокий уровень доверия. Как ты не отслеживай свои работы, как не веди трекер, есть у заказчика два неубиваемых аргумента:
- а почему эти работы заняли 2 часа? Вот тут написано "сделал то и вот это, а мой муж/сват/брат говорит, что на это максимум полчаса нужно!
- я смотрел, ваш программист был подключен ко мне всего час, а мышкой тыкал так и вовсе полчаса, почему я должен оплачивать 3 часа работы? полчаса я готов, а три это грабёж!
Как правило в такой ситуации очень помогает высокая документированность:
Чаще всего вот этих вот мер хватает, что бы убедить клиента, что работа велась, всё учтено и находится под контролем.
Но если клиент упёрся в эти аргументы, то либо его передавить и потерять как клиента, либо поддаться на шантаж и в дальнейшем получать торг по любому счету.
Если клиент согласен со счетами и актами и подписывает их из месяца в месяц, эта, идеальная в общем-то картина, портится тем, что постепенно взращивает наглость программиста. Появляется соблазн раздуть отчет по работам, включить побольше услуг, работать поменьше, получать побольше, это ведёт к застою в квалификации, снижению эффективности.
И рано или поздно такой путь приводит к потере клиента - просто приходит конкурент, который за тот же объем услуг, с той же квалификацией может выставить меньший счет (просто более современные методы, знания, платформа для разработки, выше квалификация и эффективность работы, лучше организованы процессы - выберите любой пункт) и у клиента наступает прозрение - как так, я столько лет платил ХХХ руб. за это, а мог бы платить ххх рублей! От такого почти невозможно отпетлять или отмазаться.
Вот с этими минусами приходиться бороться большую часть времени.
И, к сожалению, почасовка у нас в портфеле заказов занимает наибольший объем.
4) Типовые услуги
Выполняя большой объем работ от разных заказчиков приходит понимание, что какая-то часть их запросов, в общем-то, типовая.
В таком случае на помощь приходит типовой портфель услуг. Просто знаешь и заявляешь, что:
работа А - стоит 1 000 руб.
работа Б - стоит 2 000 руб.
работа В - стоит от 5 000 до 10 000 руб.
и т.д.
Сколько там внутри часов работы программиста - клиенту пофиг. Он платит за конкретную услугу и получает конкретный результат.
Клиент может сравнить эту услугу с конкурентами - включаются рыночные механизмы.
Исполнитель может эффективно монетизировать свой опыт и квалификацию - если ты выполняешь работу А за 1 час, потом набрался опыта и уже за полчаса - ты стал эффективней в 2 раза и получаешь за это достойную оплату, а при почасовке - ты или должен поднять часовую ставку (при этом работу Б и работу В ты как делал 2 часа и 8 часов, так и делаешь) или должен брать меньше за работу А, ведь ты выполнил её быстрее! Но это крайне нелогично!
Повышать свою эффективность при типовом портфеле услуг - это естественное желание исполнителя!
Клиенту проще согласиться со счетом в котором перечислены конкретные выполненные услуги, чем абстрактные 20-30-50 часов работы.
В стоимость услуги разработчик может спокойно заложить контрольные мероприятия и риски превышения трудоёмкости. Например если "работа В" требует 1 час руководителя отдела на код-ревью или на взаимодействие с менеджером/заказчиком - их можно спокойно заложить в себестоимость не раскрывая структуру себестоимости клиенту.
Кстати, если клиент видит структуру себестоимости и он достаточно въедливы, поверьте мне, он доебётся (а по другому не скажешь) до каждой строчки!
Типовой портфель услуг очень сложно сделать. В нашей работе одна и та же по описанию задача может очень сильно отличаться по трудоёмкости, ну например - разработать печатную форму. Это может быть как очень простая складская накладная, на что у программиста средней руки уйдёт час, с тестированием - полтора, так и очень сложная форма договора с динамическим условиями, несколькими таблицами, сложной вёрсткой - и такая работа может занять и 5 и 10 часов, а, учитывая согласования и особенности приёмки работ - ещё больше.
5) Проектная разработка
Именно тут происходит самая дичь. Я лично видел оценку работ, которую мои специалисты могли выполнить за 100 000 руб. с некоторым запасом на форсмажор, а другой участник рынка оцени эти же работы в 400 000 руб. и при выполнении превысил бюджет.
В проектных работах очень большую долю маржи приносит "рыночная сила" - чем ты более известный и опытный, тем больше цена для клиента будет отличаться от себестоимости работ, тем выше будут премии на проекте.
В свою очередь "рыночная сила" формируется из положительного имиджа, вложений в маркетинг и отраслевого опыта и специфики.
По большей части проектные команды со специфическим отраслевым опытом хорошо известны, их график расписан на 1-2 года вперёд, а ценник на их работу формируется в аукционном порядке.
Это связано с тем, что у проектной команды намного ценней их опыт удачных, а ещё больше неудачных проектов в данной сфере, чем сложный навык программирования или разработки ТЗ или менеджмента.
Самый дорогой проект который мы выполняли в сумме 800 тыс. руб. При этом я всё проклял что ввязался в это дело, заказчик систематически развивал требования, и, несмотря на то, что мы вместе с заказчиком готовили довольно подробное ТЗ, постоянно расширял разрабатываемый функционал. Были провалы и с нашей стороны в виде сдвигания сроков вправо и слабой коммуникации.
Эту работу мы довели до конца, но осталась взаимная неудовлетворённость.
Уверен, заказчик считает, что мы раздули смету и взяли с него х2 денег от первоначальной стоимости.
Я считаю, что за такой уровень отклонения от ТЗ и мозгоклюйства надо было брать раза в полтора-два больше.
А в целом в нашей отрасли стоимость проектов (с учетом оборудования, ПО и работ) колеблется от 200 тыс. до сотен миллионов руб.
