Методы оценки трудозатрат проекта

18
0
проект

Руководство для неутомимых оптимистов и сдержанных скептиков. Вы в IT?

Поздравляю, вы в игре, где деньги превращаются в строки кода, а строки кода — в бессонные ночи. Неважно, на каком этапе вы находитесь: стартапер с блестящими глазами или ветеран, седеющий при упоминании слов “дедлайн” и “миграция”. Но есть момент, который всех нас объединяет — оценка IT-проекта. Ведь где-то между утопической мечтой и суровой реальностью лежит тот самый бюджет, о котором будут говорить поколения.

Метод №1: Оценка методом “Пальцем в небо”

Это базовый метод, подходящий для тех, кто верит в волшебство и магию. Суть метода в том, чтобы объявить цифру, которая первой пришла вам в голову. Иногда это “100 часов”, иногда “миллион долларов”, а иногда — это просто истерический смех.

Преимущества:

  • Быстро.
  • Не требует подготовки.
  • Звучит убедительно, если использовать уверенный тон.

Недостатки:

  • Точность колеблется между “абсолютно неверно” и “мы тут все обречены”.
  • Может привести к нежелательным последствиям в виде неожиданных сверхурочных.

Совет: Если после такой оценки вас кто-то спросит “Почему?”, смело отвечайте: “Интуиция не подводит”. Главное — сохранять уверенность в себе.

Метод №2: “Берем чужие наработки”

Вы когда-нибудь задумывались, как оценивали проекты ваши коллеги-конкуренты? Вот и не стоит изобретать велосипед! Используйте готовые данные. “У них на CRM ушло 200 часов? Значит, у нас точно будет 150!” — логика простая и понятная. А если что, всегда можно сослаться на “рыночные стандарты”.

Преимущества:

  • Можно сделать вид, что вы глубоко проанализировали рынок.
  • Отличный способ замаскировать свою лень под стратегический анализ.

Недостатки:

  • Чужие оценки могут быть такими же неадекватными, как и ваши.
  • Если у конкурентов тоже все пошло не так, это не всегда повод следовать их примеру.

Совет: Всегда добавляйте 15% на “всякий случай”. В любом случае это выглядит профессионально.

Метод №3: Agile оценка (aka “Немного каждый день”)

Этот метод как марафонская дистанция: берете проект и оцениваете каждый шаг по ходу работы. Идея в том, что если к точности прикидывать каждый новый спринт, в конце вы, возможно, приблизитесь к адекватной оценке. А может, и нет — главное не останавливаться!

Преимущества:

  • Метод гибкий, как гимнаст на олимпиаде.
  • Позволяет исправить ошибки в процессе, а не через три месяца отчаяния.

Недостатки:

  • Постоянное пересчитывание — это как жизнь в калькуляторе.
  • Может раздражать тех, кто любит определенность и отчеты на 200 страницах.

Совет: Держите под рукой графики и диаграммы. Чем больше красивых картинок, тем больше доверия от клиента.

Метод №4: PERT (Проектирование: “Все будет хорошо, ну или нет”)

PERT (Program Evaluation and Review Technique) — метод для тех, кто любит сложные названия и у кого есть калькулятор под рукой. Суть в том, что вы оцениваете проект тремя числами: оптимистичным (если звезды сойдутся), пессимистичным (если всё пойдет к черту) и наиболее вероятным (когда все идет не так уж плохо, но и не идеально).

Преимущества:

  • Звучит умно, коллеги будут вас уважать.
  • Можно списать ошибки на “прогнозирование риска”.

Недостатки:

  • Требует навыков работы с математикой, а это не всем по вкусу.
  • Оптимизм в IT — вещь опасная, ведь пессимистические сценарии, как правило, ближе к правде.

Совет: Добавьте в оптимистический расчет побольше кофе. Без кофе проект может оказаться гораздо дольше.

Метод №5: “Метод Делфи” (или “Один ум хорошо, а десять — лучше”)

Этот метод хорош для тех, кто не любит брать на себя ответственность. Берете группу экспертов, закрываете их в виртуальной комнате (или Zoom), даете им немного времени и наблюдаете, как они спорят, пытаясь договориться о сроках и бюджете.

Преимущества:

  • Решение принимается коллективно, а значит, виноватых не найдется.
  • Высока вероятность получить несколько вариантов ответа, из которых можно выбрать самый подходящий.

Недостатки:

  • Эксперты могут быть настолько умны, что не договорятся никогда.
  • Возможны затяжные обсуждения, во время которых можно успеть закончить половину проекта.

Совет: Когда кто-то начинает говорить слишком умные слова, просто кивайте. Пусть думают, что вы в теме.

Заключение: Какой метод выбрать?

Нет универсальной методики оценки IT-проекта, как нет универсальной таблетки от головной боли в пятницу вечером. Но хороший выбор — это комбинация методов, немного интуиции и чуточка удачи. А если ничего не помогает — включайте юмор. Ведь как известно, когда проект идет не по плану, остается только смеяться!

Дмитрий Филиппов
АВТОР

Дмитрий Филиппов

Редактор, тех. специалист и фотограф сообщества DEVAN. IT Project Manager и один из организаторов конференции DEVAN.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *