Комментарии 46
Не показывайте эту статью своему боссу. :)
Ещё будете и балы считать. (
А в чем отличие от обычной методики освоенного обьема, в которой все задачи в часах, которые можно легко назвать попугаями, но через 200 рабочих часов, задачу нужно закрыть так как пришел срок сдачи?
После прочтение сложилось ощущение, что автор продавец от бога и может действительно продавать просто время, без результата деятельности! Тогда вы нереально ценный кадр, вас оставить, программистов разогнать и про баллы не вспоминать.
Хотя мне кажется вы просто не умеете абстрагировать от слова часы и понять что они значат не только физическое время, и назвав наконец-то их баллами смогли начать работать.
Непонятно почему заминусована, идея разумная. Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.
Т. Е. По факту все скажут разное значение времени, однако существует тот факт, что расстояние до города одно и то же.
Т. Е. Вместо времени, можно использовать другую величину — расстояние ( баллы) в данном случае.
Единственное замечание, что баллы или поинты логично применять для Фичей, а не для Задач. Задачи сами по себе небольшие должны быть… 8-16 часов, максимум для любого программиста, в идеале 1 задача один день и измерять их в баллах уже смысла нет, а вот фичи очень даже, потом считать скорость спринта и на следующий спринт брать столтко фичи на столько баллов, на сколько было сделано фичей в предыдущем спринте. Таким образом менеджеру после каждого спринта можно уточнять прогноз по финальной дате.
Просто пример, если спросить бегунов за сколько вы добежите до ближайшего города. Тот кто бегал скажет за час, кто понятия не имеет какая там дорога, может сказать 8 часов, кто по карте посмотрел и знает свою скорость бега — за 2 часа, а бабушка бегунья — за 4 часа.фишка в том, что аналогия не очень хорошо работает:
1) никто туда еще не бегал — фича-то еще не сделана.
2) куда именно бежать — не настолько точно известно (менеджер будет говорить «А», а иметь в виду А1, бегуны будут слышать «А», а подумают на А2). Вот когда прибегут — тогда и будет известно, что «добежали».
Такой подход еще возможно будет хоть как то работать в продуктовой разработке, которая хотя бы немного конвеер напоминает и в общем то является типовой.
Но стоит ее применить к r&d так все рассыпется а все специалисты просто разбегуться.
В конце концов, от ученых же не ждут, что они смогут оценить сложность исследований и декомпозировать их на простые понятные задачи.
Да, для rnd не подходит.
А об этом году нибудь пишут красными буквами?
Так вы же разобрались без красных букв.
К тому же, каков процент rnd среди всей разработки? Кроме rnd, полно другой экзотикт — красных букв не хватит перечислить.
Вообще не такой уж маленький, к тому же я видел, что бывает если пытаться сторипойнты использовать в задачах, где нет понятного решения.
В лучшем случае просто каждый раз решение ускользало оставляя еще ворох задач на которые необходимо было тратить время и внимание на оценку.
То есть инструмент просто переставал работать, но его недостатки остались на месте
Мне кажется, договариваясь о сумме, программисты всегда сразу, в уме, переводят ее в часы, недели, или месяцы.
А есть еще часы, которые скрыли в себе все накладные расходы. То есть чтобы в договоре Заказчик видел только часы приведенные к стоимости человекочаса, но платил за все и не беспокоился за это.
Это уже 6 часы или эти 5-е?)
Понятно, что инструмент внутренний. Но начало статьи сбивает с толку.
Программист получает конкретную задачу, которая оценена на 6 часов, например. За месяц объем работы на 120 проектных часов нужно сделать каждому. Если не успевает — надо разбираться почему и помогать, а если помощь без результатов, то увольнять. Если успевает за месяц сделать объем задач не на 120 часов, а на 200, то срочно надо повышать зарплату. И все это с учетом качества — исправления багов по протоколам тестировщиков тоже надо учитывать, у кого сколько.
Заказчику счет выставляется за проект, а не за часы. За часы выставляется счет, когда нет четкой задачи или время решения неизвестно: надо что-то либо исследовать, либо старый код поковырять, либо еще что-то подобное. И даже в этом случае я бы предпочел дать заказчику вилку в деньгах от Х до У, а потом выставить счет по факту в пределах этой вилки.
Если будете выставлять заказчику счет за часы, то он найдет того, кто оценит работу на меньшее количество часов и будет вас носом тыкать, что вы время ему завышаете. А если почасовая ставка покажется заказчику высокой, то будет тыкать вас в ставки индусов или программистов из Сычевки Смоленской области (как пример). Явно Вы с заказчиками мало работали.
Измерять задачи лучше в натуральных единицах – баллах;
А можно ссылку на стандарт, руководящий документ, учебник или учебное пособие, где бы балл вводился как натуральная единица измерения? Мерой какого физического (естественного = природного = натурального) явления такой балл является?
Он ответил: хорошая — это когда слушаешь и ммм… Зае@ись!
Можете придумать более натуральную оценку качества музыки?
Нужен ли вам стандарт, руководящий документ или что-то еще для того, чтобы этой оценкой пользоваться и называть ее натуральной?
А между тем, Горшок мертв, Ваша статья не о музыке, а п. 2 (на мой взгляд, конечно же) не имел бы шизофренического оттенка и был бы более соответствующим и Вашему тексту про управление, и духу Вашего же комментария, если бы советовал «измерять задачи лучше в порядковых величинах и выражать в [абстрагированных] баллах».
Сейчас еще кто-нибудь прибежит, и скажет, что слово «баран» в моей статье не соответствует ГОСТ 28509-90 «Овчины невыделанные. Технические условия».
Поэтому я Вас и спрашивал, увидев в тексте «натуральных единицах – баллах», без тени сарказма (все-то знать невозможно), это что-то новое в науке микроэкономике, как человека, заявляющего об инновациях, а оказывается это квадратноколесные велосипеды автора.
Может быть, если не изобретать очередной новояз там, где и уже имеющийся язык замечательно распространен и справляется, больше людей будут Вас понимать (покупать)?
Про статистику знаю. Про хозяйственную статистику — нет.
Мне всегда казалось, что в бизнесе результат важнее терминологии.
Поэтому точности формулировок и однозначному их пониманию всеми участинками стоит уделять особое внимание.
Думаю, что и в бизнесе должно быть также.
У баллов ведь те те же проблемы, что у часов, только они не ограничены физическими ограничениями как время и допускают свободное их увелечение и уменьшение.
Или наоборот, сегодняшнюю задачу на 5 баллов оценят в 8, метрика покажет рост производительность «баллов в час», реальная производительность останется той же.
Чтобы этого избегать нужен какой-то устоявшийся механизм оценки сложности задач. Плюс «воронка погрешности» т.к. редко какую задачу можно оценить сразу — обычно всегда имеются недосказанности или, еще хуже, изменения прямо по ходу работы.
Однако, как быть если задача не имеет подходящего «якоря»? Скажем проект разработан, теперь команда начинает расширять его функциональность в новую для себя предметную область?
Для исследования этой мысли стоит для начала исследовать вариацию между задачами. Возможно там не такая уж и большая разница.
Теперь все наши задачи измерены в натуральных единицах – баллах.
А чем баллы лучше и натуральнее часов, если одно в другое переводится по формуле 1балл = 15 минут?
А как это оптимизирует работу программистов?
т.е. раньше они делали, к примеру, по 15 типовых базовых задач в день, а с введением баллов станут делать больше?
Единственное, на что это повлияет — на возможность как то более гибко распределять оплату труда по факту закрытых задач и понимать человеку, который далёк от разработки этого проекта, кто из разработчиков эффективнее, а кто — менее. Хотя это и так должен иметь возможность сказать тимлид (и это, в общем то и так видно).
Одно отличие, правда, есть — числа фибоначи. т.е. рост сложности задачи не линеен ко времени. В этом есть смысл, но это уже из разряда «как правильно оценить задачу по времени».
Я работал в конторе, где была строгая оценка задачь по «баллам» (но мы их называли часами), выдавали премию за достижение определённых показателей и… нет, не наказывали тех, кто не дотягивал (но пристально присматривались). Подход был, конечно, чертовски суровым, оценки — не всегда точными («8 часов на задачу» обычно значили почти неделю работы), но это работало. Правда, не из за «бальной» системы, а мощного контроля за выполнением и хорошо поставленного процесса.
Другое место — пытались внедрить как раз скрам-покер… но, когда в команде — два с половиной разработчика, которые и так струячат с максимальной скоростью и бесперебойностью и на конкретной ЗП (как, наверное, в больше части мест), то это не имело смысла. Эффективнее они работать бы не стали, оценивать их эффективность в баллах смысла так же небыло — от них нужны были не баллы, а решённые задачи.
Но…
Такова участь всех технологий по управлению процессом. Они нужны не для оптимизации процесса, а для прозрачности, осмысленности и управляемости не изнутри, а снаружи.
Вам, как «бизнес-инженеру», надо было обратить именно на это внимание. Это методики «как перестать плыть по течению процесса, и взять его под контроль». =)
ЗЫ: Вы-таки решили поделиться своими секретными технологиями? По моему скромному мнению — в них есть зерно и их можно эффективно и интересно применять. Но надо как следует описать область применения (для каких команд? какого бизнесса? Какого типа проектов?), сместить акценты с того, что это ДЛЯ РАЗРАБОТЧИКОВ на то, что ЭТО ДЛЯ УПРАВЛЕНИЯ РАЗРАБОТЧИКАМИ и ещё много чего. Тем не менее — спасибо за попытки передать опыт )
ЗЫЫ: А ещё, как вариант, было бы интересно сделать песочницу, которая могла бы предложить попробовать управлять проектом с этими технологиями или без. Игровой вариант)
Как сжать время?