Традиционный способ измерения задач в нашей отрасли – часы. Давайте посчитаем, сколько метрик в часах мы используем.
Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.
Вторые часы – те, что назвал программист, отвечая на вопрос «сколько тебе надо времени на решение задачи?». Если мы договариваемся с клиентом заранее, то именно эти часы и выставляем для продажи. Если оплата идет по факту, то мы спрашиваем оценку у программиста для целей планирования.
Третьи часы – сколько программист потратил на решение задачи по факту. С той плановой цифрой, которую он сам назвал, эти часы совпадают крайне редко, и это нормально – никто не умеет точно планировать свое время, потому что на работу программиста действует множество сил из окружающей среды – он отвлекается, он не в настроении, он сталкивается с непредвиденными трудностями и т.д.
Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.
А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?
Можно ответить туманно: эффективность работы программиста. Хорошо, а как, и что мы будем измерять? В наличии у нас, напоминаю, три или четыре вида часов.
Попробуйте сказать программисту: хотим, чтобы ты производил больше часов. Что он ответит? Программист – парень толковый, в институте учился, и он сразу вспомнит о пятой метрике – количестве часов в сутках. И смело вам об этом скажет – я не могу работать больше, чем 24 часа в сутки, побойтесь Бога.
Еще теорию относительности вспомнит. Пусть не в деталях, но о невозможности сжатия времени точно упомянет – мы ведь не движемся на скоростях, близких к световой?
Если часы не сжимаются, то как повышать эффективность? Как о ней вообще можно говорить? Как ее вообще посчитать можно? Сколько часов на час работы потратил программист? Потрать на час работы полчаса? Как составить формулу? Без формулы ведь и расчетов никаких не получится, и цель не поставишь.
Давайте зайдем с другой стороны. Представьте себе не программиста, а рабочего на заводе. Вот он стоит, бедняга, целую смену у станка и производит детали. Как планируется его работа? Допустим, сто деталей в смену. Смена длится восемь часов, получается 4.8 минуты на одну деталь.
А теперь представьте: мы, с нашими подходами к измерению работы, пришли руководить этим рабочим. Мы больше не говорим ему «сделай 100 деталей», мы любим измерять в часах, поэтому новый план рабочего будет звучать, как «сделай 8 часов в смену».
Он, конечно, поначалу посчитает нас идиотами. Спросит – а деталей сколько надо сделать? Неважно, ответим мы. Главное – часы. Мы понимаем, что действуют вариации, ты там покурить ходишь, с дружбанами поболтать, но средний чек себе представляем – 4.8 минуты на деталь. Поэтому сделай нам 100 раз по 4.8 минут своей работы.
Поначалу он, конечно, будет стараться следовать старому плану, но, когда увидит свою расчетку, жизненные ценности поменяются – там будет написано «начислено столько-то за 20 смен по 8 часов». Какой ему теперь смысл вообще делать детали, если оплачивается только время, проведенное у станка?
Если нас к тому времени с завода еще не выгонят, то мы и систему продаж поменяем. Мы не будем продавать клиентам детали – в счетах будут часы, потраченные нашими рабочими. Просит клиент 100 деталей, мы уходим подумать, потом присылаем счет – 8 часов работы специалиста. Клиент удивляется, но соглашается, и счет оплачивает. А через пару дней получает еще «прибавку» — пару часов. Ну а что, так получилось. Не смог рабочий уложиться в 8 часов.
Клиенты начинают возмущаться – да что за черт, какие часы? Нам детали нужны! В штуках, коробках, паллетах, вагонах – не важно. Нам без разницы, сколько часов надо на их производство!
Тут, думаю, нас точно выгонят. Вернут учет в штуках – и внутренний, и внешний, для клиентов. И займутся эффективностью.
Где здесь эффективность, какова ее формула? Ответ очевиден: чем больше деталей в единицу времени производит рабочий, или цех, или весь завод, тем лучше. Разумеется, при соблюдении технологии, приличном качестве и без затаривания склада.
Но формула эффективности очевидна – штуки в час. И направления для приложения усилий менеджмента очевидны, по повышению эффективности.
Мы же, удрученные, возвращаемся к своим программистам. И тоже хотим простую и понятную формулу расчета эффективности. А что у нас там? Часы, часы, кругом – часы.
Теперь вы уже понимаете, что не так с часами. Часы измеряют время – неподвластное вам физическое явление, которое происходило, происходит и будет происходить всегда. Неважно, работаете вы или нет, существует ваша фирма или закрылась, есть у вас клиенты или нет – время будет идти, и измеряться оно будет в часах.
Все, что вы можете – это распоряжаться своей деятельностью в часы, отпущенные вам Трудовым Кодексом, т.е. что-то производить, и как-то измерять то, что производите.
В случае с заводом все понятно – там есть измерение в натуральных единицах. Штуки, литры, погонные, квадратные или кубические метры. А с нами, программистами, как быть? В чем измерять наши задачи, кроме часов?
Первое, что приходит в голову – штуки. Но такая мысль нежизнеспособна – слишком высока вариация между задачами.
На самом деле, ответ уже давно найден в т.н. гибких методологиях разработки, наподобие скрама. Метод называется «Покер планирования».
В каких единицах измеряются задачи в покере планирования? Ответ необычный – в любых. Называйте их так, как хотите. Собаки, попугаи, табуретки, баллы, очки – не важно. Наиболее распространенное название – story points (стори пойнтс, очки историй). Лично мне нравится более простое и лаконичное – баллы. Его я и буду использовать в ходе дальнейшего изложения. Вы, разумеется, можете выбрать любое другое.
Ключевая особенность баллов – их относительность. Это не единица измерений из какого-то классификатора, а уникальная для каждой компании, или даже команды, шкала. Одна и та же задача, в двух разных командах, может быть оценена по-разному. Где-то – пять баллов, где-то – тринадцать, и т.д.
Количество баллов – это и есть натуральная величина задачи. Та самая оценка, которой нам не хватало.
Методика покера планирования рекомендует использовать оценки из ряда Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 34 и т.д. баллов, где каждый последующий элемент равен сумме двух предыдущих. Причина проста: нужно, чтобы межу оценками была существенная разница. Довольно трудно выбрать оценку между, например, 5 и 6 баллами. Намного проще – между 5 и 8, или 8 и 13.
Проводить оценку в команде методика рекомендует так. Всем участникам команды необходимо раздать карточки с написанными на них оценками (из ряда Фибоначчи). Можно приобрести специальные карты для покера планирования, если хочется какой-то красоты, но для простоты достаточно взять обычные маленькие бумажки для записей, вроде стикеров, только без клейкой полосы.
Итак, команда собралась, у каждого на руках – карточки. Объявляется задача, перечисляются ее особенности и детали – так, чтобы все поняли, что надо сделать. После этого каждый участник делает свою оценку – выбирает одну из карточек – и кладет ее на стол рубашкой вверх (так, чтобы не было видно оценку).
Когда все оценили, карты переворачиваются, и выполняется ключевая проверка – не должно быть оценок, отстоящих друг от друга более, чем на один элемент ряда Фибоначчи.
Например, оценки 5 и 8 – нормально, а 3 и 8 – не годятся. Слишком большой разбег в оценках говорит о том, что кто-то чего-то не понял. Тот, кто поставил низкую оценку, либо слишком много знает (например, уже решал такую задачу), либо ничего не понял и слишком оптимистичен.
Так же и высокая оценка может говорить о непонимании задачи. Например, программист просто никогда не решал подобных задач, или они связаны с неизвестными ему механизмами платформы, и он, на всякий случай, про запас, ставит высокую оценку.
В любом случае, если оценки сильно разошлись, нужно повторное обсуждение – прояснить детали, обговорить тонкости, выдать максимум информации. Когда обсуждение проведено, оценка выполняется повторно. Если потребуется – снова и снова, пока оценки не будут отстоять друг от друга не более, чем на один элемент ряда.
Иногда полезно исключить кого-то из членов команды из оценки конкретной задачи. Например, если в команде есть стажер, то ему хоть объясняй, хоть не объясняй – он не поймет, в чем сложность или, наоборот, простота задачи. В итоге он просто согласится, и поставит нужную оценку, чтобы не задерживать команду.
Такой результат не несет в себе никакой ценности, потому что превращает покер планирования в пустую формальность. Поэтому я рекомендую простое правило: в оценке задачи участвую только люди, что-либо понимающие в задаче. Не понимаешь – просто сиди и слушай.
Разумеется, иногда бывает так, что в задаче понимает только один человек. Например, если она относится к какой-то очень специфичной, редко применяемой области знаний. Ничего страшного, пусть будет одна оценка.
Бывает и крайний случай – никто не понимает, как решать задачу. Тоже ничего страшного – ставим, что получилось, потом разберемся.
Когда оценки выставлены, считается среднее арифметическое – это и будет итоговая оценка задачи. В гибких методологиях ее записывают на стикер и вешают на доску, но я рекомендую просто внести ее в вашу информационную систему, где вы записываете задачи. Разумеется, предварительно надо добавить соответствующее поле.
Другой алгоритм оценки – без использования команды. Например, баллы может проставлять руководитель, или лидер, или самый толковый программист. Обычно к этому алгоритму переходят после того, как несколько недель или месяцев поиграют в покер всей командой.
Причина проста: надо, чтобы все участники команды привыкли к системе оценки. Прониклись ею, научились быстро оценивать задачи, и не смотрели на баллы, как баран на новые ворота. Когда привычка выработалась, можно отдавать оценку одному человеку. Разумеется, оставив команде право на высказывание своего мнения – никто не идеален, и руководитель может ошибаться в оценках.
Иногда у команд возникают трудности при начале работы с баллами – никто не знает, что выбрать за точку отсчета. Я рекомендую выбрать несколько якорей – типовых задач, которые вы периодически решаете.
Первый якорь – самая простая задача. Обычно, насколько я знаю, время работы программистов тарифицируется кратно 15 минутам. Какие задачи вы обычно решаете за 15 минут? Простой отчет? Добавление пользователя в базу? Заполнение адресного классификатора?
Вот этой задаче стоит дать оценку в 1 балл. В дальнейшем вы будете на нее ориентироваться.
Можно добавить еще несколько якорей, в зависимости от вашей специфики. Например, простой внешний отчет по одному остаточному регистру, без наворотов с оформлением, без кода в форме и модуле – пусть будет 3 балла. Добавить реквизит в документ и вывести на форму, без обработки ввода и проверок – пусть будет 2 балла. И т.д.
Важно, чтобы эти якоря выбрала сама команда, согласилась с ними и использовала в дальнейшем. Оценки относительны, и якоря будут играть роль отправных точек.
Теперь все наши задачи измерены в натуральных единицах – баллах. Мы знаем, сколько баллов выполнили за неделю, месяц, год и т.д. Нам известно, сколько баллов производит каждый из программистов. Мы четко видим, сколько баллов «весят» нерешенные задачи.
Но главное – мы знаем эффективность, как отношение баллов к часам. Проще, конечно, считать баллы в день.
Один программист производит 4 балла в день, другой – 8, третий – 2. На прошлой неделе мы сделали 50 баллов, на этой – 80, значит – наша эффективность повысилась.
Цель повышения эффективности тоже становится очевидной: надо научиться производить больше баллов в единицу времени. Время, как мы знаем, неподвластно нашему влиянию, а вот количество решенных баллов – еще как. Собственно, именно этому мы и будем учиться дальше.
Баллы – это ключевая система координат, которая будет использована в дальнейшем изложении. Это – обязательный раздел, который нельзя пропустить. Нет особого смысла внедрять какие-то другие методы, пока не посчитаны баллы. Понимаете, почему?
Потому, что вы не сможете оценить действенность примененных методов. Как понять, стало лучше или хуже, не обладая цифрами? Никак, только фантазировать остается. Менеджмент, основанный на фантазиях и иллюзиях, конечно, очень широко распространен, но для повышения эффективности он не годится.
Открою небольшой секрет: внедрив систему оценки задач в баллах, вы уже можете повысить эффективность работы команды программистов. Иногда даже вдвое, я проверял эту гипотезу несколько раз.
Причина проста – появляется реальная прозрачность. Иллюзии исчезают, остаются голые цифры. Вкупе с оплаченными клиентом часами вы получаете достаточно мощную систему учета эффективности. Люди, увидев свои цифры, сами начнут работать лучше, потому что больше не смогут прятаться за часами.
Поэтому, не откладывая в долгий ящик, сделайте в своей системе учет задач в баллах. Это совсем несложно, особенно если у вас используется система на платформе 1С – достаточно добавить числовое поле к объекту метаданных, который хранит ваши задачи. Ну и написать несколько отчетов по балльной системе – сколько задач решено, кем, когда, сколько еще не принято в работу, сколько ожидает принятия заказчиком и т.д.
Резюме
- Измерение задач только в часах лишает вас возможности повысить эффективность;
- Измерять задачи лучше в натуральных единицах – баллах;
- Начинать внедрение баллов лучше с командного покера планирования;
- Когда система оценок станет понятна команде, можно отдать оценку одному человеку;
- Оценка в баллах дает понимание эффективности;
- Учет баллов обязательно нужно автоматизировать.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Иван, благодарю Вас за полезную информацию. Очень хочу применить новую систему оценки работы программистов в своей деятельности. Есть сомнение: после перехода на учет трудозатрат в баллах придется изменить базу для расчета сдельной части оплаты. И я понимаю, что сумма з/п станет меньше. Как правильно организовать такой переход, чтобы не распугать исполнителей? Нельзя же сказать, что с завтрашнего дня у нас меняется система ценностей и я заранее становлюсь недоволен тем результатом, который обычно устраивал?
(1) за баллы платить нельзя, как мне кажется, они слишком зыбкие.
Лучше традиционные схемы. Для фикси — оклад, для франча — сделка.
Просто оцениваемый результат станет более многомерным.
Например, для франча к выработке в часах и подписанным актам по проектам добавятся баллы.
Тогда оценка станет более комплексной, и потому — более объективной.
Пока фирма разработчик будет повышать свою эффективность, придумывая способы как повысить эффективность, за это время частники уже успеют сделать 80% задач и про них забыть.
Вот честно, непонятно для чего нужна оценка эффективности?
На первый взгляд кажется, что такой вопрос сам по себе глупый. Ведь понятно, что информация о том, сколько конкретной «пользы» производит каждый работник, является важной. Но если вникать в этот вопрос глубже, то в среде 1С все не так однозначно.
Далее идут вопросы типа:
1. Что с этой информацией делать?
2. Кому и где эта информация полезна?
3. Не выйдет ли так, что получение этой информации будет занимать слишком много ресурсов-времени?
Вот я вижу, что основной целью повышения эффективности для компании разработчика, это уменьшение себестоимости с одной стороны, и увеличение производительности с другой.
Получается, что для составления шкалы баллов по каждому проекту нужно потратить время. Это время в любом случае не уменьшает себестоимость, а наоборот. Себестоимость может сыграть главную роль в конкуренции на рынке.
А потом сказать работникам, что данная задача будет оценена в 2 балла, потому что так решил лидер.
По сути это звучит так: Мы коллектив, или еще хуже, — Я лидер решил что за эту задачу исполнитель получит 2 балла, потому что по моему мнению, я ее сделаю за 30 мин». Проще говоря — ты можешь делать эту задачу сколько хочешь, но оплатят тебе 30 мин.
С увеличением производительности здесь тоже проблема.
Потому что — «не сколько хочешь», — а «сколько нужно». Ведь у исполнителя все равно будут спрашивать планируемое время выполнения задачи, т. к. эта оценка необходима для календарного планирования и графика работ.
Короче сплошной диссонанс. Вся эта история больше похожа на утопию.
Это когда тебя клиент просит сделать ему расчет итогов в колонке — Количество, хотя в одном документе может встречаться и весовой товар и штучный. Информация вроде бы и полезная, но бессмысленная.
(3) вы абсолютно правы все так и делают.
(1) во первых, чемпионы свое уже отработали и теперь архитектурой занимаются другие.
Во вторых, результат это то что требуется заказчику. Если заказчику требуется из по ГОСТ, то его нужно сделать. И задача РП помочь исполнителю или правильно составить команду, которая сможет не только декомпозировать задачу на более мелкие и выполнить по частям не более двух-трех баллов каждая, но и собрать из этого результат.
Важно кроме декомпозиции задач еще и сохранить их логическую взаимосвязь. Если один сотрудник может поглотить сразу запоем объем в несколько десятков декомпозированных частей и воспринимать их как одну задачу из блока автоматизации склада в рамках проекта внедрения системы, то другой должен взять и сдать именно часть
хвоста собакизадачи, оцененную не более чем в 2 балла.Разница между внешним и внутренним проектом в том что изменение требований — когда вчера заказчику это надо, а завтра уже может быть не актуально — должны обрабатываться на внутреннем проекте.
На самом деле мы знаем за сколько баллов программиста заставили сделать задачу.
Мне видимо, все равно не понятен процесс оценки задач. Скажите пожалуйста, чем руководствуются оценщики?
Вот задача:
Сделать в Бух 3.0 подсистему учета Путевых листов и топлива в баках автотранспорта.
Для этого нужно сделать как минимум:
— справочник Автотранспорт или доработать справочник Основные средства.
— справочник Марки автотранспорта и нормы расхода
— документ Путевой лист
— отчет Ведомость учета горючего
— регистр сведений Показатели автотранспорта
— сделать ввод списания ГСМ на основании путевого листа.
Ну и как в баллах будут оценивать данную работу?
Что даст эта оценка, если эта задача может и не повторится больше никогда, а разработчик ее делал 10 часов? И фактически потраченное время известно станет по окончании разработки, и это без учета тестирования?
Короче вопросов у меня больше …. одни вопросы, и ни одного ответа.
(7) тут бессмысленно пытаться ответы получить, надо пробовать. Хотя бы на себе.
Вот как бы я оценил задачи:
— справочник Автотранспорт или доработать справочник Основные средства. — 3-5 баллов;
— справочник Марки автотранспорта и нормы расхода — 3-5 баллов;
— документ Путевой лист — 8-13 баллов (если он большой и сложный, как обычно бывает);
— отчет Ведомость учета горючего — 5 баллов;
— регистр сведений Показатели автотранспорта — 5-8 баллов;
— сделать ввод списания ГСМ на основании путевого листа — 5-8 баллов.
Итого 29-42 балла, если не ошибся.
Ну 29-44. И что дальше?
Я завожу себе такое поле — количество балов, и записываю в него что? 29-44?
Кроме того у меня в задаче указано фактическое время решения задачи, например 15 часов.
Т.е. я могу получить среднее количество балов в час.
А что дальше?
Извините что мучаю вопросами. Я действительно хочу понять и разобраться.
Имеется ввиду вероятно что после добавления путевого листа в конфигурации трёх клиентов.вы будете делать это в полтора раза быстрее, а после двадцати даже с закрытыми глазами.
При этом оценка останется прежней. Вы сможете увидеть насколько вырос ваш профессионализм.
(9) я указал диапазон, т.к. «Путевой лист» — очень растяжимое понятие, тут нужно больше деталей.
Дальше — указываете баллы в задаче, и садитесь ее выполнять. В каждой задаче указываете баллы и выполняете ее.
Делаете себе отчет, который покажет по дням, неделям и месяцам, сколько баллов задач вы выполнили.
А через месяц напишите, что получилось. Если на самом деле интересно, то на днях еще пара статей выйдет с рекомендациями. Если их примените, то результат должен получиться весьма неплохим.
в качестве побочного эффекта со временем может возникнуть инфляция или дефляция в паре баллы в час… 🙂
После того как я «зашью» этот модуль в расширение, я его буду ставить клиенту за одну минуту.
А через какое то время я сделаю магазин расширений, и клиенты сами смогут его установит, оплатить и обновить.
Так что дело как раз не в этом.
Получается что в идеале нужно нормировать работы, просто оценка будет не в минутах-часах, а в баллах.
Например автосервис особенно крупный всегда нормирует работы. Там используются громадные каталоги с нормами и расценками за каждую работу.
Видимо я все равно здесь чего-то не понимаю.
Понимаю идею — зачем это нужно,
Понимаю чем руководствоваться при оценке: чем сложнее задаче, тем больше баллов.
Понятно, что сразу выработать правильный баланс оценок не возможно, нужно сделать несколько первых замеров.
Это как начертить с линейкой длинную прямую через две точки, но когда длинны линейки не хватает от начала до конца. Нужно сперва нанести промежуточные точки и чертить по ним.
Не понимаю что с этим делать дальше.
Получил я марте 100 баллов за 22 рабочих дня на сумму 200 т. руб.
В следующем месяце наработал 80 баллов, но заработал 300 т. руб. (меньше работал, но продал какие-то готовые решения)
В следующем месяце наоборот, заработал 150 баллов, т.к. делал сложные задачи, но заработал — 40 т. руб. т.к. делал эти задачи первый раз, многое не учел и фин потери взял на себя потому, что с клиентом была оговорена стоимость заранее.
Что мне это дает?
Что я в последнем месяце работал менее эффективно?
И да и Нет. Я по жадничал времени на анализ задачи, но получил огромное количество опыта.
Что я работал в убыток? И да, и нет.
Нет — потому что это прямая инвестиция в опыт и готовые наработки-решения.
Да — только тогда, когда есть фин. отдел и бюджет на месяц, и часовая или дневная расценка.
Тогда исходя из этой расценки, если бы я делал обычные задачи, то заработал бы гораздо больше.
Тогда в последнем месяце из-за этого маневра, я не дополучил прибыль — упустил.
Но если рассматривать фин. год, и таких задач было несколько, тогда этот маневр, может принести 100% и более прибыли, потому что следующие задачи удалось решить практически не затратив времени.
Т.е. оценка сложности задачи в баллах осталась бы прежней, но время на ее выполнения уменьшилась бы в разы.
Или в этом случае и оценку в баллах нужно тоже уменьшать?
(12) да, может.
Дефляцию, кстати, можно сознательно устраивать, я так делал.
(13) кажется, вы забегаете слишком далеко вперед.
Продажу готовых решений сюда примешивать не надо. Их разработку — да, а продажу — нет.
Если вы решили задачу в первый раз, оценили в 13 балов, а потом просто вставляете готовое решение, то правильно будет переоценить задачу, в смысле переоценку сделать — оставить, например, 1-3 балла за внедрение готового решения.
«Всегда готовьтесь ко всему и как можно заранее»
Карл фон Клаузевиц «О войне» …
Тогда мне не понятно вот это утверждение и ниже.
Если мы знаем что задачу можно выполнить быстрее, а значит и эффективнее, тогда ее оценку в баллах нужно уменьшать. Тогда вопрос продажи и распределения прибыли решать отдельно, а эффективность отдельно. И между собой их не переплетать.
Но это неизбежно произойдет, т.к. станет простым инструментом управления. Любимым для руководства. Сказал что сделаешь за 5 баллов — делай. и, мягко говоря, никого не волнует.
Вася наработал 50 баллов за месяц, а Петя 200. Но все и так знают, что Петя тянет крупных клиентов, и работает 24/7 и имеет 20 лет опыта. Какие к нему могут быть вопросы.
«Учитель объявляет ученикам:
— Наша школа переходит на бальную систему оценки. Теперь цифры заменяем буквами от A, B, C и т.д. Учиться нужно теперь хорошо, потому что теперь вместо двойки я вам дам по E-баллу.»
(Хорошо работать одному на предприятии, нет оценок в баллах, только рубли и критерий всего один — база работает или не работает).
(18) вы не знали, что задачу можно решить быстрее, пока не перевели ее в баллы. В моем примере были согласованы часы — по 4 на каждую. Без баллов программисты и решали бы их за 4 часа каждую. Потому что действует закон Паркинсона — человек выполняет работу столько времени, сколько на нее отпущено.
В примере про Петю и Васю есть, чем заняться. Например, сделать так, чтобы Петя продолжал делать 200 баллов, но перестал работать 24/7 — это вредно для здоровья. Пусть делает те же 200 баллов за восьмичасовой рабочий день.
(19) одному на предприятии работать хорошо. Плохо только, что это — не навсегда.
Я как понимаю это можно использовать только для повышения эффективности работы программистов. Но как быть в такой и ситуации, хотелось бы понять:
Пример:
1 месяц:
Всего было 30 задач
Программист1 — 80 попугаев (10 задач)
Программист2 — 75 попугаев (8 задач)
Программист3 — 90 попугаев (9 задач)
2 месяц:
Всего было 10 задач
Программист1 — 30 попугаев (2 задачи)
Программист2 — 50 попугаев (5 задач)
Программист3 — 25 попугаев (3 задачи)
В итоге какая формула по расчету эффективности?
Если в идеале отбросить использование бальной системе в системе мотивации, тогда я вижу что использовать методику можно для получения точной информации о том, какие задачи решают программисты (простые-сложные), а так же динамику изменения сложности задач, а не то — насколько эффективно эти задачи были сделаны.
Эта информация может быть полезна для:
— повышения квалификации отдельных специалистов.
— изменения ценовой политики.
Например, разделить спецов на категории 1,2 и т. д. уровня, и для клиента озвучивать стоимость за работу спеца разных категорий по разному.
Я встречал такой подход в веб. студиях. Кодер 20S/час, — аналитик 30, архитектор-40 и т.д.
— не представляю даже сколько придется воевать с руководством, чтобы отстоять мнение, что эту оценку не нужно использовать в системе мотивации и и оплаты — короче готовится к борьбе…, Только нужно ли это тому, кто эту инициативу захочет проявить?
(8)
А это важно.
(23)
Я встречал такой подход в веб. студиях. Кодер 20S/час, — аналитик 30, архитектор-40 и т.д.
Озвучивание клиенту стоимости разных специалистов прямой путь к работе веб студии за тарелку супа.
Как только озвучил из чего складывается себестоимость услуг тут же начинают продавливать по деньгам. В сфере услуг сплошь и рядом.
У меня на предприятии производят очень сложные наукоёмкие(делают их кандидаты наук и тд и по ходу пишут диссертации и получают патенты) приборы, так один покупатель попросил прислать спецификацию с расшифровкой себестоимости изделия мотивируя это тем что ему надо знать за что он платит деньги… вот и откуда такие берутся.
(15) это правильное направление. Но по нему следует пройти чуть дальше.
У вас появляется клиент с задачей.
Задача это спрос. Будете ли вы делать задание при нем с нуля или закажете аутсорсеру/ фикси или есть готовые но требует адаптации это ваша коммерческая тайна, ноу хау.
Вам необходимо оценить сколько клиент готов за это платить и в какие суммы и сроки вы уложитесь.
Первая проблема у программистов нет навыка продаж и это будет делать менеджер.
Вторая проблема у программистов нет навыков передачи части работ на субподряд это тоже менеджер.
Третья проблема сколько два менеджера будут платить одному своему программисту, который как правило будет только адаптировать (типовые или выполненные аутсорсерами), если со всеми остальными программистами оценка за сдельную работу идёт в деньгах (а не в часах и не в баллах) и их обьемов в вашей базе нет.
Это значит что работы, превышающие какой то пороговый объем будут отсекаться и только рост профессионализма позволит брать за те же сроки и деньги большие объемы. Т.е. оценка в баллах призвана быстро ответить сможете ли вы поднять какой то проект не проседая по текущим задачам.
Сколько баллов стоит прочитать эту статью? 13 баллов — нормально будет? А с комментами?
(27) написать — 15 баллов.
Прочитать — 3 балла.
Комментов мало, так что прочитать с комментами — 5 баллов.
(22) продуктивность и эффективность упали одинаково низко, если программисты на окладе (затраты на достижение результата одинаковы от месяца к месяцу).
Но, вообще, тут вроде всё понятно. Есть чем заняться.
(23) зачем с кем-то воевать? Систему вполне можно внедрить втихаря, для внутреннего использования. Она добавит элемент игры и поднимет настроение.
А если нет — всегда можно выкинуть.
Ну и, вообще, учет в баллах — лишь первый этап на пути повышения эффективности. Можно и без него обойтись, но будет сложнее.
(28)Не цените вы своих читателей ((
Они стараются, тратят время, а вы 3 балла….
(30) Любые элементы игры повышают настроение только когда в целом все неплохо и все адекватные.
Итак, сидят в отделе условно 6 человек в двух кабинетах. В рабочее время явка обязательна, тех.обслуживание пользователей и ввод забытых паролей, после окончания рабочего дня перестановки оборудования, обновления продакшн и так каждый день.
И тут появляется новый начальник с учётом баллов и элементами игры.
(29) Как она могла упасть, если всего было в один месяц 30 задач, которые они все не сделали, а в другой было 10 задач и они все выполнили. Короче тут все не так просто и не всегда можно адекватно оценить эффективность. Плюс вы так и не ответили по какой формуле вычислять эффективность.
Размышляя над это статьей у меня все время не выходит из головы одна мысль, засела как параноя.
Мне все время кажется, что основной замысел, перевести в балы подсчет интеллектуального труда состоит в следующем.
1. Обесценить или снизить значимость этого самого труда. Чтобы работники этой сферы, не привязывались к потраченному времени, и не могли использовать конкуренцию на рынке или внутри компании для личных целей. Причем не просто не могли, а даже и не пытались. Чтобы у них не было критериев для оценки своих возможностей в часах. Автор приводил понятный пример выработки изделий в штуках, но для нематериального актива это пример не годится.
Давайте уйдем от программистов и возьмем условного писателя художественной литературы.
И давайте возьмем издательство, которое захочет внедрить бальную систему. Там тоже есть заказы и на переводы текстов и на статьи и на худ. литературу. Сразу становится понятным что бальная система на основании сложности работать не будет. Думаю даже объяснять не нужно почему.
Или возьмем учителя англ. языка и учебный центр. Там есть рейтинги, т.е. по сути категории и расценки.
Только если…
2. Только если предприятие хочет отделить работников, которые выполняют более сложные задачи от менее сложных.
Например чтобы подтянут квалификацию последним. Тогда последние станут более эффективными.
Но это очень тонкий лед, т.к. предприятие становится еще более зависимо от кадров. Чем выше квалификация, тем выше конкуренция и шанс потерять.
Даже если рассматривать бальную систему в образовании детей, то применив данную методику и поделив детей, предположим на две группы, сильные и слабые, с целью повысить слабым уровень, приходим к следующему заключению:
Все задания по англ. языку, которые должен выполнить участник сильной группы это 100% его работы.
Как и у программиста заказ от клиента.
За эту работу ученик сильной группы получить оценку — 5.
Ученик слабой группы делает задания проще, но сделав их, тоже должен получить оценку — 5.
Вопрос: какой смысл если в результате оба имеют одинаковую оценку?
Но если ученик сильной группы будет получать 5, а ученик слабой будет получать 3, несмотря на то что тоже все сделал, получим конфликт, потому что ученики не отвечают сами за организацию их труда-учебы.
И ни как невозможно отделить эту оценку от системы мотивации или оплаты, потому что в ней сразу исчезает смысл.
Таким образом, в этой истории прорисовывается только одна цель — и это заговор(шутка). Все, выбрасываю эту идею из головы.
(34) Интересные мысли, есть над чем задуматься.
Кстати у меня тоже мысль промелькнула о том, что эффективность тут не причем. Идея тут получилась в обоснование стоимости работы, и действительно разделения на «сильных» и «слабых» программистов. И еще мне кажется статью писал как раз заказчик, а не исполнитель работ. Так как есть в жизни такая ситуация когда покупатель(заказчик, работодатель) хочет получить свою выгоду (это за максимально короткие сроки и минимальную плату, получить необходимый результат работы), а продавец (исполнитель, работник) хочет тоже получить выгоду (это за наименьшие трудозатраты и максимальную оплату, получить тотже самый результат работы который хочет заказчик).
Очередная попытка оценить то, что нельзя оценить?
(34) Идея оцифровать труд программистов и на этой основе регулировать их доходы в сторону выгодную работодателю — это идея проходящая красной нитью через всё творчество Ивана. Под разными соусами в результате всегда одно и тоже. ИМХО.
(34) о, дальше интереснее. Конкуренция школ и вузов за рейтинг и престиж, конкурс человек на место, проходной балл, требования за прохождение вне конкурса.
Пропущена тема естественной двухпартийной системы. Когда в классе есть лидер отличников, как правило староста и есть лидер троечников, оппозиция. Может быть ещё третья группа. Получать оценки выше лидера своей группы не приветствуется всей группой. Как и ниже минимального уровня группы.
Поэтому троечники на самом деле могут хорошо поступить в ВУЗ. А отличники, которые знают что они списывали, даже не будут пытаться.
(36)
Если верить книге — Scrum Революционный метод управления проектами (Джефф Сазерленд)
так работают (и оценивают) многие передовые компании и не только в ИТ отрасли.
Для программиста «одиночки», возможно, и не актуально, но для масштабных проектов весьма…
/Если верить книге/
(3)Ну в фирме разработчике может быть лишь единсвенная шкала эффективности — ₽. Неважно сколько кто закрыл часов/баллов важна лишь сумма подписанных актов. Программист может воообще качать обработки с инфостарта, привлекать колег, совершенно не разбираться в коде. Но если не эффективный сотрудник (по меркам подобных шкал), приносит от довольных клиентов подписанные акты, то какие к нему могут быть вопросы? Да и обычно сотрудники в таких фирмах крайне заинтересованы в своей эффективности, ведь от этого зависит их заработок.
А вот на окладе может это и актуально. Особенно когда оклад внушительный, проект расстянутый , команда большая, именно тогда это и нужно.Но не все так гладко, ведь это раздражает. «Я получу n рублей в конце месяца, а они хотят чтоб я тут надрывался?Нет уж пусть лучше Гена больше делает, я слышал у него оклад на m руб больше.»
ИМХО. Лучшая схема оклад+премия. Но пока удачной модели я не видел.
По моему вы взяли одну из «метрик часов» обозвали ее баллами и оцениваете эффективность работы программиста. Из интересного но не нового — коллективная оценка сложности задачи. Из интересного но не до конца мне понятного оценка из ряда Фибоначчи. Единственный смысл ряда вижу в простоте отсева неадекватных оценок, но на мой взгляд это вполне решаемо и так.
А может я за 15 лет уже настолько закостенел что все в часах и поменять себя не могу…