Привет, Хабр!
Я Денис Тимощук, руководитель направления «Управление командами и задачами» в Диасофт.
На рынке разработки ПО Диасофт уже 35 лет, и за это время у нас накопилась огромная экспертиза в управлении ИT-производством. Сегодня мы управляем более 150 командами разработки, и главная головная боль любого руководителя (да и самого разработчика) — это оценка задач. Сколько времени нужно на фичу? Почему вчера на аналогичную задачу ушло 4 часа, а сегодня – гораздо больше? И главное — как объяснить заказчику, почему сроки сдвигаются?
Мы перепробовали много способов: от сторипоинтов до экспертных оценок «взглядом сверху». Но настоящий прорыв случился, когда мы вместо «сколько времени нужно?» стали спрашивать команду «какие типовые работы вы будете делать?». В этой статье я расскажу, как нам удалось снизить время на выполнение типовых работ в 2 раза за первый год и превратить нормирование из бюрократической обузы в инструмент масштабирования эффективности.
Проблематика: треугольник хаоса
В классическом управлении проектами есть три кита: сроки, бюджет и объем работ. В реальности в ходе разработки часто нарушалось все и сразу. Я выделил три главные зоны потерь:
Неточность оценок. Мы часто путаем «сложно» с «долго». Разработчик говорит: «займет, ну, часа 4», подразумевая написание кода. Но при этом он не учитывает аналитику, тестирование, релиз и деплой на стенд клиента. Погрешность в таких случаях колоссальная.
Оценка больших проектов. Когда перед нами проект на несколько месяцев, попытка оценить его целиком — это гадание на кофейной гуще. Риски раздувают бюджеты и делают проект непривлекательным для бизнеса.
Переговоры с заказчиком. Когда оценка размыта и непонятно из чего состоит, заказчик закономерно пытается ее оспорить. Начинаются долгие переговоры, которые выматывают обе стороны и подрывают доверие.
Мы поняли: проблема не в людях, а в подходе. Невозможно эффективно управлять тем, что нельзя измерить и декомпозировать.
Нормативы как новый язык общения
Решение «Нормирование задач» (входит в состав производственной платформы Digital Q.Management) – не просто очередной плагин для Jira или трекера задач. Это смена парадигмы.
Мы предложили командам больше не указывать абсолютные величины времени на задачах. Вместо этого мы ввели понятие «норматив». Норматив — это небольшая типовая работа с фиксированной трудоемкостью, которая уже включает в себя полный цикл: от постановки аналитика до кода, тестов, релиза и деплоя на стенде клиента.
Сердце системы – Справочник нормативов. Для каждой архитектурной линейки (микросервисная, двухзвенная, трехзвенная, мобильная разработка) мы выделили 15-20 типовых работ, которые свели к понятным типам: API или серверная процедура; форма интерфейса; отчетная форма и т.д.
У каждого норматива есть три уровня сложности (простой, средний, сложный) с четким описанием отличий. Например, «простой API» — это метод без сложной валидации, а «сложный» — уже с транзакциями и сложной бизнес-логикой.
Важно: Трудоемкость норматива взята не с потолка, а сформирована на основе опыта ведущих разработчиков «Диасофт». Это эталон, к которому мы стремимся.
Как это выглядит на практике
Теперь разработчик получает задачу и выбирает типовые работы, которые предстоит выполнить в ее рамках: создание API – 8 часов, форма договора – 6 часов, конвертор данных – 1 час. Итоговая оценка считается и складывается автоматически.
Такой подход дает нам несколько преимуществ:
Прозрачность для заказчика. Вместо абстрактной цифры он видит список конкретных работ. Если бюджет ограничен, мы можем перенести какие-то работы в следующий релиз.
Объективность. Оценка перестала зависеть от настроения или квалификации конкретного разработчика. Мы опираемся на набор типовых работ.
Артефакты нормирования. Мы нормируем задачу до начала реализации. Это значит, что архитектор или тимлид видят план работ заранее и могут вовремя его скорректировать, что позволяет избежать написание лишнего кода.
Еженедельно мы смотрим, как команды справляются с задачами: сравниваем, как разные команды выполняют один и тот же норматив. Отстающие команды получают помощь от лидеров. Мы буквально «подтягиваем» слабых к сильным.
Если по какому-то нормативу наблюдается постоянное превышение трудозатрат, эксперты ищут причину. Возможно, этот тип работ требует автоматизации или пересмотра архитектурного подхода.
За первый год применения подхода мы снизили время на выполнение типовых работ в 2 раза.
С какими сложностями мы столкнулись
Когда мы только начинали внедрять нормирование, казалось, что главная сложность – написать виджет и собрать справочник нормативов (как же мы ошибались!). Разработчики говорили: «Я программист, а не оценщик», «Зачем мне это, я и так знаю, сколько нужно времени», «Нормативы — это для конвейера, а мы тут творчеством занимаемся». Убедить людей, что нормирование не отнимает свободу, а дает прозрачность и защиту от бесконечных правок, оказалось непросто.
Также столкнулись с техническими сложностями: как сделать так, чтобы виджет не бесил? Как встроить его в уже сложившийся workflow, а не заставлять команды делать лишние движения? Как собрать данные так, чтобы они были полезны, а не просто лежали мертвым грузом? Мы перебирали варианты интеграции, переписывали интерфейс, настраивали автоматические рассылки для тех задач, которые «зависли» без нормирования.
При этом, мало внедрить инструмент – нужно, чтобы он стал частью ритма. Мы начали использовать спринты как естественный цикл для анализа нормативов. В конце каждого спринта смотрим: какие нормативы превышали план, какие команды справляются лучше, где нужна помощь. И постепенно превратили это из контроля в поддержку.
Бонус: геймификация
Когда мы добавили рейтинг команд на производственный дашборд, случилась магия. Команды начали не просто соблюдать процесс, а соревноваться. Кто точнее нормирует? У кого меньше превышений? Кто быстрее закрывает типовые работы? Это превратило нормирование в командный вызов. Люди сами стали предлагать, какие нормативы пора пересмотреть, где можно автоматизировать рутину.
Вывод
Нормирование задач — это не про контроль ради контроля. Это про честность перед заказчиком и уважение к своему времени. Это возможность для джуниора быстро выйти на уровень лидера, имея перед глазами четкий стандарт работ, а для лидера — масштабировать эффективность без выгорания команды.
Мы в Диасофт не просто разрабатываем софт, мы строим предсказуемое ИT-производство. Наш опыт показывает, что даже в такой творческой сфере, как разработка ПО, системный подход к оценке дает колоссальный результат.
Если хотите глубже погрузиться в тему, можете посмотреть наш вебинар, где мы разбирали кейсы внедрения более детально. Запись доступна по ссылке.
О том, как мы проектировали архитектуру виджета, интегрировали его в трекеры задач, настраивали аналитику и параллельно выстраивали «человеческий» подход, расскажу в следующей статье.
А как вы боретесь с превышением первоначальных оценок в ваших командах? Используете ли вы нормативы или полагаетесь на экспертное чутье? Делитесь опытом в комментариях!
