Статья написана как для руководителей, так и для программистов, т.к. описанные методы применимы и для подчиненных, и для себя.
Сначала кратко методику (не все с ней работали), потом – главное, зачем ее применять.
Методика измерения
Сама методика известна давно, никакого секрета собой не представляет – это покер планирования из Scrum. Чтобы ее применять, не нужно применять весь Scrum.
Алгоритм измерений прост, как автомат Калашникова. Каждая задача, которую вы собираетесь решать, должна получить оценку в баллах – цифрах из ряда Фибоначчи. Вот эти цифры: 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Каждая цифра является суммой двух предыдущих (один элемент ряда пропущен, по понятным причинам). Некоторые ребята называют цифры не баллами, а сторипойнтами (story points). Тут как хотите, мне ближе и проще говорить «баллы».
Ряд Фибоначчи выбран разработчиками Scrum потому, что соседние оценки стоят друг от друга довольно далеко, и позволяют точнее идентифицировать разницу в сложности задач. Одно дело – выбирать между оценками 7 и 8, совсем другое – между 5 и 8.
Если у вас команда, то желательно, чтобы оценивали все ее члены. Изготавливаете из бумажек или покупаете карты для покера планирования – это просто бумажки, на которых написаны цифры из ряда. Собираетесь вместе, каждый ставит свою оценку на задачу – кладет карту рубашкой наверх. Переворачиваете, смотрите – если есть оценки, стоящие друг от друга дальше, чем на один элемент ряда (например, 3 и 8) – еще раз обсуждаете задачу, т.к. кто-то что-то не понял. Или переоценил сложность, т.к. не знает деталей или механизмов реализации, или недооценил, по той же причине. Повторяете оценку.
Как только удалось добиться правильной разницы в оценках – не дальше одного элемента ряда – считаете среднюю, это и будет оценка задачи.
Если команды у вас нет, или они не хотят развиваться вместе с вами, ставьте оценки самостоятельно. В этом случае карты вам не нужны.
Чтобы оценки не уплывали в сторону увеличения или снижения, придумайте себе якорь. Самый простой якорь – решить, что есть задача на 1 балл. Это – бит вашей работы, самое простое из того, что вам приходится делать. Например, добавить поле ввода. Можно придумать не один, а несколько якорей, если вам так проще.
Тут правил нет. Главное – чтобы система оценок не уплывала, иначе начнется не измерение, а иллюзия. В этом смысле проще, когда есть команда, т.к. несколько человек обычно тщательнее следят за системой координат, чем один.
Разумеется, систему учета оценок надо автоматизировать. Это очень просто – достаточно к объекту системы, который у вас содержит задачи, приделать числовое поле и заполнять его.
Если вы ведете свои задачи в GitHub, то можно использовать метки (labels). Достаточно в метки добавить ряд чисел, и каждой задаче назначать подходящую метку, а потом собрать оценки через API. Я сам веду задачи в GitHub и собираю оттуда оценку простеньким скриптом.
Также стоит отметить, что в вашей системе у задачи должна быть дата выполнения, иначе сложно будет анализировать эффективность. Что есть дата выполнения – вам на месте виднее. Это может быть дата отметки исполнителем, дата приемки заказчиком, дата проверки тестировщиком – что вам ближе.
Лично мне ближе дата отметки исполнителем + условие, что задача принята заказчиком, потому что от исполнения до приемки может пройти несколько дней, и если брать дату приемки, то задачи будут попадать не в тот период, когда выполнены. Знать период, когда задача выполнена, важно – это станет понятно из дальнейшего изложения.
На выходе система измерения должна давать нам такую табличку:
В отчетах даты лучше группировать по разным периодам, чтобы видеть динамику. У меня спринт недельный, поэтому смотрю обычно по неделям. Но иногда и по месяцам, чтобы картина была более полной.
Немного поговорим о том, как на нее смотреть.
Как смотреть результаты
Лично мне ближе всего графики. Например, вот так выглядит график моей эффективности, нарисованный через Google Charts в flowcon:
На диаграмме сразу видны тренды, понятна динамика, легко визуально сравнить две точки по высоте.
Также полезно бывает выводить на графике не сумму баллов за неделю, а баллы за человекодень – достаточно поделить сумму баллов на количество дней, которое человек работал. Это на тот случай, если люди работают по разному графику, или, например, берут день без содержания, или подолгу торчат на совещаниях. Но важнее, конечно, объем выполненной работы за весь период.
Крайне важно, чтобы график можно было смотреть в течение недели, и на нем сразу появлялись баллы выполненных задач – то, что в Scrum называется «Диаграмма сгорания задач». Это основной инструмент контроллинга в течение недели, позволяющий увидеть текущую эффективность и принять своевременные меры к ее улучшению.
Теперь поговорим об том, как выглядит управление собой и командой без измерений, т.е. об иллюзиях.
Flash-дурилка
Есть у вас измерения, или нет у вас измерений – вы все равно составляете некоторое представление об эффективности работы, своей и команды.
Один из способов, используемых сознательно и подсознательно – flash-дурилка. Делается очень просто – надо в конце отчетного периода выдать Нечто, и именно нечто запомнится как главный итог периода.
Например, программист всю неделю тупит, ничего не выдает, ковыряется в носу, а в пятницу выдает «на гора» некое решение. Вы, как руководитель, по итогам недели видите это решение, и вся неделя запоминается в его контексте. Если спросить вас через 1, 2 или 3 недели, как работал программист в такой-то период, вы вспомните это решение, выданное «на гора» — flash-дурилку.
У инструмента flash-дурилка есть несколько названий, одно из самых распространенных – ИБД, имитация бурной деятельности, которой пользуются практически все сотрудники, особенно крупных предприятий. Вы сами найдете массу примеров в жизни своего предприятия.
Например, я видел компанию, которая составляла план стратегического развития на каждый квартал. Всем руководителям служб и подразделений доставались какие-то проекты, призванные поднять предприятие на новый уровень. Было очевидно, что до конца квартала об этом плане никто не вспоминал, а под конец начиналось бурление. Каждый выбирал из своего плана наиболее простые задачи, и старался до стратегической сессии чего-то выдать, пусть и полуфабрикат. Цель – чтобы на стратегической сессии по итогам квартала было что показать. Пусть из 10 проектов будет сделан один – квартал запомнится, как успешный (или хотя бы не провальный).
Такой прием постоянно используют в государственном управлении деревень, вроде нашего Челябинска. У нас в городе большие проблемы с экологией – иногда просто невозможно дышать от выбросов. Угадайте, когда в нашем городе чисто, красиво и воздух, как в горах Кавказа? Когда приезжает президент или премьер-министр. Это flash-дурилка для них. Последняя дата – 9 ноября, какой-то форум проходил. Ждали с нетерпением, смогли за пивом без противогаза сбегать. Что запомнили гости Челябинска по итогам визита? Город чистый, ларьков с шаурмой нет, воздух прекрасный, немного пованивает выхлопными газами – ну куда ж без этого, город миллионник. Простейшая система измерений – процент дней, когда дышать невозможно – убила бы возможность показывать flash-дурилки.
Что важно – flash-дурилки работают не только для других, но и для себя. Себя обмануть даже легче, чем других – вы ведь с собой быстрее и проще договоритесь, чем с начальником. Можно точно также неделю просидеть, ковыряясь в интернете, в пятницу выдать Нечто, и запомнить этот период как успешный.
Самый парадоксальный вариант – виртуальная flash-дурилка, применяется как по отношению к себе, так и для начальства. Это когда вы выдаете Нечто в конце периода, и дополняете обещанием, что дальше все будет еще лучше. «Согласен, понимаю, что могу лучше и больше, но посмотрите, что я выдал в пятницу, я теперь осознал, как работать лучше, и на следующей неделе все изменится к лучшему, я теперь понял, и динамика у меня отличная».
Булево vs Число
Традиционная система измерения работы программистов и не только – управление по срокам. Говоря нашим языком, у выполненной задачи или проекта есть вычисляемый параметр – «выполнена в срок». Сами понимаете, этот параметр типа Булево.
И вот на этих булевых строится управление. Таблица исходных данных выглядит так:
Для каждой конкретной задачи булево какой-то физический смысл имеет. Чтобы оценить работу за период, уже нужна более сложная функция. Надо добавить виртуальную колонку «Количество задач», поставить там формулу, которая за выполненную в срок задачу даст единичку, а за невыполненную — нолик.
Получится некое подобие цифровой оценки – сколько задач за период выполнено в срок, или процент выполненных в срок задач.
Можно ли управлять собой и командой, зная лишь такую цифру? Безусловно, большинство людей этим и занимаются. Несколько лет назад я сам считал, что так и надо, и даже построил систему управления задачами для всех сотрудников предприятия на такой системе. Мне до сих пор стыдно.
Реальность показала мне, что управление по булевой цифре бессмысленно. Кривая эффективности очень быстро становится ровной, и перестает давать хоть какую-то полезную информацию для корректирующих действий, потому что отвечает только на один вопрос – попадает ли человек в срок.
Ответа на вопрос «эффективно ли человек работает?» булева цифра не дает. Она говорит – «человек выполнил все задачи в срок». На следующей неделе повторяет – «человек выполнил все задачи в срок». И т.д.
Я спрашиваю «а человек на какой неделе лучше работал?», или «а вот этот человек лучше того работал или хуже?». Булева цифра отвечает – «не знаю, нашел что спросить. Оба выполнили все задачи в срок». Я говорю – «Siri булева цифра, ты дура?». «Вообще-то, это очень обидно» — отвечает бессмысленная машина.
Самое гадкое, что такой подход к измерениям убивает мотивацию к повышению эффективности – и у начальника, и у подчиненного. Эффективности вообще нет в формуле. Цель одна – выполнить в срок, сделать Булево = Истина.
Самые простые варианты достижения Булево=Истина:
• Брать на себя поменьше задач;
• Отжимать сроки подлиннее;
• Требовать ТЗ, прототипирование, миллион согласований;
• Создавать алгоритмы переноса сроков при изменении требований и ресурсов;
• Разводить бюрократию везде, где только можно;
• Добавлять ненужные этапы решения задачи, в которых можно растворить прибавку к срокам (например, тестирование всего подряд);
• И т.д.
Разницу между Булево и Цифрой придумали, проверили и показали практикой японцы, в своих системах управления качеством.
Смысл прост. Японцы измеряют деталь, получая цифру – например, диаметр вала 26.34 мм. Из этой цифры они выстраивают шикарную систему управления качеством (результаты ездят по дорогам). База всей системы управления качеством в Японии – цифры. По-умному это называется «количественный признак качества».
Наши братья из автопрома не измеряют детали, они пользуются т.н. калибрами – железяками с двумя размерами, минимальным и максимальным. Деталь в калибр или проходит, или не проходит – т.е. имеем то же Булево. По-умному это называется «альтернативный признак качества».
Японцы и для альтернативных признаков придумали системы управления, т.к. тоже ими пользуются. Например, «внешний вид детали соответствует требованиям» — сложно измерить в цифре. Но это вспомогательные признаки, основа же – цифра.
Влияние Булева на управление
Вы наверняка видели много управленцев, которые занимаются только одним делом – управлением. И заняты этим делом постоянно, весь день, еще и после работы задерживаются.
Причина зачастую проста – они подсели на Булево, но жизнь требует большего. Недостатки системы измерения менеджерам приходится компенсировать своим непосредственным участием и личным присутствием.
Особенно это касается здоровых, адекватных, но застрявших в прошлом менеджеров. Они подсознательно понимают, что чего-то не хватает, что-то упущено в системе оценки и управления. Их здравый смысл и ответственность говорят – от тебя требуют реальных результатов, а не комбинации флажков и отчетов.
А как понять, что работа идет хорошо, если у тебя только Булево? Инструменты известны и широко применяются:
• Проводить совещания;
• Подходить и спрашивать, как дела;
• Лично проверять результаты и процесс;
• Требовать отчеты о проделанной работе (в виде текста обычно);
• Составлять и вести планы-графики;
• И т.д.
Такая работа занимает все свободное время менеджера, и это настолько вошло в привычку у всех, что диву даешься. Сами можете прикинуть, сколько денег уходит на такой менеджмент в компаниях.
Таких здоровых менеджеров даже жалко, потому что рядом вполне прилично существуют нездоровые менеджеры, которые поняли правила игры – это бюрократы.
Бюрократы знают, что не обязательно выдавать полезные результаты – достаточно, чтобы Булево было равно Истина. И иногда надо делать flash-дурилку.
Конфликты и взаимоотношения здоровых и нездоровых менеджеров вы можете пронаблюдать сами, в своей компании. Это очень занимательно, хотя и грустно, потому что нездоровые обычно более успешны в карьере.
Развитие на цифрах
Как упоминалось выше, без цифр нет понятия об эффективности. Раз нет понятия об эффективности, не будет ее развития.
Развитие – это повышение эффективности, так или иначе. Эффективность, в классике – это затраты на производство результата.
Если вы – программист, и вам платят оклад, то затраты на вас – постоянны. Значит, чтобы повысить эффективность, надо увеличить результат.
Хотя в жизни, конечно, обычно оклад уменьшают – речь не только о программистах. Непонимание развития эффективности через увеличение полезного результата, т.е. КПД, ведет к тому, что первой мерой повышения эффективности у нас всегда считают уменьшение зарплаты. Это очень грустно, и это следствие победы иллюзий.
Но не будем о грустном, вернемся к развитию. Все очень просто – пока вы не измеряете количество произведенного результата за период, вы ничего не знаете о своей эффективности.
Дальше еще проще. Если вы не знаете свою эффективность, то вы не знаете ее динамику – растет она или падает.
Ну и совсем просто – если вы не знаете эффективности и ее динамики, то ничего не сможете с ней сделать. Не придумаете мероприятия по повышению эффективности, не будете следить за событиями и контекстом, чтобы понять их влияние на эффективность, и т.д.
Самое гадкое не то, что вы не сможете, а то, что вы не будете. Даже пробовать.
И команда ваша не будет пробовать, потому что она тоже в плену иллюзий.
Если же отбросить иллюзии, и начать измерять, то работа над эффективностью станет реальной.
Работа над эффективностью
Тема обширная и глубокая, и обычно – строго индивидуальная. Я обязательно расскажу все, что знаю о повышении эффективности, в последующих статьях. Пока расскажу один универсальный прием.
Придумал прием не я, а те же японцы (у которых, кстати, и автор Scrum очень много полезного взял, и не стеснялся об этом говорить).
Прием простой – записывать все изменения и значащие события, происходящие с процессом, и отмечать их на графике эффективности. Японцы рисуют такие штуки на своих контрольных картах.
Вот график моей эффективности с наложенными событиями:
О чем говорят маркеры? Начало работы в flowcon, по сути, означает, что я выставит свою эффективность напоказ. Раньше я держал ее в секрете. Какой вывод? Лично для меня полезно, чтобы мою эффективность кто-то видел – меня это подстегивает.
Второй маркер это доказывает. Пока шел рефакторинг, я смотрел эффективность своим старым, скрытым от публики, инструментом – и она пошла вниз.
Третий маркер говорит, что я нарушил одно из своих правил – не копаться в больших механизмах в одиночестве, особенно если мне надо решить небольшую задачу. Я прокопался три дня, и по результатам сделал задачу на 8 баллов. Вроде ничего страшного, покопался – значит разобрался, в следующий раз решу задачу быстрее. Но лично для меня это не эффективно – я знаю, что забуду все это через месяц, а задачи по этому механизму возникают раз в полгода, т.к. все уже написано и отлажено.
А вот график с маркерами моего падавана (он учится программированию):
Первый маркер сказал мне, что когда я даю ему задачи на уже известные механизмы, то он решает их хорошо и быстро. Так мы закрепляем материал.
Второй маркер говорит, что если дать падавану большую задачу, содержащую не один, а сразу несколько новых механизмов, то возникает бутылочное горлышко. Один новый механизм он, грубо говоря, осваивает за 3 часа, два новых механизма – за 8 часов, три новых механизма – за 16 часов и т.д., зависимость нелинейная. На втором маркере я дал задачу, содержащую более 5 новых механизмов, и падаван не смог решить эту задачу за неделю. Какой вывод конкретно для этого падавана – не ронять его большим объемом знаний за один присест.
Третий маркер я пока сам не понял, он случился неделю назад. Задачи были сложные, механизмы новые, алгоритмы серьезные (для его уровня), но он выдал самую высокую эффективность за всю историю. Буду анализировать. Возможно, был какой-то душевный подъем, вообще не связанный с работой.
События на диаграммах нужны и важны, хотя бы потому, что если их не записывать, то они забудутся. Понимание причин как роста, так и провала эффективности – суть управления улучшениями. Вы вносите изменение в работу, отмечаете это событие на графике, и смотрите результат в цифрах. Если результат ухудшился или остался на месте – изменение не имеет смысла, или его надо доработать. Если результат улучшился – изменение надо зафиксировать, сделать частью процесса.
Если процесс изменился в лучшую сторону без внесения изменений – надо понять причину, увидеть изменения, которые произошли без вашего участия, и сделать их частью системы. Вполне возможно, что кто-то из вашей команды втихую что-то улучшил, и ждет, что вы заметите и похвалите, а вы проворонили. Ну и в конце концов может оказаться, что главный ухудшитель эффективности – вы сами со своими дурацкими изменениями. Тогда лучшим изменением будет прекращение изменений, хотя бы на время, и система сама себя отрегулирует. Ровно в таком режиме я нахожусь сейчас, после третьего маркера падавана.
С чего начать
Начните с себя (если хотите, разумеется).
Вам никто не запрещает измерять свою эффективность и работать над ее повышением. Работая молча, никому не рассказывая, вы быстрее достигнете результата, потому что не нужно никому ничего объяснять и доказывать.
Просто оцениваете задачи, которые решаете, в баллах, и ведете статистику. Отмечаете события, внесенные вами и окружающей средой изменения. Анализируете причины роста и падения эффективности.
Ну или убедитесь, что это не ваше, и вам и так нормально.
Возможно, даже вероятно, что ваше руководство этого не просит, не ждет и не поймет. Но работа над собственной эффективностью – это лично ваш товар, продукт. Вы можете его продать своему работодателю, а можете оставить своим секретом. Это ведь не последний ваш работодатель.
В моей практике постоянно случалось, что руководство как-то где-то узнавало о том, что написано в этой статье – необходимости измерения результатов и повышения эффективности. В такие моменты очень пригождалась моя молчаливая система измерения собственной эффективности. Так, например, было, когда руководство прочитало Scrum и вспомнило, что у программистов висит доска со стикерами. Появился отличный повод поговорить, который обернулся скачком по карьерной лестнице.
Но главное, конечно, собственная эффективность и умение ей управлять. Этого никто не отнимет.
Автор: nmivan
