Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
В колоде покера — карты с цифрами (вот это поворот!), которые обозначают часы: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
В данном случае цифры какраз обозначают относительную оценку, а не абсолютную, да тем более в часах.
Наиболее часто в покере планирования встречается/используется последовательность чисел Фибоначчи.
Про буферы, подстраховку и закон Мёрфи
Клиента нужно приучить к вилкам и к тому, что в них заложена подстраховка. Это не обман, а реальность. Мы можем быть уверенными только в одном: здесь работает закон Мёрфи. Если он бьёт часто, буферы должны быть больше. Проверить частоту Мёрфи можно итеративно.
Если клиент категоричен и не хочет видеть вилки — просто уберите нижнюю границу. Но важно не только закладывать адекватные буферы, но и пристально контролировать их расход.
Если буфер съеден на треть, а работа еще не готова — это повод начать экспедирование и проталкивание. В сфере веб-разработки мы используем burndown chart, чтобы визуализировать расход.
Экспедирование и проталкивание при отлаженных процессах должны занимать не более 5% всей работы. Если меньше — значит, у вас есть запас мощностей. Если больше — у вас проблема.
На сложных проектных цепочках наибольший контроль должен быть на выявлении бутылочного горлышка проекта и контроле его питающих буферов.
Если горлышком являются различные согласования в проекте, то в этом случае контроль буферов может не помочь. С такой ситуацией не сталкивались?
Вы забыли упомянуть про конус неопределенности-на начальных этапах проекта оценка может быть в диапазоне от -50% до +400%
На мой взгляд, его упоминание здесь будет излишним, ввиду того, что имеется такой пункт:
Естественно, это подразумевает хорошую работу менеджера с клиентом, с уточнением как можно большего числа требований. Вероятнее всего, автор своих менеджеров обучил такому искусству, но увы, такое бывает далеко не всегда(
Постановка задачи, анализ и предварительная оценка (оценивается срок получения сроков).
Естественно, это подразумевает хорошую работу менеджера с клиентом, с уточнением как можно большего числа требований. Вероятнее всего, автор своих менеджеров обучил такому искусству, но увы, такое бывает далеко не всегда(
Если проект сложный и не слишком типовой, то все это — гадание на кофейной гуще, извините. Хоть Эйншейна наймите для оценок.
В этом случае делаются прототипы, чтобы отработать основные сложные моменты. Длительность прототипов фиксирована, а результат нет. В каких-то случаях можно отработать всё, что нужно для проекта в проверяемой области, в каких-то понять сколько еще делать, в каких-то отказаться от изначально выбранного подхода, и запланировать новый прототип по другому принципу.
Естественно, нужно сознаваться клиенту, что для вас это сложная и нестандартная задача. При этом будет вполне заметное время (и затраты компании) на оценку. Ваша бизнес-модель должна учитывать подобные расходы (либо сразу с клиента брать, либо уровень маржи и проценты конверсии из оценки в проект перекрывают затраты и возможные отказы от заказа).
Естественно, нужно сознаваться клиенту, что для вас это сложная и нестандартная задача. При этом будет вполне заметное время (и затраты компании) на оценку. Ваша бизнес-модель должна учитывать подобные расходы (либо сразу с клиента брать, либо уровень маржи и проценты конверсии из оценки в проект перекрывают затраты и возможные отказы от заказа).
«Постепенно задача усложняется: для декомпозиции дается проект, в котором есть только прототип. Затем — стандартное техническое задание, потом — плохое и сложное ТЗ.»
В конце гуру определяет сроки по мычанию заказчика с учетом всех хотелок его левой пятки, который появятся в будущем.
В конце гуру определяет сроки по мычанию заказчика с учетом всех хотелок его левой пятки, который появятся в будущем.
> внимательным к мелочам
На то, чтобы обойти все мелочи, нужно потратить много времени.
Поэтому оценка будет тем точнее, чем больше времени на нее потрачено. Но тратить на оценку много времени тоже вряд ли стоит.
Но и в этом случае нельзя знать, с какими подводными камнями столкнемся.
Когда у меня спрашивают, когда будет готово, то часто говорю, что мне проще сделать, чем оценить сроки.
>К сожалению, автору неизвестно, применяется ли где либо еще на практике относительные оценки. Всем подавай точные сроки и деньги :)
Если есть относительные, то в чем проблема вывести абсолютные?
Или вы на вопрос, сколько времени займет создание ИМ, отвечатаете 20 * время создания лендинга? :^)
На то, чтобы обойти все мелочи, нужно потратить много времени.
Поэтому оценка будет тем точнее, чем больше времени на нее потрачено. Но тратить на оценку много времени тоже вряд ли стоит.
Но и в этом случае нельзя знать, с какими подводными камнями столкнемся.
Когда у меня спрашивают, когда будет готово, то часто говорю, что мне проще сделать, чем оценить сроки.
>К сожалению, автору неизвестно, применяется ли где либо еще на практике относительные оценки. Всем подавай точные сроки и деньги :)
Если есть относительные, то в чем проблема вывести абсолютные?
Или вы на вопрос, сколько времени займет создание ИМ, отвечатаете 20 * время создания лендинга? :^)
Срок выполнения любого проекта по Бобуку-Бацеку, формула от 2008 года: https://twitter.com/bobuk/status/636252417089212416
Там еще видео есть.
Там еще видео есть.
А какое распределение (не Пуассона)? Где почитать?
Когда не знаю как оценить сроки использую оценку по методике PERT, вроде нормально выходит.
Оптимистичное время (O) — Минимальное возможное время исполнения задачи, предполагая, что всё идёт лучше, чем обычно ожидается.
Пессимистичное время (P) — Максимально возможное время исполнения задачи, предполагая, что всё идёт неправильно (но исключая крупные катаклизмы).
Нормальное время (M) — Лучшая оценка времени исполнения задачи, предполагая, что всё идёт как ожидалось.
Ожидаемое время TE = (O + 4M + P) ÷ 6
Буферное время (B) — Запас времени, закладываемый в буфер проекта для исполнения данной задачи, обычно B = (P — TE) ÷ 2
Таким образом, задача с вероятностью 50% будет завершена в ожидаемое время. Дополнительно вычисляем буферное время, это такой период времени, что добавив его к ожидаемому периоду, мы получим период с вероятностью исполнения задачи, равной 80-90%.
Оптимистичное время (O) — Минимальное возможное время исполнения задачи, предполагая, что всё идёт лучше, чем обычно ожидается.
Пессимистичное время (P) — Максимально возможное время исполнения задачи, предполагая, что всё идёт неправильно (но исключая крупные катаклизмы).
Нормальное время (M) — Лучшая оценка времени исполнения задачи, предполагая, что всё идёт как ожидалось.
Ожидаемое время TE = (O + 4M + P) ÷ 6
Буферное время (B) — Запас времени, закладываемый в буфер проекта для исполнения данной задачи, обычно B = (P — TE) ÷ 2
Таким образом, задача с вероятностью 50% будет завершена в ожидаемое время. Дополнительно вычисляем буферное время, это такой период времени, что добавив его к ожидаемому периоду, мы получим период с вероятностью исполнения задачи, равной 80-90%.
На мой дилетантский взгляд — эта проблема и ее решение было описано Джоелом Спольски еще в 2000 году, в статье «Планирование малой кровью»
http://russian.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html
http://russian.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html
Цитаты из статьи:
Здесь и сейчас подобные фразы смотрятся забавно. Но все они из вступления.
Само планирование описано достаточно грамотно и подробно.
Та же ошибка что и обрёкшая Ashton-Tate, Lotus, и Apple MacOS стать хламом истории софта.
за исключением высшего руководства, которое одновременно полагает… что НЛО существуют
Я нахожу, что с программным обеспечением, зависимости настолько очевидны, что не стоит труда, формально следить за ними.
Здесь и сейчас подобные фразы смотрятся забавно. Но все они из вступления.
Само планирование описано достаточно грамотно и подробно.
В оригинале статьи добавлена авторская пометка об ее неактуальности и приводится ссылка на более подробную и интересную заметку об измеримом планировании, которая была переведена на хабре — а вот и ссылка.
Актуально и в 2020 и далее :) хорошо бы вписать оценку по UCP и прочим поинтс и будет прям полноценный учебный материал.
Автору больше спасибо! Ты выразил нормальными словами целый пласт знаний и отношений. Теперь достаточно дать линк на статью для передачи контекста.
Респект.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как дать адекватную оценку времени, когда неопределённость бьёт по башке