Дедлайн — вчера - как правильно оценить трудоемкость задачи
Каждый 1С-ник сталкивался с оценкой задачи. И, почти уверен, многим доводилось страшно ошибаться не в свою пользу. А потом либо думать, как же согласовать дополнительные сроки, либо изо всех сил стараться уложиться в озвученный вариант (нередко в ущерб качеству).
Что делать? Есть различные более-менее формальные модели (например, COCOMO II), в которых эксперт должен дать оценку количества строк кода в проекте. Исходя из этого высчитывается критерий трудоемкости.
Но, как говорил Билл Гейтс, «измерять трудоемкость программирования подсчетом строк кода — это все равно, что оценивать постройку самолета по его весу». Думаю, для 1С-проектов это верно втройне. Я ни разу не сталкивался с тем, чтобы работу 1С-ника анализировали с помощью формальных методик. Этим всегда занимается эксперт.
Проблемы чаще всего возникают, когда оценщик — это неопытный специалист:
а) Ему сложно декомпозировать проект на небольшие части.
б) У него не хватает опыта, чтобы прикинуть трудоемкость работ. Особенно если еще не сталкивался с похожими задачами.
в) Он оценивает, например, только разработку, и забывает про неочевидные дополнительные работы.
Есть шуточная формула для получения реальной оценки задачи (Треал) по оценке программиста (Тпрогр):
Треал = Тпрогр ✕ π ✕ e
Формула рабочая, советую 🙂. Но если вам хочется лучшего обоснования, тогда используйте мои наработки (подходит для небольших задач). Они мало помогут с пунктами (а) и (б) из списка выше, но позволят не забыть о важном пункте (в).
Анализ сроков — отдельная тема. О ней в следующий раз.
Ошибаетесь в оценке?
🔥 — часто, но только в свою пользу!
😱 — постоянно недооцениваю реальные трудозатраты и сроки, мучаюсь из-за этого.
👍 — оценкой не занимаюсь, но возьму на вооружение твои наработки, и ух!.. 🙂
#кейсы