Как же всем менеджерам хочется разогнать программистов, чтобы они делали все бысто-быстро, без ошибок-без ошибок, чтобы можно бы закрыть глаза на секунду и вжик… и в дамках.
Ну, что, берет за душу? Если вы менеджер – уверен берет, если вы программист – тоже берет, хотя за другой кусок души и уже хочется разогнать всех менеджеров к чертовой бабушке 🙂
Осторожно ниже много букв. Так, что читать только морально устойчивым и заинтересованным.
Ну да ладно, перейду ближе к делу. На протяжение уже достаточно многих лет я пытаюсь вычислить формулу программистского ускорения. Что собственно нужно (и нужно было), что самому (как программисту) все сделать быстро-быстро, ну и как менеджеру, что другие программисты шуршали.
И представляете, я таки нашел эту формулу (спасибо товарищу Паше Веревкину 🙂 ). Но о ней чуть позже.
А пока, разберемся, что вообще помогает программистам шустрить:
— Удобности
Мощный компьютер, удобный стул, любимые программы на компьютере и любимая клавиатура на столе. Можно дополнять дальше, но в общем это все таки вещи, которые позволяют себя почувствовать полноценным программистом с большой буквы «П».
— Неотвлекательности
Большой просторный звукоизолированный офис в который даже менеджер может зайти только прислав за два дня запрос на это почтой, постоянно материализующееся на столе кофе с сладостями (дабы не тратить время на презренную еду), ну и тому подобные предметы роскоши. Да, и само собой никаких «умных» митингов по поводу выбора цвета пиктограммы для новой формочки.
— Мозго_хорошести
Хорошести, которые должны быть в мозге все две – мысль (причем умная), а второе желание. Этого обычно хватает.
Теперь посмотрим на каждый пункт. Удобности – хороши тем, что покупаются в магазине за 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 лет на работе, люди утыкаются в потолок зарплат и после этого не ищут как больше работать, а скорее ищут как бы поменьше всего делать, чтобы с своей стороны оптимизировать соотношение деньги/усилия.
Продолжение статьи можно прочесть тут.
А третью часть статьи можно прочесть здесь.
> А теперь, представим другую ситуацию, что фирма платит за результат и позволяет не сидеть в офисы в плохие дни.
А давайте представим что результат отрицательный 🙂 например выясняется после исследования которое проводилось программистом что мы не будем использовать эту библиотеку.
Или задача которая казалась легкой на самом деле намного сложнее и результата нет.
Или представим что производится реогранизация кода, написание автоматизированых тестов.
Вообще говоря как оценивать труд программистов никто не знает(точнее знают но у всех свое мнение 🙂 знают только что некоторые программисты _гораздо_ продуктивнее 🙂
А теперь, внимание — позитив:
Хорошо когда хороший программист мало времени сидит на работе, много успевает и получает нормальную зп.
Читайте тайм менеджмент, улучшайте персональные процессы и думайте головой 🙂
2Dmitry Gorbunov: На самом деле отрицательного результатов быть не может. Такой тип работы только подчеркнет все те проблемы, которые есть сейчас и которые обычно «заметают» под стол.
Ведь согласись — это же проблема, что планирование страдает на обе ноги. То, что estimate с реальностью чаще всего расходится на 300%. Причем, когда программисты делают очередной estimate они почему-то не берут во внимание погрешности своих прошлых ошибок estimat’ов.
И тоже самое с стороны менеджера, которые не вкладывают в проект время на реорганизацию кода и автоматизацию тестов и не просто пытаются отчитаться перед начальство, что все идет хорошо, вместо того, чтобы объективно оценивать отставание или опережение графика.
То-есть все эти вещи, станут гооораздо болезненней и люди к ним начнут относится тщательнее чем сейчас, что по большему счету только улучшит планирование и исполнение в положенные сроки.
Уверен, что переходной период будет дико тяжелый и для менеджеров и для программистов, но зато после того как это устаканится, компании которые смогут это водворить — будут иметь сумашедшее преимущество перед текущим видом компаний.
Причем здесь переход?
Я имел в виду что нелья более менее точно сравнить продуктивность 2х программистов(например).
Дать одинаковые задачи на разработку тоже не всегда работает хотя бы потому что в основном программистам приходится не писать а читать код 🙂
Нужно уметь\стараться использовать сильные стороны людей, делать так чтобы работа доставляла удовольствие, а не платить за текущий результат и сидеть в плохие дни дома.
а по поводу
>То, что estimate с реальностью чаще всего расходится на 300%. Причем, когда программисты делают очередной estimate они почему-то не берут во внимание >погрешности своих прошлых ошибок estimat’ов.
IMHO дать более менее точный эстимейт (+/- 30%) можно только после того как уже человек сделал как минимум две аналогичные задачи. В других случаях присутствуют различные риски поэтому так и получается.
но 300% это что-то многовато, хотя если это происходит постоянно то можно просто умножать на 3 🙂
2Victor and Dmytro: «Неточно составленный план требует в три раза больше времени, чем предполагалось; тщательно составленный — только в два раза.» Мерфи
много цифр 🙂 еле осилил 😉
Витя,
1. а как при таком режиме работы можно планировать релизы ? если кто-то ушел в «мозговой запой» на неделю например..
2. как ты будешь эстимэйтить под разных людей?
и вообще что-то кажется что при внедрении этой системы много сил будет уходить на сопротивление злоупотреблениями и махинациям.. и обид всяких много будет друг на друга..
кстати, похожая схема работает в Евросети, владелец которой ОФИГЕННО толковый товарищ и владелец компании которая в 2006 заняла первое место на рынке продаж сотовых телефонов России (35-40 % рынка) с оборотом $4,62 млрд.
Чичваркин: «Кроме того, сейчас хочу дать продавцам «Евросети» возможность работать по четыре часа в день. Так мы привлечем свободомыслящих людей, которые готовы работать, но хотят при этом полдня ходить по своим делам.»
http://sf-online.ru/chichvarkin/?OID=4264F4B6-D92B-4F24-A164-88AE4A910205
а вот тут он чуть говорит про схемы мотивации, правда для sales 🙂
http://sf-online.ru/chichvarkin/?OID=8E5A177F-63B8-45D9-BAD4-81119636DD27
а тут про тим-билдинги 🙂
http://sf-online.ru/chichvarkin/?OID=6995D0B6-7D92-4BA8-9525-8E74F0841558
2Dmytro Gorbunov: «Я имел в виду что нелья более менее точно сравнить продуктивность 2х программистов(например).» Да — это так. В нынешней схеме очень сложно проверять продуктивность.
«Нужно уметь\стараться использовать сильные стороны людей»
С этим согласен.
«делать так чтобы работа доставляла удовольствие, а не платить за текущий результат и сидеть в плохие дни дома.»
А вот с этим не согласен. Сейчас программистская зарплата зависит от чуть ли от всего (кол-во часов отсидки, подвешенный язык, длительность работы в компании), кроме эффективности и результата.
И лучше бы программисты в плохие (с интеллектульаной точки зрения) дни — ездили кататься на лыжах, а в хорошие — работали.
«но 300% это что-то многовато, хотя если это происходит постоянно то можно просто умножать на 3»
Частично в этом и состоит идея, что человек должен будет в этой схеме, сам найти свои множители и не морочить другим людям голову. А то, сейчас менеджеры зачастую просто гадают на гуще (так как у них нет статистики, чтобы найти множитель), а программистам вообще все равно какой estimate дать, так как если сделаешь раньше — нагрузят еще, если сделаешь позже — пожурят и забудут.
2Gef: Отличные цитаты постоянно выдаешь 😉
2A.Stelmakh: Правильные вопросы задаешь 🙂 Я как раз в следующей статье хотел это описать, про то, как планировать в такой схеме и откуда вообще должна браться оценка.
Забегая вперед. Оценка достигается путем торговли.. Менеджер выставляет задачу и говорит: «Бюджет на задачу X долларов». Петя говорит — берусь. Если, же бюджет слишком мал и никто не берется, соответственно менеджер повышает бюджет, пока кто-то не возьмется.
Я думаю, это вызовет партию следующих вопросов, но я уже детальней буду про это расказывать в посте.
Опять же про злоупотребления и махинации тоже в статье.
Вот планирование, честно говоря пока вопрос сложный. Вообще эта схема, хорошо может работать в крупной фирме (скажем 300 человек), и не применима для фирм в 30 человек.
2A.Stelmakh: Думаю Евросеть достаточно сильно отличается от IT фирм. Хотя естественно в ней могут быть применены похожие схемы.
Ситуация следующая. Стандартная схема — ЗП и отработать 184 часа, очень хорошо работала для отраслей, где эффективность фактически не играет роли.
Например, если закручивать гайки на конвеере — то если закрутил не все, вероятнее всего уволят, но закручивать быстрее чем идет конвеер тоже невозможно. Поэтому основное — равномерное и правильное выполнение и отработанное время.
Но, все отрасли в которых эффективность может колебаться в 10 раз (например продажи, IT, изобретательство, писательство и т.п.) требует новых смех, так как те кто еще неумелые — вероятнее всего приносят прибыли меньше, чем им платят, а те кто умелые, ленятся работать эффективно, так как упираются в потолок зарплат.
Пожалуй, настолько четко эту тему по-русски еще не озвучивали. Эти слова должен был кто-то сказать. Просто, как борщ, но в 99% статеек о мотивации пишут откровенную чушь. Точнее, они все пишутся эмпирическим путем, как у алхимиков: попробовали — работает, будем пробовать что-то еще.
Проблема в чем? Мотивация всегда должна быть направлена на дельту, то есть на увеличение производительности от текущего уровня. Рассмотрим две ситуации. Один программер пишет свой продукт на продажу и, ясное дело, стремится сделать это побыстрее и побезбажнее. Производительность фактически равна 100%: программер мотивирует себя по максимуму своих возможностей.
И второй пример: программер сидит на зарплате и знает, что от него хочет начальнег, как сделать вид, чтобы он заценил работу программера, а потом и зряплату ему повысил. Когда начальнега нет, программер читает баш.
Первый программер четко понимает, что он получит, если отложит баш в сторону и сконцентрируется на создании результата. Тем более, если он уже решился делать свой проект. Второй, в принципе, играется в песочнице. Каким будет проект, как юзеры отреагируют на его баги, сколько человек купят программу или воспользуются сервисом, программера не волнует, он получает свою бочку песка в месяц и развлекается как хочет. Ну, почти как хочет — чтобы взрослые не ругали и поменяли бочку на большую.
Вопрос: за что программист получает зарплату? За то, что работает работу на работе?:)
Как вообще можно измерять результат труда программиста в часах. Почему не в километрах?:) Одно дело консалтинг, когда платят за возможность получения ответов на вопросы в течение определенного периода времени, а мотиватором к результату является репутация — если схалтуришь, останешься без заказов, а если сделаешь все наилучшим образом — зоказчеги в очередь выстроятся и можно будет поднять цену. То есть лаг обратной связи краткосрочный, как и сам контракт.
Смысл деятельности программера — в создании результата, то есть работающего софта. Есть ТЗ, его нужно реализовать на таких-то условиях (срок, платформа, разные нюансы). Так вот какой смысл программеру, сидящему на стабильной белой зряплате, париться, с высунутым языком спешить писать код, чтобы преподнести его хозяину на задних лапках, виляя хвостом? Или может он будет это делать, если зряплату поднять в 2 раза?
Все хотят идти простым путем, а такого не бывает. Наивно ожидать производительности стартапа на зряплате и наивно полагать, что устроившись на позицию с такой зряплатой, можно плевать в потолок. За все нужно платить. В данном случае с позиции компании первый шаг — это внедрение схемы мотивации за значимые результаты. Сегодня чаще всего оплачиваемым «результатом» является «прийти в офис на 9 и уйти в 18». Существующие системы бонусов — капля в море. Внедрение культуры обратной связи и приближение оплачиваемых показателей от практики 19 века к реальности 21 — это непочатый край работ для бизнесменов, менеджеров, консультантов всех мастей. Это один аспект, стимулирование результатов.
Второй аспект — это устранение препятствий. Об этом часто говорят как о «нематериальной мотивации», что в принципе хорошо — на эти вещи давно пора было обратить внимание, но только если нематериальной мотивацией не пытаются подменять материальную. Дело в том, что как мотивирующие, так и демотивирующие факторы действуют по закону умножения. Всего лишь одно маленькое неудобство способно свести все мотивационные усилия на нет. Это может быть график, система контроля, неудобная мебель, транспортные проблемы и т.п. Устранение этих проблем — прежде всего в интересах компании, оно способно дать ей весомое конкурентное преимущество (тоже умножающий фактор), но боже упаси пытаться его конвертировать в относительное понижение ЗП — это может резко изменить внутренний климат компании, куда стекутся совершенно другие люди и «драйв» будет потерян.
Короче говоря, факт налицо: экономические отношения отстали от производительных сил, последние больше не укладываются в традиционную схему «работа-зарплата», а культура новых отношений еще формируется и психологически многие еще настроены на то, что уже устарело, поэтому возникают коллизии. Если говорить о долгосрочной перспективе, то все однозначно указывает на уход от долгосрочных контрактов (найм на работу) к краткосрочным, в сторону консалтинга, фриланса, «внутринимательства», отвязки от времени и места и вообще от каких-либо навязанных шаблонов. А сегодня внедрение нетрадиционных схем еще сопряжено с риском, но это как со стартапами: если сработает, синхрофазотрон останется далеко позади:)
Спасибо всем, и автору и коментаторам.
Мы уже очень давно перешли на оплату по факту. Проект начат — 30% оплачено, проект закончен — оставшиеся 70% + бонус. Вы можете сказать,- «а как же можно определить стоимость проекта еще не зная сколько реально времени на него уйдет?» Отвечу: Хороший програмист может сказать навскидку — «задача на месяц» или «2 недели и чтоб еще 2 кодера строчили под диктовку». А хороший мэнеджер посчитает все это, накинет 20% риска, снимет 10% накрутки и выдаст на гора стоимость. В качесте затравки и стимула выдаст часть денежек вперед и будет ждать результата.
Бывает, правда, что в процессе натыкается програмер на какой-то тупик и сидит над ним неделями. Вот тут хорошо бы ему обговорить с шефом и придумать вместе решение. Чаще всего тупики от усталости или от желания сделать лучше чем надо…
Кстати, нашей фирме вобще никогда не было важно сидит програмер в офисе под боком или дома, или в кафе в Гонолулу. Главное — результат.
Вот только где их брать? Програмеров, которые во-первых могут работать, а во-вторых самоорганизоваться…
2VX: Гигантское спасибо за комментарий. Полностью согласен с выводами, что все буде уходить от долгосрочной перспективе к короткосрочной и «внутринимательства».
Вообще, этот комментарий нужно было бы поместить, как выводы в конце поста. 🙂 Так как именно это я и имел в виду, и точнее я сформулировать бы не смог.
Насчет «обратной связи». Я сказал бы, что похоже внедрение везде быстрых обратных связей будет главным достижением начала XXI века. Сейчас во всех бизнесах активно внедряют это для отслеживания какие товары популярны и нет. Думаю, что аналогичные схему будут внедрены и относительно работников.
Познавательно. Уважили.
2Eugene: Отлично, что похожие вещи уже начали внедряться 😉 И появились фирмы, которые близки к описанной схеме. Оплата по факту, не сидение в офисе, ориентация на результат — это очень-очень правильные решения 🙂
Единственное, в следующей статье я опишу, куда дальше оно, как мне кажется, должно двигаться. Так как сдельная оплата для мотивации — это только общая идея (хотя и самая главная). Остальное — это просто идеи о том, как сделать, чтобы схема была гладкая и ее нельзя было легко «взломать» как со стороны менеджеров, так и со стороны программистов.
Все таки, есть множество опасных пунктов в идее «Хороший программист может сказать навскидку — задача на месяц.» Во первых, это значит, что менеджер/владелец — должен 100% доверять программисту. Доверие штука хорошая, но на больших маштабах дает сбои. Так же, программист, даже хороший склонен зачастую к преуменьшению или преувеличению estimat’ов. И это нужно учитывать в схеме (лучше с математической точки зрения), чем каждый раз пытаясь вспомнить коэффициент для конкретного программиста.
2Андрей: Спасибо 😉 Ждите продолжения. Оно будет либо сегодня позднее (по американскому времени), либо завтра.
Интересно нет ли у товарищей «внедренцев» или других руководителей реальной статистики отношения успешных проектов к неуспешным по такой схеме оценки программистов?
По моему Брукс писал что более 80% проектов требуют минимум на 50% больше времени чем запланировано — ну в общем в этом духе. Но это было давно и по-моему для крупных амер. компаний.
[…] Блог об IT бизнесе Несерьезные мысли о серьезном бизнесе от Виктора Ронина. Browse other articles in Деньги, Менеджмент, Персонал categories. « Программистский синхрофазотрон. […]
2Dmytro Gorbunov:
Честно говоря у меня нету даже статистику по обычной схеме (работа-зарплата). Ну и по новой схеме тем более статистики нет, так как она еще никуда не внедрена.
Я только что выложил статью продолжение, в которой много чего написал по поводу сбора статистики.
Так как новая схема очень удобно и хорошо позволит ее собирать. И собственно говоря, если постоянно проекты выходят на 50% больше времени, значит имеет смысл ввести коэффициент 1.5 на который умножать все задачи, а даже если точнее создавать резервное время 0.5 от размера всех задач и пользоваться его куда надо. Тогда, процентах неправильно оцененных проектов резко упадет.
[…] этим двум статьям о программистском синхрофазотроне (статья 1 и статья 2). Но читать их не обязательно (хотя […]
[…] про программистский синхрофазотрон и про тому кому выгодные плохие […]
хочу посоветовать 2 книги которые могут навести на интересные мысли, по крайней мере меня наводили 🙂
1. Дэвид Майстер Управление фирмой, оказывающей профессиональные услуги
http://www.ozon.ru/context/detail/id/1456592/
2. Под редакцией Питера Т. Чингоса Оплата по результату. Из опыта оплаты труда персонала в США
http://www.ozon.ru/context/detail/id/2138498/
Очень хорошие мысли. Особенно в начале поста.
Все упирается в давно известную стенку. Вот некоторые из проблем:
1. Если оплачивать результат — все замечательно, но как оценить вклад каждого участника проекта в результат? Если в конторе 5 человек и все друг друга знают, и есть бесспорный лидер, который «делит деньги» — это хорошо. А если компания большая? А если проект на 2 года, и состав команды за полгода сменился на 60%? Опять сводимся к пресловутым «метрикам» которые непонятно откуда взять. И это мы только о программистах говорим, а возьмите архитекторов, аналитиков, тестеров, и т.п. Как делить апельсин?
2. Очень жду описания — как бороться с махинациями со стороны программистов. Например, завышение estimates для задач, при технической безграмотности менеджмента (начальники — не программисты).
3. Схема сама по себе рискованная. Поставьте себя на место программиста. Он должен пахать много и долго, а проект может быть вообще провалится и тогда денюжек вообще не видать! Успех проекта зависит не от одного человека. А если он только пришел? А если ему семью кормить и важна стабильная зарплата — откуда ее будут платить?
Поэтому, мне кажется, что ваша схема работает только в маленьких коллективах, состоящих из очень хороших (но молодых) специалистов и для маленьких (полгода и меньше) проектов. Собственно — типичный стартап.
2Dart:
Пожалуйста прочтите продолжение, если вы его не читали, так как там есть некоторые ответы на «стенки».
1. Деньги всегда привязанны к каждой задаче. Как только задача сдела и проверена, исполнитель получает деньги. То-есть никто не сидит и не учитывает, какой вклад каждый внес. Есть 100 задач, условно говоря примерно по 100 долларов. Один сделал 30 задач — получил $3k, другой 10 задач — получил $1k.
2. Завышать estimate не будет сильно иметь смысла. Человек составивший estimate не всегда будет делать задачу. Estimate отдается менеджеру, потом тот выставляет задачи на аукцион. Вполне вероятно, это задачи возьмут другие люди. Второе, это то, что estimate будут делаться независимыми людьми и поэтому у менеджера всегда будет альтернативное мнение о том, сколько займет задача.
3. Оплата производится по окончанию задачи, а не окончанию проекта. По большему счету, провал проекта или успех проекта — это уже риски фирмы, а не человека. И именно из-за этих рисков она получает прибыль. Соответственно, как сейчас платят ЗП до того, как проект окончен, то точно также будут выплачиваться деньги по успешному окончанию каждой задачи.
По поводу того, что я написал, как раз схема расчитана на большой коллектив, с внутренней конкуренцией по задачам.
2Dart:
Пожалуйста прочтите продолжение, если вы его не читали, так как там есть некоторые ответы на «стенки».
1. Деньги всегда привязаны к каждой задаче. Как только задача сдела и проверена, исполнитель получает деньги. То-есть никто не сидит и не учитывает, какой вклад каждый внес. Есть 100 задач, условно говоря примерно по 100 долларов. Один сделал 30 задач — получил $3k, другой 10 задач — получил $1k.
2. Завышать estimate не будет сильно иметь смысла. Человек составивший estimate не всегда будет делать задачу. Estimate отдается менеджеру, потом тот выставляет задачи на аукцион. Вполне вероятно, это задачи возьмут другие люди. Второе, это то, что estimate будут делаться независимыми людьми и поэтому у менеджера всегда будет альтернативное мнение о том, сколько займет задача.
3. Оплата производится по окончанию задачи, а не окончанию проекта. По большему счету, провал проекта или успех проекта — это уже риски фирмы, а не человека. И именно из-за этих рисков она получает прибыль. Соответственно, как сейчас платят ЗП до того, как проект окончен, то точно также будут выплачиваться деньги по успешному окончанию каждой задачи.
По поводу того, что я написал, как раз схема рассчитана на большой коллектив, с внутренней конкуренцией по задачам.
Теоретика как теоретика. Все программисты мечтают о том, чтобы работать когда вздумается и еще кучу бабла за это получать. Это факт известный.
Логичный вопрос: хотя бы один пример работающей по подобной схеме компании. Компания, где программеры ходят в спортзалы когда их не прет, но при этом сдают во время проекты. Не надо гугл приводить в пример, там люди пашут, как и везде в америке. А всем показывают фотографии со спортзалами.
Yuri Shilyaev: Я знаю компанию, которая работает по принципу «хоть ночью приходи». Не буду утверждать, что все хорошо и гладко, так как проблем при этом много 🙂 Но… Живут много лет, работают исключительно на запад. Хозяин от такой схемы не очень в восторге, но из-за некоторой специфики того, что делают и ограниченного выбора специалистов на рынке — вынужден смириться из-за риска вообще не найти специалистов.
2D.Mikhantiev
Ха. 3 раза.
Если схема работает не в угоду эффективности, а в угоду чтобы вообще хоть что-то работало, то это не схема. Это выживание. Если выбор или работаем примерно вот так или вообще сдохнем, то это с математикой выше не имеет ничего общего.
2 D.Mikhantiev
Ха. 3 раза.
Если выбор стоит: работать по принципу «хоть ночью приходи» или сдохнуть… то конечно компания будет работать так. Но это не схема, это выживание. С математикой выше не имеет никакого отношения.
Автор, направьте добавление комментов. При добавлении вываливается куча варнингов при коннекте с MySQL.
2 Yuri Shilyaev:
По-моему, если рассматривать эффективность с точки зрения «есть продукт и прибыль» vs «нет продукта и прибыли» — то это эффективно. 🙂
Предлагаю термин «эффективность» не обсуждать. Потому что под «что такое эффективно» можно отдельное длииииное обсуждение затевать.
Чтобы быть совсем честным — я, менеджер, по личной инициативе позволяю сотрудникам нарушать правила трудового распорядка. Но при этом подразумевается, что за это я потребую от них множества мелких услуг и все с этим согласны 🙂 Сотрудникам — спокойнее, мне — удобнее. Конечно, есть доп условия, которые позволяют делу двигаться в нужном направлении и в нужные сроки.
а кто отвечает за провалы стыковки задач ? 🙂
ситуация — все задачи сделаны и оплачены но готового ничего нет 🙂
2 D.Mikhantiev.
http://yuri.shilyaev.com/archives/2007/09/13/373/motivatsiya-komandyi-veb-proekta.html
Я как-то на эту тему делал доклад, когда проводил секцию на конференции в Минске.
Нешто я да не пойму
При моем-то при уму?..
Чай, не лаптем щи хлебаю,
Сображаю, что к чему.
Приведенная автором модель на мой взгляд к производственному процессу имеет очень малое отношение.
2 A.Stelmakh: Не понял вопроса 🙂 Тот, кто за это ответственный и те, кто эти задачи писали. А потому что они либо профессионалы и понимают меру ответственности за результат либо ламеры неразумные и тогда должны тихо сопеть в уголочке слово «достойная зарплата» произносить только во сне).
Как-то мне плохо представляется адекватность процесса создания чего-либо из кусков без проработки связи этих кусков.
Мы наверное «результат» понимаем по-разному ;-). В моем понимании результат — это не кусок кода, пусть даже написанного просто супер с точки зрения теория программирования, а работающий автоматизированный бизнес-процесс. До этого момента результата нет, есть промежуточные итоги. Это — правило игры, которое принято всеми участниками процесса разработки (я имею ввиду там, где я работаю). Как мне кажется, с точки зрения бизнеса это единственный вариант результата.
2 D.Mikhantiev
Про «результат». Автор поста говорит о задачах по 8-16 часов, которые оплачиваются по факту выполнения, которые являются предметом аукциона между исполнителями. «Автоматизированный бизнес-процесс» за 2 дня руками одного человека это круто, вам не кажется?
Не забывайте что мы обсуждаем схему предложенную Victor Ronin.
Вопрос A.Stelmakh’а поддерживаю.
Есть менеджер, который подробил задачи и 10 программистов которые эти задачи делали. Программисты все сделали верно (по 8 часов на задачу). Но суммарный результат — нулевой. Максимум что можно сделать — не заплатить менеджеру. А дальше вопрос — как поступить с программистами? Они же честно отработали свои деньги. Но откуда эти деньги взять если суммарного результата нет? Или вы считаете что программист должен своим кошельком отвечать за провалы своего начальника? Вы бы пошли работать в такую компанию?
Имхо, если если Вы правильный директор, то чтобы менеджер правильно работал свою работу, его нужно контролировать, так же как правильный менеджер должен контролировать работу разработчиков, дизайнеров, писателей, тестировщиков и т.д. Контроль должен быть регулярным, за плохую работу на первый раз можно ограничится усными пилюлями и уже начинать искать замену раздолбаю, за повторное нарушение можно в принципе не увольнять сразу, а брать на место человека замену, а человека ставить помощником у нового. Если он поймет свою ошибку, то подождет своего второго шанса.
Наемный менеджер — такой же работник, как и все. Если Вы — кодер, то приходя в контору, отдавайте предпочтение тому месту, где менеджеры контролируются директором (или посредством отдела контроля качества), а не являются сами себе хозяинами и диктуют свои условия руководству. Это разумеется не имеет отношения к случаям, когда компания просто собирается перепродавать ваш труд, т.е. все риски и менеджемент находятся на стороне клиента. Конечно таких контор (где менеджеры контролируются руководством не по результату, а по ходу работы) очень мало. Но зато можно быть более менее уверенным, что там не будет проблем с тем, что на кодера повесят собак и не заплатят ему за работу.
2D.Mikhantiev
По-моему результат — это полученные за проект деньги 🙂 Dart ниже абсолютно точно сказал то, что я сказал чуть неуклюже 🙂
2Dart:
Именно это я и имел в виду. Спасибо 🙂
2 Yuri Shilyaev. Тезисы доклада посмотрел. Противоречий с темой — не нашел. 🙂 Обсуждаемая здесь идея — часть большой проблемы управления.
2 Dart. Хм… Смотря что за процесс и что за задача по нему. Например — «Процесс отгрузки готовой продукции», к нему надо прикрутить вариант «Процесс отгрузки за пределы страны». При каких-то условиях это реально.
Про «кто ответственнен». Так как ответственность нельзя передать, а проект пошел сверху… То где-то там и надо искать ответственных. Где-то мне попадалась статистика причин провалов ИТ-проектов, и там 40% было за «Невнимание руководства к проекту».
В обсуждении «Программистский синхрофазотрон продолжается.» http://victorronin.com/2008/01/06/programmistskij-sinxrofazotron-prodolzhaetsya/#comment-405 я предложил закончить дискуссию «работает/не работает» формулировкой «надо дорабатывать напильником». Потому что из «теоретически…» (что есть разминка для ума), начинаем сваливаться в «а кто должен быть ответственным» — а это уже создание готовой системы мотивации и написание регламентов.
Если есть желание продолжить обсуждение деталей и вариантов разрешения противоречий идеи — предлагаю сменить поле битвы. В смысле общения 🙂
Фух… Сообщений набралось не мало. Будут отвечать, скопом скорее чем на каждое, а то весь день можно будет тут просидеть 🙂
Добавление комментов буду сегодня править. Меня самого достало, что там какие-то глюки.
Теперь по сути.
а) Ответственный за задачу каждый несет на своем уровне — программист, на уровне маленькой (8-16) часов задачи, которые он взялся. Менеджер младшего звена ответственен за 80-160 часов блоки (в том числе и сведение их воедино) — он создает аукционы на меленькие задачи, их сведение и т.п. (что-то может делать сам). Менеджер старшего звена ответственен за сведение еще большие блоки — 800-1600 часов (он разбивает их и выставляет на аукцион для менеджеров младшего звена) и т.п.
Если все сделано, но оно никому не нужно — это проблема директоров — они ставили задачу.
Результат на каждом уровне — это не кусок кода, это я бы сказал модуль. Чем ближе оно к прогрммисту, тем больше это действительно код, чем ближе оно подымается к директору, тем больше — это становится готовым продуктом — с инсталятором, документацие, слайдами и т.п.
2Yuri Shilyaev: Да — это теоретика и игра ума в данный момент. Схема дико рискована и я согласен с D.Mikhantiev, что ее надо дорабатывать напильником. Однако, я считаю, что схема не просто имеет права на жизнь, но еще и будет хорошо работать.
По сравнению с 80% фирм, где люди просто отсиживают часы, она будет очень эффективной.
Кстати, слово эффективно бояться не стоит. Можно, конечно свалиться в глубокое обсуждение, что это. Но как по мне — это выдача требуемого результа/время.
2Dart: Насчет суммарного результата, я уже отписал. Например пишется простой почтовый клиент.
Каждый на своем уровне отвечает за выполнение поставленной задачи. Один из программист отвечает за написание Base64 кодировки, один младший менеджер за написание модуля по пересылки attachment’ов, один старший менеджер за всю работу с протоколами, VP — за продукт, директор — за идею.
Соотвественно, если на уровне директора обнаружилось, что продукт работает, только никому не нужен , это уж точно не проблема программистов. И кстати, это проблема не имеет ничего общего с тем, как платить программистам.
Если же например обнаружилось, что Base64 не нужен — это проблема младшего менеджера — он дал выполнение лишней задачи.
2D.Mikhantiev: В смысле, на что, сменить поле битвы/общения?
Вставлю свои пять копеек 🙂
Мне кажется что предложенная схема работы уж слишком идеальна — задачи в ней легко разбиваются на независимые части, точные спецификации ко всем без исключения задачам есть, требования не меняются, багов нет, программисты одновременно пишут код, коменты (которые всегда актуальны), хелп, инсталяторы и (о ужас !) слайды.
Хотелось бы увидеть ответы на такие вопросы
1. Как вообще с багами? Кто будет исправлять ошибки связанные с интеграцией модулей? менеджеры ?:)
Просто например задачи «напишите что то» и «и напишите что то что будет использоваться 10ком модулей в разных режимах даже мб на разных платформах» это разные задачи. Чтобы это понять достаточно взглянуть на код STL например и на код самописного контейнера.
2. Как будут проходить изменения требований в процессе разработки? (и не надо говорить что такого никогда не бывает 🙂
3. Как сделать чтобы Вася который делает модуль А и Петя который делает модуль Б не писали разных вспомогательных функций которые выполняют одну и ту же задачу?
Хотя последний вопрос это не только по продложеной схеме но все равно.
Всегда ваш :))
Горбунов Дмитрий
2Dmytro Gorbunov: Я думаю, нужно сразу разделить проблемы, которые присущи любой системе с любой оплатой от тех которые относятся именно к этой.
Например, когда делали — делали, а потом оказалось, что оно не нужно или все надо переделать (по бизнеса причинам, а не по техническим) — так в любой системе выйдет, что деньги уже «проедены», а делать нужно еще что-то.
Теперь по пунктам
1) Ошибки связанные с интеграцией будут выделяться в отдельную задачу. То-есть у менеджера есть 5 задача сделать 5 моделей и 2 задачи исправление ошибок интеграции.
2) Когда меняются требования, то они выделяются из бюджета менеджера, который их меняет. Например, если директор их меняет, то он дает на estimate задачу, сколько займут изменения — после чего выставляет большую задачу по изменениям на аукцион. Если какой-то средний менеджер меняет, то он делает это из своего бюджета.
3) Это проблема не имеет отношения к какой либо схеме
В общем основная идея схемы — кто неправ, тот пусть и платит. Когда неправых много — то это должно закладываться коеффициентами в estimate и быть специальных задачи на интерацию и т.п.
Есть такое мнение, что чем штрафовать, лучше уволить.
Люди — они обидчивые.
2A.Stelmakh: Даже и не знаю. Очень зависит от ситуации. Если человек первый раз запорол — то просто нужно объяснить, второй раз запорол — штрафовать и еще раз объяснить, третий — пожалуй таки увольнять.
Да и штрафы бывают разные. Когда проммиста штрафуют по субъективным причинам — то естественно он обижается, а вот если по объективным — то это воспринимается легче (не скажу легко).
В этой системе программист сам берется за задачу у которой написаны, сроки, оплата, задача. И если он не вписался — то это его проблема и она сразу видна.
Другое дело, когда происходит как сейчас — программисут выдает менеджер задачу с сроками и без согласия программиста. В таком случае всегда можно обижаться.
Витя, а вот скажи ты сам в подобной схеме согласишься работать?
и на сколько ты хочешь больше получать с рисками штрафов, чем на стабильной ставке ?
а может просто пойти консультантом ? отвечаешь только за свой опыт и получаешь больше 🙂
2A.Stelmakh: Я бы в такой схеме хотел бы попробовать работать. Причем вероятнее всего я бы тогда даже в бизнес не рвался. Эта схема позволяет с увеличением опыта, умений и знаний в проекте постоянно увеличивать свой доход.
Консультанство — это все равно оплата за часы, а не за результат. ч
Единственная похожая вещь — это делать проект по fixed cost. Но, если самому начинать искать проекты, общаться с заказчиком и т.п. делать, то большинство времени уйдет на не программирование, да и это уже ближе будет таки к стартованию бизнеса, чем к программированию.
Собственно именно зарплатный потолок и сподвигнул меня заняться бизнесом. И потолок в зарплатах есть фактически всегда. Мне лично обидно осознавать, что если я стану в 5 раз более продуктивным, то это будет оценено в виде 20% надбавки к ЗП.
[…] статье про программистский синхрофазотрон мы вели дискуссию с D.Mikhantiev о том, кто должен […]
[…] Источник — Блог Виктора Ронина […]
[…] На эту тему я писал о программистском синхрофазотроне. […]
[…] своем блоге сделал интересную заметку насчет статьи о программистском синхрофазотроне. Что по большему счету, я пытаюсь найти серебренную […]
Да счет хороших дней согласен!
Был я в одной компании там можно приходить на работу когда хочешь, офис работает 7 дней в неделю 24 часа в сутки:) Так что как тебе по ритму удобнее так и работаешь.
А вот по поводу разгона менеджеров тоже далеко за примером ходить не надо, сосед мой работает через инет и день у него начинается с мата, потому что кто-то из менеджеров снова переписал ТЗ:)
Ну, кстати, я не ратую за разгон менеджеров. Просто менеджеры должны выполнять свою работу (причем хорошо), а программисты свою.
Но, свободный график — просто необходим.
Насчет переписывания ТЗ. В этой схеме очень хорошо это будет давать по голове. Переписал менеджер ТЗ — изволь из своего кармана оплачивать изменения. Сразу начнут продумывать наперед ТЗ и не пытаться их менять по каждому чиху. Аналогично для программистов, дали ТЗ, а наваял что-то к нему не относящееся — увы денежку не дают.
Для этих целей и придумали тот же agile, чтобы можно было хоть раз в неделю переписывать ТЗ и от этого никто не страдал. Потому что это зачастую не прихоть, а необходимость.
В целом, текущая схема не решает нормально вопроса мотивирования деньгами.
Поэтому и получается, что все делают свою работу левой ногой.
Опять же, та же agile — дело хорошее, но если хороший программист, видит, что делает в 10 раз больше, а получает на 10% больше, то обычно его продуктивность постепенно падает и никакой agile этому не поможет.
Свободный график — это психология фрилансера. Даже если ты не проснулся «на взводе» есть много способов поднять тонус, спортзал (на крайняк элементарная зарядка) с утра перед работой, нормальный сон 8 часов в сутки. Не отрицаю, биоритм у разных людей разный, у меня самого график плавает в пределах нескольких часов, но при этом все знают, что я железно в офисе с 11 до 18 (т.е. график плавает от 9-18 до 11-20). «Мозговые запои» на неделю — это вообще недопустимо, особенно для проектов на 1-2 человека! Хороший программист должен думать не только о себе, но и о компании и её заказчиках.
Честно говоря, я не совсем понял комментарий за или против это идеи. Но, все же хочу чуть растолковать несколько пунктов
> я железно в офисе с 11 до 18
> Мозговые запои” на неделю — это вообще недопустимо
>Хороший программист должен думать не только о себе
То, что вы описали — это классика жанра. Все эти вещи необходимы, для поддержания работоспособности текущих фирм.
Если же фирму строить по описанной в посте схеме, то основной тезис станет
«Оплата по результату.». А дальше уже каждый может оптимизировать как ему удобно, чтобы выдать наибольший результат.
Свободный график и оплата по результату годится для небольшого проекта на одного человека, где есть ТЗ и чёткие сроки. А когда проект живой и динамичный, когда каждый день новые задания, с разными приоритетами, а в офисе никого, у одного запой, у другого бабушка заболела, третьему просто лень было на работу приходить и всё, проект завален.
Не согласен.
Как раз на проекте из одного человека оплата по результату не всегда годится. Подбил человек денег и исчез на 3 месяца (а тут изменения, которые нужно внести, и он единственный, кто вообще что-то в проекте знает).
А вот, когда проект состоит из 100 человек. Да, 20% всегда заботяться о бабушке и леняться, но 80% активно работают над проектом.
Плюс, опять же живой динамический проект — значит, просто на разных уровнях менеджмента будут выделяться деньги из буфферных на изменения.
[…] Как “разогнать” программиста, рецепт Виктора Ронина: Программистский синхрофазотрон […]
[…] красивую статью на эту тему нашел здесь. […]
почитал пару ваших заметок… виктор, а может рановато еще писать такие рецепты ?
фуфло, если честно.
где-то поверхностно, где-то вообще в степи широкие забегаете….
Дорогой zwitter, я решил на 10 лет удалиться в монастырь шаолинь и оттачивать свой разум. Когда я буду готов, я вернусь на белом коне и выдам ЕДИНСТВЕННУЮ и ПОСЛЕДНЮЮ истину. 😉
А если чуть серьезнее. Писать заметки никогда не рановато и никогда не поздновато. Это уж дело читателей отделять зерна от плевел.
Что конкретно в этой статье вам показалось не правильно?
P.S. Пожалуйста прочтите статью Либо старо, либо мало. Не слишком ли у вас много критериев по отбору правильных статей?
Пиши -пиши Виктор. Не обращай внмания на такие коментарии.
Меня всегда поражали эти завистливые люди, которым лишь бы обосрать что-то.
Если Вы, zwitter, такой умный, зачем же Вы потратили свое время на то, чтобы оставить этот коментарий. И с какой целью Вы его оставили?
Та, я пишу 🙂
Меня просто тоже поражает, когда приходит человек и выдает фразу, а-ля
«Все говно, один я в белом фраке». Причем дается без аргументации.
И ведь действительно люди тратят время на
— прочесть несколько статей
— написать говно-комментарий
Наверное мне не понять их. Может это такой метод поднятия самооценки?
Хи… А они не читают 🙂 Они сразу пишут ГК.
Черт. Я же в душе оптимизатор, а не дошел до такой простой истины 🙂