Comments 24
пошел к заказчикам
Оказывается большинство думало, что наши оценки это даты когда будет готовы задачи
Поздравляю с открытием.
Вы написали целую статью, с графиками, расчетами, объяснениями, и пр, и все еще не можете ответить заказчику на этот вопрос.
Расчеты и инструменты не дают вам предсказательной силы (т.е. знания), вы все еще тычете пальцем в небо, но с умным видом.
Ваша деятельность в этом направлении абсолютно бессмысленна как прогноз. Польза только в том, что вы всей этой шелухой заказчика успокаиваете.
Хорошего дня!
Приведенная вами цитата иллюстрирует лишь ошибку в коммуникации, но на базе неверного ее толкования вы построили вывод с большим количеством оценочных суждений. Я не хочу его оценивать как либо, лишь выражу недоумение
Вы ведь не разработчик ПО, ведь правда? Вам не приходится периодически удивляться, почему хорошо знакомая работа вдруг заняла непривычно много времени. Вам не приходилось ни разу оценивать, к какой дате вы сможете выполнить работу, которую до этого вы ни разу не делали. А если вдруг и приходилось, ты вы не несли никакой ответственности за свои оценки. Вы пришли под толковую статью, в которой автор делится своими собственными (!) наблюдениями и выводами по использованию различных методик, вот с этим своим высером и последующим пожеланием хорошего дня. Про вас уже давно анекдот сочинили:
Женщина сидит, беседует с подругой. Вбегает дочка вся в слезах:
- Мама, мама - меня мальчишки во дворе жопой называют! - и выбегает.
Женщина тоже в слезы и жалуется:
- Вот так всегда - забежит, пропердит что-то - и убегает.
Хорошего дня!
Вы ведь не разработчик ПО, ведь правда?
неправда, я web разработчик
Вам не приходится периодически удивляться, почему хорошо знакомая работа вдруг заняла непривычно много времени.
неправда, приходится, и часто. оценка скрам мастера никак на это не влияет
Вам не приходилось ни разу оценивать, к какой дате вы сможете выполнить работу, которую до этого вы ни разу не делали.
приходилось, и каждый раз я убеждаюсь что это тык пальцем в небо. независимо от методики: считать в попугаях, сторипоинтах (чтобы в итоге перевести их в часы для заказчика и руководства, пообещать, а потом давить на разработчиков, хех), на статистике, или на картах таро, или на честном слове, или на "тыщу раз так делал".
все перечисленные проблемы упираются в наличие в задаче "неизвестных неизвестных".
есть задача. есть идея. есть план реализации. и есть/возникают в процессе "неизвестные неизвестные".
они не обсчитываются. дробление задачи до "известных известных", хоть и возможно в теории, но на практике я не видел чтобы где-то это работало (то есть давало практически применимую гарантию: задача будет выполнена к N).
пытаются почти везде, реально работает (так, чтобы можно было дать гарантию выполнения к сроку) - нигде.
я критикую подход, а не автора.
"Задача будет выполнена к N, мы знаем будущее! У нас и методика, и циферки, и скрам мастер есть"
А на практике:
"Вы дадите денег, мы возьмемся за задачу, а там разберемся... Может повезёт и уложимся, тогда все будет прекрасно. Не повезет - будем стараться смягчать и договариваться, где-то мямлить и краснеть, где-то убалтывать, где-то врать"
вместо того, чтобы искать удобные для обеих сторон (заказчик и исполнитель) способы отказа от дачи невыполнимых обязательств, люди пытаются искать способы посчитать чего-нибудь, чтобы чего-нибудь наобещать, а потом как-нибудь разруливать.
"высер", "жопой", "пропердит", и прочие атрибуты фиксации на заднице оставьте себе, а здесь ведите себя прилично.
Все эти "Поздравляю с открытием", "Вы написали целую статью ... и все еще не можете ответить", "вы все еще тычете пальцем в небо, но с умным видом", "Ваша деятельность в этом направлении абсолютно бессмысленна как прогноз" - это конечно же "я критикую подход, а не автора". По мне, так это чистый высер. Нечто толковое, похожее на (наивную) критику подхода, вам удалось изобразить лишь в своём ответе на мой коммент.
Поробуйте провести переговоры с заказчиком (человеком, который платит деньги за разработку вашего веб-приложения) без указания сроков и объёмов работ - что-нибудь, когда-нибудь, как-нибудь сделаем, сколько денег заплатите не знаем. Много у вас таких заказов было? Все девелоперы мечтают о таких, но лично мне такие заказы не встречались. Всегда что-нибудь подсчитывается, что-нибудь обещается и как-нибудь разруливается.
Яриться на воду, что она мокрая - глупо. Так же, как и гнать на автора за то, что он делится своим опытом взамодействия с мокрой водой. Другой не бывает.
А высер высером и остаётся, даже если его обернуть в вежливую форму и добавить в конце "Хорошего дня!"
Хороший сборник антипаттернов в управлении. Кажется, собраны все возможные ошибки при работе с оценками.
Какие например?
1) Оценка (любая) как скаляр (а не вектор или, лучше распределение вероятностей). Все методы, предполагающие аддитивность подобных оценок (или возможность их сравнивать) можно сразу отправлять в топку.
2) Покер-планирование.
3) Отсутствие учета рисков при планировании (хотя это единственно полезное вообще в оценках и в планировании)
4) Применение методов статистики на недостаточной базе (с понятными результатами). Тут и про прогноз и про контроль управляемости - все эти подходы на небольшой базе бесполезны.
1) Кажется тут идет путаница оценок и прогнозов. Также замечу что на деле абсолютно любое измерение является некой совокупностью возможных величин, но иногда проще упрощать до скаляра. Я также не до конца понимаю смысл крестового похода против менеджмента в стиле "вы складываете оценки, значит вы идиоты". Да, ты безусловно прав, что если подрубать научный подход это в корне неверно, но как костыль для прикладного использования подходит хорошо
2) Покер планирование - самая обычная техника для управления групповым обсуждением и основа на Дельфи, который вполне себе научный экспертный метод. Не понимаю негатива на его счет
3) Где было сказано что риски нужно не учитывать? То что на этом не было подробной остановки не значит что этого не нужно, но это упомянуто в том в топике про теорию ограничения систем и буферы
4) Это обзорная статья которая лишь показывает что "оценивание" (пусть будет так название) несколько шире просто уточнения оценки у разработчиков и умножения на число ПИ, чтобы направить мысли читателя на более глубокое изучение этой темы
Меня в целом искренне возмущает что большая часть комментариев сводится к позиции разработчиков "очередной менеджер-глупец верящий в оценки написал бред". При этом я читаю комментарии и ощущение что статью либо не читали, либо читали по диагонали
1) Нет, и оценки и прогнозы - не являются скаляром. Оценки вообще без указания вероятности (даже по одному ресурсу) не имеют значения, так как не понятно, это оценки вообще чего. Про это много у тех же ДиМарко/Листера написано в "Вальсируя с медведями".
2) То, что она обычная - не делает ее хоть сколько-то полезной и практичной. И нет, Дельфи - не научный метод. Хотя и используется в экспертной среде. И нет, он никак не связан с планинг-покером (так как вообще предполагает строго противоположные подходы).
3) А где указано? При том, что и майки и даже SP - это именно про оценку рисков (а не чего-то еще). Но, почему-то, про это не сказали
4) Для обзорной статьи в ней очень плохо со структурой, нет никаких обоснований, очень мало хоть сколько-то полезного контента, нет ни одной работающей методики. Это примерно как обозревать разные школы астрологии в статье про найм.
Вообще мне несколько удивительно получать критику в такой форме на статью, которая по сути сводится к сублимации большого количества информации, в том числе научной. Ладно бы я рассказывал какой-то особенный свой взгляд или приводил авторскую методику оценки
А где там научная информация-то?
Моя статья, как и доклад по сути выжимка из материалов который я изучил. Я приложил в статье ссылку на гугл док с книгами и статьями, это не научная работа, поэтому я не вкладывался настолько чтобы приводить цитаты и сноски. Да и сомнительно что кто-то бы стал читать такой объем
Но в списке литературы нет ни одной научной работы. Есть какие-то разнообразные спекуляции на тему оценок, некоторые могут быть интересными. Но научного - нет ничего.
В https://docs.google.com/spreadsheets/d/1wKKVJyFomRsPeQes-zh9bh6V3dpuznSaCbAHqBAbtcM/edit#gid=1696329397 есть 2 раздела. Книги и статьи, существенная часть которых научная и рецензируется
Скорее всего это связано с тем, что все эти методики очень популярны, известны, но почти никто не умеет их успешно применять. Не достаточно подойти к программисту и спросить - сколько сторипоинтов? 8? Хорошо. И на этом закончить. Но в большинстве случаев все именно так и происходит.
По мне, так самая основная проблема оценки как раз отсутствие методики и требований к ней, чтобы задачу хотя бы пару часов поковыряли, посмотрели проект, что помнят, что не помнят, где коду 5 лет и т.п.
Конечно, заказчикам может не понравиться, если вместо обычного спринта скажут, что теперь эта задача занимает три, но за-то это будут реальные три, а не один с опозданием на два
В разработке софта есть две проблемы со сроками и затраченным на работу временем.
- Точная оценка возможна только после того, как работа полностью сделана.
- Какие-то цифры всё таки нужны, иначе бизнес не будет готов вкладываться в разработку.
Отсюда и пляшем — разработчики (в широком смысле, их менеджеры в том числе) пытаются ткнуть пальцем в потолок с приемлемой степенью достоверности, а бизнес делает вид, что их это устраивает (хотя на деле — не устраивает). И успешность проекта/продукта во многом зависит от софт-скиллов обеих сторон и умении идти на компромиссы.
Поэтому важно хотя бы выровняться о том на кой вам оценки и что за оценки. Ожидать от них управления будущим не стоит)
Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование.
Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.
Путеводитель по оценкам задач и котики