Войти в систему
Войти с помощью соц. сетей:
Обычно трудозатраты по работам в консалтинговых проектах по внедрению ERP-систем оцениваются в человеко-часах работы специалистов над задачами, часы суммируются в рабочие дни, дни в недели, недели в месяцы итоговых сроков проекта. Рассмотрим подробнее, что собой представляет человеко-час и сколько их может предоставить специалист, участвующий в проекте.
Данный раздел книги назван по мотивам известной и рекомендуемой к самостоятельному изучению книги «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering). Книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения (на основе опыта IBM OS/360) впервые была опубликована в 1975 году. В 1995 году было добавлено несколько новых глав, актуализирующих книгу.
Современный мир повысил темпы создания новых продуктов и технологий, поэтому счет сегодня логично вести на часы, тем более мы оцениваем бюджет в человеко-часах, пусть и в сотнях или тысячах. Но выводы книги для нас очень интересны, и они реально работают на практике, какими бы удивительными ни казались заключения автора на первый взгляд.
Фредерик Брукс сделал вывод: «Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере, по двум причинам:
Если есть N специалистов, то количество пар специалистов (для взаимодействия между собой, в нашем случае «консультант – разработчик») равно N(N–1)/2, то есть с ростом числа участников проекта затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N рост числа участников проектной команды замедляет выполнение проекта».
Фактический пример из реальной оценки одной проектной задачи. Есть задача на 320 ч, один разработчик делает ее за 8 недель. Привлекаем второго разработчика, задача делается за 4 недели (линейный прирост). Далее привлекаем еще специалиста, результат уже не кратный, а те же 3–4 недели. А если добавить сюда еще кого-то (явно лишнего), то срок будет такой же (3-4 недели, если не будет мешать работать остальным своим желанием «помочь») или увеличится до 6–8 недель, т. к. время на коммуникацию всех со всеми начнет расти в ущерб самой задаче.
Если сроки сорваны, наем новых специалистов замедляет выполнение проекта по причине того, что новичкам требуется время на изучение текущего состояния задач, подходов к разработке. В книге сформулирован закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше».
В примере, что был рассмотрен выше, где 1 специалист делал задачу за 8 недель, предположим, что он уже потратил 4 недели, 4 остается, но очень хочется ускорить процесс за счет привлечения дополнительных сил. Добавим еще одного специалиста – в идеале можно было бы поделить оставшиеся 4 недели на два, но фактически экономия будет где-то 1 неделя, т. к. половину времени новый специалист будет «въезжать» в задачу, а тут еще и 50-процентная готовность, чужой код... А если привлечь двух специалистов в помощь? Тогда срок будет 9+ недель, то есть вырастет! Срок не изменится, если эти новые специалисты не будут мешать первому и он продолжит делать все сам, но если задачи поделить и «ускорять», то будут накладные расходы на интеграцию наработок и коммуникацию.
При очень большом числе специалистов проект может быть вообще никогда не закончен: из-за общей неразберихи попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается.
Можно привести любимую руководителями проектов цитату, когда нужно это все обосновать в одном предложении: «Даже если собрать вместе 9 беременных женщин, то ребенок через месяц не родится».
Какой вывод можно сделать из рассмотренных тезисов? При планировании сроков работ нельзя просто делить итоговое число часов трудозатрат, полученное по оценкам пунктов ИСР, на число специалистов и их часы работы. Срок должен учитывать последовательность задач и их возможную декомпозицию на подзадачи.
В своей книге Фредерик Брукс приводит также 2 способа снизить стоимость разработки программного обеспечения:
Эти тезисы актуальны и для процесса внедрения ERP-системы: на начальном этапе команда проекта должна быть разумной, а не максимальной, участники добавляются и убираются по необходимости в зависимости от задач на разных фазах проекта (см. рис. 5.1 – график привлекаемых специалистов). Предполагается, что у исполнителя этот проект – не единственный источник доходов и специалисты могут переключаться на задачи других проектов на время простоя, например в процессе согласования. На практике это не всегда так, иногда команда выделяется сразу и содержится за счет именно этого проекта.
Второй тезис для проекта внедрения – это возможность закрыть какие-то потребности готовыми отраслевыми решениями или отчуждаемыми функциональными блоками, которые могут встраиваться в выбранную ERP-систему. Стоимость этих блоков может быть значительной, но расчеты трудозатрат на разработку, отладку и запуск в эксплуатацию, а главное, сроки на все это могут говорить в пользу приобретения готового решения.
Давайте рассмотрим еще один интересный вопрос: сколько же «мифических» человеко-часов может «выдать» в месяц условный специалист?
Тут нужно учесть, сколько сотрудник реально работает часов в средний месяц условного года с учетом больничных, отпусков и других факторов.
Обычный расчет говорит нам, что 8 ч в день, 5 дней в неделю дают 40 ч в неделю. Что при 20 рабочих днях в месяц дает 160 ч, а при 23 рабочих днях – уже 184 ч. Но в среднем по году в месяце что получится?
Учтем факторы: отпуск сотрудника 4 недели, болезни условные 2 недели в год – это минус 240 ч в год, еще есть множество государственных праздников (минус еще 2 недели в году). Получается, из 52 недель в календарном году реально рабочие у сотрудника 44 недели, это 1760 ч. Делим на 12 месяцев, получаем 146 часов в условный месяц.
Именно эти 146 часов в месяц нужно планировать на проектах более 6 месяцев длительностью. Относительно 160 и 184 ч (для 20 и 23 рабочих дней в месяце) получаем разницу почти в 10 % и 20 % соответственно. Сверхурочное время и переработки (overtime) будут запасом на случаи форс-мажоров и обычно оптимистичных оценок проектов. Если же на это «святое» время закладываться сразу, то это заведомый срыв сроков или снижение качества, т. к. в режиме аврала специалисты долго в приемлемом качестве работать не смогут.
Эти условные 146 ч. в условный месяц и есть наши искомые «мифические человеко-часы», которые мы в следующем разделе будем учитывать в расчете себестоимости человеко-часа по годовому бюджету расходов.
Еще одним важным фактором в учете человеко-часов является доля участия того или иного специалиста.
Если в известной сказке «В стране невыученных уроков» ответ для математической задачи «полтора землекопа» был явно неверным, то вот в консалтинге 1,5 разработчика или 2,5 консультанта – это нормальное дело. Может встретиться даже 0,25 системного архитектора.
Долевое участие в проекте для специалистов применяется при наличии в компании-исполнителе других проектов и задач. Оно позволяет рассчитать для заказчика приемлемый бюджет проекта за счет более точного распределения работ по специалистам (привлечение их по мере необходимости на разных фазах проекта). Если же вся работа для команды проекта предполагается как единственный монопроект, то там предполагается 100-процентное участие всех – возможно, в разных ролях на разных фазах проекта. При этом нужно понимать, что на ранних стадиях проекта всем специалистам просто нет задач (нечего разрабатывать разработчикам, пока нет утвержденных технических заданий, нечего тестировать, пока что-то не разработано и т. п.).
Руководитель проекта со стороны заказчика должен понимать потребность в специалистах и загрузку всех специалистов исполнителя на всех фазах проекта и логику расчета бюджета (из трудозатрат всех участников), т. к. желание компании-исполнителя включить в проект содержание проектной команды в режиме «простоя» понятно, но и желание не переплачивать за это у заказчика тоже понятно.
Войти с помощью соц. сетей: