Про оценку времени выполнения задач в ИТ
Оценка и соблюдение сроков времени выполнения задач в ИТ довольно больная тема.
Недавно на Хабре вышли две статьи, и я предлагаю вынести на обсуждение довольно важный тезис — «Убедитесь, действительно ли вам нужна оценка задач, кому она нужна и какую проблему она решает?». И можно ли решить эту проблему иначе?
Внешний клиент и заказная разработка — тут больше про юридические риски и оплату. Кто-то подписывается под фиксированной стоимостью, а кто-то продаёт время.
Большая компания, много разных команд и проектов — тут больше про синхронизацию отделов и команд, внутренние конфликты и «политические игры». Может быть прозрачность и улучшение коммуникаций даст больший эффект, чем жесткие дедлайны?
Не ИТ-компания с ИТ-отделом, или небольшая компания с одной командой разработки — тут больше про недопонимание, инерцию мышления и/или подражание. «Вы не Гугл», что тут скажешь.
Моё личное мнение, что может происходить следующая цепочка событий:
Топ-менеджмент, на бизнес-обучении узнает о постановке целей по методике SMART (или по любой похожей методике), о необходимости ставить сроки и контролировать их выполнение. «Если цель не ограничена во времени, не будет ощущения срочности и, следовательно, выполнение цели растянется надолго» или в другом переводе — «Если срок забыли обозначить, то сотрудники будут откладывать выполнение задач и переключаться на другие, с понятными приоритетами во времени.»
Применение данного подхода транслируется на подчиненных, по всей цепочке должностной иерархии. Формально или не формально.
В какой-то момент, способность дать точные сроки и уложиться в них становится показателем профессионализма сотрудника.
В качестве примера, цитата из статьи
№3. В конце проскорили полученные метрики через ключевые, на наш взгляд, характеристики, определяющие эффективность производства: соблюдение сроков; …
Кажется, что профессионализм должен оцениваться как-то иначе и по разному, для разных профессий. А не единой, но более простой метрикой.
Кажется, что в ИТ, сроки нарушали, нарушают и будут нарушать.
Менеджеры могут увеличить прессинг и возможные последствия тоже известны: завышение сроков (даже для простых задач), неэффективная трата ресурсов компании на сложные методики оценки и конфликты, выгорание и текучка кадров.
Более конструктивной выглядит идея снижения важности или замены сроков на WIP-лимиты и Канбан.
И ещё одна мысль про метрики, начну с цитаты:
Итак, как же теперь использовать метрики?
Первое, чем они оказались полезны, так это тем, что ввод фиксированного набора метрик позволил нам всех заинтересованных лиц привести к одному знаменателю в вопросе понимания эффективности.
Использование метрик для понимания эффективности — это не самоцель, а промежуточный этап и хороший способ «выбить премию». Найти способ взломать метрики по KPI займёт некоторое время, была бы мотивация.
Метрики должны помогать принимать решения, правильные решения. И не всё можно оцифровать.
Вся история начинается с топ-менеджмента, которому часто нужны не столько сроки и метрики, сколько ответы на вопросы: А сотрудники хорошо работают? Не ленятся? Не врут?
Но контролировать сроки гораздо проще. Это очень традиционный и привычный способ, из очень давних времён, когда ИТ не было.
