Несколько тезисов об оценке трудоемкости
Собирал я тут информацию об оценках трудоемкости в веб разработке, описывал стандартные проблемы и ошибки. Вот часть получившегося документа, может кому-нибудь будет полезно:
Обычные проблемы при выполении заданий (нетехнические), которые существенно влияют на сроки.
- разрастание объема работ (scope creep)
- оптимистичность в плане качества (заработает с первого раза и с правильным результатом)
- не учтено время на необходимые вспомогательные задачи (настройка окружения, базы, выкатка, проверка и так далее)
- неправильно понята задача, недостаточно подробное или конкретное описание
- запланирован неправильный объем работ (как следствие предыдущего пункта)
- проблемы с коммуникациями
- слишком оптимистичная оценка из-за страха назвать оценку, которая не понравится руководству
Давайте разберем, что делать с каждым из пунктов:
- разрастание объема работ (scope creep)
Очень важно представлять суть проблемы, которую заказчик пытается решить тем или иным заданием. Чаще всего существенное увеличение или изменение объема работ является следствием того, что заказчик слабо представляет, что он хочет получить и пытается угадать, как лучше решить его проблему. В процессе он будет перебирать разные идеи, варианты, часто больше следуя своей интуиции, чем реальным данным. Задача разработчика — определить главную проблему, которую заказчик пытается решить, предложить ему варианты решения либо данные, на основании которых он сможет принимать более обоснованные решения. Стоит отметить, что небольшое изменение объема работ почти всегда неизбежно и уменьшить риски, связанные с этим помогает итеративность разработки, когда мы делаем какую то небольшую часть задачи, затем измеряем результат и на основании полученных данных выбираем следующий шаг. Если в процессе разработки вы видите, что заказчик сомневается или пытается добавить слишком много функционала сразу, то разбивайте задачу на несколько частей и выделяйте новые запросы заказчика в отдельные задачи, попутно стараясь замерить результаты текущей разработки.
2. оптимистичность в плане качества (заработает с первого раза и с правильным результатом)
Часто задача оценивается по самому оптимистичному сценарию, когда разработчик думает, что он будет заниматься только этой задачей, не отвлекаясь и не сталкиваясь с непредвиденными трудностями, неожиданным рефакторингом, фиксом багов от предыдущей задачи и фиксов багов этой задачи. Тут может помочь закладка определенного буфера времени на подобные вещи. Величина подобного буфера для каждого разработчика вычисляется исходя из предыдущего опыта разработки задач подобной трудоемкости.
3. не учтено время на необходимые вспомогательные задачи(настройка окружения, базы, выкатка, проверка и так далее)
Тут все понятно: учитывать время, необходимое на такие задачи.
4. неправильно понята задача, недостаточно подробное или конкретное описание
Недостаточно подробное или непонятное описание можно определить почти сразу после прочтения задачи. В таком случае надо составить список вопросов, задать их инициатору задачи и не начинать работу над задачей, пока не будут получены исчерпывающие ответы. Сложнее с другой частью — задача понята, но неправильно. Нельзя знать, чего ты не знаешь. Соответственно никогда нельзя быть на сто процентов уверенным, что ты правильно понял задачу, но можно уменьшить риск, уточняя детали, которые могут быть истрактованы двояко, не делать поспешных выводов и обобщений, иногда перефразировать и уточнять даже вещи, которые с первого взгляда могут казаться очевидными.
5. проблемы с коммуникациями
Если заказчик не отвечает на вопросы, игнорирует их, пропадает на долгое время или просто истерит, что его мысли не были прочтены сразу, то здесь помогает экалация вопроса выше, с привлечением вышестоящего человека из разработки, ответственного за коммуникацию с заказчиками. Разработчик не обязан заниматься управлением ожиданиями заказчика, равно как и его психотерапией. Если не можете найти общий язык с заказчиком — пусть это сделает человек, в чьи обязанности это непосредственно входит.
6. слишком оптимистичная оценка из-за страха назвать оценку, которая не понравится руководству
В итоге вы сами себе злобный буратино, потому что руководству намного больше не понравится, когда вы будете существенно затягивать сроки, авралить или жертвовать качеством.
Какие есть варианты определения трудоемкости задачи
- Собственный опыт оценки похожих задач
- Экспертная оценка кем то, у кого большой опыт оценки похожих задач
- Использование методик на основе отраслевого опыта. Применяются в случае очень больших задач и для оценки целых проектов
- FPA IFPUG — метод функциональных точек (14 параметров 150 стр.),
- метод COCOMO II, Constructive Cost Model (21 параметр, описание модели — 90 стр.).
4. инженерный метод оценки PERT (достаточно простой и достаточно точный, особенно с увеличением опыта)
1 и 2 — методы с большой погрешностью, 3 — очень сложный и неприменим для небольших задач.
Поговорим подробнее про метод PERT.
необходимо 3 оценки:
M — наиболее вероятная оценка затрат
O — минимальная трудоемкость, выполнение в идеальных условиях идеального мира.
P — самая пессимистичная оценка, когда все риски реализовались и все пошло не так.
Оценки должны быть независимыми, то есть желательно получить их от нескольких людей.
Оценка суммарной трудоемкости:
Средняя трудоемкость по каждой задаче —
Еi = (Р + 4М + О)/6
Среднеквадратичная ошибка оценки каждой задачи —
СКОi = (Р — О)/6
Оценка средней суммарной трудоемкости —
Е = Σ Ei
Среднеквадратичная ошибка суммарной оценки —
СКО = ΣСКОi2 (корень из суммы квадратов CKOi, tumblr не дружит с формулами)
Гарантированная оценка с вероятностью 95% —
Е95% = E + 2 * СКО
Еще больше информации можно найти у Архипенкова тут
