Оценка трудоемкости и сроков разработки — это очень щепетильный вопрос, потому что на него сложно ответить точно, так как в расчеты вступает множество известных и неизвестных факторов. Поэтому, когда говорят, что нужно выполнить работу в кратчайшие сроки, — всегда становится интересно, а кратчайшие сроки — это сколько дней? А как посчитать эти «кратчайшие сроки», чтобы действительно было быстро, но в то же время качественно? А можно ли сделать быстрее? А нужно ли ставить крайний срок выполнения задачи? Вопросов очень много, но так же много и принципов оценки трудоемкости и сроков разработки.
Оценивать время и трудоемкость разработки можно двумя подходами:
основываясь на формулах и коэффициентах;
основываясь на своем личном опыте.
Оба имеют право на существование, и оба имеют погрешности.
Кратчайшие сроки — это сколько дней?
Кратчайшие сроки — это минимальное количество из возможно затраченных дней на разработку продукта. Сколько это может быть дней — нужно считать, потому что длительность разработки проекта — это переменная величина, которая задается не точной датой, а какими-то временными рамками.
Кратчайшие сроки: технический подход в расчетах
Технические расчеты времени на разработку программного продукта ведутся на основании ГОСТа 19.102-77 «Стадии разработки». Суть в том, что есть среднестатистические временные затраты на каждую отдельную стадию разработки и формула, как это все складывается. Результатом таких расчетов будет среднее время на разработку конкретного продукта.
Коэффициенты и обозначения, которые сопровождают технический расчет:
Тпо — подготовительное описание задачи. Этот показатель берется по фактически затраченному времени.
То — описание задачи. Расчет этого коэффициента осуществляется по формуле То=Q*B/50*K. Q — это условное число команд, которое зависит от типа поставленной задачи; оно рассчитывается по формуле Q=q*c, где q — примерное число команд, а с — это коэффициент сложности и новизны программного продукта. В — это коэффициент вероятных изменений в задаче, который берется из интервала 1,2-1,5. К — это коэффициент, который учитывает квалификацию специалиста, зависит от стажа в программировании.
Тбс — подготовка блок-схем алгоритмов. Рассчитывается по формуле Тбс= Q/50*К.
Тн — написание программного обеспечения. Расчет ведется по формуле Тн=Q-1.5/50*К.
Тд — документирование продукта. Время берется фактическое и обычно составляет 40 чел/часов.
Общее время на создание всего продукта подсчитывается по формуле:
Т = Тпо + То + Тбс + Тн + Тд
Результатом такого расчета будет количество необходимых человеко-часов для разработки конкретного продукта одним специалистом. Это будет среднее время, в которое не входят индивидуальные характеристики специалиста, например, скорость печати или знакомство с технологией, на которой будет вестись разработка. Ведь вполне вероятно, что специалисту нужно будет подучить выбранный стек, потому что он ему мало знаком.
Поэтому вдобавок к техническому подсчету времени на разработку приходит в помощь расчет на основе личного опыта.
Кратчайшие сроки: подсчет на основе личного опыта
Не трудно понять, что тут в игру вступает личный опыт человека, который берется ответить на вопрос: «Кратчайшие сроки разработки — это сколько дней?» или просто посчитать примерное время, которое необходимо выделить на разработку конкретного продукта.
Обычно такими подсчетами занимаются программисты с большим опытом, которые понимают, где их может ждать «засада» в работе и куда может уйти драгоценное время. Это не значит, что они уже заранее знают о длительности проекта и способны моментально выдавать какую-то дату. Им также нужно изучить проект, понимать возможности и загруженность своей команды, проанализировать вероятные сложности, приложить к этому непредвиденные обстоятельства и т. д. Они тоже ведут подсчет, который также будет примерным, как и в случае с применением формул. С той лишь разницей, что при использовании формул и таблиц коэффициентов время на разработку рассчитывается на основе средних данных, полученных непонятно откуда. А когда рассчитывает конкретный специалист, то он пользуется конкретно своими характеристиками или характеристиками конкретной команды, которая будет заниматься разработкой. То есть его расчеты будут более приближенными к реальности.
Ключевые факторы при оценке личным опытом
Люди, которые оценивают время на разработку на основе своего опыта, обращают внимание на несколько ключевых факторов, чтобы расчеты получились максимально точными:
Личное время. Если разработкой занимаетесь лично вы, тогда вопрос «Сколько времени нужно лично мне?» будет актуальным. Но если это командная разработка, то не нужно оценивать, за сколько времени сделаете именно вы, нужно брать во внимание возможности команды. Ведь может так случиться, что в команде будут менее опытные специалисты, а значит, они будут работать медленнее.
Время нужно завышать. Даже если вы вроде точно посчитали, сколько нужно времени на разработку, то хорошая практика — это повысить расчетное время на 15-20%. Лучше сделать раньше, чем превысить оговоренный срок.
Уровень квалификации. Иногда для того, чтобы разработать продукт, вам или кому-то из вашей команды нужно будет выучить что-то новое. На изучение новых технологий также нужно закладывать время.
Аналогичные проекты. Если вы уже занимались подобными проектами, то не лишним будет проанализировать, есть ли у вас уже готовые наработки похожего продукта, ведь есть вероятность, что с готовыми решениями работа пойдет куда быстрее. Если нет готовых решений, то, возможно, есть разработчики в команде, которые занимались чем-то подобным.
В разработку продукта входит время не только разработчиков. Если просят посчитать время «от идеи и до релиза», то нужно считать работу и других специалистов: тестировщиков, аналитиков, специалистов по обеспечению и т. д.
Заключение
Если вас просят указать кратчайшие сроки конкретной разработки, чтобы вы ответили, сколько это займет дней или часов, — вы в сложной ситуации. Ведь не нужно вдаваться глубоко в философию, чтобы понять, что время не посчитать. Это касается и разработки. Все расчеты дают лишь примерные результаты, которые иногда могут оказаться верными, а иногда — нет. Может так случиться, что вы выполняли несложную работу много раз и знаете, сколько на нее нужно времени, но, взявшись еще раз, вы обнаружили, что произошло какое-то обновление, поменялась структура или алгоритм, сменились API и т. д. А это значит, что вам нужно дополнительное время для решения этой задачи. Именно для таких случаев и закладывается 15-20% в плюс от ваших расчетов.
Другое
