Как стать автором
Обновить

Комментарии 13

Если говорить про it, то несмотря на все человеко-часы, все равно при согласовании стоимости у обоих сторон уже есть в голове какое-то видение стоимости. А норомо или человеко-часы просто помогают придать некоторую видимость ее обоснованности.

Да, обычно когда заказчик предлагает проект уже есть некие бюджетные рамки, в которые нужно постараться уложиться, но бывает и такое что бюджет требует увеличения и здесь без обоснования человеко-часами уже не обойтись.

Как правило, в кошельке заказчика ограниченный бюджет, а в голове - желание решить все проблемы за эти деньги. Однако, IMHO, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога.
Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис.
Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию.
Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.

Как видит работу и стоимость заказчик и исполнитель - холиварная тема. Я бываю с обеих сторон. И даже не хочу ее начинать.

В рамках темы статьи я просто хотел сказать что все эти расчеты не более как способ чем-то обосновать стоимость работы. Хотя по факту все услуговые цены - договорные из разряда «согласен» - «не согласен».

Просто психологически труднее расставаться с деньгами без какого то формального подтверждения обоснованности стоимости. Вот и все.

Мой опыт строителя говорит что это все от Лукавого =)

Трудоемкость первый раз оценивается укрупненно и формально. Можно условно назвать ее "инвестиционная трудоемкость" просто грубая оценка человеческих ресурсов и грубая прикидка затрат ресурсов. После согласования ТЗ и проекта формируется уточненный график производства работ, который с реальностью опять же бьется слабо, кроме некоторых принципиальных моментов, зато задает лимиты времени.

Еще трудоемкость учитывают при расчете ФОТ и зарплаты, но в контексте табеля, с натягиванием на него налогов и, в некоторых случаях, сделки.

Проблема в том, что люди не роботы, а значит и человеко-часы один из инструментов детализации расчетов при планировании, который нужно использовать совместно с другими инструментами.

>Мой опыт строителя говорит что это все от Лукавого =)
Мой тоже. И в целом статья ничего путного не содержит. Обычные банальности, причем не новые. Можно подумать, кто кто-то из использующих человеко-день в работе не знает, что неделя или месяц не получается из дня путем простого умножения на константу? Это смешно. Что месяцы в году разные по числу рабочих дней — знает любой, кто брал отпуск.

Согласен что необходимо использовать и другие инструменты планирования.

Что это и зачем оно здесь? Абсолютное отсутствие полезной информации.
Лучше прочитать оригинал, на который ссылается автор.

Да, рекомендую прочитать Фредерик Брукса «Мифический человеко-месяц» начинающим менеджерам проектов. Будет очень полезно. Эта статья лишь делает краткий обзор по проблеме человеко-часа.

Один из критериев оценки мной "качества" ИТ компании - это сколько человека часов у разработчика в сутках. Часто видел 8, как и время рабочего дня, что в корне не верно и для меня сигнал, что в компании не понимают базы и не любят точность. Я всегда считал для своей команды 6ч/день и 30 - неделя. Ёмкость спринта - кол-во человек * 2 недели минус отпуск (если есть). Ну и далее насыпайте в спринт задач примерно 2/3 ключевых и 1/3 мелких. И будет всем счастье)

В Agile/Scrum проектах правильнее использовать для оценок не человеко-час, а Story Points

Многие так и используют, но SP так или иначе коррелируют с часами. Так зачем измерять что-то ещё чем-то?

Меня на фрилансе всегда просят оценить в часах. Каждый час - плюс минус косарь для заказчика. 37 часов - соответственно 37 косарей.

Никогда не оперировали такими терминами как человеко-месяц и прочее.

Всегда, частному лицу, который работает с конкретным тобой важно знать, сколько конкретных косарей он должен потратить, чтобы получит хоть какой-нибудь результат.

И тут два варианта - либо для подрядчика это фикс цена, и сколько бы часов он не потратил на реализацию продукта - получит одну и туже сумму при каких бы то ни было трудозатратах.

Либо заказчик с тобой работает уже давно и понимает, что в ИТ невозможна точная оценка всего, а если бы и была возможна это наверняка бы существовал целый отдел аналитиков, и она бы уточнялась бы каждый день на протяжении всего срока жизни разработки.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий