{"id":14289,"url":"\/distributions\/14289\/click?bit=1&hash=892464fe46102746d8d05914a41d0a54b0756f476a912469a2c12e8168d8a933","title":"\u041e\u0434\u0438\u043d \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u043b \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0430 5%, \u0430 \u0441\u0440\u0435\u0434\u043d\u0438\u0439 \u0447\u0435\u043a \u2014 \u043d\u0430 20%","buttonText":"","imageUuid":""}

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

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

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

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

Смертные грехи

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

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

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

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

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

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

Фред Брукс (1975)

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

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

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

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

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

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

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

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

Загадка:

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

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

Общепринятное определение оценки гласит: 'Оценка - это самое оптимистичное предсказание, которое имеет ненулевую вероятность сбыться'... Принятие этого определения неизбежно приводит к методу, называемому "какая самая ранняя дата, когда вы не можете доказать, что не закончите оценивание".

Том ДеМарко (1982)

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

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

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

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

Все исследователи находят некоторый компромисс между сжатием графика и затратами. Никто не считает, что компромисса нет. Предполагается, что максимально возможное сжатие графика составляет около 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

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

0
3 комментария
Ксения Мороз

Полезная статья, спасибо!
Как раз в тему про оценку проекта тоже написала статью: https://vc.ru/659029. Очень много пересекающихся моментов. Оцените, пожалуйста, как эксперт в этой теме)

Ответить
Развернуть ветку
Владимир Бычко

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

Ответить
Развернуть ветку
Артем Летюшев
Автор

Звучит как опыт из крупных интеграторов)

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда