В штате WebCanape — 90 человек. Управлять таким количеством сотрудников и контролировать их не у всех получается хорошо. Из-за неэффективного управления может проседать качество услуг компании, снижаться рентабельность проектов, ухудшаться общий климат в офисе. Чтобы этого избежать, мы внедрили у себя мониторинг эффективности работы сотрудника.
Это комплексная система, предполагающая не только учет времени, которое сотрудники тратят на выполнение задач по проектам, но и контроль других важных аспектов их работы. В условиях, когда все переходят на гибкие методологии разработки (и мы тоже в процессе перехода), важно следить за качеством и рентабельностью проектов, и учет времени лежит в основе всех работ.
Эта система дала нам возможность:
Сейчас расскажем, как мы в этому пришли.
Контроль работы строится на четырех китах: учет трудозатрат, учет времени на рабочем месте, мониторинг загрузки производства и контроль рентабельности. Для каждой из этих задач используется отдельный инструмент — всего четыре, а два из них — наши собственные разработки.
Подробно о каждом инструменте и об их работе далее.
Из 90+ штатных сотрудников студии около 30% составляют менеджеры. Остальные — производство и административный персонал.
Сейчас производственный отдел работает по каскадной модели, но мы постепенно внедряем Agile на крупных проектах. У занятых в производстве сотрудников — разработчиков, дизайнеров, верстальщиков и прочих — есть три категории трудозатрат:
Наши сотрудники могут тратить 20% своего рабочего времени на изучение новых технологий, сервисов и инструментов, прохождение курсов и чтение профлитературы. Единственное требование — чтобы это саморазвитие было в рамках вектора развития компании и текущих задач.
Трудозатраты административного персонала учитываются по времени нахождения в офисе.
Характер работы менеджера сильно отличается от характера и состава задач других сотрудников. Потому мы не считаем время, которое уходит на выполнение работы менеджерами и аккаунт-менеджерами. Мы отказались от учета их трудозатрат, потому что если менеджер ведет более 10 проектов (а у нас в WebCanape получается примерно так), то при ручном отслеживании времени разрастается время на переключение между системами. Автоматизировать этот процесс мы пока не стали, потому что считать время телефонных переговоров, коммуникации в почте, постановки задач автоматически в условиях нашей инфраструктуры оказалось непросто. Да и сейчас это не является для нас приоритетом — отдел внутренней разработки загружен релизами новых версий Canape CMS.
Опытным путем мы выяснили, что на ведение проекта уходит в среднем 10% от заложенных в него часов, потому сразу включаем эту цифру в оценку. Если менеджер выполняет задачу по проекту самостоятельно (например, разрабатывает стратегию или заливает фотографии), то есть затрачивает время, которое учитывается при оценке проекта, он указывает потраченные часы в соответствующей задаче.
К текущей системе мы пришли не сразу. Сначала решали проблемы точечно, а затем объединили все решения в комплекс.
| Проблема | Решение |
1 | Затягивание сроков по проектамВроде все работали как обычно, но все чаще сроки сдачи проекта срывались. Нужно было понять, на каком сегменте цепочки проблема. Штат: до 20 человек | Учет времени разработчиковЧтобы понять, где образуются дыры, мы стали учитывать время, затрачиваемое разработчиками, анализировать его и корректировать структуру задач и регламенты работы. |
2 | Превышение оценочного времени по проектамКогда начали четко контролировать время разработчиков, часов, которые закладывали в проект при продаже, стало не хватать, и проекты оказывались нерентабельными. Штат: 35 человек | Подсчет рентабельности проектовАнализ рентабельности проектов позволил нам скорректировать оценку трудозатрат по проектам и вывести более 90% в зону рентабельности. |
3 | Отсутствие консолидированных данных по загрузке производстваПроектов становилось все больше, сроки нужно было выдерживать, производство начало «задыхаться». Одни отделы были загружены на несколько недель вперед, другие сдали большую часть проектов и оказывались недозагружены. Не хватало сводных данных по нагрузкам на каждый отдел, чтобы можно было грамотно распределить работы по проектам. Штат: 40 человек | Визуализация данных по трудозатратам и нагрузкамДля визуализации всех данных по загрузке сотрудников мы разработали собственный сервис, куда попадали данные из Redmine. Отображение всех сведений оформлено в виде тепловой карты, где цветовым кодом обозначена недозагрузка/перегрузка конкретного сотрудника/отдела. |
4 | Расширение штата —> сложно контролироватьС повышение рентабельности мы стали быстрее развиваться, больше вкладывать в маркетинг, что вылилось в увеличение потока заявок и, как следствие, расширение коллектива, чтобы эти заявки обрабатывать и отрабатывать. Появилась потребность в автоматизации контроля сотрудников. Штат: 60 человек | Интеграция с системой контроля доступаБольшим коллективом сложно управлять. Чтобы поддерживать трудовую дисциплину на уровне, мы стали учитывать время нахождения людей в офисе. Все наши сотрудники официально трудоустроены в штат компании. Данные о трудозатратах, количестве задач и времени на рабочем месте объединили в одну систему и получили наглядную картину по отделам. |
5 | Увеличение объема заказов -> потребность в оптимизации работыС увеличением объема заказов стало недостаточно просто считать рентабельность и время нахождения людей на работе. Захотелось оптимизировать процессы так, чтобы обрабатывать больший объем заказов без расширения штата. Штат: 90 человек | Решение выявленных проблем и оптимизация работыНам стало интересно, как сделать заказы рентабельнее и сократить сроки выполнения. На этом этапе мы стали искать «тонкие места» в производстве и продумывать способы оптимизации, чтобы в дальнейшем зарабатывать еще больше. |
Рассмотрим подробнее, какую работу мы провели на каждом из этих этапов.
Начали мы с малого — ввели таск-трекер. Не стали внедрять никакие дополнительные таймеры, все делали в Redmine и собственной CRM. Это дало понимание, сколько времени уходит на конкретную задачу. Все это нормировали — появились нормативы по типам задач.
После этого установили почасовую оплату труда для разработчиков. Благодаря этим мерам у нас улучшилась трудовая дисциплина и стало формироваться понимание того, насколько проекты рентабельны.
Для учета рентабельности и контроля сроков по проектам мы давно разработали собственную систему управления проектами Canape CRM, в которой ведем все услуги компании: от разработки до продвижения сайтов.В договоре по каждому проекту прописаны сроки сдачи. Эти сроки мы визуально представили в CRM.
Менеджер четко видит, в какой срок должен быть сдан его проект, сколько осталось дней, может приостановить работу на время согласования. Это нам позволило также вывести все данные по срокам на большой монитор, который висит в центре офиса. Такая визуализация стимулирует здоровую конкуренцию между менеджерами, подстегивает разработчиков, руководители тоже обращают на эти сводки внимание и могут поинтересоваться ходом проекта.
Помимо своевременности сдачи проектов, в CRM мы также видим их рентабельность. В отчете выводится сводка по заложенным и потраченным часам по каждому договору.
На основе этих данных несложно сделать вывод об эффективности каждого менеджера. Видно, сколько каждый сдал проектов, сколько из них — в срок, сколько заработал для компании.
Это открытая статистика — сотрудники могут видеть, кто справляется лучше, а кто хуже. В CRM-системе автоматически выстраивается рейтинг.
Не секрет, что главное офисное противоборство — это противоборство менеджера с разработчиком. Как быть, если разработчик затягивает сроки по проекту? Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя. Своевременность сдачи проектов мы стали учитывать и при переводе разработчиков на следующий грейд.
В итоге мы начали отслеживать нагрузку на менеджерах и исполнителях, их эффективность и рентабельность их проектов. На основе этих данных мы формируем планы роста и развития, применяем полученные данные при финансовом стимулировании. Все это выливается в повышение уровня клиентского сервиса.
Мы видим отзывы, которые оставляют клиенты. Если не укладываемся по срокам — предупреждаем и объясняем причины. Сейчас это контролирует руководитель производства.
После предыдущего шага остались некоторые проблемы, одна из которых заключалась в том, что у нас не было данных по загрузке отделов. Мы не знали и не могли спрогнозировать, когда, например, верстальщики разгребут очереди и смогут снова брать проекты. То есть все эти данные у нас фактически были, но в разрозненном виде. Интерпретировать их правильно не получалось.
Для решения проблемы мы разработали еще один собственный внутренний сервис — Canape STAT. Система Redmine дает все данные о трудозатратах, задачах и проектах в этот сервис, где в формате тепловой карты отображаются трудозатраты и нагрузка по каждому разработчику. Это реальные трудозатраты, которые сотрудник проставил по задачам в Redmine.
При этом мы сразу видим, если где-то есть превышение, явное отклонение от необходимого объема часов, недоработки и прочие проблемные области. В нашей компании специалист должен отбивать по задачам 7 часов в день. Таким образом, руководители и специалисты видят, сколько часов отработал каждый сотрудник, заметны недоработки и переработки.
В системе можно выбрать специалиста и увидеть, над какими задачами он трудился в конкретный день, сколько часов на них потратил, какие комментарии оставил. Так можно выявить причину отклонения от норматива.
После того как мы вывели эти данные в нашу систему, потребовалось еще дополнить ее некоторой информацией, которой нам не хватало — данными о времени, проведенном в офисе. Так мы объединили систему учета трудозатрат по часам с системой контроля доступа.
Теперь мы видим, сколько времени человек потратил на задачи и сколько он находился в офисе при этом. Это позволяет исключить манипуляции с трудозатратами. Если сотрудник находился на рабочем месте 6 часов, а в задачах проставил 10 часов, у руководителя или контролирующего возникнут вопросы. Система также помогает поддерживать дисциплину труда. Мы видим, кто постоянно опаздывает, а кто приходит вовремя. Когда в офисе больше 50 человек и они рассажены по двум этажам и разным кабинетом, за такими вещами сложно уследить.
В эту же систему наши HR-специалисты заносят данные по отпускам, отгулам, больничным, заполняют производственный календарь.
Руководители и коллеги видят, когда кто уходит в отпуск или на больничный. Это упрощает коммуникации в коллективе. Вся статистика открыта для сотрудников.
Здесь же отражено плановое количество часов на каждый отдел и по каждому сотруднику, а также сколько из них реально отработано в этом месяце. Благодаря этому отделу кадров стало проще составлять отчеты. Мы смогли спланировать время на саморазвитие, когда оценили нормативное количество часов в месяц и сравнили с трудозатратами по коммерческим задачам.
Все уже выглядело достаточно хорошо, и контролировать процессы стало проще, но одна проблема никак не решалась — не получалось грамотно приоритизировать задачи. Стандартный принцип «что горит — делаем в первую очередь» не работал, потому что с таким подходом все задачи рано или поздно превращались в горящие из-за того, что постоянно откладывались ради более срочных. Соответственно, нужно было как-то понять, что делать быстрее, и кто должен принимать решения.
Чтобы решить эту проблему и дать сотруднику понимание о его загрузке, мы снова доработали Canape STAT. Теперь специалисты видят свои задачи, распределенные примерно на полторы недели вперед и могут планомерно их выполнять, учитывая оставшееся по задаче время и исполнителей внутри этой задачи.
Менеджеру и разработчику не нужно уточнять друг у друга, кто, когда и какую задачу будет делать. Все есть в системе. Задачи со статусами «Оценка» (нужно дать ответ новому клиенту) и «К выкладке» (когда нужно что-то выложить на живой сайт) по умолчанию идут первыми. Есть задачи со статусом «Не продано». Это значит, что проект точно будет запущен, на него нужно отвести время, но приступать к задаче пока нельзя, потому что какие-то данные по нему еще уточняются. В задачах также предусмотрена метка «Приоритетная» — это самые срочные задачи, и такую метку может выставлять только руководитель отдела.
Это долгий путь, который мы еще не прошли до конца. Как и в любой компании, у нас остаются «узкие» места, над которыми мы работаем. Промежуточные итоги таковы:
Последний пункт нас не очень радует, но когда мы начинали этот процесс, ни Битрикс, ни AmoCRM не было. Мы писали собственный инструмент под себя без опоры на внешние сервисы. Если бы такие проблемы стали перед нами сейчас, мы бы, конечно, искали решение на стороне, а сегодня это наше «узкое» место. На поддержание и усовершенствование системы требуется много ресурсов, сил разработчиков. Однако есть и положительный момент — это серьезный вызов для новых сотрудников. Они прокачивают свои скиллы на наших внутренних продуктах.
Самое сложно для сотрудников в нашей системе — это засекать свое время работы по задачам и прикладывать пропуск в системе пропусков. Сложно представить, чтобы кто-то не смог с этим справиться.
Директор, руководители отделов, тимлиды, линейные сотрудники, административный персонал — правила действуют абсолютно для всех. Все ведут учет трудозатрат и отчитываются о времени, проведенном на рабочем месте. Это позволяет нам точно отслеживать рентабельность проектов и стоимость внутренних задач.
Каждый может зайти в Canape STAT и посмотреть, сколько времени он или его коллега отработали по проекту, когда они приходят и уходят, сравнить себя с коллективом.
Мы доверяем сотрудникам, но контролируем их. Руководитель примерно раз в месяц проверяет дисциплину труда и, если есть систематические нарушения, проводит беседу с сотрудником. Он отвечает за перегрузку отдела, недоработки подчиненных и их низкую производительность, так как у него есть все инструменты для того, чтобы вмешаться до того, как проблема приобрела критический характер.
Достижение и повышение рентабельности — главная цель внедрения этой системы. Все инструменты в рамках этой системы ориентированы на то, чтобы получить максимальный экономический эффект от деятельности компании.
Глобальные изменения нельзя вводить скопом. Это может вызвать недовольство сотрудников, путаницу при учете. Мы интегрировали новые инструменты учета постепенно, чтобы все успели перестроиться и адаптироваться к новым условиям.
Мы постоянно переосмысливаем наши внутренние процессы, чтобы сделать учет времени более полным и менее утомительным для сотрудников. Расскажите, как это организовано у вас? Какие метрики вы используете для оценки рентабельности проектов?
Сейчас мы готовим еще один материал о том, как и для чего мы разработали собственную CRM. Подписывайтесь на канал в Telegram, чтобы не пропустить.