Сдельная оплата - зло?

Александр Чуркин (http://fokgroup.com)

Мысль о том, что программист не имеет права работать на ставке, я слышал еще будучи студентом магистратуры. Большинство заказов в ИТ выполняется сейчас по Fixed Price, т.е. заказчик перед началом работ требует точную оценку бюджета (и сроков) и не намерен потом платить больше. Оценка стоимости должна быть адекватной: не заниженной, иначе команда просто сработает в убыток, но и не завышенной – в этом случае клиент просто уйдет к конкурентам. Допустим, бюджет согласован, как избежать перерасхода средств? Если программист получает фиксированный оклад, он может и не спешить. Работа стоит, но месяц-то к концу подходит – скоро зарплата :)

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

На первый взгляд, у данной схемы достаточно плюсов. Клиент платит фиксированную сумму, компания получает четко запланированную прибыль, да и с мотивацией девелопера все нормально. Допустим, задача оценивается в 8 часов и оценка эта справедлива. Если разработчик сделает ее за 12 часов (поленится, отвлечется или просто сработает плохо), то получит он оплату только за ожидаемые 8 часов. Если же наоборот поднапряжется и сделает ее за 4 часа, то получит вдвое больше – опять же за 8 часов. Рисков для компании нет, а метод кнута и пряника на лицо.

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

Команда на тот момент была средняя по своей производительности – были хорошие разработчики, но были и очень непродуктивные, выполняющие задачи в 3-4 раза медленнее оценки. Причины медлительности были разные.

Некоторые ребята, увидев ответ интерпретатора «Поставь точку с запятой в файле index.php в строке 12, символ 34», могли часами анализировать причину неисправности. Так проходил месяц, другой, а умения так и не приходили. Скорее всего, в этом случае медицина бессильна – просто неверно выбрано место работы.

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

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

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

Хотя схема оплаты и защищала от больших убытков, двигаться вперед с такими сотрудниками было невозможно. Каких-то людей увольняли, кто-то сам уходил из-за недостатка финансирования, а мы старались искать только опытных и успешных разработчиков. Проводилось по 1-2 собеседованию в неделю (из кандидатов, уже прошедших жесткий отбор в кадровом агентстве), однако брали мы кого-то в лучшем случае раз в 4-5 месяцев. На сбор качественной команды разработчиков в итоге ушло около полутора лет, но получилась команда настоящих разработчиков! На этом этапе сдельная оплата и дала сбой…

Чем отличается программист от разработчика? Разработчик – птица высокого полета, человек, который может выполнять большой круг задач. Написание кода – лишь обязательная часть работы, разработчик умеет (и любит) писать документацию, заниматься тестированием, решать различные проблемы пользователей путем консультаций и предложений по улучшениям, а также генерировать разные идеи на пользу дела. Он изучает новые технологии и успешно их применяет.

Нет, это не тот парень, который пишет функцию и на этом останавливается. Что-то не то с интерфейсом? Это к дизайнеру. Уползло в верстке? Обратитесь к верстальщику. Как лучше сделать? Откуда я знаю – скажите мне четко, что и как, я сделаю.

Разработчики – очень ценные кадры, которыми должна дорожить любая адекватная компания. Так какие проблемы со сдельной оплатой?

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

Приемлемое качество

Жесткая оценка заставляет выполнять задачу в максимально сжатые сроки, при этом качество должно быть такое, чтобы «пипл схавал». Чем быстрее сделаешь – тем больше получишь, а вот качеству в данной схеме нет места, поскольку «вылизывая» проект от и до, разработчик тем самым тратит время, которое жестко ограничено. Получается, что более всего ценится быстрая и «сносная» работа. Хороший разработчик – это творец, желание сделать все как можно лучше и интереснее у него в крови.

Отказ от творчества

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

Снижение мотивации

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

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

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

 

Комментарии

Пастух Котов, 15.01.2011 21:48

вам неправильно кажется


Сергей, 24.02.2011 15:16

Статья хорошая. Стресса в нашем мире итак хватает, а вот с творчеством - дефицит.


Timur, 25.02.2011 07:08

Очень интересная и актуальная статья. В общем и целом - согласен с выводами автора.


Timur, 25.02.2011 07:11

Однако, фраза "Правило нанимать осторожно, а увольнять быстро" --- весьма спорная.


Сергей, 09.03.2011 21:38

Вопрос поставлен верно. Но можно другой подход. Разделим население на 4 группы-1,2,3,4. Представители группы 4-бомжи и им аналогичные, интереса к ним нет, они так или иначе паразиты, люди вне общества. представители группы 3 - уровень развития низкий, самооценка неадекватная, словарь в районе 20 слов, без надсмотрщика работать не могут, для ИТ ессно не интересны. Интересны только группы 1 и 2. Группа 1 - ЛЮБОПЫТНЫ, часто авантюристичны, высокоразвиты, адекватная самооценка, умеют ЧИТАТЬ и УЧИТЬСЯ, работают самостоятельно, увлекающиеся. Но - нестабильны, то взлеты, то падения, хандра. Немогут делать однообразную работу. нет творчества-сдохнет. Новая работа-сделает с интересом, еще раз эта работа-найдет что-то новое,сделалает быстрее или лучше, на третий раз энтузиазм пропадет, на 5-7 может заболеть, запить...Но! Именно эта группа создает правила, по которым живет весь остальной мир. И, по большомусчету, первые работают за интерес, а не за деньги. Группа 2 - их можно назвать исполнителями, адекватная самооценка, стабильны, работают самостоятельно, не любопытны, достаточно высокоразвиты, не любят создавать правила, хорошо учатся, если их учить. Сами учатся неважно, но и этому можно научить. Комбинировать группы? С 4 можно комбинировать только гробокопателей. С 3 комбинировать 2 в качестве надсмотрщиков, 1 с ними подохнет. Комбинировать есть смысл 1 и 2, на одного 1 двух 2. Если у вас работа на три человека и вы поставите трех первой группы или трех вторй - провалите работу. Три первых сделают самую сложную часть работы, а на оставшуюся мене творческую потеряют интерес. три вторых просто не сделают самую сложною работу. А вот когда первый и два вторых-первый упрется до изнеможжения решит самые сложные вопросы и затем, в изнеможжении передаст пищу и естафету двум вторым, которые при его подсказках, помощи, обучении будут четко, стабильно выполнять задание. Первый будет отдыхать и накапливать энергию для следующего раза и походу дела помагать вторым, в том числе и учиться на их ошибках. Первые учатся на своих и чужих ошибках! Остальное можно домыслить по ходу. Или на мыло [email protected] Сразу ответ не гарантирую, зыглядываю не каждый день зы да вот еще, на глаз кривой выпуклый группа 1-20% населения 2-30% 3- 30% 4- 20% для нас в совке, за бугром что то похожее


x, 01.04.2011 13:47

Работать на зарплату в частной компании это рабство и тупик для творческих людей


black knight, 07.04.2011 06:56

И где же опыта набрать тем начинающим?


ST, 09.08.2011 22:58

black knight верно подмечено)


Всеволод, 28.10.2011 07:59

Сергей, 09.03.2011 21:38 ... Одно могу сказать :- "БРАВО!".


Александр, 30.11.2011 19:07

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


Ксения, 18.12.2012 10:46

Абсолютно и полностью согласна с автором статьи! Как с позиции работодателя, так и нанимателя. Не бывает сдельной оплаты в нашей сфере!


Олег, 22.04.2015 13:30

Повною мірою підтримую автора, гібритна оплата є оптимальною для розробника в ІТ-галузі, бо це правильно, але хто буде оцінювати творчість та виконану добре роботу? Діло в тому, що добра, якісна робота дійсно є якісною, але добру роботу можна зробити швидше без документації, бо біля 40% часу при розробці йде на документацію і це така рутинна робота, що дійсно мало кому подобається, от тому і программісти пишуть код без документації і деякі пишуть програми досить геніально. Сергей, від 09.03.2011 21:38, написав тоже дуже корисні речі, бо творчі люди або справжні програмісти мало дають часу для документації і тут треба розділювати частку роботи на менш талановитих, але стабільних особистостей, тому Сергій і запропонував розділити категорії творчих людей та схильних до точності й стабільності, які корисні для написання документації, відповідно до розрахованного часу на ті чи інші дії. Статья є досить корисною та актуальною, бо дійсно сфера ІТ має поділ і є різні люди в плані психології і колектив повинен набиратися з урахуванням цих факторів.

 

Оставить комментарий

Имя:
Комментарий:
Проверочный код Сменить картинку