Мне кажется, между словами «улучшение» и «уточнение» разница небольшая. Во всяком случае, несущественная в данном контексте.

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

Проблема оценки задач в том, что не все задачи учитываются.

Зачастую не все задачи учитываются из-за недостаточной <b>детализации</b> — раз, недостаточного учёта возможности появления <b>"рисковых"</b> задач — два.

Оба эти пункта отмечены в статье.

Конечно, бывают в жизни неучтённые задачи, не попадающие в перечисленные два пункта — рутовые неучтённые задачи. Их рассмотрение выходит за рамки данной статьи.

из статьи я сделал вывод, что вы верите в Соционику

Из статьи не следует, что мы верим в соционику.

Из статьи видно, что мы ею невозбранно воспользовались :)

описанные вами правила эстимации известны человечеству уже 100500 лет

Известны. На то и ссылка на КО. Это же не значит, что не надо о них писать.
Вы можете показать у человечества место, где эти правила выписаны столь же сжато, для тех, кто ещё не успел ознакопиться со 100500-летним опытом человечества в области эстимации?

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

«Некоторые правила временнóй оценки задачи»

Возможно. Однако же внимание статьи всё-таки сосредоточено не на изначальной оценке времени выполнения задачи, а на её <b>улучшении<b>, ибо предполагается, что некая оценка перед началом применения изложенных методов всё же имеется. Посему слово это в заголовке представляется не только уместным, но и одним из определяющих.

Из этих правил где-то следует, что ПП НЕ ТРЕБУЕТ

неких конкретных цифр-естимейтов, полученных от конкретных людей

??

Я не говорю уже про некий Эджайл, зачем-то упомянутый в посте, стартующем тред.

Спасибо за развёрнутый ответ.

нечто что не является его мнением....

Я всего лишь просил различить факт и мнение. У факта подразумевается наличие пруфа (доказательства, свидетельства). У мнения подразумевается обосновывающий комментарий.

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

про то как надо время правильно организовывать

В статье где-то написано о том, как надо организовывать время?

По-моему, речь идёт только об оценке времени, но никак не об организации.

теории ломаются практикой....

В статье нет никакой теории. Только практика.

Нельзя сказать, что применимая в 100% случаев и у 100% людей.

Вы статью прочитали. Там где-то написано, что тут излагается какая-то теория, которую всем нужно сломя голову применять?

Это практические методы. Они на то и методы, чтобы быть применимыми или неприменимыми. И право каждого — применять метод или методику, или не применять. Неужели за время Вашей обширной карьеры никогда не приходилось применять некоторые отдельные методы из известных методик?

Разрешите напомнить заголовок: Некоторые правила улучшения временнóй оценки задачи

Разрешите расшифровать по словам.
Некоторые — т.е. не все. Возможно даже, далеко не все. Только некоторые. Никакого единственно верного исчерпывающего списка.
Правила — не догмы. Их можно принимать, а можно не принимать. Соответственно, их можно применять, а можно не применять. Ваш выбор всегда за вами.
Улучшения — не достижения предела совершенства. Только лишь улучшения оценок, полученных каким-либо иным способом.
Временнóй — речь идёт об оценке продолжительности задачи во времени.
Оценки — не организации. А планирования. Когда дойдёт речь до организации, тут уже нужно применять правила организации по существующим оценкам.

Задачи — имеются в виду задачи, которые могут встать перед вами как человеком, играющим какую-то роль в IT-деятельности. Это может быть маленькая задача, несколько задач, маленький или большой проект. Думаю, кое-что из этого применимо даже и для группы проектов.

Думается мне, содержание статьи хорошо соответствует её заголовку.

На большее, т.е. что-либо, выходящее за пределы указанного в заголовке, статья, очевидно, не претендует.

К тонкости я тут не стремился.
Это мой обычный вопрос на спорное утверждение.
В этом форуме он уже фигурировал.

Научился я этому вопросу в одной книге, но она не по IT.

Однако же, если можно, ответьте, пожалуйста коротко.
И если есть немного времени, кратко обоснуйте.

Если же у Вас найдётся времени чуть больше, то, думаю, читатели форума будут рады развёрнутому обоснованию.

это факт или мнение?

Вот интересно, автор поста статью читал? А то вопросы актуальные задаются проблемы существенные поднимаются, но каким боком они к содержанию статьи относятся, совершенно непонятно. По крайней мере, неочевидно. Явно что-то мы тут не дорабатываем, недопонимаем.....

пруф есть? (теперь без копирайта)

(копирайт ставлю, потому что фразы известные своей эффективностью, но не мои)

таки не требуют.

это факт или мнение? ©

эджайлами пользуемся, в плэннинг покер играем

«Спасибо, Кэп!» © сабжевая статья.

Эджайл и плэннинг покер перед началом и в процессе работы таки требуют неких конкретных цифр-естимейтов, полученных от конкретных людей.

Здесь предлагается методика получения этих цифр от людей, которые, возможно, весьма поверхностно знакомы с этими умными и продвинутыми понятиями. Либо вовсе не знакомы, такое тоже бывает в IT-индустрии. Причём, как выясняется при близком контакте с реальной жизнью, не только среди джуниоров.

неизмеримо больше больше вероятности андертайма

простите, неизмеримо меньше.

опять знак неравенства перепутал :D

бывает что для того что бы «передвинуть», нужно кучу кода перелопатить

Не уверен — не оценивай. Если у тебя супер-кастомный продукт с монолитным дизайном архитектуры, то такое не просто бывает, но более чем вероятно.

Ну а если ты допустим ошибся в оценках, то что девелопер должен бесплатно овертаймить?

Однако же если мой бизнес продаёт установку, веб-дизайн, минимальную подкрутку и минимальную поддержку известной CMS, и моя девочка-договорщик по саппорту уже много раз естимейтила такие запросы на 4 часа, то вероятность овертайма девелопера неизмеримо больше больше вероятности андертайма.

Я писал не о саппорте

А статья старается давать рекомендации, применимые во всех IT-жанрах.

На счет [[миллионных]] бюджетов — да. Стараемся.

А статья старается давать рекомендации, которые люди могут применить на IT-задачах с любым бюджетом, либо даже вовсе без бюджета (такие, как ни странно, тоже бывают).

естимейты и посчитанный бюджет

в статье где-то речь шла о бюджетах?

Если с вас в течении дня требуют естимейты и посчитанный бюджет, то это уже не в одни ворота не лезет.

Ну, это зависит от оцениваемой задачи.

Если задача стоит так — вон в том сайте, который ты два месяца назад мне отдал. переставить этот текст бокс сюда, поменять три картинки на вот эти — то это совершенно без проблем.

Ты говоришь — о, это саппорт, 4.132 часа, стандартная такса $хх.xx за час.

А у Вас, я так понимаю, только миллионнобюджетные проекты?

так хоть бы написать к линке на книжку пару фраз.

например — о, чувак, какой у тебя классный сайт/блог/страничка. а вот сходи сюда, тут тебя голышом сняли и весь инет сюда посмотреть ходит.

а по голым линкам должна быть пре-модерация. а лучше — пре-бан.

толсто вброшенный спам? тонко замаскированная реклама?

Вот для этого и заводят реестр рисков, и заказчик его подписывает.

На самом деле читатели этого обсуждения уже, наверное, с первого камента, поняли, что Вы умный и опытный почти во всех областях, затрагиваемых на ДОУ. Однако же не у всех читателей этого сайта и, в частности, этой статьи, практика отношения с заказчиком именно такая, как у вас. У некоторых не самых маленьких компаний отношение с заказчиком сводятся к единственной цифре — цена, которая будет уплачена за результат, без разбиения на пункты. И уж тем более никаких отдельных строк про управление рисками.

А статья адресована индивидуально людям, IT-специалистам, перед которыми стоит задача оценки времени, своего или команды. И цель её — поделиться начальными шагами с тем, кому это нужно, а не научить всему и сразу, или научить чему-нибудь существенно новому продвинутого специалиста по естимейтам.

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

Эстимировать надо без рисков, а лишь потом добавлять новые задачи

Это факт или мнение? ©

Это вообще то задача менеджера, и того кого назначили ответственным, за какой то риск.

Ах божечки ш ты мой, как всё логично и связно, понятно, прозрачно, компетентно и контролируемо.

Однако же та методика, которая используется у вас в вашем конкретном случае, может быть объективно неподходящей для другого конкретного случая. Расскажите фрилансеру-одиночке про PMBOK, который косит больше, чем средний PM с его BOK-ом. А менеджер далеко не всегда компетентен, чтобы оценить время подчинённого-исполнителя и вынужден обращаться к нему за оценкой времени. Как ему это сделать? Обяжете всех изучить PMBOK? Можно, если есть на это ресурсы.

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

P.S. простите за многабукыф если шо.

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

А методика учёта рисков может быть разной — внесения отдельного пункта по всем рискам, внесение риска по каждой задаче в саму задачу, указание нескольких оценок (пессимистичная, оптимальная, оптимистичная) для каждой терминальной задачи (или всей группы зависимых или не очень зависимых друг от друга задач).

У всех этих методик есть плюсы и минусы. В разных командах и компаниях могут быть разные практики, требования и рекомендации по использованию и применению этих методик.

Это всё дополнительные сложности, а Mid-Level исполнитель далеко не всегда владеет даже одной из этих методик, я не говорю уже о том, чтобы знать их все и различать.

а где написано, что без обоснования?

риски — они и есть обоснование.