Оценка проектов в IT — больная тема. Кто не давал невыполнимых обещаний, а потом не сидел овертайм, чтобы уложиться в тот срок, что сам и озвучил?
В начале пути, когда давал оценку будучи разработчиком, я постоянно недооценивал. Каждый раз выявлялась работа, которую я не учел. Коллеги советовали умножать оценки на 2, на 3, на число ПИ — но это не помогало улучшить точность оценок, а только добавляло других проблем. Например, когда нужно было объяснить, откуда взялась высокая оценка.
С того времени прошло 10 лет. За это время я участвовал в оценке более 200 проектов, набил много шишек и хочу поделиться с вами мыслями на тему оценки проектов.
Надеюсь, статья поможет вам улучшить качество оценок, которые вы даете.
Процент «успешных» проектов не превышает 29% (Исследование The Standish Group за 2015 год). Остальные 71% либо провальные, либо вышли за рамки тройного ограничения (сроки, функционал, бюджет).
Из этой статистики делаем вывод, что оценка проектов часто не соответствует действительности. Значит ли это, что оценку давать нет смысла? На просторах интернета даже появилось движение за то, чтобы не давать никаких оценок, а просто писать код — и будь, что будет. Что успеем, то успеем (поищите по тегу #noestimates).
Не давать никаких оценок — звучит заманчиво, но давайте отвлечемся и представим, что вы заказываете такси. Вы спрашиваете водителя: «сколько стоит доехать до такой-то улицы», а он отвечает: «не знаю, садись в машину, доедем — скажу, сколько заплатить по приезду».
Или, например, вариант в стиле Agile: «Ну, мы будем ехать, а ты будешь платить мне каждые 10 минут в дороге — и так пока не кончатся деньги) Как кончатся — высажу, но, возможно, мы доедем, или будем уже рядом. Ну, а если не рядом, то это твои проблемы — не повезло.»
Примерно так ощущают себя заказчики в ИТ, когда им предлагают начать работы без каких-либо оценок.
В примере выше в идеале мы хотим получить от водителя точную цену, за которую он нас довезет. В крайнем случае, неплохо бы получить диапазон цен. Так мы сможем прикинуть — брать такси, ехать общественным транспортом, идти пешком или вообще никуда не ехать и остаться дома.
Лезть в машину, совсем не понимая, чего ожидать — не то решение, которое принимают в здравом уме.
Надеюсь, мне удалось убедить вас, что оценка — это важная составляющая для принятия решений на проекте. Она может быть близкой к реальности, а может быть не очень, но она нужна.
Давайте представим, что менеджер спрашивает разработчика, за сколько он сделает задачу. Разработчик уже делал подобное ранее и дает «наиболее вероятную» оценку. Пусть это будет 10 дней. Есть, конечно, вероятность, что задача займет 12 дней, но эта вероятность ниже, чем вероятность того, что задача займет 10 дней. Так же есть вероятность, что задача займет 8 дней, но и эта вероятность будет меньше.
Часто предполагается, что оценки на задачу/проект распределяются по нормальному закону распределения (