Оценка трудоёмкости — важный шаг при решении задачи. Чаще всего она требуется для определения бюджета и срока проекта. Мы регулярно сталкиваемся с пожеланиями снизить оценки или повысить их точность. Но далеко не все понимают, что такое оценка трудоёмкости и что с ней реально можно сделать.
6370 просмотров
Привет. Меня зовут Максим Никитцов, я занимаюсь управлением проектами в SmartHead. Мы хотим поделиться нашим опытом оценки трудоёмкости и реагирования на типовые ситуации, которые возникают в процессе их обсуждения. Из этой статьи вы узнаете:
- Что такое оценка и точность. При чём тут вероятность.
- Как повысить точность оценки.
- Как снизить оценку.
- Какая связь между оценкой трудоёмкости и стоимостью работ. Спойлер: не всё так очевидно. Не нужно путать оценки трудоёмкости и стоимости решения. Они необязательно должны быть связаны линейно.
И в конце сделаем выводы.
Здесь не будет разбора методологий оценки и рекомендаций, как оценивать конкретные задачи или проекты целиком. Это заметки о том, что означает оценка и что с ней можно сделать.
решение задач по ГЭСН определение трудоемкости
В контексте этой статьи термины «задача» и «проект» стоит понимать одинаково. А «инженер» — это исполнитель задачи (разработчик, дизайнер, инженер инфраструктуры).
Оценка трудоёмкости и её точность
Оценка — это предположение о возможной трудоёмкости решения задачи. Это всегда вероятностная величина. Она показывает некий диапазон трудоёмкости, в который с достаточной вероятностью уложится решение задачи. Чем он уже, тем выше точность оценки. Обычно градация точности следующая:
- грубые оценки (+/-50%),
- средней точности (+/-30%),
- точные (+/-10%).
При этом люди оценивают трудоёмкость чаще всего позитивно и недооценивают риски. Поэтому более приближены к реальности несимметричные диапазоны:
- -25+75% для грубой оценки,
- -20+40% для средней точности,
- -5+15% для точной оценки.
Немного теории
Этот раздел можно пропустить при наличии аллергии на математику и перейти сразу к вопросу, как обычно оценивают трудоёмкость. Но лично мне разбор матчасти помогает понять принципы предметной области.
Оценка — это вероятная характеристика. Она подчиняется нормальному закону распределения. Например, из википедии:
Вероятность попадания в диапазон среднего отклонения (+/- σ) составляет 68%. Вероятность 95% уже относится к диапазону +/- 2σ. Чем шире диапазон, тем выше вероятность в него уложиться, и наоборот. Вопрос только в величине отклонения, который зависит от разброса пессимистичной и оптимистичной оценок. Другими словами отклонение отражает риски и неопределённость задачи.
Диапазон оценки можно рассчитать, используя метод оценки по трём точкам и бета-распределение (формулы, если интересно). Например, имеем следующую оценку задачи от эксперта:
- Наиболее реалистичная: 100 часов.
- Пессимистичная: 125 часов.
- Оптимистичная: 90 часов.
Тогда с вероятностью 0.9 (90%) удастся уложиться в диапазон 93-112 часов. Это достаточно вероятно, но не на 100%.
Производительность труда. Трудозатраты. Трудоемкость
Как обычно оценивают трудоёмкость
Самый распространённый способ — экспертный. Трудоёмкость задачи должен оценить специалист (эксперт), который понимает, как её сделать — получить результат, удовлетворяющий цели. Он знает технологию и владеет соответствующими навыками. Оценку должен давать тот, кто будет решать задачу. Неправильно ожидать и требовать от специалистов попадания в чужие оценки, особенно в оценки более опытных специалистов.
Иногда на вдумчивую экспертную оценку нет времени или давать её пока не нужно. Например, при проверке гипотез и оценке бюджета на разработку продукта в порядках: миллионы или десятки. В таком случае можно давать быстрые оценки по аналогии. Они основаны на опыте конкретных людей, которые делали подобные проекты и могут переложить этот опыт на текущую задачу.
Такая оценка всегда грубая. Быструю оценку по аналогии может дать даже опытный руководитель проекта, и она также будет достоверной в границах грубой оценки.
«Плюс-минус» в оценке откладывается от наиболее реалистичной оценки. Диапазон зависит от начальной неопределённости требований и способа решения задачи. Думая о ширине диапазона, нужно поработать с рисками: выявить основные и решить, что с ними делать.
Оценка — это предположение. Даже самые точные оценки — это вероятностная характеристика задачи. Если нужно зафиксировать затраты до начала работы по модели fixed price, мы можем заложить в бюджет резервы на риски и зафиксировать именно стоимость работ, а не сделать оценку трудоёмкости с точностью 100%.
Как преподносить оценку
- Диапазоном. Чем более грубая оценка, тем шире диапазон.
- Одним значением с оговоркой, какой точности оценка.
Комбинировать эти варианты не стоит. Странно будет выглядеть оценка в виде 80-100 часов с точностью -10+25%. На самом деле это либо 70-125 часов, либо 98 часов при условии, что оценка средней точности (+/-30%).
4. Определение трудоемкости разработки программного продукта
Величина трудоемкости разработки программного продукта в человеко-месяцах ЧМ зависит от многих факторов, которые могут изменять их в различных направлениях. Наибольшее влияние на них оказывает объем программного продукта (число исходных команд), который из всех параметров изменяется в самом широком диапазоне и в современных разработках варьируется на три-четыре порядка.
Термин “объем программного продукта” охватывает все команды, разработанные в ходе проектирования и переработанные в машинный код с помощью процессоров, компиляторов и ассемблеров. Команды определяются как кодовые строки. Поэтому строка содержащая два и большее число исходных операторов, считается одной командой, а пяти-строчное описание команды — пятью командами.
Поэтому при оценке непосредственных затрат и длительности полного цикла разработки сложных программных продуктов, объем программ используется в качестве базового доминирующего параметра. Остальные факторы можно отражать поправочными коэффициентами.
Зависимость затрат труда в человеко-месяцах ЧМ от численного, выраженного в тысячах исходных команд (КЧИК) размера программного изделия, и скорректированная рядом поправочных коэффициентов, представляется следующим образом [1]:
, (2)
где КЧИК – число исходных команда в тысячах;
–коэффициенты изменения трудоемкости.
Коэффициенты отражают изменение трудоемкости непосредственной разработки строки текста программы за весь цикл создания программного продукта при воздействии ij фактора.
5. Факторы, влияющие на трудоемкость разработки программного продукта
В ранних исследованиях, проведенных в 60-х годах, было рассмотрено 104 различных фактора, каждый из которых до некоторой степени влияет на трудоемкость программной разработки. В результате проведенного анализа факторов, используемых в конструктивной модели стоимости [1], а также в [2,3], было получено 12 стоимостных атрибутов, объединенных в четыре группы.
- Атрибуты создаваемого программного продукта:
- ТНПП – требуемая надежность программного продукта;
- СПП – сложность программного продукта;
- МК – мобильность (переносимость) использования компонент программного продукта для других разработок;
Каждому из указанных стоимостных атрибутов соответствует коэффициент характеризующий влияние атрибута на программную разработку 
. Эти коэффициенты используются в качестве множителей в (2) при определении трудоемкости разработки программного продукта. Рассмотрим каждый из стоимостных атрибутов подробнее.
- Требуемая надежность программного продукта (ТНПП).
Является наиболее важным фактором, отражающим качество программного продукта. Для систем реального времени, в качестве параметра, характеризующего надежность системы, наиболее широко используется наработка на отказ Тн. Зависимость C11 от Тн можно увидеть на рис. 2 или вычислить по формуле [2]: 
(3) Р
ис.2. Коэффициент изменения трудоемкостиC11 в зависимости от наработки на отказ Тн 1.2. Сложность программного продукта (СПП). Наиболее активно в качестве показателя сложности используется объем программ, выраженных в числе исходных команд. По мере увеличения объема программ возрастает трудоемкость на разработку каждой очередной команды в программе. Зависимость изменения стоимостного коэффициента данного фактора от объема программ нелинейна, и высчитывается по формуле [2]: 
| Фактор трудоемкости | Коэффициент для рейтингов | ||||
| очень низкий | низкий | Номинальный | высокий | очень высокий | |
| ТНПП | Незначительные ограничения | Небольшие, легко восстанавливаемые потери | Умеренные, восстанавливаемые потери | Большие финансовые потери | Риск для человеческой жизни |
| СПП | КЧИК < 5 | 5 | 10 | 50 | КЧИК >= 100 |
| МК | Часть функций системы вынесены в отдельные библиотеки (DLL) | В проекте существуют объектыCOM. | Все объекты системы построены на основеCOM-технологии | ||
| ОБД | Требуется не более 50% имеющегося быстродействия | Требуется не более 70% имеющегося быстродействия | Требуется не более 85% имеющегося быстродействия | ||
| ОП | Требуется не более 50% имеющейся оперативной памяти | Требуется не более 70% имеющейся оперативной памяти | Требуется не более 85% имеющейся оперативной памяти | ||
| КА | Опыт работы в данной предметной области | Опыт работы в данной предметной области12 мес. | Опыт работы в данной предметной области36 мес. | Опыт работы в данной предметной области72 мес. | Опыт работы в данной предметной области144 мес. |
| КП | Опыт работы15 | Опыт работы4 мес. | Опыт работы12 мес. | Опыт работы36 мес. | Опыт работы> 36 мес. |
| КЗ | Отсутствует опыт заказов, незнаком с предметной областью | Отсутствует опыт заказов, мало знаком с предметной областью | Специалист в своей предметной области, отсутствует опыт заказов | Есть некоторый опыт заказов, знаком с предметной областью | Большой опыт заказов, высокая квалификация в предметной области, четко определена цель разработки |
| ПСМ | Отсутствие | Начальное | Некоторое | Широкое | Обязательное |
| ИИС | Отсутствие каких-либо инструментальных средств | Простейшие инструментальные средства | Инструментальные средства программирования и отладки среднего уровня | Мощные инструментальные средства программирования и отладки | Мощные инструментальные средства программирования и отладки, а так же инструментальные средства анализа, проектирования и документирования |
| ОСР, % от ном. сроков | 75 | 85 | 100 | 130 | 160 |
К
ак видно из формулы данный коэффициент следует учитывать при объеме программ, превышающем 1000 исходных команд. График изменения данного стоимостного коэффициента представлен на рис. 3. Рис.3. Коэффициент изменения трудоемкости C12 в зависимости от объема программного продукта
- Мобильность использования компонент программного продукта для других разработок (МК).
Данный фактор имеет место, если в программный продукт необходимо проектировать как комплекс автономных модулей. Например, создание элементов ActiveX, OLE-объектов, позволяющих впоследствии использовать данные объекты многократно в данном проекте, а также в других. При этом трудоемкость разработки проекта возрастает приблизительно пропорционально предполагаемой доле многократно используемых компонент. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (табл. 3).
- Квалификация аналитика (КА).
На сегодняшний день отсутствуют апробированные методы надежного измерения квалификации специалистов. Данный фактор приближенно может оцениваться продолжительностью работы аналитика по данной тематике, однако это не учитывает его индивидуальных особенностей. При наличии опыта работы в данной области от 1 до 15 лет производительность труда может повышаться в 1,5..3 раза. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (табл. 3).
- Квалификация программиста (КП).
При создании программных продуктов опыт применения методов, средств и всего технологического процесса отражает квалификация программиста. После 2-3 лет работы в наибольшей степени проявляются индивидуальные особенности программистов, их творческие способности, тщательность в работе, рациональное использование средств автоматизации. Для опытных специалистов переход на новый язык программирования обычно не требует особых усилий и успешно проходит за несколько месяцев. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (табл. 3).
- Квалификация заказчика (КЗ).
При испытаниях программного продукта заказчик зачастую обнаруживает, что решаются не совсем те задачи и не совсем так как нужно, вследствие чего необходима переработка готовых программ. Даже весьма квалифицированные заказчики вынуждены иногда корректировать ТЗ на любых этапах разработки, что влияет в среднем на снижение производительности труда разработчиков на 10..20 %. В предельных случаях неоднократное корректирование задания может привести к увеличению затрат даже в 3..5 раз.
- Применение современных методов разработки программного продукта (ПСМ).
Опыт крупных разработок позволил выделить наиболее широко и эффективно применяемые современные методы:
- использование современных методологий анализа и проектирования программных продуктов (ARIS, ERD, RAD и т.д.)
- использование современных методов программирования – объектно-ориентированное программирование, структурное программирование
Большинство из приведенных методов применяются в совокупности с другими, что не позволяет оценивать отдельно эффективность каждого из них. Интегральные оценки эффективности совокупности методов более стабильны и отражают повышение производительности труда приблизительно на 50 %. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (табл. 3).
- Использование инструментальных средств (ИИС).
Использование инструментальных средств при проектировании программных продуктов (CASE-системы) и программировании (визуальное компонентное программирование) позволяют повысить производительность труда. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (таблица 3).
- Ограничение сроков разработки (ОСР).
В конструктивной модели стоимости [1] срок разработки оценивается по следующей формуле: 
, (6) где ЧМ – трудоемкость проекта в человеко-месяцах. Уменьшение сроков разработки проекта (2) ведет к увеличению трудоемкости разработки примерно на 10-20%. Также и увеличение этих сроков ведет к увеличению трудоемкости из-за простоев аппаратных и программных средств разработки, а также из-за неэффективной работы разработчиков. Численное значение стоимостного коэффициента определяется с помощью шкалы рейтингов (табл. 3). Приближенные значения стоимостных коэффициентов вышеперечисленных факторов, влияющих на трудоемкость разработки, приведены в табл. 2. Основная же шкала рейтингов по каждому фактору поясняется в табл. 3. Таблица 2. Численные значения стоимостных коэффициентов
| Коэффициент | Фактор трудоемкости | Коэффициент для рейтингов | ||||
| очень низкий | низкий | номинальный | высокий | очень высокий | ||
| C11 | ТНПП | 0,75 | 0,88 | 7 | 1,15 | 1,4 |
| C12 | СПП | 0,43 | 0,87 | 1 | 1,69 | 2-3 |
| C13 | РБД | 0,94 | 1 | 1,08 | 1,16 | |
| C14 | МК | 1 | 1,15 | 1,53 | ||
| C21 | ОБД | 1 | 1,67 | 3,33 | ||
| C22 | ОП | 1 | 1,67 | 3,33 | ||
| C31 | КА | 1,46 | 1,19 | 1 | 0,86 | 0,71 |
| C32 | КП | 1,42 | 1,17 | 1 | 0,86 | 0,7 |
| C33 | КЗ | 1,23 | 1,11 | 1 | 0,91 | 0,85 |
| C41 | ПСМ | 1,24 | 1,1 | 1 | 0,91 | 0,82 |
| C42 | ИИС | 1,24 | 1,1 | 1 | 0,91 | 0,83 |
| C43 | ОСР | 1,23 | 1,08 | 1 | 1,04 | 1,1 |
Источник: studfile.net
Оценка трудозатрат в разработке ПО для начинающих
Оценка временных затрат при разработке ПО может быть сложной задачей, но есть несколько хитростей, которые помогут получить точные цифры.
Помню, как меня впервые попросили дать оценку…
Тогда это застало врасплох.
Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.
Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.
И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»
Я не знал, что сказать, — меня к этому не готовили. Мне не сказали, что на этой встрече нужно будет давать оценку — я думал, меня позвали поприсутствовать, чтобы я чему-то научился.
И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.
Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа — без понятия, для чего, но точно не для этой оценки.
Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»
Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.
Не очень люблю вспоминать тот день.
Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?
Цель проведения оценки
Прежде чем приступать к оценке, нужно понять, для чего она будет использоваться. Вы сообщите цифры начальнику или вышестоящему руководству — и что будет дальше?
Оценка объема работы используется в основном в двух целях:
- Планирование.
- Выставление счета клиенту.
Планирование
Старшие менеджеры, директора и вице-президенты компании заинтересованы в том, чтобы работа шла и выполнялась в срок. Им нужно знать, что и к какому времени будет сделано — а для этого нужна оценка того, сколько времени уйдет на проект.
Они знают, какой объем работы какая группа разработчиков может на себя взять в месяц, квартал и год. И чтобы обеспечить занятость сотрудников, руководству нужно составить график работы над проектами. Данная вами оценка и поможет в таком планировании загрузки.
Допустим, в вашей команде разработчиков три человека. Каждый работает по 40 часов в неделю — это примерно 160 часов в месяц, или 480 часов в квартал (на троих — примерно 1500 часов).
Представьте, что ваша команда должна выполнить пять проектов — с оценками объемов работ 800, 400, 300, 200 и 50 часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки — на случай, если разработка займет больше времени, чем предполагалось.
С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50 часов, и при этом осталась бы некоторая свобода для маневра.
Выставление счета клиенту
Разработка программного обеспечения — это бизнес, цель которого — зарабатывать. Если клиент хочет, чтобы для него был выполнен индивидуальный проект, и он готов за это платить, ваша оценка поможет определить соответствующую стоимость.
Вам передают требования, вы говорите, сколько времени потребуется на разработку, отдел продаж переводит время в денежную сумму и сообщает ее клиенту, который после этого решает, стоит ли желаемое таких затрат.
Примечание. Это применимо не ко всем компаниям — разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.
Ключевые факторы при оценке
Теперь, когда вы знаете, для чего вообще нужна оценка, пришло время выяснить, как ее проводить. Когда в следующий раз кто-нибудь спросит, сколько времени потребуется на разработку чего-либо, помните о следующих пяти ключевых факторах.
1. Не оценивайте, сколько времени понадобится ВАМ
Первые два года своей карьеры в качестве «оценщика» я постоянно пытался определить, сколько времени на разработку ушло бы у меня — но спрашивают-то не об этом.
Помните, что вы даете оценку с учетом продуктивности команды разработчиков. Не нужно думать, что те, кто будет этим заниматься, знают предметную область так же, как вы. Добавьте небольшой запас, чтобы они могли изучить кодовую базу и новую область знаний.
Часто полезным будет предположить, что работу будет выполнять самый неопытный в команде.
2. Не занижайте — завышайте
Помните, что в первую очередь оценка делается для планирования. Поэтому не нужно давать цифры, которые, по вашему мнению, могут быть превышены.
Если разработчики выйдут за отведенный вами срок, это нарушит график работ.
Находиться в границах 20% — это нормально, но только если оценка оказалась завышена — а не занижена.
К какой бы цифре вы ни пришли, добавьте к ней 20%: задачи обычно оказываются сложнее в реализации, чем кажется.
3. Повышение квалификации
Потребуется ли команде для выполнения проекта изучать что-то новое? Например, если вы обычно разрабатываете приложения для «толстых» клиентов, а новый проект — это создание веб-страницы.
Если есть компоненты, требующие приобретения новых навыков (повышение квалификации), учтите это и в оценке. Дайте команде время изучить все тонкости новых шаблонов, языков, фреймворков и т. д. — это всё равно придется делать, поэтому время на обучение нужно заложить в оценку.
4. Примеры аналогичных проектов
Проще всего давать оценку проектам, основанным на уже привычных для команды шаблонах.
Если у команды имеется некий опорный материал в виде ранее разработанного ПО, то объем работы может значительно снизиться. Разработчикам проще действовать по принципу «копировать, вставить, заменить», и это отражается на скорости выполнения задач.
Обязательно подумайте, делали ли что-то подобное в этой компании раньше. Если у вас есть специалисты, которые занимались такого рода проектами, проконсультируйтесь с ними при оценке и обязательно используйте их код в качестве вспомогательного при разработке.
5. Не забывайте об аналитиках
Часто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.
В этом случае дать оценку только по разработчиками будет мало — нужно учесть, что бизнес-аналитикам придется писать документацию, делать пользовательские истории и руководить обзорами спринтов.
Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.
Чтобы научиться давать оценку объему работу, нужно время. Этот навык, как и любой другой, требует практики.
Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.
Если резюмировать самое главное, запомните вот что:
задача всегда сложнее, чем кажется, и лучше переоценить объем работ, чем недооценить.
Никто не будет злиться, если у вас всё пойдет по плану, — начальство даже порадуется! И при этом у вас останется больше времени на другие проекты.
Так что не стесняйтесь выделять побольше времени и помните, что оценка — это всего лишь оценка.
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.