В новой статье хочу попробовать новый формат. Надеюсь, что в новом виде материал возымеет больше интереса и лучше получится донести ключевые мысли и тезисы.
Итак, представляю на ваш суд пьесу "Неэффективная эффективность" в 13 частях от продуктового лидера с 20-летним опытом, который так и не смог решить маленькую проблемку.
1. Кажется, что-то не так
Я хорошо помню момент, когда классический подход в оценке эффективности команды разработки стал меня смущать. Появилось недоверие к цифрам и метрикам. Не потому, что они были плохими. Наоборот, всё выглядело красиво и правильно.
Velocity стабилен. Burn down chart горит. Story points закрываются. Команды работают по процессу. Планирование, стендапы, демо, ретро, всё отлажено. Дашборды зелёные.
Но внутри нарастало ощущение, которое сложно формализовать: я больше не понимаю, стало ли лучше. Есть ли положительная динамика, растёт ли эффективность?
Цифры отвечали «да», но чувства подсказывали, что есть НО… Опыт предательски молчал.
И именно это молчание стало для меня самым тревожным сигналом.
2. Когда бежишь, ты не считаешь шаги
Есть огромная разница между молодыми продуктами и зрелыми. В ранних продуктах вопрос эффективности не возникает вообще. Фокус смещён на выживание, скорость, поиск ценности. Когда ты бежишь, ты не считаешь шаги.
Но по мере взросления продукта меняются обстоятельства, меняются внутренние потребности. Происходит переход, который компании редко осознают, а вовремя, практически, никогда.
Из-за большого количества быстрых изменений сложность продукта растёт. Команд становится больше, процессы усложняются. Каждое изменение начинает требовать всё больше контекста: архитектурного, бизнесового, исторического.
И в какой-то момент ты начинаешь ловить себя на мысли: мы вроде бы делаем не меньше, но каждое новое движение даётся всё тяжелее, дороже, дольше и получается хуже.
Вот здесь и появляется вопрос эффективности. Поздно. Не сразу. Но неизбежно.
3. Результативность — не эффективность
Первое, что приходит в голову: "раньше мы могли делать по 5 фичей в неделю, а сейчас нет. Надо вернуть!". Но это про результативность, а не про эффективность.
Результативность показывает сколько мы сделали.
Эффективность - какой ценой.
Как ни странно, компании и менеджеры долгое время подменяют одно другим. Это приводит к ещё большему росту команд, появляются новые роли: фасилитаторы, скрам-мастера, менеджеры проектов, менеджеры продуктов, продакт-оунеры и многое другое. Сложность и издержки растут, как снежный ком.
Можно быть очень результативными и при этом:
выжигать команды,
раздувать сложность,
откладывать проблемы "на потом".
Компании чаще всего сначала лечат именно результативность: «Давайте делать больше». А эффективность приходит как запоздалый диагноз.
4. Без Story points как без рук
Переход к оценкам задач через Story points является значимым, сложным и, пожалуй, крайне необходимым шагом на пути эволюции каждой компании.
Человеко-часы слишком субъективны, потому что:
люди разные,
скорость разная,
часы врут.
Каждый раз приходилось ретроспективно сопровождать оценку контекстом. Поэтому мы договорились считать относительную сложность.
Самое главное и самое сложное это выбрать эталонную задачу. Всё остальное сильно проще. Берём числа Фибоначчи: чем сложнее, тем больше шаг оценки. Синхронизировали понимание в команде, между командами.
И какое-то время это действительно работает. Первое время даже кажется, что это идеальная схема и таким способом можно управлять эффективностью разнородных команд. Создаётся ощущение, что можно даже сравнивать эффективность разных команд.
Красота!
5. "А король-то голый!"
Проблема подкрадывается незаметно.
Мы делаем «простую» задачу. Быстро. С компромиссами. Чуть-чуть увеличиваем технический долг. Ничего страшного, кажется нам, обычное дело.
Проходит время. Мы берём такую же задачу. И внезапно она уже не такая простая. Продукт стал сложнее. Зависимостей больше. Контекста слишком много.
Формально это всё ещё один story point.
На практике это уже совсем другая работа.
И в этот момент наша линейка плывет...
6. Жидкий эталон
Закономерно возникает парадокс: мы используем story points, чтобы работать над эффективностью, но наши же решения:
накапливают технический долг,
усложняют архитектуру,
меняют контекст,
и незаметно изменяют саму эталонную единицу измерения.
Вчерашний story point ≠ сегодняшний.
Мы сравниваем цифры, но не можем быть уверены, что сравниваем одно и то же. Это как пытаться измерить расстояние линейкой, которая с каждым днём становится чуть короче. Или длиннее. Мы не знаем.
7. Технический, бизнес- и дизайн-долг — это одна система
Со временем я перестал разделять долги на отдельные категории.
Технический долг увеличивает стоимость изменений. Бизнес-долг ломает логику требований. Дизайн-долг усложняет реализацию простых идей.
Они не существуют отдельно друг от друга. Они усиливают друг друга, как резонанс. И каждый из них делает эталонную задачу тяжелее, даже если в метриках это не отражается.
Я видел проекты, где команда говорила: "Мы работаем быстро!". И цифры их подтверждали. Но под капотом копился хаос, который через полгода взорвётся и парализует всю разработку.
Velocity показывал стабильность. А продукт превращался в минное поле.
8. Плоскость эффективности
Мой опыт привёл меня в точку, где я решаю вопрос эффективности не на линейной шкале, а в двумерной системе координат (пока двумерной):
Сложность продукта.
Архитектура. Наследие решений. Долги всех мастей.Процессы.
Коммуникации. Качество требований. Согласования. Ритуалы.
Мы можем улучшать процессы и закрывать больше задач. Мы можем чистить архитектуру и чувствовать облегчение.
Но обе эти работы искажают метрики, как кривое зеркало.
Компании часто фокусируются на одной оси: либо пилят процессы, либо рефакторят код. А эффективность живёт на пересечении. И если ты движешься только по одной координате, ты не видишь реальной картины.
9. “Видишь прогресс? - Нет. - А он есть!”
Иногда команда делает огромную работу:
рефакторинг,
переработка архитектуры,
наведение порядка в процессах.
В цифрах, практически, ничего не меняется. Velocity стоит на месте. Story points те же. И появляется опасная мысль: «Значит, мы не стали эффективнее».
Хотя на самом деле:
система стала здоровее,
будущие изменения будут дешевле,
риски будут ниже.
Просто метрика этого не показывает.
Это как с профилактикой здоровья. Ты бегаешь, правильно питаешься, высыпаешься. Анализы не показывают драматических изменений. Но ты не заболел. А мог бы. Только как это измерить? Как посчитать болезнь, которая не случилась?
10. Как оцифрорвать ощущения?
Если у тебя одна команда, то ты все чувствуешь. Ты видишь. Ты понимаешь без цифр. Но когда команд 20, 30, 50 , то интуиция перестаёт работать.
Тебе нужен «пульт управления». Метрики. Дашборды. И здесь возникает управленческая трагедия: нам нужны цифры, механизмы, которым мы не можем полностью доверять.
Мне довелось несколько раз наблюдать это в разных компаниях: чем больше организация, тем сильнее потребность в метриках. И тем меньше эти метрики отражают реальность. Это как смотреть на город через спутник: ты видишь общую картину, но не видишь, что творится на улицах.
Топ-менеджмент требует цифр. Менеджеры дают цифры. Все делают вид, что понимают, что они значат.
11. Кризис веры
Со временем я перестал верить:
в универсальную метрику эффективности,
в честный velocity без контекста,
в цифры как окончательный ответ,
в то, что если цифра зелёная, то всё хорошо.
Зато я начал верить в другое:
в динамику сложности,
в качество архитектурных решений,
в ясность требований,
в честные разговоры о долгах,
в команды, которые могут сказать "мы тормозим, потому что надо разобрать завалы".
Я начал верить в то, что эффективность - это не цифра в дашборде, а способность организации, команды, руководителя честно смотреть на себя и не врать.
12. Эффективность как вопрос, а не формула
Сегодня я не могу предложить формулу эффективности.
Но я точно знаю вопросы, которые стоит задавать:
Что стало проще по сравнению с прошлым годом?
Где мы ускорились, а где просто изменили масштаб?
Какую цену мы платим за скорость через полгода?
Можем ли мы развернуть фичу за день? А месяц назад могли?
Сколько человек нужно собрать, чтобы принять решение? А год назад?
И, возможно, эффективность это не то, что можно точно измерить. А то, что нельзя перестать осмыслять. Это непрерывный диалог с реальностью, а не очередной отчёт.
13. Эпилог
Если у вас есть метрика, которая:
не плывёт,
не меняется со временем,
не врёт,
показывает реальную эффективность, а не её иллюзию,
Пожалуйста, поделитесь. Я всё ещё ищу.
И, кажется, уже понял, что поиск этой метрики не баг, а фича. Потому что в момент, когда ты найдёшь идеальную формулу, ты перестанешь думать.
А думать, пожалуй, это единственное, что по-настоящему делает нас эффективными.
Комментарии (16)
MEGA_Nexus
22.12.2025 09:55Velocity, Story points...
И, кажется, уже понял, что поиск этой метрики не баг, а фича. Потому что в момент, когда ты найдёшь идеальную формулу, ты перестанешь думать.Побуду капитаном очевидностью. Чтобы выполнить работу, нужно начать делать работу. Не придумывать метрики, не заниматься излишним планированием, не тратить время на бесконечные митинги, а просто выполнять работу. Чем больше работы выполнил, тем меньше её осталось. Не нужно ни с кем соревноваться, планировать закрытие задач к определённому сроку или празднику. Просто начните уже делать работу. Когда она будет сделана, тогда и будет готова. Да, вот так всё просто.
К сожалению, Scrum (а Velocity и Story points это атрибуты Scrum'а) породил кучу ритуалов и метрик, которые в последствии подменили собой цель. Теперь не важно, какой результат у тебя в конце получится, а важно, что ты соблюдаешь все ритуалы Scrum. В общем, типичный карго-культ.
Так как же тогда работать? Всё просто. Начните использовать в работе Канбан, а не Scrum. 1 раз в неделю собирается несколько человек, например, лид + аналитик + СТО и решают, какие задачи для них важны на эту неделю. А затем нарезают задачи в to-do, откуда исполнители их тягают себе по мере того, как выполняют свои текущие задачи. Сколько за неделю успели сделать, столько и будет. Не надо никуда спешить, ни на что отвлекаться. Взял задачку из to-do и выполняешь её в однозадачном режиме. Выполнил задачу, переместил её в done или тестирование, чтобы её потом себе взяли тестировщики. Взял другую задачу для решения.
Если задач до конца недели не хватило, т.е. сделали всё быстрее, то лид + аналитик + СТО нарежут ещё задач. Если какие-то задачи остались, то они переносятся на следующую неделю без каких-либо наказаний и глумлений. Работа - это поток. В этом и есть суть Канбан. Это сложно понять тем, кто привык к постоянной гонке в виде спринтов. Но если понять суть Канбан, то работать становится намного приятнее и комфортнее.
Smozub Автор
22.12.2025 09:55Отлично все описали. А теперь поставьте себя на место СТО и попробуйте ответить на несколько вопросов:
- нужно ли расширять штат, чтобы успевать сделать больше задач?
- можно ли текущим составом делать больше?
И команд не 1-5, а штук 50.
А задается этими вопросами СТО, потому что надо оставаться конкурентноспособными на рынке, надо держать рентабельность бизнеса, а еще и в будущее заглядывать и соломки подстилать.MEGA_Nexus
22.12.2025 09:55- можно ли текущим составом делать больше?
Да, можно. Для этого необходимо устранять потери в работе, т.е. делать то, что реально приносит пользу. А то, что пользы не приносит, делать не нужно. Потери называются японским словом муда.
- нужно ли расширять штат, чтобы успевать сделать больше задач?
Смысл не в том, чтобы делать больше задач, а в том, чтобы делать только те задачи, которые реально приносят пользу бизнесу.
Касательно измерения скорости работы, то это делается легко. Берётся любой интервал времени, например, неделя, месяц или даже полгода и смотрится, сколько задач текущая команда выполняет за неделю или месяц. Это и будет производительностью команды.
И команд не 1-5, а штук 50.
Канбан работает во многих компаниях. Родоначальником Канбан является компания Тойота, которая насчитывает около 380 000 человек (по состоянию на 2024-2025 год). Заводы и операции Toyota присутствуют в более чем 170 странах. Так что управление 50 командами - это так, лёгкая разминка.
Также замечу, что СТО не управляет 50 командами и даже не управляет 50 руководителями этих команд. СТО управляет 5-6 руководителями управлений\департаментов, а они в свою очередь управляют руководителями групп, которые уже непосредственно управляют своими группами.
А задается этими вопросами СТО, потому что надо оставаться конкурентноспособными на рынке, надо держать рентабельность бизнеса, а еще и в будущее заглядывать и соломки подстилать.
Если вы используете Канбан и придерживаетесь принципов бережливого производства (lean), то всё это будет доступно из коробки. Для примера, вы можете внедрять новый функционал в 2 раза быстрее, чем конкуренты и тратя на это в 2 раза меньше усилий. При таком раскладе при любом кризисе на рынке вы останетесь на плаву, а конкуренты нет.
Если рынок поменяется, то опять таки вы сможете быстрее к этом адаптироваться, т.к. выпускаете функционал в 2 раза быстрее и тратя на это в 2 раза меньше усилий.
MEGA_Nexus
22.12.2025 09:55Ещё пара слов о проблемах со Scrum.
Scrum - это работа спринтами, т.е. предполагается, что команда на 1-2 неделю берёт себе некий объём задач и обязуется его выполнить к концу спринта. Кроме психологического давления в виде дедлайна, есть ещё проблема срочных задач.
Как только прилетает срочная задача от вышестоящего руководителя, весь спринт ломается нафиг и начинаются адские переработки, чтобы втиснуть в уже начавшийся спринт эту срочную задачу. Так как у руководителей команд, как правило, нет яиц, чтобы сказать нет, то лишняя задача становится проблемой исполнителей, что ведёт к их выгоранию, недовольствами и будущим конфликтам.
В Канбан с этим намного проще. У исполнителя установлен лимит в 2 активные задачи (WIP - Work in Progress). Исполнитель сосредоточен на выполнении одной задачи. Выполнил одну задачу, взял себе другую задачу.
И вот прилетает срочная задача. Что делает исполнитель в Канбан? Он просто заканчивает свою текущую задачу, т.е. доводит её до логического конца, после чего вместо второй задачи, которая у него была в In Progress, берёт эту срочную задачу и решает её как обычную задачу. Решил эту срочную задачу и потом вернулся к оставшейся в In Progress задаче.
В канбан можно спокойно поменять порядок выполнения задач. Попалось 2 срочные задачи - ок, сделаю их. Исполнителю в целом всё равно, обычная это задача или срочная, т.к. у исполнителя нет обязательств выполнить какой-либо объём работы в конкретному сроку. Нет никакой разницы, было выполнено 10 обычных задач или 8 обычных задач + 2 срочные.
При работе с Канбан намного проще планировать нагрузку, проще видеть производительность команды и отдельных её участников. А визуализация в виде досок Канбан позволяет руководителю видеть все пролбемы и своевременно их решать.
Также важный момент. В Канбан все видят работу каждого, т.е. если у кого-то затор в работе, то любой может подойти к нему и помочь. Также нет необходимости проводить утренние стендапы, т.к. все в любой момент видят работу каждого. Для этого достаточно подойти к доске Канбан. 100% прозрачность.
Если приходит высокий босс и говорит, что вы все пи....сы и ничего не делаете, то его можно подвести к Канбан доске и показать, какие задачи были выполнены вчера, позавчера, или даже неделю задач. Показать, какие задачи сейчас в работе и какую пользу они приносят бизнесу. После этого все вопросы к команде, как правило, отпадают.
В Scrum же каждый нацелен только на то, чтобы решить свои собственные задачи к концу спринта и чужие задачи его мало интересуют. Ведь если он не успеет выполнить свою работу, то придётся потом оправдываться.
Smozub Автор
22.12.2025 09:55Очень классно описали преимущества канбана и проблемы скрама для отраслей и ситуаций с высокой степенью неопределенностью, для задач с отсутствием внешних обязательств, давления и дедлайнов.
Для некоторый компаний и некоторых выбранных стратегий канбан действительно лучший выбор.
Тот же самый пример с Тойотой прекрасно это демонстрирует. Фокус на процесс был сквозной для всей компании, это лежало в основе стратегии. Это же и отразилось на продукции - автомобили стали эталоном надежности и сочетанием цены и качества. Этим они завоевали свою долю рынка. Но это не единственная успешная стратегия в автомобильной отрасли. Европейцы ставили на высокотехнологичность и были в этом сильнее японцев, но уступали в качестве. Итальянцы брали дизайном, но уступали во всем остальном. И европейцы, и итальянцы работали не по канбану и у них было совсем другое отношение к процессу работы.
Но организации разные и выбор методологии зависит от внутренних потребностей, компетенций и обстоятельств.
Чем меньше вокруг уровень неопределенности, тем больше ценится прогнозируемость, планируемость и попадание в срок с заявленным объемом и качеством.
Учитывая текущую ситуацию в мире и в РФ в частности, канбан для большинства малого/среднего/крупного бизнеса будет, действительно, оптимальным выбором. А вот корпорациям, госпредприятиям и компаниям со сложными продуктами надо выбирать методологии с большим количеством точек контроля.
Но изначально статья была не о том, какая проектная методология оптимальная. Вопрос не одномерный и это надо учитывать.
Ну и позабавила фраза, что надо "делать только те задачи, которые реально приносят пользу бизнесу". Для меня она звучит как "просто надо делать задачи без багов и технического долга" и все будет замечательно.MEGA_Nexus
22.12.2025 09:55Но изначально статья была не о том, какая проектная методология оптимальная. Вопрос не одномерный и это надо учитывать.
Так в том то и дело, что пока люди ищут некую метрику, которая им покажет всё, что они хотят, работа в этот момент стоит на месте, т.е. нет движения вперёд. И чем больше люди тратят времени на поиск мистической метрики, тем дальше отдаляются от основной цели - выполнения работы. И очень часто сама метрика становится самоцелью.
Ну и позабавила фраза, что надо "делать только те задачи, которые реально приносят пользу бизнесу". Для меня она звучит как "просто надо делать задачи без багов и технического долга" и все будет замечательно.
Да, я специально так написал, чтобы не нагружать ещё сильнее свой коммент, иначе никто до конца его не прочитает. :)
Касательно метрик. У разных групп разные критерии оценки их результатов труда. У закупщика - купить побольше сырья и подешевле; у производственника - произвести как можно больше изделий; у маркетолога - расширить охваты и повысить узнаваемость компании; у продавцов - продать как можно больше, у разработчиков - закрыть как можно больше задач в Jira ))). И часто эти метрики могут друг с другом конфликтовать.
Так что тут приоритет задач будет определяться теми планами, что ставит на год\квартал директор или собственник компании. Метрики самой разработки - это дело десятое. Какая разница, какой был Velocity у команды или сколько Story points было выполнено, если квартальные задачи не выполнены. И наоборот, какая разница, если в этом году Velocity был в 2 раза хуже, чем в прошлом году, но все квартальные и годовые целы выполнены успешно.
Я к тому, что не нужно так сильно задрачиваться на метрики, т.к. они локальны (локальный оптимум), а во вторых - никакие метрики сами по себе задачи не выполнят, так что лучше рабочее время потратить на выполнение задач.
P.S. Всё, что написано ниже, это для тех, кто хочет углубиться ниже.
Если дочитали до этого места, то открою секрет. Есть метрики на уровне всей компании, например, Теория Ограничений Голдратта фокусируются на трёх ключевых финансовых показателях для оценки результативности системы: Пропускная способность (Throughput) — деньги, генерируемые системой; Запасы (Inventory) — деньги, вложенные в материалы и незавершённое производство (ТМЦ); и Операционные расходы (Operating Expenses) — деньги, потраченные на превращение запасов в пропускную способность, то есть себестоимость.
Поняв, что это за метрики на уровне всей компании и как отдел разработки на них влияет, вы можете создать новые метрики, которые реально будут полезны вашей компании. Для этого нужно понимать текущие цели и задачи менеджмента, активно общаться с ним, что не всегда возможно.
Метрики вида, Velocity, Story points, величина тех. долга и прочее - это просто мусор, т.к. это локальные метрики (локальными оптимумы), которые могут вредить общему процессу формирования добавочной стоимости.
Но писать о том, что текущие метрики это мусор, под статьёй, где человек старательно хочет найти нужную метрику - это было слишком грубо с моей стороны, поэтому я решил пойти другим путём и сообщить, что текущие метрики сильно переоценены, поэтому лучше рабочее время потратить на саму работу, а не на поиск метрики. Канбан позволяет просто спокойно выполнять работу, в то время, как Scrum заражён метриками от начала и до конца, поэтому чтобы отойти от метрик, придётся отойти от Scrum.
Например, компания хочет выйти на рынок новой страны и получить там 15 клиентов за 1 год. Сколько Story points мне для этого нужно? А какого Velocity должна придерживаться команда разработки? А какая величина тех. долга будет приемлемой для этой цели?
И вот тут становится понятно, что локальные метрики совершенно бесполезны. И что намного эффективнее пойти и пообщаться с людьми, которые участвуют в этом проекте и понять, как именно команда разработки может им помочь добиться общей цели - получить 15 клиентов за 1 год на новом для компании рынке. Может и разрабатывать ничего не нужно, а достаточно просто перевести интерфейс ПО на новый язык и купить подписку на сервис рассылок для менеджеров по продажам, вместо того, чтобы разрабатывать свой собственный рассыльщик.
Smozub Автор
22.12.2025 09:55Интересно вы рассуждаете. Метрика - это не цель, она не определяет деятельность. Метрика - это оценка деятельности.
Это как в школе: проходим тему по математике, а потом контрольная и учитель проверяет работу и знания, ставит оценку. Получаем метрику успеваемости. Но нельзя просто взять и подвинуть метрику. Нужно осваивать материал, глубже понимать предмет и тогда учитель выше оценит знания. И только после этого поднимется метрика успеваемости.
В статье поднималась тема оценок. Не глубины, не сути исполнения задач, а система оценок. Ведь именно оценки (метрики) дают понимания в момент нужно что-то корректировать или все идет хорошо. Они не говорят как корректировать.
На своем опыте сталкивался с разными ситуациями и да, легче всего отруливается личным общением, выяснением проблем, контекста с последующим внесением изменений. Но так же столкнулся с ситуацией, когда 200 разработчиков замедляются с каждым кварталом. Именно на уровне аутпута, а по низкоуровневым показателям все хорошо: раппортуют о том, какие трудности преодолели, сколько задач героически выполнили.
И, самое интересное, разработчики правы. Они просто делают задачи и стараются как можно лучше их выполнять.Вот и получается парадокс: команды разработки делают все по как можно лучше, по отчетам и демонстрациям все отлично, а вот в целом медленно. Не абстрактно медленно, а относительно - медленнее и дороже с каждым кварталом, с каждым годом. Расходы растут и уже нет такой отдачи в деньгах. А задача любого управленца - приносить прибыль, увеличивать стоимость компании, капитала для акционаров.
P.S. а Голдратт написал отличную книгу, она очень помогает запустить мышление, но это бизнес-роман, не стоит его переоценивать. Почитайте Друкера, Гранта, Бэста.
andyblaster
22.12.2025 09:55нужно начать делать работу
просто выполнять работу
просто начните уже делать работуСкрытый текст
JUST DO IT! Как исполнитель, я тоже голосую за канбан. Но все остальные размышления довольны размыты и наивны. Из разряда "у тебя не будет плохих метрик, если у тебя изначально нет метрик")
делать только те задачи, которые реально приносят пользу бизнесу
Как или в чем оценить реальную пользу? Если чисто на словах, договоренностях и убеждении, то будущее таких компаний меня пугает. Из-за того, что в менеджмент просачиваются личности, умеющие красиво говорить и профессионально высасывать деньги из работодателя, разрушая при этом все - атмосферу в коллективе, эффективность работы и технологичность автоматизации.
В общем, чтобы воплотиться в жизнь, озвученные принципы требуют очень высокой осознанности и ответственности от каждого участника процесса. И даже, в каком-то смысле, это шаг в строну плоских горизонтальных структур управления. Строгая иерархия гораздо более привычна/понятна и гораздо более распространена, и она как раз требует таких же организованных в иерархию метрик. Хотя бы чтобы ими можно было управлять иерархическими же подходами.
Tolnik
22.12.2025 09:55На счет текста своего мнения не имею, т.к. его не читал из-за того, что тема меня не сильно интересует. А вот иллюстрация от нейросети вызвала небольшое раздражение. Я не против нейросетевой иллюстрации в принципе, но хотелось бы, чтобы автор что-то подчищал за нейросетью в этом плане. Издалека иллюстрация как иллюстрация, но для людей, которые всматриваются, я бы заменил цифры (хотя бы те, которые покрупнее) на валидные. В большинстве растровых редакторов это несложно сделать, а в векторных еще проще.
Krasnoarmeec
22.12.2025 09:55Цикломатическая сложность, поделённая на количество функционала/фич?
В идеале - постоянная, когда код становится неуправляемым - растёт.
DUst_comp
Интересная статья, как раз не хватало мнения, что метрики это не главное в проекте.