Комментарии 9
Практически на каждом поекте кроме оценки трудозатрат требуется еще и оценка сроков.
Если про оценку времени в статье много написано, то про сроки в целом мало. Частенько бывают ситуации когда возникают события на которые мы не можем влиять, например кто-то из заказчиков уехал в неплановую командировку и повисла куча вопросов которые тормознули основной процесс.
По этому я ВСЕГДА стараюсь добавить к основным (большим) этапам по 2 недели а потом уже можно применять разные методы апроксимации...
Лет 15, как системный аналитик занимаюсь оценкой трудозатрат/сроков. Честно говоря не читал специализированную литературу про это, кроме университета где учили про диаграмму Ганта. У меня получилась смесь из вышеперечисленного. Без детального исследования не берусь серьёзно оценивать, кроме как сказать маленький, большой, сложный. Вначале провожу полевые исследования, хотя бы грубые. Но мучаю заказчика, пока точно не пойму, что они хотят. Потом изучаю НПА, так как хотелки заказчика не всегда соответствуют им. Потом проговариваю с закачиком общие черты решения. И только когда у меня есть картинка, делю на части и оцениваю каждую часть трудозатрат по ролями разработчиков. В основном оцениваю сам, но иногда где есть несколько архитектурных решений, консультируюсь с сеньор разработчиками. Не сколько спрашиваю сроки, а сами архитектурные решение. Так как системы которые я разрабатываю немного спецефичны, очень часто надо делать чтобы соответствовало закону, а не логике, то оценкам программистов не доверяю. Они не знают бизнес требований, не учитывают тип и бекграунд пользователей, поэтому могут вложиться в то, что можно сделать упрощено и наоборот отмахнуться от важного. Min - max оцениваю по подзадачам в которых ещё есть элемент неопределённости. По остальным делаю одну среднию вероятную оценку. По неопределённый беру максимальную, по остальным среднию. И если хорошо знаю команду, то оставляю как есть, так как когда оцениваю, то оцениваю с учётом скорости каждого. Если пока плохо знаю кого-то в команде, то оцениваю в среднем, а потом добавляю 30÷. Конечно бывают просчеты, но в целом приемлемо укладываюсь.
Лучшая книга на эту тему Ф.Брукс "Мифический человеко-месяц". Всем советую.
Простая формула: длительность разработки, названную программистом, нужно умножать на число Пи. Научный подход...
Автор, вы круто разложили суть темы. Я возьму в заметки. Но я по своей сути человек ленивый и предпочитаю не делать многое руками. И использую сервисы, которые помогают автоматизировать рутину и выстроить процессы так, чтобы легко было отследить загруженность каждого отдела и сотрудника. Точно могу посоветовать Юджайл, с ним дедлайны перестали ехать и заказчики довольны.
Как правильно оценивать сроки IT-проектов