Привет, Хабр!

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

Откуда ноги растут?

Как обычно, все начинается с устройства человека и особенностей его поведения. В психологии есть феномен под названием «C-D gap», где «С» — это «competence», «D» — «difficulty», а «gap» — «разрыв». Когда у человека возникает разрыв между его компетенциями и сложностью стоящей перед ним задачи — это большая проблема для него. Как правило, в такой ситуации мозг пытается быстро придумать или взять извне набор простых правил для создания иллюзии управляемости хаоса. Слово «иллюзия» написано специально, потому что набором правил не восполнить недостаток компетенций, иначе все в мире уже давно стали бы супер-успешными.

Применяем науку на конкретную ситуацию

Вот растет какая-нибудь IT-компания, и вдруг у нее начинает падать рентабельность. Исходя из нашей практики общения с десятками генеральных директоров из разных отраслей экономики, самые частые причины почти у всех одинаковые, и никакого «вдруг» не бывает:

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

Да, иногда бывают тонкости, но основные причины приведены выше.

Так вот, прибыль падает, акционеры в шоке, что делать — непонятно. Здесь-то и включается феномен «C-D gap»: многие начинают «латать дыры» и включать механизм репрессий — внедрять ограничения, бюрократию и прочие экстренные меры (детали см. в книге «Русская модель управления» Прохорова). Локально это может дать небольшой прирост прибыли, но в долгосрочной перспективе приведет к уходу из компании адекватных людей.

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

Необходимый и достаточный минимум

Мы не утверждаем, что учет часов совсем не нужен, мы считаем, что он просто не должен отвлекать людей от работы.

Да, если вы работаете в агентской структуре (интегратор, рекламное агентство, веб-студия), вам придется считать бюджет по проекту и, соответственно, часы. Причины всего две:

1. в случае споров с клиентами отчеты о затраченном времени могут стать аргументом в вашу пользу;
2. вы сможете примерно понимать рентабельность по проектам.

Слово «примерно» про рентабельность проектов в агентствах написано нарочно. Исходя из опыта, точно посчитать рентабельность проекта можно только в случае полной изоляции проектной команды. Для этих целей лучше всего выделить ее в отдельное юр.лицо. Иначе любая система распределения общих затрат будет вносить свою погрешность.

Мы в своей практике используем четыре градации рентабельности проекта: «провал», «скоро провал», «хорошо» и «превосходно». Этого вполне достаточно, чтобы решить управленческую задачу выбора: отказаться от проекта, просто продолжать работу или активно развивать отношения с клиентом.

Чтобы обеспечить такую градацию, достаточно ввести простые правила:

• по итогам рабочего дня сотрудник распределяет свои 8 часов по задачам;
• квант распределения — 1 час;
• никакие штрафы и бонусы к логированию фактического времени не привязываются.

Самое главное — донести причину введения учета до всех сотрудников и убедиться, что они ее поняли. Все мы люди, со всеми можно договориться, если цель благая. Новичков надо просто сразу приучать к тому, что учет есть и это регулярная простая процедура, как почистить зубы 2 раза в день — как правило, с новичками проблем нет.

Целевая архитектура

На мой взгляд, есть два жизнеспособных метода ведения бизнеса в IT:

1. создание долгосрочных дорогих проектов под заказ (не важно, заказчик внутренний или внешний);
2. поточное производство дешевых унифицированных проектов.

В обоих вариантах проблема учета фактического времени не стоит по понятным причинам. В случае с дорогим длинным проектом команда просто вся целиком работает на один проект. Посчитать расход в этом случае — задача тривиальная. В случае с потоком большинство задач должно быть автоматизировано или детально описано инструкциями, как на кухне в сетевых пиццериях. Доля вероятностного креатива сводится к минимуму, а KPI у сотрудников становится простым — сколько десятков или сотен гаек он прикрутил за месяц. Рентабельность в этом варианте будет обеспечиваться двумя показателями: скоростью выполнения процесса, объемом входящих заявок и плавной увязкой их роста.

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

Резюме

Да, иногда учет часов нужен, но если уж он внедрен — не закручивайте гайки слишком туго.
Но, по-хорошему, при нормальной организации бизнеса, особой потребности в логировании часов нет.

PS.

Прошу прощения, забыл рассказать, что же делают достаточно сообразительные топы, когда падает рентабельность и возникает «CD gap». Все просто — они восполняют недостаток компетенций, чтобы их хватило на решение текущих задач. Т.е. либо нанимают крутых специалистов в штат, либо подключают внешних консультантов.

Автор: Gugnin

Источник