Измерение трудоемкости атомарной задачи

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

aiciaay-ooa-ioaiee-odhoaiaieinoe.png
Как ее разбить?

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

  • 1-й период - 37 страниц
  • 2-й - 46
  • 3-й - 42
  • 4-й - 30
  • 5-й - 51

Это означает, что:

  • В среднем одна страница меньше двух дней. Причем существенно меньше.
  • На больших объемах происходит усреднение, и это позволяет управлять версткой на основании статистических данных. Мы можем с очень высокой точностью сказать, когда будут сверстаны все 800 страниц. Примерно за 80 недель. Процесс разработки переведен в статистически управляемое состояние.

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

Несколько тонких моментов.

  1. Трудоемкость надо считать как N задач в M дней (800 задач в 400 дней), а не одна задача в среднем 2 часа. Ваш сотрудник ходит на совещания, читает почту, вынужден писать вам отчеты и т.д. Но это совершенно не важно. Заказчика волнует «Когда закончится проект?».
  2. Список сделанных атомарных задач является отличным отчетом. Другой отчет для контроля за работой сотрудника не нужен. Бонус: «Хотите поднять производительность сотрудника на 5-10%? Отмените таймшиты. Используйте реестр задач как отчет.»
  3. Обязательно возникнет вопрос: «Да, но есть страницы, которые верстались по неделе и более. Их надо разбить!». Нет, не надо. Пока отклонение в трехсигмовом пределе, не надо насиловать процесс. Будет только хуже. Смотри главы 4, 5, 6 книги «Пространство доктора Деминга».
  4. Пожалуй, самое главное. Вычисление уровня и создание реестра атомарных задач обязательно – обязательно! – должны предшествовать попыткам управлять задачами по «приоритетам», «дедлайнам» и т.д. Практически все пытаются сделать наоборот, что приводит к дичайшему хаосу в управлении. Вернее, к отсутствию управления.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.