Как стать автором
Обновить

Комментарии 46

Не показывайте эту статью своему боссу. :)
Ещё будете и балы считать. (

Как в неприличном анекдоте про волка, лису и медведя?
А потом настанет синергия команды, и количество баллов на любую задачу будет увеличиваться. Ведь тут можно крутить в обе стороны, правда? )
НЛО прилетело и опубликовало эту надпись здесь

А в чем отличие от обычной методики освоенного обьема, в которой все задачи в часах, которые можно легко назвать попугаями, но через 200 рабочих часов, задачу нужно закрыть так как пришел срок сдачи?
После прочтение сложилось ощущение, что автор продавец от бога и может действительно продавать просто время, без результата деятельности! Тогда вы нереально ценный кадр, вас оставить, программистов разогнать и про баллы не вспоминать.
Хотя мне кажется вы просто не умеете абстрагировать от слова часы и понять что они значат не только физическое время, и назвав наконец-то их баллами смогли начать работать.

Непонятно почему заминусована, идея разумная. Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.
Т. Е. По факту все скажут разное значение времени, однако существует тот факт, что расстояние до города одно и то же.
Т. Е. Вместо времени, можно использовать другую величину — расстояние ( баллы) в данном случае.
Единственное замечание, что баллы или поинты логично применять для Фичей, а не для Задач. Задачи сами по себе небольшие должны быть… 8-16 часов, максимум для любого программиста, в идеале 1 задача один день и измерять их в баллах уже смысла нет, а вот фичи очень даже, потом считать скорость спринта и на следующий спринт брать столтко фичи на столько баллов, на сколько было сделано фичей в предыдущем спринте. Таким образом менеджеру после каждого спринта можно уточнять прогноз по финальной дате.

Может потому, что люди, участвующие в разработке не видят никакой разумной причины менять «часы» на «балы». И еще тратить свое время на автоматизацию подсчета?
НЛО прилетело и опубликовало эту надпись здесь
Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.
фишка в том, что аналогия не очень хорошо работает:
1) никто туда еще не бегал — фича-то еще не сделана.
2) куда именно бежать — не настолько точно известно (менеджер будет говорить «А», а иметь в виду А1, бегуны будут слышать «А», а подумают на А2). Вот когда прибегут — тогда и будет известно, что «добежали».
НЛО прилетело и опубликовало эту надпись здесь
лет 5 назад

Такой подход еще возможно будет хоть как то работать в продуктовой разработке, которая хотя бы немного конвеер напоминает и в общем то является типовой.
Но стоит ее применить к r&d так все рассыпется а все специалисты просто разбегуться.
В конце концов, от ученых же не ждут, что они смогут оценить сложность исследований и декомпозировать их на простые понятные задачи.

Да, для rnd не подходит.

А об этом году нибудь пишут красными буквами?

Так вы же разобрались без красных букв.
К тому же, каков процент rnd среди всей разработки? Кроме rnd, полно другой экзотикт — красных букв не хватит перечислить.

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

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

Оценку ставите исходя из фактически потраченного времени или сколько стоило потратить?

сколько стоило потратить
Ок, так я и думал.
Например, разного рода интеграции одних сервисов в другие. Бывают сервисы с огромным API. Написание кода по встраиванию могут сопровождаться разными проблемами, в том числе концептуальными. И никто не может внятно оценить время на это, от дня до года. Одну из систем интегрировали почти год). В момент планирования, у скрам-мастера текут кровавые слезы, а у менеджера проекта появляются тики.
Есть еще как минимум пятые часы — это когда сначала договариваются о сумме, а затем уже делением на стоимость часа получают «часы». Они, как правило, больше всех вышеперечисленных, хотя в некоторых случаях могут быть и меньше реально затраченных

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

Это только в случае, если клиент не согласился заплатить больше. Т.е. сначала называется некая большая сумма, а вот если «не прокатило», тогда можно уже и посчитать. Но ведь может и прокатить

А есть еще часы, которые скрыли в себе все накладные расходы. То есть чтобы в договоре Заказчик видел только часы приведенные к стоимости человекочаса, но платил за все и не беспокоился за это.
Это уже 6 часы или эти 5-е?)

Странно, что статья начинается с проблемы заказчика — как так, он покупает непонятные часы, которые ему нафиг не нужны. А потом оказывается, что ему надо покупать ещё более непонятные баллы. Которые в отличие от времени даже не привязаны к реальности, а у всех команд разные, так что даже и сравнить не получится.

Понятно, что инструмент внутренний. Но начало статьи сбивает с толку.
Баллы — это все равно производная от времени, поэтому лишний элемент. Есть проект, по нему составляется спецификация и по каждому пункту оценивается время в часах. Это проектное время, по нему оценки и оплата.
Программист получает конкретную задачу, которая оценена на 6 часов, например. За месяц объем работы на 120 проектных часов нужно сделать каждому. Если не успевает — надо разбираться почему и помогать, а если помощь без результатов, то увольнять. Если успевает за месяц сделать объем задач не на 120 часов, а на 200, то срочно надо повышать зарплату. И все это с учетом качества — исправления багов по протоколам тестировщиков тоже надо учитывать, у кого сколько.
Заказчику счет выставляется за проект, а не за часы. За часы выставляется счет, когда нет четкой задачи или время решения неизвестно: надо что-то либо исследовать, либо старый код поковырять, либо еще что-то подобное. И даже в этом случае я бы предпочел дать заказчику вилку в деньгах от Х до У, а потом выставить счет по факту в пределах этой вилки.
Если будете выставлять заказчику счет за часы, то он найдет того, кто оценит работу на меньшее количество часов и будет вас носом тыкать, что вы время ему завышаете. А если почасовая ставка покажется заказчику высокой, то будет тыкать вас в ставки индусов или программистов из Сычевки Смоленской области (как пример). Явно Вы с заказчиками мало работали.
Измерять задачи лучше в натуральных единицах – баллах;

А можно ссылку на стандарт, руководящий документ, учебник или учебное пособие, где бы балл вводился как натуральная единица измерения? Мерой какого физического (естественного = природного = натурального) явления такой балл является?
Был такой музыкант — Михаил Горшенёв. Его как-то спросили: как понять, что музыка — хорошая?
Он ответил: хорошая — это когда слушаешь и ммм… Зае@ись!

Можете придумать более натуральную оценку качества музыки?
Нужен ли вам стандарт, руководящий документ или что-то еще для того, чтобы этой оценкой пользоваться и называть ее натуральной?
Ну, тогда так и пишите:… в «натуральных по Ивану Б.» единицах. Чтобы не было путаницы с понятийным аппаратом хозяйственной статистики.

А между тем, Горшок мертв, Ваша статья не о музыке, а п. 2 (на мой взгляд, конечно же) не имел бы шизофренического оттенка и был бы более соответствующим и Вашему тексту про управление, и духу Вашего же комментария, если бы советовал «измерять задачи лучше в порядковых величинах и выражать в [абстрагированных] баллах».
Как я могу не допускать путаницы с понятийным аппаратом хозяйственной статистики, если я только из вашего комментария узнал о ее существовании?
Сейчас еще кто-нибудь прибежит, и скажет, что слово «баран» в моей статье не соответствует ГОСТ 28509-90 «Овчины невыделанные. Технические условия».
Очень странно, что Вы ничего не слышали о статистике, хотя даже эту свою статью Вы в конце-концов к ней сводите. Вы же пишите об анализе хозяйственной деятельности предприятия (в общем) с целью повышения эффективности (в частном). Эта область не нова, в ней уже имеется сложившийся понятийный аппарат, в том числе статистический.

Поэтому я Вас и спрашивал, увидев в тексте «натуральных единицах – баллах», без тени сарказма (все-то знать невозможно), это что-то новое в науке микроэкономике, как человека, заявляющего об инновациях, а оказывается это квадратноколесные велосипеды автора.

Может быть, если не изобретать очередной новояз там, где и уже имеющийся язык замечательно распространен и справляется, больше людей будут Вас понимать (покупать)?

К сожалению, как ни стараюсь, не могу без сарказма рассуждать на подобные темы.
Про статистику знаю. Про хозяйственную статистику — нет.
Мне всегда казалось, что в бизнесе результат важнее терминологии.
Часто самые большие споры разгораются как раз на почве терминологии и слегка разном её понимании оппонентами, а на выявление различий в понимании тратиться много ресурсов. Как, например, получилось выше.
Поэтому точности формулировок и однозначному их пониманию всеми участинками стоит уделять особое внимание.
Думаю, что и в бизнесе должно быть также.
Мне кажется высок риск иллюзорного прироста производительности. Когда в результате внедрения чего-то меняется система распределения баллов а не реальная эффективность. Грубо говоря начали дробить задачи на более мелкие и оценивать их выше чем старую задачу до этого. В итое программисты стали зарабатывать в 3 раза больше баллов, но реальная эффективность могла вырасти только на 30% или вообще не изменится.

У баллов ведь те те же проблемы, что у часов, только они не ограничены физическими ограничениями как время и допускают свободное их увелечение и уменьшение.
да, за этим надо тщательно следить.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Мне в этой системе больше всего сбивает с толку отсутствие эталона «балла». В результате чего балл может довольно легко «плыть», если сегодня задачу оценивали в 5 баллов, то завтра аналогичную задачу оценят в 3 (и сделают за меньшее время). Производительность команды в баллах осталась прежней, реальная производительность (задач в час) выросла но метрика этого не показывает.
Или наоборот, сегодняшнюю задачу на 5 баллов оценят в 8, метрика покажет рост производительность «баллов в час», реальная производительность останется той же.

Чтобы этого избегать нужен какой-то устоявшийся механизм оценки сложности задач. Плюс «воронка погрешности» т.к. редко какую задачу можно оценить сразу — обычно всегда имеются недосказанности или, еще хуже, изменения прямо по ходу работы.
Если я правильно понял, то для этого как раз можно использовать «якоря», про которые было сказано в конце статьи.
Якоря хороши, если задачу можно достаточно легко сравнить с «якорем». Но это означает что мы работаем с типовыми задачами, которые легко сравнивать и оценивать.
Однако, как быть если задача не имеет подходящего «якоря»? Скажем проект разработан, теперь команда начинает расширять его функциональность в новую для себя предметную область?

Один мой друг, например, такие "якоря" применяет:


1: Ничего проще не бывает. Например, поменять конфиг
2: Знаем, как делать, мало писать
3: Знаем, как делать, но много писать или сложные тесты
5: Нужно думать, пробовать, писать. И/или будут легаси либо 3парти сюрпризы
8: Нужно разбивать задачу
Вот за эту градацию — спасибо. Немного подкорректирую и возьму на вооружение.
> Первое, что приходит в голову – штуки. Но такая мысль нежизнеспособна – слишком высока вариация между задачами.

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

А чем баллы лучше и натуральнее часов, если одно в другое переводится по формуле 1балл = 15 минут?

Эм…
А как это оптимизирует работу программистов?
т.е. раньше они делали, к примеру, по 15 типовых базовых задач в день, а с введением баллов станут делать больше?
Единственное, на что это повлияет — на возможность как то более гибко распределять оплату труда по факту закрытых задач и понимать человеку, который далёк от разработки этого проекта, кто из разработчиков эффективнее, а кто — менее. Хотя это и так должен иметь возможность сказать тимлид (и это, в общем то и так видно).

Одно отличие, правда, есть — числа фибоначи. т.е. рост сложности задачи не линеен ко времени. В этом есть смысл, но это уже из разряда «как правильно оценить задачу по времени».

Я работал в конторе, где была строгая оценка задачь по «баллам» (но мы их называли часами), выдавали премию за достижение определённых показателей и… нет, не наказывали тех, кто не дотягивал (но пристально присматривались). Подход был, конечно, чертовски суровым, оценки — не всегда точными («8 часов на задачу» обычно значили почти неделю работы), но это работало. Правда, не из за «бальной» системы, а мощного контроля за выполнением и хорошо поставленного процесса.

Другое место — пытались внедрить как раз скрам-покер… но, когда в команде — два с половиной разработчика, которые и так струячат с максимальной скоростью и бесперебойностью и на конкретной ЗП (как, наверное, в больше части мест), то это не имело смысла. Эффективнее они работать бы не стали, оценивать их эффективность в баллах смысла так же небыло — от них нужны были не баллы, а решённые задачи.

Но…
Такова участь всех технологий по управлению процессом. Они нужны не для оптимизации процесса, а для прозрачности, осмысленности и управляемости не изнутри, а снаружи.
Вам, как «бизнес-инженеру», надо было обратить именно на это внимание. Это методики «как перестать плыть по течению процесса, и взять его под контроль». =)

ЗЫ: Вы-таки решили поделиться своими секретными технологиями? По моему скромному мнению — в них есть зерно и их можно эффективно и интересно применять. Но надо как следует описать область применения (для каких команд? какого бизнесса? Какого типа проектов?), сместить акценты с того, что это ДЛЯ РАЗРАБОТЧИКОВ на то, что ЭТО ДЛЯ УПРАВЛЕНИЯ РАЗРАБОТЧИКАМИ и ещё много чего. Тем не менее — спасибо за попытки передать опыт )

ЗЫЫ: А ещё, как вариант, было бы интересно сделать песочницу, которая могла бы предложить попробовать управлять проектом с этими технологиями или без. Игровой вариант)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации