Как оценивать срок разработки

Многие компании создают программы и сайты на заказ и всегда очень остро стоит вопрос, как оценить, сколько времени уйдет на ту или иную работу. Я решил собрать несколько правил, которые могут помочь в оценке.


Сначала несколько мифов, которые бытуют среди начинающих менеджеров:

1. Время разработки можно оценить точнее, чем на 10%. Всегда когда кто-то вам оценивает время разработки, будьте уверены, что оценка никогда не высчитывается точно. Особенность программирования состоит в том, что всегда создается нечто, что еще никогда не делалось. В строительстве, например можно оценить время дома, поскольку дом изготавливается строго по определенной многократно проверенной технологии. В программировании, если программа была создана, достаточно ее просто скопировать и делать ее не нужно.
2. Существует единое мнение о том, сделана работа или нет. По программам нет гостов, нет единых правил о качестве программного обеспечения. Каждая компания имеет свои правила работы. Если вы заказываете программу у фрилансера, то готовьтесь получить говно, если у дорогой компании, то получите нечто получше, но ошибки в программе все равно будут. Программист очень рискует, когда делает программу на заказ, поскольку клиент в любой момент может сказать, что вот тут нужно подвинуть на пиксел, вот тут не так работает. Чтобы обезопаситься необходимо прописывать в договоре или тех. задании, каким условиям должна соответствовать программа.
3. Программу или сайт можно написать без ошибок. Если в программе нет ошибок, она просто не до конца протестирована. Программа может работать без ошибок, если она не используется. Как только программа попадает в реальный мир, который сам содержит бесконечное количество ошибок, программа начинает неправильно работать. Любая программа содержит программный код, который позволяет обходить распространенные ошибки окружающего мира, но все ошибки обойти невозможно. Чем больше система, тем больше в ней ошибок. Также любая достаточно большая система имеет список ошибок, которые не решены и не будут решаться в ближашее время.
4. Программу можно доделать до конца. Только программу, которая пишется для какого-то временного события или задачи можно написать до конца. Поскольку ошибки в программе всегда есть, то доделать до конца ее невозможно. К этому добавляются постоянно изменяющиеся требования окружающего мира к программе. Сданные клиенту программы представляют собой некий компромисс между сроком и количеством оставшихся ошибок.

Каким же образом возможно что-либо оценить в этом непредсказуемом мире? Необходимо следовать следующим правилам:

1. Собирайте информацию, сколько времени уходит на похожие работы. Сколько уходит времени на форму, страницу, отчет.
2. Попытайтесь выделить параметры, по которым вы можете оценивать трудоемкость: примерный объем javascript на форму, количество контролов, количество операций с базой данных на форме. Если новая форма будет отличаться по одному параметру, то вы можете соответственно умножить или поделить время пропорционально параметру.
3. Чем вреднее и труднее в переговорах заказчик, тем больше будет с ним проблем. Смело увеличивайте время разработки в 1.5 раза.
4. Чем больше посредников между вами и клиентом, чем больше контролирующих сторон, тем дольше вы будете разрабатывать. В программе всегда есть ошибки. Большое количество наблюдателей найдет больше ошибок, чем один наблюдатель.
5. Закладывайте срок с большим запасом на те инструменты и API, с которыми вы ни разу не работали. Здесь также учитывается интеграция с неизвестными системами. Пусть даже заказчик будет вас уверять, что его программист сказал, что там все просто, не верьте ему. Лучше перестраховаться.
6. Учитывайте риски: человек заболел, какая-то функция работает не так, как написано в документации, просто лень работать и болит голова. Рассчитывайте, что работать нужно спокойно и взвешено, а не второпях, чтобы можно было попить чай и посмотреть на проект со стороны.