Итак прошло фактически пол года, с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 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 раза и речи не будет).
По моему личному мнению правильная мотивация это набор следующих факторов:
— интересные проекты
— работа в команде с толковыми людьми, у которых можно поучиться
— наличие плана карьерного роста
— доля в компании
— бонусы за хорошо выполненные проекты. Бонусы должны быть незапланированными и отражать реально хорошую работу.
Разумеется все это работает на фоне хорошей основной финансовой компенсации, не ниже средней по отрасли и региону.
Другими словами «отдельно взятая финансовая компенсация не работает». Всегда найдется кто-то предложит больше и разработчик сбежит срывая сроки и унося с собой знания.
Насчет хорошей мотивации — согласен. Это действительно хорошая мотивация
Но в каждом пункте есть проблемные места:
>- интересные проекты
Многие продуктовые фирмы работают только над одним продукто-проектом.
И людям зачастую остывают через некоторое время
>- работа в команде с толковыми людьми, у которых можно поучиться
Согласен — это всегда приятно.
>- наличие плана карьерного роста
Вот тут дело плохо. Очень как-то нестабильно в IT все идет.
Поэтому планов особо никто не строит. Через 2 года фирма может оказаться на коне или в банкротстве и зачастую это не предсказуемо
А сотрудники чаще всего через 2-3 года перекачевывают в другую фирму.
>- доля в компании
Разумную долю редко кто-то согласен дать. Стандартный option plan — это чаще всего просто насмешка. Из него можно получить только что-то если компания становится вторым Google.
>- бонусы за хорошо выполненные проекты. Бонусы должны быть
>незапланированными и отражать реально хорошую работу.
Вот это действительно отличная идея. Хотя опять же, лучше работает в малых фирмах.
Я написал дополнение 2 внизу статьи.
С одной стороны все работают слегка расслаблено и это принятое положение вещей.
А с мотивацией действительно проблем полно. Собственно говоря об этом и есть эта серия статей. Сложно быть мотивированным, когда можешь сделать в X раз больше для фирмы, только вот не получишь в X раз больше денег.
Например для sales есть вполне зависимость от продаж. И если за 100 продаж тебе дадут дополнительно 20 рублей, то за 1000 дадут 200 рублей.
> И то и другое поддается оценке
Поддается. Вопрос в погрешности и в том, кто оценивает.
Я в конце статьи написал добавление N1.
>ак верно подметил RSSH, человек на сдельной оплате выпадает из жизни компании. По сути >дела это фрилансер, который занимает табуретку в здании фирмы. Его бесполезно >мотивировать и вклад его ограничен. Он не перепишет какой-то модуль, не оформит набор >функций в библиотеку, не напишет инструкцию по найстройке.
Не согласен с этим. Он вполне таки напишит инструкцию и перепишет (за обсужденную плату).
С чем согласен, что полностью исчезает вне финансовая мотивация. Зато финансовая цветет и пахнет.
[…] Виктор Ронин рассуждает о планировании и оценке производительности программист…. […]
Верно подмечено. Абсолютно согласен
Уважаемый Виктор, есть вопрос. Я совершенно не программист и понятия не имею, чем это работа программиста так принципиально отличается от работы электрика, но вот какое у меня есть сомнение: Вы легко допускаете, что программист из Вашего примера работает 160 часов в месяц за фиксированную оплату (стало быть, Вы знаете, во что Вам обходится один час его работы), но при этом не готовы допустить мысли о переводе его на сдельщину.
На самом деле вопрос снимается сам собой, как только Вы начинаете учитывать задачи, которыми занимается программист, в течение, скажем пары-тройки месяцев.
Далее, полагаю, выяснится, что работа программиста это набор типовых задач, вполне формализуемых и по требованиям к качеству, и к срокам.
Вы, например, с легкостью допустили, что работа электрика может быть оплачена сдельно: 1 розетка — 5 рублей. Вы станете слушать электрика, который начнет говорить, что установка розеток это творческая задача, что одна розетка в деревянном здании на уровне 20 см от пола это одно, а на открытом складском комплексе на высоте 15 метров ночью в дождь это совсем другое, а в канализационном коллекторе — третье? Да фиг с ним, с экстримом, в бетонной коробк и бревенчатом деревенском доме это уже разные по сложности работы. Тем не менее, Вы допускаете возможность формализации задач и сдельной оплаты труда.
Полагаю, оплачивать сдельно работу программиста можно ровно так же: менеджер, опираясь на опыт и накопленную статистику, оценивает трудоемкость работы в человеко-часах и объявляет прайс заказчику и сроки — программисту. Ну а если программист на сдельщине — то еще и прайс.
Собственно, понятно, что никто не собирается говорить о фактически затраченном времени — беседа идет только о нормо-часах. Если программист провозится над задачей вместо часа пару дней, в случае сдельной оплаты труда это только его проблемы. Разумеется, мы исходим из предположения, что нормо-часы берутся не из головы Жанны Агузаровой, а по ранее накопленному опыту и по заранее известной всем сторонам таблице, с которой все эти стороны согласны.
Ну а стоимость часа программиста, как мы постановили, нам и сейчас известна
все очень красиво, только это не работает. и не потому, что работа программиста от работы электрика принципиально отличается, а потому что программирование не относиться к сектору реальной экономики. у электрика все просто — его результат виден, этот результат можно потрогать, этот результат можно увидеть и он зависит только от физических свойств проводки, напряжения в сети и качества сделанной работы. результата работы программиста увидеть и потрогать нельзя, на этот результат влияет множество факторов. работа электрика меряется прямым математическим исчелением, работа программиста — только статистическим. статистические пики в обе стороны будут всегда и их тоже нужно учитывать, тут проблема в том, что появление пиков предсказуемо только с вероятностью близкой к n%. тоже относится к эстимэйшинам, к качеству кода, к качеству продукта, к эфективности работы одного конкретного программиста.
я не говорю, что нельзя перевести программиста на сдельную оплату труда — можно, нужно только тчательно взвесить стоимость затрат на контроль этой схемы. в мелких и средних конторах цена подобного конроля сопоставима прибыли, в крупных — нет проблем с иерархической лестницей, а следовательно с качественным приростом зарплат. схема сдельной оплаты труда перестает быть нужной.
p.s. если программист провозиться с задачей вместо часа пару дней — это в любом случае его проблемы. потому что есть такая штука, как не оплачиваемый овертайм.
Антон, Вы так хорошо все расписали про работу электрика, мне все так понравилось. Мне, как обладателю действующей IV группы электробезопасности и как человеку, имеющему в подчинении двух электриков, все сразу стало понятно 🙂
Расскажите пожалуйста, а учитель может работать сдельно? Я вот на столбах вижу объявления про репетиторство — это сдельная работа? А ее можно оплачивать именно по достигнутому результату? Ну вот, например, если я договорюсь, что учитель проведет со мной цикл занятий по логарифмическому исчислению — это сдельщина?
>Расскажите пожалуйста, а учитель может работать сдельно? Я вот на столбах вижу >объявления про репетиторство — это сдельная работа? А ее можно оплачивать именно >по достигнутому результату? Ну вот, например, если я договорюсь, что учитель >проведет со мной цикл занятий по логарифмическому исчислению — это сдельщина?
Наемные учителя работают на почасовке, а не на сдельной оплате. Оплата была бы сдельная в том случае, если он получал бы оплату только когда вы пройдете экзамен.
Я не слышал о том, чтобы так учителя работали.
А тут когда как. Некоторые и в зависимости от результата оплату берут.
Это же, как и в случае с программированием — задача, где надо заранее договариваться о том, что считать результатом и что — справедливой оплатой труда.
Вот например меня учитель будет учить, а я не сдам экзамен — иными словами, качество работы преподавателя не пройдет контроля внешним аудитом — почему я должен платить?
Я не имею своего мнения о том, хорошо учитель меня учил или плохо, я не специалист. Но экзаменатор показал, что я ни фига не знаю предмета — возможно, что вместо курса высшей математики учитель полгода учил меня нотной грамоте — это что, работа, за которую я должен платить?
Полагаю, к варианту отношений программиста с заказчиком Вы приведете тему сами.
Ведь всё то же самое: менеджер или заказчик — они далеко не всегда имеют детальное представление о специфике работы программиста. Это не значит, что менеджера надо менять, а заказчик — лох, которого не жалко.
Это значит, что надо вводить прозрачные и понятные обеим сторонам критерии оценки качества и стоимости выполненных работ.
Иначе конфликты сторон будут неизбежны.
>А тут когда как. Некоторые и в зависимости от результата оплату берут.
Вы с такими работали?
Я нет и никогда даже такого не слышал.
Потенциально можно конечно договорится, но уверен, что учитель сразу очень серьезно поднимет цену, так как на него ложатся много рисков — что человек просто не захочет сдавать экзамен, что человек окажется полной тупицей и не поддающимся обучению и т.п.
У меня жена — бизнес-тренер, владелец своей маленькой тренинговой конторки.
На 100% результат не коммитится, конечно, но отчет работодателю-заказчику о том, что именно усвоили обучаемые за его счет граждане есть стандартная услуга.
И в общем поскольку подъем идет с повторных продаж, можно говорить о том, что имеет место оплата в зависимости от результата.
Впрочем, Вы перевели тему. Вот как оценивать работу специалиста, если сам не разбираешься в его работе?
Я бы сказал есть серьезное отличие между бизнес-тренером и наемным преподователем скажем математики.
>На 100% результат не коммитится, конечно, но отчет работодателю-заказчику о том, что именно усвоили обучаемые за его счет граждане есть стандартная услуга.
Отчет о усвоенном и гарантия результата — две большие разницы.
>Впрочем, Вы перевели тему. Вот как оценивать работу специалиста, >если сам не разбираешься в его работе?
>Это значит, что надо вводить прозрачные и понятные обеим сторонам >критерии оценки качества и стоимости выполненных работ.
С заказчиком все проще. Для заказчика важен только вход и выход.
Если при интересующем его входе получается интересующих его выход, то все отлично.
И это легко описывается user case.
Например для авто, меня интересует чтобы я нажимал на газ — оно ехало быстрее (причем плавно), на тормоз — тормозило и т.п.
Но в этом смысле заказчик относится к системе как к черному ящику.
А вот менеджер и программист не могут относится к системе как к черному ящику.
Так вот, для того же авто, когда оно разбивается на подсистемы, очень четко известно что каждая подсистема должна делать. И даже по ходу разработки мотор не станет работать как система для подкачки задних колес.
А вот в программировании разбивка на подсистемы (особенно когда доходит до мелких деталей) абсолютно не интуитивна. потому что нету (и не будет) настолько накатанной архитектуры, как например в авто.
Поэтому даже хороший менеджер с трудом может оценить (правильно) задачи программиста. Более того, даже хороший программист не всегда может оценить задачу из чужого проекта.
Одна из стандартных принятых схем — оценка по test case. Проблема с этим что оно выявляет только внешнее качество (как черного ящика) + test case редко покрывают разумный процент возможных внутренних состояний системы.
Один из примеров. Представьте, вас завтра сажают управлять проектом связанным с изменением генокода. Даже те, кто это делают не представляют как и что пойдет. Вы же не только не представляете, вы еще и не понимаете, что же толком и как они делают. Как можно в таком случае оценить работу?
Где-то также (согласен, не так плачевно) дело обстоит на множестве IT проектов.
Это я к тому, что есть то над чем работает специалист, уже сто раз обкатано, то оценить легко прогнав через определенные (уже тоже обкатанные тесты). Если это что-то не обкатанное и не разбираешься в специфике — то оценить фактически нереально. Единственное можно нанять друг(ого/их) специалистов и верить их мнению по поводу первого.
Юрий (?) к чему такой сарказм? я ведь не пытаюсь Вас учить Вашу работу. ассоциация Ваша. разумеется и в Вашей работе есть масса тонкостей мне не известная. предлагаю перестать меряться знанием предметной области, в которой каждый из нас работает. возможно Вы отлично знаете и свою и мою — готов признать Ваше превосходство и прекратить дискуссию — только скажите.
суть в другом. но сначала отвечу на Ваш вопрос. учитель наверное может работать сдельно. в этом случае либо его услуги должны стоить очень дорого, либо он заработает крайне мало. плюс он берет на себя риски, с преподаванием материала никак не связанные — желание и мотивацию ученика, его моральное и физическое состояние во время экзамена, не способность ученика коммуницировать… наверное потому я не встречал таквых учителей. деньги беруться за время. и я отдаю себе отчет почему.
теперь вернемся к суть. суть не в том, что электрик может, а программист не может работать сдельно — оба могут. просто для контроля работы электрика требует намного меньше затрат, чем для контроля работы программиста, как мне кажется. поправьте меня если я ошибаюсь.
>Вы начинаете учитывать задачи, которыми занимается программист, в течение, скажем пары-тройки месяцев.
>Далее, полагаю, выяснится, что работа программиста это набор типовых задач, вполне >формализуемых и по требованиям к качеству, и к срокам.
Собственно это я в посте и писал, что задачи не типовые и их очень тяжело перевести в численное измерение.
>Вы станете слушать электрика, который начнет говорить, что установка розеток это >творческая задача, что одна розетка в деревянном здании на уровне 20 см от пола это одно, >а на открытом складском комплексе на высоте 15 метров ночью в дождь это совсем другое, а >в канализационном коллекторе — третье?
Уже кому-то отвечал. Что для электрика 90% задач связанными с розетками — 20 см от пола в типовых зданиях. Если он работает на предприятиях, то 1 метр от пола.
Для программистов настолько типических задач нету.
>менеджер, опираясь на опыт и накопленную статистику, оценивает трудоемкость работы в >человеко-часах и объявляет прайс заказчику и сроки — программисту.
Для IT, сроки и стоимость указанная менеджером — лучший путь завала проекта. В отличии от не IT области, менеджер чаще всего не способен точно (даже +/- 50% оценить задачу).
>известной всем сторонам таблице, с которой все эти стороны согласны.
Я дорого отдал бы за то, чтобы иметь такую таблицу. Человек который ее изобретет, станет миллиардером сходу.
> Я дорого отдал бы за то, чтобы иметь такую таблицу. Человек который ее изобретет, станет миллиардером сходу.
Артемия Лебедева ждут миллиарды: http://www.artlebedev.ru/kovodstvo/sections/148/
Не вижу таблицы, вижу обсуждение вслух той же проблемы о которой говорим мы.
Введена странная единица измерения, которую не саму измерять нельзя толком, ни ней измерять объем работ.
Фактически это метод «функциональных точек» придуманный Барри Боемом (он кажется тогла в IBM работал)
http://en.wikipedia.org/wiki/Function_point
На практике в бизнесе применяется мало из-за трудоемкости. Какое-то время был обязателен в NASA,. Общепризнанно, что его использование лучше, ч ем считать по LOC-ам.
Честно говоря, что-то статья какая-то тяжкая… мозг не переварил ее.
То, что мне бросилось в глаза, что она user oriented measurement. То есть, с точки зрения нужна функция А и функция Б и то и другое будет считаться единицей. С точки зрения программирования — это не значит, что на них потратиться одинаковое кол-во времени/затрат.
да, хороший метод. и действительно практически неподъемный для конторы, размером по-меньше NASA. я полагаю ни один из ИТ-бизнесменов не отказался бы от введения таковой процедуры, если его спонсором выступал бюджет США 🙂
Люди, а в чем метод состоит. Я трижды перечитал статью в wikipedia и что-то не вкурил…
Ну как-бы если очень-очень-очень грубо — то это можно описать как количество requirements на которые специально обратили внимание (специально подумали). (и они не обязщатьельно были записаны)
Более или менее нормальное изложение на русском (или украинском, не помню точно) я видел в учебнике Молодцовой по програмной индженерии
URL так с зоду не приведу — хотя наверное найти русское описание довольно легко по фразе «метод функциональных точек»
Ясно. Надо будет как-нибудь глянуть.
Я оценивал по ФТ около 5 проектов в среднем на каждый по 4-6 человеколет. Предварительно составив историческую базу сделанных проектов естественно, чтоб было по чем калибровать. Расхождения оценок с реальным выполнением составили до 10%. Так же, чисто для себя — проверить точность и достоверность метода, оценивал уже сделанные проекты, когда базу нарабатывал, расхождение составило до 15% (в среднем 10 %где-то) на 7 проектов.
Следует так же помнить что не все задачи этим методом можно оценить, например всякие визуальные редкторы оценивать — неблагодарное и трудоемкое дело и вносит изрядную долю субъективизма в оценку.
Если интересно, могу скинуть учебник как эти точки считать.
Так же рекомндую Стива Макконнелла «Сколько стоит проект», а так же его бесплатную программу Construx Estimate, собственно в ней и делал оценки.
Кинь пожалуйста учебник на vronin at consultant.com
Хотя у меня специфика проектов в том, что многие из них системные были. И с точки зрения количества функций предоставляемых пользователю — их тяжко оценивать.
Здесь не путаем функциональные точки с количеством функций? 🙂
Имхо, системные проекты даже легче оценивать, количество легковыявляемых связей больше.
Та похоже путаю 🙂
Считая количество функций можно получить количество ФТ.
как и в системе уравнений — одно можно опреобразовать в другое без проблем, вот только надо ли? 🙂
В общем, требую учебник на стол, чтобы разобраться, что там количество функцию, а что там ФТ и тому подобное 😉
у Темы есть немногим меньше. а если посчитать чистые активы — т.е. стоимость бизнеса и брэнда, я думаю что как минимум один он получит. а может и полтора.
Имхо, если установка розетки «на высоте 15 метров ночью в дождь» стоит столько же, сколько и «в деревянном здании на уровне 20 см от пола», то именно вторым большинство электриков и предпочтет заниматься. А в канализацию вообще никто не полезет.
И если с розетками все более-менее наглядно и очевидно, то объяснить заказчику почему похожие с его точки зрения задачи требуют в разы различающегося времени — не так просто.
Гм… И часто электрикам надо на высоте 15 метров ночью в дождь ставить розетки.
Я бы сказал, что для электрика — типовые задачи 90% и 10% не типовые.
Для программиста фактически понятие типовых задач отсутствует.
Проект может быть типовой, но даже в нем задачи не слишком типовые.
Victor Ronin, вы очень правильно выделили то, что задачи нетиповые. Однако, мне кажется, при этом надо выделять отдельно estimate и отдельно сложность задачи.
Возьмем еще один пример с копанием дядей Васей траншеи. В такой ситуации в любое время я могу сказать, что время до окончания работы = (оставшиеся кубометры)/(выем кубометров в час). Более того, это означает так же, что если дядя Вася будет копать в 2 раза быстрее (и это *можно* замерить!), то работа будет окончена в 2 раза быстрее.
В случае с программированием это не так — я даже не знаю, чем мерять возросшую продуктивность. В линиях кода? Это зло и очень плохо — будет копи-паст. В затраченных часах? Так сотрудники будут сидеть в интернете. Так что идея повышения прибыли пропорционально повышению производительности упирается в то, что это повышение нечем замерить; так что объективного способа померять прирост продуктивности просто нет, хотя есть некоторые мотивационные инициативы — премии, например.
Так что вывод такой — estimate есть, но «нелинеен»; сложность задач в т.ч. и субъективна; измерение прироста производительности упирается в отстутвие методики измерения этой самой производительности.
P.S. В аналогии с копанием траншеи есть еще один плюс — там мы всегда сможем сказать, где наш вышестрадальный землекоп Вася начал работать «на износ», т.е. сверх плана и для себя. В случае с программистами — если те повысят производительность, у руководства возникнет резонный вопрос — а что ж они раньше так не работали, если могут?
как это нечем? у фирмы есть очень классный интегральный показатель — приход.
я, конечно, утрирую, но если работа человека продаётся лучше — значит он производительнее.
естественно, если убрать утрирование, то тут возникают проблемы уравниловки (продаётся проект, а не 1 человек, кроме случаем, когда проект = 1 человек) и прочее и прочее.
Собственно говоря, если утрирование и убрать, то тот же самой доход фирмы, даже с одного проекта размазывается на 4 программистов, менеджера, админа настраивающего им компа и т.п.
Выделить из этого сколько полагается Васе, а сколько Пете — будет тяжело. На сдельной оплате же люди будут не в восторге от уравниловки.
не-не-не. то, что у обслуживающего офис админа задачи типовые никто спорить не будет? так вот пойду дальше и скажу, что задачи, которые приписаны к роли МЕНЕНДЖЕР тоже типовые, точнее гораздо более типовые, чем у програмера.
поэтому в случае с одним програмером не проекте всё прозрачно: вы вкидываете туда сколько то оценённого эффорта (то, что продали), програмер делает это за сколько-то реального эффорта. ему идёт как за оценённый.
все в плюсах.
как только их двое+ и их квалификация различна, то начинаются проблемы…
Да, согласен оценить overhead на проекте не сложно.
Кстати, никогда не задумывался, что в нормальной ситуации, действительно у менеджера задачи более типовые чем у программиста.
Увы, действительно разделить даже между 2 программистами — откровенно тяжко.
Собственно говоря, я об этом и говорю. Проблема, что задачи толком неизмеримы и прирост эффективности из-за этого и не измерим.
Насчет, того, что они делали раньше. Я написал дополнение 2 к статье.
не буду много писать
но честно говоря насколько мне известно ИТ довольно таки точная сфера, по-этому можно все же выработать ряд типовых задач, участков работы и договорится об оплате выполнения задач…
в целом идея очень интересная и актуальная, даже уверен рабочая, но естественно, не для всех областей можно применять 🙂
Почему вы считаете, что IT довольно точная сфера?
Я бы сказал, что информатика (особенно вычислительная) довольно точная наука.
Но, вот как по мне IT не слишком точная сфера. Да, есть некоторое количество людей делающие похожие (даже не одинаковы) задачи.
Тем не менее огромная часть IT работает по
а) над задачами, которыми они раньше не работали
б) без нормальной постановки задачи
в) давая очень неточные estimat’ы
г) на ходу обнаруживая непредвиденные сложности
д) споря о том, что есть баг, а что новая функциональность
е) не имея полного плана тестирования и критериев оценки качества
Я думаю я мог бы все это дальше продолжать.
Но суммирую, IT не слишком точная область. Скорее IT похоже, на 100 художников, которых приглашают разрисовывать то здание на базаре, то Секстинскую Капеллу, то квартиру новому русскому. Вроде и задача одна и та же, но вот четко сказать, что и как должно быть в каждый следующий раз тяжело.
для продуктовой конторы я бы даже предложил больше — выделить одно ядро и расшерять плагинами-дополнениями. нарисовать с 10 библиотек, решающих типичные задачи и использовать их. даже фреймворк свой можно сделать. да что там, и первыя, и вторая, и третья идея рализовывались на практике 1001 раз.
что делать аутсорсерам? у которых
1) код принадлежит заказчику. можно тупо поднять параллельный репозиторий, но реиспользование на уровне исходного кода — это копипаст кода в проект. плохая идея.
2) любая типичная задача решается по-новому. может случится все, что угодно — от интеграции с очередной легаси-системой, до желания заказчика видеть получамый продукт именно в в таком виде.
3) времени, на создание фрэймворков, библиотек и даже поддержки параллельного репозитория нет. либо мы работаем, либо отдыхаем. можно пожертвовать отдыхом. но наш труд все-равно принадлежит конторе и за него не станут платить. я как-то не привык заниматься благотворительностью в таких объемах.
Н-да, изложение Спольски только своими словами 😉
Это он у меня списывал 😛
А если серьезно, то с одной стороны, конечно я его читал. С другой стороны было это давно и писал я пост не по его книге/блогу.
Просто проблема животрепещущая, поэтому все ее задевают.
> Ситуация 2. Оценку делает каждый для себя. В таком случае, люди могут завышать оценку, тем самым
> выбивая деньги из фирмы.
Еще есть ситуация когда человек, который оценивает, участвует в ценообразовании.
Провокационная тема:)
У самого такие проблемы, но в еще более невесомой работе. Написание ТЗ, консультации и т.п.
Проблема в том что при приводя заинтересованность в выполнении работы к чисто фиксированной = сдельной плате, мы создаем дуальную систему взаимоотношений. Продавец-покупатель, и всегда каждая сторона будет стремиться к максимальной выгоде. А выгода в данном случае получается за счет уменьшения выгоды другого, т.е. выгода программиста обратно пропорциональна выгоде владельца\менеджера и наоборот. Как бы там нибыло всегда будет:
1. у программиста интерес и мотивация увеличить эстимейт и работать меньше\дороже.
2. у владельца задачи\менеджера и т.п. желание занизить оценку работы и заставить работать больше\дешевле.
И ничего тут не поделаешь… оценку кто-то должен делать. В идеале ее делают совместно, получается более или менее честно если оба человека разбираются в оцениваемом. Но сколько стоит время 2-х человек затрачиваемое на оценку…Что делать если один не знает оцениваемое, а если оба не знают?
Получается очень злая система и обычно ее может исправить\контролировать оценки рынок, т.е. рыночные отношения; есть проект\задача, есть возможность выбрать кто на ней будет работать на основании эстимейтов, точно так-же программист может выбирать несколько задач или отказаться от всех. Но это уже превращает организацию в сборище фрилансеров в одном офисе. Это не решает проблем с совместной работой программистов, дает высокие издержки на множество эстимейтов и переговоры и простой!!!. Но вносит объективность в оценку стоимости решения задачи.
Если рыночные принципы не пускать в свою организацию, то схема сдельщины может работать при хороших отношениях, совместных целях\интересах = нематериальном мотивировании, и всем прочем связанном с goodwill.
Нужно тогда понимать что мотивация происходит не только из сдельной оплаты, но и из других источников.
Подбирать их, комбинировать, в любом случае в каждом конкретном случае будет своя оптимальная схема.
Обычно это банальные — ставка + % от стоимости проекта. причем ставка может быть от количества отработанных часов, так и просто от присутствия в офисе. Все остальное набирается нематериальной мотивацией. Это интересные проекты, развитие, удовольствие от работы.
Итого:
1. Померять объективно работу можно рыночными отношениями.
1.1. Рыночные отношения убивают прирост достигнутый в производительности необходимость растрачиваться на оценки, общение, конкурирование, простои.
1.2. Рыночные отношения значительно уменьшают управляемость организацией, особенно в стратегическом плане.
1.3. Большие вопросы с командной и долгосрочной работой
2. Померять объективно работу можно статистически и постфактум менять выплату за счет исторических данных. Но это применимо к простым проектам и формализуемым задачам.
2.1. Там где никто не знает как решить задачу невозможно оценить эффективность. После того как задачу решили, всем решение кажется простым и быстрым. А проверять раздавая задачу каждый раз 10-ти исполнителям накладно;)
3. Все проекты попадают в диапазон от копать\понятно\формализованно до творить\неизвестно\не формализованно.
3.1. каждый проект имеет свое место в этом диапазоне
3.2. каждый проект состоит из совокупности задач которые имеют свое отличное от других положение на этом диапазоне.
4. Определить положение проекта в этом диапазоне тоже работа:)
4.1. На основании понимания что это за проект можно играться с мотивацией и схемами оплаты
4.2. логично что чем больше творчества тем большую часть сдельщина должна занимать.
5. Нужно понимать что творчество оценить невозможно, т.е. качество эстимейтов уменьшается у проектов с задачами решение которых заранее не известно.
5.1. Рыночные отношения и\или goodwill для проектов с большой долей неопределенности.
Вот такие заметки.
Ну с этим сложно не согласиться 😉
Эээ…, со всем, или с чем-то конкретно? Было бы интересно узнать вашу точку зрения.
Так, буду отвечать целиком, чтобы по отдельным пунктам не рыться.
Рыночные отношения, может слегка и злая форма, но зато более эффективная.
Многие из нас видели, что происходит при централизованной системе управления страной.
Я согласен, рыночные отношения убивает, теплый и уютный настрой в фирме. С другой стороны, зачастую именно этот теплый и уютный настрой дико понижает производительность.
Ведь получается, что человек в определенный момент решает — нафига напрягаться и так все тепло и хорошо.
Согласен, что с стратегической точки зрения рыночные отношения гораздо сложнее прогнозировать.
Дальше, возвращаясь к рыночным отношение и войне интересов. Пусть есть компания А которая выполняет заказы компании B. У них вроде тоже есть такая же война интересов, как в случае работодатель — рабочий, однако я бы сказал, что как раз самые лучшие рыночные отношения складываются тогда, когда ты делаешь деньги там же, где их делает их другая компания.
Условно говоря, компания B продает авто и делает на этом деньги, а компания А делает для компании B проверку и помывку авто. Так вот, без компании B, компания A получала бы меньше денег. Поэтому хоть борьба и есть, но обе стороны серьезно заинтересованы.
Проблемы только возникают и будут возникать, когда программист делают какую-то работу, которая не приносит выгоды фирмы. Тогда действительно выгода программиста противопоставляется выгоде фирмы.
Но и сейчас с этим есть те же самые проблемы. Как пример на внутренние проекты, которые могут не выстрелить зачастую сажают самых слабых программистов.
Проблема тут в том, что фирма пытается снять свои риски насчет этих внутренних проектов и переложить на программистов (путем уменьшения зарплаты). А вот это совсем странная вешь, так как именно идея ведения бизнеса — взятие рисков и получение прибыли в случае если удалось миновать рискованную область.
Витя, похоже есть счастье на земле и сильная зависимость зп от личного вклада в IT 🙂
послушал вчера интервью Михаила Тюленева вот тут http://itblogs.ru/blogs/pod/archive/2007/05/13/16767.aspx
говорит что зп в НьюЙорке 600К + 500К премия за.. личный вклад, так как в той области где он работает этот личный вклад виден и тот кто работает получает 200К, а кто хорошо работает — 600К.
интересно так же сравнение Калифорнии и НьюЙорка.
а предметная область я так понял вот эта:
http://en.wikipedia.org/wiki/Financial_mathematics
Интересная информация. Я пока о таких вот зарплатах не слышал.
Ну, да до 200 бывает, особенно у sales engineering.
Надо будет поузнавать.
Кстати наверное у них поэтому и ставят серьезную зависимость, потому что для financial mathematics сразу видна дополнительная прибыль.
Есть такие три показателя:
-трудозатраты
-размер кода
-«дефект денсити»
Индифидуальность кода вычислется из настроек SVN’а ( иже с ними).
А далее существует пара-тройка методик по которым можно понять, качественно программист работал или балду гонял 🙂
Эффективность = Размер задачи / Трудозатраты.
Трудозатраты считаются легко.
Однако размер задачи не равен размеру кода или -”дефект денсити”.
Собственно говоря, в это и утыкается…
Для электрика посчитать размер задачи «установка розетки» — реально. Для программиста нету типовой задачи а-ля «установка розетки).
Так, что с одной стороны размер кода и баги — важный показатель, с другой стороны — этот показатель не напрямую связан с размером задачи.
Идея со сдельной оплатой замечательна.
Я даже считаю, что проблема «кто оценивает» — не самая страшная. Хотя бы потому, что если руководитель готов заплатить $XXX за реализацию такой-то части проекта в срок Nдней — то не все ли ему равно, если даже разработчик реально работал 1 час, а остальное время лежал на пляжУ с пивом? У всех разные режимы работы, лишь бы результат устраивал заказчика в т.ч. и в плане затрат.
А вот реальных проблемы мне видится три.
1.Старо, как мир — «дешевле — не значит лучше». Вася взялся реализовать задачу за $100 и два дня, выиграв «тендер» у Пети, предлагавшего сделать тоже самое за $300 и неделю. Все супер — но — что если руководитель на основании знания своих кадров допускает, что реализация Пети будет намного более качественна?
2.Чисто технический, казалось бы, момент с конкретизацией финрасчетов. Даже три момента.
2.1.Это «обычную» зарплату, даже почасовую, сможет начислить простая расчетчица Люба. А чтобы задокументировать все эти «тендеры» — потребуются уже гораздо более серьезные средства. В частности, дополнительные штатные единицы, разработка специальных регламентов — чтобы все было по-серьезному и поддавалось контролю.
2.2.Врач должен лечить, кухарка — готовить, программист — программировать. Если вместо того, чтобы готовить обед посетителям, повар в ресторане займется подсчетом своей зарплаты — «сколько я получу за бифштекс, сколько за полпорции ухи» и т.д. — настанет бардак. Ему попросту будет некогда к плите подходить. А предложенная технология предлагает программистам как раз таки заниматься не своими прямыми обязанностями, а подсчетами экономики своей деятельности.
3.»Каждый сам за себя»
С внедрением предложенного подхода может выяснится две прелюбопытнейших вещи.
3.1.Не секрет, что кроме сладких конфеток бывает еще и черная работа. На которую невозможно предложить «интересные условия». Если у руководителя нет возможности распорядиться — «так, Серега, берешь вот эту задачу и решаешь» — то либо задача вообще не будет решена, либо придется бегать за Серегой и его заинтересовывать. Обычный подход, когда сегодня Серега занимается черной работой, а завтра ему это компенсируют более интересным (в любом смысле) заданием здесь не прокатит. Простейший пример — исправить косяк в закрытом проекте, который вел уволившийся специалист. Да, это не Серегин косяк, казалось бы — надо ему заплатить. Но с другой стороны — Серега работает в команде, а не подвизается фрилансером, что накладывает свои обязательства.
3.2.То же самое, но в чуть более широком смысле. Неправильно думать, что если программа написана очень хорошо, но из-за недоработок… ну, скажем, переговорщиков с заказчиком проект запорот — то программист не при чем, и заплатите ему сполна. Это если бы он был внештатным аутсорсником — тогда да. А до тех пор, пока мы все в одной лодке — подход «проект-то завален, но лично я-то все сделал нормально, заплатите премию» некорректен, т.к. приводит к спихиванию вины на товарищей и фактическому оставлению командира один на один с проектом (режим «я прокукарекал, а там хоть не рассветай»).
«Хотя бы потому, что если руководитель готов заплатить $XXX за реализацию такой-то части проекта в срок Nдней — то не все ли ему равно, если даже разработчик реально работал 1 час, а остальное время лежал на пляжУ с пивом?»
Вопрос кто оценивает, важен потому, что качественно оценить руководитель зачастую не может. Если он занижает оценку — никто не берется, если он завышает — то тогда просто тратит слишком много.
В общем-то как я обсуждал — решается тендерами. Хотя согласен, что проблема не самая большая.
>»дешевле — не значит лучше”
У каждой задачи, должны быть четкие критерии приемки. В том числе
— Прохождение тестов
— Написание юниттестов
— Review кода с кем-то и т.п.
В таком случае, будет минимальный уровень приемлемого качества.
«Чисто технический, казалось бы, момент с конкретизацией финрасчетов. Даже три момента.»
Ответ — автоматизация. На самом деле конкретной зарплаты не выплачиваются. Сделал задачу и ее приняли, получил оговоренную сумму.
Да, это поднапряжет сначала. Но на самом деле, это напряжет только в нужную сторону, человек почувствует связь между деланием и получением. Сейчас связь очень слабенькая.
>3.”Каждый сам за себя”
Да, тут все будет злее чем сейчас.
Из приведеного примера — когда запорол переговорщик. Так вот, если он запорол — его и надо по идеи наказывать. А то сейчас получается, что наказываются все (и вот это вызывает гораздо больше злости, чем когда наказывается виновный).
Вообще с точки зрения бизнеса — тот, кто работает хорошо (исполняет то, что ему сказали) — тот должен получать. Тот кто работает плохо (не исполняет, или исполянет не то) — должен не получать.
Так, что в целом я согласен — схема злая. Особенно она будет злая для тех, кто
а) Ничего не делал и получал зарплату
б) Занимался всякой херней, вместо своих обязанностей
в) Частенько ошибался и его ошибки расхлебывали все хором
Просто уже очень много людей подпадают под категорию а), б) и в). Причем и программистов и менеджеров и топ менеджеров. Естественно им прийдется не сладко в таком случае.