Программистский синхрофазотрон продолжается.

Итак, как я говорил в первой части статьи (лучше всего ее прочесть включая комментарии) текущий метод работы – от забора до обеда устарел. Фактически для программистов старый момент работы полностью убивает мотивацию, так как зарплата не зависит от результатов. И самый лучший метод мотивировать программистов – сдельная оплаты, когда программистам выгоднее всего делать все быстро и качественно, чтобы получить как можно больше денег, за как можно меньший промежуток времени.

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

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

Ну, начнем с того, что мотивировать программистов, нужно только в случае, если IT рынок идет вверх. Когда IT рынок идет вниз, то вероятностью увольнения потрясающе мотивирует всех, так как сама идея оказаться на улице в момент рецессии подстегивает людей работать, на 120% все время. Кстати, наверно именно поэтому множество очень успешных компаний стартовали именно в момент рецессии (так как все в них просто работали, а не думали, как заработать лишний доллар).

Вернемся к проблемам схемы:

Самое первое обо, что бьются головой фактически все —

Estimat’ы

На данный момент есть два метода estimat’ов. Первый, когда начальство говорит – это нужно сделать по быстрячку к следующему понедельнику. Как вы понимаете точность этого estimate равна нулю, так как она не основана на анализе, опыте и т.п. Она основана только на желание получить, зачастую, нереальный результат в короткие сроки.

Второй метод estimat’а –когда программиста спрашивают: «сколько прикидочно оно может занять». Ну и программист почесав голову – говорит, ну эдак месяца два. Уже лучше, estimate основан на опыте, но все еще не основан на анализе. В лучше случае, программисту дают несколько дней, и он разбив на несколько задач и подзадач, выдает estimate.

А теперь одно простое замечание, даже estimate основанный на анализе и опыте вероятнее всего оказывается очень неточным, так как у программиста фактически отсутствует обратная связь от прошлых estimat’ов. Никто не дает ему больше денег, если estimate правильный и не забирает, если неправильный. Да, естественно, если он ошибся очень сильно он это и сам заметит, но например, ошибка на +/- 50% вообще не считается за ошибку. И уж тем более программист не хранит статистику о том, как он делал estimat’ы на протяжение прошлых пяти лет, чтобы умножить или делить их (в случае если он прошлые estimat’ы завышал или приуменьшал).

А теперь важный пункт. Работа должна быть не просто базироваться на сдельной оплате, а она должна быть сдельной оплатой с хорошей обратной связью.

Добавим немножко соревновательного эффекта в компанию. Менеджер выставляет задача и называет цену, скажем $100. Дальше кто-то из программистов либо соглашается на такой объем работы, либо никто не соглашается и менеджеру приходится поднять ее до $200 и тогда кто-то соглашается. В общем, проводим, что-то типа аукциона задач. Причем задачи, должны быть атомарные – на 8-16 часов (объяснение к этому позже).

Пункт, номер один – у программиста появляется потрясающая обратная связь. Он не только оценивает задачу (стоит ему браться за эти деньги или нет), но и если он ее правильно оценивает то он получает свои деньги быстрее (за оцененное время), если он ее недооценивает – то он получает отрицательный обратную связь и в следующий раз он подумает, чтобы не занижать estimate (да и статистика ему в этом поможет).

Завышать estimate программист в этом случае тоже не может иначе другие программисты возьмутся за задачу раньше.

Тоже самое касается менеджера. Во первых он начнет консультироваться с программистами и выделять задача на estimate больших задач (причем может быть даже давать ее нескольким независимым программистам). Если он будет занижать estimate в результате за задачу никто не возьмется. Если он будет завышать – он будет расходовать слишком много финансов, что для него будет тоже не выгодно (об этому чуть позже).

Итого в такой схеме, всем выгодно давать как более точные estimate, иначе они будут получать меньше денег за единицу времени.

Да товарищи программисты, если вы согласились таки делать что-то, а оказалось, что оно занимает больше времени, то увы это ударит по карману. И я считаю, что один или несколько раз можно принять ту же оплате за более долгий срок, чтобы в конце-концов начать делать правильные estimate и зарабатывать хорошие деньги (большие, чем текущая ЗП). Кстати, тем же самым правил будут подчиняться и плохие/начинающие программисты. И соотношение в оплате (из-за разной эффективности) вполне будет 1:20 (относительно хороших программистов). И это будет отличной мотивацией учиться как можно быстрее. Такая мотивация гораздо лучше, чем повышение через год ЗП на 10%.

Непредвиденные задачи

На данный момент непредвиденные задачи врываются в план, как слон в посудную лавку (на то они и непредвиденные). Почему-то в каждом проекте есть таки задачи, и почему-то каждый раз забывают предсказать, что они будут. Странно – правда?

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

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

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

Автоматизация

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

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

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

Планирование

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

Вы замечали, что скажем с 15 декабря по 15 января делается в 5 раз меньше работы, чем с 15 января по 15 февраля. Я думаю, вы и так догадываетесь, что Новый Год является ответом на этот феномен.

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

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

Но, для компаний скажем в 100 человек, планирование уже не будет проблемой. Да действительно кто-то может решить сначала ударно поработать месяц, а потом месяц отдохнуть. И что с этого? С помощью статистики всегда можно будет следить среднее кол-во полученного результата. И, кстати, тогда гораздо легче будет учитывать влияние Нового Года и других праздников, детских каникул, когда родители тоже не могут тщательно работать и т.п. То-есть как только мы переходим на большие числа, то всегда можно точно знать, что фирма вырабатывает, например, $6000 в день и из этого очень легко можно считать, когда закончится проект, который оценен в $1M.

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

На закуску остается пару вещей:

Сильной заниженный estimate

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

Обучение

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

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

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

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

Передача знаний

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

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

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

Злоупотребления системой

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

Ну и под конец, пример как оно все должно работать. Президенту фирмы приходит идея сделать новый проект X, он дает задачу стоимость $10k на estimate этого проекта . Один из менеджеров берется за это — выдает задачу на $100 по разбиению на части проекта. Программист берется, и менеджер дает другую задачу на $50 на проверку разбиения — другой программист, проверяет и может быть что-то поправляет. Проект разделен на 5 модулей, и менеджер дает на estimate каждый модуль за $1000 и $300 на проверку — младшим менеджерам, те в свою очередь раздают задачи по следующему разбиению и проверке. Так в конечно счете, все разбито на задачи, позадачи и оценено. На каждом этапе менеджеры оценивали риски, брали статистику по непредвиденным задачах на похожих задачах и накидывали эти коэффициенты. В конце презедент получает оценку в $1.5M, делает очередные накидки и общается с советом директором, говоря что проект выйдет $2M, они соглашаются. Он делает большие задачи по выполнению 5 больших модулей, за них берутся менеджеры, создают согласно estimate подзадачи, за них берутся team lead’ы, создают подзадачи, за них берутся программисты. Естественно какие-то estimat’ы не точны и программисты за них не берутся, тогда менеджеры дают кому-то переestimat’ить задачу или просто повышают цену задачи из резервов. Все постепенно идет вперед, программисты делают задачи, менеджеры получают остатки денег с подзадач. Причем все это работает очень-очень эффективно, так как за любым действием стоят деньги и никому не хочется валять дурака в этом случае.

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

P.S. Спасибо этим вот товарищам: Макс Крайнов, Сергей Корнилов, за то, что поставили на меня ссылки в статьях и привели ко мне людей. Если вы их еще не читаете, очень рекомендую 🙂

Очередную (третью часть) этой статьи  можно прочесть тут.

68 комментариев to “Программистский синхрофазотрон продолжается.”

  1. 2Victor Ronin:

    ага, я и говорю что вероятности то перемножаются, но второй множитель гораздо больше 10%

  2. 2Victor Ronin:
    >>Кстати, насчет 10% программистов на C++ и из них 10% предпринимателей. Предприниматель — это не клеймо при рождение, это такая же как C++ область знаний. Находясь внутри данной схемы количество предпринимателей в фирме быстро вырастет с 10% до 90%.
    Ну, не совсем так. Квалифицирующие признаки могут разбиты на 3 уровня:
    1. Личностные (психофизические). Человек характеризуется психотипом определенным психотипом (например, сангвиник/холерик), интеллектом и здоровьем. Требования к программисту и предпринимателю в чем-то противоположны (интраверт/экстраверт) и т.п.
    2. Знания (грубо говоря, выучено)
    3. Умения (получен опыт)
    (2,3 — Hard и Soft Skills)
    Поэтому не всякий пройдет эти фильтры на пути обладания человеком данной квалификацей. И с 90% — это вы явно погорячились 🙂

  3. Victor Ronin:

    2Serge_Kond: Согласен, есть пункт N 1. Но, я бы сказал, что требования к психофизике программистов за последние скажем двадцать лет сильно изменились.

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

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

    А насчет 90% я думаю не погорячился. Вы ведь сами сказали, что большинство людей не смогут работать в таком режиме — вероятнее всего те, кто совсем не сможет поменяться — уйдут. Поэтому в конечном итоге в фирме будут в основном, кто неплохо справляется с этой частичкой предпринимательства.

  4. 2Victor Ronin: О каком программисте говорим? 🙂
    По-моему, не психофизика поменялась, а понятие «программист» изменилось. Т.е. есть»кодеры» и «программисты». Первых описывать неинтересно, это из названия понятно — бойцы софтварного конвейера. Вторые — весьма даже экстравертные люди, вполне креативные, отнюдь не всегда чистые математики, очень часто технические специалисты (не в обиду математикам — к жизни ближе, их так учили), общительные, умеющие обсудить с клиентом его проблемы и реализовать их. Первые изобрели множество замечательных алгоритмов и продолжают их совершенствовать. Вторые придумали парное и экстремальное программирование, багтрекинг и прочие приблуды для управления своим и чужим трудом.

    Далее IMHO. Предпринимательство и программист… По-моему, естественный процесс. Кто делает продукт для широкой потребительской аудитории? Они, программисты. Программы везде вокруг нас — устройства для отражения и сбора информации на каждом углу. Телефон или КПК, ноут, десктоп — норма жизни во многих странах. Все они обвешаны мелкими рюшечками, не только облегчающими их использование, но и делающее это использование более «одушевленным». Почему раньше не было такого количества мелких фирм? Потому что организация распространения каналов сбыта была под силу только большим фирмам, с департаментами маркетинга, рекламы, логистики, производства (сколько дискеток надо было записать!). Как только Интернет стал общедоступным дешевым транспортом информации, была снята проблема организации канала сбыта. Огромное распространение получили маленькие, удобные программы «на каждый день». А это может делать небольшая фирма. Даже офис ей не нужен по большому счету.

    Вот в чем я согласен на 90% процентов с Serge_Kond, так это в том, что «вопрос взаимосвязи ЗП и мотивации — последний.» Почему 90%? Потому что не последний, а равноправный с прочими мотивациями.

  5. Victor Ronin:

    2D.Mikhantiev: Собственно это я и хотел сказать. Что понятие программист изменилось и теперь другие люди подпадают под эту категорию (гораздо более предпринимательные, чем раньше).

    Насчет мотивации — сложная эта штука…. Это сейчас его ставят последним или равным. Потому, что в городе X можно поставить зарплату в $1k (хорошую) или в $1.5k максимально. И 50% разницы еще неплохой разрыв. Естественно 50% разницы в ЗП мотивируют, но электромоторчик в задницу не вставят.

    Условно говоря, берем хорошего программиста который получает $1.5k сейчас. Если он будет действительно зависить от результата (и сможет получить $10k если будет работать в поте лица), то
    а) Он будет очень мотивирован работать хорошо
    б) Он будет мотивирован постоянно пытаться улучшить свои результаты, чтобы меньше работать, при этом столько же получая.

    Тогда, вместо того, чтобы смотреть YouTube люди будут и книги читать по экстремальному программированию и применять их и свои новые методики вырабатывать.

    Я бы сказал, одна из проблем мотивации — это стеклянный потолок. Как-то обидно осознавать, что можешь хоть всю жизнь улучшаться и стать в 100 раз более эффективным, а зарплата вырастет в 2 раза.
    Кстати, я об этом следующую статью буду писать.

  6. 2Victor Ronin: Не согласен про «это сейчас его ставят последним или равным». По-моему, хороший программист не может быть таковым только за деньги. У меня вообще есть глубокое убеждение, что в ИТ нельзя хорошо «просто работать», для хороших результатов надо «в этом жить». И это роднит ИТ с творческими профессиями. Т.е. меня «прет» от решения задачек, задач и задачищ, и именно это самое «прет» заставляет меня делать очередной «шажок вперед» (читай http://victorronin.com/2008/02/05/shag-vpered/ 🙂 ). Ради этого, по-моему, стоит упираться. А только за деньги… Как-то скучно 🙂

    Про стеклянный потолок. Если уперся в него, то у тебя есть два выхода — остаться в деле и ограничить потребности («дауншифтинг», по-моему, как одно из средств), либо подняться по лестнице на другой этаж, чтобы потолок стал полом и найти драйв там, в новых делах и возможностях. 🙂

    Я знаю и тех, кто остался, и тех, кто перешел на другой этаж.

  7. Victor Ronin:

    2D.Mikhantiev: Я пока не буду отвечать развернуто, так как пишу статью и там выражу свое мнение.
    В кратце — я согласен, что не все деньгами выражается.

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

  8. Victor Ronin:

    2D.Mikhantiev: Я решил, что бессмысленно бегать по этажам. Нужно строить свои здания.

  9. […] разговора, который с D.Mikhantiev в этой статье: «Если уперся в потолок, то у тебя есть два выхода — […]

  10. Shrike:

    Признайтесь, уважаемый, отсюда позаимствовали:
    http://www.eldar.com/node/108

    • Victor Ronin:

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

  11. Dart:

    В тему мотивации программистов, набрел вчера на замечательный сайт:
    http://motivateme.ru/book/

  12. DM:

    Где бы только найти работодателя с таким подходом…

    • Victor Ronin:

      В глобальном маштабе, RentACoder, eLance и т.п. чем-то похожи на эту идею.

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

  13. Насчёт сдельщины-повремёнки: рекомендую здесь почитать.

    2 D.Mikhantiev: насчёт денег — присоединяюсь, в них не счастье, а подстраховка 😉

    • Victor Ronin:

      Спасибо за ссылку.

      Насчет денег, я тоже присоединяюсь.
      В основном, когда я говорю о том, чтобы зарабатывать больше, я скорее имею повышения эффективности (стоимости часа). И естественно деньги — только инструмент, а дальше — это дело человека, что делать с этим инструментом.

    • Victor Ronin:

      Почитал но не вдохновился.

      Да, хорошо написанный текст о том, что слабо мотивированная механизация лучше сильно мотивированной не механизации.

      В схеме только упущена еще один возможный эффект — сильно мотивированная механизация.
      Как там у немцев насчет конкуренции с китайцами? Думаю не слишком.
      А это история с переносом заовда Nokia в Румынию. Nokia не такая дурная компания, чтобы понижать себе эффективность. А значит, еще голодные (и эти мотивированные) Румыны, за меньшую оплату будут эффективней, чем немцы.

      Я не знаю, как у немцев дела обстоят с IT. Но по крайней мере, в копании ям и в IT есть существенное отличие. И в IT медленность можно позволить только дорос до определенного уровня, если же стартовать карьеру в таком стиле, то вряд ли можно будет добраться хоть до чего-то.

      Кстити, тот пост похож на классический парадокс — Ахилеса и черепахи. Парадокс решается путем того, что нужно поглядеть вперед. И какое-то у меня странное впечатление, что время «застоя» на западе прошло. И сейчас им наступает на пятки Китай с Индией. Так, что работать ковыряясь в зубах уже вряд ли удастся.

  14. […] Итак прошло фактически пол года,  с тех пор как я выложил нашумевшие у меня в блоге статьи Программистский синхрофазотрон (часть 1 и часть 2). […]