Как сжать время?

04.05.19

Управление проектом

Как, и зачем измерять задачи в чем-то, помимо часов.

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

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

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

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

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

А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?

Можно ответить туманно: эффективность работы программиста. Хорошо, а как, и что мы будем измерять? В наличии у нас, напоминаю, три или четыре вида часов.

Попробуйте сказать программисту: хотим, чтобы ты производил больше часов. Что он ответит? Программист – парень толковый, в институте учился, и он сразу вспомнит о пятой метрике – количестве часов в сутках. И смело вам об этом скажет – я не могу работать больше, чем 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С – достаточно добавить числовое поле к объекту метаданных, который хранит ваши задачи. Ну и написать несколько отчетов по балльной системе – сколько задач решено, кем, когда, сколько еще не принято в работу, сколько ожидает принятия заказчиком и т.д.
 

Резюме

 

  1. Измерение задач только в часах лишает вас возможности повысить эффективность;
  2. Измерять задачи лучше в натуральных единицах – баллах;
  3. Начинать внедрение баллов лучше с командного покера планирования;
  4. Когда система оценок станет понятна команде, можно отдать оценку одному человеку;
  5. Оценка в баллах дает понимание эффективности;
  6. Учет баллов обязательно нужно автоматизировать.

эффективность управление разработкой проектами гибкие методики agile

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2983    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4097    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3442    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3320    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15053    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6169    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5216    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5796    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Realyzer 04.05.19 22:39 Сейчас в теме
Иван, благодарю Вас за полезную информацию. Очень хочу применить новую систему оценки работы программистов в своей деятельности. Есть сомнение: после перехода на учет трудозатрат в баллах придется изменить базу для расчета сдельной части оплаты. И я понимаю, что сумма з/п станет меньше. Как правильно организовать такой переход, чтобы не распугать исполнителей? Нельзя же сказать, что с завтрашнего дня у нас меняется система ценностей и я заранее становлюсь недоволен тем результатом, который обычно устраивал?
2. 1c-intelligence 12825 04.05.19 23:38 Сейчас в теме
(1) за баллы платить нельзя, как мне кажется, они слишком зыбкие.

Лучше традиционные схемы. Для фикси - оклад, для франча - сделка.
Просто оцениваемый результат станет более многомерным.

Например, для франча к выработке в часах и подписанным актам по проектам добавятся баллы.

Тогда оценка станет более комплексной, и потому - более объективной.
5. acanta 05.05.19 09:23 Сейчас в теме
(1) во первых, чемпионы свое уже отработали и теперь архитектурой занимаются другие.
Во вторых, результат это то что требуется заказчику. Если заказчику требуется из по ГОСТ, то его нужно сделать. И задача РП помочь исполнителю или правильно составить команду, которая сможет не только декомпозировать задачу на более мелкие и выполнить по частям не более двух-трех баллов каждая, но и собрать из этого результат.
Важно кроме декомпозиции задач еще и сохранить их логическую взаимосвязь. Если один сотрудник может поглотить сразу запоем объем в несколько десятков декомпозированных частей и воспринимать их как одну задачу из блока автоматизации склада в рамках проекта внедрения системы, то другой должен взять и сдать именно часть хвоста собаки задачи, оцененную не более чем в 2 балла.
Разница между внешним и внутренним проектом в том что изменение требований - когда вчера заказчику это надо, а завтра уже может быть не актуально - должны обрабатываться на внутреннем проекте.
3. script 128 05.05.19 00:56 Сейчас в теме
Пока фирма разработчик будет повышать свою эффективность, придумывая способы как повысить эффективность, за это время частники уже успеют сделать 80% задач и про них забыть.

Вот честно, непонятно для чего нужна оценка эффективности?
На первый взгляд кажется, что такой вопрос сам по себе глупый. Ведь понятно, что информация о том, сколько конкретной "пользы" производит каждый работник, является важной. Но если вникать в этот вопрос глубже, то в среде 1С все не так однозначно.
Далее идут вопросы типа:
1. Что с этой информацией делать?
2. Кому и где эта информация полезна?
3. Не выйдет ли так, что получение этой информации будет занимать слишком много ресурсов-времени?

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

Получается, что для составления шкалы баллов по каждому проекту нужно потратить время. Это время в любом случае не уменьшает себестоимость, а наоборот. Себестоимость может сыграть главную роль в конкуренции на рынке.

А потом сказать работникам, что данная задача будет оценена в 2 балла, потому что так решил лидер.
По сути это звучит так: Мы коллектив, или еще хуже, - Я лидер решил что за эту задачу исполнитель получит 2 балла, потому что по моему мнению, я ее сделаю за 30 мин". Проще говоря - ты можешь делать эту задачу сколько хочешь, но оплатят тебе 30 мин.

С увеличением производительности здесь тоже проблема.

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

Короче сплошной диссонанс. Вся эта история больше похожа на утопию.

Это когда тебя клиент просит сделать ему расчет итогов в колонке - Количество, хотя в одном документе может встречаться и весовой товар и штучный. Информация вроде бы и полезная, но бессмысленная.
evgd02; sevushka; krollzlat; Aggressorak; Robbi; Рамзес; manlak; wolfsoft; 3vs; +9 Ответить
4. acanta 05.05.19 01:06 Сейчас в теме
(3) вы абсолютно правы все так и делают.
6. 1c-intelligence 12825 05.05.19 20:02 Сейчас в теме
(3) во-первых, никакого времени на составление шкалы не нужно, шкала уже есть - ряд Фибоначчи.
Во-вторых, навык оценки задач в баллах вырабатывается за несколько итераций, т.к. там нет правильного и неправильного варианта оценки.
В-третьих, оценка в баллах не выходит наружу - ни клиенту, ни в систему мотивации. Она живет параллельно, обогащая понимание происходящего.
Например, есть две задачи от разных клиентов, с договоренностью по оплате в 4 часа. Пока у нас одна метрика, задачи выглядит одинаково.
Теперь мы их оцениваем в баллах. Оказалось, что первая стоит 8 баллов, а вторая - 13. Картина оценки становится двумерной.
Используя баллы, мы знаем производительность программистов, т.е. баллы в час или баллы в день. Соответственно, мы можем, наконец, нормально планировать их загрузку и определять сроки.
Как определить срок исполнения задачи, если известно только, что на нее согласовано 4 часа? Вариантов не много - ставим 4 минимум часа от текущей даты. Раньше, чем через 4 часа, мы результата не получим. 4 часа есть 4 часа.
А тут мы раз, и знаем, что программист у нас работает со скоростью 4 балла в час. На первую задачу ему надо 2 часа, на вторую - 3 часа. Уже интереснее.
Зная скорость, ни у программиста, ни у его начальника, нет желания растягивать исполнение задачи на 4 часа. Можно суммарно потратить 5 часов, а денег получить за 8.
И все это - без повышения эффективности, просто добавив параллельную метрику. А вот если программиста, а лучше - всю команду, ускорить, то эти 8 часов они закроют за 2-3. А денег, напоминаю, и компания, и программисты получат за 8.
Собственно, дальше каждый сам решает, надо ему это, или нет.
16. пользователь 05.05.19 22:13
Сообщение было скрыто модератором.
...
17. пользователь 05.05.19 22:14
Сообщение было скрыто модератором.
...
40. krollzlat 08.05.19 06:42 Сейчас в теме
(3)Ну в фирме разработчике может быть лишь единсвенная шкала эффективности - ₽. Неважно сколько кто закрыл часов/баллов важна лишь сумма подписанных актов. Программист может воообще качать обработки с инфостарта, привлекать колег, совершенно не разбираться в коде. Но если не эффективный сотрудник (по меркам подобных шкал), приносит от довольных клиентов подписанные акты, то какие к нему могут быть вопросы? Да и обычно сотрудники в таких фирмах крайне заинтересованы в своей эффективности, ведь от этого зависит их заработок.

А вот на окладе может это и актуально. Особенно когда оклад внушительный, проект расстянутый , команда большая, именно тогда это и нужно.Но не все так гладко, ведь это раздражает. "Я получу n рублей в конце месяца, а они хотят чтоб я тут надрывался?Нет уж пусть лучше Гена больше делает, я слышал у него оклад на m руб больше."

ИМХО. Лучшая схема оклад+премия. Но пока удачной модели я не видел.
Lapitskiy; +1 Ответить
7. script 128 05.05.19 20:35 Сейчас в теме
Используя баллы, мы знаем производительность программистов.

На самом деле мы знаем за сколько баллов программиста заставили сделать задачу.

Мне видимо, все равно не понятен процесс оценки задач. Скажите пожалуйста, чем руководствуются оценщики?

Вот задача:
Сделать в Бух 3.0 подсистему учета Путевых листов и топлива в баках автотранспорта.
Для этого нужно сделать как минимум:
- справочник Автотранспорт или доработать справочник Основные средства.
- справочник Марки автотранспорта и нормы расхода
- документ Путевой лист
- отчет Ведомость учета горючего
- регистр сведений Показатели автотранспорта
- сделать ввод списания ГСМ на основании путевого листа.

Ну и как в баллах будут оценивать данную работу?
Что даст эта оценка, если эта задача может и не повторится больше никогда, а разработчик ее делал 10 часов? И фактически потраченное время известно станет по окончании разработки, и это без учета тестирования?
Короче вопросов у меня больше .... одни вопросы, и ни одного ответа.
8. 1c-intelligence 12825 05.05.19 20:43 Сейчас в теме
(7) тут бессмысленно пытаться ответы получить, надо пробовать. Хотя бы на себе.
Вот как бы я оценил задачи:
- справочник Автотранспорт или доработать справочник Основные средства. - 3-5 баллов;
- справочник Марки автотранспорта и нормы расхода - 3-5 баллов;
- документ Путевой лист - 8-13 баллов (если он большой и сложный, как обычно бывает);
- отчет Ведомость учета горючего - 5 баллов;
- регистр сведений Показатели автотранспорта - 5-8 баллов;
- сделать ввод списания ГСМ на основании путевого листа - 5-8 баллов.

Итого 29-42 балла, если не ошибся.
24. Ziggurat 50 06.05.19 12:19 Сейчас в теме
(8)
если не ошибся

А это важно.
9. script 128 05.05.19 20:56 Сейчас в теме
Ну 29-44. И что дальше?
Я завожу себе такое поле - количество балов, и записываю в него что? 29-44?
Кроме того у меня в задаче указано фактическое время решения задачи, например 15 часов.
Т.е. я могу получить среднее количество балов в час.
А что дальше?

Извините что мучаю вопросами. Я действительно хочу понять и разобраться.
11. 1c-intelligence 12825 05.05.19 21:15 Сейчас в теме
(9) я указал диапазон, т.к. "Путевой лист" - очень растяжимое понятие, тут нужно больше деталей.

Дальше - указываете баллы в задаче, и садитесь ее выполнять. В каждой задаче указываете баллы и выполняете ее.

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

А через месяц напишите, что получилось. Если на самом деле интересно, то на днях еще пара статей выйдет с рекомендациями. Если их примените, то результат должен получиться весьма неплохим.
10. acanta 05.05.19 21:14 Сейчас в теме
Имеется ввиду вероятно что после добавления путевого листа в конфигурации трёх клиентов.вы будете делать это в полтора раза быстрее, а после двадцати даже с закрытыми глазами.
При этом оценка останется прежней. Вы сможете увидеть насколько вырос ваш профессионализм.
12. Perfolenta 206 05.05.19 21:51 Сейчас в теме
в качестве побочного эффекта со временем может возникнуть инфляция или дефляция в паре баллы в час... :)
14. 1c-intelligence 12825 05.05.19 21:59 Сейчас в теме
(12) да, может.
Дефляцию, кстати, можно сознательно устраивать, я так делал.
13. script 128 05.05.19 21:56 Сейчас в теме
После того как я "зашью" этот модуль в расширение, я его буду ставить клиенту за одну минуту.
А через какое то время я сделаю магазин расширений, и клиенты сами смогут его установит, оплатить и обновить.
Так что дело как раз не в этом.

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

Видимо я все равно здесь чего-то не понимаю.
Понимаю идею - зачем это нужно,
Понимаю чем руководствоваться при оценке: чем сложнее задаче, тем больше баллов.
Понятно, что сразу выработать правильный баланс оценок не возможно, нужно сделать несколько первых замеров.
Это как начертить с линейкой длинную прямую через две точки, но когда длинны линейки не хватает от начала до конца. Нужно сперва нанести промежуточные точки и чертить по ним.

Не понимаю что с этим делать дальше.
Получил я марте 100 баллов за 22 рабочих дня на сумму 200 т. руб.
В следующем месяце наработал 80 баллов, но заработал 300 т. руб. (меньше работал, но продал какие-то готовые решения)
В следующем месяце наоборот, заработал 150 баллов, т.к. делал сложные задачи, но заработал - 40 т. руб. т.к. делал эти задачи первый раз, многое не учел и фин потери взял на себя потому, что с клиентом была оговорена стоимость заранее.

Что мне это дает?
Что я в последнем месяце работал менее эффективно?
И да и Нет. Я по жадничал времени на анализ задачи, но получил огромное количество опыта.

Что я работал в убыток? И да, и нет.
Нет - потому что это прямая инвестиция в опыт и готовые наработки-решения.
Да - только тогда, когда есть фин. отдел и бюджет на месяц, и часовая или дневная расценка.
Тогда исходя из этой расценки, если бы я делал обычные задачи, то заработал бы гораздо больше.
Тогда в последнем месяце из-за этого маневра, я не дополучил прибыль - упустил.
Но если рассматривать фин. год, и таких задач было несколько, тогда этот маневр, может принести 100% и более прибыли, потому что следующие задачи удалось решить практически не затратив времени.
Т.е. оценка сложности задачи в баллах осталась бы прежней, но время на ее выполнения уменьшилась бы в разы.

Или в этом случае и оценку в баллах нужно тоже уменьшать?
15. 1c-intelligence 12825 05.05.19 22:03 Сейчас в теме
(13) кажется, вы забегаете слишком далеко вперед.

Продажу готовых решений сюда примешивать не надо. Их разработку - да, а продажу - нет.
Если вы решили задачу в первый раз, оценили в 13 балов, а потом просто вставляете готовое решение, то правильно будет переоценить задачу, в смысле переоценку сделать - оставить, например, 1-3 балла за внедрение готового решения.
26. acanta 06.05.19 13:49 Сейчас в теме
(15) это правильное направление. Но по нему следует пройти чуть дальше.
У вас появляется клиент с задачей.
Задача это спрос. Будете ли вы делать задание при нем с нуля или закажете аутсорсеру/ фикси или есть готовые но требует адаптации это ваша коммерческая тайна, ноу хау.
Вам необходимо оценить сколько клиент готов за это платить и в какие суммы и сроки вы уложитесь.
Первая проблема у программистов нет навыка продаж и это будет делать менеджер.
Вторая проблема у программистов нет навыков передачи части работ на субподряд это тоже менеджер.
Третья проблема сколько два менеджера будут платить одному своему программисту, который как правило будет только адаптировать (типовые или выполненные аутсорсерами), если со всеми остальными программистами оценка за сдельную работу идёт в деньгах (а не в часах и не в баллах) и их обьемов в вашей базе нет.
Это значит что работы, превышающие какой то пороговый объем будут отсекаться и только рост профессионализма позволит брать за те же сроки и деньги большие объемы. Т.е. оценка в баллах призвана быстро ответить сможете ли вы поднять какой то проект не проседая по текущим задачам.
18. script 128 05.05.19 22:17 Сейчас в теме
кажется, вы забегаете слишком далеко вперед.

"Всегда готовьтесь ко всему и как можно заранее"
Карл фон Клаузевиц «О войне» ...

Тогда мне не понятно вот это утверждение и ниже.

Зная скорость, ни у программиста, ни у его начальника, нет желания растягивать исполнение задачи на 4 часа. Можно суммарно потратить 5 часов, а денег получить за 8.


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

Но это неизбежно произойдет, т.к. станет простым инструментом управления. Любимым для руководства. Сказал что сделаешь за 5 баллов - делай. и, мягко говоря, никого не волнует.

Вася наработал 50 баллов за месяц, а Петя 200. Но все и так знают, что Петя тянет крупных клиентов, и работает 24/7 и имеет 20 лет опыта. Какие к нему могут быть вопросы.
20. 1c-intelligence 12825 06.05.19 07:24 Сейчас в теме
(18) вы не знали, что задачу можно решить быстрее, пока не перевели ее в баллы. В моем примере были согласованы часы - по 4 на каждую. Без баллов программисты и решали бы их за 4 часа каждую. Потому что действует закон Паркинсона - человек выполняет работу столько времени, сколько на нее отпущено.

В примере про Петю и Васю есть, чем заняться. Например, сделать так, чтобы Петя продолжал делать 200 баллов, но перестал работать 24/7 - это вредно для здоровья. Пусть делает те же 200 баллов за восьмичасовой рабочий день.
19. ILM 241 06.05.19 05:40 Сейчас в теме
"Учитель объявляет ученикам:
- Наша школа переходит на бальную систему оценки. Теперь цифры заменяем буквами от A, B, C и т.д. Учиться нужно теперь хорошо, потому что теперь вместо двойки я вам дам по E-баллу."

(Хорошо работать одному на предприятии, нет оценок в баллах, только рубли и критерий всего один - база работает или не работает).
alest; Aggressorak; script; Ziggurat; zqzq; +5 Ответить
21. 1c-intelligence 12825 06.05.19 07:24 Сейчас в теме
(19) одному на предприятии работать хорошо. Плохо только, что это - не навсегда.
22. bashirov.rs 31 06.05.19 09:38 Сейчас в теме
Я как понимаю это можно использовать только для повышения эффективности работы программистов. Но как быть в такой и ситуации, хотелось бы понять:

Пример:
1 месяц:
Всего было 30 задач
Программист1 - 80 попугаев (10 задач)
Программист2 - 75 попугаев (8 задач)
Программист3 - 90 попугаев (9 задач)
2 месяц:
Всего было 10 задач
Программист1 - 30 попугаев (2 задачи)
Программист2 - 50 попугаев (5 задач)
Программист3 - 25 попугаев (3 задачи)

В итоге какая формула по расчету эффективности?
29. 1c-intelligence 12825 06.05.19 15:06 Сейчас в теме
(22) продуктивность и эффективность упали одинаково низко, если программисты на окладе (затраты на достижение результата одинаковы от месяца к месяцу).

Но, вообще, тут вроде всё понятно. Есть чем заняться.
33. bashirov.rs 31 06.05.19 15:27 Сейчас в теме
(29) Как она могла упасть, если всего было в один месяц 30 задач, которые они все не сделали, а в другой было 10 задач и они все выполнили. Короче тут все не так просто и не всегда можно адекватно оценить эффективность. Плюс вы так и не ответили по какой формуле вычислять эффективность.
23. script 128 06.05.19 10:56 Сейчас в теме
Если в идеале отбросить использование бальной системе в системе мотивации, тогда я вижу что использовать методику можно для получения точной информации о том, какие задачи решают программисты (простые-сложные), а так же динамику изменения сложности задач, а не то - насколько эффективно эти задачи были сделаны.

Эта информация может быть полезна для:
- повышения квалификации отдельных специалистов.
- изменения ценовой политики.
Например, разделить спецов на категории 1,2 и т. д. уровня, и для клиента озвучивать стоимость за работу спеца разных категорий по разному.
Я встречал такой подход в веб. студиях. Кодер 20S/час, - аналитик 30, архитектор-40 и т.д.

- не представляю даже сколько придется воевать с руководством, чтобы отстоять мнение, что эту оценку не нужно использовать в системе мотивации и и оплаты - короче готовится к борьбе..., Только нужно ли это тому, кто эту инициативу захочет проявить?
25. TODD22 19 06.05.19 12:44 Сейчас в теме
(23)
Например, разделить спецов на категории 1,2 и т. д. уровня, и для клиента озвучивать стоимость за работу спеца разных категорий по разному.
Я встречал такой подход в веб. студиях. Кодер 20S/час, - аналитик 30, архитектор-40 и т.д.

Озвучивание клиенту стоимости разных специалистов прямой путь к работе веб студии за тарелку супа.
Как только озвучил из чего складывается себестоимость услуг тут же начинают продавливать по деньгам. В сфере услуг сплошь и рядом.
У меня на предприятии производят очень сложные наукоёмкие(делают их кандидаты наук и тд и по ходу пишут диссертации и получают патенты) приборы, так один покупатель попросил прислать спецификацию с расшифровкой себестоимости изделия мотивируя это тем что ему надо знать за что он платит деньги... вот и откуда такие берутся.
30. 1c-intelligence 12825 06.05.19 15:08 Сейчас в теме
(23) зачем с кем-то воевать? Систему вполне можно внедрить втихаря, для внутреннего использования. Она добавит элемент игры и поднимет настроение.
А если нет - всегда можно выкинуть.
Ну и, вообще, учет в баллах - лишь первый этап на пути повышения эффективности. Можно и без него обойтись, но будет сложнее.
32. acanta 06.05.19 15:21 Сейчас в теме
(30) Любые элементы игры повышают настроение только когда в целом все неплохо и все адекватные.
Итак, сидят в отделе условно 6 человек в двух кабинетах. В рабочее время явка обязательна, тех.обслуживание пользователей и ввод забытых паролей, после окончания рабочего дня перестановки оборудования, обновления продакшн и так каждый день.
И тут появляется новый начальник с учётом баллов и элементами игры.
27. Painted 49 06.05.19 14:53 Сейчас в теме
Сколько баллов стоит прочитать эту статью? 13 баллов - нормально будет? А с комментами?
28. 1c-intelligence 12825 06.05.19 15:03 Сейчас в теме
(27) написать - 15 баллов.
Прочитать - 3 балла.
Комментов мало, так что прочитать с комментами - 5 баллов.
31. Painted 49 06.05.19 15:16 Сейчас в теме
(28)Не цените вы своих читателей ((
Они стараются, тратят время, а вы 3 балла....
34. script 128 06.05.19 15:46 Сейчас в теме
Размышляя над это статьей у меня все время не выходит из головы одна мысль, засела как параноя.

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

Давайте уйдем от программистов и возьмем условного писателя художественной литературы.
И давайте возьмем издательство, которое захочет внедрить бальную систему. Там тоже есть заказы и на переводы текстов и на статьи и на худ. литературу. Сразу становится понятным что бальная система на основании сложности работать не будет. Думаю даже объяснять не нужно почему.

Или возьмем учителя англ. языка и учебный центр. Там есть рейтинги, т.е. по сути категории и расценки.

Только если...

2. Только если предприятие хочет отделить работников, которые выполняют более сложные задачи от менее сложных.
Например чтобы подтянут квалификацию последним. Тогда последние станут более эффективными.
Но это очень тонкий лед, т.к. предприятие становится еще более зависимо от кадров. Чем выше квалификация, тем выше конкуренция и шанс потерять.

Даже если рассматривать бальную систему в образовании детей, то применив данную методику и поделив детей, предположим на две группы, сильные и слабые, с целью повысить слабым уровень, приходим к следующему заключению:

Все задания по англ. языку, которые должен выполнить участник сильной группы это 100% его работы.
Как и у программиста заказ от клиента.
За эту работу ученик сильной группы получить оценку - 5.
Ученик слабой группы делает задания проще, но сделав их, тоже должен получить оценку - 5.

Вопрос: какой смысл если в результате оба имеют одинаковую оценку?
Но если ученик сильной группы будет получать 5, а ученик слабой будет получать 3, несмотря на то что тоже все сделал, получим конфликт, потому что ученики не отвечают сами за организацию их труда-учебы.

И ни как невозможно отделить эту оценку от системы мотивации или оплаты, потому что в ней сразу исчезает смысл.

Таким образом, в этой истории прорисовывается только одна цель - и это заговор(шутка). Все, выбрасываю эту идею из головы.
acanta; Aggressorak; VladimirMelnychenko; bashirov.rs; +4 Ответить
35. bashirov.rs 31 07.05.19 07:06 Сейчас в теме
(34) Интересные мысли, есть над чем задуматься.
Кстати у меня тоже мысль промелькнула о том, что эффективность тут не причем. Идея тут получилась в обоснование стоимости работы, и действительно разделения на "сильных" и "слабых" программистов. И еще мне кажется статью писал как раз заказчик, а не исполнитель работ. Так как есть в жизни такая ситуация когда покупатель(заказчик, работодатель) хочет получить свою выгоду (это за максимально короткие сроки и минимальную плату, получить необходимый результат работы), а продавец (исполнитель, работник) хочет тоже получить выгоду (это за наименьшие трудозатраты и максимальную оплату, получить тотже самый результат работы который хочет заказчик).
37. Aggressorak 07.05.19 12:53 Сейчас в теме
(34) Идея оцифровать труд программистов и на этой основе регулировать их доходы в сторону выгодную работодателю - это идея проходящая красной нитью через всё творчество Ивана. Под разными соусами в результате всегда одно и тоже. ИМХО.
38. acanta 07.05.19 13:12 Сейчас в теме
(34) о, дальше интереснее. Конкуренция школ и вузов за рейтинг и престиж, конкурс человек на место, проходной балл, требования за прохождение вне конкурса.
Пропущена тема естественной двухпартийной системы. Когда в классе есть лидер отличников, как правило староста и есть лидер троечников, оппозиция. Может быть ещё третья группа. Получать оценки выше лидера своей группы не приветствуется всей группой. Как и ниже минимального уровня группы.
Поэтому троечники на самом деле могут хорошо поступить в ВУЗ. А отличники, которые знают что они списывали, даже не будут пытаться.
36. aparinp 52 07.05.19 10:15 Сейчас в теме
Очередная попытка оценить то, что нельзя оценить?
39. _Amator_ 9 07.05.19 16:56 Сейчас в теме
(36)
Очередная попытка оценить то, что нельзя оценить?

Если верить книге - Scrum Революционный метод управления проектами (Джефф Сазерленд)
так работают (и оценивают) многие передовые компании и не только в ИТ отрасли.
Для программиста "одиночки", возможно, и не актуально, но для масштабных проектов весьма...
/Если верить книге/
41. AlexCherdakov 21 08.05.19 13:08 Сейчас в теме
По моему вы взяли одну из "метрик часов" обозвали ее баллами и оцениваете эффективность работы программиста. Из интересного но не нового - коллективная оценка сложности задачи. Из интересного но не до конца мне понятного оценка из ряда Фибоначчи. Единственный смысл ряда вижу в простоте отсева неадекватных оценок, но на мой взгляд это вполне решаемо и так.
А может я за 15 лет уже настолько закостенел что все в часах и поменять себя не могу...
Оставьте свое сообщение