Здравствуйте,
обращаюсь с вопросом о том кто как оценивает обьем преддстоящих работ в терминах времени.

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

Вискажите свое мнение
Спасибо

Здравствуйте, nstasiv, Вы писали:

N>Вискажите свое мнение
Гуглимся на предмет Function Point Analysis

По оценке трудозатрат гугл показывает много интересных материалов.

Во-первых, это будет цифра нереальная.
Во-вторых, иногда проект состоит не всегда из уже известных вещей, но также и тех, которые раньше не делались. Отсюда — часть времени нужно обязательно заложить на investigation/prototyping phase.
В-третьих, оценивать нужно не спецификацию по количеству страниц, а задачи, на которые разбит весь проект (продолжительность выполнения одной задачи должна быть сопоставима с одним-двумя днями).
В-четвертых, оценивать желательно не в "человеко-днях", а в "еденицах сложности реализации" задачи. Конкретные человеко-дни — это сложность реализации задачи, умноженная на уровень программистов, которые эту задачу будут делать. Не секрет, что иногда производительность программистов различается в разы.
В-пятых, учесть доп. время на интеграцию и тестирование.

Более подробно — в книжках и гугле.

IMHO, только так можно выдать более-менее реальную цифру.

ЗЫ: главная причина, по которой я написал этот пост — не поучения, а чтобы вы никогда не использовали способ "умножить число страниц на примерную величину времени потраченную на разработку одной страници".

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

Начну знакомится <a href="http://en.wikipedia.org/wiki/Function_point_analysis">отсюда</a>

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, nstasiv, Вы писали:

N>>Вискажите свое мнение
GZ>Гуглимся на предмет Function Point Analysis

Здравствуйте, nstasiv, Вы писали:

N>Начну знакомится <a href="http://en.wikipedia.org/wiki/Function_point_analysis">отсюда</a>

N>Здравствуйте, GlebZ, Вы писали:

GZ>>Здравствуйте, nstasiv, Вы писали:

N>>>Вискажите свое мнение
GZ>>Гуглимся на предмет Function Point Analysis

а там написано, что для эффективной работы метода функциональных точек необходима солидная статистика ?

зы
Если ваша организация этой статистики не имеет, то ПМ должен хотябы исходить из предыдущего опыта.

Здравствуйте, nstasiv, Вы писали:

N>Большое спасибо за ответ. Резюмируя могу сказать что сначала нужно провести декомпозицию задачи до елеметарних заданий, и лишь затем начинать оценивать каждую.

Как говорится, лучший способ точно оценить проект — выполнить его!

Во-первых, что может стоять за "декомпозицией задачи до елеметарних заданий"? Кто вообще заранее знает, какие задания возникнут в ходе проекта? Вы экстрасенс? Потому что я — точно нет! Выполнить "декомпозицию до елеметарних заданий" означает понять в деталях, что собой предствляет система, т.е. выполнить анализ требований, разработку архитектуры и частично планирование. А ведь это добрая четверть бюджета (в то время как проект еще начался, бюджет не утвержден). Есть ли у нас на это время? Как правило, нет. Есть ли у нас на это деньги? Как правило, нет. Всегда ли требования заказчика сформулированы достаточно полно? Как правило, нет. Меняются ли они по ходу проекта или даже на первой стадии? Как правило, да. Оценивать по декомпозиции хорошо, когда декомпозиция уже существует и вероятность ее изменения низкая (т.е. явно не перед началом проекта). Можно декомпозировать до упора а потом обжечься на том, что анализ требований (который выполняется уже после утверждения оценки!) отправит большую часть стройной картины декомпозиции заданий фтопку.

Как видите, детальная декомпозиция не всегда уместна. В некоторых ситуациях метод "посчитать примерное количество чего-то и умножить на N чел-часов" является более адекватным — точность та же (три лаптя по карте), а затраты меньше. К слову сказать, если вы можете сходу определить примерное количество пользовательских форм, это уже предпосылка к точной оценке. По-крайней мере для web-приложений. Понятно, что страничка login займет 2 часа, а страничка какого-нибудь отчета 16, но, поверьте, что на точность это повлияет мало. Смело множьте и вперед! Незабудте добавить коэфициенты на риски, новизну задачи или неопытность разработчиков, взятые со справочника "Стэли", затраты на разработку требований, развертывание, тестирование, управление и т.д. Для многих ситуаций вы получите достаточно хорошую оценку.

Вообще, в этом вопросе нужна определенная гибкость. Оценки бывают разные, и каждой — свое место и свое время. Я бы класифицировал их следующим образом:
1. Оценки на случай, когда интересен просто порядок затрат
2. Оценки на случай подписания контракта
3. Оценки для уточнения бюджета
Соответственно выбирается и подход к оценке: от интуиции (читай "от балды") через "посчитать и умножить" до оценки по "детальной декомпозиции". К слову сказать, умение быстро охватить проект, разбить его на "счетные элементы" и предсказать трудозатраты (и чтобы сбылись!) требует определенного таланта. Поэтому старайтесь вычислять среди ваших сотрудников таких "природных оценщиков".

P.S. Также можно почитать мой post про оценку затрат на разработку требований здесь

Автор: Unabomber
Дата: 01.03.06