Для наглядности, представим гипотетическую ситуацию, которую узнают многие менеджеры разработчиков программного обеспечения.
Совещание по текущему проекту. У нас работает разработчик Федор. Федор – ведущий инженер программист с солидным стажем. Мы ставим перед ним задачу Х. Выдав ему хорошо сформулированную постановку задачи, интересуемся, сколько необходимо времени, чтобы закодировать задачу Х?
Федор отвечает, что ему необходимо четыре часа, максимум - шесть. Мы резюмируем, что исходя из того, что завтра Федор начнет работать в девять часов утра, в шесть вечера мы уже включим задачу Х в завтрашнюю версию проекта. Федор соглашается с этим решением.
Наследующий день в 6 часов вечера Федор не готов. Ему надо еще два-три часа. Почему не готов, объяснить толком не может. Вопрос ''чем ты занимался весь день?!!'' повергает его в ярость. Выпуск версии проекта сорван, руководство разочаровано в Федоре…
Для анализа получившейся ситуации, проанализируем фотографию рабочего времени Федора:
Реализация задачи Х (4 часа)
10:00. Пришел на работу. Был приглашен на совещание по другому проекту в качестве консультанта.
11:00. Выпил кофе. Встретил Ивана, сходили на перекур.
11:15. Сел писать задачу Х.
12:30. Вынужденный простой из-за починки кондиционера, который расположен над рабочим местом.
13:00. Вызвали в бухгалтерию. Долго расспрашивали о документах со сложными аббревиатурами.
13:30. Обед.
14:30. Пришел с обеда, начал работать. Дописал почти все.
16:00. По указанию заместителя директора, снова приглашен на совещание.
17:00. Продолжил писать задачу Х.
18:15. Получил от руководителя выговор: ''Задача на полдня, а ты весь день с ней провозился, да еще и опоздал!''
Итак, причина срыва сроков понятна. Сколько времени Федор потратил на непосредственно написание кода? 15 минут + 1 час 30 минут + 1 час 15 минут. Итого – 3 часа! На осуществление его прямых обязанностей в нашем проекте у него было всего три часа вместо четырех, которые были ему нужны! И он справился гораздо раньше – он потратил меньше чем четыре часа! Его хвалить надо было, а не ругать! Теперь понятно, почему его взбесил вопрос ''чем ты занимался весь день?''
Он занимался работой. Просто КПД его деятельности был вынужденно низким. Не потому, что плох Федор. А потому, что продуктивность любого разработчика влияет на то, что называется ''коэффициентом мусорного времени''. В общем случае – это соотношение непроизводительных часов к производительным. В случае Федора – 5:3, что означает что для выполнения четырехчасовой задачи ему был необходим весь день и еще немного следующего. Если посмотреть на его результат, то мы увидим, что это вполне справедливо – Федя лихорадочно заканчивал дописывать свой код после того, как рабочий день кончился.
Многие полагают, что в их организации ''мусорного времени'' нет. ''Мусорное время'' есть всегда. У одних его больше, у других меньше. Статистика по двум десяткам компаний, показывает следующие значения ''коэффициента мусорного времени'':
а) Лучшие компании (две из 20):
- 1\7;
- 1\6,5;
б) Средние значения :
- 2\6;
- 3\5;
в) Худшая:
- 4\4.
Итак, лучше, сразу избавиться от иллюзии того, что ''мусорное время'' на проект не влияет.
А теперь самое интересное - как учесть влияние ''мусорного времени'' на проект?
Действовать в данном случае стоит в двух направлениях:
1. Учитывать ''коэффициент мусорного времени'' при планировании (обязательно).
2. Снижать ''коэффициент мусорного времени'' путем устранения источников мусора.
Давайте по порядку. Прежде всего – как учитывать коэффициент при планировании. Прежде чем учитывать, его надо определить. Определяется он элементарно просто: назначаем своим разработчикам несколько коротких и безрисковых, но осмысленных задач (при длинных или рискованных задачах начинают действовать факторы громоздкости или рисков, что нежелательно для ''чистоты эксперимента''). Лучше всего на роль таких задач подходят типовые задачи по имплементации стандартных функций (отображение данных, создание элементов и т.д.) При этом просим их сформулировать оценки в ''идеальных часах'' (сколько надо времени, если сесть и писать задачу от начала и до конца, и никто при этом не будет мешать, без включения просадки, и если не надо будет есть, курить и т.д.) После этого нажимаем кнопку секундомера и пусть все начинают. Сравниваем полученные фактические значения продолжительности с продолжительностью в идеальных часах. Теперь мы получили ''коэффициент мусорного времени''. Идеально это будет что-то вроде 1:7.
Итак, коэффициент есть. Теперь надо учесть при планировании. Самый простой способ сделать это – перейти от коэффициента к множителю, т.е. получить значение, на которое нужно умножить запланированную длительность проекта. В нашем случае для этого подойдет следующая формула:
Давайте рассмотрим действие формулы на примере. Предположим, у нас есть проект, чистая продолжительность которого (без учета влияния ''мусорного времени'') равна 10 дням. При этом в рабочем дне 8 часов. ''Коэффициент мусорного времени'' равен 1:7, то есть один час в день ''мусорный''.
Практика покажет: эта оценка была правильной. Важно другое – без учета этого фактора мы каждые 10 дней ''теряем'' один день. А если проект был длиной полгода, то по милости ''коэффициента мусорного времени'' мы потеряем 12 дней – отстанем более чем на две недели... Знакомо, не правда ли?
Этот метод вполне точен и годится для оценок. Еще более точным методом может стать использование статистического моделирования – например, с помощью метода, разработанного Томом де Марко и Тимом Листером для моделирования влияния рисков на проекты. Согласно этого метода, надо задать параметры проекта, внести новый риск непрерывного типа ''влияние мусорного времени'' и задать коэффициент его влияния согласно инструкции.
Но учет влияния мусорного времени – это, собственно, только половина дела. Мусорное время есть не что иное, как непроизводительные издержки, а с издержками в любой индустрии принято бороться.
Для сокращения непроизводственных издержек, предлагаю службе управления персоналом провести ряд мероприятий:
Определить наличие мусорного времени. Для этого необходимо проанализировать следующие виды деятельности на предприятии:
- административная деятельность поддерживающих служб предприятия. Наблюдался случай, как ведущего разработчика проекта несколько раз заставляли переделывать авансовый отчет, в то время как в переговорной находились представители заказчика. Стоит ли говорить, что такая ситуация недопустима. Не стоит забывать, что задачи административно-хозяйственной службы – обеспечивать производственную деятельность, а не мешать ей.
- бюрократическая деятельность, связанная с проектным делопроизводством. Другая бездонная пропасть, поедающая время. Зачем заполнять журнал учета рабочего времени с пятнадцатиминутной детализацией, если заказчик этого не требует? Зачем снабжать документ из одной страницы тремя страницами шапок, обязательных к заполнению? Примеров такого бездарного использования рабочего времени можно привести много. Здесь совет один: обходиться минимумом бумаги и даже при этом автоматизировать эту область деятельности по максимуму.
- рабочая обстановка самого офиса. Если люди начинают приходить на работу к восьми часам или уходить в час ночи – это верный признак того, что в офисе лучше всего работается, когда никого нет. При этом может мешать множество факторов – скученность, телефонные разговоры, громкие обсуждения, духота.
- личные интересы сотрудников. Возможно, кто-то удивиться, но достаточно много людей рассматривает работу как способ заниматься своими делами за чужой счет. Чаты, форумы, поиск фильмов и музыки, онлайновые знакомства – вот далеко не полный перечень развлечений в рабочее время. Конечно, не надо путать теплое с мягким – форумы могут способствовать профессиональному росту, коммуникаторы можно использовать для общения с коллегами из других городов – но во всем хороша мера.
Провести мероприятия по сокращению мусорного времени:
- разрешить разработчикам отвечать на все письма, не связанные напрямую с рабочей деятельностью, в конце рабочего дня. Данная рекомендация особенно актуальна для больших компаний. Каждый день сотрудники получают как минимум два-три письма типа ''сообщите'', ''проголосуйте'', ''представьте данные''. Все это мешает сосредоточиться и отнимает время, при этом не является критичным.
- требовать использовать голосовую почту на рабочих и персональных рабочих телефонах. Во-первых, это существенно сократит уровень шума в комнате, а во-вторых, позволит людям сохранять концентрацию, так как они не будут отвлекаться на звонки. Голосовую почту можно проверять на перекурах или кофе-брейках, убивая двух зайцев.
- руководителей проектов посадить так, чтобы они видели мониторы членов рабочей группы. После этого удивительным образом возрастет количество времени, которое люди уделяют работе и соответственно снизится время, уделяемое tut.by. Обычно лучше всего расставить рабочие столы по периметру комнаты вплотную к стенам – это, во-первых, обеспечит достаточное количество рабочего пространства, во-вторых обеспечит свободу передвижения, что важно для парного программирования, например, и в-третьих, поможет занять стратегический наблюдательный пункт, с которого все видно. Тем не менее, лучше объявить, что все хобби в Интернете остаются на вечер – в конце концов, должна же быть у людей личная жизнь?
- руководителям проектов быть буфером между своими разработчиками и администрацией. Защищать их от бюрократов, попыток вовлечь их в бесконечные совещания, начать менять им мебель в середине рабочего дня – одним словом, от любых действий, которые могут помешать им работать.