Как оценить сложность проекта

Любой проект состоит из списка функций или составных, которые эти функции выполняют. И вот перед нами длинный список столбиком всего подряд, без разбора по важности: от цвета бирок до закупки товара. Теперь во всём этом потоке надо выстроить тематические или последовательные закономерности. Это могут быть просто столбики, разбитые по различным признакам (например, “Налоговая/Нотариус”, “Сайт”, “Торговая точка” и т. п.), и временная ось для фиксации хронологической последовательности. Но это необходимо только для того, чтобы наш мозг перестал выискивать связи между всеми этими элементами в своём стремлении охватить всё и сразу. Когда всё упорядочено, мозгу сразу становится легче воспринимать и обрабатывать информацию — есть немало научных трудов на эту тему. Наша задача — оценить сложность и приоритет реализации каждого элемента. Но и тут мы, как оказывается, слабы, существует даже термин “ошибка планирования”. Однако что-то мы всё же точно умеем делать хорошо: мы умеем сравнивать предметы и определять их размер, ценность и т. д.

Теперь с учётом всего вышеперечисленного давайте присвоим оценку всем нашим задачам. Можно начать с того, чтобы оценить все столбики по важности, если таковое уместно: от менее важного к более важному или наоборот. Идея заключается именно в том, чтобы начать с крайности, это поможет более чётко видеть разницу между задачами.

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

Лучше всего руководствоваться методом под названием “покер планирования”. В чём он заключается? Если коротко, суть в том, что оценку задачам дают все участники проекта, а не один человек. Приведём пример: допустим, вы делаете интернет-магазин. Ваша команда состоит из двух программистов, дизайнера и тестировщика. Следовательно, оценку дают уже не один, а пять человек, что значительно повышает её объективность. Впрочем, тут тоже есть подвох, касающийся разной степени компетентности участников проекта в тех или иных его составляющих. К примеру, на вопросы из разряда “сколько времени потратит дизайнер на дизайн главной страницы” может ответить только дизайнер, и мы даём ему здесь полный карт-бланш — в конце концов, дизайнер может обосновать свою оценку и убедить в своей правоте остальных не имеющих компетентности в этом деле членов команды. Если же все участники проекта одинаково компетентны, то можно сразу бросать карты с цифрами последовательности Фибоначчи (примерно): 1, 3, 5, 8, 13. (Почему именно Фибоначчи? Просто разница величин между цифрами этой последовательности более ощутима, чем разница между 4 и 5, например. По этому поводу тоже есть научная теория). Так, в процессе совместного мозгового штурма мы приходим к общему знаменателю в оценке сложности и длительности выполнения каждой задачи.

Вот вам история из книги Дж. Сазерленда “Scrum. Революционный метод управления проектами” о том, как проекты оценивали собаками.
Майк Кон всю жизнь борется с проблемой планирования, пытаясь уложить проекты во временные, бюджетные и оценочные рамки. Большой любитель собак — хотя жена так и не дала ему завести пса — он придумал измерять объём той или иной работы по проекту “в собаках”. Чтобы его разработчикам было удобнее ориентироваться в “собачьей” системе, он составил для них список пород: лабрадор-ретривер, терьер, немецкий дог, пудель, такса, немецкая овчарка, ирландский сеттер, бульдог.
Теперь его вопросы звучали примерно так: “Эта проблема — такса или дог? Последняя была таксой, значит, сейчас мы имеем дело с лабрадором, да?” Участники группы просматривали все элементы, которые нужно было разработать, и определяли их размер “в собаках”. Позже Майк предложил присвоить каждой породе числовое значение. Так было проще: такса — единица, а дог — тринадцать, лабрадор стал пятёркой, а бульдог — тройкой.
Испробуем эту систему на примере подготовки к свадьбе. Итак, что же у нас в списке? Найти зал для приёма гостей? Что ж, надо будет собрать информацию о ценах, просмотреть все варианты помещений — этот пункт потребует некоторых усилий, так что назовём его лабрадором (значит, пять). Жених и невеста? В принципе, всё просто. Нам лишь нужно будет обзавестись белым платьем и смокингом и не забыть явиться на торжество — этот пункт будет таксой (единица). Приглашения? Дело хлопотное. Нужно составить список жениха, список невесты, получить список от тех и других родителей, выбрать бумагу и конверты, заказать печать приглашений, подписать их все от руки. Этот весомый пункт тянет на дога (тринадцать). Может быть, даже на двух догов. Почти слон. Возможно, есть смысл разделить его на мелкие кусочки. Сделаем подпункты “сбор имён” и “печать пригласительных открыток” — они будут по бульдогу каждый (по три). Ещё один подпункт выделим для подписей женихом и невестой всех открыток — его назовём овчаркой (пять). И так далее.

Присвоение оценок не является аксиомой, это опять же “предложения на тему”. Может оказаться, что в результате выполнения определённых действий какие-то вещи не будут соответствовать нашим предположениям и потребуется вносить коррективы. Сейчас же нам необходимо в первых недельных итерациях выявить более чёткую ценность задач и спланировать более конкретные сроки по их реализации в коэффициенте “оценка=срок”. Во время планирования действий мы должны решить, какой полноценный работающий самостоятельный результат мы можем получить — так называемый MVP. Например, берём какие-то задачи и суммируем по ним баллы. Получаем, скажем, 40 баллов и предполагаем, что за неделю сделаем из этого полностью работающую функцию. Допустим, всё так и получилось. Теперь мы знаем, что 40 баллов — это неделя; из этого, в свою очередь, приблизительно понимаем, скольким баллам равен один день. Оценив остаток баллов для реализации всего проекта, мы уже понимаем, сколько времени это займёт. А также не забываем о совете Дэвида Аллена, создателя метода повышения личной эффективности GTD (Getting Things Done), и добавляем ещё 10% к сроку — и будет вам счастье.