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
Утверждать, что разработчики могут научить лучше оценивать. Выносить это как решения с ретроспективы
Полезная статья, спасибо!
Как раз в тему про оценку проекта тоже написала статью: https://vc.ru/659029. Очень много пересекающихся моментов. Оцените, пожалуйста, как эксперт в этой теме)
Самый частовстречаемый мной косяк с оценкой, особенно часто встречающийся в крупных компаниях — оценивают и делают разные люди.
Звучит как опыт из крупных интеграторов)