Работа службы управления персоналом предприятия: анализ пути ее совершенствования

''Во множестве компаний есть статистика об использовании рабочего времени. Но ни в одной я не видел статистики о качестве этого времени''

Том де Марко, Peopleware

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

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

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

Почему так трудно планировать? Почему фактическое время, потраченное на задачи, всегда выше запланированного? Даже когда мы доверяем оценки непосредственно тем людям, которые должны выполнять задачу, они все равно ошибаются. При этом они всегда находят тысячи оправданий превышению сроков – привлекли к другому проекту, помешали, отвлекли в бухгалтерию по поводу командировки и так далее. Эта ситуация типична.

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

Совещание по текущему проекту. У нас работает разработчик Федор. Федор – ведущий инженер программист с солидным стажем. Мы ставим перед ним задачу Х. Выдав ему хорошо сформулированную постановку задачи, интересуемся, сколько необходимо времени, чтобы закодировать задачу Х?

Федор отвечает, что ему необходимо четыре часа, максимум - шесть. Мы резюмируем, что исходя из того, что завтра Федор начнет работать в девять часов утра, в шесть вечера мы уже включим задачу Х в завтрашнюю версию проекта. Федор соглашается с этим решением.

Наследующий день в 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 дней – отстанем более чем на две недели . Знакомо, не правда ли?

Этот метод вполне точен и годится для оценок. Еще более точным методом может стать использование статистического моделирования – например, с помощью метода, разработанного Томом де Марко и Тимом Листером для моделирования влияния рисков на проекты. Согласно этого метода, надо задать параметры проекта, внести новый риск непрерывного типа ''влияние мусорного времени'' и задать коэффициент его влияния согласно инструкции.

 Скачать реферат