В штате компании – 90 человек. Управлять таким количеством сотрудников и контролировать их не у всех получается хорошо. Из-за неэффективного управления может проседать качество услуг компании, снижаться рентабельность проектов, ухудшаться общий климат в офисе. Чтобы этого избежать, мы внедрили у себя мониторинг эффективности работы сотрудника.
Это комплексная система, предполагающая не только учет времени, которое сотрудники тратят на выполнение задач по проектам, но и контроль других важных аспектов их работы. В условиях, когда все переходят на гибкие методологии разработки (и мы тоже в процессе перехода), важно следить за качеством и рентабельностью проектов, и учет времени лежит в основе всех работ.
Эта система дала нам возможность:
- увеличить скорость выполнения задач и сократить сроки сдачи проектов;
- строить реальные прогнозы загрузки производства на месяц вперед;
- прогнозировать потребность в новых сотрудниках и планировать набор персонала
- внедрить инструмент управленческой отчетности;
- вывести более 90% проектов в зону рентабельности
Сейчас расскажу, как мы в этому пришли.
Архитектура системы мониторинга эффективности
Контроль работы строится на четырех китах: учет трудозатрат, учет времени на рабочем месте, мониторинг загрузки производства и контроль рентабельности. Для каждой из этих задач используется отдельный инструмент – всего четыре, а два из них – наши собственные разработки.
- Учет трудозатрат. Для этой цели используем Redmine. Здесь мы ставим задачи друг другу и отбиваем затраченное время по каждой.
- Учет времени нахождения на рабочем месте. У каждого сотрудника есть индивидуальный электронный ключ, которым он открывает дверь, чтобы попасть в офис. Мы установили систему контроля доступа Bolid, которая собирает все данные о входе и выходе сотрудников. Так мы знаем, сколько времени каждый человек находится в офисе.
- Мониторинг производства в Canape STAT – собственная разработка. Сюда собираются все данные по трудозатратам из Redmine и сведения о времени на рабочем месте от СКД. Так у нас появляется полная картина по всем сотрудникам, а также по загруженности отделов (количестве часов/задач на отделе и на каждом сотруднике).
- Контроль рентабельности в Canape CRM (тоже разработали сами). В систему попадают данные по всем трудозатратам из Redmine, и мы можем отследить, когда проект попадает в зону риска, то есть количество отработанных часов вот-вот превысит оценочное время.
Подробно о каждом инструменте и об их работе далее.
Структура штата: чье время и как мы считаем
Из 90+ штатных сотрудников студии около 30% составляют менеджеры. Остальные – производство и административный персонал.
Сейчас производственный отдел работает по каскадной модели, но мы постепенно внедряем Agile на крупных проектах. У занятых в производстве сотрудников – разработчиков, дизайнеров, верстальщиков и прочих – есть три категории трудозатрат:
- Выполнение задачи.
- Коммуникация по задаче.
- Самообразование.
Наши сотрудники могут тратить 20% своего рабочего времени на изучение новых технологий, сервисов и инструментов, прохождение курсов и чтение профлитературы. Единственное требование – чтобы это саморазвитие было в рамках вектора развития компании и текущих задач.
Трудозатраты административного персонала учитываются по времени нахождения в офисе.
Характер работы менеджера сильно отличается от характера и состава задач других сотрудников. Потому мы не считаем время, которое уходит на выполнение работы менеджерами и аккаунт-менеджерами. Мы отказались от учета их трудозатрат, потому что если менеджер ведет более 10 проектов (а у нас в WebCanape получается примерно так), то при ручном отслеживании времени разрастается время на переключение между системами. Автоматизировать этот процесс мы пока не стали, потому что считать время телефонных переговоров, коммуникации в почте, постановки задач автоматически в условиях нашей инфраструктуры оказалось непросто. Да и сейчас это не является для нас приоритетом – отдел внутренней разработки загружен релизами новых версий Canape CMS.
Опытным путем мы выяснили, что на ведение проекта уходит в среднем 10% от заложенных в него часов, потому сразу включаем эту цифру в оценку. Если менеджер выполняет задачу по проекту самостоятельно (например, разрабатывает стратегию или заливает фотографии), то есть затрачивает время, которое учитывается при оценке проекта, он указывает потраченные часы в соответствующей задаче.
Как мы интегрировали системы учета в бизнес-процессы компании
К текущей системе мы пришли не сразу. Сначала решали проблемы точечно, а затем объединили все решения в комплекс.
|
|
Проблема |
Решение |
| 1 |
Затягивание сроков по проектамВроде все работали как обычно, но все чаще сроки сдачи проекта срывались. Нужно было понять, на каком сегменте цепочки проблема. Штат: до 20 человек |
Учет времени разработчиковЧтобы понять, где образуются дыры, мы стали учитывать время, затрачиваемое разработчиками, анализировать его и корректировать структуру задач и регламенты работы. |
| 2 |
Превышение оценочного времени по проектамКогда начали четко контролировать время разработчиков, часов, которые закладывали в проект при продаже, стало не хватать, и проекты оказывались нерентабельными. Штат: 35 человек |
Подсчет рентабельности проектовАнализ рентабельности проектов позволил нам скорректировать оценку трудозатрат по проектам и вывести более 90% в зону рентабельности. |
| 3 |
Отсутствие консолидированных данных по загрузке производстваПроектов становилось все больше, сроки нужно было выдерживать, производство начало “задыхаться”. Одни отделы были загружены на несколько недель вперед, другие сдали большую часть проектов и оказывались недозагружены. Не хватало сводных данных по нагрузкам на каждый отдел, чтобы можно было грамотно распределить работы по проектам. Штат: 40 человек |
Визуализация данных по трудозатратам и нагрузкамДля визуализации всех данных по загрузке сотрудников мы разработали собственный сервис, куда попадали данные из Redmine. Отображение всех сведений оформлено в виде тепловой карты, где цветовым кодом обозначена недозагрузка/перегрузка конкретного сотрудника/отдела. |
| 4 |
Расширение штата --> сложно контролироватьС повышение рентабельности мы стали быстрее развиваться, больше вкладывать в маркетинг, что вылилось в увеличение потока заявок и, как следствие, расширение коллектива, чтобы эти заявки обрабатывать и отрабатывать. Появилась потребность в автоматизации контроля сотрудников. Штат: 60 человек |
Интеграция с системой контроля доступаБольшим коллективом сложно управлять. Чтобы поддерживать трудовую дисциплину на уровне, мы стали учитывать время нахождения людей в офисе. Все наши сотрудники официально трудоустроены в штат компании. Данные о трудозатратах, количестве задач и времени на рабочем месте объединили в одну систему и получили наглядную картину по отделам. |
| 5 |
Увеличение объема заказов -> потребность в оптимизации работыС увеличением объема заказов стало недостаточно просто считать рентабельность и время нахождения людей на работе. Захотелось оптимизировать процессы так, чтобы обрабатывать больший объем заказов без расширения штата. Штат: 90 человек |
Решение выявленных проблем и оптимизация работыНам стало интересно, как сделать заказы рентабельнее и сократить сроки выполнения. На этом этапе мы стали искать «тонкие места» в производстве и продумывать способы оптимизации, чтобы в дальнейшем зарабатывать еще больше. |
Рассмотрим подробнее, какую работу мы провели на каждом из этих этапов.
Шаг 1. Считать трудозатраты
Начали мы с малого – ввели таск-трекер. Не стали внедрять никакие дополнительные таймеры, все делали в Redmine и собственной CRM. Это дало понимание, сколько времени уходит на конкретную задачу. Все это нормировали – появились нормативы по типам задач.
После этого установили почасовую оплату труда для разработчиков. Благодаря этим мерам у нас улучшилась трудовая дисциплина и стало формироваться понимание того, насколько проекты рентабельны.
Шаг 2. Следить за рентабельностью и сроками
Для учета рентабельности и контроля сроков по проектам мы давно разработали собственную систему управления проектами Canape CRM, в которой ведем все услуги компании: от разработки до продвижения сайтов.В договоре по каждому проекту прописаны сроки сдачи. Эти сроки мы визуально представили в CRM.
Менеджер четко видит, в какой срок должен быть сдан его проект, сколько осталось дней, может приостановить работу на время согласования. Это нам позволило также вывести все данные по срокам на большой монитор, который висит в центре офиса. Такая визуализация стимулирует здоровую конкуренцию между менеджерами, подстегивает разработчиков, руководители тоже обращают на эти сводки внимание и могут поинтересоваться ходом проекта.
Помимо своевременности сдачи проектов, в CRM мы также видим их рентабельность. В отчете выводится сводка по заложенным и потраченным часам по каждому договору.
На основе этих данных несложно сделать вывод об эффективности каждого менеджера. Видно, сколько каждый сдал проектов, сколько из них – в срок, сколько заработал для компании.
Это открытая статистика – сотрудники могут видеть, кто справляется лучше, а кто хуже. В CRM-системе автоматически выстраивается рейтинг.
Не секрет, что главное офисное противоборство – это противоборство менеджера с разработчиком. Как быть, если разработчик затягивает сроки по проекту? Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя. Своевременность сдачи проектов мы стали учитывать и при переводе разработчиков на следующий грейд.
В итоге мы начали отслеживать нагрузку на менеджерах и исполнителях, их эффективность и рентабельность их проектов. На основе этих данных мы формируем планы роста и развития, применяем полученные данные при финансовом стимулировании. Все это выливается в повышение уровня клиентского сервиса.
Мы видим отзывы, которые оставляют клиенты. Если не укладываемся по срокам – предупреждаем и объясняем причины. Сейчас это контролирует руководитель производства.
Шаг 3. Визуализируем нагрузки
После предыдущего шага остались некоторые проблемы, одна из которых заключалась в том, что у нас не было данных по загрузке отделов. Мы не знали и не могли спрогнозировать, когда, например, верстальщики разгребут очереди и смогут снова брать проекты. То есть все эти данные у нас фактически были, но в разрозненном виде. Интерпретировать их правильно не получалось.
Для решения проблемы мы разработали еще один собственный внутренний сервис – Canape STAT. Система Redmine дает все данные о трудозатратах, задачах и проектах в этот сервис, где в формате тепловой карты отображаются трудозатраты и нагрузка по каждому разработчику. Это реальные трудозатраты, которые сотрудник проставил по задачам в Redmine.
При этом мы сразу видим, если где-то есть превышение, явное отклонение от необходимого объема часов, недоработки и прочие проблемные области. В нашей компании специалист должен отбивать по задачам 7 часов в день. Таким образом, руководители и специалисты видят, сколько часов отработал каждый сотрудник, заметны недоработки и переработки.
В системе можно выбрать специалиста и увидеть, над какими задачами он трудился в конкретный день, сколько часов на них потратил, какие комментарии оставил. Так можно выявить причину отклонения от норматива.
Шаг 4 – интегрируем со СКУД
После того как мы вывели эти данные в нашу систему, потребовалось еще дополнить ее некоторой информацией, которой нам не хватало – данными о времени, проведенном в офисе. Так мы объединили систему учета трудозатрат по часам с системой контроля доступа.
Теперь мы видим, сколько времени человек потратил на задачи и сколько он находился в офисе при этом. Это позволяет исключить манипуляции с трудозатратами. Если сотрудник находился на рабочем месте 6 часов, а в задачах проставил 10 часов, у руководителя или контролирующего возникнут вопросы. Система также помогает поддерживать дисциплину труда. Мы видим, кто постоянно опаздывает, а кто приходит вовремя. Когда в офисе больше 50 человек и они рассажены по двум этажам и разным кабинетом, за такими вещами сложно уследить.
В эту же систему наши HR-специалисты заносят данные по отпускам, отгулам, больничным, заполняют производственный календарь.
Руководители и коллеги видят, когда кто уходит в отпуск или на больничный. Это упрощает коммуникации в коллективе. Вся статистика открыта для сотрудников.
Здесь же отражено плановое количество часов на каждый отдел и по каждому сотруднику, а также сколько из них реально отработано в этом месяце. Благодаря этому отделу кадров стало проще составлять отчеты. Мы смогли спланировать время на саморазвитие, когда оценили нормативное количество часов в месяц и сравнили с трудозатратами по коммерческим задачам.
Шаг 5 – оптимизируем процессы
Все уже выглядело достаточно хорошо, и контролировать процессы стало проще, но одна проблема никак не решалась – не получалось грамотно приоритизировать задачи. Стандартный принцип «что горит — делаем в первую очередь» не работал, потому что с таким подходом все задачи рано или поздно превращались в горящие из-за того, что постоянно откладывались ради более срочных. Соответственно, нужно было как-то понять, что делать быстрее, и кто должен принимать решения.
Чтобы решить эту проблему и дать сотруднику понимание о его загрузке, мы снова доработали Canape STAT. Теперь специалисты видят свои задачи, распределенные примерно на полторы недели вперед и могут планомерно их выполнять, учитывая оставшееся по задаче время и исполнителей внутри этой задачи.
Менеджеру и разработчику не нужно уточнять друг у друга, кто, когда и какую задачу будет делать. Все есть в системе. Задачи со статусами «Оценка» (нужно дать ответ новому клиенту) и «К выкладке» (когда нужно что-то выложить на живой сайт) по умолчанию идут первыми. Есть задачи со статусом «Не продано». Это значит, что проект точно будет запущен, на него нужно отвести время, но приступать к задаче пока нельзя, потому что какие-то данные по нему еще уточняются. В задачах также предусмотрена метка «Приоритетная» – это самые срочные задачи, и такую метку может выставлять только руководитель отдела.
К чему мы пришли
Это долгий путь, который мы еще не прошли до конца. Как и в любой компании, у нас остаются «узкие» места, над которыми мы работаем. Промежуточные итоги таковы:
- Повышение скорости выполнения задач и сдачи проектов.
- Прогноз загрузки производства на месяц вперед.
- Прогноз потребности в кадровых ресурсах.
- Инструмент управленческой отчетности.
- Более 90% проектов в зоне рентабельности.
- Еще один внутренний сервис :(
Последний пункт нас не очень радует, но когда мы начинали этот процесс, ни Битрикс, ни AmoCRM не было. Мы писали собственный инструмент под себя без опоры на внешние сервисы. Если бы такие проблемы стали перед нами сейчас, мы бы, конечно, искали решение на стороне, а сегодня это наше «узкое» место. На поддержание и усовершенствование системы требуется много ресурсов, сил разработчиков. Однако есть и положительный момент – это серьезный вызов для новых сотрудников. Они прокачивают свои скиллы на наших внутренних продуктах.
Логика системы учета рабочего времени
- Не мешает рабочему процессу.
Самое сложно для сотрудников в нашей системе – это засекать свое время работы по задачам и прикладывать пропуск в системе пропусков. Сложно представить, чтобы кто-то не смог с этим справиться.
- Охватывает всех сотрудников.
Директор, руководители отделов, тимлиды, линейные сотрудники, административный персонал – правила действуют абсолютно для всех. Все ведут учет трудозатрат и отчитываются о времени, проведенном на рабочем месте. Это позволяет нам точно отслеживать рентабельность проектов и стоимость внутренних задач.
- Открыта для всех.
Каждый может зайти в Canape STAT и посмотреть, сколько времени он или его коллега отработали по проекту, когда они приходят и уходят, сравнить себя с коллективом.
- Возлагает ответственность на руководителей отделов.
Мы доверяем сотрудникам, но контролируем их. Руководитель примерно раз в месяц проверяет дисциплину труда и, если есть систематические нарушения, проводит беседу с сотрудником. Он отвечает за перегрузку отдела, недоработки подчиненных и их низкую производительность, так как у него есть все инструменты для того, чтобы вмешаться до того, как проблема приобрела критический характер.
- Строится вокруг рентабельности.
Достижение и повышение рентабельности – главная цель внедрения этой системы. Все инструменты в рамках этой системы ориентированы на то, чтобы получить максимальный экономический эффект от деятельности компании.
- Внедряется поэтапно.
Глобальные изменения нельзя вводить скопом. Это может вызвать недовольство сотрудников, путаницу при учете. Мы интегрировали новые инструменты учета постепенно, чтобы все успели перестроиться и адаптироваться к новым условиям.
Мы постоянно переосмысливаем наши внутренние процессы, чтобы сделать учет времени более полным и менее утомительным для сотрудников. Расскажите, как это организовано у вас? Какие метрики вы используете для оценки рентабельности проектов?
Сейчас мы готовим еще один материал о том, как и для чего мы разработали собственную CRM. Подписывайтесь на канал в Telegram, чтобы не пропустить.
Комментарии (77)
Kuz_ma Автор
25.06.2019 18:001) Болид
2) На рост по грейдам
3) Да, на распределение премиального фонда внутри подразделения. На начальника тоже.
savostin
25.06.2019 22:09Всегда было интересно как заставить себя, а тем более кого-то, постоянно делать записи, отмечать текущую выполняемую задачу. Я всегда то забуду отметить начало, то конец. В итоге все красивые в задумке отчеты превращаются в бесформенную кашу без особой ценности.
Kuz_ma Автор
25.06.2019 22:55В связи с этим мы отказались от ручной фиксации времени на переговоры, переписки и т.д.
Orange11Sky
25.06.2019 22:21Интересно возросла ли текучесть кадров после нововведения?
Kuz_ma Автор
25.06.2019 22:53Смотря каких. Наши изменения мы вводили постепенно и явных зависимостей не заметили. Сейчас стало гораздо проще выявить проблемные места и заранее спровоцировать разговор с сотрудником. Многие сотрудники, которые по тем или иным причинам поменяли место работы, наоборот отмечали факт, что уровень нашей автоматизации гораздо сильнее, чем в новых компаниях и что многое приходилось делать в вордах и эксклюзив.
Orange11Sky
26.06.2019 04:37+1Интересно как реагируют программисты на логирование прихода-ухода.
Походы в туалет или в курилку тоже учитываются?
На мой взгляд такая система на корню убивает желание сделать задачу раньше срока и распорядиться по-своему освободившимся временем.
Мало кто из программистов способен еффективно пахать по восемь часов в день, но при должной организации труда он вполне сможет справиться с восьмичасовым заданием за три-пять часов. Но при этом он уже будет не в состоянии сделать что-либо существенное. И что — тупить в монитор, высиживая положенное время?
Такое сильно демотивирует и побуждает искать более адекватную работу.
И уж, разумеется, на лояльность сотрудников компания может не расчитывать.Kuz_ma Автор
26.06.2019 06:19Конечно до такого бреда мы не доходим и не планируем, а постепенно переходим к более гибкой организации команд и их рабочего времени.
Yuriy_krd
26.06.2019 08:34+2Вы так и не ответили на вопрос: «что делать разработчику если он (фактически, а не по вашей системе учета задач) закрыл задачу но до окончания рабочего дня есть еще время?»
pewpew
26.06.2019 09:03+3Полагаю, он должен искренне написать, что смотрит мемасики, за что его вассал получит
пропистон в статистику эффективности.
Ну и да, разработчик — молодец, решил задачу, на которую запланировано 8 часов за 4. Повысим норматив. Теперь подобная задача будет планироваться к выполнению за 6 часов. Так что разработчик, если он понял систему попросту будет затягивать выполнение задачи. Печально, но так ему будет «выгоднее».
Kuz_ma Автор
26.06.2019 09:12-2А какая мотивация смотреть мемасики? Сделал быстрее — молодец, берем его опыт и пересматриваем нормативы.
TyVik
26.06.2019 09:42+2Получается, не выгодно делать задачи быстрее, чтобы нормативы не пересматривали.
Kuz_ma Автор
26.06.2019 10:01-2Почему? Поясните вашу логику.
roscomtheend
26.06.2019 10:43+4Потому что у него не будет запаса по времени в следующий раз и он получит штраф (в виде отсутствия бонуса и поднятия грейда) и повышение плана на выработку. Поэтому разработчик, видя уязвимости вашего KPI (а их видно даже из статьи), будет максимально их эксплуатировать, а не стремиться получить себе больше проблем с их помощью.
PS. У нас "типовая задача" часто получается — "сделать неведомое нечто, что не делалось до сих пор", а "сделать отчёт", скорее, нетипичная.
Kuz_ma Автор
26.06.2019 13:36Если у вас разработчики ищут уязвимости в KPI, остается вам посочувствовать.
Slader
26.06.2019 15:05Люди, они такие. Ходят на работу за зарплатой обычно. Любят кушать и покупать игрушки детям своим и украшения женам. Ездить в отпуск в новые страны. И кучу всего.
Если же вы смогли найти сотрудников, которые искренне поддерживают ваш KPI и не стараются сломать/обойти/хакнуть его, а стопроцентно соблюдают (даже в ущерб себе) — ну молодцы вы. Счастья, здоровья и как там наш премьер говорил
roscomtheend
27.06.2019 11:41У нас не ищут — нет формального KPI. А вот в Гугле ищут (об этом на Хабре была статья), и тут ищут, но это скрыто от начальства (никто же не будет хвастаться — "смотрите как я обманул вашу систему"). Так что посочувствуйте себе — вас обманывают, а вы делаете вид что всё нормально.
И я работал в компании, где одним из аспектов KPI было нахождение на рабочем месте (как коэффициент <=1, т.е. 146% было не получить пересиживая, но помножить з/п на <1 легко). Как итог — это был отличный опыт и он помог мне осознать что такие компании
~можно~нужно игнорировать сразу.Kuz_ma Автор
27.06.2019 15:39Вопрос в комплексном анализе контролируемых факторов и нахождения зависимостей, в не конкретно в одном. Нет у нас такого KPI, как нахождение в офисе. Эти данные у нас используются как дополнительный фактор оценки и контроля.
ilnuribat
26.06.2019 13:31по сути, любая KPI на разработчика будет проверена на прочность самим же разработчиком.
Да, разработчику в итоге нет смысла делать быстрее что-то, при этом он всегда будет время закладывать на оценке. Если оценили слишком мало, то даст понять почему задача сложная, найдет барьеры
Мне тут вот что интересно — а какая цель компании в связи с этой системой? Получить рентабельность за счет удешевления внутренних ресурсов? за счет большего контроля?
Если да, то это напоминает попытку выжать максимум от всего возможного, в том числе от сотрудников, и плевать на клиентов, ведь от них тоже будут все соки выжимать.
В таких местах каждый программист чувствует себя рабом, ресурсом, которого утилизируют по максимуму, не давая ни минуты простоя. Поэтому выше и были намеки на утечки кадров — в системе тотального контроля нет места внутренней мотивации делать крутой продукт.
В компаниях, где целью является, например «довольный клиент», все по-другому: там бизнес доверяет программистам, не следит за ними, за их «часами отработки». В то же время программисты доверяют бизнесу по части направления и стратегии и хотят делать лучший продукт на рынкеKuz_ma Автор
26.06.2019 13:39Система используется не для карательно-надзорных функций, а для нахождения проблемных мест и дальнейшей оптимизации процессов. Не пойму, откуда сложилось мнение про тотальный контроль и жесткую отчетность?
Slader
26.06.2019 15:19Потому что под оптимизацией процессов обычно понимают штрафы/задержку карьерного роста и иные схемы мотивации.
Как будто в советское время таких KPI не было. И реагировали на них так же. И сообща били морду (если могли, конечно :) ) стахановцу, из-за которого всему цеху поднимали план выработки
Yuriy_krd
26.06.2019 09:32+3Еще, как мне кажется, данная организация труда поощряет выпускать в продакшн всякое Г с костылями, если прогер не успевает расправиться с внезапно обнаруженными граблями вовремя. Лишь бы KPI не упали (а еще и манагер мозг проест).
Kuz_ma Автор
26.06.2019 10:34Это происходит крайне редко. Костыль или всякое Г, далее аукнется на менеджере проекта, что отразится на всей команде исполнителей. Если в процессе работы выясняется, что оценка сделана ошибочно (по нашей вине) и нужно больше времени, эти риски компания берет на себя. Если во время разработки изменилось ТЗ по требованию клиента — то делается перерасчет бюджета.
А вообще, бОльшая часть задач по разработке сайта (если не брать дизайн), они типовые, по которым у нас есть статистика за 2 года, и предварительная оценка довольна точная. Если программист не успевает ее сделать, значит проблема в его квалификации и повод его обучить и т.д.Yuriy_krd
26.06.2019 10:40+1Может, Вам написать вторую часть? Я бы почитал с удовольствием. Есть много мелких и неочевидных нюансов, подводных камней., которые раскрываются только тут в комментариях. Потому что сама по себе идея — интересная. Но прочитав данную статью возникает ощущение, что миром правят «эффективные» менеджеры и во главу угла поставлено исполнение KPI и сроки.
Kuz_ma Автор
26.06.2019 10:47«во главу угла поставлено исполнение KPI и сроки.» — ведь это действительно так в любом бизнесе, кто заинтересован зарабатывать деньги.
Я был в офисах разных IT компаний, как бы не был у них устроен процесс управления персоналом и проектами, все равно у каждого сотрудника есть понятные KPI.
lamerok
26.06.2019 14:18Про походы в туалет есть даже такое правило:
«всегда ходите в туалет по большому на работе, вы не только по используете туалетную бумагу, воду и унитаз работодателя, но вам за это еще и заплатят»
AndreyUA
26.06.2019 07:27Как вы контролируете работу руководителей?
Несколько раз на нескольких предприятиях попадал на внедрение листков описания выполненной работы за день. Обычно у всех это был творческий процесс, который отнимал большой кусок рабочего времени, но очень развивал фантазию. Но, как временная мера для оценки работы отдела/организации, довольно эффективна.
У Болида есть возможность забрать данные из СКУД? Радуйтесь, что у вас не PERCo. Эти ребята даже баги закрывают с большой неохотой, а уж о доработке некоторых функций можно вообще забыть. Толком интеграции с другими системами нет, даже за деньги. И делать не собираются.
Сейчас на предприятии используем 1С Документооборот. Вот эти люди знают толк в извращениях.Yuriy_krd
26.06.2019 08:32Радуйтесь, что у вас не PERCo. Эти ребята даже баги закрывают с большой неохотой, а уж о доработке некоторых функций можно вообще забыть. Толком интеграции с другими системами нет, даже за деньги.
Не совсем понимаю, о чем Вы говорите, У нас полноростовые турникеты PERCo, датчики Biosmart и СКУД «Сигур».
" Сигур" вполне корректно управляет всей этой бодягой и скидывает табели рабочего времени в 1С.AndreyUA
26.06.2019 09:12Имел ввиду СКУД PERCo WEB. Sigur нормальная штука, разработчики с норм обратной связью. Сейчас очень пожалел, что выбрал не Sigur. Очень подкупило именно веб решение. Не ожидал, что база закрыта, API как такового нет, модулей интеграции нет, техподдержка работает только по почте и после нескольких звонков с вопросами и претензиями. Подключиться по удаленному рабочему столу они не могут для демонстрации бага, переписка может длиться несколько месяцев. Для того, чтобы ответили на почту в 90% случаев требуется звонок в ТП, но все вопросы нужно писать по почте. Любые запросы и баги исправляются очень туго. Исправление некоторых вещей ждем с ноября месяца.
Kuz_ma Автор
26.06.2019 09:14У каждого руководителя есть квартальный план, который описан, как в цифровых показателях, так и в качественных. По окончанию каждого квартала с руководителем встреча, где он рассказывает о том, что сделал из плана и т.д.
СКУД у нас самый простейший, из него забираем сырые данные и далее визуализируем.
PERCo
26.06.2019 13:23Андрей, добрый день! Мы всегда рады обратной связи от наших клиентов.
СКУД PERCo-WEB продолжает активно развиваться. Реализованы проекты: поддержка API; поддержка БД MySQL; поддержка биометрии PERCo; интеграция с 1С, мобильное приложение для удаленной регистрации событий и ряд других доработок. Новая версия системы выйдет уже в 3-ем квартале 2019 года. Если у вас есть дополнительные примечания/пожелания к доработкам, вы можете оставить координаты для связи или просто написать нам: feedback@perco.ru. Спасибо, отличного дня!AndreyUA
26.06.2019 14:07Здравствуйте!
Ваша техподдержка меня уверяла еще в ноябре, что вы переходите на поквартальный выпуск релизов и в следующем релизе, то есть в 1 квартале 2019 года все будет исправлено. Вы сообщаете, что новая версия выйдет в 3 квартале. Пока я только слышал, что ваше ПО будет поддерживать«поддержка API; поддержка БД MySQL; поддержка биометрии PERCo; интеграция с 1С, мобильное приложение для удаленной регистрации событий»
. Предоставить доступ в базу и описание полей вы отказываетесь, мотивируя это тем, что у вас там все может поменяться. Но, мне кажется, что это просто отговорка и не более. Если честно, то мне, например, API не нужно, а нужет просто доступ в базу, где я мог бы взять данные о проходах. Я в состоянии осознавать эти риски и, если что-то поменяется, исправить. Хотелось бы узнать реальную причину того, что вы не даете доступ к базе.
Я звонил в техподдержку раз 10 и написал не одно письмо для того, чтобы получить патч, который исправляет некоторые недоработки. И это касается неправильного учета рабочего времени. Сообщили мы об этом в ноябре, патч получили в феврале. Если бы вы знали, сколько раз я пожалел о выборе вашего продукта, выслушивая лекции руководителя о том, что я его убедил, что нам надо переходить на новый СКУД, т.к. он больше не поддерживается и если что-то сломается, то мы ничего сделать не сможем. Что у нас там был доступ к базе и запросами все доставалось. Что теперь не обойдешься простым изменением запросов к базе и небольшим исправлением логики. Что все наши самописные инструменты можно Shift+del. Что потратили деньги и теперь действительно ничего сделать не можем. Даже исправления бага с учетом мы ждем столько времени. Каждое начало месяца я выслушивал жалобы от отдела кадров и требования руководителя решить вопрос в конце концов. И, к сожалению, они были правы. Я сам наступил на эти грабли и втянул в это своих коллег.
И даже когда у вас выйдет новая версия, я 10 раз подумаю, переходить мне на нее или нет, т.к. если что-то не заработает, то за 4 месяца, пока будет предоставлен патч, я буду уволен или сам вручную буду записывать людей на проходной. Вам надо не новую версию выпускать, а пересмотреть подход к техподдержке.
ЗЫ Софт у вас неплохой, поэтому я его и выбрал, но я в который раз убеждаюсь, что техподдержка, возможность получения информации по запросу, быстрое исправление багов, обратная связь — это основной критерий по выбору продукта.PERCo
26.06.2019 14:56Андрей, спасибо за развернутый feedback. Мы учтем ваши комментарии в нашей работе.
lasc
26.06.2019 07:41+5Хорошо конечно, но если бы у меня был выбор, я бы предпочел компанию без учета часов.
Kuz_ma Автор
26.06.2019 09:16У каждого свой выбор. Бизнес должен считать деньги и в любой компании где 50+ сотрудников, этот путь практически неизбежен.
Kastrulya0001
26.06.2019 10:37+2Этот путь я наблюдал в нескольких компаниях, где я работал. Везде одно и то же. СКУД -> контроль времени -> текучка кадров -> развал. Сам я обычно успевал поработать неплохо несколько лет. У меня есть несколько триггеров для поиска новой работы:
любой штраф,
камера в помещении,
расписание чего либо, касающееся жизнедеятельности,
дресскод для бэкенд работников,
появление необходимости расписывать свои действия.
Сейчас мы по пятницам играем в настолки, все вместе и руководство тоже, не заметил, чтобы были проблемы от этого.Kuz_ma Автор
26.06.2019 10:50-1Полностью с вами согласен, что любой процесс можно довести до абсурда. 90% того что вы перечислили даже близко у нас нет и по пятницам у нас тоже весело)
Ranyee
26.06.2019 10:34Интересно. По мне не хватает резервов и планирования/перепланирования для менеджеров.
Не считаю что видеть коллег(я сейчас про разработчиков) это хорошо. Все разные. Это задача руководителя взаимодействовать с сотрудником и давать обратную связь по вопросам его эффективновности.Kuz_ma Автор
26.06.2019 10:35Про планирование менеджеров — это отдельная тема статьи. Попробую написать ее тоже.
На счет видимости коллег — возможно вы правы, но у себя мы такой проблемы не заметили или не замечаем)Ranyee
26.06.2019 13:19Если все работают одинаково, значит все работают одинаково средне.
Я отошел от точечных оценок и для разработчиков и планирования использую интервальные, что бы с одной стгроны разработчики не были постоянно под прессингом, с другой были границы и задача не «занимала все отведенное для нее время».
У нас небрльшой коллектив. Поэтомк особо не до экспериментов. Но подозреваю, что если раскрыть для всех статистику, то производительность выравняется, но не в лучшую сторону. Сейчас у всех она равна/лучше нормативной, при этом, понятно, у всех свои отклонения…
amarao
26.06.2019 11:32Увлекательно у вас работать, наверное. /сарказм
Kuz_ma Автор
26.06.2019 11:52Приходите в гости. /без сарказма
amarao
26.06.2019 12:38Я работаю в компании со свободным графиком, которая не занимается подсчётом секунд, проведённых в туалете и не использует в качестве KPI расхождение между плановыми и реальными часами.
К вам работать я пойду только в аварийной ситуации.
Kuz_ma Автор
26.06.2019 12:55Не утрируйте, откуда информация про подсчет секунд в туалете, ей богу, лишь бы коммент написать.
amarao
26.06.2019 13:59А есть большая разница между учётом секунд в туалете и "Учет времени нахождения на рабочем месте. У каждого сотрудника есть индивидуальный электронный ключ, которым он открывает дверь, чтобы попасть в офис. Мы установили систему контроля доступа Bolid, которая собирает все данные о входе и выходе сотрудников. Так мы знаем, сколько времени каждый человек находится в офисе."?
Я вполне серьёзно говорю, что при таком отношении к сотрудникам вы — работодатель последнего уровня.
Kuz_ma Автор
26.06.2019 14:07А что, к примеру в Яндексе, вы думаете это не используется? Там аналогично есть СКУД, аналогично это отслеживается. Покажите мне современный офис без контроля доступа в него?
amarao
26.06.2019 14:11Дело не в логах доступа, а в использовании этих данных для оценки времени наличия человека в офисе и использования этих данных для оценки его продуктивности.
Kuz_ma Автор
26.06.2019 14:20Вы хотите сказать, что Яндекс эти данные использует по-другому?
Возможно стиль материала получился такой, что кажется, что отслеживание времени сотрудника сведено до параноидального, но это совершенно не так.
Весь процесс мониторинга сводится не к разбирательству, почему конкретный сотрудник делал задачу долго или обедал дольше положенного, а к выявлению узких мест в бизнес процессах на основе данных из разных источников.
В ходе объединения разного рода статистических данных по сотрудникам/отделам/проектам и дальнейшего их анализа нам многое удалось улучшить, в том числе и в жизни персонала.stanislavkulikov
26.06.2019 15:53нам многое удалось улучшить, в том числе и в жизни персонала.
Очень интересно а что же?
atd
26.06.2019 17:21там есть скуд, но часы никто не считает, по крайней мере в московском офисе.
если человек не справляется, его лучше уволить, чем стоять надсмотрщикомKuz_ma Автор
26.06.2019 17:28Уверены, что не считают? Я нет. Месяц назад был на стажировке в Яндексе, задавали им подобные вопросы. Учет присутствия сотрудников на рабочем месте есть, но конечно не для всех эта информация анализируется.
Уволить это самое простое. Мы стараемся за счет подобных анализов выявлять пробелы и тонкие места и решать их. Кроме этого, наличие, назовем так «логирования» действий сотрудников, позволяет быстро разобраться в разного рода форс-мажорах.atd
26.06.2019 23:40Да, уверен, если за пять последних лет они не начали страдать фигней. Эти логи, возможно, достают только когда приходтся уволить человека по статье, но для яндекса это история редкая. Там работают в целом адекватные люди. А учёт по скуд скорее нужен чтобы понять можно ли в данный момент застать нужного человека на определённом рабочем месте. Многие работают из дома или в командировках. Менеджеры бывают на встречах вне офиса.
До этого я работал в конторе, где даже выходить покурить нужно было по карточке и в конце месяца считалась каждая минута. Кто сколько обедал, кто не доработал, кто опоздал. Это трэш и содомия, в конце недели многие тупили в соцсеточках чтобы нагнать нужные часы, хотя таски все по сути были сделаны (до людей через некоторе время дошло, что лучше закладывать планы с запасом). В яндексе такого совершенно не наблюдалось, по крайней мере для кодеров, единственно выжным был только результат а не просиживание штанов или микроменеджмент.
Уволить это не простое. Но и воспитывать человека не получится. Может для грузчиков или первой линии саппорта это и сработает, но для работников интеллектуального труда это не вариант. Я сам увольнял людей и увольнялся оттуда. Пытаться «воспитать» кодера, который выдохся по той или иной причине практически не реально. Можно только перевести в другую команду (отдел) или уволить.Kuz_ma Автор
27.06.2019 09:09-1Возможно вы не так внимательно читали материал, либо просто хотите поспорить. В нашей системе, как и в Яндексе, нет задачи контролировать каждую секунду сотрудника. Аналогично, как вы пишите, если есть результат, то и внимание на данные скуд обращать не будем, а вот если есть отклонение от нужного результата, тут то и помогают подобные решения для выяснения причин и внедрения дальнейших улучшений.
atd
27.06.2019 13:57А вы невнимательно читаете мой ответ. В приличных конторах если есть отклонение, то это повод задуматься непосредственному руководителю, провести беседу, а не смотреть на посещаемость. В данные скуд обращают внимание только после того, как прошли человеческое общение, обсудить задачи, обсудить жизнь в компании, предложение сходить в отпуск, сменить задачу, сменить команду, сменить компанию. Если после всего этого человек одновременно не хочет работать но и не хочет решать эту проблему или уйти по-хорошему, только тогда может понадобиться посещаемость.
Человеческие проблемы надо решать человеческим общением, а не метриками над данными. И в общении не использовать эти метрики и сами данные, это только испортит нормальные рабочие отношения.Kuz_ma Автор
27.06.2019 15:45А с чего вы взяли, что у нас не так? Я где-то пишу, что сотрудники наказываются штрафами за опоздания или курение?
Цифровые данные нам помогают принимать управленческие решения, но не являются решающими. Живое общение оно само собой разумеется.
SbWereWolf
26.06.2019 13:35Спасибо за серию статей, получились хорошие руководства.
отдельные моменты улыбнули:
Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя.
Менеджеры когда то не наседали? по моему опыту руководители всегда хотят получить вчера, то что им пришло в голову сегодня. Мне исполнителя жалко, он и раньше не знал как сделать работу что бы не потерять в качестве, а теперь вы его ещё и с секундомером у него над душой стоите. Хотя если работа типовая, то это наверное правильная практика.
Совсем другое дело что с вводом лимитов на «операции» и наглядной демонстрацией истечения сроков — исполнители могут наглядно понимать что уже нет времени копаться в нюансах и пора форсировать работу. Это плюс.
Мы видим, кто постоянно опаздывает, а кто приходит вовремя.
а тех кто постоянно задерживается? Или после часа X охрана всех выгоняет?Kuz_ma Автор
26.06.2019 13:42С секундомером над душой не стоим, про это я не писал. Просто не допускаем случая, когда «сколько не дай разработчику времени на задачу, ему будет мало».
По задержкам — охрана не выгоняет, но мы контролем этот показатель и работаем с сотрудниками, кто допоздна сидит в офисе, выясняем причины переработок, т.к. это один из первых признаков выгорания.
HellKaim
26.06.2019 13:53Kuz_ma
Вообще — все что вы делаете это правильно. Просто в РФ еще много народу, который думает что бизнес это такая социальная функция. В большинстве стран с высокой производительностью труда ни кто не удивляется СКУД, подсчёту часов и нормированию. Не сдавайтесь ;)
А про менеджеров пишите — интересно почитать.
Kuz_ma Автор
26.06.2019 13:56Спасибо за оценку. Новые материалы готовим.
HellKaim
26.06.2019 14:23Да, если вам и дальше будут возражать и говорить про "компании со свободным графиком", то тут все достаточно просто.
Если, грубо, 2 типа производства: в одном территориальная составляющая важна, во втором — нет.
Если дизайнер может делать макет сам общаясь по телефону, то верстальщик, скажем, должен переодически сверяться с коллегой все ли верно + там рядом QA.
И сверху этого — личная культура сотрудника. Т.е. есть люди, которые не могут работать "вне офиса".
Я видел схемы, при которых у сотрудников есть 5 дней в месяц, которые они могут работать удаленно. Контролируется все так же: логин в систему, сдача задач и т.п. часто такое решение позволяет выпустить пар и снять иллюзию "потогонного производства". Но, повторюсь, это не со всеми людьми работает и нагружает менеджера юнита (ему же нужно понять пойдет ли и на сколько хорошо).
Мы делаем так: у нас у всех почасовая ставка + нормирование. План идёт на неделю, месяц, квартал. Строится сверху вниз от воронки продаж. Часть сотрудников может не приходить в офис, но обязана быть доступен по 3 каналам в течение рабочего дня (у нас своя рабочая среда и, по сути, это значит что он должен рагировать на push из мобильного клиента.
Некоторым (около 25% штата) такой вольницы не досталось и они обязаны быть в офисе и каждый рабочий день.
У нас есть бот, которому можно быстро отписать по задаче комментарий или закрыть ее со списанием часов. Даже логинется в систему не нужно. Т е. Мы постарались максимально разгрузить и упростить отчётный функции для человека, не потеряв в качестве.
KPI для разработчика строим на основе ножниц оценка/факт. Сам KPI идет снизу вверх, т.е.если у меня сфакапил Петя из отдела А, то я, как директор компании, не получаю часть своего бонуса. + кросс-отдельные KPI — когда руководитель отдела Б зависит от результатов отдела А, а руководитель отдела А зависит от скорости решения задачи отделом Б (т.е. ему нужно передать задачу так, что бы Б уложился в план).
Получается некая война внутри — но сверху находится линейный руководитель который всех мирит + hr постоянно оценивает эффективность kpi и помогает.
Если мы видим, что какая-то функция у нас не нагружается нужным образом, мы ее выносим на аутсорс. Скажем бухгалтерия, первая линяя поддержки.
Сей час 120+ человек, при этом мы скакнули с 50 за год.
shurkandak
27.06.2019 08:02снижаться рентабельность проектов
Если не секрет, как вы эту самую рентабельность подсчтиваете?Kuz_ma Автор
27.06.2019 09:14-1На эту тему есть несколько наших материалов:
habr.com/ru/company/twins/blog/181886
habr.com/ru/company/twins/blog/311380
Ramopitek
27.06.2019 09:10Потому мы не считаем время, которое уходит на выполнение работы менеджерами и аккаунт-менеджерами
А вы учитываете, что эти же самые менеджеры могут за день написать разработчику, который занят одной системой, «100500 сообщений» по системам, которыми сейчас разработчик не должен заниматься? По-сути получается, что разработчик может вести еще 10 систем других 10 менеджеров в чисто консультативном порядке.
У меня был опыт, что из-за таких моментов время на текущую задачу уходило намного больше чем ожидалось.Kuz_ma Автор
27.06.2019 09:11а) время на коммуникации заложено в бюджет проекта
б) адекватный разработчик долго не будет молчать, если менеджер будет писать ему 100500 сообщений, либо это увидит его руководитель
Peter03
Особенно было бы интересно его трансформация, с чего начали какие изменения были сделаны и к чему в конце концов пришли.
Kuz_ma Автор
Сейчас мы смотрим на:
Peter03
Kuz_ma Автор
1) По оценке времени на задачу — по разному
Если задача типовая — то менеджер
Если не типовая, то оценку делает руководитель подразделения
2) По планированию производства
Тут у нас есть годовой финансовый план, исходя из него мы планируем загрузку производства по месяцам. А уже по реальным данным, ежемесячно за это отвечает руководитель производства и руководитель производственных подразделений.
Peter03
А какую СКД используете?
И на что кроме зарплаты влияет KPI разработчика?
Отражается ли KPI конкретного разработчика на отдел? На непосредственного начальника?
Kuz_ma Автор
1) Болид
2) На рост по грейдам
3) Да, на распределение премиального фонда внутри подразделения. На начальника тоже.