Практически все проекты связаны с рисками и неопределённостями. Из-за объективных и необъективных причин могут сдвигаться сроки, раздуваться бюджеты, увеличиваться объёмы работ. Как избежать ошибок и правильно оценивать задачи изначально? Ну или хотя бы с максимально возможной точностью…. Сейчас покажем и расскажем.
Какие преимущества даёт правильная оценка задач в проектах
В целом, плюсы оценки очевидны: вы точно знаете, что, когда и в каком объёме вам предстоит сделать. Однако этого недостаточно. При создании нового проекта есть также стейкхолдеры, бюджет и дедлайны. Необходимо учитывать влияние всех сторон и рисков.
Итак, зачем оцениваются задачи в проектах:
- Для лучшего планирования работы и грамотного распределения ресурсов. Ресурсы – это не только время, но и люди, финансы, оборудование, материалы, продукция и прочее. Всё это должно находиться в балансе.
- Чтобы держать темп. Работать над проектом можно по-разному: с надрывом, поскольку сроки горят, или планомерно, без стресса. В каком случае вы получаете меньше рисков и не теряете нервные клетки? Только при сохранении оптимального темпа, который позволяет следить за всеми параметрами продукта: его качеством, стоимостью и временем реализации.
- Для адекватного запроса бюджет. Ресурсы никогда не бывают бесконечными. И если бюджет проекта быстро выйдет за изначально обозначенные рамки, скорее всего, его закроют как нерентабельный. Если вы запросите деньги «с запасом», то вам их могут не выделить. Здесь важен баланс и трезвая оценка.
- Для лучшего контроля процесса. Контроль – это всегда сравнение планов с реальностью. Если появляются отклонения, у вас есть шанс что-то предпринять. Но если нет критериев оценки (нет плана и цифр), то и контролировать ничего не получится.
- Для своевременного принятия управленческие решения. Это прямое следствие предыдущего пункта. Представьте, что продолжение проекта стало нецелесообразным (изменились условия, задачи, он потерял актуальность). Когда лучше остановить работу: сразу, как это стало ясно, или когда проект будет доведён до логического конца? Конечно, сразу. А понять текущее состояние помогает только качественная и адекватная оценка.
- Для поиска общего решения. Заказчики хотят одного, конечные пользователи — другого, разработчики — третьего, инвесторы — четвёртого… Как прийти к компромиссу? Только правильно обосновав свою точку зрения. И тут снова помогает качественная оценка.
Основные трудности оценки задач в проектах
- Риски и форс-мажоры. Они повышают неопределённость и влияют на точность оценки. Даже при наличии статистики и опыта форс-мажор может перечеркнуть всё и внести свои коррективы. Могут измениться внешние обстоятельства, рынок, пожелания стейкхолдеров и прочее. Все мы зависим от внешних факторов.
- Отсутствие или недостаток данных. Если для анализа не хватает информации, то выводы могут быть неправильными или неточными. В новых проектах это встречается сплошь и рядом. Чем больше наработано статистики, тем точнее будет оценка аналогичных задач.
- Субъективность оценки. Если вы можете реализовать задачу за N-часов, это не означает, что все могут сделать так же. Кто-то сделает задачу быстрее, кто-то медленнее, а кто-то вообще никогда.
- Чрезмерный оптимизм. Это когда вы выдаёте желаемое за действительное. Одно дело — хотеть сделать задачу, а другое – реально её сделать.
- Чрезмерный пессимизм. Это обратный процесс: вы видите только одни проблемы и риски, что может казаться трезвым подходом, но на самом деле это ограничение, которое не даёт вам нормально работать. Вероятность самого негативного сценария всегда крайне низка. Если ничего не делать, ничего и никогда не получится. Отказавшись от борьбы, вы заранее проигрываете.
- Отсутствие необходимых ресурсов. Даже хорошо стандартизированный проект может иметь отклонения. Выбыл или заболел сотрудник, не выделили финансирование, сломалось оборудование, или его еще не закупили… Варианты могут быть любыми. Это может быть как форс-мажор, так и системная ошибка. Например, если вы неправильно оценили квалификацию специалистов или рассчитывали на одну производственную базу, а получили другую.
- Влияние стейкхолдеров. Команда видит проект одним образом, а клиенты и инвесторы — совершенно по-другому. Так или иначе и пользователи, и спонсоры могут настаивать на своих интересах. Всё это может кардинально повлиять на проект и на качество планирования и оценки.
Какие существуют техники оценки задач
Ниже опишем те подходы, которые чаще других используются в IT и в других сферах.
1. Оценка задач снизу вверх
Самый логичный и действенный подход. Совместим даже с очень сложными проектами и задачами. Своего рода «инженерный подход».
Он заключается в декомпозиции задачи или проекта на действия, которые можно оценить с высокой точностью: по времени, ресурсам и не только. Полная картину оценок можно сложить и на выходе получить адекватную совокупную оценку.
Но есть и нюансы:
- Во-первых, задача должна раскладываться на известные действия. Если это невозможно, то и оценить задачу не получится.
- Во-вторых, у каждой подзадачи могут быть свои пределы «от» и «до». Соответственно, общие пределы могут иметь значительные отклонения как в большую, так и в меньшую сторону от реальности.
- В-третьих, при суммировании оценивается последовательная реализация. А многие задачи можно распараллелить. Если задействовать разных специалистов и параллельные потоки на разных точках, с привязкой к датам и без них, то сложность оценки возрастает кратно.
2. Экспертная оценка
Прямая противоположность предыдущему подходу – всё оценивается просто и быстро. В основе лежит опыт и знания эксперта, который уже сталкивался с аналогичными задачами. Он может с высокой точностью оценить сроки, бюджет и необходимые ресурсы. Такой метод эффективен даже в ситуациях, когда задачу невозможно декомпозировать на подзадачи и оценить их по отдельности (как в подходе «снизу вверх»).
Но и тут есть подводные камни:
- Всё зависит от мнения эксперта, а его ещё нужно найти. Если задача кардинально новая, то специалистов по ней просто не существует.
- Эксперт – тоже человек, а значит, он может ошибаться. Ведь он всегда мыслит субъективно, исходя из своего опыта и знаний.
- Даже при достаточном опыте и знаниях оценка никогда не будет точной. Это всегда примерный ориентир.
3. Метод PERT (в некоторых источниках «техника трёх точек»).
Страница на Wiki. Аббревиатура расшифровывается как Program Evaluation and Review Technique, что в переводе означает «Методика оценки и обзора программ».
Метод сводится к математическому расчёту некоего промежуточного значения между оптимистичной (O), наиболее вероятной (M) и пессимистичной (P) оценками.
Формула расчёта ожидаемой оценки выглядит следующим образом:
(O + 4*M + P) / 6
Если внимательно её рассмотреть, можно заметить, что наибольший приоритет (4 части из 6 возможных) отдаётся наиболее вероятной оценке. Остальные нужны для нивелирования.
Иногда используется формула, которая имеет смещение к пессимистичному сценарию – самая «плохая» оценка получает 3 доли из 6 возможных:
(O + 2*M + 3*P) / 6
Расчёт на самом деле очень простой. Но есть у него и минусы:
- Необходимо продумать сразу несколько вариантов оценок. Брать их с потолка бессмысленно, от этого точность итоговой оценки не увеличится.
- Вы всё равно получаете только примерную ожидаемую оценку и лишь сужаете коридор отклонений.
- Оценка не учитывает предыдущий опыт, даже если он есть.
4. Метод аналогий
Один из немногих подходов, который опирается на историю и предыдущий опыт. К примеру, у вас уже есть данные по срокам и ресурсам, полученные в аналогичных задачах. Их вполне можно взять за основу при расчёте оценки новой задачи – такой же или похожей по составу операций.
Вероятность отклонения в теории должна быть минимальной.
Конкретных формул здесь нет, но вы можете использовать усреднение (медианное значение), аппроксимацию, корреляцию, разные методы интерполяции (вычисления промежуточных значений) или любые другие математические методы для поиска пределов отклонения новой величины на основе предыдущих значений.
Подводные камни:
- Если предыдущее событие завершилось за N-часов, нет никаких гарантий, что следующее аналогичное событие займет столько же времени.
- Даже при большом объеме наработанной статистики всё равно могут случаться форс-мажоры. Их ни одна формула учесть не сможет.
- Если аналогов нет, проведение расчёт значений невозможно.
5. Покер планирования (согласование)
При планировании задачи задействованные лица (ответственные сотрудники, эксперты, стейкхолдеры) с помощью цифровых карт (чаще всего соответствующих упрощённой последовательности Фибоначчи) оценивают сложность реализации конкретной задачи. Каждый может и должен защищать свою точку зрения, аргументируя оценку. В течение нескольких итераций согласования участники должны прийти к консенсусу – к той оценке, которая устроит все стороны.
Аналогичные коллективные решения можно принимать и без элементов геймификации – на очном собрании, в формате обсуждений или форума.
Минусы очевидны:
- Более влиятельные и напористые участники могут настоять на своей точке зрения и оценке. Но не факт, что она останется адекватной.
- Здесь нет никаких расчётов, поэтому оценки фактически основываются на мнении экспертов (с такими же недостатками и следствиями).
6. Параметрическая оценка
Здесь за основу берётся некий хорошо известный параметр, на основе которого можно измерить задачу. Например, это может быть производительность сотрудника: сколько строк кода он может написать в час, сколько деталей он делает в день/неделю и т.п.
Когда такой параметр известен, легко посчитать, сколько усилий или ресурсов необходимо потратить на реализацию новой задачи. Расчёты можно усложнять и адаптировать, внедряя личные коэффициенты производительности для каждого отдельного сотрудника.
Звучит убедительно, но есть нюансы:
- Такие расчёты можно вести только тогда, когда известен хотя бы примерный общий объём работ. Сколько строк кода не пиши, а если задача не решена, то проект в релиз не выйдет.
- Рядовым специалистам выгоднее производить «параметры», а не результат. На выходе можно получить затягивание сроков и повышение бюджетов.
- Оценка остается примерной и не учитывает риски или различные технические нюансы.
- Для расчета личных коэффициентов сотрудников потребуется накопленный по другим проектам опыт. Соответственно, нестандартные задачи оценить будет невозможно.
7. Delphi-метод
Усовершенствованный метод оценки экспертами. Для «усреднения» результата оценки выставляют сразу несколько независимых экспертов. Они не должны знать, какие оценки ставят другие участники. Это повысит вероятность получения объективных мнений.
После того как оценки выставлены, экспертов можно собрать вместе и выслушать каждого. При желании можно попытаться прийти к консенсусу, как при покер-планировании, а можно просто посчитать среднее значение.
Минусы в этой схеме тоже есть:
- Все эксперты могут ошибаться, если задача новая и по ней нет статистики и опыта.
- Не всегда возможно найти большое количество экспертов.
- Оценка будет чем-то напоминать «среднюю температуру по больнице». Кто конкретно в итоге окажется прав, покажет только практика.
- Если будет общее обсуждение, то итоговую оценку «продавит» тот, кто обладает наибольшим авторитетом и является активным оратором.
Что делать, если «математика» не сходится?
В итеративных методологиях разработки приоритеты задач постоянно меняются, и в список на исполнение накидываются новые вводные. Как свести концы с концами и начать двигаться к сдаче проекта, а не тратить время на решение мелочей?
Здесь ключевым является не правильная оценка задачи, а правильное определение приоритетности. Самая частая ловушка, в которую попадают многие неопытные (а иногда и опытные) команды, – это зависимость от числа закрытых задач. Чтобы показать высокую производительность, команда берёт на исполнение только те фичи и задачи, которые можно сделать быстро и с минимальными усилиями. В итоге большие и сложные задачи остаются в листе ожидания до последнего.
Но когда до них доходит дело (поскольку заказчик всё равно не будет принимать продукт без нужных функций), то работа над ними превращается в ад: бессонные ночи, переработки, аврал, ошибки, компромиссы и так по кругу.
И в таком случае проблема не в оценке сроков или сложности, а в неправильной организации работы и в неверно расставленных приоритетах. Чтобы система была в балансе, нужен грамотный менеджер проекта, которые не даст отлынивать исполнителям и будет использовать правильную мотивацию, чтобы подчинённые работали не на количество, а на качество.
Чтобы держать руку на пульсе, в команде нужно использовать систему управления проектом. Ведь чем больше задач в бэклоге, тем выше вероятность что-то упустить.
Краткий итог
Каждая из обозначенных методик имеет свои преимущества и недостатки. Поэтому выбор конкретного варианта оценки должен опираться на особенности отдельно взятого проекта. Не нужно равнять всех под одну гребёнку. Даже если аналогичный подход работал и работает у других, это не значит, что он подойдет вам. Изучайте и экспериментируйте, накапливайте опыт. И обязательно учитывайте специфику проекта.