Измерение vs Иллюзии

31.10.17

Саморазвитие

Почему важно измерять свою работу, и что будет, если этого не делать.

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

Сначала кратко методику (не все с ней работали), потом – главное, зачем ее применять.

Методика измерения

Сама методика известна давно, никакого секрета собой не представляет – это покер планирования из Scrum. Чтобы ее применять, не нужно применять весь Scrum.

Алгоритм измерений прост, как автомат Калашникова. Каждая задача, которую вы собираетесь решать, должна получить оценку в баллах – цифрах из ряда Фибоначчи. Вот эти цифры: 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Каждая цифра является суммой двух предыдущих (один элемент ряда пропущен, по понятным причинам). Некоторые ребята называют цифры не баллами, а сторипойнтами (story points). Тут как хотите, мне ближе и проще говорить «баллы».

Ряд Фибоначчи выбран разработчиками потому, что соседние оценки стоят друг от друга довольно далеко, и позволяют точнее идентифицировать разницу в сложности задач. Одно дело – выбирать между оценками 7 и 8, совсем другое – между 5 и 8.

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

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

Если команды у вас нет, или они не хотят развиваться вместе с вами, ставьте оценки самостоятельно. В этом случае карты вам не нужны.

Чтобы оценки не уплывали в сторону увеличения или снижения, придумайте себе якорь. Самый простой якорь – решить, что есть задача на 1 балл. Это – бит вашей работы, самое простое из того, что вам приходится делать. Например, вывести реквизит объекта на форму. Можно придумать не один, а несколько якорей, если вам так проще. Например, решить, что разработка простого отчета на СКД, типа отчета Продажи по оборотному регистру накопления, стоит 3 балла. И т.д.

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

Разумеется, систему учета оценок надо автоматизировать. Это очень просто – достаточно к объекту информационной системы, который у вас содержит задачи, приделать числовой реквизит и заполнять его. Или не реквизит, а свойство (если у вас что-то вроде 1С:Документооборота).

Если вы ведете свои задачи в GitHub, то можно использовать метки (labels). Достаточно в метки добавить весь ряд, и каждой задаче назначать подходящую метку, а потом собрать оценки через API. Если кому нужно, я выложу отчет для 1С, который это делает – я сам веду задачи в GitHub и собираю оттуда оценку.

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

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

На выходе система измерения должна давать нам такую табличку:

Дата выполнения

Исполнитель

Задача

Баллы

30.10.2017

Белокаменцев И.Е.

Форма получения произвольного объекта из CouchDB

5

31.10.2017

Белокаменцев И.Е.

Статья «Иллюзии vs Измерения» на Инфостарте

13

В отчетах даты лучше группировать по неделям.

Немного поговорим о том, как на нее смотреть.

Как смотреть результаты

Лично мне ближе всего графики. Например, вот так выглядит график моей эффективности, нарисованный в Google Charts в flowcon:

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

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

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

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

Flash-дурилка

Есть у вас измерения, или нет у вас измерений – вы все равно составляете некоторое представление об эффективности работы, своей и команды.

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

Например, программист всю неделю тупит, ничего не выдает, ковыряется в носу, а в пятницу выдает «на гора» некое решение. Вы, как руководитель, по итогам недели видите это решение, и вся неделя запоминается в его контексте. Если спросить вас через 1, 2 или 3 недели, как работал программист в такой-то период, вы вспомните это решение, выданное «на гора» - flash-дурилку.

У инструмента flash-дурилка есть несколько названий, одно из самых распространенных – ИБД, имитация бурной деятельности, которой пользуются практически все сотрудники, особенно крупных предприятий. Вы сами найдете массу примеров в жизни своего предприятия.

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

Такой прием постоянно используют в государственном управлении деревень, вроде нашего Челябинска. У нас в городе большие проблемы с экологией – иногда просто невозможно дышать от выбросов. Угадайте, когда в нашем городе чисто, красиво и воздух, как в горах Кавказа? Когда приезжает президент или премьер-министр. Это flash-дурилка для них. Ближайшая дата – 9 ноября, какой-то форум будет (https://rf-kz.ru/). Ждем с нетерпением, сможем за пивом без противогаза сбегать. Что запомнят гости Челябинска по итогам визита? Город чистый, ларьков с шаурмой нет, воздух прекрасный, немного пованивает выхлопными газами – ну куда ж без этого, город миллионник. Простейшая система измерений – процент дней, когда дышать невозможно – убила бы возможность показывать flash-дурилки.

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

Самый парадоксальный вариант – виртуальная flash-дурилка, применяется как по отношению к себе, так и для начальства. Это когда вы выдаете Нечто в конце периода, и дополняете обещанием, что дальше все будет еще лучше. «Согласен, понимаю, что могу лучше и больше, но посмотрите, что я выдал в пятницу, я теперь осознал, как работать лучше, и на следующей неделе все изменится к лучшему, я теперь понял, и динамика у меня отличная».

Булево vs Число

Традиционная система измерения работы программистов и не только – управление по срокам. Говоря нашим языком, у выполненной задачи или проекта есть вычисляемый параметр – «выполнена в срок». Сами понимаете, этот параметр типа Булево.

И вот на этих булевых строится управление. Таблица исходных данных выглядит так:

Исполнитель

Задача

Выполнена в срок

Белокаменцев И.Е.

Форма получения произвольного объекта из CouchDB

Ложь

Белокаменцев И.Е.

Статья «Иллюзии vs Измерения» на Инфостарте

Истина

 

Для каждой конкретной задачи булево какой-то физический смысл имеет. Чтобы оценить работу за период, уже нужна более сложная функция. Надо добавить виртуальную колонку «Количество задач», поставить там формулу: Если ВыполненаВСрок = Истина Тогда 1 Иначе 0 Конец.

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

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

Реальность показала мне, что управление по булевой цифре бессмысленно. Кривая эффективности очень быстро становится ровной, и перестает давать хоть какую-то полезную информацию для корректирующих действий, потому что отвечает только на один вопрос – попадает ли человек в срок.

Ответа на вопрос «эффективно ли человек работает?» булева цифра не дает. Она говорит – «человек выполнил все задачи в срок». На следующей неделе повторяет – «человек выполнил все задачи в срок». И т.д.

Я спрашиваю «а человек на какой неделе лучше работал?», или «а вот этот человек лучше того работал или хуже?». Булева цифра отвечает – «не знаю, нашел что спросить. Оба выполнили все задачи в срок». Я говорю – «Siri булева цифра, ты дура?». «Вообще-то, это очень обидно» - отвечает бессмысленная машина.

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

Самые простые варианты достижения Булево=Истина:

  • Брать на себя поменьше задач;
  • Отжимать сроки подлиннее;
  • Требовать ТЗ, прототипирование, миллион согласований;
  • Создавать алгоритмы переноса сроков при изменении требований и ресурсов;
  • Разводить бюрократию везде, где только можно;
  • Добавлять ненужные этапы решения задачи, в которых можно растворить прибавку к срокам (например, тестирование всего подряд);
  • И т.д.

Разницу между Булево и Цифрой придумали, проверили и показали практикой японцы, в своих системах управления качеством (рассказывал здесь - //infostart.ru/public/662986/).

Смысл прост. Японцы измеряют деталь, получая цифру – например, диаметр вала 26.34 мм. Из этой цифры они выстраивают шикарную систему управления качеством (результаты ездят по дорогам). База всей системы управления качеством в Японии – цифры. По-умному это называется «количественный признак качества».

Наши братья из автопрома не измеряют детали, они пользуются т.н. калибрами – железяками с двумя размерами, минимальным и максимальным. Деталь в калибр или проходит, или не проходит – т.е. имеем то же Булево. По-умному это называется «альтернативный признак качества».

Японцы и для альтернативных признаков придумали системы управления, т.к. тоже ими пользуются. Например, «внешний вид детали соответствует требованиям» - сложно измерить в цифре. Но это вспомогательные признаки, основа же – цифра.

Влияние Булева на управление

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

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

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

А как понять, что работа идет хорошо, если у тебя только Булево? Инструменты известны и широко применяются:

  • Проводить совещания;
  • Подходить и спрашивать, как дела;
  • Лично проверять результаты и процесс;
  • Требовать отчеты о проделанной работе (в виде текста обычно);
  • Составлять и вести планы-графики;
  • И т.д.

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

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

Бюрократы знают, что не обязательно выдавать полезные результаты – достаточно, чтобы Булево было равно Истина. И иногда надо делать flash-дурилку.

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

Развитие на цифрах

Как упоминалось выше, без цифр нет понятия об эффективности. Раз нет понятия об эффективности, не будет ее развития.

Развитие – это повышение эффективности, так или иначе. Эффективность, в классике – это затраты на производство результата.

Если вы – программист, и вам платят оклад, то затраты на вас – постоянны. Значит, чтобы повысить эффективность, надо увеличить результат.

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

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

Дальше еще проще. Если вы не знаете свою эффективность, то вы не знаете ее динамику – растет она или падает.

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

Самое гадкое не то, что вы не сможете, а то, что вы не будете. Даже пробовать.

И команда ваша не будет пробовать, потому что она тоже в плену иллюзий.

Если же отбросить иллюзии, и начать измерять, то работа над эффективностью станет реальной.

Работа над эффективностью

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

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

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

Вот график моей эффективности с наложенными событиями:

О чем говорят маркеры? Начало работы в flowcon, по сути, означает, что я выставит свою эффективность напоказ. Раньше я держал ее в секрете. Какой вывод? Лично для меня полезно, чтобы мою эффективность кто-то видел – меня это подстегивает.

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

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

А вот график с маркерами моего падавана (он учится программированию на 1С):

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

Второй маркер говорит, что если дать падавану большую задачу, содержащую не один, а сразу несколько новых механизмов платформы, то возникает бутылочное горлышко. Один новый механизм он, грубо говоря, осваивает за 3 часа, два новых механизма – за 8 часов, три новых механизма – за 16 часов и т.д., зависимость нелинейная. На втором маркере я дал задачу, содержащую более 5 новых механизмов, и падаван не смог решить эту задачу за неделю. Какой вывод конкретно для этого падавана – не ронять его большим объемом знаний за один присест.

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

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

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

С чего начать

Начните с себя (если хотите, разумеется).

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

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

Ну или убедитесь, что это не ваше, и вам и так нормально.

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

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

Но главное, конечно, собственная эффективность и умение ей управлять. Этого никто не отнимет.

См. также

Личная эффективность Бесплатно (free)

Я Костя, разработчик 1С и руководитель образовательного направления в компании. Живу в Казахстане, работаю удалённо. Прошёл путь от стажёра до руководителя отдела разработки, меняю позиции и роли, потому что всегда хочется задач посложнее. Расскажу о карьере и тех условиях, которые сыграли важную роль для роста.

25.11.2024    4498    0    PROSTO-1C    7    

11

Обучение и наставничество Бесплатно (free)

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

12.11.2024    598    0    AlexSvoykin    9    

4

Личная эффективность Бесплатно (free)

«Я знаю одно – во мне есть нечто, и я это скрываю. Я не говорю об этом. Но оно там всегда. Мой Темный попутчик. Когда он просыпается, я чувствую себя живым.» (сериал «Декстер»). «Жажда разработки» – это психологические проявление внутреннего «я», вызывающее острую необходимость программировать. Все, кто любит программировать, неоднократно испытывали такую жажду, и я не исключение. Расскажем о том, как утолить свою жажду и найти баланс между хобби, работой и другими аспектами жизни.

07.11.2024    3219    0    BlizD    71    

42

Обучение и наставничество Бесплатно (free)

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

09.10.2024    2336    0    Akcium    1    

5

Личная эффективность Бесплатно (free)

В этом выпуске мы поговорили с ведущими подкаста "Аналитики у микрофона" Татьяной Рыловниковой и Анной Войкиной про цели и ценности создания, прослушивания и участия в подкастах.

09.09.2024    389    0    Radio_Analyst    1    

2

Личная эффективность Бесплатно (free)

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

23.08.2024    1094    0    user1947860    3    

5

Удаленная команда Личная эффективность Бесплатно (free)

Я Егор, 1С-разработчик, который уже год работает дистанционно. В конце рабочего дня часто чувствовал себя выжатым лимоном, поэтому нашёл принципы сохранения ресурсности — делюсь рецептом.

20.08.2024    4459    0    PROSTO-1C    14    

23

Коммуникации Личная эффективность Обучение и наставничество Бесплатно (free)

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

23.07.2024    1873    0    SerjoginaMaria    6    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Dzenn 894 31.10.17 13:31 Сейчас в теме
Взял на заметку методику оценки с числами Фибоначчи.
Остальное — почему-то вызывает негативное восприятие.

Один новый механизм он, грубо говоря, осваивает за 3 часа, два новых механизма – за 8 часов, три новых механизма – за 16 часов и т.д., зависимость нелинейная.
— твой падаван гений.


Третий маркер я пока сам не понял, он случился неделю назад. Задачи были сложные, механизмы новые, алгоритмы серьезные (для его уровня), но он выдал самую высокую эффективность за всю историю. Буду анализировать. Возможно, был какой-то душевный подъем, вообще не связанный с работой.
https://youtu.be/XrxxJVSE8Og?t=3m40s
2. 1c-intelligence 12851 31.10.17 13:44 Сейчас в теме
(1) спасибо за ссылку, только не понял, что вы имели в виду, приведя ее.
3. Dzenn 894 31.10.17 13:59 Сейчас в теме
(2) имелось ввиду, что высокая эффективность — результат предшествующего развития с кажущейся низкой эффективностью, экспонента в действии.
4. 1c-intelligence 12851 31.10.17 14:12 Сейчас в теме
(3) я не даю оценок, низкая была эффективность или высокая. Речь лишь о ее повышении, постоянном и непрерывном. Вроде нет противоречий.
53. ILM 241 04.08.21 16:17 Сейчас в теме
(4) Есть ещё одна сторона медали:
1. Аксиома: - Существует точка максимальной эффективности (производительности) для человека, отдела, предприятия и т.д..
2. Следствие 1-е: - Постоянное повышение эффективности - невозможно.
3. Следствие 2-е: - Рост эффективности в будущем будет замедляться и остановится достигнув максимума.
4. Следствие 3-е: - Чтобы поддерживать высокую эффективность, необходимо отдыхать, а следовательно снижать производительность.
5. Следствие 4-е: - Привязывая метрики эффективности к оплате, вы изменяете поведение людей в худшую сторону.

Теорема: - Заставлять ИТ решать проблемы(задачи) бизнеса с максимальной эффективностью - неэффективно.
Доказательство напишите сами)))
5. dmpas 418 31.10.17 14:19 Сейчас в теме
Если вы ведете свои задачи в GitHub, то можно использовать метки (labels)

так вот, что значат эти метки в вашей метадате!!!
6. 1c-intelligence 12851 31.10.17 14:20 Сейчас в теме
(5) да, выкручиваемся, как можем.
7. spezc 793 31.10.17 14:21 Сейчас в теме
Иван, а когда же вы работаете?)))
9. 1c-intelligence 12851 31.10.17 14:26 Сейчас в теме
(7) да как все, то днем, то ночью.
8. genayo 31.10.17 14:24 Сейчас в теме
Вот делаешь задачу неделю, эффективно, сил нет. А потом заказчик такой говорит - спасибо, а это уже и не нужно. И остаешься со свой эффективностью и думами, как обустроить Россию...
Gluk_1C; artempo; knight2007; alex-l19041; +4 Ответить
10. 1c-intelligence 12851 31.10.17 14:27 Сейчас в теме
(8)
И остаешься со свой эффективностью и думами, как обустроить Россию...

зачем оставаться - берешь следующую задачу и погнали.
Заказчик соскочить может и при низкой, и при высокой эффективности исполнителя. При низкой вероятность соскока вроде выше.
11. genayo 31.10.17 14:29 Сейчас в теме
(10) Бессмысленная работа демотивирует, а следовательно снижает эффективность :))
artempo; rpgshnik; +2 Ответить
12. 1c-intelligence 12851 31.10.17 14:33 Сейчас в теме
(11)
Бессмысленная

это же вы ее так назвали, верно? Любую работу можно сделать полезной. В жизни есть масса примеров, когда делаешь одному заказчику, он отказывается, продаешь другому. Или себе оставляешь. Так было, например, со структурой затрат.
13. genayo 31.10.17 14:39 Сейчас в теме
(12) "always look on the bright side of life" (с)
user746911; 1c-intelligence; +2 Ответить
14. pm74 203 31.10.17 14:46 Сейчас в теме

Смысл прост. Японцы измеряют деталь, получая цифру – например, диаметр вала 26.34 мм. Из этой цифры они выстраивают шикарную систему управления качеством (результаты ездят по дорогам). База всей системы управления качеством в Японии – цифры. По-умному это называется «количественный признак качества».

Наши братья из автопрома не измеряют детали, они пользуются т.н. калибрами – железяками с двумя размерами, минимальным и максимальным. Деталь в калибр или проходит, или не проходит – т.е. имеем то же Булево.

поясните пожалуйста эту фразу

По-умному это называется «альтернативный признак качества».

по умному это называется попаданием в квалитет


p/s извините придираюсь конечно , понимаю что это все про контроллинг и прочее но ,
не все на форуме разбираются в системе допусков и посадок и расчете размерных цепей
15. 1c-intelligence 12851 31.10.17 16:38 Сейчас в теме
(14)
не все на форуме разбираются в системе допусков и посадок и расчете размерных цепей

я отношусь к числу тех, кто не разбирается.

Признак качества - это абстрактное свойство продукта. Для определенного продукта его, наверное, можно назвать "попадание в квалитет" - там, где существует понятие "квалитет" (оно же не абстрактное).

Если продукт - крокодил, и признак качества у него - "крокодил зеленый?", то понятия "квалитет" уже не существует, и назвать попаданием в квалитет зеленый цвет крокодила уже нельзя.

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

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

Придираться - правильно.
16. pm74 203 01.11.17 07:42 Сейчас в теме
(15) Квалитет - это показатель точности размера (ЕСДП), задается конструктором исходя из технологических требований к изделию. Если размер попадает в поле допуска согласно требуемого квалитета . размер считается выдержанным. Поэтому применение калибров в массовом производстве вполне оправдано. Если японцы же измеряют каждую деталь (с ваших слов ) , очевидно это автоматизированный процесс для корректировки программы обработки с учетом износа режущего инструмента.

Ладно это все не по делу. Можно ли считать объективным показателем эффективности рейтинг на этом ресурсе ?
18. 1c-intelligence 12851 01.11.17 08:13 Сейчас в теме
(16)
очевидно это автоматизированный процесс для корректировки программы обработки с учетом износа режущего инструмента

в вас какой-то жуткий технарь говорит :)
Управление качеством построено на мат.статистике, на нормальном законе распределения, поэтому нужны цифры.
Например, для прогнозирования качества. Если у вас все детали просто "годные", потому что попали в квалитет, то вы не можете спрогнозировать процент брака. Потому что не знаете распределение размера внутри квалитета.
Если распределение размера занимает весь квалитет, то вы на грани, и в любой момент, по мизерной причине может пойти брак. Прогнозный брак составляет 0.27 %, или 2700 деталей на миллион.
Если распределение размера занимает 75% квалитета, да еще мат.ожидание совпадает с серединой поля допуска, то у вас есть запас прочности - как на смещение мат.ожидания, так и на увеличение дисперсии размеров. Прогнозный брак составляет 0.006%, или 60 деталей на миллион.

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

японцы же измеряют каждую деталь (с ваших слов )

такого я не говорил. Иногда да, иногда нет, иногда тоже Булево используют.

Можно ли считать объективным показателем эффективности рейтинг на этом ресурсе ?

Объективным нельзя считать ни один показатель, это всегда результат субъективного выбора. Про выбор показателей качества, вычисление сбалансированного показателя качества написано много литературы.
23. TODD22 19 01.11.17 08:26 Сейчас в теме
(18)
в вас какой-то жуткий технарь говорит :)

Скорее человек понимающий в производстве чуть больше чем прочитанные книжки по lean и 6 сигмам.....
27. 1c-intelligence 12851 01.11.17 08:44 Сейчас в теме
(23) спорить не буду, подходы у нас с вами разные, это давно понятно.
Раз для вас управление качеством производства и производство - одно и то же, то диалога на эту тему у нас не получится.
24. TODD22 19 01.11.17 08:35 Сейчас в теме
(18)
такого я не говорил.

Но привели пример про умных японцев которые измеряют и не очень умных русских которые пользуются лаптем калибром.
28. 1c-intelligence 12851 01.11.17 08:45 Сейчас в теме
(24) да, привел, но не говорил, что японцы измеряют каждую деталь.
29. TODD22 19 01.11.17 08:51 Сейчас в теме
(28) А русские каждую деталь калибром измеряют? Или иногда прибегают к другим методам измерений? Микрометры в руки берут например.
30. 1c-intelligence 12851 01.11.17 08:52 Сейчас в теме
(29) конечно иногда прибегают к другим методам измерений.
Но все равно ошибаются, потому что измеряют на ОТК, когда уже поздно.
34. TODD22 19 01.11.17 09:22 Сейчас в теме
(30)
Но все равно ошибаются, потому что измеряют на ОТК

А что станочник сам не измеряет?

На том производстве где работал я. У каждого токаря(фрезеровщика) были калибры которые проходят поверку и выдаются отделом ОТК для конкретной задачи. Для массового выпуска(когда весь цех занят производством одного какого то вида продукции). Никогда станочник не снимет деталь со станка предварительно не убедившись с помощью измерительного прибора(калибра, микрометра, штангельциркуля и тд) что он получил деталь с нужными параметрами. Ну или он не опытен(стажёр например) ну или сам себе злобный буратино. Потому что при малых допусках ты её назад точно так же не факт что поставишь с первого раза а то и вообще не поставишь. И подгонять потом, делать что бы деталь не "била" то ещё удовольствие. Учитывая то что парк станков уже давно устарел(самые новые были начала 80х годов) на тот момент.

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

И это не автомобильный завод. Это просто маленький машиностроительный завод с несколькими сотнями сотрудников который производил детали для шахтового оборудования.

Или вы хотите сказать что цех взял 8 тонн каких нибудь медных прутков, наточил из них деталей не измеряя их, а потом ОТК признал все детали браком? Я очень сильно сомневаюсь что именно такая ситуация возможна на производстве.

У нас брак был в основном из за определённых технологических процессов. Но это допустимый брак. Например закалка. Когда деталь в процессе закалки изменила форму так что для дальнейшей обработки уже не пригодна. Брак был потому что у кого то руки кривые, брак был из за изношенных станков. Но это единичная деталь. А не так что весь цех работал и не измерял результат своей работы, а потом пришёл ОТК и сказал что всё брак, всё списать на ВО или отправить на доработку.
36. 1c-intelligence 12851 01.11.17 09:31 Сейчас в теме
(34) вы описали процесс, который приводит к некоему результату.
Если результат устраивает - отлично, работаем дальше.
Если результат не устраивает - смотрим, думаем, ищем, меняем. Ну или говорим херня эти все японцы, скрамы, эффективность, программисты и прочие модные штуки. Мы производственники, нам виднее.
Каждый сам решает. И потребитель сам решает, что ему покупать.
38. TODD22 19 01.11.17 10:02 Сейчас в теме
(36)
вы описали процесс, который приводит к некоему результату.

Так про то что детали не измеряют там где их делают, а только проверяют в ОТК это же вроде то же процесс который приводит к некоему результату в виде брака.
40. 1c-intelligence 12851 01.11.17 16:21 Сейчас в теме
(38) да, и то, и другое - процесс, которые приводят к некоему результату.
Потерял нить. Что мы обсуждаем?
25. pm74 203 01.11.17 08:39 Сейчас в теме
(18) потому что я и есть технарь по образованию. К сожалению многие производства сейчас , скатились на уровень кустарщины. Многое из того , что было наработано десятилетиями , похерено и забыто в нулевых. Все заново изобретают велосипед.
для прогнозирования качества
в той же обработке резанием недостаточно собрать статистику отклонения размеров от номинала , вы должны также учесть такие вещи как материал заготовки , термообработка , внутренние деффекты , режущий инструмент , сож и много чего еще поверьте ( я работал на кафедре где не один десяток диссертаций защитили по этим вопросам)

Объективным нельзя считать ни один показатель, это всегда результат субъективного выбора..
тогда в чем смысл? , для самомотивации ?
31. 1c-intelligence 12851 01.11.17 08:55 Сейчас в теме
(25)
тогда в чем смысл? , для самомотивации ?

в чем смысл чего?
Вы делаете продукт - например, публикацию на инфостарте.
Вы решаете, с какой целью делаете публикацию.
Исходя из цели выбираете показатели, или признаки ее качества.
Если вы хотите рейтинга - измеряете рейтинг. Если хотите просмотров - измеряете просмотры. Если хотите минусов - измеряете минусы.
Ну и действия предпринимаете исходя из целей.
Объективности здесь нет и не будет, все в ваших руках.
32. pm74 203 01.11.17 09:08 Сейчас в теме
(31) я имел в виду ответ на вопрос (в тизере вашей публикации)
Почему важно измерять свою работу, и что будет, если этого не делать
33. 1c-intelligence 12851 01.11.17 09:10 Сейчас в теме
(32) статья не дала ответа на этот вопрос?
17. TODD22 19 01.11.17 07:47 Сейчас в теме
Смысл прост. Японцы измеряют деталь, получая цифру – например, диаметр вала 26.34 мм. Из этой цифры они выстраивают шикарную систему управления качеством (результаты ездят по дорогам). База всей системы управления качеством в Японии – цифры. По-умному это называется «количественный признак качества».

Наши братья из автопрома не измеряют детали, они пользуются т.н. калибрами – железяками с двумя размерами, минимальным и максимальным. Деталь в калибр или проходит, или не проходит – т.е. имеем то же Булево.

Иван а вы были на производстве в Японии? Или это только в теории?

я отношусь к числу тех, кто не разбирается.

Это мы уже поняли.
Сурикат; корум; +2 Ответить
20. 1c-intelligence 12851 01.11.17 08:14 Сейчас в теме
(17)
Иван а вы были на производстве в Японии? Или это только в теории?

нет, конечно. Много общался с теми, кто был.
19. unpete 577 01.11.17 08:14 Сейчас в теме
В статье не сказано, что флакон помогает балансировать потоками задач. Наверное, это тема отдельного разговора, лично мне, идеи и качество этой балансировки нравятся.
Остаётся вопрос, что делать с балансировкой задач внутри потока. У нас в Окнософте, в каждом потоке, число задач существенно превышает возможности исполнителей. Из длинного списка всегда можно выбрать интересную работу. А что делать с противными скучными задачами? Баллы оценивают только сложность задачи, но даже если искусственно повысить бал неинтересной задачи, это не будет стимулировать ей заниматься. Метки важно, срочно, могут учитываться исполнителем, они подсказывают направление, но не участвуют в оценке эффективности.
21. 1c-intelligence 12851 01.11.17 08:18 Сейчас в теме
(19) решение есть - оценка и приоритет исходя из синергичности + оценка эффективности в комплексных баллах, учитывающих следование синергичности.
Но это и правда отдельный разговор.
22. genayo 01.11.17 08:22 Сейчас в теме
Вот кстати еще интересен вопрос, на сколько прямая связь между эффективностью и мотивацией, мне кажется, по-отдельности рассматривать их не совсем корректно.
26. 1c-intelligence 12851 01.11.17 08:41 Сейчас в теме
(22) эти вопросы, конечно, связаны. Но могут рассматриваться и по отдельности.
Повышение эффективности через денежную мотивацию рассматривал здесь.

Если применять повышение эффективности лично к себе, то проблема мотивации переходит в проблему самомотивации, а это совсем другая тема.
35. Ibrogim 1328 01.11.17 09:27 Сейчас в теме
(0) А почему бы в качестве оценки задачи не брать планируемое время выполнения.?
37. 1c-intelligence 12851 01.11.17 09:32 Сейчас в теме
41. gubanoff 63 01.11.17 16:56 Сейчас в теме
(37) автору статьи большое спасибо за его труды! :) все статьи читаю очень внимательно и жду новые с нетерпением.
По делу: в чем принципиальное отличие баллов от часов на выполнение? По-моему, это одно и то же.
42. 1c-intelligence 12851 01.11.17 17:12 Сейчас в теме
(41) принципиальной разницы нет, и вообще никакой разницы нет, как назвать метрику.
Автор Scrum рекомендует не использовать именно часы, т.к. у людей плохо получается именно в часах оценивать.
Лучше в собаках, или попугаях. Не важно. Важен относительный разброс оценок относительно друг друга.
43. gubanoff 63 02.11.17 09:26 Сейчас в теме
(42) Система мотивации в этом случае строится на баллах? Если так, то все равно как-то придется баллы в часы переводить, пусть даже косвенно. Должны же мы стоимость одного балла определить.
44. 1c-intelligence 12851 02.11.17 09:33 Сейчас в теме
(43) лично мое мнение - не стоит связывать баллы и систему мотивации. Баллы - очень зыбкая сущность, которую легко разрушить, если примешать к ней деньги.
Деньги должны быть связаны с более реальным результатом - продажами, проектами, метриками автоматизации, актами и т.д.
Если деньги и баллы существуют параллельно, то так еще интереснее - можно сравнивать то, что вы назвали стоимость балла, внешнюю и внутреннюю.
И не факт, что у кого больше баллов, будет делать больше часов и денег.

Мне кажется, во франче такая штука была бы интересна, когда ты повышаешь эффективность разработки (и вообще работы), а клиенту продаешь за те же деньги. Клиенту выгода в более быстром сроке, тебе выгода в большей выработке.
45. TODD22 19 02.11.17 09:51 Сейчас в теме
(44)
Баллы - очень зыбкая сущность, которую легко разрушить, если примешать к ней деньги.

Иногда баллы используют как раз как альтернативу слову "деньги". Для снятия так сказать излишней напряжённости и негатива.
В одной розничной сети штрафовали продавцов с начало в деньгах: "Депремирование на 1000 рублей. За то что не одела форменную одежду!".
Было много негатива по этому поводу.
Заменили деньги на баллы: "Начислен 1 штрафной балл. За то что не одела форменную одежду!"
Как ни странно хотя 1 балл = 1000 руб. Негатива стало значительно меньше. Потом ещё добавили хитрую формулу пересчета баллов что бы окончательно запутать тех кто их получает.
Но по сути паритет сохранился 1 балл = 1000 руб. Но тому кто получает штрафной балл было уже не так просто это в уме просчитывать.
39. akR00b 24 01.11.17 10:46 Сейчас в теме
все по делу, актуально и жизненно, flash-дурилка с нее проорал.
1c-intelligence; +1 Ответить
46. aspirator23 339 04.11.17 13:44 Сейчас в теме
"Если есть статья Винни, то в комментариях всегда найдешь оппонентом боряна петрова". Пора патентовать.
47. user-programmist 4 29.11.17 16:33 Сейчас в теме
Круто написано. Спасибо.
1c-intelligence; +1 Ответить
48. 1c-intelligence 12851 06.07.18 09:29 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
49. strange2007 144 04.10.18 04:24 Сейчас в теме
Может не соглашусь с некоторыми тонкостями методик, но в целом эти знания то, чего мне не хватало в молодости.

Но я возмущён! Автор, Вы ведь умеете более-менее считать и при этом пишите такую ахинею про японское качество тем более в части автомобилей. Как (!!!!!) вообще такое могло прийти в голову? Ведь ни немцы ни японцы никогда не умели и не умеют делать автомобили. Они умеют их продавать, но не делать. Вы бы хоть поинтересовались, что такое качество, а то ведь можно считать качественными только те автомобили, к которым просто применены стандарты и допуски из космической отрасли. Про японокачественные (или немецике) автомобили все говорят, пока теорию надёжности не поизучают.
В общем капец. Я возмущён.
50. mangy 30 03.11.19 22:40 Сейчас в теме
Скажите, в какой программе рисовали графики эффективности и отмечали события?
51. 1c-intelligence 12851 04.11.19 13:17 Сейчас в теме
(50) задачи вел в гитхабе, а графики рисовал в recharts (это, вроде, d3 под react).
Оставьте свое сообщение