Программистский синхрофазотрон (часть 3).
Итак прошло фактически пол года, с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 1 и часть 2).
И вот пару дней назад у меня была битва в теннис с выдумщиком этой идей. Но, в отличии от того, что я писал в блоге (где я выступал за идею), в момент обсуждения с ним я был адвокатам дьявола и пытался запинать идею ногами. И вот результаты пинания идеи выкладывают тут.
Вкратце, для тех кто не читал обе части и не хочет туда лезть - идея была в сдельной работе внутри фирмы для программистов. Таким образом программисты могут работать гораздо эффективнее, так как видят прямую зависимость доходов от своей активности (в отличии от ситуации, когда программист сидит на ЗП и может копаться в инете, вместо того, чтобы делать дело). Ну и собственно говоря, ниже, выкладываю мои мысли почему компании массово не переходят на сдельную оплату (хотя вроде она должна быть гораздо более эффективная).
Итак начну из далека.
Пусть есть электрик Вася, сидящий на зарплате, и пьющий водку в рабочее время. И вдруг к этому Васе приходит белочка и он думает , а чего это я водку все пью, лучше бабла подзашибу. Но блин, даже если я начну вкалывать, то дай бог мне подымут зарплату на 20%, лучше я пойду к своему начальнику и скажу, мол давай работать сдельно. Так Вася и делает. Приходит к начальнику и говорит, так мол и так, с водкой завяжу, сдельно работать будем и тебе лучше (я в пять раз больше сделаю и качественней делать буду) и мне лишняя денюжка в кармане. Начальник чешет голову и говорит, ладно Вася - починка розетки - 5 рублей, починка короткого замыкания - 10 рублей, полная проводка квартиры - 100 рублей. Если у заказчика все после этого через неделю сгорело - то с тебя вычет в двойном объеме. Проходит год, Вася шустрит, иногда правда клиенты ругаются, но суммарно все довольны - Вася при деньгам, начальник троих других электриков уволил, так как Вася за троих справляется, клиенты - счастливы не нюхать перегар Васи.
История вторая - есть Петя строитель. Так же самая картина маслом, но пьет он не водку, а пиво. И договаривается за 1000 положенных кирпичей. Начальнику тоже по душе, чтобы Петя работал и компания на нем деньги делала. Да, и теперь кладет кирпич в три раза быстрее, и при этом теперь больше его построек соответствует ГОСТу 1274-32-12б по укладке кирпича.
История номер три - есть Коля, модный массажист, делающий все виды массажа начиная от Боливийского и заканчивая массажем под названием “Рессора Белаза”. Коля, правда пьет уже не водку и пиво, а коньяк (не меньше 3 звездочек), но это мало что меняет. И вот он приходит к начальнику и говорит, а давайте я буду работать сдельно и буду делать все массажи в 5 лучше и в 5 раз быстрее. И вот тут начальник, выпучив глаза, говорит Коле…. Коля, а с коньячком-то видно пора таки завязывать, ты что с дуба упал в 5 раз быстрее массаж делать? Да и как мы будет проверять, что ты в 5 раз качественнее массаж сделал? У тебя что же есть массажеметр? Так, что пойди ка ты Коля, отдохни немножко и с свежими мозгами назад на зарплате работать возвращайся.
Ну, теперь более серьезно. Какова разница между вариантом Васей, Петей и Колей? А разница то, что в первых двух вариантах есть достаточно простое количественное измерение (связанной с доходом) сделанной работы и определенный (разумно измеримый) качественный уровень. В третьем же варианте, хотя количественное измерение есть, но оно не связанно с доходом и качественного измерения нету.
И теперь мы наконец возвращаемся к нашим горе-программистам.
С одной стороны, программисты (включая меня) очень хотят чисто сдельную оплату. Причем не просто сдельную оплату (такую как имеют freelancer’ы), а сдельную оплату внутри фирмы, когда дополнительной работы по поиску клиентов, ведению бухгалтерии у них нет, а вот денег можно зашибить дофига, если ты достаточно эффективен.
Кстати, коротенькое замечание сдельная = fixed cost за задачу, а не почасовка. Почасовка - это фактическа зарплата, просто в зависимости от того, сколько отсидишь на работе. Концептуально почасовка не меняет отношения к тому на сколько быстро хочется решить задачу. Я бы даже сказал, почасовка наоборот двигает человека в направлении растягивания задач.
Так вот, возвращаясь к тому, что программисты хотят сдельную оплату. Есть исследования, которые показывают, что отличный программист может быть эффективнее среднего в 10 раз. Соответственно, перед глазами мелькают цифры с 5-6 нулями за год ![]()
И вроде все было бы хорошо, если бы не
- Отсутсвие типовых задач
Фактически сама по себе - это не проблема, но я покажу, во что оно выливается ниже.
Тот же электрик или строитель, да и даже массажист имеет вполне ограниченный набор типовых задач. Их может быть скажем сотня, но все таки сотня разных задач - это вполне разумное число. И эти задачи можно записать.
- Отсутсвие количественной оценки задачи
Вот это проблема, которая вытекает из первой. Так как типовых задач нет, то все задачи не типовые. Для типовых задач, даже если их нельзя оценить впрямую, то можно оценить чисто статистически, сколько они занимают и какую прибыль они приносят. В случае, если же задачи не типовые, то начинается проблемы с их оценкой. И дай бог, если задачу можно оценить каким-то разумным методом. В программировании же, оценка чаще всего очень эмпирическая и +/- 30% даже на небольших задачах считается вполне неплохой точностью. В добавление к этим проблемам, еще зачастую единственный человек который может дать оценку - является тот самым программист, работающий на проекте. И начальник никак не может проверить, дал ли он настоящую оценку или завысил ее в три раза.
Соответственно, начальник не может вывесить прейскуранта (как было сделано для Васи и Пети).
- Отсутствие измеряемого качества
Основным методом измерения качества программы (в основном) является оценка количества багов. С другой стороны, любой программист вполне может сказать, что программа может иметь сумасшедшие проблемы с внутренним качеством (архитектурой) и при этом иметь не так много найденных багов. И может быть наоборот, множество мелких багов, при том, что внутренняя структура достаточно нормальна.
Итого, суммируя три вышеперечисленных проблемы. Программист, который от компании хочет полностью сдельной оплаты, похож на того массажиста (давайте я буду делать массажи в 5 раз лучше и 5 раз быстрее). Вроде как и пожелание разумное, но до тех пор пока не изобретут массажеметр или программистозатратометр, то фактически все параметры работы являются субъективнымы, так как и оценка размера задачи и оценка качества программы не является объективной величиной.
И поэтому в ушах начальника это звучит так “Давайте я увеличу мое субъективное вложение в 5 раз, а вы мне увеличите объективную зарплату в 5 раз”. Так в жизни не бывает, что субъективное оценивается равным объективному. И кстати, именно поэтому хорошие программисты получают зарплату в 2-3 раза больше средних, а не в 10. Так как они только субъективно в 10 раз эффективнее, и то непонятно по чьим измерениям, когда же субъективное конвертируется, то на выходе получает большая в 2-3 объективных раза зарплата.
Фух… Что-то я начал запутываться, но думаю вы меня поняли. Вся проблема именно в отсутствии объективных оценок. Поэтому думаю к такому виду сотрудничества как я писал в первых частях - IT бизнес таки не придет.
Воооот… Ну и очень хотелось бы услышать ваши мнения, комментарии и идеи.
Дополнение N1: Итак, давайте, оценку = estimate из понятия абстрактного (а-ля сферический конь в вакууме) переведем на понятие реальное. Есть конечный человек которые делает оценку задачи.
Ситуация 1. Оценку делает менеджер, которые с кодом не работает. Я не верю, что человек не работающий с проектом может дать насколько нибудь разумную оценку.
Ситуация 2. Оценку делает каждый для себя. В таком случае, люди могут завышать оценку, тем самым выбивая деньги из фирмы.
Ситуация 3. Оценку делает team lead или другой опытный разработчик имеющий большой опыт на проекте. Это достаточно разумная практика, но в ней есть две проблемы. Даже team lead не дает точную оценку и очень обидно будет программистам, которые недополучат денег из-за ошибки team lead’а. Вторая проблема, что ситуация 3 вырождается в ситуацию 2 для самого team lead’а. То есть самый опытный человек делает оценку для самого себя и может ее завышать.
Учитывая, что весь этот сыр бор с программистским синхрофазотроном обсуждается именно для самых толковых программистов, то Ситуация 2+3, крайне важна. Непонятно, кто будет оценивать оценку team lead’а.
Дополнение 2. У многих возникает удивление. Типа, если программисты станут в 3 раза быстрее работать, какого фига они сейчас так не работают. Так что, эти заразы, работают не на полную мощность.
Так вот, как руководитель и программист в одном лице скажу, да, программисты практически всегда работают не в полную силу. Кстати и не только программисты. Фактически в любой профессии если человек не дикий трудоголик то он в конечном итоге работает по возможному минимуму. И фактически все программисты - на работе читают блоги, смотрят YouTube, переписываются по ICQ с знакомыми. И это на самом деле выходит за рамки - передохуть подумать.
Но эта ситуация устраивает работодателя, так как он знает, если программиста выгнать, то другой будет делать тоже самое. Может если на рынке будет кризис, то тогда программисты поднапрягутся, а так просто люди сидя на зарплате не видят смысла вкалывать.
Есть такая штука называется estimation, что по русски говоря оценка работы. Т.е опытный специалист (который знает толк в коде, он уже в конторе 2-3года, где косяки могут быть и тд),оценивает задачу по часам. Программист выполняет эту задачу приблизительно за это время. За неделю идет отчет - в котором, проект, задача, затраченные на это часы. Сразу предвидя вопрос, мол разные задачи бывают, как оценивать? А очень просто - это работа руководителя проекта, он то и распределяет работу. Есть такая еще система как review кода, крендель делает кусок кода, закидывает его в cvs к примеру, а тот человек который имеет статус review кода (можно сказать у него высокий скилл и экспириенс :), да статус review кода надо еще заслужить, опять же опыт) проверяет всё это дела, если косяк - обратно кодеру. Вот.
Несколько “НО”, которые ломают эту стройную идею.
а) Оценка задач чаще всего не слишком точна.
б) Обычно одни люди оценивают, другие делают. Что умноженное на а) еще больше усугубляют ситуацию.
в) Руководитель проекта, если он менеджер, то он не может оценить задачу, так как кода она не знает. Есть руководитель проекта - team lead, то возникает ситуация, что он может сам себе оценивать задачи (читай ставить им любую стоимость).
Кстати во всех статьях про синхрофазатрон идет речь именно о хороших/лучших программистах, которые как раз и окажутся вероятнее всего в позиции людей, которые оценивают задачи.
Соответственно они могут оценить их в 5 раз больше, если они захотят.
Насчет ревью кода, не совсем понял, к чему это относится….
Кстати, еще то что я говорил (наверное к чему был code review), что проблема контроль качества. Опыть же, кто будет проверять качество самых лучших программистов.
То есть получается, что вроде можно сделать сдельную оплату, но как раз средним программистам (которые в этом не так сильно заинтересованы). И для них она будет не слишком объективная, а субъективная относительно того, как хороший программист оценит задачу.
Кстати, через такую систему я проходил на своей первой работе. И честно говоря, я был не слишком счастлив и как программист и как team lead.
Я ввел у себя на фирме для некоторых людей и некоторых задач сдельную оплату. Перед распределением задач мы каждый кусок работы обговариваем и следим что бы он был не больше нескольких дней. И фактически оплачивается estimations стоимости работы, сдлеланная исполнителем
Что хорошего
- мини-ТЗ и планы стали действительно вестись аккуратно, так как без них не будет оплаты
- если человек уверен в то, что надо делать так как он говорит, а не так как я — то пусть сам и проверяет на его ответственность. Т. е. я не трачу время на то что бы заставить человека что-то сделать
Что плохого
- приходлится проверять задачи и результаты иногда бывают неутешительными. То есть на проверку надо дополнительные ресурсы
- так получается, что человек который сидит на сдельщине, чуть ли не автоматом исключается из внутренних разработок и проектов (которые могут принести прибыль потом) и работает на обслуживании текущих источников прибыли. Мотивации обучаться чему-то новому у него особой тоже нет.
Очень интересный опыт из жизни.
Ту сдельщину, которая я проходил, была не слишком приятная и в общем-то не позволяла получить больше.
По этому поводу пару вопросов:
А кто у вас называет конечную цифру, сколько стоит задача?
Я имею в виду, если называет начальник и оказывается неправ (занижает размер), как это решается?
Если подчиненный называет цифру, как начальник решает проблему, если ему кажется, что она завышена?
Насколько большой получается overhead?
- мини-ТЗ
- оценка задач
- тщательный контроль
И последнее самое важное. Если кто-то вдруг работает очень хорошо и эффективный, если метод заработать скажем в 2-3 раза больше чем на зарплате (в чем должна быть основная забавность хорошей сдельной работе).
1 overhead по mini-TЗ
у разных людей по разному. С моекй стороны в целях сдачи-приемуи практически не изсменился
(Хотя я должен уделять этому больше времени — уже был косяк из-за нечеткиз формулировок)
А програмисты - есть один который говорит что полдня соствляет, а другой за 15 минут/полчас во время/непосрелдственно после нашего с ним разговора.
Но там еще и специфика работы. Скажем что у нас на сдельной оплате — в большинстве совем отчеты. Еще у нас бывает “мини-ТЗ” с таском “написатьт ТЗ или UCS по такой-то фиче”
2. оценка задач — у нас совмещена с (1) и лежит на исполнителе.
3., Контроль — я бы оуенил как 1/8 - 1/16
Хотя тоже завист от задачи: есть вещи которые проверить сложно, а есть еще вещи (и именно такие вещи в большинстве своем отдаются на сделбную оплату) где критерием приемки является подпись клиента
Что касается эффективности - ну как бы да, но не знаю точно. Дело в том что есть как-бь разработчкики которым интересно ращраьатывать и которые понимают бизнес-часть, а есть разроаботчкик которым инетересно написать для клиена максимум отчетов и внедлрение и получитть за это максимум денег.
Эффективные как-бы первые; но на сдельщине сидят преимущественно вторые, А первым
я не могу платить огромные зарплаты, так как именно прибыли они не приносят - это инвестиции в будущее. Тут по идее должен работать механизм совместного инвестирования (или опционов) но там свои нюансы, в которые сейчас углубляться нецелесообразно.
Ну и очевидно, что если на сдельщину переведено, к примеру, составление custom отчетов, то чем больше заработает работник, тем больше заработает и фирма — так что нам выгодно что бы сдельные работники зарабатывали как можно больше - мы же платим им деньгами клиентов. С одной стороны. C другой стороны есть проекты с первышением бюджета, которые нам невыгодны но которые все равно надо делать. И там тоже отчеты есть., А еще есть клиенты которые легко т ратят деньги и тяжело.
А вобще — тут такая отдельная сложная тема — мне кажеться что рассматривать и говорит эффективно/неэффективно абстрактно вобще нельзя — это зависит от бизнес-модели фирмы и
от того, как именно деньги поступают на фирму, как мы определяем внешнюю стоимость работы и как они распределчются. Скажем, в аутсорсинге цена для клиента опредлеляетс по нормочасам (тогда вобще непонятно какая сдельная оплата) а в продуктовом производстве при разработке чего-то нового как правило есть как минимум три стороны, в переговорах между которыми определяется цена. И тогда можем ли мы тогда позволить конечным программитстоам участвовать в ценообразовании ? Если да, то через какие мезанизмы ?
А еще есть люди которые хотят код писать и не влезать во все эти бизнес-вопросы.
То есть какая-то модель таки оформляется постепенно, но она далеко не тривиальная и
в двух словах ее описать сложно.
ok. Понял.
Я бы сказал, что та часть, что например сдельщиков на внутренние проекты не посадишь в основном базируется на том, что чаще всего внутренние проекты не имеют четкого бюджета.
Если бы бюджет был, то оно не сильно отличается от внешних проектов.
Кстати, насчет почасовой работы на заказчиков. Это действительно хорошее замечание. И кстати, ситуация с этим очень-очень похожа на программиста сидящего за ЗП. С одной стороне вроде фирме говорят - сделайте побыстрее, с другой стороны, а нафига фирме делать быстрее если оплата за часы. Получается что фирма делает с минимальной скоростью, чтобы ее не выгнали (точно как программист).
Четкий бюджет есть - просто рейт там ниже внешнего. И есть люди которые во внутренних проектах стараюбтся не работать.
Понял.
Мини ТЗ уже попахивают XP. Если говорить о estimation то как раз на маленьких поделенных задачах отдельно и можно судить о настоящей проделанной работе.
По поводу проверять лучше довериться отделу качества(QA) если он есть, если нет, то лучше его создать.
>- так получается, что человек который сидит на сдельщине, чуть ли не автоматом >исключается из внутренних разработок и проектов (которые могут принести прибыль потом) >и работает на обслуживании текущих источников прибыли. Мотивации обучаться чему-то >новому у него особой тоже нет.
А вот это 5.
P.S. по поводу самого поста, мне кажется понять какой программист приносит большую прибыль будет видно адекватными глазами всегда и без всяких оценок качества или скорости написания.
>мне кажется понять какой программист приносит большую прибыль будет видно >адекватными глазами всегда и без всяких оценок качества или скорости написания.
Ситуация такова, что адекватные глаза - это очень субъективное понятие. И его очень тяжело выразить в числовом эквиваленте.
Для сдельной оплаты, именно нужны точные цифры.
Ведь, электрику нельзя сказать, что за одну ррзетку мы тебе дадим то ли 1 рубль, то ли 5 рублей, от того, как там нам в душе будет казаться, хорошо ты работал или нет.
Если нет адекватных глаз, то товарищ скорее всего уйдет с компании в компанию где эти адекватные глаза имеются. По поводу сдельной оплаты не забывайте что самое главное, товарищ должен быть доволен выделенной для него оплатой.
Да, субъективное восприятие оплаты важнее объективных цифр.
Но с другой стороны, когда разница между зарплатами в одном месте и другом месте становится серьезная, то люди готовы плевать и на адекватные глаза и на много чего еще.
Все таки, как жестокий меркантилист, я считаю, что самое важное в работе/бизнесе - это деньги. Остальное - приятный добавок.
То есть на остальное обращают внимание, когда разница оплаты в одном месте отличается от другого не слишком сильно.
Я о том же:)
По выносу из внутреннего процесса раработку
Тут надо учесть что у нас не все работы, а часть (определенного типа) сдельные.
По идее лечиться это должно какими-то методами совместного инвестирования в разработку, но многие люди просто не хотят инвестирвать в развитие и получать виртуальные деньги, когда можно получить сейчас и реальные (почему и выключаются из процесса)
Насчет вовлечения программистов в инвестирование. Дело, как по мне, неблагодарное. Основная идея наемной работы - уменьшение рисков. Если человек готов инвестировать, то он и сам бизнес сможет стартовать.
Ну с одной стороны да, с другой — опционы общеприщнанный элемент мотивации, а это от опционов мало чем отличается кроме оформления
мы стараемся делать это инвестирование как можно менее напряжным: по системе [которая еще не формализированна до конца но будет формализироваться и внедряться в этом году] у меня на внутреннюю разработку можно будет делтать по рейту чуть меньшему чем на внешнюю, разница этих рейтов (не так уж что бы очень большая) и является то, что инвестируется. (потом эти деньги возвращаюбтся любдям как проценты от продаж ) Риск для работкника небольшой (то есть максимум что потеряет - пару сотен долларов). Более того - никто не заставляет челоовека работать по меньшему рейту если у него есть работа по большему. Естественно работа за меньшний рейт (”со встречным планом”) имебт преимущество (при распределении задач менеджером этого проекта.).
Опционы - с одной стороны общепринятый элекмент. С другой стороны я уже где-то писал, что обычно это издевательство а не мотивация.
Вот типичный случай для США.
Условно говоря, опционов у работника 30 тысяч. В компании выпущенно ну скажем 100 млн акция. Цена компании при продаже ну скажем 50 млн. Это значит, что получается (в хорошем случае, если опциони отконвертят 1 к 1) 15 тысяч.
Дальше, опционы надо выкупать в течении 3-4 лет.
Итого 15 тыс мотивировки делим на 3-4 года. Получаем мотивировку в 5 тыс.
При зарплате в $100k (вполне реалистичная цифра), мотивировка получает 5% от ЗП, которые могут выплатить через 3-4 года.
В общем от этого не тепло не холодно.
Ага — да, интересно — я думал там доля опционов чуть больше.
В общем-то бывает и побольше, но это скорее если прийти в стартам 5-м, и старпат взлетает вверх.
Если же приходишь 20-м или 100-м, то по большему счету уже стать богатым (та ладно там богатым, даже просто приятную прибавку) не светит не при каких раскладах.
Есть правда еще одно исключение, если прийти на позицию CEO, СTO или что-нибудь такое.
Но, в общем-то это и логично. Если каждому программисту выдавать 1% фирмы (что вроде не так много), то через 100 человек выдавать будет нечего :))
Интересный подход. В принципе в какой то конторе встречал подобное построение и эта фирма вроде как плодотворно работает таким образом. Другое дело, на такое будут согласны лишь определенного качества люди…
Мне кажется тут проблема не в том что трудно оценить сроки и результат. И то и другое поддается оценке, иначе бы не было фрилансеров в принципе.
Как верно подметил RSSH, человек на сдельной оплате выпадает из жизни компании. По сути дела это фрилансер, который занимает табуретку в здании фирмы. Его бесполезно мотивировать и вклад его ограничен. Он не перепишет какой-то модуль, не оформит набор функций в библиотеку, не напишет инструкцию по найстройке.
Посмотрим с другой стороны. Если у вас есть работник, который в состоянии работать в два раза лучше, либо он саботажник и его надо гнать, либо у руководства проблемы с мотивацией сотрудников и организацией труда. В обоих случаях каши не сварить.
Кстати, открываю глаза на реальное устройство мира: парикмахеры, маникюрши, массажисты и том подобная публика всегда сидят на сдельщине. На окладе никто из них не сидит - это и им невыгодно, и работодателям.
Ну я просто несколько лет работал в этом бизнесе. Типа, я в теме.
Так вот, люди эти еще как не выпадают из жизни компании: живут полной жизнью.
Да или чтоб парикмахеров в покое оставить - все сотрудники служб сбыта ровно так же сидят на процентах с продаж. Они что, тоже не участвуют в жизни компании? Или не кормят отделы маркетинга и аналитики данными по своим регионам?
yurich,
ваша ошибка в том, что вы правильные слова в неправильный блог пишете. У IT бизнеса есть определенная специфика и рассуждения о реальном устройстве мира здесь не катят.
Спасибо конечно, что открыли глаза. Я на самом деле не знаю как работают парикмахерские и пока этим не интересуюсь.
Самая большая ошибка ИТ-специалиста - он вдруг начинает считать, что он избранный, особенный и его работа - она не такая же, как работа прочих подлых людишек.
Считать так - заблуждаться в полный рост и сидеть в #опе.
Специфика, безусловно, есть в любой работе: и у маникюрши, и у дровосека, и у программиста. Кто на что учился, как говорится. Кто дрова рубить, кто в сишарпе кодить.
Но так и что с того? ИТ-специалисты не хотят жрать? Им не нужна крыша над головой? Чистая одежда им противопоказана? Деньги для них не главное? Типа, как Виктор Цой в фильме “Асса” - “он музыкант, на белом свете живет”?
Ой как сильно сомневаюсь. Бабло эти люди хотят получать то же самое, что и дровосеки с маникюршами, жрут ту же еду, что и бухгалтеры с сантехниками, да и в метро ездят не особом ИТ-шном, а в том же, что и помянутые тут электрики.
Более того, бизнес, который зависит от ИТ, очень сильно хочет, чтоб ИТ-специалисты были предсказуемы, понятны, чтоб можно было прогнозировать будущее, планировать траты и чтоб не оказаться в заложниках у собственного ИТ-подразделения, если оно вдруг начнет мудить по полной программе.
Ну а потому, собственно, и бизнес начинает ставить задачи измеримые и контролируемые в плане качества, и успешные ИТ-подразделения - все меньше трещать про свою особость.
Нет никакой особости. Специфика есть, да. Но нет ничего, что противоречило бы рассуждениям о реальном устройстве мира.
И про блог - мне нравится читать Виктора, он интересно пишет. Почему бы и не поучаствовать в дискуссии, раз автор не против? Я ж никогда и никому не навязываю свою точку зрения, но у меня она есть и я не против ей поделиться.
>Нет никакой особости. Специфика есть, да.
С этим согласен.
А вот с остальным не согласен. Я имею в виду, достаточно иметь особенности, чтобы структура IT плохо вписывалась в обычные бизнес модели.
Кстати, именно из-за этих особенностей с одной стороны не удается сделать нормально проекты гигантам типа IBM (они по большему счету завалили OS/2, который им стоил миллиарды долларов). С другой стороны, компании за 10 лет становятся крупнейшими в мире (Google).
В общем я к тому, что нельзя мерять одной линейкой и думать, что одни и те же модели сработают для парикмахера, электрика, программиста и художника.
Вы привели неплохие примеры
То, где орудовали программисты, провалилось - ярким тому примером провал OS/2.
Где к выпуску программного продукта подошли, как к выпуску обычного консьюмерского продукта, с маркетологами и исследованиями на фокус-группах, с безжалостной отгрузкой рекламного говна в мозг потребителю, с навязыванием и халявой - все прекрасно удалось. Вспомните успех Win9x в сравнении с технически более совершенной OS/2. Первая была кривая, косая и дырявая. Но ее продавали, как пластинки поп-звезд и кока-колу. И ура, все получилось. Неудобная и некрасивая полуось издохла.
А зверский успех AOL, раздававшей тестовые дискеты, так же, как раздают жевачку и пакетики с шампунем?
Все это иллюстрирует тезис, что когда к ИТ относятся так же, как и к любому другому бизнесу, успех более чем вероятен.
А когда начинают гундеть про совершенство кода и про особость ИТ, добром это кончается редко (желающие могут сравнить провал Cybico и успех iPhone)
Хм… По моему все наоборот..
OS/2 - это был большой проект в IBM в котором была куча специалистов по бизнесу и они рулили проектом. Программисты там были исполнителями.
А Google стартовали программисты, а только потом подтянулась бизнес часть.
Хотя можно легко найти примеры и в другие ворота.
Я не говорю, что IT не вписывает не в какие модели. Но модель продаж подержанных авто отличается от модели ведения IT бизнеса.
>А когда начинают гундеть про совершенство кода и про особость ИТ
Осторожнее на поворотах
Гундеть = беспокоиться. Есть множество проектов, где плохое качество способно убить проек.
И все таки, может особости нет, но специфика есть.
Мой мозг безнадежно испорчен курсами ITIL - тренеры с утра до вечера твердят, что основная ошибка ИТ - воспринимать себя в отрыве от бизнеса и верить в свою особость.
У ИТ есть своя специфика и свои процессы - so what? Свои процессы есть и у HR и у бухгалтеров, и у юристов. Никто ж там не твердит про свою особость, люди просто работают.
Да, кстати, я не устаю напоминать: я не программист. Я работаю в областях ИТ-инфраструктур и ИТ-саппорта. У нас есть своя специфика
Мы куда проще поддаемся процессному подходу. Но я вижу соседей из отдела разработки, они тоже вполне работают по планам и пишут тайм-шиты, по которым их работа и оценивается (не целиком, но бонусная часть - вся)
И еще про особость: давно уже подметил, что ИТ-команду, работающую под девизом “Мы - особые люди, без нас тут все развалится” - надо гнать из конторы немедленно. Вот просто пинками и мокрыми тряпками. В 100% случаев за этим скрывается печальная истина, что все сделано безобразно криво и неумело, и только те, кто делал, имеют представление, как поддерживать тонущий пароход на плаву.
>основная ошибка ИТ - воспринимать себя в отрыве от бизнеса и >верить в свою особость.
Да, это ошибка.
>Да, кстати, я не устаю напоминать: я не программист. Я работаю в >областях ИТ-инфраструктур и ИТ-саппорта. У нас есть своя >специфика
Мы куда проще поддаемся процессному подходу.
ok. Как не для программиста. Я например не слишком хорошо знаком с ИТ-инфраструктур и ИТ-саппорта.
И представим, что я попытаюсь перенести свой опыт на эти области и скажу, что-нибудь типа:
А какого хера сеть раз в неделю падает. Вон мы один раз написали программу и при одних и тех же условиях она работает без сбоев.
На что вероятнее всего логичный ответ будет. Милок… Твою программу ногами никто не бьет, а вчера когда сеть упала, Вася в серверной комнате разбушевался и уронил сервак.
К чему это я. Например физическое вмешательство актуально для инфраструктуры и не актуально для программ.
Точно так же, один тип мотивирования может быть актуален для парикмахеров и не актуален для программистов.
Поэтому я повторюсь. В отрыве от бизнеса никто об ИТ не говорит, никто не говорить о какой-то выделенности и особости.
Но, все говорят о специфике. Этот пост о специфике мотивирования и сдельной оплаты для программистов.
Не вижу тут ничего жуткого.
) Посмотрим с другой стороны. Если у вас есть работник, который в состоянии работать в два раза
) лучше, либо он саботажник и его надо гнать, либо у руководства проблемы с мотивацией сотрудников
) и организацией труда. В обоих случаях каши не сварить.
Вот тут “в два раза лучше” - логическая ошибка. Там не велична а вектор и проекции по разным осям могут раз в 10 отличаться
rssh,
я не совсем понял про вектор. Допустим у вас есть сотрудник, который может писать код в два раза быстрее без ухудшения качества. О чем это говорит?
Перевести его на сдельщину и платить ему в два раза больше я считаю неправильным. При правильной мотивации он и так должен работать со скоростью близкой к максимальной.
1. Допустим у вас есть сотрудник, который может писать код в два раза быстрее без ухудшения качества. О чем это говорит?
Быстрее кого ? Или себя же бещ сдельщины ?
2. При правильной мотивации он и так должен арблотать со скоростью блищкой к максимальной.
Тут я просто предложение не понимаю. Что значит “правильная мотивация” ? Финансовая мотивация правильная или нет ? Если да - то чем плоха сдельная работа как мотиватор.
И если будет только нефинасовая мотивайия а з/р существенно ниже рынка, то конкуренты предложат емку заметно больше и он уйдет)
То есть я боюсь меня сейчас забанят за коммунизм, но мы должны говороить о справедливом методе определения стоимости труда программиста (ладно, можно “справедливый” заменить на “приводящий к cубоптимальной стратегии”, не баньте) который бы отражал разницу в произволитеольности и колебания рынка. Одним из таких методов для некоторых задач может быть сдельная оплата
>Быстрее кого ? Или себя же бещ сдельщины ?
В моем посте именно быстрее себя без сдельщины. В то время, когда он раньше броузил web - он решит работать. И ему будет гораздо интереснее найти как и где он еще сможет 10-15% времени экономить и что ему нужно выучить чтобы стать еще быстрее.
>То есть я боюсь меня сейчас забанят за коммунизм, но мы должны говороить о >справедливом методе определения стоимости труда программиста (ладно, можно >“справедливый” заменить на “приводящий к cубоптимальной стратегии”, не >баньте) который бы отражал разницу в произволитеольности и колебания рынка. >Одним из таких методов для некоторых задач может быть сдельная оплата
Банить не буду. Наоборот поддержу.
Именно это мы и обсуждаем. Ищется некая субоптимальная стратегия, которая
а) Для компании будет выжимать максимум результата (уменьшать сроки) при не увеличении затрат
б) Для программиста позволит, получать деньги в прямую связанные с количеством исполненной работы.
Ничего общего вроде это с коммунизмом не имеет.
Попробую привести пример более детальный.
Есть программист, получающий хорошую зарплату, немного выше средней по индустрии. Пусть это будет $100-120K в год в Штатах. Работает хорошо, что сказано сделать за 6 месяцев - за 6 месяцев и делает.
Тут выясняется что при переходе на сдельную оплату он делает шестимесячный план за 3 месяца без ухудшения качества.
О чем это говорит? Что ему нужно платить в два раза больше, чтобы он работал как умеет?
Вставлю 5 копеек.
Лучше говорить не о одном, а о 10 программистах. И вот если они все двое увеличат эффективность (предположим что мы таки нашли метод это честно мерять) - то им таки нужно платить вдвое больше.
Если же 9 человек увеличили эффективность на 20%, а один в два раза. То вероятнее всего тот, который увеличил в 2 раза - дико халявил раньше. И вот тут вопрос, что с ним делать дальше.
1 Он через 6 месяцев не увольняется нафиг ?
2 А у фирмы есть столько клиентов что бы его загрущить ?
3 Если (1) и (2) - то что, получается при потоках работ которые налдо сделать его менеджер не определил что человек может работает быстрее ? тогда конечно к нему (менеджеру) будут вопросы И это маловерочяно
(Вот тут позволю себе не согласиться с Виктором и сказатиь что по моему опыту — люди у которых интерес к работе сохранился - показывают хлорошую проищволительность независимо от з/р. Единственное что им надо — это
уверенность в том что, человек который их работу оценивает - не обманывает и прлатит где-то как в среднем по отрасли. Если у них есть бищнес-метка, имеет смысл
вводить их в долю в продукте. [как раз то инвестирование] А те, у кого и нтереса нет — вот им такие схемы мотивации и нужны, но работают они все равно хуже чем первые.
rssh,
Я не вижу ответа на свой вопрос. Вижу только встречные вопросы. Повторю свой вопрос.
“Есть программист, получающий хорошую зарплату, немного выше средней по индустрии. Пусть это будет $100-120K в год в Штатах. Работает хорошо, что сказано сделать за 6 месяцев - за 6 месяцев и делает.
Тут выясняется что при переходе на сдельную оплату он делает шестимесячный план за 3 месяца без ухудшения качества.
О чем это говорит? Что ему нужно платить в два раза больше, чтобы он работал как умеет?”
О чем вам говорит вышеописанная ситуация.
Ну тогда прямой ответ - ни о чем, так как ситуация слишком обще-сформулированна (и в зависимости от ответов на приведенные вопросы, может говорить о абсолютно разных вещах, возможно противоположных)
>При правильной мотивации он и так должен работать со скоростью близкой к >максимальной.
Правильная мотивация - это какая?
Люди обычно работают ровно с такой скоростью, чтобы их не увольняли. Это гораздо меньше чем максимальная.
Плюс, если человек знает метод, как увеличить свою продуктивность в 2 раза (например, прочев дополнительной литератури и пойдя на курсы) то это сейчас в этом не так чтобы супер сильно заинтересован (так как о повышении ЗП в 2 раза и речи не будет).
По моему личному мнению правильная мотивация это набор следующих факторов:
- интересные проекты
- работа в команде с толковыми людьми, у которых можно поучиться
- наличие плана карьерного роста
- доля в компании
- бонусы за хорошо выполненные проекты. Бонусы должны быть незапланированными и отражать реально хорошую работу.
Разумеется все это работает на фоне хорошей основной финансовой компенсации, не ниже средней по отрасли и региону.
Другими словами “отдельно взятая финансовая компенсация не работает”. Всегда найдется кто-то предложит больше и разработчик сбежит срывая сроки и унося с собой знания.
Насчет хорошей мотивации - согласен. Это действительно хорошая мотивация
Но в каждом пункте есть проблемные места:
>- интересные проекты
Многие продуктовые фирмы работают только над одним продукто-проектом.
И людям зачастую остывают через некоторое время
>- работа в команде с толко