Victor Ronin's IT blog

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

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

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

Ну, начнем с того, что мотивировать программистов, нужно только в случае, если 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. Спасибо этим вот товарищам: Макс Крайнов, Сергей Корнилов, за то, что поставили на меня ссылки в статьях и привели ко мне людей. Если вы их еще не читаете, очень рекомендую 🙂

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

This entry was posted on Воскресенье, Январь 6th, 2008 at 10:25 пп and is filed under Деньги, Менеджмент, Персонал, Эффективность. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.