Первые, самые главные часы – те, что мы выставляем клиенту. В зависимости от ситуации, мы либо договариваемся о часах заранее, либо выставляем по факту – сколько затратил программист.
Вторые часы – те, что назвал программист, отвечая на вопрос «сколько тебе надо времени на решение задачи?». Если мы договариваемся с клиентом заранее, то именно эти часы и выставляем для продажи. Если оплата идет по факту, то мы спрашиваем оценку у программиста для целей планирования.
Третьи часы – сколько программист потратил на решение задачи по факту. С той плановой цифрой, которую он сам назвал, эти часы совпадают крайне редко, и это нормально – никто не умеет точно планировать свое время, потому что на работу программиста действует множество сил из окружающей среды – он отвлекается, он не в настроении, он сталкивается с непредвиденными трудностями и т.д.
Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.
А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?
Можно ответить туманно: эффективность работы программиста. Хорошо, а как, и что мы будем измерять? В наличии у нас, напоминаю, три или четыре вида часов.
Попробуйте сказать программисту: хотим, чтобы ты производил больше часов. Что он ответит? Программист – парень толковый, в институте учился, и он сразу вспомнит о пятой метрике – количестве часов в сутках. И смело вам об этом скажет – я не могу работать больше, чем 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С – достаточно добавить числовое поле к объекту метаданных, который хранит ваши задачи. Ну и написать несколько отчетов по балльной системе – сколько задач решено, кем, когда, сколько еще не принято в работу, сколько ожидает принятия заказчиком и т.д.
Резюме
- Измерение задач только в часах лишает вас возможности повысить эффективность;
- Измерять задачи лучше в натуральных единицах – баллах;
- Начинать внедрение баллов лучше с командного покера планирования;
- Когда система оценок станет понятна команде, можно отдать оценку одному человеку;
- Оценка в баллах дает понимание эффективности;
- Учет баллов обязательно нужно автоматизировать.
Комментарии (46)
alexkuzko
04.05.2019 14:29А потом настанет синергия команды, и количество баллов на любую задачу будет увеличиваться. Ведь тут можно крутить в обе стороны, правда? )
TiesP
04.05.2019 14:34По идее, сначала эти баллы будут оценивать, сколько времени вы работали продуктивно в этот день/неделю. Поскольку баллы всё равно изначально привязаны ко времени:
Обычно, насколько я знаю, время работы программистов тарифицируется кратно 15 минутам. Какие задачи вы обычно решаете за 15 минут?
Конечно, здесь тоже уже можно повышать эффективность (или продуктивность)… потому что часто время уходит не на работу). Ну а дальше, с ростом мастерства (или знания/применения лучших инструментов), получится что вы одну и ту же задачу можете решить намного быстрее, чем раньше… но это будет не сразу
b00b1ik
04.05.2019 14:37А в чем отличие от обычной методики освоенного обьема, в которой все задачи в часах, которые можно легко назвать попугаями, но через 200 рабочих часов, задачу нужно закрыть так как пришел срок сдачи?
После прочтение сложилось ощущение, что автор продавец от бога и может действительно продавать просто время, без результата деятельности! Тогда вы нереально ценный кадр, вас оставить, программистов разогнать и про баллы не вспоминать.
Хотя мне кажется вы просто не умеете абстрагировать от слова часы и понять что они значат не только физическое время, и назвав наконец-то их баллами смогли начать работать.
lamerok
04.05.2019 14:41Непонятно почему заминусована, идея разумная. Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.
Т. Е. По факту все скажут разное значение времени, однако существует тот факт, что расстояние до города одно и то же.
Т. Е. Вместо времени, можно использовать другую величину — расстояние ( баллы) в данном случае.
Единственное замечание, что баллы или поинты логично применять для Фичей, а не для Задач. Задачи сами по себе небольшие должны быть… 8-16 часов, максимум для любого программиста, в идеале 1 задача один день и измерять их в баллах уже смысла нет, а вот фичи очень даже, потом считать скорость спринта и на следующий спринт брать столтко фичи на столько баллов, на сколько было сделано фичей в предыдущем спринте. Таким образом менеджеру после каждого спринта можно уточнять прогноз по финальной дате.ni-co
04.05.2019 15:19Может потому, что люди, участвующие в разработке не видят никакой разумной причины менять «часы» на «балы». И еще тратить свое время на автоматизацию подсчета?
vassabi
06.05.2019 11:38Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.
фишка в том, что аналогия не очень хорошо работает:
1) никто туда еще не бегал — фича-то еще не сделана.
2) куда именно бежать — не настолько точно известно (менеджер будет говорить «А», а иметь в виду А1, бегуны будут слышать «А», а подумают на А2). Вот когда прибегут — тогда и будет известно, что «добежали».
Gorthauer87
04.05.2019 16:46+2Такой подход еще возможно будет хоть как то работать в продуктовой разработке, которая хотя бы немного конвеер напоминает и в общем то является типовой.
Но стоит ее применить к r&d так все рассыпется а все специалисты просто разбегуться.
В конце концов, от ученых же не ждут, что они смогут оценить сложность исследований и декомпозировать их на простые понятные задачи.
nmivan Автор
04.05.2019 16:53Да, для rnd не подходит.
Gorthauer87
04.05.2019 18:33+1А об этом году нибудь пишут красными буквами?
nmivan Автор
04.05.2019 19:14Так вы же разобрались без красных букв.
К тому же, каков процент rnd среди всей разработки? Кроме rnd, полно другой экзотикт — красных букв не хватит перечислить.Gorthauer87
04.05.2019 22:04Вообще не такой уж маленький, к тому же я видел, что бывает если пытаться сторипойнты использовать в задачах, где нет понятного решения.
В лучшем случае просто каждый раз решение ускользало оставляя еще ворох задач на которые необходимо было тратить время и внимание на оценку.
То есть инструмент просто переставал работать, но его недостатки остались на местеnmivan Автор
04.05.2019 22:37Я постоянно использую оценки в задачах, где изначально не понятно решение, трудоемкость и в процессе генерируются новые задачи. Просто оценку ставлю после решения.
boodda
05.05.2019 10:09Например, разного рода интеграции одних сервисов в другие. Бывают сервисы с огромным API. Написание кода по встраиванию могут сопровождаться разными проблемами, в том числе концептуальными. И никто не может внятно оценить время на это, от дня до года. Одну из систем интегрировали почти год). В момент планирования, у скрам-мастера текут кровавые слезы, а у менеджера проекта появляются тики.
RaFaeL-NN
04.05.2019 23:18Есть еще как минимум пятые часы — это когда сначала договариваются о сумме, а затем уже делением на стоимость часа получают «часы». Они, как правило, больше всех вышеперечисленных, хотя в некоторых случаях могут быть и меньше реально затраченных
nmivan Автор
04.05.2019 23:41Мне кажется, договариваясь о сумме, программисты всегда сразу, в уме, переводят ее в часы, недели, или месяцы.
RaFaeL-NN
05.05.2019 00:22Это только в случае, если клиент не согласился заплатить больше. Т.е. сначала называется некая большая сумма, а вот если «не прокатило», тогда можно уже и посчитать. Но ведь может и прокатить
b00b1ik
05.05.2019 00:05А есть еще часы, которые скрыли в себе все накладные расходы. То есть чтобы в договоре Заказчик видел только часы приведенные к стоимости человекочаса, но платил за все и не беспокоился за это.
Это уже 6 часы или эти 5-е?)
qw1
05.05.2019 09:50+1Странно, что статья начинается с проблемы заказчика — как так, он покупает непонятные часы, которые ему нафиг не нужны. А потом оказывается, что ему надо покупать ещё более непонятные баллы. Которые в отличие от времени даже не привязаны к реальности, а у всех команд разные, так что даже и сравнить не получится.
Понятно, что инструмент внутренний. Но начало статьи сбивает с толку.
lotse8
05.05.2019 15:51Баллы — это все равно производная от времени, поэтому лишний элемент. Есть проект, по нему составляется спецификация и по каждому пункту оценивается время в часах. Это проектное время, по нему оценки и оплата.
Программист получает конкретную задачу, которая оценена на 6 часов, например. За месяц объем работы на 120 проектных часов нужно сделать каждому. Если не успевает — надо разбираться почему и помогать, а если помощь без результатов, то увольнять. Если успевает за месяц сделать объем задач не на 120 часов, а на 200, то срочно надо повышать зарплату. И все это с учетом качества — исправления багов по протоколам тестировщиков тоже надо учитывать, у кого сколько.
Заказчику счет выставляется за проект, а не за часы. За часы выставляется счет, когда нет четкой задачи или время решения неизвестно: надо что-то либо исследовать, либо старый код поковырять, либо еще что-то подобное. И даже в этом случае я бы предпочел дать заказчику вилку в деньгах от Х до У, а потом выставить счет по факту в пределах этой вилки.
Если будете выставлять заказчику счет за часы, то он найдет того, кто оценит работу на меньшее количество часов и будет вас носом тыкать, что вы время ему завышаете. А если почасовая ставка покажется заказчику высокой, то будет тыкать вас в ставки индусов или программистов из Сычевки Смоленской области (как пример). Явно Вы с заказчиками мало работали.
55m55
05.05.2019 20:48Измерять задачи лучше в натуральных единицах – баллах;
А можно ссылку на стандарт, руководящий документ, учебник или учебное пособие, где бы балл вводился как натуральная единица измерения? Мерой какого физического (естественного = природного = натурального) явления такой балл является?nmivan Автор
05.05.2019 20:54Был такой музыкант — Михаил Горшенёв. Его как-то спросили: как понять, что музыка — хорошая?
Он ответил: хорошая — это когда слушаешь и ммм… Зае@ись!
Можете придумать более натуральную оценку качества музыки?
Нужен ли вам стандарт, руководящий документ или что-то еще для того, чтобы этой оценкой пользоваться и называть ее натуральной?55m55
05.05.2019 21:34+1Ну, тогда так и пишите:… в «натуральных по Ивану Б.» единицах. Чтобы не было путаницы с понятийным аппаратом хозяйственной статистики.
А между тем, Горшок мертв, Ваша статья не о музыке, а п. 2 (на мой взгляд, конечно же) не имел бы шизофренического оттенка и был бы более соответствующим и Вашему тексту про управление, и духу Вашего же комментария, если бы советовал «измерять задачи лучше в порядковых величинах и выражать в [абстрагированных] баллах».nmivan Автор
05.05.2019 21:46Как я могу не допускать путаницы с понятийным аппаратом хозяйственной статистики, если я только из вашего комментария узнал о ее существовании?
Сейчас еще кто-нибудь прибежит, и скажет, что слово «баран» в моей статье не соответствует ГОСТ 28509-90 «Овчины невыделанные. Технические условия».55m55
05.05.2019 22:21Очень странно, что Вы ничего не слышали о статистике, хотя даже эту свою статью Вы в конце-концов к ней сводите. Вы же пишите об анализе хозяйственной деятельности предприятия (в общем) с целью повышения эффективности (в частном). Эта область не нова, в ней уже имеется сложившийся понятийный аппарат, в том числе статистический.
Поэтому я Вас и спрашивал, увидев в тексте «натуральных единицах – баллах», без тени сарказма (все-то знать невозможно), это что-то новое в науке микроэкономике, как человека, заявляющего об инновациях, а оказывается это квадратноколесные велосипеды автора.
Может быть, если не изобретать очередной новояз там, где и уже имеющийся язык замечательно распространен и справляется, больше людей будут Вас понимать (покупать)?
nmivan Автор
05.05.2019 22:42К сожалению, как ни стараюсь, не могу без сарказма рассуждать на подобные темы.
Про статистику знаю. Про хозяйственную статистику — нет.
Мне всегда казалось, что в бизнесе результат важнее терминологии.mirror13
06.05.2019 08:02+1Часто самые большие споры разгораются как раз на почве терминологии и слегка разном её понимании оппонентами, а на выявление различий в понимании тратиться много ресурсов. Как, например, получилось выше.
Поэтому точности формулировок и однозначному их пониманию всеми участинками стоит уделять особое внимание.
Думаю, что и в бизнесе должно быть также.
tymanst
05.05.2019 20:52Мне кажется высок риск иллюзорного прироста производительности. Когда в результате внедрения чего-то меняется система распределения баллов а не реальная эффективность. Грубо говоря начали дробить задачи на более мелкие и оценивать их выше чем старую задачу до этого. В итое программисты стали зарабатывать в 3 раза больше баллов, но реальная эффективность могла вырасти только на 30% или вообще не изменится.
У баллов ведь те те же проблемы, что у часов, только они не ограничены физическими ограничениями как время и допускают свободное их увелечение и уменьшение.
eugene_bx
05.05.2019 22:03У нас баллы были относительно прошлых задач, т.е. определялся некий набор недавно сделанных задач и баллы присваивались по сложности примерно соотсветсвующей одной из тех задач.
Плюс было утверждение: 5 баллов + 3 балла != 8 баллов. т.е. нету прямого соответсвия сложности.
Но конечно потом всё равно баллы складываются, делятся и к часам привязываются. Хотя процесс реально работал, оставалось странное послевкусие от ощущения некой игры.
Aingis
05.05.2019 22:25Отличный способ, но со многими НО:
1) Это должна быть разработка фич. Исправление багов занимает непредсказуемое время. Даже если большинство исправлений производится быстро, иногда много времени занимает тестирование. Особенно, если исправление оказалось неправильным. В моей практике бывало, что какая-то часть просто недописана. (Кроме того, багфиксинг в больших количествах сам по себе демотивирует людей, эффективность будет снижаться.)
2) Задачи должны быть хорошо описаны и декомпозированы. Просто для того, чтобы было то самое хорошее понимание, и не было зависимостей от внешних условий (например, неделю ждал дизайна/ответа от человека вне команды). А это сама по себе работа, которая тоже важна, но которую почему-то никто не оценивает.
3) Разработчики должны достаточно хорошо ориентироваться в кодовой базе. Новичок ничего не сможет сказать.
4) Выгодно завышать оценку, так же как выгодно делать оценку времени с запасом.
5) Непредсказуемость факторов «множества сил из окружающей среды – он [программист] отвлекается, он не в настроении, он сталкивается с непредвиденными трудностями и т.д.» никуда не?девается. В лучшем случае помогает декомпозиция и подготовка из 2 пункта.
6) На планирование и подготовку тратится время всей команды, хотя скорей всего конкретными задачами будут заниматься не все, а скорее только один человек на задачу. На синхронизацию этого действа тоже будут неизбежные потери.
Как итог, не понятно чем это лучше той самой оценки времени, скажем, техлидом, только названо по-другому. Так можно контролировать работу не слишком мотивированных сотрудников как на конвеере и при таких же конвеерных задачах, но не будет никакой выгоды по сравнению с работой реально мотивированных программистов, особенно когда речь идёт о какой-то качественной работе, такой как написание платформы, рефакторинг или исследование новых возможностей.
Akela_wolf
06.05.2019 08:10Мне в этой системе больше всего сбивает с толку отсутствие эталона «балла». В результате чего балл может довольно легко «плыть», если сегодня задачу оценивали в 5 баллов, то завтра аналогичную задачу оценят в 3 (и сделают за меньшее время). Производительность команды в баллах осталась прежней, реальная производительность (задач в час) выросла но метрика этого не показывает.
Или наоборот, сегодняшнюю задачу на 5 баллов оценят в 8, метрика покажет рост производительность «баллов в час», реальная производительность останется той же.
Чтобы этого избегать нужен какой-то устоявшийся механизм оценки сложности задач. Плюс «воронка погрешности» т.к. редко какую задачу можно оценить сразу — обычно всегда имеются недосказанности или, еще хуже, изменения прямо по ходу работы.mirror13
06.05.2019 08:32Если я правильно понял, то для этого как раз можно использовать «якоря», про которые было сказано в конце статьи.
Akela_wolf
06.05.2019 13:15Якоря хороши, если задачу можно достаточно легко сравнить с «якорем». Но это означает что мы работаем с типовыми задачами, которые легко сравнивать и оценивать.
Однако, как быть если задача не имеет подходящего «якоря»? Скажем проект разработан, теперь команда начинает расширять его функциональность в новую для себя предметную область?mirror13
06.05.2019 15:31+1Один мой друг, например, такие "якоря" применяет:
1: Ничего проще не бывает. Например, поменять конфиг 2: Знаем, как делать, мало писать 3: Знаем, как делать, но много писать или сложные тесты 5: Нужно думать, пробовать, писать. И/или будут легаси либо 3парти сюрпризы 8: Нужно разбивать задачуAkela_wolf
06.05.2019 15:51Вот за эту градацию — спасибо. Немного подкорректирую и возьму на вооружение.
nekt
06.05.2019 09:35> Первое, что приходит в голову – штуки. Но такая мысль нежизнеспособна – слишком высока вариация между задачами.
Для исследования этой мысли стоит для начала исследовать вариацию между задачами. Возможно там не такая уж и большая разница.
Druu
06.05.2019 12:08Теперь все наши задачи измерены в натуральных единицах – баллах.
А чем баллы лучше и натуральнее часов, если одно в другое переводится по формуле 1балл = 15 минут?
dss_kalika
06.05.2019 15:23Эм…
А как это оптимизирует работу программистов?
т.е. раньше они делали, к примеру, по 15 типовых базовых задач в день, а с введением баллов станут делать больше?
Единственное, на что это повлияет — на возможность как то более гибко распределять оплату труда по факту закрытых задач и понимать человеку, который далёк от разработки этого проекта, кто из разработчиков эффективнее, а кто — менее. Хотя это и так должен иметь возможность сказать тимлид (и это, в общем то и так видно).
Одно отличие, правда, есть — числа фибоначи. т.е. рост сложности задачи не линеен ко времени. В этом есть смысл, но это уже из разряда «как правильно оценить задачу по времени».
Я работал в конторе, где была строгая оценка задачь по «баллам» (но мы их называли часами), выдавали премию за достижение определённых показателей и… нет, не наказывали тех, кто не дотягивал (но пристально присматривались). Подход был, конечно, чертовски суровым, оценки — не всегда точными («8 часов на задачу» обычно значили почти неделю работы), но это работало. Правда, не из за «бальной» системы, а мощного контроля за выполнением и хорошо поставленного процесса.
Другое место — пытались внедрить как раз скрам-покер… но, когда в команде — два с половиной разработчика, которые и так струячат с максимальной скоростью и бесперебойностью и на конкретной ЗП (как, наверное, в больше части мест), то это не имело смысла. Эффективнее они работать бы не стали, оценивать их эффективность в баллах смысла так же небыло — от них нужны были не баллы, а решённые задачи.
Но…
Такова участь всех технологий по управлению процессом. Они нужны не для оптимизации процесса, а для прозрачности, осмысленности и управляемости не изнутри, а снаружи.
Вам, как «бизнес-инженеру», надо было обратить именно на это внимание. Это методики «как перестать плыть по течению процесса, и взять его под контроль». =)
ЗЫ: Вы-таки решили поделиться своими секретными технологиями? По моему скромному мнению — в них есть зерно и их можно эффективно и интересно применять. Но надо как следует описать область применения (для каких команд? какого бизнесса? Какого типа проектов?), сместить акценты с того, что это ДЛЯ РАЗРАБОТЧИКОВ на то, что ЭТО ДЛЯ УПРАВЛЕНИЯ РАЗРАБОТЧИКАМИ и ещё много чего. Тем не менее — спасибо за попытки передать опыт )
ЗЫЫ: А ещё, как вариант, было бы интересно сделать песочницу, которая могла бы предложить попробовать управлять проектом с этими технологиями или без. Игровой вариант)
ni-co
Не показывайте эту статью своему боссу. :)
Ещё будете и балы считать. (
qw1
Как в неприличном анекдоте про волка, лису и медведя?