Программистский синхрофазотрон (часть 3, о estimat’ах и качестве).

Июнь 30th, 2008

Итак прошло фактически пол года,  с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 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 с знакомыми. И это на самом деле выходит за рамки — передохуть подумать.

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

Стандартная ошибка начинающих программистов-бизнесменов.

Июнь 27th, 2008

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

— Я могу сделать это лучше других.

Потрясающая формула, которая способна превратить вашу жизнь в ад (просто потому, что дел станет больше чем времени).

— Я толком не могу контролировать, что они сделают это качественно.

Во первых, не все вещи нужно делать качественно. Некоторые вещи, нужно просто делать. Например не идеально подметенный пол — это достаточно. Не обязательно он должен блестеть.

Если действие действительно должно быть сделано качественно придумайте не как вы должны проверять качество, а как подчиненный должен вас удостоверить в качестве.

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

— Я же трачу на это деньги.

Частично, я об этом писал в статье «Умение оценить нерабочее время«. Подумайте, вы можете делать дело (чинить стул), которые не принесет денег фирме и стратегическое планирование, которое в удачном случае может принести серьезную прибыль. Соответственно, нужно оценить стоимость своего часа и все задачи которые лежат ниже этой стоимость должен делать кто-то другой.

Дополнение от Станислава Малкина:

— Программисты не любят переходить к следующей задаче

Очень часто, программисты предпочитают полировать задачу то потери пульса. И поэтому им тяжело переключится с текущий задачи и отдать ее кому-то на следующую.

Ради бога, сынок, ничего не трогай!

Июнь 27th, 2008

Я думаю все помнят этот анекдот с длинной бородой:

Сидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!

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

На самом деле, эта одна из самых моих нелюбимых фраз (от программистов) что-нибудь типа «Не трогай это, оно очень ненадежное/сложное».

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

Пожалуй сразу оговорюсь, если это legacy система, которая доживает свои последние дни, то фиг с ним, действительно трогать наверное не стоит. Однако, чаще всего такое произносят о какой-то части кода для проекта в самом расцвете сил.

Итак, почему мне это не нравиться?

— Во первых, если какая часть ненадежная, то чаще всего ее боятся серьезно менять и все изменения в ней делают не архитектурные, а заплаточные. И самом собой от этого надежность и понятность этого места только продолжает падать.

— Во вторых, почему-то этими самым ненадежными местами оказываются критические части функциональности. И это не самая хорошая идея иметь ненадежную критическую функциональность.

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

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

Зато, по окончанию этого времени, чаще всего уже становится понятно как оно работает, слегка перепланирования архитектура, счищается толстый слой заплаток и т.п.

А для тех, кому таки не по себе эти изменения, не забывайте что есть система контроля версий и идеально если еще есть и unitTest’ы (их кстати, можно и написать если их нет). После чего изменения даже в самой запустанной системе не так страшны, как их рисуют.

Без фанатизма.

Июнь 24th, 2008

Уверен, что люди которые со мной работали слышали эту фразу много-много-много раз.

Но, начну с начала. Начинается все с того, что есть гуру Вася или немерно крутая фирма Мугл (кстати, если скрестить Microsoft + Google то как раз выйдет Moogle). И вот по ходу своей жизни, Вася бросает фразу «Самое важное это строить архитектуру Model-View-Controller, а остальное херня» или этот самый Мугл говорить, нанимайте самых лучших специалистов и все будет у вас пучком.

Ну, и соотвественно вокруг, тысчи почитатей и обожателей, начинают шептать… «о… да… я всегда знал, архитектура MVC — это круто… это единственное важное» или «нанимать самых лучших, точно, как мы раньше не доперли, самых лучших».

И вот, проходит неделя, месяц, год. И эту фразу превращаю в мантру, одевают в красивую рамочку и приходят на нее помолиться. Постепенно вырастает поколение, которое обожествляет фразу (зачастую не помня даже к чему она была сказана). Это поколение передает ее следующему и т.п. Та даже, если не передает, а просто первое поколение бьет поклоны фразе, уже выходят перекосы.

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

Ну, условно говоря, какая MVC для написания драйверов? Или какое нанимание лучших в случае, когда нужен средний человек для выполнения какой-то руттинной работы в малом Перепурдянске?

Собственно говоря, даже тогда, когда фраза  применима у нее есть границы. Предположим — хороший чистый код для программы всегда хорошо. Но это не значит, что чистить код надо до дыр. Это не есть цель, это метод. И нужно понимать, что стоит за этим методом, какая более высокая цель.

Например чистый код ведет к более легкому исправлению ошибок, добавлению функциональности. Но опять же и это не самоцель. Это нужно для того, чтобы программа была более конкурентоспособная, но и это промежуточная цель. А выше стоит большие продажи.

Вот думаю, большинство подумаю что повышение продаж или прибыли это уже фактически самоцель.

Две ситуации, чтобы доказать, что максимизации прибыли еще не самоцель

а) Петя продал все запчасти для холодильников которые были вместо 6 месяцев за 1 неделю. Петя вроде большой молодец. Вот только новая партия не прийдет раньше чем через 3 месяца. И это значит, что все остальные заказчики уйдут к конкурентам, плюс VIP заказчики не получат деталей тоже. Прибыль максимизированна, но на очень коротком сроке.

б) Берем более длинный срок (скажем год). За три месяца до окончания года, большая фирма увольняет 1000 человек, и экономит этим очень приличную сумму. Проходит пол года, обнаруживается, что на всех проектах не хватает людей.

Можно продолжать до бесконечности.

Собственно я хочу сказать, что когда фраза начинает возносится в нечто божественное, спущенное свыше, она тут же теряет свой смысл. Особенно мне не нравиться, когда выбирается один элемент из сложной системы и ставится краеугольным камнем (например MVC). Это лучший метод задурить головы молодежи и получить вместо движения к цели, просто следование методу.

Кстати, даже фразу «Без фанатизма» нужно воспринимать с некоторым сомнением. Вот такая вот рекурсия.