Традиционный способ измерения задач в нашей отрасли – часы. Давайте посчитаем, сколько метрик в часах мы используем.
Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.
Вторые часы – те, что назвал программист, отвечая на вопрос «сколько тебе надо времени на решение задачи?». Если мы договариваемся с клиентом заранее, то именно эти часы и выставляем для продажи. Если оплата идет по факту, то мы спрашиваем оценку у программиста для целей планирования.
Третьи часы – сколько программист потратил на решение задачи по факту. С той плановой цифрой, которую он сам назвал, эти часы совпадают крайне редко, и это нормально – никто не умеет точно планировать свое время, потому что на работу программиста действует множество сил из окружающей среды – он отвлекается, он не в настроении, он сталкивается с непредвиденными трудностями и т.д.
Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.
А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?
Можно ответить туманно: эффективность работы программиста. Хорошо, а как, и что мы будем измерять? В наличии у нас, напоминаю, три или четыре вида часов.
Попробуйте сказать программисту: хотим, чтобы ты производил больше часов. Что он ответит? Программист – парень толковый, в институте учился, и он сразу вспомнит о пятой метрике – количестве часов в сутках. И смело вам об этом скажет – я не могу работать больше, чем 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С – достаточно добавить числовое поле к объекту метаданных, который хранит ваши задачи. Ну и написать несколько отчетов по балльной системе – сколько задач решено, кем, когда, сколько еще не принято в работу, сколько ожидает принятия заказчиком и т.д.
Резюме
- Измерение задач только в часах лишает вас возможности повысить эффективность;
- Измерять задачи лучше в натуральных единицах – баллах;
- Начинать внедрение баллов лучше с командного покера планирования;
- Когда система оценок станет понятна команде, можно отдать оценку одному человеку;
- Оценка в баллах дает понимание эффективности;
- Учет баллов обязательно нужно автоматизировать.
Автор: Иван Белокаменцев
