А я их мочу. Очень помогает.

2009-10-29 13:43:47 2282

Недавно мой знакомый поинтересовался у меня:

«Какие сейчас считаются нормальными наценки на программистов? Если человек знает, сколько я получаю на него у заказчика, то какую долю нужно ему платить так чтобы это считалось «честно»? Заказчик финансирует проект из своего кармана»

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

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

Далее оказалось ещё интереснее, выяснилось, что ни одного успешного проекта, в котором наемный работник знал бы изначальную цифру, нам не известно. Людей элементарно душит жаба работать за 15-35% входных денег, в результате они остаются без работы (т.к. ясное дело что сами не найдут и на столько), а у нас портятся отношения с заказчиками из-за проваленных проектов, в результате мы и сами можем оказаться без работы... Предложить же 70% человеку неразумно - так как тогда он просто наймет еще кого-то, просто потому что лень свойственна всем, нанять кого-то на 50% своих денег он сможет легко, и идея получать столько же сколько обычно, но ничего не делая - мегапривлекательна для любого - и цепочка удлинится до состояния полной неуправляемости, и проект точно будет провален.

Может возникнуть возражение, что логичнее ставить задачу иначе: нужно сделать "от сих до сих" в такие-то сроки, с такими-то оговорками/ограничениями. Стоить будет столько-то. Кто возьмётся?

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

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

Крайне важным также является вопрос ментальности - я понимаю, что русский никогда не будет платить по часам. Просто потому, что привык к кидалову, и думает, что ему нарисуют часов и кинут. С другой стороны, работая по оценке, он рассчитывает кинуть сам.
Меня иногда просят сделать оценку, я говорю - "X в час", когда спрашивают "а всего скока"? Я, обычно думая 30 секунд, говорю - "от 20 до 100 килобаксов", даже особенно не задумываясь, что нужно сделать - потому что по факту все проекты которые доделаны, попадают в этот диапазон.

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

Спрашиваю у знакомого прораба: "Вот тебе сдавать завтра объект - а сантехник, который "ошибся в размере своего гонорара" - забил, и нет его, что ты делаешь?" - " А я их мочу. Очень помогает"

Действительно, почасовая работа должна быть более эффективна, чем с фиксированным бюджетом. К сожалению, для клиента, она всегда требует больших бюджетов. Эффективность для исполнителя определяется "неограниченным бюджетом", любая переработка - сто процентная доплата. Хочешь зарабатывать больше - работай больше. Получается довольно эффективная мотивация, направленная на качество работы, скорость исполнения в данном случае будет определяться профессионализмом исполнителя, которая обычно пропорциональна его ставке. Единственное необходимое условие для обеспечения действительно эффективной работы со стороны заказчика - микроменджмент, он не нужен только при 100% процентной уверенности в исполнителе и достаточно гибком бюджете. Он же решит проблему 90% выполненной работы и закончившимся бюджетом.

Что касается самой методики разработки, то все зависит от задачи. Уже отмечалось, что при написании подробной техдокументации на разработку, ее можно отдать студенту. Это действительно так, такая методика относится к "тяжелой разработке" (например RUP) и ориентирована на низко квалифицированных конечных исполнителей и высококвалифицированных проектировщиков, бизнес-аналитиков и т.д. Такой метод хорошо подходит для решения больших задач, в которых требуется разделение на множество исполнителей или, как уже отмечалось, на низко квалифицированных исполнителей, только при условии автоматизации устойчивых бизнес-процессов, или вынесении изменчивой части в настройки. Очевидно, что строгие рамки для проекта на пол года-год могут его просто сделать не актуальным, слишком быстро все меняется и должны меняться требования.

И в завершении дополнительный вопрос к размышлению.

Как вы поступаете, если задача носит слегка исследовательский характер - вероятность ее исполнения неочевидна, хотя, скорее всего, выйдет, а сроки исполнения - совсем непонятны?
В случае почасовки все очевидно - делаем пока заказчику не надоест платить или не получится. А как быть в случае зафиксированного бюджета?