10 смертных грехов оценок задач в IT

Искусство и наука об оценки в IT:

• Наука оценки хорошо развита и хорошо поддерживается программными инструментами
• Искусство оценки преимущественно основано на эмпирических правилах и их еще нужно немного доработать

Эта статья основана на материалах Steve McConnell из Construx и часть материалов как были остались картинками

Грех №1 Путать цели с оценками

Проводите различия:

• Установка целей — ключевая часть искусства оценивания
• Когда вас попросят дать оценку, определите, действительно ли вы должны оценивать или лучше выяснить, как достичь цели
• Лучше всего рассматривать это как итеративный процесс который выравнивание цели и оценки

Грех №2 Говорить «да», когда вы действительно имеете в виду «нет»

Почему разработчики говорят «да»

Особенности коммуникаций в компании:

• Разработчики программного обеспечения, как правило, интроверты и относительно молоды
• Специалисты по маркетингу и продажам, как правило, более экстравертны и организационно выше разработчиков, с которыми они договариваются
• Очень легко скатиться в продавливание

Грех №3 Приверженность к ранним оценкам в конусе неопределенности

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

Самые точные оценки - поздние

Грех №4 Предположение, что недооценка не влияет на результаты проекта

Ошибки планирования влияют нелинейно на проект. С течением времени накапливаются ошибки и дефекты, а также начинают все чаще выстреливать риски

Грех №5 Оценка в «Невозможной зоне»

Загадка:

• Предположим, вы едете вверх по холму 1 милю со скоростью 30 миль в час.
• Как быстро вам нужно ехать вниз по холму, чтобы в среднем за всю поездку средняя скорость составляла 60 миль в час?"

Вариация на тему греха #5

Оценки - это вероятностные утверждения

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

Сжатие расписания и "Невозможная зона"

Компромисс между затратами и графиком

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

Тут вспоминается старый пост: https://t.me/junior_pm/17

Не создавайте оценки в "невозможной зоне"

• Какое решение загадки?

Грех №6 Переоценка полезности от новых инструментов

Полезный эффект от новых инструментов или методов есть Есть и проблемы:

• Необходимо заплатить цену за обучение при первом использовании
• Максимальная эффективность не достигается при первом использовании
• Первое использование часто сопряжено с ошибками
• Ранние заявления об эффективности часто основаны на экспертном использовании - иногда разработчиками или авторами, изобретшими инструмент или метод!
• Результат меньше ожидаемого, когда он появляется
• Новые инструменты и методы увеличивают риски

Лучшее предположение - потери производительности от начального использования нового инструмента или метода.

Грех №7 Использование только одного метода оценки

Используйте несколько методов:

• Сложно быть уверенным в оценках, созданных только одним методом, - это способствует проблеме «энергичной защиты» Брукса.
• Ведущие организации используют несколько техник оценки
• Создавайте оценки разными способами и ищите сходимость или разброс между оценками.

Грех №8 Не использование программного обеспечения для оценки

Используйте программное обеспечение для оценки:

• Лучшая поддержка для науки оценки - это инструменты
• Оценки, созданные с помощью инструментов, могут иметь большую достоверность, чем оценки, созданные вручную
• Хорошие инструменты для работы с оценками: https://github.com/FocusedObjective/FocusedObjective.Resources

Грех №9 Не включение в оценку влияния рисков

Учет рисков при оценке:

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

Грех №10 Предоставление импровизированных оценок

Обращайтесь к оценке как к мини-проекту:

• Использование догадок и интуиции при создании оценок коррелируется с превышением бюджета и сроков (на уровне значимости 0,05)
• Использование простых арифметических формул отрицательно коррелирует с превышением бюджета и сроков (на уровне значимости 0,01)

Определите стандартизированную процедуру оценки

Элементы стандартизированной процедуры:

• Четкое описание неопределенности оценки
• Использование нескольких подходов к оценке
• План повторной оценки на заранее определенных этапах проекта
• Определение момента, когда «оценки» становятся «обязательствами»

Разбивайте большие оценки на меньшие оценки

Разделяйте системы на модули Разделяйте большие задачи на маленькие задачи Используйте статистическое свойство, называемое "законом больших чисел" - высокие и низкие значения склонны уравновешиваться друг друга.

• Плохие оценки (или цели) - это норма
• Возможны хорошие оценки!
• Представленные здесь смертные грехи и эмпирические правила - это только верхушка айсберга

Грехи №20– №11

Грех №20

Давать оценку “этого”, чтобы составить план прежде чем кто-либо узнает, что "это"

Грех №19

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

Грех №18

Думать что все оценки конвертируются друг в друга. Переводить деньги в календарные сроки и сторипойнты в дни

Грех №17

Строить планы на новый проект опираясь на первоначальный план прошлого проекта. Игнорируйте фактические сроки и прошлый опыт

Грех №16

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

Грех №15

Давайте оценку, игнорируя рабочие моменты:

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

Грех №14

Представлять оценки с высокой степенью точности («67,5 часа»), которые поддерживаются только низкой степенью точности («±2 месяца")

Грех №13

Считать, что инструменты оценки (такие как Монте-Карло) не могут сравниться с вычислительной мощностью из системы менеджера, ручки и салфетки

Грех №12

Рассуждать так: «Чем раньше мы профакапим сроки, тем больше времени у нас будет на их опережение"

Грех №11

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

#проектное_управление

#оценка_проектов

#projectmanagement