Итак, как я говорил в первой части статьи (лучше всего ее прочесть включая комментарии) текущий метод работы – от забора до обеда устарел. Фактически для программистов старый момент работы полностью убивает мотивацию, так как зарплата не зависит от результатов. И самый лучший метод мотивировать программистов – сдельная оплаты, когда программистам выгоднее всего делать все быстро и качественно, чтобы получить как можно больше денег, за как можно меньший промежуток времени.
Есть уже компании, где частично это сделано – в виде сдельной оплаты, однако, это только первый шаг в том, чтобы сделать нормальную систему с хорошей обратной связью. Тем не менее большинство компаний, пока боятся сделать даже этот шаг.
Погрузимся же в пучины страхов предпринимателей и программистов и как все организовать, чтобы все были счастливы.
Ну, начнем с того, что мотивировать программистов, нужно только в случае, если 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. Спасибо этим вот товарищам: Макс Крайнов, Сергей Корнилов, за то, что поставили на меня ссылки в статьях и привели ко мне людей. Если вы их еще не читаете, очень рекомендую 🙂
Очередную (третью часть) этой статьи можно прочесть тут.
[…] Блог об IT бизнесе Несерьезные мысли о серьезном бизнесе от Виктора Ронина. Browse other articles in Мысли вслух categories. « Программистский синхрофазотрон продолжается. […]
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% вероятностью сдачи.
[…] Менеджмент, Персонал categories. « Государство и бизнес. Программистский синхрофазотрон продолжается. […]
Ну мне до такого додуматься тяжело, это говорил главный русскоязычный блоггер 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 часов своей оплаты. » Сейчас происходит тоже самое, причем один к одному, только вот за это ответственен программист, а не компания. А сейчас именно компания оплачивает такие проблемы.
Психологичести, это схема тяжелая только в начале. Когда хороший программист за месяц сможет поднять две своих зарплаты, тут же все психологические проблемы отключатся.
2Dart & D.Mikhantiev: Согласен, что эта схема лучше работает для четко обозначинных проектов, чем для чего-то расплывчатого.
Теперь, то что я вижу, что постоянно обсужается
а) Деньги заплатили, результат нет
б) Кто за все это ответственный.
в) Что делать с непредвиденными задачи
В вкратце, может частично повторюсь, то что писал в комментариях к первой статье
а) Деньги выплачиваются по результу. То-есть когда задача, сделана, протестирована, продокументирована и менеджер сказал — все ok, тогда они выплачиваются. Никто не платит деньги
вперед или за неизвестный результат
б) Ответственный каждый за свою задачу, на своем уровне. Поэтому, если проект идиотический изначально, а программисты получили свои деньги — это проблема директора. Программисты свою работу сделали нормально и наоборот, если кто-то не может сделать из программистов свою задачу вовремя — это его проблемы, так как он согласился уже на цену.
в) Во первых, за это и платиться остаток денег менеджерам, чтобы не было совсем уж непредвиденных задач или задач, которые не влазят в буферное время. Для этого и ведется статистика.
Кстати, мне кажется неправильна взят прицел на оценку этой идеи. Ее нужно сравнивать не с идеалом, а с текущими системами. Она должна всего лишь быть лучше чем они.
Ни одна из текущих систем тоже не решает нормально проблем типа- задача сделана, но никому не нужна или появилась непредсказуемая задача (а кто за это будет платить?) и т.п.
Еще раз соглашусь, все требует четкой доработки напильником. Но как я писал, для больших и медленных компаний, это может не просто поднять эффективность, а просто взвить ее.
Витя, помнишь что из-за системы 75%\25% произошло с одной компанией?
опять на эти грабли отложенных выплат наступать?
а знаешь как тяжело НЕ ДАТЬ денег тому кто считает что их ему ДОЛЖНЫ ?
потом такие сказки про тебя придумывают и про то что ты сказал 🙂
тут уже нужно глубоко понимать как думает большинство сотрудников=людей
🙂
2A.Stelmakh: Ситуация следующая — система 75% по оконачанию задачи /25% по окончанию проекта не совсем честна в смысле, что если проект затянулся или завалился НЕ по вине программиста, то программист ждет своих 25% и он прав, что ему их должны.
В описанной схеме, программист может не получить своих денег, только в том случае если он НЕ сделал свою задачу корректно. Как только он делает задачу, он получает деньги. Аналогично с менеджером.
ОК. менеджер захочет брать на себя огромный риск ?
проект на $100 000
пусть себестоимость (зп + накладные расходы) $75 000
длительность — год.
сколько идет на бонусы менеджеру?
и в % от его годовой зп это сколько?
что будут делать владельцы, если выдано зп + накладные расходы $75 000 и проект не сдан, $80 000, $95 000 и проект все еще не сдан.. нужно выдавать задачи на багфикс, за какие деньги?
менеджер зная наперед правила, постоянно смотрит на места альтернативного получения денег — и сваливает как только чувствует что тут пахнет жереным. Разве нет ?
2A.Stelmakh: Оk. Отделяем разные проблемы
а) Потрачено X, а проект не сдан. И что делать дальше? Это проблема есть в любой схеме.
Хотя, вопрос конечно правильный — если на уровне программиста задача оказалась больше, чем он ожидал — он ее может вернуть и фирма денег еще не потратила. Если на уровне менеджера задача оказалась больше чем он ожидал, он не может ее вернуть, так как деньги уже потрачены.
Да, пожалуй это тонкий момент этой системы. У меня нету ответа прямо сейчас. Я подумаю над этим.
б) Зарплаты у менеджеров нет — они получают полностью остаток от бюджета по своей задачи, когда она считается выполненной.
в) Из-за того, что ЗП нет, и все живут с выполнения задач, то если менеджер уйдет до выполнения задачи — не получит денег вообще (что вряд ли его привлечет).
Зато в случае хорошего выполнения задачи — он вполне может получить хороший кусок от размера задачи.
Суммируя — основной вопрос состоит в том, что делать с задачами, которые оказались больше (на уровне менеджера) и то, что менеджеру нужно долго ждать, пока закончиться задача, чтобы получить свои деньги.
думаю нужно менеджмент мотивировать по долгосрочным целям.
1. Про это хорошо пишет Warren Buffet в книге об инвестициях он рассказывает как мотивирует своих управляющих. могу выложить куски.
2. А также я выше линки посылал на книгу о истории схем мотивации в США.
А я вижу основную проблему в том, что если проект на $1 000 000 и себестоимость его $500 000, то можно менеджеру пообещать ОГРОМНЫЙ куш за успех и он будет работать как зверь.
А если расходы на проект $950 000, то нужно передавать проект туда, где его себестоимость ниже так как хороших менеджеров за эти деньги нет, им проще живется на стабильных ставках.
и тут главный ответ: если владельцы(акционеры) выбирают первый вариант, то все равно от риска провала никто их не спасает даже с супер-дорогим менеджером, а есть ли альтернативы ? есть!!! это промышленный подход к разработке ПО с хорошими процессами 🙂
На самом деле, основная идея предложенной схемы, чтобы туже самую сумму запихнуть в меньшие сроки.
Если раньше тратилось $1M за год и получался продукт, идея в том, чтобы сделать этот продукт за пол года и потратить тот же $1M. Таким образом, для фирмы суммарные затраты на продукт — те же самые, а для все работников, это значит повышение прибыли в 2 раза (так как они получают те же деньги, за более короткий срок).
И ускорение должно быть из-за того, что люди будут знать, что чем быстрее сделают, тем быстрее получат деньги.
В остальном, эта схема имеет те же недостатки, что и остальные.
Еще один контраргумент схеме с аукционами. В ней предполагается что в любой момент времени число потенциальных исполнителей задач гораздо больше чем их нужно для выполнения этой задачи. Именно по этому у них есть возможность торговаться. В реальной жизни все наоборот :). Работы много — людей мало. Задачу дают не тому кто лучше торговался, а тому у кого в данный момент ниже загруженность работой :).
Теперь про менеджеров. Если у него вообще нет оклада, то как тут правильно заметили он попытается свалить, когда увидит что шансов уложиться в хорошую прибыль — нет. А в реальной жизни, даже если проект убыточен, фирме важно довести его до конца чтобы хоть как-то компенсировать свои издержки. Пример, проект на 1 млн., а потрачено 900 тыс, и ясно что еще придется потратить 300 тыс. Ни один менеджер не станет доделывать этот проект, потому что 900 тыс. уже ушло на оплату труда программистов, и он вообще ни копейки уже с этого проекта не поимеет. Но для компании важно чтобы менеджер этот проект доделал. Если доделает убытки будут только 200 тыс, а если все бросить — 900 ты + возможная потеря клиента. В реальной жизни эта проблема решается с помощью высокой зарплаты менеджера. В вашей схеме не ясно что заставит менеджера доделывать убыточный проект.
Я все вспоминал что мне напоминает эта схема. Потом понял — это rentacoder. Все что вы описали — это именно оно. И аукционы, и маленькие задачи, и оплата по факту…
Итого. Более разумной мне видиться такой подход:
Все работники получают фиксированную з/п которая устанавливается при приеме на работу + корректируется с помощью различных аттестаций и review.
Помимо этого проектная команда получает бонус по завершению проекта. Например, половина прибыли проекта идет на премии. И, например, половина этой премии идет менеджеру.
Получаем «позитивную» мотивацию — сделай проект быстрее \ дешевле, получи больше премию. Но нет негативной «если не выполнил задачу — отвечай кошельком». Максимум чего лишиться работник — проектной премии. Я думаю, что с точки зрения работника такая схема более привлекательна — меньше риски и есть за что впахивать. Насколько я знаю, подобная схема применяется в некоторых компаниях…
2Dart: Насчет того, что количество исполнителей нужно больше чем в обычном случае — уже обсуждал с кем-то. Я думаю людей на самом деле понадобиться примерно столько же сколько при классической схеме.
С одной стороны
— нужно больше людей для аукциона
— нужно больше людей, так как работать будут не по 184 часа в месяца
С другой стороны
— из-за увеличения эффективности, количество необходимых людей станет меньше
Насчет RentACoder. Оно похоже тремя вещами — аукцион и оплата по факту и конкуренция. Но тем не менее оно отличается следующими моментами
— взятие задач и подразбиение их на подзадачи (такого на RentACoder не видел)
— сбор централизованной статистики по задачам для более точной оценки будущих задач.
(это крайне важный пункт, так как получается что каждая компания собирает данные, а чаще не собирает, на размере 10 человек). Данные должны собираться с сотни людей и тогда за год они будут действительно точными.
Насчет менеджеров. Это действительно единственный сложный момент в этой системе. На уровне программистов задачу можно вернуть не потратив деньги, на уровне менеджеров — это невозможно.
Я бы сказал, что когда возникает ситуация 900k потрачено, запас на уровне менеджера 100k, а нужно еще 300k и если есть выбор — либо теряем, либо доделываем — то менеджер должен общаться с менеджером более высшего звена, чтобы он ему выдал деньги из своего запаса.
Ведь, невыполненая одна из задач — это проблема и вышестоящего менеджера тоже.
Насчет удерживания высокой ЗП менеджеров. Опять же, описанная схема рассчитана на то, чтобы как можно быстрее делать задачи и тем самым получать больше денег за единицу времени. Таким образом, не только программисты в результате получат в 3 раза большие ЗП, но и менеджеры. Уверен, что для хорошего менеджера по новой схеме, нынешние стандартные ЗП будут просто смешными.
Насчет только «позитивной» мотивации. Проблема возникает в том, что появляется дикое количество субъективных вещей которые влияют на премию. Например, как распределять премию между программистами? Кто это будет решать? Разные аттестации и review, которые тоже достаточно субъективны (особенно в большой бюрократической компании).
Да, внутри описанной схемы, можно получить и отрицательную мотивацию. Кстати, на уровне программистов потерять деньги невозможно, можно их только не получить (то-есть работать в 0).
Но зато, количество субъективных вещей сведено к минимуму и поэтому оплата впрямую зависит от качества работы, а не подковерных политических игр.
Victor Ronin: У меня возникло ощущение, что проблема методики для задач объемом большим, чем для одного исполнителя, кроется в том, что предусмотрена только единоличная ответственность. А на больших проектах единоличной ответственности, по-моему, не может быть. И если принять некую долю коллективной ответственности, то с вопросами «кто отвечает за…» будет, IMHO, проще.
Victor Ronin: И еще к проблеме «кто за это ответит…»
«Если ты хочешь построить корабль, не надо созывать людей, чтобы все спланировать, разделить работу, достать инструменты и рубить деревья. Надо заразить их стремлением к бесконечному морю. Тогда они сами построят корабль.»
Сент-Экзюпери
2D.Mikhantiev: Я полностью согласен с вами для маленьких сплоченных коллективов. Я бы сказал, небольшая группка сплоченных хороших специалистов, может рвать проекты без всякой дополнительной мотивации. Им просто интересно работать с другими толковыми людьми и им хочется построить корабль.
А теперь возьмем организацию на эдак пятьсот человек:
а) политические игры
б) малый процент толковых людей
в) наверх выбираются бюрократы, а не хорошие менеджеры
и т.п.
В такой схеме, очень тяжело вдохнуть в людей какие-то высшие идеи. Обычно люди приходят просто отработать 8 часов, получить деньги и пойти домой. Причем даже самые хорошие компании с ростом обретают все эти признаки.
Именно для таких компаний эта схема и рассчитана. Не помню в комментариях к какой статье A.Stelmakh писал что большим компаниям нужно добавлять предпринимательство снизу. Я согласен с ним, что большие компании без этого становяться слишком «грузными»
Victor Ronin: Не согласен про маленькие и большие коллективы. Это вопрос, как мне кажется, корпоративной культуры.
Никакая мотивация, по-моему, не будет работать при отсутствии общей цели, идеи. Описанная организация — вообще работать не будет и умрет. Конечно не сразу, а долго и тяжело, потому что большая.
Работа над корпоративной культурой, созданием соответствующей атмостферы — это тяжкий труд в первую очередь ТОПов. И смотрите, что получается (я все к самому большому противоречию обсуждаемой схемы — «кто отвечает?»):
— чтобы схема работала, надо ее «запустить» в компанию, это может сделать только ТОП-менеджмент;
— чтобы схема работала за счет единоличной ответственности — рядовые сотрудники должны эту ответственность понимать и принимать на себя; причем чтобы большинство было таких (а тем более в крупной организации) — надо все тем же ТОПам предпринимать много усилий по созданию соответсвующего коллектива;
— все проекты запускаются с уровня ТОПов.
IMHO. Что получается? За все отвечают ТОПы. Без их понимания и постоянной работы — не будет действовать ни одна, самая замечательная в теории, схема. Вот и ответ — кто виноват. В описанной у вас компании не будут работать те, кто хочет чего-то добиться, а тех, кто останется, в большей степени устраивает работа ни шатко ни валко, за ограниченную зарплату, с ограниченными потребностями — зато без напряжени.
Про «предпринимательство снизу» — это, по-моему, элемент корпоративной культуры, и опять же просто так «от сырости», он не может появиться и, тем более, заработать. И снова возвращаемся к теме ТОПов…
D.Mikhantiev: Да, естественно в любом коллективе за корпоративную культуру (да и вообще за все изменения и свершения) в конечном счете отвечают том менеджеры. И я согласен, что предпринимательство снизу само как грибы не вырастет.
Почему, я везде говорю о больших vs. маленьких коллективов. Просто в маленьких коллективах, культура обычно складывается сама неплохая — владелец активно работает, показывая пример другим, все чувствуют себя частью компании. В большой компании — владельца в управление чаще всего уже нет, наемные директора уже не так усердны и никто не чувствует себя причастным к компании.
Поэтому, да таки топ менеджеры могут в большой компании пытаться организовать корпоративную культуру аналогичную маленькой компании, но это граничит между пунктами невозможно и оочень тяжело. В маленькой же оно само собой организовывается.
Я предлагаю тему культуры перенести. Я сегодня напишу отдельный пост и там можно будет под деталькам ее разобрать 🙂
[…] Продолжение статьи можно прочесть тут. […]
Я у себя в блоге оставил, здесь просто целиком скопирую:
Надысь набрел на статью «Программистский синхрофазотрон» (+часть 2) о методах повышения производительности программистов — предлагается разбивать проект на элементарные задачи и устраивать мини-аукцион среди программистов. Таким образом, программисты будут получать по результатам и будут стараться изо всех сил уложиться в сроки и требования. Чем-то это похоже на обычный аутсорсинг. Забавно, но автор принципиально пытается решить два фундаментальных экономических ограничения:
1. Рынок vs фирма. С точки зрения цены товара/услуги — рынок («обычный») предлагает самую оптимальную цену. Поэтому идеальным было бы вообще покупать услуги по программированию на стороне. И, собственно говоря, автор и предлагает внести во внутрикорпоративную модель этот самый рынок — дескать, программисты будут выступать в виде мини-фирм, оттого будет конкуренция и всеобщая благодать (рациональные сроки и наименьшая цена). Вот только автор забывает про транзакционные расходы и риски, свойственные рынку: в данном случае есть издержки на организацию торгов, контроль адекватности оценки и т.п.; риск срыва сроков или предоставления товара/услуги ненадлежащего качества. Кроме того, реальный рынок отличается от идеального тем, что участникам недоступна вся информация для принятия решения. Разница с аутсорсингом прежде всего в размере услуги/товара, торгуемого на этом мини-рынке, с одной стороны, а с другой стороны — это рынок покупателя, так как у программиста, «работающего» в такой фирме, нет альтернативного спроса.
2. Человеческие ресурсы — такие же ограниченные ресурсы. И, условно говоря, людей с требуемой квалификацией (программист Си) есть, например, 10%. Людей, обладающих предпринимательскими способностями, например, тоже 10%. Вероятность того, что найдется программист Си, обладающий предпринимательской способностью — всего лишь 1%. Т.е. реально работать в предлагаемой автором модели может быть ничтожно малое количество людей.
Таким образом, возможно создать фирму, в которой будут реализованы эти принципы, но это будет скорее исключение, нежели образец для подражания.
2Serge_Kond:
возможно если представить фирму в виде распределенной сети, не ограниченной рамками города, а также представить несколько конкурирующих сетей, то перспектива становится менее призрачной 😉
также не думаю что работа по такой схеме требует предпринимательских способностей, нужно просто быть чуть лучше других и обладать небольшой жадностью или эгоизмом. А таких людей гораздо больше чем 1% 🙂
2A.Stelmakh:
Видите, ли в макроэкономике и микроэкономике субъекты квантуются до конечных потребителей (иногда до домохозяйств) и фирм (индивидуальный предприниматель в т.ч.). В.Ронин пытается решить задачу минимизации издержек, разделяя фирму на отдельные самостоятельные элементы, некий «рынок» в себе. Следовательно, это решение можно анализировать с точки зрения существующих принципов, не внося в модель неких сетей. Фирма же вообще может располагаться не только в 1 городе, а, например, в нескольких странах.
Как вы назовете квалифицирующий признак — жадность, эгоизм, предпринимательский талант — не важно. Важно, что это, грубо говоря, перемножение вероятностей снижает доступное количество таких ресурсов. Я ж не отрицаю возможность такого решения. Просто оно имеет очевидное ограничение.
Я на самом деле советую ознакомиться с книгой Тома Демарко и Тимоти Листера «Человеческий фактор: успешные проекты и команды». Можно почитать «Мифический человеко-месяц» и кучу других книг — но во всех них вопрос взаимосвязи ЗП и мотивации — последний.
2Serge_Kond : Я прочел ваши комментарии (второй три таза). Увы я недостаточно подкован в экономике и терминологии, чтобы ответить на достойном уровне.
То, что я могу сказать, что — это действительно похоже на аутсорсинг. Однако есть несколько отличительных особенностей
а) За выполнение задачи берется человек, а не фирма. Количетсво программистов в фирме гораздо меньше, чем фирм в мире.
Благодаря этим двум факторами — возможно накопление статистики, которая является ключевой для этой идеи.
б) Издержки есть всегда. В данной схемы количество издержек больше чем в текущей. Однако, я бы сказал, что они гораздо легче автоматизируются и как результат это может снизить их стоимость.
2A.Stelmakh: Да, фирма не обязательно должна находиться в одном месте.
Кстати, насчет 10% программистов на C++ и из них 10% предпринимателей. Предприниматель — это не клеймо при рождение, это такая же как C++ область знаний. Находясь внутри данной схемы количество предпринимателей в фирме быстро вырастет с 10% до 90%.
2Serge_Kond:
эти книги я читал, спасибо 🙂
1. я привел Вам пример как можно увеличить открытость и повысить конкурентность на рынке, который похож на олигополию, а также показал каким образом создать конкурентный рынок для исполнителей.
2. перемножение вероятностей я понимаю, я говорю, что предпринимателями тут не надо быть в классическом понимании этого слова, и 10% это мало для оценки количества таких людей 🙂 Следовательно с количеством людей все не так плохо.
основные проблемы предложенного подхода — в сложности реализации 🙂 с транзакционными расходами и рисками согласен.