Привет!
Когда в разговорах с айтишниками заходит речь про учет трудо-часов, холивор зажигается моментально. И не важно, с кем про это говорить: тема задевает и рядовых разработчиков, и тимлидов, и топ-менеджеров. Предлагаем на обсуждение наше видение темы с учетом часов — может, мы продвинемся немного в поисках истины в процессе обсуждения.
Откуда ноги растут?
Как обычно, все начинается с устройства человека и особенностей его поведения. В психологии есть феномен под названием «C-D gap», где «С» — это «competence», «D» — «difficulty», а «gap» — «разрыв». Когда у человека возникает разрыв между его компетенциями и сложностью стоящей перед ним задачи — это большая проблема для него. Как правило, в такой ситуации пытается быстро придумать или взять извне набор простых правил для создания иллюзии управляемости хаоса. Слово «иллюзия» написано специально, потому что набором правил не восполнить недостаток компетенций, иначе все в мире уже давно стали бы супер-успешными.
Применяем науку на конкретную ситуацию
Вот растет какая-нибудь IT-компания, и вдруг у нее начинает падать рентабельность. Исходя из нашей практики общения с десятками генеральных директоров из разных отраслей экономики, самые частые причины почти у всех одинаковые, и никакого «вдруг» не бывает:
- компания отстала от рынка и не обновляет продукты;
- отсутствует маркетинг и позиционирование;
- компания обросла не очень полезными сотрудниками;
- топы забывают считать и планировать прибыль;
- внутренние конфликты между ключевыми лицами;
- компания просто потеряла курс.
Да, иногда бывают тонкости, но основные причины приведены выше.
Так вот, прибыль падает, акционеры в шоке, что делать — непонятно. Здесь-то и включается феномен «C-D gap»: многие начинают «латать дыры» и включать механизм репрессий — внедрять ограничения, бюрократию и прочие экстренные меры (детали см. в книге «Русская модель управления» Прохорова). Локально это может дать небольшой прирост прибыли, но в долгосрочной перспективе приведет к уходу из компании адекватных людей.
Среди панических мер обычно и находится трекинг человеко-часов. Руководство хочет вычислить неэффективных сотрудников с помощью математики или просто внедрить, чтобы было, как у других. Но если вдуматься — в этом нет смысла. Все итак знают, кто работает хорошо, а кто — плохо. А если не знают — налицо нехватка компетенции.
Необходимый и достаточный минимум
Мы не утверждаем, что учет часов совсем не нужен, мы считаем, что он просто не должен отвлекать людей от работы.
Да, если вы работаете в агентской структуре (интегратор, рекламное агентство, веб-студия), вам придется считать бюджет по проекту и, соответственно, часы. Причины всего две:
- в случае споров с клиентами отчеты о затраченном времени могут стать аргументом в вашу пользу;
- вы сможете примерно понимать рентабельность по проектам.
Слово «примерно» про рентабельность проектов в агентствах написано нарочно. Исходя из опыта, точно посчитать рентабельность проекта можно только в случае полной изоляции проектной команды. Для этих целей лучше всего выделить ее в отдельное юр.лицо. Иначе любая система распределения общих затрат будет вносить свою погрешность.
Мы в своей практике используем четыре градации рентабельности проекта: «провал», «скоро провал», «хорошо» и «превосходно». Этого вполне достаточно, чтобы решить управленческую задачу выбора: отказаться от проекта, просто продолжать работу или активно развивать отношения с клиентом.
Чтобы обеспечить такую градацию, достаточно ввести простые правила:
- по итогам рабочего дня сотрудник распределяет свои 8 часов по задачам;
- квант распределения — 1 час;
- никакие штрафы и бонусы к логированию фактического времени не привязываются.
Самое главное — донести причину введения учета до всех сотрудников и убедиться, что они ее поняли. Все мы люди, со всеми можно договориться, если цель благая. Новичков надо просто сразу приучать к тому, что учет есть и это регулярная простая процедура, как почистить зубы 2 раза в день — как правило, с новичками проблем нет.
Целевая архитектура
На мой взгляд, есть два жизнеспособных метода ведения бизнеса в IT:
- создание долгосрочных дорогих проектов под заказ (не важно, заказчик внутренний или внешний);
- поточное производство дешевых унифицированных проектов.
В обоих вариантах проблема учета фактического времени не стоит по понятным причинам. В случае с дорогим длинным проектом команда просто вся целиком работает на один проект. Посчитать расход в этом случае — задача тривиальная. В случае с потоком большинство задач должно быть автоматизировано или детально описано инструкциями, как на кухне в сетевых пиццериях. Доля вероятностного креатива сводится к минимуму, а KPI у сотрудников становится простым — сколько десятков или сотен гаек он прикрутил за месяц. Рентабельность в этом варианте будет обеспечиваться двумя показателями: скоростью выполнения процесса, объемом входящих заявок и плавной увязкой их роста.
Все промежуточные варианты организации, как правило, нестабильны из-за необходимости постоянно жонглировать ресурсами и сложности в планировании загрузки сотрудников. Если ваша IT-компания находится в таком состоянии — это тревожный знак и пора задуматься о позиционировании и стратегии.
Резюме
Да, иногда учет часов нужен, но если уж он внедрен — не закручивайте гайки слишком туго.
Но, по-хорошему, при нормальной организации бизнеса, особой потребности в логировании часов нет.
PS.
Прошу прощения, забыл рассказать, что же делают достаточно сообразительные топы, когда падает рентабельность и возникает «CD gap». Все просто — они восполняют недостаток компетенций, чтобы их хватило на решение текущих задач. Т.е. либо нанимают крутых специалистов в штат, либо подключают внешних консультантов.
Автор: Gugnin
