Как оценивать время на разработку проекта

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

Работая в консалтинге мне приходилось сталкиваться и с тем, и с другим. Когда я только начинал работать на цифровом агентстве, то мы работали как раз проектами. Клиент приходит и говорит, хочу реализовать возможность авторизации с помощью Facebook. Мы считаем, сколько времени это займет, и компания выставляет клиенту стоимость проекта. Например, если мы посчитали, что на разработку уйдет 10 часов и компания при расчетах использует часовую ставку в 200 долларов, то клиенту говорят, что проект будет стоить 2 тысячи долларов (200 долларов * 10 часов). 

Сразу скажу, что 200 долларов я сейчас взял только для простоты расчетов, из того, что я вижу, в США и Канаде чаще ставка составляет 170 долларов. 

Если клиент соглашается на такую стоимость проекта, то подписывался контракт, в котором описывались требования клиента и начиналась работа. Если мы реально успевали сделать проект за 5 часов, то прибыль компании оказывалась выше. Если не успевали сделать, то прибыль была меньше. В убыток уйти при такой часовой ставке было сложно, потому что программист реально получает в районе 50 долларов в час. Это нужно очень сильно ошибиться в оценке, чтобы компания потратила на программиста больше, чем оценили проект, и ничего не осталось себе. 

При оценке стоимости проекта часовая ставка обычно выше, потому что у клиентов всегда появляются хотелки. В моей практике были случаи, когда хотелки были минимальные, но обычно их все же достаточно много, процентов 20% меняется по мере работы. 

Чуть позже я перешел на работу по часам – клиент оплачивал по факту время, которое мы тратили на проекты, но оценка все равно нужна была, чтобы клиент мог примерно планировать проекты – когда и что делать и когда их нужно запускать. Клиент должен понимать, что если сейчас начать проект, то он будет готов через определенный срок. При такой оплате часовая ставка обычно на много ниже, потому что все платиться по факту. Из того, что я слышал, в таких случаях ставка где-то 120 долларов. Программист получает 50, остальное уходит в компанию. 

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

Когда клиент платит за проект, то точность оценки очень важна, а когда платиться по факту, то допускается большая погрешность, потому что тут оценка влияет не на стоимость, а на планирование. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К тому же я писал API, а само мобильное приложение для Андроид и iOS делали в Индии. Зависимость между командами, да ещё и с разницей во времени стали серьезной проблемой. 

В результате проект то мы запустили, но даже с коэффициентом в 3 мы все равно запустили позже. 

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

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

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

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

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

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

 

Add two language support12

Create French pages14

Modify registration page3

Update creative12

Any updates to feeds???

Push to UAT2

Push to Prod1

 

Total= 44Ideal

Multiply =2.5

110Worst

 

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

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

Почему обновление UAT в моем шаблоне 2 часа, а обновление продакшн 1? UAT – это окружение, где клиент сам тестирует и проверяет функционал. Обычно его приходиться обновлять несколько раз, потому что что-то клиент захочет подправить или изменить и за одно обновление редко все решается. Так что для больших проектов я могу закладывать несколько обновлений и эта строка может быть даже 3 часа. 

---

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