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

Давайте серьёзно: оценки и списания — это инструменты прогнозирования и анализа проблем. Если бы все ИТ-команду всегда укладывались в сроки, эти вопросы бы не возникали. Но реальность другая: менеджеры ругаются на разработчиков, разработчики — на «чайка-менеджеров», а в итоге, по опросу в моём канале, 50% компаний либо не учитывают затраты вовсе, либо делают это формально.

Почему это важно и какой стороной это к управлению командой? Оценка — это планирование работы, а списание — это учет фактических затрат. Вместе, при правильной настройке, они дают замечательную прозрачность и прогнозируемость работы ИТ-команды.

В статье ниже я собрал основные подходы, выделил их плюсы и минусы, а в конце, опираясь на свой опыт (25+ лет внедрения проектов и несколько лет развития собственного продукта для управления IT-командами), делаю вывод о наиболее эффективном подходе.

Эта статья — обобщение идей, обсуждавшихся в моём Telegram-канале «Морковка спереди, морковка сзади». Если вам интересно проектное управление в IT и все проблемы, с ним связанные — заходите и подписывайтесь, а также читайте другие мои статьи здесь, на Хабре.

Зачем вообще нужны оценки и списания?

Есть оценки в попугаях, есть в человекочасах, а есть оценка по средней статистике исполнения аналогичных задач. Есть списания в табелях, есть в трекере, а бывает так, что и вовсе нет никаких списаний. Как правильно?

Для начала надо понять, зачем все это нужно: оценка и списания – это инструменты план/фактного анализа, который нужен менеджерам для:

• прогнозирования сроков готовности;

• разбора проблем по факту нарушения сроков.

Причем менеджер в данном случае – это не только РП и его начальники, но и тот исполнитель, который делает задачу. Любой, кто берёт в работу задачу и сообщает срок, уже управляет этой задачей. А значит, должен понимать, как его оценка соотносится с реальностью.

Итог 1: учитывать точность оценок и попадание в них — важно. Это полезно и исполнителям (на уровне задачи), и менеджерам (на уровне проекта), и руководству (на уровне портфеля проектов).

Давайте теперь разберемся с оценками и списаниями по порядку

Основные способы оценки задач

1. Оценка в человеко-часах

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

2. Оценка в story points

   Метод используется как замена способу выше, чтобы не так напрягать исполнителя точной оценкой при неточной постановке. Может быть оправдан, но часто приводит к снижению точности оценки и ухудшению качества планирования. Например, команда может договориться, что небольшая задача – 1 пойнт, средняя – 3, а крупная – 5, но без привязки к реальному времени могут возникнуть проблемы с загрузкой команды (сделали раньше и пинали балду). Ну и самая главная проблема в этом подходе будет дальше.

3. Оценка на основе статистики

   Метод применяется в крупных проектах с однотипными задачами: время выполнения новых задач прогнозируется на основе данных о предыдущих аналогичных. В теории звучит хорошо, но в реальности задачи по доработке ИТ систем крайне редко бывают идентичными. Средняя оценка неизбежно исключит отклонения, что приведет к срывам плановых сроков и никто не будет причем, это просто метод такой. Отдельно — крайне узкая область применения. Поэтому данный метод выглядит экзотикой, которая неприменима в реальности (если у кого то есть реальный опыт успешного применения — добро пожаловать в комментарии, обсудим).

Сравнивая первые два подхода, я выбираю первый, так как:

1. Оценивая в сторипойнтах, я снимаю с разработчиков ответственность за оценку, но тем самым я избегаю правильных вопросов, которые стоит задать ДО начала разработки. Например, можно уточнить постановку или сделать допущения, которые позволят ограничить ее объем — это работа аналитиков и менеджера. Так может быть лучше не спихивать эту проблему на разработку, прикрываясь неточной оценкой, а решить ДО начала разработки?

2. Оценка в часах выявляет проблемы: если исполнители серьезно завышают оценки — они не доверяют менеджеру (об этом писал Голдратт в «Критической цепи»), если постановки слабые — есть проблемы с аналитикой. Это не повод избегать оценки, а повод разобраться и исправить.

3. Оценка в часах даёт более точное планирование, особенно если ресурсы распределяются динамически.

4. Ну и мотивация команды: исправляя пункты 1 и 2 вы получите команду, которая будет гораздо более мотивирована работать с вами, как с менеджером. Ведь вы не просто пихаете ответственность, а вы помогаете работать. Это всегда ценится!

Итог 2: оценивать лучше в человеко-часах. Если не получается, стоит разобраться в причинах, а не переходить на заменители.

Как правильно списывать время

По данным опроса в моём Telegram-канале:

• 43% сотрудников фиксируют время в трекере,

• 28% не ведут учёт времени,

• 14% используют таймшиты,

• 5% списываются в Экселе (внимание, 2025 год!!),

• 10% не фиксируют время из-за работы с подрядчиками.

То есть 28% просто не учитывают фактические затраты, а 19% учитывают их формально (почему формально — читайте дальше). Так может быть и не надо учитывать время, тем более, если всех это раздражает?

Что вы теряете без учёта времени?

1. Вы не знаете, насколько были точны ваши предварительные оценки.

2. А значит, у вас нет шанса исправить ошибки в оценках.

3. А значит вы не можете прогнозировать выполнение работ в срок.

4. А значит, вы не управляете рисками, а надеетесь на «авось».

5. Вы не понимаете текущего состояния по работам, вам нужны ДЕЙЛИКИ (hint: без дейликов можно отлично обходиться).

Итог 3: списание времени лучше вести.

Какие же способы списаний времени есть и какой предпочтительнее?

1. Использование табелей и таймшитов.
   Лидер по недостоверности учета. По таймшиту исполнители списываются строго формально: «сколько часов выделено, столько и списываю». Я и сам так списывал, когда был исполнителем. Фактические данные могут выглядеть идеально (100% утилизация, высокая эффективность), но что творится под капотом таких списаний – никто не знает.

   

2. Списание фактически затраченного времени.
   Идеальный баланс: не требует много времени, в тоже время достаточно близко к реальному времени, затраченному на задачу.

3. Учет времени по кнопке с секундомером.
   Максимально точный учет. Исключает любые простои в части «пошел за кофе», «вышел на обед» и так далее, но требует постоянных действий с секундомером, что раздражает, плюс, надо еще и описывать, что было сделано. Такая детализация явно избыточна даже для фриланса.

Я являюсь большим сторонником баланса и решения 80% задач через 20% усилий, поэтому вариант со списанием времени в трекере по факту выполнения или по итогу дня выглядит оптимальным. С одной стороны, все участники процесса видят состояние работы и могут корректировать планы, с другой, исполнителя не грузят излишним контролем и бюрократией, предоставляя свободу.

Как правильно списывать:

1. В списанное время должны включаться паузы на «попить кофе», созвоны с архитектором по задаче, прояснение деталей с аналитиком и даже участие в тестировании (и да, оценка тоже это должна учитывать, если исполнителю так комфортно. Без фанатизма, разумеется :)

2. Частота списания времени — раз в день или по факту закрытия задачи. Практика показывает, что это хороший баланс, чтобы не частить, списывая каждый час, но и не переводить списание в профанацию, где исполнителю приходится судорожно вспоминать, а что он делал 5 дней тому назад.

Итог 4: списывать надо в часах и списывать надо ежедневно.

Подводя итог

1. Оценки по задаче должны быть и лучше — в человекочасах.

2. Списание времени по задаче учитывать надо и лучше — в человекочасах.

3. Списания через таймшиты – зло, они должны уйти вместе с 20м веком в прошлое.

4. Механизм оценок и списаний нужен:

   1. Исполнителям для фокусировки на сроках и защиты от чайка-менеджеров.

   2. Менеджерам для контроля исполнителей, улучшения коммуникаций и работы с рисками.

   3. Топам – для контроля план/факта и понимания, что у них реально (а не по мнению их менеджеров) происходит.

5. Списывать время надо раз в день или при закрытии задачи, и этого достаточно.

6. Все проблемы этого механизма вполне решаются через коммуникации между РП и командой.

7. Если у вас есть непреодолимые проблемы на пути внедрения этого подхода, скорее всего, это именно те проблемы, которые и надо решать для повышения производительности вашей ИТ команды.

Еще раз оговорюсь: это видение мое, как эксперта с большим опытом собственных внедрений, опытом управленческого консалтинга, а также итог обсуждений в ТГ канале, например вот тут. Это не означает, что данное мнение является истиной в последней инстанции (проекты могут быть уникальны). Если ваш опыт отличается от указанного в статье – добро пожаловать в комментарии к статье – обсудим!