Программистский синхрофазотрон продолжается.
Итак, как я говорил в первой части статьи (лучше всего ее прочесть включая комментарии) текущий метод работы – от забора до обеда устарел. Фактически для программистов старый момент работы полностью убивает мотивацию, так как зарплата не зависит от результатов. И самый лучший метод мотивировать программистов – сдельная оплаты, когда программистам выгоднее всего делать все быстро и качественно, чтобы получить как можно больше денег, за как можно меньший промежуток времени.
Есть уже компании, где частично это сделано – в виде сдельной оплаты, однако, это только первый шаг в том, чтобы сделать нормальную систему с хорошей обратной связью. Тем не менее большинство компаний, пока боятся сделать даже этот шаг.
Погрузимся же в пучины страхов предпринимателей и программистов и как все организовать, чтобы все были счастливы.
Ну, начнем с того, что мотивировать программистов, нужно только в случае, если 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. Спасибо этим вот товарищам: Макс Крайнов, Сергей Корнилов, за то, что поставили на меня ссылки в статьях и привели ко мне людей. Если вы их еще не читаете, очень рекомендую
Очередную (третью часть) этой статьи можно прочесть тут.
http://blogs.technet.com/eldar/archive/2007/12/22/1547815.aspx в чем то перекликается с твоим постом, и как мне кажется местами даже смелее
2Dmitry: Да, действительно идеи перекликаются в многих местах. Хотя шли мы абсолютно с разных концов.
Я скорее пытался повысить эффективность, ты скорее пытался удалить менеджеров из схемы.
Что я считаю крайне важным - это статистику, так как игра без статистики все таки останется игрой в рулетку. С накопленной статистикой она станет предсказуемой торговлей задачами.
Но вообще забавно, что даже терминология (”аукцион”) похожая :))
Идея конечно интересная но очень утопическая. Я лично по своему опыту вижу достаточно много но.
Во-первых, самая большая проблема с этим - практически тяжело разбить работу на независимые части, тем более небольшого объема. Если бы это было несложно, было бы вообще бессмысленно содержать фирму как единицу - бери себе задачу, разделяй на части, раздавай посторонним людям, сдавай результат, бери себе разницу итп. Если кто не справился - в следующий раз ему не раздавай. Опять же, программирование такая штука что если ты уже сделал задачу из одного проекта даже не на 20 часов а скажем на 100, то следующую задачу ты почти гарантированно сделаешь в 1.5-2 раза эффективнее любых конкурентов которые раньше над этой задачей не работали, т.к. им нужно будет время на изучение задачи и вникание в то, что кто-то сделал до них. Поэтому аукцион работать просто не будет - ты либо всю задачу отдашь одной команде, либо будешь выдавать первый таск из всеискать команду до тех пор, пока не найдешь нормальных людей которые опять-таки сделают всю задачу целиком, а заодно и все последующие тоже.
В целом, я бы сказал что если бы можно было вывести какой-то формализованный подход в управлении проектами, это занятие не было бы таким сложным, интересным и творческим делом. Поэтому возьму на себя смелость утверждать, что какой-то научной формулы стимулирования труда программистов вывести просто невозможно. Все очень субъективно и пракрически на 100% зависит от личности руководителя.
Случайно задел энтер, и отправилась половина поста. Сегодня у нас праздник, Рождество (с которым всех и поздравляю), я немного позволил себе лишнего, поэтому позволю уж себе также побыть многословным. Так вот, у меня лично такое радикальное мнение, что тот или иной способ оплаты труда программистов не сильно влияет на результат, то есть, он может быть либо повременным, либо сдельным, либо сдельно-премиальным, либо любым другим, при условии что он устраивает обе стороны. Я считаю, что хороший работник не будет работать плохо, если он может работать хорошо, независимо от того как ему платят. Поэтому основная задача - просто найти (или воспитать, что в наших условиях гораздо актуальнее) хороших работников. Я не люблю людей уговаривать или воспитывать поощрениями или наказаниями - у меня не детский сад, и если человека не научили хорошо работать родители, я тем более не хочу браться за это неблагодарное занятие. Я как руководитель достаточно квалифицирован, чтобы оценить, кто работает нормально, а кто нет. Если я не буду или не смогу этого делать, значит я плохой руководитель. Управление людьми - вещь гораздо более многофакторная, чем написание программ, и многие руководители - бывшие программисты - этого пытаются не замечать. Я сам иногда очень хочу спрятаться куда-нибудь от проблем управления в программирование или аналитику, но жизнь, как говорится, вносит свои коррективы. Наш бизнес, к сожалению или к счастью, не такого типа, который можно один раз наладить и потом о нем забыть, просто написав правильные правила (тавтология :)) Поэтому, друзья, давайте засучим в Новом Году рукава, и с новыми силами начнем бороться с энтропией каждый в своей отдельно взятой компании день за днем, час за часом.
У Джоэла есть по этому поводу Evidence Based Scheduling http://www.joelonsoftware.com/items/2007/10/26.html. Они как раз включили в FogzBugz систему по сбору статистики.
2zdv: Поздравляю с Новым Годом и рождеством. :))) Идея действительно слегка утопическая.
Насчет разделения на мелкие задачи - согласен это достаточно большая проблема. Хотя с другой стороны, зачастую из-за неразделения на мелкие задачи точно также происходят проблемы и при нынешней разработки - неточность estimat’ов, потерянные задачи.
Насчет того, что человек сделавший задачу становится более эффективных. В общем-то ничего плохого в этом нету если он постоянно будет получать задачи на схожую тему. В общем-то я и не писал же, что разные люди должны делать одно и тоже. В конце-концов, он может взять большую задачу целиком, делать ее основные части, а мелкие выделять и раздавать как это делают менеджеры.
“Я считаю, что хороший работник не будет работать плохо” :)) Оптимистично. Но думаю, ты сильно преувеличиваешь достоинства человечества.
Я бы сказал, что у человека есть четыре параметра связанных с работой - оплата, реально потраченное время, интересность, спокойствие. У каждого в голове своя формула по оптимизации этих параметров. И зачастую (по крайней мере я видел тут в США это очень у многих) когда невозможно повысить оплату и интересность люди начинают понижать реально потраченное время и повышать спокойствие.
Исходя из этого, хороший программист - может все равно работать лучше плохих, но при этом работать хуже, чем он мог бы.
Насчет найти или воспитать. Как я писал в второй части статьи, в основ эта идея актуальна для большиъ компаний. В маленьких и так с эффективностью обычно все неплохо.
Полностью согласен, что управление многофакторная вещь и ее не загонишь в формулу (кстати, точно также как и программирование). Но это не значит, что управление нельзя слегка формализовать и оптимизировать.
Просто то, что я вижу в США, что здесь (да, что там и в Украине тоже самое) управление - это черная магия. И менеджеры с бубнами бегают вокруг команды и отгоняют злых духов. Я бы сказал, что это не слишком хорошая политика.
Но тем не менее, рукава таки засучим и с энтропией продолжаем бороться :)))
2AndrewSK: Спасибо большое
Чуть ответ на английском писать не начал, после прочтения статьи.
Я полностью согласен с Джоэлем по этому вопросу. Накопив статистику можно гораздо точнее предсказывать будущее. Кстати, мне очень понравилась идея с вероятностью сдачи проекта в день X. Действительно не обязательно ведь делать черное или белое (сдал или нет), просто менеджер может выбирать дату с той вероятностью, которая его удовлетворяет. Тот кто рискованный, может взять вероятность 70%, а сверхаккуратный выберет дату с 95% вероятностью сдачи.
Ну мне до такого додуматься тяжело, это говорил главный русскоязычный блоггер Microsoft
Схема похожа на предложенную тут:
http://blogs.technet.com/eldar/archive/2007/12/22/1547815.aspx
оопс выше уже отослали к этой статье. виноват не заметил %-)
2Dmitry: Это просто активнее курить нужно :))
2JK: Забавно, видно все читают похожие вещи…
Кстати, я раньше этого поста не видел, но действительно мысли похожи.
Витя, хорошая идея но сложная в реализации
Кстати именно она была путеводной звездой в развитии отношений владельца компании с наемными сотрудниками в одной известной нам с тобой компании
Начальники отделов должны были мотивироваться процентом от прибыли отдела.
Прибыль получалась как разница между доходами отдела (стоимость заказов пришедших в отдел от Sales) и расходами отдела (запрлата сотрудников плюс накладыне расходы).
Отдел Sales выбрасывает на внутрифирменный рынок проекты, начальники отделов соревнуются за них и получают свои бонусы после окончания проектов. Споры решает управляющая компания, которая и распределяет деньги. НО..
Вот тут и возникают много мелких и крупных НО:
1. Личности руководителей. Начальники отделов, как правило, сильные личности и часто не стыкуются и не срабатываются друг с другом и когда они начинают думать о своей выгоде в виде процента, вообще начинаются сцены выяснения отношений, достойные пера Шекспира
2. Олигополия. Отделов, которые могут выполнить конкретный проект как правило немного. Начальники отделов начинают выкручивать руки и завышать цены, и ситуация в фирме где работает 200 человек в 6-ти отделах совсем не отличается от ситуации когда в работает 20 человек. И мы вместо конкурентного рынка, получаем олигополистический рынок, со всеми его недостатками.
3. Альтернативы для руководителей. Начальник отдела должен получать достаточно большой процент, который удерживает его от того, чтобы махнуть рукой на все и пойти куда-то просто на ставку без нервных срывов и грызни за результат.
конкурентный рынок http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B2%D0%B5%D1%80%D1%88%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BA%D0%BE%D0%BD%D0%BA%D1%83%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F
олигополистический рынок http://ru.wikipedia.org/wiki/%D0%9E%D0%BB%D0%B8%D0%B3%D0%BE%D0%BF%D0%BE%D0%BB%D0%B8%D1%8F
В общем, я принимал самое непосредственное участие в построении такой или очень похожей системы в компании с примерно двумя сотнями сотрудников. Компания занималась офшорным программированием.
Могу консультировать и комментировать
работающие системы на которые интересно посмотреть:
1. Система Business Unit Management, компания Martex
“В системе Business Unit Management реализован главный принцип мотивации: если хочешь, чтобы на тебя работали, - поделись результатом. Дай долю от прибыли, и ты удивишься изобретательности и трудолюбию, которые проявят люди, работая на тебя. Потому что они будут работать на тебя и на себя.”
“Бонус в системе Business Unit Management получает руководитель подразделения, поскольку только он отвечает за поддержание прибыльности бизнеса - это условие, на котором он получил право управлять бизнесом. Как только прибыльность бизнеса нарушается, возникает угроза отзыва этого права - как лицензии на управление, и выставления ее на внутренний аукцион, в котором будут участвовать другие руководители подразделений и внешние претенденты на управление данным бизнесом.
Победитель торгов получает в управление подразделение, а старый руководитель перемещается на вторую позицию и лишается права получать бонус. Его судьбу решает новый руководитель. И если старый управленец не будет мешать своему преемнику, новый руководитель с удовольствием будет с ним работать и даже, возможно, предложит ему долю в бонусе, поскольку нуждается в соратнике, знающем “кухню” данного бизнеса. Если же старый руководитель будет вредить новому (например, из ревности), новый его уволит. ”
http://www.martex.ru/238
2. Компания Градиент
http://www.iteam.ru/publications/finances/section_43/article_219/
http://www.iteam.ru/publications/finances/section_43/article_3012/
http://www.iteam.ru/publications/finances/section_43/article_3095/
2A.Stelmakh: Действительно идея в реализации не тривиальная, требует некоторого кол-ва софта, смелости предпринимателя, готовности программистов к такой схеме.
Насчет путеводной звезды. Если даже и была, то реализация была в корне неправильная: отсутствие возможности программистов выбирать задачи, estimat’ы который программист обязан принимать и т.п.
Я бы сказал, слишком большое кол-во власти сосредоточилось в руках младшего менеджемента.
Причем власть зачатсую использовалась для отрицательной мотивации.
Описанная мной схема предполагает положительную мотивацию.
Я бы сказал, что 1), 2) и 3) как раз присущи неправильной реализации это схемы. Так как, в описанной схемы нету жесткого деления по отделам и соответственно нету олигополии (честно говоря незнакомое слово). Так как нету отделов, то особо и грызни быть не может. Предположим, есть 5-6 человек, которые в фирме берут задачи и разбивают их на меньшие. Думаю каждый из них скорее будет обеспокоен как сделать лучше дешевле свои задачи, чем выяснять с кем-то отношение.
Насчет 3), частично согласен - такая схема хороша для достаточно сильных пормально менеджеров. С другой стороны, при удачной работе они за это будут получать очень неплохие деньги.
И еще раз повторюсь, фирма, где мы работали строила абсолютно другую схему. Единственное, что в ней было общее, то что была попытка улучшить мотивацию и была некоторая попытка ввести сдельную оплату.
2A.Stelmakh: Прочел насчет олигополии. Именно поэтому я писал, что эта схема работает только для достаточно большого кол-ва человек в фирме, когда никакая группа не может сговориться и пытаться поднять цены.
Насчет “Business Unit Management”. Одна из вещей которая мне не нравиться, что всегда есть какой-то Вася который решает - давать или не давать, оставить или выгонять человека.
В фирме по описанной схеме, ты получаешь сам премию, если все делаешь правильно (что компания получает то, что хочет). И никто не может у тебя премию забрать. И с выгонянием тоже самое - делаешь все так, что у тебя денег не остается - сам уйдешь, денег остается много - за что тебя собственно выгонять?
Прочитал обе статьи. Интересно. Только, по-моему, необязательно все проецировать на большую группу желающих что-либо сделать.
Нечто подобное работает на небольшой группе (10 человек) из аналитиков-консультантов + программистов, осуществляющих внутренний ИТ-проект для неИТ-компании. Принципы очень похожие:
1. Есть цена+срок проекта всего, есть цена+срок блока задач. До цены часа/дня - не заморачивались.
2. П.1 Обсуждался на совместных собраниях исполнителей и представителей бизнеса (вплоть до генерального). Все согласились с условиями игры.
3. Есть “главные” исполнители и есть “рядовые” исполнители. В нашем случае это ведущий аналитик-консультант по проекту (методология с точки зрения бизнес-задач) и технический лидер (для руководства программистами и глобальные технические решения)
4. Есть обязательное планирование и ежедневная отчетность по задачам. Но это больше для того, чтобы вовремя реагировать на проблемы.
5. Есть ощутимая часть денег (порядка половины) которая зависит от результата. Результат - некие законченные куски, которые можно пощупать живьем и со сроком разработки не более 4 недель. Почему 4 недели? А потому что зарплата окладно-премиальная и надо по концу месяца ее рассчитать
6. Рядовые исполнители получают 100% денег в случае выполнения взятых на себя обязательств по времени и качеству. По времени обычно все понятно - по качеству сложнее. Об оценке - ниже
Если есть неудовлетворенность по времени или по качеству - с помощью неких обговоренных заранее коэффициентов сумма денег становится меньше, вплоть до голого оклада.
Как определить качество и сроки? Для этого есть п.7
7. У “главных” исполнителей сумма денег зависит от правильного выполнения бизнес-задач всеми сдаваемыми блоками (для консультанта) и выполненными сроками и отсутствием ошибок кода(допустимым, оговоренным заранее уровнем ошибок - покажите мне ПО без ошибок). Как результат в нашем случае - эти двое очень старательно гоняют своих подчиненных и друг друга (качество и сроки одного зависят от другого)
8. Недополученные в результате недовыполнения задач деньги остаются в проекте и могут быть получены другими исполнителями за перевыполнение своих+чужих планов.
9. Estimate… “Главные” обладают достаточным опытом, чтобы оценить озвученные программистами трудозатраты и программисты об этом знают. А так как главные - люди не случайные и пользуются авторитетом… Более-менее достаточный по точности и согласованный сторонами estimate присутствует.
10. Конечно, есть автоматизация процесса регистрации задач и передачи их между исполнителями.
Как мне кажется, степень достаточной схожести с предлагаемой системой (в рамках проекта), присутствует
И это - работает. Правда, должен заметить, что вот эта материальная составляющая - только часть, которая влияет на результат. И кроме того - она не единственно главная. Пример - при сдаче большого этапа нужно было сделать некие задачи в период с 30.12 по 08.01. На выбор в качестве компенсации предлагались двойная оплата или отгулы с оговоренным сроком, когда на них можно рассчитывать - в результате исполнители разделились по предпочитаемым компенсациям 50% на 50%, т.е. деньги оказались не главным “стимулятором” для половины (что было ожидаемым результатом).
Справедливости ради скажу, что:
11. Кроме указанных, есть другие стимуляторы нематериального плана, разные.
12. Людей совсем случайных в команде нет - хотя и есть те, кто появился во время проекта. Все отбирались достаточно тщательно, и в немалой степени в попытках оценить нематериальные мотивации будущего сотрудника. Т.е. человек, который сказал на собеседовании “дайте мне ХХХ денег и я буду пахать лучше всех, больше меня ничего не интересует” - однозначно не был принят на работу.
Прошу прощения, если много букв
D.Mikhantiev: Предложеная вами идея - хорошая и правильная, а главное достаточно легко внедримая. По большему счету есть даже фирмы, которые лучше или хуже это пользуют.
Однако есть несколько больших отличий от того, что предлагал
а) В моей идее введена полная зависимость от результата. Фактически убрана страховочная “подушка” в виде ставки.
б) Самое главное отличие в описанное мной схеме - то, что задачи не назначаются, а выбираются и таким образом нельзя получить “плохую” задачу. Это очень большая проблема в том, что главные хоть и главные, но они тоже ошибаются, а по деньгам страдает конечный программист (из-за чужой ошибки).
Я проходил через похожую схему и не всегда она адеквтна.
описанная в статье схема же является абсолютно независящей от чужих ошибок (в плохую сторону). То-есть человек может получить меньше денег, только если сам делает ошибки.
Ну и как результат она гораздо объективнее. Нету ситуации, что люди недовольны тем, что кто-то что-то сделал не так и теперь, а получал они меньше денег.
Victor Ronin: Отличие в изначальной схеме только одно - полная зависимость от результата
Потому что схему распределения “по выбору” мы используем. Отличие в том, что есть тем не менее некий круг задач, которые распределяются при совместном обсуждении группы. Обычно это задачи мелкие, дешевые и малоинтересные либо суперсрочные.
Мы ведь не в ИТ-компании работаем, и наши задачи - задачи вполне конкретного бизнеса.
По вашей схеме получается, что численность исполнителей должна быть N+k, где N - оптимальная численность для решения задач, k - коэффициент “настроения” (у программиста нет настроения, он дома смотрит фильм. Цитата из части первой: [i]”Лучше было бы посидеть дополнительный час, когда день на взводе и не приходить в тяжкий день. Результат был бы тем же, только вместо просиживания дня на работе, можно было пойти в тренажеру разогнать себя, почаевать дома, поглядеть фильм, да мало ли что еще.”[/i]) И тогда в соответствии с вышеприведенной “формулой счастья”
надо держать некий запас исполнителей. И тут я не готов оценить в деньгах что лучше - держать дополнительных людей или ждать, пока “муза придет” у имеющихся.
Я ведь не зря говорил, что, во-первых, люди тщательно отбираются, во-вторых имеются нематериальные стимуляторы. Хм… Пожалуй есть еще “полуматериальные” стимуляторы. И к такому я бы отнес имеющуюся у нас окладную часть, которая [b]материально[/b] гарантирует, что человек может заболеть и не остаться совсем без средств к существованию (он ведь в этот момент не делает ничего полезного с точки зрения компании), и как результат - [b]нематериальная[/b] составляющая в виде социальной защищенности, уверенности своей нужности для работодателя и т.п.
По-моему, в случае с ИТ-специалистами нематериальная составляющая мотивации у хорошего специалиста не менее 50%, у отличного - может быть больше 50%. И тогда деньги перестают работать так, как хотелось бы менеджеру
Насчет атомарности задач.
Если вы спсобны разбить проект на задачи по 8-16 часов, значит 80% работы по проекту уже сделано (аналитика + проектирование) и остался тупой кодинг. Вся сложность разработки именно в том, чтобы выявить требования, зафиксировать их, управлять их изменениями, продумать архитектуру, спроектировать систему, составить и поддерживать в актуальном состоянии план. Эффективность разработчика (на повышение которой направлена вся описанная выше система) тут не причем. Я считаю эту мысль настолько важной, что повторю ее еще раз: успешность проекта (для компании) лишь в малой степени зависит от качества и эффективности программистов.
Конечно, это справедливо, если у вас есть аналитика, архитектура и проектирование. А если вы сразу в карьер начинаете программировать систему, то тут да - все зависит от эффективности программистов.
1. Расскажите мне как в вашу схему укладывается работа аналитика, архитектора и тестера? Какие там аукционы?
При приемке каждой конкретной задачи все выглядело хорошо, но стоило собрать все вместе - выявились косяки. Делать задачу на “интеграцию”? Она будет самой непопулярной и непредсказуемой - за нее не будут браться. Кому охота склеивать куски чужого кода?
2. Не ясно как проводится приемка задачи менеджером. Программист сделал задачу на 16 часов, сдал ее, получил свои 100$. Через неделю в этой задаче нашли 20 багов. Кто их правит? А если баги “смежные”? Нельзя сказать точно чьи они и разработчики начинают перекладывать вину друг на друга (если это черевато потерями денег то это 100% начнется). Если ваш аргумент - это приемочные тесты, то кто и за какие бабки их пишет / готовит?
Также надо понять, что будут споры: разработчик будет считать что сделал задачу, а менеджер будет отказываться ее принимать, например, из-за недостаточного качества, или из-за разного толкования требований. Грызня будет сильной - каждый борется за свои деньги. В случае когда программист сидит на зарплате, ему вообще пофиг - хоть сто раз переделает этот модуль, т.к. плохие требования это не его риск, а риск компании.
3. Есть подсистема на 1000$, менеджер разбил ее на 10 задач по 100$, раздал 10 людям, каждый сделал свой кусок, но вместе вся эта хрень не работает.
4. Насчет заниженных estimate - вы говорите, что при этом разработчик потеряет максимум 8-16 часов своей оплаты. Но компания при этом теряет 1-2 человеко дня! Это бывает важно (сроки, обязательства перед заказчиками), особенно если задача на критическом пути.
5. Психологический прессинг. Не каждый человек хочет, чтобы его зарплата зависела от того объема работы который он выполняет. Многие, даже очень хорошие программисты, хотят просто приходить на работу, делать ее хорошо, читать башорг в перерывах, получать свою высокую зарплату и не париться с этой внутренней конкуренцией, аукционами, страхом ошибиться в оценке, беспокойством по внешним (относительно него) рискам, типа требований и т.п.
Короче :). Идея аукционов действительно интересна, но утопична.
Dart:
1. А чем работа аналитика, архитектора и тестера принципиально будет отличаться от программиста? И срок и качество можно оценить. Самое важное - чтобы правила оценки были оговорены и однозначно понятны всем заинтересованным сторонам.
2. Побейте зарплату за задачу на две части - за кодирование и после внедрения. А лучше на три - кодирование, тестирование и внедрение
И тут мы из области теории переходим к практике создания продукта “коллективного разума”, или к теме “Как мотивировать коллектив сделать что-либо качественно, в срок - при разумных затратах”. Уверен, что задача решаема, иначе бы не было очень многих ИТ-компаний (и не только).
3. Менеджер - плохой. Он не предусмотрел задачу интеграции. Он не получит своих денег.
5. Аукционы - не для тех, кто “честно, но вяло отрабатывают свою зарплату”. Они, по-моему, для тех, кто хочет чего-то добиться и готов рискнуть. Т.е. вообще-то изначально для наиболее эффективных и живых.
2 D.Mikhantiev:
1. Как вы это себе видите? Берем кучу тестеров и спрашиваем у них за сколько вы протестируете этот модуль? Один говорит - я за 500$, другой - я за 300$, третий - а я за 100$! Ну и кому отдавать? Может первый ошибок найдет на порядок больше чем третий? Что является приемкой работы тестера? Внедрение? Если проект будет внедряться через 1,5 года человек должен сидеть и ждать своей доли?
Аналитики. Приходит шеф и говорит - мне тут заказчик звонил, они там что-то хотят у себя автоматизировать… Я понятия не имею сколько там работы, но они готовы заплатить $500′000. За сколько денег вы готовы поехать к ним и выяснить что они хотят и написать ТЗ? И что, аналитики начинают жарко торговаться друг с другом?
Я лишь хочу сказать, что это работы которые заранее сложно оценить, и торговаться за них - бессмысленно.
А “правила оценки” работы аналитиков и архитекторов еще никто не придумал. Если вы их способны формализовать и сформулировать - вам памятник поставят.
2. Мысль хорошая. Но тут вылезает другая проблема. Чтобы получить свои деньги целиком, разработчик вынужден ждать пока его проект будет внедрен. А если он не хочет ждать? Может внедрение планируется через год? А он планирует свалить из фирмы через пару месяцев (может обстоятельства семейные)? Работу он сделал прямо сейчас - пусть сразу и платят. Как против этого спорить?
3. Замечательно :). Менеджер своих денег не получит, а разработчики? Они то свою часть работы сделали хорошо? Хорошо. Значит им нужно платить? Нужно. А из каких денег? Ведь реального суммарного результата который можно продать - нет. “Где деньги, Билли?”
Я все никак не могу понять - ответственность персональная (каждый получает деньги за свой маленький кусок работы вне зависимости от суммарного результата проекта) или коллективная (проект либо успешный и все получают свою долю, либо нет - и даже те кто работал хорошо не получат ни шиша) ? Объясните мне кто-нибудь :).
5. Да, я это и хотел сказать. Я все пытаюсь сформулировать те ограничения при которых описанная схема может работать. Одно из них, как вы верно заметили - “живая, не вялая, эффективная команда”, которая готова рисковать своими деньгами (например, стартап). Это несколько расходится с моим представлением о больших компаниях о которых говорит автор поста.
Dart:
Так как в нескольких пунктах есть вопрос про “а когда будет окончательный расчет?”, то отдельно выскажу свое мнение: все предложенное хорошо и легко может работать на небольших, четко обозначенных задачах, в идеале - на одного-двух человек, под персональную ответственность. Для достаточно больших задач - требуются дополнительные усилия по поддержанию системы и обязательные элементы коллективной ответственности.
Пример из жизни: запускаем достаточно большой кусок - после трехступенчатого тестирования (у нас тестируют: непосредственно разработчик, что совсем явных глупых ляпов нет; за ним - так называемый специалист поддержки, что все точно по методичке; за ним консультант - придумывает из головы самые невероятные бизнес-извращения) - все работает, все счастливы. Через день вопль консультанта “Оно же вот вчера работало!” Разбор полета обнаруживает кусок общего кода, который “соптимизировал” сотрудник под себя и в результате перестало работатьу других. Получил по голове (право на одну ошибку) и в свое свободное время привел общий код в исходный вид. Второй раз пошел ему в зачет как низкое качество выполняемой им работы и полученные денежки стали меньше. Третьего раза за последние 5 месяцев не было
Остальные - приняли к сведению.
1. Тестирование - это тоже работа. И у нее есть результат. Принимая на себя обязательство что-то протестировать, исполнитель подписывается под некими правилами. Например: “Результатом тестирования является полный список несоответствия продукта требованиям”.
2. Тогда он не получает полностью своих денег, так как результатов же в виде ГОТОВОГО продукта нет? По-моему - законно.
3. По-моему, надо выбирать, когда ответственность может быть персональная, когда персонально-коллективная.
5. Это может быть ОЧЕНЬ нужный продукт, когда заказчик готов закрывать глаза на получение исполнителем денег выше среднего, а исполнитель понимает, что в результате он за короткий срок приобретает нечто, в других случаях труднодостижимое за этот же срок. В больших компаниях тоже интересуются эффективностью сотрудников
2 D.Mikhantiev
Я рад что мы пришли к единому мнению, что “все предложенное хорошо и легко может работать на небольших, четко обозначенных задачах, в идеале - на одного-двух человек, под персональную ответственность”.
Но разработка серьёзного программного продукта от стадии пресейла до внедрения сюда вряд ли подойдёт…
2 Dart: По-моему, подойдет. Но с дополнительными усилиями по внедрению метода, по созданию внятного коллектива и т.п.
Предлагаю сойтись на формулировке “Идея интересная, но для практического применения без серьезной доработки напильником вряд ли годится. WARNING! Таблетка не универсальная!”
А доработка до снятия имеющихся противоречий и тонких мест - это уже несколько другая, и более обширная работа.
2D.Mikhantiev: Да, действительно людей придется держать N+k, для того, чтобы получить 100%*N. Сейчас людей держать N, но получают (условная цифра) 15%*N.
Опять же оговорюсь, что эта проблема для больших компаний. В маленьких компаниях все на виду и все обычно неплохо работают. То-есть в маленьких компаниях из-за того, что люди работают хорошо, можно получить выигрыш 50% от новых схем, но не 500% как в больших.
2Dart: ok. Разбиение задач на составные и т.п. действительно вещь сложная. Но, как и все остальное - это просто очередная задача. Разбивать на задачи можно не сразу, а постепенно:
а) Делается estimate, как я описывал. Внутри каждой крупной задачи в estimate есть время на ее подразбиение. Поэтому во время estimate не обязатльно все добивать даже до идеальной атомарности.
Когда же сверху начинают идти реальные задачи, то менеджер выделяет задачу по дальнейшему разбиению - выставляет ее на аукцион (и в этот момент например аналитик - бьет по задачам).
Точно также в задачах есть часть для тестирования, чтобы проверять, выполнена ли задача корректно.
Задача никогда не принимается не прошов тестирования. Если задача проходит тестирование - то деньги выплачиваются и дельнейшие проблемы (например баги в интеграции) - это дело менеджера, он может выделить еще одну задачу. Собственно для этого ему статистика и нужна, чтобы оценить, что
если у него есть 10 задач по 16 часов, ему нужно будет еще выделить 2 задачи по 16 часов на исправление багов по интеграции.
“Насчет заниженных estimate - вы говорите, что при этом разработчик потеряет максимум 8-16 часов своей оплаты. ” Сейчас происходит тоже самое, причем один к о