Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

Автор статьи: Александр Дрёмов.

Подготовка статьи к публикации: Алексей Мудрик.

Содержание


© ralphb58

http

1. Введение

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

Глава XXXIV. Междупланетный шахматный конгресс

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

Все мы рождаемся с разными способностями в работе с теми или иными информационными аспектами окружающего нас мира. Одним из таких информационных аспектов является восприятие времени.

Если не вдаваться в дебри психологии, то можно сказать коротко и просто: люди делятся на сенсориков и интуитов.

Работа с аспектом времени интуитам дается от рождения лучше чем сенсорикам.
Интуитам же (одним из которых являюсь и я сам) часто не бывает необходимости думать о том, как именно они оценивают время: они и так работают со временем без проблем, имея соответствующий тип строения психики.

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

Если же вам захочется сказать мне по окончании чтения этой статьи: «Спасибо, Кэп!», скорее всего это значит не то, что вас сегодня посетил Капитан Очевидность в моем лице, а то, что вы либо сами являетесь сильным интуитом, либо, устав терять энергию на оценку временных затрат, сами уже давно реализовали через логику защиту своей психики от лишних энергозатрат по аспекту интуиции времени.

http

2. Об оценке времени


2.1. Поймите, что именно вам надо сделать в результате

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

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

Далее, если задача не атомарная, создайте ее детализацию.

http

2.1.1. Детализация задачи

Нельзя оценивать задачу без четкого понимания того, на что вам нужно время. Немного о правильной детализации задачи.

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

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

Не увлекайтесь чрезмерным дроблением.

Слишком сильное дробление не несет пользы; скорее наоборот — оно вредно. Чрезмерная детализация забирает время на ее построение и дальнейшее поддержание детализированного плана задачи. Также чрезмерная детализация бессмысленна при недостаточно подробном тех.задании на задачу на момент оценки.
Лично я при оценке чаще всего не опускаюсь ниже 4 часов на задачу. Хотя иногда ставлю 2 часа или 1 час (необходимость в этом возникает тогда, когда явно выделяются атомарные задачи небольшой продолжительности). Но, в целом, ваш минимальный порог будет зависеть от того, какой минимальный уровень сложности задачи вы сможете точно оценить.

http

2.1.2. Определение рисковых подзадач

Определите, является ли задача рисковой. Рисковой она для вас является если включает, например, работу с технологией с который вы слабо знакомы, или ставит вас в зависимость от внешних факторов (возможное неожиданное для вас изменение API внешней системы, которой вы пользуетесь и т.д.). Добавьте коэффициент на риск. На то что «что-то пойдет не по плану» обычно отводится 20%-30% от времени задачи.

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

http

2.1.3. Оценка времени детализированной задачи

Во-первых, помните, оценивая задачу, что вы никогда не тратите все 8 часов рабочего дня непосредственно на работу по задаче. У вас всегда будут затраты времени, на то чтобы заварить/попить кофе/чай, посидеть в туалете, послушать свежий анекдот и т.д. Потом вы садитесь за компьютер и пытаетесь какое-то время вспомнить, что же вы там делали. Вас отрывают коллеги вопросами по работе и прочее, прочее.

Когда же вы оцениваете задачи по запросу менеджера, вы, возможно, выдаете время оценки исключительно на работу над задачей, без учета всех этих непроизводственных затрат времени. Как результат, ваши оценки будут менеджером использованы в суммарной оценке задачи, и получится ,что в вашем рабочем дне все 8 часов непрерывная работа над задачей. Что, конечно же, не так. Хорошо если из этих 8 часов хотя бы 6 часов составят время вашей эффективной работы. В результате, получаем неточную реальную оценку задачи.

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

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

http

2.2. Оцените качество вашей оценки

Ведите для себя статистику качества вашей временной оценки по задачам. Сравните реальное время, потраченное на задачу, с данной вами предварительной оценкой. Определите ваш коэффициент погрешности в оценке времени. Определите его как отношение реального времени (Tp), потраченного на задачу, к времени предварительной оценки (To).

K = Tр / Tо

Чем больше статистика замеров, тем вероятнее то, что вы более точно учтете вашу погрешность.

Запомните этот коэффициент и умножайте в дальнейшем на него вашу предварительную оценку. Это приблизит вас к более точному прогнозу.

http

2.3. Для менеджеров

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

Добавляйте к суммарным временным оценкам комплексных задач 20%-30% на риски. Это может быть риск того, что кто-то из исполнителей заболеет, или у него неожиданно (для вас) родится ребенок, или будет свадебное путешествие в Магадан. Так или иначе, что-то да обязательно сработает, особенно если сроки верхнеуровневых задач более двух недель.

Не забывайте при составлении интегрального календарного плана о блокирующих взаимозависимостях между различными задачами. Календарный срок реализации комплексной задачи не равен сумме оценок всех исполнителей. Кто-то будет ждать окончания работы другого сотрудника, для того чтобы начать свою задачу. Учитывайте это. Иначе будут неожиданные сдвиги даты окончания задачи.

Ведите свои коэффициенты точности оценки времени каждым вашим подчиненным. Корректируйте с помощью этих коэффициентов полученные от подчиненных оценки.

http

2.4. Кратко об инструментарии

Есть множество программ для тайм-менеджмента и временнóго планирования. Лично я пользуюсь для построения календарного плана общеизвестным продуктом MS Project. Мне его возможностей более чем достаточно.

У вас могут быть свои предпочтения.

http

3. Итоги

Резюмируем все вышесказанное. Что чаще всего приводит к ошибкам во временных оценках задачи?

Причины:

• Отсутствие конкретики в поставленной задаче и попытка оценить задачу, сформулированную в стиле «Пойди туда, не знаю куда. Принеси то, не знаю что»

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

• Неучтенные риски, влияющие на те или иные задачи

• Оценка задачи в «чистом» времени без учета непроизводственных временных затрат

• Неучтенность временных затрат на интеграцию различных подзадач друг с другом

• Неучтенность блокирующих взаимозависимостей между задачами различных исполнителей

Методика устранения:

• Требуйте конкретики в постановке оцениваемой задачи. Либо требуйте себе полномочий на определение того, каким образом та или иная неопределенность будет разрешена.

• Детализируйте задачу до тех пор пока вы не получите подзадачи которые уверено сможете оценивать во времени.

• Не увлекайтесь чрезмерной детализацией

• Определите рисковые задачи и увеличьте их оценку по времени, в соответствии с риском (по умолчанию это увеличение времени оценки на 20%-30%)

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

• Учитывайте в вашей временной оценке непроизводственные затраты времени

• Высчитайте ваш коэффициент погрешности оценки и используйте его в дальнейшем для корректировки.

• Учитывайте в оценке блокирующие взаимозависимости между задачами различных исполнителей.

• Ведите коэффициенты погрешности оценки для ваших подчиненных и используйте их для корректировки выдаваемой ими временной оценки.

Это все на сегодня.
Спасибо за внимание.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

To estimate project duration we apply Celsius to Fahrenheit formula. C is internal estimate and F is what we tell PM: C x 9/5+ 32 = F days. ©

85 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Сенсорика, интуиция времени неужели соционика и сюда добралась? Следующий шаг гадание на кофейной гуще.

А я просто процитирую из своих заметок. Писано 12 дня марта месяца 2009 года.

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

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

Опять же, любая работа начинается с планирования. А планировать, как это ни грустно звучит, в программной индустрии умеют считанные единицы. Более того, не могу с уверенностью сказать умею ли планировать программные проекты я сам :-)

Раз человечество выработало механизм постепенного углубления в проблему «от общего к частному», то стоит ли изменять ему при планировании программных проектов?

В КТЦ (Конструкторско-технологический центр МО Украины), где я имел честь служить пять лет, учили создавать перспективный план части (на пять лет), годовой план части, годовой план отдела, план на тему («тема» в КТЦ то же, что «проект») в целом, квартальный план темы, месячный план и вплоть до недельного плана отдела.

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

Так может быть такое планирование не было точным? Оно было точным и по результатам выполнения темы отклонение в часах на 10 % от первоначального плана уже считалось большим. Да, бывали и переносы на другой период, если заказчик не смог вовремя предоставить исходные материалы, бывали увеличения плановых показателей, если по ходу выяснялось, что заказчику требуется больше, чем изначально планировалось. Но на каждые десять тем таких было не больше одной-двух. То есть методы планирования, которые использовали наши отцы и деды, работают! Планировать надо от общего к частному, но не в иную сторону!

Зачем я так подробно остановился на том, как было в КТЦ? Уже не раз сталкивался с идиoтским посылом среди манагеров новой формации, что «пока мы не распишем все задачи (вплоть до каждого моллюска), план на проект выдать не можем».

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

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

А еще, не открою секрет, у заказчика есть свои сроки. Но это не абстракции, как у разработчика. Например, с 1 апреля по закону о резинотехнических изделиях необходимо организовать строгий номерной учёт выданных резинок. Планируй что хочешь и как хочешь, а появиться вечером 31 марта и радостно сообщить, что усё готово, это — провал. То есть за месяц, 1 марта, должно было начаться обучение операторов; ещё за месяц до того программа должна была пройти приёмо-сдаточные испытания; ещё за месяц до того заказчик должен был увидеть стабильную версию программы, кандидат на выпуск; а периодически до того он должен был бы видеть и промежуточные версии, чтобы понимать, как идет проект.

Отлично написано! К последнему абзацу добавлю только, что если проект должен быть сдан к первому апреля, сейчас январь, а аналогичные проекты занимают полгода, то что? Правильно, нужно было начинать в сентябре!
Либо нужно искать временные решения.
И тому есть примеры. Один из самых известных фейлов в индустрии, например. Задержка запуска автоматической системы доставки багажа денверского аэропорта обошлась в 560 миллионов долларов.

calleam.com/...F/?page_id=2086

Если по любым темам отклонение было не более 10%, это значит, что заявленные сроки заведомо растягивались, а потом происходила подгонка под них. Иначе такой устойчивой точности достигнуть невозможно. Вся «мудрость предков» тут не более чем метод прикрыть задницу в условиях жёстко плановой экономики. Снизу и молодому такое увидеть действительно нереально, но опытный сотрудник мог делать вид тотальной плотной занятости на ровном месте только чтобы точно попасть в описанный в планах срок.

Аналогия с предыдущими проектами, конечно, работает, но не столь устойчиво.

Я за год вёл по несколько тем различной сложности. Отдел (около 14 чел.) за год закрывал более 15 тем.

Первая моя тема (отчетность частей по драгметаллам и драг.камням для Управления драгметаллов МО) начата мной в начале августа 1994 и сдана к сроку в декабре.

В этой теме абсолютно все по нынешним понятиям было сплошным риском — ведущий по теме выпускник этого года без опыта работы над такими проектами; изучение новых технологий по ходу проекта (такая была система DataEasy со своим языком запросов DQL, а с СУБД я вообще до того не работал); обучение основам управления и планирования проектами по ходу выполнения темы.

Этот проект после сдачи заказчику проработал минимум 10 лет. Причем, за первый год работы я внес несколько незначительных доработок, а потом 9 лет заказчик про нас вообще не вспоминал...

И заслуга в этом в основном не моя, как ведущего по теме, а старших товарищей, которые этот проект спланировали и вовремя подсказывали какие организационные мероприятия необходимо провести. Причем, начальник отдела, п-к Колоколов, вообще не знал, что такое программирование и что существует «процесс разработки ПО» как отдельное понятие и он чем-то отличается организационно от процесса разработки КД.

По нынешним временам, «по процессу», такой проект делает команда минимум из 6 чел. и минимум год.

А вот сроки если и завышали (бывало, иногда брали с хорошим запасом), то трудоемкость завысить было практически невозможно. При системе, когда заказчик рассчитывается не деньгами, а «нормо-часами» и учет временных показателей идет по системе план/факт/табель завысить «факт» ну очень проблематично.

А вот сроки если и завышали (бывало, иногда брали с хорошим запасом),

ну а я о чём.

то трудоемкость завысить было практически невозможно.

от фактически затраченной? неудивительно.

По нынешним временам, «по процессу», такой проект делает команда минимум из 6 чел. и минимум год.

Ну процесс разный бывает. Мы обычно не фиксируемся на каком-то одном, по крайней мере пока не сделан прототип, по которому можно оценить, туда ли идём.

Пиковый напряг — оно, конечно, бывает. Главное чтобы системой не стало.

А вот сроки если и завышали (бывало, иногда брали с хорошим запасом),

ну а я о чём.

Вы о системе «заявленные сроки заведомо растягивались». А я о том, что такое бывало, но не было системой.

...а потом 9 лет заказчик про нас вообще не вспоминал...

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

Ну, они, фактически, и были заказчиками. Я, уже будучи гражданским, лет через пять после увольнения был случайно рядом, зашел в гости. Собственно с непосредственными пользователями и общался. Единственная проблема, которая была у них на тот момент, это архаичный DOS-овский интерфейс программы.

Видимо «будучи гражданским», в данном случае ключевой момент )

Имел немного счастья иметь отношение к использованию и созданию програмного обеспечения в сфере образования. И если чесно, отсутствие притензий вообще, и наличии об них информации у разработчика в часности — это удивительно, для не коммерческой организации )

Скажем так, заказчик в некотором смысле был «идеальным». Люди знали и понимали предметную область, понимали что и зачем они хотят от статистики и работали еще по стройной гостированной системе отчетности, налаженной еще в советское время. А еще они понимали к каким последствиям приводит внесение изменений в первичные формы отчетности и итоговые отчеты. Поэтому они изначально смогли достаточно четко построить свою работу, а после автоматизации на любые поползновения «а давайте в форму отчетности добавим...» задавали простой вопрос «зачем?» — вразумительных ответов не было и необходимости изменений в ПО не возникало :)

По судебной статистике пример прямо обратный. Там была и продолжается по наши дни перманентная задница — изменения чуть ли не каждый квартал. Причем, вплоть до таких. Добавляется в отчет новая колонка. Мой диалог с ответственной за форму отчета:
— Вы понимаете, что эта колонка та же самая, что через одну слева, но с другим заголовком в шапке?
— Да.
— Зачем?! Мы сделаем, это элементарно, но ЗАЧЕМ???
— Так сказали в Верховном суде!
— Я не верю, что они именно так сказали.
— Да, именно так, попросили добавить именно ее [от себя: попросили устно, на уровне «мысли вслух»].
— Кто именно?
— Руководитель департамента статистики.
— А вы пробовали ей объяснить, что такая колонка есть но с другим названием?
— Как?! Вы что, это же Верховный суд! — многозначительно и перепугано таращит глаза, — Как мы можем им указывать?

— Не указывать, а подсказывать, помогать... Имя, телефон!

В общем, звоню. Руководитель департамента — нормальная адекватная женщина, суть проблемы сразу вкурила, задачу отменила, как не имеющую смысла.

Так что, мой первый проект — уникальный во всех смыслах. Его можно приводить только в качестве примера, что такое возможно в принципе. Ненормальным, но нормой является второй пример, на такое, как правило и следует ориентироваться. К сожалению.

Хорошая статья. Всегда здорово подытоживать даже то, что уже известно, т.к. это позволяет а) освежить и б) еще раз обдумать изложенное и сделать новые выводы в данном направлении. Тем более, тут все хорошо по пунктам расписано. Автору +1.

Коэффициентом погрешности оценки нельзя пользоваться как тут написано, никто не делает постоянно одинаковые проекты и производительность и точность его не постоянна, поэтому этим коэффициентом можно только показать уменьшаете ли вы какими-либо методами погрешность или нет.

Хотелось бы добавить цитату из замечательной книги Программист-прагматик:
«Одной из интересных особенностей оценки является тот факт, что интерпретация ее результата зависит от используемых вами единиц измерения. Если выговорите, что для некоего действия потребуется 130 рабочих дней, то люди будут ожидать наступления этого события в достаточно узком интервале. Но если вы скажете „около шести месяцев“, они будут знать, что этого события следует ожидать через 5–7 месяцев. Обе цифры обозначают одну и ту же продолжительность, но „130 дней“, вероятно, подразумевает большую точность, чем вы полагаете. Мы рекомендуем следующую градацию оценок времени:
Продолжительность == Оценка (порядок)
1-15 дней == дни
3-8 недель == недели
8-30 недель == месяцы
30 и более недель == перед тем, как оценить, стоит хорошенько подумать
Так, если после всей необходимой работы, вы придете к решению, что проект займет 125 рабочих дней (25 недель), он может быть оценен как „примерно за шесть месяцев“.

Те же принципы применимы к оценкам любых количеств: выберите единицы, в которых будет дан ответ, чтобы отразить точность, которую вы намерены передать.»

Таке питання, скільки тре часу на оцінку завдання.
Наприклад, робота з першого погляду оцінена на 4 людино-місяці.

Із них 100 годин на архітектуру рішення, деталізацію завданнь і оцінки окремих етапів та визначення мейлстоунів, це багато чи мало?

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

Но работа разработчика — работа проектная, а проект по определению (см. PMBook, хотя бы) — инновация. И очень трудно составить список всех вспомогательных, но необходимых задач. Что-то да потеряется. А потом всплывет в виде отставания или овертаймов.

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

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

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

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

Эти задачи как правило не выявляются увеличением детализации, потому что:
1) Они ортогональны к задачам
2) Они находятся в области связей между задачами
Кроме того, задачи обычно описывают функциональные требования к системе, в то время как нефункциональные (качество интерфейса, производительность, расширяемость и т.п.) остаются за кадром.

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

Все, виданные мной проекты с проваленными сроками, подвергались тщательному первоначальному планированию методом детализации задач.

И да, в них всегда учитывались +20-30%, а то и больше, на риски.

Проваливались сроки как раз из-за неучтенных, неизвестных заранее задач, которые выявлялись по ходу проекта.

Я таки скажу: «Спасибо, Кэп!», и не потому, что я интуит (из статьи я сделал вывод, что вы верите в Соционику), а потому, что описанные вами правила эстимации известны человечеству уже 100500 лет.

И да, статье бы более подошло такое название: «Некоторые правила временнóй оценки задачи»

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

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

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

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

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

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

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

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

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

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

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

Интуит...интуит... где-то встречалось подобное понятие... а, вспомнил, вот: www.intuit.ru

Я просто умножаю estimate на число Pi — тоже еще никогда не прокалывался ;)

Pi — очень много. С тройки можно начинать с новой командой или новыми технологиями. Ну или новым заказчиком...

Когда ко всему привыкли, то НУЖНО уменьшать сроки. Помните «задача отнимает все отведенное время»?

Ну больше лучше чем меньше. Правда кризис берет свое — на крупных проектах больше чем на 2 умножить не дают ;)

За статью спасибо, но это советы для менеджера. Для разработчика — советы не очень подходят. По пунктам:

2.1 Ни непосредственный менеджер, ни выше по иерархии — никто не может дать достаточно подробное описание задачи. Хорошо когда есть коллеги недавно работавшие непосредственно с кодом, который надо будте менять — можно проконсультироваться у них. В противном случае — читать код, анализировать качество кода, дизайна, архитектуры. Попутно можно составлять WBS и делать прототипы для уточнения оценки. Но основной навык — это чтение кода.

2.1.1 Гранулярность задач — завист от проекта. На некоторых необходима точность до часа, на других вполне приемлимы оценки вида «меньше одного дня» для простой задачи, «4-5 дней» для сложной атомарной задачи.

2.1.2 Риски для разработчика — это плохая архитектура, плохой дизайн и унаследованный код с историческими напластованиями. При проблемной архитектуре — или увеличивать период анализа и создавать полный прототип — или закладывать в риски несколько сотен процентов. Плохой дизайн кода — частичное прототипирование или до 100% на риски. Просто плохой код — 20%-40% на риски.

Фаза анализа и дизайна — есть всегда, только при работе с знакомым кодом она может занять совсем немного времени, а незнакомый код, да еще проблемный — и эта фаза может занять до 60%-70% процентов времени проекта.

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

2.2 Не уверен, что для разработчика этот коэффициент будет иметь смысл, особенно на краткосрочных задачах. Он не учитывает влияния окружающей среды на эффективность

работы.

2.3 Я бы добавил — помните, что у менеджера и разработчика — разные понятия о

рисках.

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

ЗЫ. Все вышесказанное — исключительно мое мнение.

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

И в случае сферического коня в вакууме (есть конкретно взятый кастомер, который дествительно знает что ему нужно, и это что не меняется в зависимости от сочетания звед на юном полушарии) — данная статья актуальна. Несмотря на некоторую склонность к капитанству.

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

Явно что-то мы тут не дорабатываем, недопонимаем.....

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

Мысль понял, перехожу но понятный стиль изложения.
Читал.
Одобряю.
Практического применения, в условиях в которых работает топ 4 компаний, по данным ДОУ, не имеет.

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

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

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

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

Если честно, воображение рисует страшные картины, как народ под пытками пишет в постах нечто что не является его мнением....
А в этой книге разве не было написано, что любой, даже самый неоспоримый факт, является таковым только субъективно, в глазах его носителя? Так что вопрос только в степени доверия к источнику этого самого факта....

Например я для Вас (и для большинства из 24000 специалистов тут присутствующих) являюсь источником вообще не определенным.

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

И все предыдущие 15 лет моей работы в разных местах, я слушал про то как надо время правильно организовывать, и смотрел как эти теории ломаются практикой....

На всякий случай замечу, я не только этим занимался, но остальное в данном контексте не существенно )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

таки не требуют.
\\Ваш К. О.

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

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

Факт.

З. Ы. Ставить копирайт в конце каждой фразы вовсе необязательно.

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

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

Конечно есть — собственно, правила ПП:

en.wikipedia.org/...poker#Procedure

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

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

??

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

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

Нет, это вообще-то обязательная к прочтению книжка по оценке :)

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

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

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

Самый главный секрет оценок — это то, что оценка — это не одно число. В идеале — это распределение вероятностей прогнозируемой продолжительности работы. Ну а практически это два числа: оптимистичная и пессимистичная оценка. Нет возможности оценить вообще — говоришь от 1 дня до 1 месяца. Если такая оценка не устраивает, можно дальше детализировать, разбивать.

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

Пользуюсь liquidplanner’ом именно потому, что он умеет правильно складывать такие оценки. А MS Project — уже непомню когда последний раз смотрел — не умел на тот момент.

Одно число — это promise date. Но это уже не вопрос оценок, а вопрос переговоров.

Або Ви погано дивились, або Вас надурили.
В MS Project завжди була можливість використовувати optimistic/expected/pessimistic оцінки і встановлювати різні вагові коефіцієнти для таких оцінок при розрахунку очікуваної працемісткості/тривалості роботи. Хоча в деяких конкуруючих продуктах цю функцію реалізовано краще.
Втім, це не має великого значення з огляду на те, що замовник хоче знати не інтервал, а конкретне число. Єдине, що ми можемо йому дати, крім цього числа — ймовірність того, що ми в нього впишемось.

В MS Project завжди була можливість використовувати optimistic/expected/pessimistic оцінки і встановлювати різні вагові коефіцієнти для таких оцінок при розрахунку очікуваної працемісткості/тривалості роботи.

Я не спорю. Рад, что вам подходит и все довольны. А насчет даты и вероятности — так в том и дело, что дата (и вероятность вписывания) имеет только косвенное отношение к оценке. Оценка должна быть основана только на реальном прогнозе (никакой привязки к 1 сентября, к рождественскому сейлу, к очередной конференции, к обещаниям инвесторам, данным на каком-то митинге непонятно почему и пр.) А вот обещаная дата должна учитывать как оценку, так и environment.

Я щось казав про прив’язку оцінки до дати? Під «числом» я мав на увазі «число» (eng. «number»), а не дату. В даному випадку — працемісткість, бо в чомусь іншому оцінювати проекти недоречно. Оцінка і є прогноз, а основною характеристикою прогнозу є його вірогідність. Звідси і з’являється друге число (не дата), яке ми можемо дати замовнику — ймовірність.
Тобто, в ідеалі наша оцінка для замовника має виглядати приблизно так: «Цей проект потребує Х людино-днів/місяців з імовірністю У»

Мы говорим об одном и том же, вопрос лишь в том, как распределение величины трудоемкости проекта выразить одним/двумя числами. Одним слишком мало, а двумя можно вполне, если я скажу 8 мес +/- 1 мес, или скажу от 7 до 9 мес. — какая разница?

При этом, игнорируется тот факт, что распределения-то мы не знаем. Предполагаем нормальное, но какой перцентиль используется в оценках «от» и «до» — тоже непонятно. Liquidplanner предполагает 20 и 80. Хотя кто-то может захотеть 5 и 95. Прогноз есть прогноз.

«В идеале» мы дадим заказчику функцию распределения вероятности даты окончания проекта, только мне не попадался такой заказчик, который захочет такое читать :)

В таком случае лучше говорить «Мы сделаем за 9 месяцев, но есть вероятность что сделаем раньше и если сделаем раньше, то дадим Вам знать». 100% работает с любым заказчиком.

Я намагаюсь уникати інтервалів як виду «7-9», так і виду «8±1».
А розподіл величини (вважатимемо його нормальним апріорі) залежить в першу чергу від дисперсії. Відповідно, за низької дисперсій ймовірність попадання в оцінку вища і навпаки (якщо, звісно, оцінка адекватна і ми оперуємо медіаною).
Перцентиль же визначає, яку частину нашого розподілу ми вважатимемо значущою (цільовою).

Вообще то есть нормальная практика управление рисками — создание реестра рисков итд. Прибавление же 20-30% времени на задачи без обоснования — gold plating, и за это бьют по голове.

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

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

Имелось ввиду, что проценты добавляются не с самого начала, когда происходит оценка длительности и стоимости, а тогда когда сработал триггер риска. То есть когда стало ясно, что API поменялся или когда програмер сказал что ему надо срочно к тёще в Магадан. :)

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

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

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

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

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

Вот для этого и заводят реестр рисков, и заказчик его подписывает. Потому что если внесён например риск «Внесение новых требований на каком-то этапе проекта», то это означает что заказчик, как подписант заранее согласен на дополнительные затраты если будет вносить изменения, когда уже все практически спроектировано и изменения потянут за собой рефакторинг и переделку архитектуры. И тут он задумается что ему важнее — деньги или новая фича.

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

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

IMHO, лучше чем в PMBOK еще не придумали. ;)

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

Поэтому, на все возможные риски приходится закладывать буфер сразу при планировании.

Ну это вообще закон бизнеса — купить дешевле и продать подороже. Естественно изначально заказчик делает как выгодно только ему. Поэтому что бы не работать бесплатно нужно тоже иметь зубы. Насчет фиксед прайс — есть треугольник -"цена, качество, обьем", и если зафиксировали все три грани, то естественно, имея в реестре список рисков, плана реагирования на них, можно просчитать стоимость этих мероприятий и добавить к стоимости проекта. Тогда, в самом тяжёлом случае — когда сроки не подвинешь, можно с помощью этих средств нанять ещё ресурсов.

Реестр рисков, просто позволяет обосновано заложить дополнительные сроки и средства. А если управлял рисками как нужно и устранял их вовремя или хвала аллаху не настали, эта сумма может пойти на бонусы тебе и твоим людям. ;)

Треугольник обычно звучит «цена, сроки, объем». Качество иногда добавляют 4й вершиной.

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

Сложность в том, что все риски вы никогда не предусмотрите. Поэтому в fixed price проектах особенно важно закладывать время на компенсацию рисков в оценку, сроки и бюджет проекта. Кто этого не делает — обычно пополняет статистику полностью или частично зафейленных проектов.

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

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

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

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

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

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

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

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

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

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

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

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

Конечно, необходимо всегда советоваться с командой по эстимейтам.
P.S. Все члены команды на проекте — это единый организм, который должен действовать очень слаженно. За такую самостоятельность, если она есть, нужно наказывать.

P.P.S. Сейчас подтянется народ с ветки об agile и продолжат здесь срач расскажут о planning pocker.

planning pocker.

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

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

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

Да и вообще — единоличное установление естимейтов — смертный грех проектного менеджмента.

Кстати, те, кто прочел PMBOK, знают что в ней по оценке материалов маловато. В основном «вода».

Дык материалы у всех разные — у одних люди, а у других кирпичи, под каждый случай PMBOKов тогда не напасёшся. :)

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

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

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

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

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

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

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

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

Ну а если ты допустим ошибся в оценках, то что девелопер должен бесплатно овертаймить? Время и деньги так же неразделимы как и пространство-время :)
Я писал не о саппорте, хотя бывает что для того что бы «передвинуть», нужно кучу кода перелопатить. Потому что делалось быстро с голоса заказчика и риски на «technical debt» никто не предусматривал.

На счет бюджетов — да. Стараемся. Но только отчитываться надо за каждую копейку. Просто так денежки не дают.

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

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

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

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

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

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

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

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

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

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

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

Дякую, було цікаво.
В мене питання до тих хто може працює в продуктових компаніях: чи там задачі також в часі оцінюється? (В аутсорсингу то само собою.)

Просто у мене на проекті ми ставимо складність задачі і все, баги взагалі не оцінюємо — оскільки це не профіт для проекту. Так прогрес команди оцінюється по кількості зробленої роботи, а не потраченого часу.

В продактовых компаниях оценка времени очень важна. Это дает заранее понять какие фичи пойдут на живой в конце релиза и запланировать маркетинговую активность.

• Добавляйте к суммарным временным оценкам комплексных задач 20%-30% на риски. Это может быть риск того, что кто-то из исполнителей заболеет, или у него неожиданно (для вас) родится ребенок, или будет свадебное путешествие в Магадан. Так или иначе, что-то да обязательно сработает, особенно если сроки верхнеуровневых задач более двух недель.

Ставлю всегда 30-40% к задачам, еще ни разу не прокалывался. Если остается время, мы всегда найдем куда его потратить на проекте.

Вообще правильно эстимейтить используя PERT Formula (описание — www.pmhub.net/...-pert-formula/, пару раз пробовал, проколося на одной из задач с эстимейтом, так что тоже не всегда такой вариант «выстреливает».

Ставлю всегда 30-40% к задачам, еще ни разу не прокалывался. Если остается время, мы всегда найдем куда его потратить на проекте.

Как же проколоться-то в такой ситуации. И 200% тоже вполне найдется куда потратить.

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

А хороший менеджер от плохого как раз тем и отличается, что ведет риск лог, которым может удачно оперировать при планировании.
30-40% — это то, что я получил за 6 лет опыта работы в должности ПМ, могу сказать, что эти цифры близки к идеальным.

На fixed price проектах тоже закладывали плюс 30-40% к цене. Было оправдано. Но важно отделять оценку от договоренностей.

Спасибо. Всё по отдельности было понято «потом и кровью», но в купе, лаконично... спасибо ещё раз.

соционика для программистов)

To estimate project duration we apply Celsius to Fahrenheit formula. C is internal estimate and F is what we tell PM: C x 9/5+ 32 = F days. ©

Это пять. Беру на вооружение,

Підписатись на коментарі