Миф о человеко-часах, или вновь про оценку трудозатрат.
Вы когда-нибудь задумывались, что есть рабочий день у программистов, профессия которых, IMHO, тесно сопряжена с творчеством и наукой? Сколько часов в день, скажем, человек действительно созидает нечто осязаемое, а сколько времени обдумывает идею или изучает новые техники? А ещё вопрос – сколько этот человек тратит в день на себя, а именно, “кофейные” сплетни, всякие youtube, facebook и смежное, если есть выход в интернет?
Формула.
По личному опыту многих проектов на которых я участвовал во всевозможных ролях: менеджер/координатор, архитектор, технический лидер, разработчик, консультант, и по доверию к литературным источникам, рабочий день программиста делился ( или должен был делиться) в соответствии с таким алгоритмом:
Tcreative = 8h*Kmaturity – Tego – Tnoise,
Где:
Tcreative - это время созидания: исходный код, тесты, документация; при этом стоит учтывать, что в это врямя входят активности сопряженные фазе созидания , такие как проверка созданных артефактов, обсуждение поставки, обдумывание задачи, поиск решенияили само-образование, направленное на текущую проблему или комплекс проблем.
Kmaturity – это коэффициент опыта программиста в условиях этого проекта, или задач. Вариации от самых слабых разрабочиков (0.5+), до матерых профессионалов (1.0+)
Tego - это время, которое тратит программист на себя.
Tnoise - как бы это не звучало, но это то время, которое тратится на “шум”, включая: проектные совещания(!), обсуждения чего-либо в команде (прямо-пропорциональная зависимость), и иные переговоры по проекту, не сфокусированные на область созидания для программиста.
Делаем выводы.
Программистам, посвящается -
- Отвечая на вопрос “сколько времени тебе требуется на…”, учитывать такую формулу, и аргументированно отстаивать грамотные сроки перед своими начальниками.
- Обращаясь к сознательным, которые расширяют рабочий день в офисе чтобы успеть и >Tcreative сделать и Tego уделить. Необходимо сокращать время Tego до минимума, не позволяя себе пересиживать в офисе больше 8-9h в день, если того не требует ситуация, но о выгорании ресурсов человека – в отдельной статье.
- Обращаясь к тем, кто не верит в формулу – мы то все видим
Менеджерам, посвящается -
- Принимайте во внимание то, какие люди с вами работают – “хирурги” или “ассистенты” (см (1975). The Mythical Man-Month. Addison-Wesley. ISBN0-201-00650-2.) и учитывайте среднее значение Kmaturity.
- Учитывайте, что чем больше команда, тем больше “шума” в коллективе и тем, собственно, меньше работает конкретный человек. Для классических методик я советую учитывать 10% шум в день, в agile проектах это время равняется 3-5%
- При постановке задач и утверждении сроков поставки, учтите эго команды и также включите доп время в длительность проекта. Минимальное время на эго – 20% в день!
- Влиять сторонне можно и нужно на сокращение Tnoise до минимума (убрать ненужные совещания, разбить команду на подгруппы) и увеличение Kmaturity до максимума (тренинги, парное программирование).
- Увы и ах, но влиять на Tego невозможно. И тут остается только следить или за синдромом пересиживания или искоренять лодырей из проектов.
Соответственно,
- Самое главное, прописанное в миллионах книг, статей, и проверенное мною не раз, правило утрвеждает, что люди – это нелинейный механизм, и нельзя планировать проектные сроки оперируя терминами “человеко- час/месяц/год” или, проще говоря, - люди не работают по 8 часов в день.
- Длительность проекта или возможности итерации в agile средах, зависит от реального трудодня человека, которое равнозначно, в среднем, 6-7 часам или 80% коэффициенту для подсчёта team velocity в спринтах.
Пользуйтесь.
