Как правильно оценивать проекты - пособие для программистов

Прежде чем начинать какой-то проект, программистов очень часто просят оценить, сколько времени займёт разработка. Это важно менеджерам, чтобы понять, когда продукт или функционал может быть доставлен клиенту или на рынок. 

Из моего опыта я часто видел, что программисты не любят заниматься этим. Я сам никогда не любил. В России мне этим не приходилось заниматься (тогда мало где делали оценки) и только во второй компании в Канаде мне пришлось впервые столкнуться с этим. 

Когда впервые столкнулся с необходимостью оценить время, необходимое на выполнение проекта, я сидел и возмущался про себя: "Ну и как это оценивать? Да хрен его знает, сколько времени займёт разработка". Мне казалось, что оценка это лишняя трата времени, ведь если не заниматься этой ерундой, а сразу прыгнуть с головой в разработку, я только сэкономлю время и раньше доставлю результат. 

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

Я также много раз видел, как программисты оценивают только идеальный случай, когда все идёт отлично. Но отлично никогда и ничего не бывает, поэтому сроки постоянно срываются, а это проблемы для всех, включая самого программиста, потому что плохое начальство будет думать, что это плохой программист. 

Чтобы улучшить оценку программист начинает закладывать какие-то дополнительные часы, что-то мудрит. Я слышал, что при оценке нужно умножать свою оценку на 2, вроде как это написано в какой-то книге. Ну обязательно меняются требования, обязательно появляются баги и у клиента почти всегда появляются новые хотелки, которые увеличивают время выполнения проекта. Программист не может работать без остановки и обязательно появляется что-то, что тормозит. Это нормально и это обязательно нужно закладывать во время оценки. 

Лично я при оценке своих проектов всегда умножаю на 2.5 минимум. Если я вижу, что проект сложный, то этот коэффициент может быть увеличен даже до 3. Когда я работал в клике, то там тоже все использовали коэффициенты ещё 7 лет назад (в 2010-м году) и каждая команда выбирала его по-своему. В нашей был 2.7. Вообще там формула была немного даже сложнее. 

Сразу же при оценке нового проекта в шаблоне было учтено фиксированное время обновления продакшн, обновления UAT, создание рабочей среды для программиста и qa. Это время было фиксированное и за 5 лет моей работы в компании не менялось и не умножалось на коэффициент. Ну а дальше уже шла оценка необходимых для исполнения действий. 

При оценке конечно же мы оценивали идеальный вариант, если программист садится и работает все 8 часов, не бездельничает и все идёт как по маслу. За счёт коэффициента в 2.7 мы обычно покрывали все возможные проблемы, задержки и даже дополнительные требования. А дополнительные требования появляются всегда и именно это обычно отнимает большую часть заложенного коэффициентом время. Мы обычно на работе работали, а не занимались фигней. 

Клиенту я всегда предоставляю оба числа – идеальное время и максимальное (которое учитывает мой поправочный коэффициент). Клиент закладывает в свой календарь максимальное время и таким образом определяется время запуска. 

Таким образом я провожу оценки проектов с 2010-го года и пока что все работало неплохо, если я делал расчёты и сам же реализовывал. Но если я дела оценку, а кто-то другой реально программировал, то очень часто было заметно большое расхождение и иногда даже коэффициент не помогал. И причина не в том, что кто-то программирует медленнее, тут все на много проще. 

1. Когда я оцениваю проект, то я держу в голове какой-то план реализации. Не факт, что дугой программист выберет тот же план.

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

3. Опыт и знания. Оба эти параметра не исключают друг друга. Чтобы успешно и вовремя завершить проект в указанные мной сроки, нужно обладать как опытом, так и знаниями. Если проект включает в себя большое количество работы с какой-то технологией, а программист не имеет опыта в этом, то какой бы умный он не был, ему понадобиться больше времени. 

Да я сам тратил больше времени на проекты, когда нужно было делать что-то новое. Например, когда я писал первый REST сервис, у меня уже были теоретические знания, как все работает, но не было опыта, а нужно было сразу же написать сервисы для достаточно траффикового мобильного приложения SonyRewards. У самого сайта тогда была большая база и было ясно, как только Sony запустит своё мобильное приложение, его по любому скачает большое количество человек и нужно было не облажатся. 

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

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

На этапе оценки лучше даже сделать небольшой набросок архитектуры, как все будет решаться. Особенно если проект очень большой. Я даже делаю иногда наброски экранов и показываю клиентам. И если клиент спросит в ответ: "а как я буду делать это?" значит где-то я что-то не так понял требования и это приведет к проблемам. 

Мой габлон оценки выглядит примерно следующим образом:

1. Обновить UAT сервер: 0.5 часов (фиксировано и не умножаетная на коэфициент)

2. Обновить продакшн: 0.5 часов (фиксировано и не умножаетная на коэфициент)

3. Базовый коэфициент: 2.5

4. Чложность проекта 0. Если заранее знаю, что есть зависимости от других компаний или разработчиков, то этот параметр увеличивается до 0.5

5. Создать админ страницу: Х часов идеал или X * (базовый коэфициент + сложность проекта) всего

6. Создать фроент энд страницу: X часов идеал или X * (базовый коэфициент + сложность проекта) всего

...

...

В общем, примерно вот так вот и оцениваю и в результате получается два числа - Ideal и Worst Case.

Да, бывали случаи, когда даже превышали время worst case, но очень редко. Это происходило обычно из-за того, что не правильно были описаны требования или их неправильно поняли. Если ошибка требований или понимания замечены слишком поздно, то переделка занимала слишком много времени и сил. Поэтому я в последнее время стал регулярно показывать Work In Progress демки, чтобы клиент видел, как и в какую сторону движется проект. Если что-то не так, клиент замечает, и переделывать уже не так много. 



Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповидания на русском или английском языке.

Пишите мне


Я в социальных сетях
Facebook Telegram Youtube Instagram