Как рассчитать сроки проекта, если проект большой и нетиповой?
Разрабатываем клиентам нетиповые вебпроекты. В основном автоматизация какой-то части их бизнес процессов. Из-за того что проекты нестандартные, встает вопрос о сроках - какой говорить?
В который раз происходит так что говорим - и не укладываемся в положенные сроки. Оказывается что модуль требует на разработку больше часов чем ожидалось. Клиент тоже планирует свою деятельность исходя по нашим срокам.
В итоге имеем не самый качественный код, затянутые сроки которые сбивают сроки по другим проектам (что бьет по карману), нервотрепку, иногда ушедших клиентов (что тоже бьет по карману) .
Что можно предпринять?
1) делать подробное тз.
2) разделить тз и раздать тем кто его будет реализовывать.
3) каждому звену, который делает проект предоставить время ознакомления с проектом и попросить определить примерное время за которое он сможет реализовать свою часть.
4) собрать данные о времени у сотрудников - проанализировать.
и только теперь вы можете предоставить примерное время разработки клиенту.
p.s. суть этого метода в том, что сотрудники сразу ознакомлены с тем, что им предстоит делать. и в 90% случаях не бывает ситуаций, как вы описали "Оказывается что модуль требует на разработку больше часов чем ожидалось."
p.p.s. понятное дело что такой метод тоже не даст вам 100% точный дедлайн, но много проблем точно отпадет.
Спасибо. Отличный, достаточно полный, совет. Я бы еще добавил "Делить работу на мелкие кусочки. Оценивать и оплачивать кусочно." что предложил товарищ malbaron
Олег Гамега: я включил это в слово "проанализировать")) а вообще там дел не так мало если глубже смотреть. кроме того как добавить 30% - порой нужно наоборот отнять. потому что если рассматривать каждую задачу самому и вникать - часто будут случаи, что сотрудник просто хочет халтурить и сам накинет 50% лишнего времени.
Декомпозиция содержания проекта - лишь один из инструментов, которые используются уже не один десяток лет в проектном управлении. Если не хотите каждый раз изобретать велосипед и делать открытия подобные этому, отправьте ваших руководителей проектов на хорошие курсы (очные или онлайн).
Расчитывать в голову приблизительно с запасом, но предупреждать о возможности неучтенной сложности. После чего сроки будут как бы иметь форс мажор в случаи не укладки во время. И вы всегда сможете сказать, что предупреждали о - возможности неучтенной сложности.
1. Учиться на своих ошибках и успехах. Алгоритма по оценке не существует, есть методики, но они требуют опыта оценки. Без опыта оценки всё равно будет неверный результат.
2. Прочитать "Вальсируя с Медведями". Там есть методика рассчёта Riskology, из неё будет хотя бы понятно как это работает вообще.
Если проект больше чем на пол года, то гораздо эффективней будет угадывать послушав 15 минутную презентацию нежели заниматься оценками и попытками сделать из этого план (Не шутка.) Наша компания если видит проект который надо разбирать более недели, сразу отказывается давать оценку и говорит что можно разрабатывать год-два и т.п. И есть клиенты кто соглашается и работает. В основном опытные. Не опытные сбегают туда где поманят фикспрайсом и конкретными цифрами.
