Все встречи

Встреча сообщества – 26 марта 2026

Основная тема: Нормирование труда в IT: применимость промышленных метрик к разработке, системы измерения продуктивности, миф о «творческой профессии», декомпозиция задач и баланс между предсказуемостью и эффективностью.
Содержание
  1. Подтемы
  2. Участники
  3. Различные мнения
  4. Основные выводы
  5. Что обсудим дальше

Подтемы и их суть

  1. Определение нормирования труда

    Участники начали с того, что плавают в терминологии, и загуглили определение: нормирование – процесс измерения затрат труда на единицу изделия. Андрей подчеркнул: это инструмент планирования, а не контроля. Нормирование работает при повторяемости процессов и имеет смысл только в контексте конкретной компании.

  2. Применимость нормирования к IT

    Ключевая дискуссия. Андрей: проблема не в уникальности IT-задач, а в порочной бизнес-модели – только 20-30% работы реально уникальны, остальное типовое (авторизация, формы, интеграции). Артур возражал: даже типовая задача в контексте разных архитектур имеет нюансы, разброс сложности гигантский. Андрей парировал: крупные компании имеют и нормы, и инновации одновременно.

  3. «Программирование – не творческая профессия»

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

  4. Нормы в других IT-дисциплинах

    Тестировщики нормируются (полный регресс = 12 часов – измеримо), дизайнеры нормируются (знают выработку по экранам), на собеседованиях норма – 2 задачи за час. Только разработчики «сопротивляются». На галерах работает норма «один тикет в день» при атомарной декомпозиции. Андрей: дизайнеры как профессия организованнее программистов, потому что их заработок зависит от выработки.

  5. Система метрик PanDev

    Артур рассказал про PanDev – систему трекинга продуктивности. Четыре показателя: Delivery Index (процент времени, дошедшего до merge requests), точность планирования (план vs факт), количество задач, КПД merge request (процент файлов, попавших в итоговый MR). Олег поделился проблемами: не трекается работа в нескольких IDE, проблемы с VPN. Андрей критиковал: это метрики процесса, а не результата.

  6. Декомпозиция: атомарность vs эффективность

    Артур: опытный фронтендер оценил рефакторинг в 8 дней, ушел и вернулся с готовым результатом – зачем дробить? Андрей: если задача большая и неделимая – это сигнал отсутствия экспертизы, нужен пилот. Василий резюмировал: мы меняем эффективность на предсказуемость и управляемость – это сознательный компромисс. Без предсказуемости бизнес зависит от героизма.

  7. Стартапы и нормирование

    Артур признал: давление стартапа приводит к сокращению углов. Андрей процитировал: «Если у вас в стартапе нет планирования, проблема не в стартапе, а в плохом управлении». Нормирование позволяет не зависеть от «героических» сотрудников. Без нормирования нельзя «самоустраниться» из бизнеса – он останется лайфстайл-проектом.

  8. Острова экспертизы и интеграции

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

Участники

Андрей Организатор (Франция), защитник нормирования
Артур Норма «4 часа кодинга в день», клиент PanDev, опыт стартапа
Василий Инициатор темы, оценка по связям сущностей
Эдельбек
Олег
Данил

Различные мнения

ВопросАндрейАртурВасилий
Нужно ли нормирование?Однозначно да, инструмент планированияДа, но 4 часа кодинга – достаточная метрикаНужно, но непонятно как
Творческая профессия?Категорически нет, это уход от ответственностиТворчество – в проектировании, не в кодеБольшинство решений шаблонизированы
Атомарная декомпозиция?Да, крупные задачи – сигнал отсутствия экспертизыНе всегда, 8 дней на рефакторинг – нормальноКомпромисс: эффективность vs предсказуемость
Метрики?Нужны метрики результата, не процессаPanDev: delivery index + точность планированияОценка по связям сущностей

Основные выводы

Нормирование возможно

Нормирование – инструмент планирования, не погонщик с барабаном. Дизайнеры и тестировщики нормируются давно. Проблема не в IT как отрасли, а в нежелании менеджмента управлять рисками.

Уникальность преувеличена

80% работы типовая: формы, интеграции, CRUD, авторизация. «Уникальный продукт» часто прикрывает отсутствие процессов. Крупные компании совмещают нормы и инновации.

Процесс vs результат

Часы кодинга – метрика процесса. Delivery Index (код, дошедший до production) ближе к результату. Идеал – комбинация усилий, результата и точности планирования.

Предсказуемость vs эффективность

Атомарная декомпозиция повышает предсказуемость за счет эффективности – время на планирование. Без предсказуемости бизнес зависит от героизма, а это не масштабируется.

Хотите обсудить эти темы с практикующими тимлидами?

Обсудить в Telegram
Следующая встреча

Каждую среду в 17:00 Астана, UTC+5