Нормирование разработки программного обеспечения: обзор подходов
В статье приводится обзор некоторых подходов к нормированию труда, которые могут быть полезными для занимающихся нормированием труда при разработке ПО.
Реакция большинства представителей ИТ-индустрии на попытки нормировать труд разработчиков программного обеспечения, как правило, - резко негативная. Основным аргументом в пользу такой оценки называется большой объем часто меняющихся творческих задач, что существенно затрудняет разработку норм труда. Однако такие утверждения можно назвать справедливыми лишь отчасти, и на конкретных примерах мы покажем, что находить сравнительно простые и эффективные способы определения норм труда при производстве программного обеспечения нам с вами вполне по силам. И держим в голове, что аналогичные задачи успешно решаются нормировщиками для других многих отраслей деятельности, связанных с интеллектуальным трудом - от проектно-конструкторской и оценочной до финансово-инвестиционной и юридической.
Не будем здесь рассматривать специально труд системных администраторов и специалистов технической поддержки. Тем более что на данную тему проведено много качественных исследований (см. например «Возможности для нормирования труда отдела ИТ»). Значительный (примерно 70%-80%) объем их работы – рутинные операции, поддающиеся регистрации, формализованному описанию и измерению. Их трудоемкость проще всего рассчитать с использованием существующих норм (на постсоветском пространстве наиболее актуальными являются «Нормы времени на работы по обслуживанию персональных электронно-вычислительных машин, организационной техники и офисного оборудования», утвержденные Постановлением Министерства труда и социальной защиты Республики Беларусь от 23.03.2011 № 19). Отражённые в них операции можно уточнить / подтвердить, а отсутствующие - выявить дополнительными исследованиями затрат времени прямо «на местах» (фотография рабочего времени (ФРВ), хронометражные замеры и т.д.). Этими же методами можно определить также примерный объем нетипичных задач, как и фактический баланс рабочего времени работников в целом.
Разработчики ПО – дело другое. Их работа более разнообразна и зависима от большего числа факторов. Но и здесь есть серьезные заделы в части нормирования труда, среди которых можно отдельно выделить[1]:
– модели COCОMO и COCOMO—II (метод расчета трудозатрат на основе количества строк кода), которые целесообразно применять при наличии сложных проектов разработки;
– Укрупненные нормы затрат труда на разработку программного обеспечения (далее — Укрупненные нормы) – опять же результат основательных работ, проведенных в Белоруссии (Постановление Министерства труда и социальной защиты Республики Беларусь от 27.06.2007 № 91. Об утверждении укрупненных норм затрат труда на разработку программного обеспечения.
В этих документах все основательно проработано, а на основе Укрупненных норм при разумных трудозатратах вполне можно сделать калькулятор трудоемкости разработки ПО с разбивкой по стадиям согласно ГОСТам Единой системы программной документации:
- техническое задание;
- эскизный проект;
- технический проект;
- рабочий проект;
- ввод в действие.
Подробный разбор модели COCOMO II приведен здесь, Укрупненных норм - здесь.
Однако применение и COCОMO, и Укрупненных норм требует не только глубокой погруженности нормировщика в процесс разработки ПО и в особенности языков программирования, но и существенных трудозатрат на анализ ПО методом функциональных точек. Кроме того, эти подходы применимы только для случаев разработки нового ПО и проведения доработок. Их «слепые зоны» – внедрение коробочного решения и устранение дефектов ПО. Конечно, для заполнения этих пробелов можно использовать и экспертный метод определения норм труда. Но зачастую это неоправданно затрудняет нормирование, да и оспорить результаты таких работ - намного проще из-за субъективности оценок трудозатрат.
В ряде случаев выходом может стать нормирование труда на основе статистики JIRA или другой аналогичной Системы отслеживания ошибок (Продолжение следует).
[1] Включая, но не ограничиваясь
