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

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

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

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

Осторожно ниже много букв. Так, что читать только морально устойчивым и заинтересованным.

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

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

А пока, разберемся, что вообще помогает программистам шустрить:

— Удобности

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

— Неотвлекательности

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

— Мозго_хорошести

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

Теперь посмотрим на каждый пункт. Удобности – хороши тем, что покупаются в магазине за 50$ и с помпой презентуются, с надеждой, что теперь программист станет ну гораздо быстрее. Замечу, что обычно эти удобности подымают эффективность ну скажем на 5%, то-бишь нужно купить дай бог десяток таких вещей, чтобы почувствовать эффект.

Неотвлекательности. С этим уже тяжелее, ну не выделишь каждому программисту офис, да и пиктограммы выбирать кто-то с менеджером должен (самому то скучно). Да и кофе подносить никто не хочет. В общем, можно конечно пару любимчиков обласкать на большую компанию – назвать их Chief Architect и порадовать их неотвлекательностями, а на всех бабок не напасешься такое делать. Но зато, эффект (сам по себе, если не считать влияние других), сразу может быть и 50% и 100%. Хотя, что уж говорить, чаще всего временный из-за пункта 3.

О… Мой любимый пункт три. Тяжко залезть в чужую голову и смотреть как там все устроено, ой как не хочется, это вам не монитор презентовать. А устроено на самом деле там все просто – если программист умный и умелый, то он может быть эффективнее на 50%, не на 30%, а в 1000% (с ноликами все в порядке), чем глупый и неумелый программист. Не помню, где уже ссылки были на все эти исследования, но если вы не верите в 1000% разницу и сами не программисты (что редкость 🙂), то пойдите спросите за сколько ведущий программист исправит хитрый баг и за сколько зеленый студент-программист, не видевшей еще вашей системы, исправит тот же баг. Думаю, вы можете получить соотношения и 1:1000.

Ok. Это я отвлекся. Мы все говорили о том, как конкретному человеку улучшить производительность, а тут начали сравнивать кого-то с кем-то. А дело ведь в том, что самые мощные программисты не рождались с встроенным знанием языка, продукта и т.п. Они этому учились. Итак, мы имеем тут две вещи, которые в какой-то мере присущи каждому — ум и опыт. Увы, ум фактически не тренируется или по крайней мере, он формируется к тому возрасту когда нанимают на работу, так что брать надо сразу умных программистов (об этому можно почитать тут). А вот опыт тренируется еще и как.

Скажите, а слабо своему программисту выделить день на то, чтобы он копался с интересными вещами (читай, как в Google) или посылать еще раз в пару месяцев на семинары на разные программистские тематики или просто давать ему потусоваться с ведущим программистом, набраться опыта. О… Тут уже цифры в денежном эквиваленте выходят покруче офиса своего, да и страшно – ты его учишь, а завтра он — «тю-тю» в фирму к конкурентам ушел. Нет уж, лучше мы ему будем таки удобные клавиатуры дарить.

Фух. Вот мы и подошли к последнему пункту, который внутри мозга сидит и который и есть та самая – волшебная формула. Это – желание, оно же и мотивация.

Хорошие программисты не дадут мне соврать (хотя может и дадут таки). 80% работы делается в 20% времени, и остальные 20% работы делается в 80% времени. Выходит это из-за того что бывает утром проснешься на взводе (кстати, стоит почитать у Губермана, поищите текст «Бывает – проснешься, как птица») и так радостно, хочется чего-нибудь сделать – идешь на работу и делаешь задачу, которая не получалась неделю в течении трех часов, причем легко так делаешь – левой пяткой. А бывает встаешь утром – за окном серо, моросит дождь (по этому поводу нужно смотреть «Одновременно» Гришковца) и плетешься на работу, одну мелкую ошибку мусолишь весь день и она не выходит, потом бросаешь ее и начинаешь перечитывать весь архив anekdot.ru, но даже от этого лучше на душе не становится.

Соответственно вопрос – а нафига было на работу приходить? Все равно пользы от проведенного времени никакой. Лучше было бы посидеть дополнительный час, когда день на взводе и не приходить в тяжкий день. Результат был бы тем же, только вместо просиживания дня на работе, можно было пойти в тренажеру разогнать себя, почаевать дома, поглядеть фильм, да мало ли что еще. Но, нет, ходит на работу Обязательно (с большой бувы «О»), иначе начальник не чувствует, что ты работаешь.

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

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

И вы действительно верите, что то, что тебе 9 месяцев назад подняли чуть (на 12% зарплату) и еще через 6 месяцев дадут бонус повлияет на то, что человек захочет сидеть дополнительные несколько часов в день когда все идет хорошо? Я бьюсь об заклад, что большинство хороших программистов с серьезным опытом на это плевать с большой горы уже. В основном они сидят на внутренней мотивации, что не хотят совсем уж заплесневеть и поэтому они что-то делают.

А теперь, представим другую ситуацию, что фирма платит за результат и позволяет не сидеть в офисы в плохие дни. Что мы имеем – программист не сидит в плохие дни, а сидит в хорошие чуть дольше. Результат для компании тот же, количество выплаченных денег то же, для программиста – работа вместо 23 дня * 8 часов, становится резко 12 дней * 10 часов. Все счастливы.

А теперь последний вираж, перед окончанием. Так вот, самая большая проблема, что хорошие программисты не мотивированы работать, даже в те самые дни когда у них все получается. Так как, хоть они будут вкалывать, хоть они будут работать еле-еле, очень мало скажется на их ЗП. Если они будут пахать – им просто подсыплют новых задач, если они будут отдыхать и чуть-чуть что-то делать, то как раз их меньше напрягать будут. И получается, что хороший (в смысле опытный и умный) программист работает с 20% эффективностью в хорошие дни и с 5% эффективность в плохие, хотя на самом деле он мог работать 100% в хорошие и с теми же 5% в плохие.

А теперь, подумаем. Если программисту начинают платить за результат, он то решит, что не стоит в хорошие дни сачковать и делать все на 20%, лучше впахать на 100% и сделать 10 дневную норму за день. Итого, легко мы получаем, что программист может вполне перейти на режим 3 дня * 12 часов * 100% эффективности = 36 эффективных часов, вместо 12 * 10 часов * 20% эффективности = 24 эффективных часов или 23 дня * 8 часов (при эффективности 20% и 5% для разных дней) = 25 эффективных часов.

То-есть мотивированный хороший программист зачастую может оказаться в 5+ раз более эффективен, чем не мотивированный. Вот она золотая формула. Кстати, золотая она и для фирмы, программисты бы пахали гораздо больше чем 3 дня в месяц и делали бы за месяц результат 3-4 нынешних — немотивированных месяцов работы, и для программистов она тоже золотая, так как получали бы программисты легко в 3-4 раза больше чем сейчас (так как им платили за результат).

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

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

Кстати, насчет корректной постановки целей и задач, смотри тут.

Зная, как будут себя бить в грудь многие программисты, крича, что они работают на 120% эффективности все время. Может вы уникум, а может вы еще в этой отрасли мало времени. Обычно по прохождению скажем 7-10 лет на работе, люди утыкаются в потолок зарплат и после этого не ищут как больше работать, а скорее ищут как бы поменьше всего делать, чтобы с своей стороны оптимизировать соотношение деньги/усилия.

Продолжение статьи можно прочесть тут.

А третью часть статьи можно прочесть здесь.