Marat @ Predictable.Team

Робяты, мы тут объединились с командой плагина Jira Metrics - чтобы в сообществе поддерживать культуру принятия решений, основанных на данных. Так что здесь будут анонсы воркшопов по работе с метриками в Jira, сравнению показателей команд. Мы с автором плагина ещё в 2012-2015 работали в месте в небезызвестной конторе в Уфе - Frumatic. Сейчас я в Райфе а Анвар в HH.ru, и вновь сошлись на почве работы с метриками. Сейчас у плагина больше 3000 регулярных пользователей, действительно стоящие своих денег дополнительные фичи (супер гибкие дашборды для разных срезов данных и AI-чатбот с навороченной базой знаний для анализа метрик). Если вы пользуетесь плагином, то вот пара полезных ссылок: - @JiraMetricsPro - канал плагина на русском языке - @akhakimov - канал Анвара про работу Lead Project Manager’а, метрики и вызовы - @JiraMetrics - чат и поддержка плагина

Встречайте Марата Киньябулатова — нового члена команды JiraMetrics.Pro. Марат — эксперт по flow-метрикам и предсказуемости, автор практических гайдов по метрикам и активный участник agile-сообщества. За его плечами — руководство PMO в MetaMap (InCode), развитие сообщества Agile Ufa, работа с ядром банковских сервисов в системно-значимом финтехе на периметре 45 команд. Что особенно важно — он давно сам пользуется JiraMetrics.Pro и знает плагин изнутри. На недавнем демо для канбан-тренеров Марат показал все возможности инструмента, поделился лучшими практиками использования и примерами, как метрики помогают командам работать предсказуемее и понятнее. И это только начало. Мы планируем регулярно проводить демо и воркшопы, чтобы превращать данные в понятные шаги и реальный результат. 👉 Подписывайтесь, чтобы быть в курсе следующих встреч.

🔥 Motivation30.com - Выбери тип мотивации сотрудника -> получи персональный план с готовыми инструкциями или как из идеи сделать интерактивную лекцию родился прототип "Motivation 3.0 - конструктора мотивации". Не люблю читать лекции. Люблю, когда ребята сами осваивают и рефлексируют над материалом. На прошлой неделе готовился читать небольшой докладик по нематериальной мотивации и подумал: «А что если дополнить презентацию интерактивом?» 🗿 Презентация была основана на "Теории Самодетерминации": - 3 основных кита мотивации: Автономность, Компетентность, Связанность. - 2 фактора нематериальной мотивации: внутренние или внешние. - Факторы также можно делить по скорости эффекта: быстрые, отложенные, долгосрочные. 🧑‍💻 За полчаса накидал прототип в Loveable (мой фаворит среди вайб-кодинг инструментов) — простой конструктор мотивационных практик. Для пилотирования пообстукивал об ребят в Ufa IT Coworking. На практической части поделил руководителей на мини-группы и оставил на полчаса обсуждать практики и делать планы повышения мотивации исходя из заданных кейсов. По итогу ребятам очень зашла практика, на дебрифе попросили: «Дай ссылку, будем пользоваться!». ✅ Ссылку-preview давать негоже, посему на выходных допилил: - Добавил полноценные практики ко всем 9 факторам мотивации, - Прикрутил ссылки на курсы и статьи, - Купил домен с SSL (шоб солидно и секурно). - Добавил экспорт планов в md / txt. ⌛ Сделано за пару часов: 30 минут на прототип (буквально с телефона перед сном) + 2,5 часа на продукт + 1,5 часа на изучение литературы = работающий инструмент, который просят сохранить. Короче лень и интерактив - двигатель прогресса *Тут есть приписка, что все таки я работаю с мотивацией персонала с 2015 года, поэтому нельзя говорить что я с нуля изучил тему.

Мы провели демо JiraMetrics.Pro для сообщества Канбан Стандарт — экспертов, которые делают канбан-метод понятнее и доступнее для индустрии. Это была не просто демонстрация. Мы получили ценный фидбэк и поддержку от людей, чья экспертиза формирует практику канбан-метода в России и СНГ. Такая обратная связь помогает нам делать продукт ещё понятнее, полезнее и ближе к задачам команд. Для нас это подтверждение: мы идём в правильном направлении, а значит, у пользователей будет меньше рутины и больше фокуса на результате. Отдельная благодарность Алексею Пименову за организацию этого созвона 🤝 Подписывайтесь на канал, чтобы первыми узнавать о следующих демо и новых возможностях продукта.

😎 Похвастаюсь: мы тут с Анваром (автором Jira Metrics) на прошлой неделе провели демо с элементами воркшопа для тренеров Канбан-Стандарта (neogenda / Лёша Пименов) по возможностям плагина и анализу команд 💪 Рассказали как строить дешборды для сравнения метрик команд, какие есть возможности у AI-ассистента по анализу метрик, и многое другое. Очень круто видеть живой интерес в глазах людей, желание вместе "вваливать" своё время чтобы дополнить документацию и гайды по оптимизации. В ближайшее время я проведу подобное еще и в @AgileUfa и аудитории канала. Даешь data-driven подход в работе с командами!

💎WIP Aging — самая важная метрика потока 🪦 Посмотрите реальный пример на скриншоте выше - там состарилась целая свора задач, какие-то явно протухли. WIP (work in progress) Aging — это количество времени, которое задача уже провела в работе, но еще не завершена. Помогает понять, где работа "застревает" в процессе и сигнализирует о рисках для потока. Мы считаем начало "в работе" как точку, когда вы втягиваете в свою систему работу (у разных команд она может разная). 📈 Где посмотреть: - Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда) - Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging 👆 Почему это важно? - Чем дольше задача "стареет" в потоке, тем выше риск, что она устареет для бизнеса, попадёт в зависимости, или просто потеряется ценность работы. - Следить за Aging надо до завершения задачи - ваш шанс оперативно реагировать на проблемы в процессе, а не ждать, когда цикл завершится и станет "слишком поздно" для улучшений. - Всё в Kanban — визуализация, блокировки, Pull-политики — заточено на то, чтобы не позволять задачам стареть без необходимости. 🕸 Какие основные паттерны Aging встречаются в практике? - Стабильный рост: WIP Aging растёт равномерно — признак стабильного процесса и правильных WIP-лимитов. - Плато или затор: Aging резко увеличивается на каком-то этапе — вероятен bottleneck или проблемы формата слишком крупных задач. - Волнообразные скачки: Aging периодически ускоряется — возможны внешние зависимости/нестабильность команды. - Разделение на мелкие задачи: Когда Aging сигнализирует о "застрявшей" задаче, best practice — разделить её на более мелкие части. - Экспоненциальный рост: Очевидная перегрузка WIP — новые задачи начинают быстрее, чем завершаются старые. Tips & Tricks: - WIP Aging — один из лучших ранних индикаторов проблем (если выбирать одну метрику, то Aging — самая полезная для начала). - Комбинируйте её с Lead Time и Throughput, чтобы видеть общую картину. Lead Time = ваш исторический SLA, а Aging - возможность увидеть в realtime что сейчас пробьёт SLA. - При превышении допустимого возраста задачи — обсуждайте и разбивайте крупные работы. Например, начинайте разбирать все, что выше 85-перцентили. - Правильно используйте WIP-лимиты: лимит не спасёт, если не анализировать aging, а просто "сжимать поток". 📝 Хотите большую большущую детальную статью про Aging? - На VC недавно вышла статья про опережающий индикатор: WIP Aging от Васи Савунова. 📈 Где посмотреть: - Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда) - Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging #aging #flowmetrics

Вот вам мемчик в тему 👆

Если на прошлой неделе я ресерчил - какие китайские альтернативы Nvidia скоро появятся. То на этой - а сколько ведущие страны-производители полупроводников вкладывают (государственных и частных денег) в ИИ-железки. И сравнил с Россией. При сохранении текущей ситуации мы доберемся до стран-лидеров никогда (но может и не надо и будем пользоваться китайским железом). Сейчас у нас все железки по старым техпроцессам и в основном для военки. https://habr.com/ru/articles/948144/

Как правильно прогнозировать, когда команда закончит следующие X задач и причем тут прогнозирование через симуляцию Монте-Карло? ❌ Точную дату говорить не надо "Эпик будет готов ровно через 42 дня" — это неправда. ✅ Правильный прогноз: 10 задач за 35-45 календарных дней, где: - 35 дней = 50% вероятности - 45 дней = 85% вероятности У любого прогноза есть - Разброс, - Вероятность, - Мы предполагаем что работа в будущем будет похожа на работу в прошлом. Работает следующим образом: - 1️⃣ Собираем историю throughput команды - 2️⃣ Запускаем 1000+ симуляций со случайной выборкой - 3️⃣ Получаем распределение вероятностей Главное условие: нужны WIP-лимиты! "Нет WIP-лимита = нет потока = нет предсказуемости" — Daniel Vacanti 👩‍🔬 Исследования и материалы: - 🖥 На прикрепленной картинке пример прогноза из приложения: Predictable.team (я когда-нибудь переведу его на русский) — загружаете CSV из Jira (или demo data) и тыкаете во вкладку Монте-Карло. - ActionableAgile доказали: простая случайная выборка работает лучше сложных алгоритмов. - Российские кейсы (Тинькофф, SportMaster) подтверждают точность 80-90%. - Daniel Vacanti "Actionable Agile Metrics". - Моя статья на Хабре - Материалы на Scrum.ru, Neogenda. Впрочем, это все неважно если продажники уже подписали контракт, обещая новую фичу клиенту. Но хотя б вы им покажете данные.

📚 Книжка "Неслучайная случайность: как управлять удачей и что такое серендипность." (en: The Serendipity Mindset: The Art and Science of Creating) 🦋 Долго и нудно, на протяжении 300 страниц автор предлагает видеть необычное в обычном, быть “открытым к неожиданностям” и прокачивать тот самый serendipity – “искусство счастливых случайностей”. Не рекомендую. 🔍 Короткий обзор и духота от меня В 2020 году профессор Кристиан Буш решил легализовать удачу (мол, это не просто "удача", это целый процесс) и описал новый “майндсет” поиска возможностей в хаосе. 🎱 Основа - принципы “серендипного” мышления: - Будь внимательнее: замечай детали, на которые обычно бы не обратил взор (развивай внимание, периферийное зрение и вот это всё). Тут про насмотренность и осознанность. - Мысли с разных сторон: рассматривай привычные ситуации с других сторон (в идеале — не только своих). Тут как бы просто про критическое/латеральное/ дивергентное мышление. - Расширяй связи: общайся шире, спрашивай про “что-то еще” в Small Talk — вдруг подвернется “касание удачи”. Я переведу - просто будь экстравертом и делай нетворкинг. - Порождай триггеры: вместо “Я маркетолог” во время знакомста удиви (вау) всех словами — “Я изучаю поведение людей, делаю подкасты, люблю сканди-детективы” — и смотри, к чему это приведет. Именно так люди запоминают тебя лучше и образовываются связи. - Не жди чуда, а сам создавай предпосылки: чем больше действий, тем выше шанс “случайного” открытия (но это не точно). Ну чем не проактивность. ☦️ К чему скепсис (мой) Неплохо, что тут есть практики self-reflection и упражнений в конце каждой главы. Но если коротко — почти всё, о чем пишет Буш можно найти в любой self-help литературе. Много историй уровня “один парень что-то сделал -> случайно повезло -> теперь миллионер”. Сама идея, что “сознательно можно тренировать удачу”, не нова. Но в этой книге глубокое знание и эрудиция как фундамент серендипности — отодвинули на второй план. Зато техник, сторителлинга который бесконечно повторяется — с лихвой. "Видеть возможности в случайностях”, как говорит автор, всегда полезно — особенно если крутишься в стартапах или креативных продуктах. Но никакой “серендипный майндсет” без системного подхода, осознанности, привычки критично смотреть на вещи и работы с культурой не жизнеспособен Ozon / Альпина / Амазон PS: Лучше прочитайте эту "Неслучайную случайность"

Воскресное чтиво: Какое есть ии-железо в Китае на замену Nvidia (и насколько они мощные). https://habr.com/ru/articles/944548/ Я на работе занимаюсь внедрением AI в разработку. И интересуюсь ИИ-темой во всех ее проявлениях. И ROI, и adoption, и в целом насколько это реально помогает командам разработки. На выхожных читал статью, на которую наткнулся в канале The Edinorog - какие в Китае есть производители ИИ чипов. Перевел статью и добавил мяса (ато как-то неинтересно без деталей) - какие по техническим характеристикам есть чипы в сравнении с Nvidia A100/H100 , AMD Ryzen.

🚀 Вы только посмотрите до чего дошли технологии. Из статьи можно делать видео-презу с аудио и графиками, причем качественно и автоматически! Вчера, интереса ради закинул свою статью про Прогнозирование с помощью симуляции Монте-Карло с Хабра и попросил сделать NotebookLM видео-обзор (я уже писал для чего использую NotebookLM). 📹 Так он сделал целую презу с хорошим визуалом, нарративом (пусть и излишне оптимистичным). Такое можно хоть на youtube запихивать! Воистину, как пела SuperAlisa, "Безнен жирда жана технологиялар" (на нашей земле горят технологии) в своем шлягере "Су Анасы". 🙄 Если кому-то было лень читать и вы не в числе 2,4к прочитавших -> ролик-преза на английском (на русском он пока не могёт).

У меня тут вышел большой практический гайд на Хабре про Throughput (динамику и паттерны) и прогнозирование симуляцией 🎲 Монте-Карло. 🔍 Разбор Throughput со стороны - Значимых периодов и частоты замеров - Вариативности - Кластеризации по типам работ 🤖 Алгоритм составления прогнозов через симуляцию Monte-Carlo на основе Throughput - Когда будут готовы следующие 50 элементов + Обзор инструментов визуализации и прогнозирования + Почему Throughput уже учитывают вариативность в работе команде + Почему Story Points менее эффективны для прогнозирования https://habr.com/ru/articles/940882/ #mcs #montecarlo #throughput #forecasting

🎓 Про Notebook LM. Back to school (как в песне Deftones), так сказать. Общаемся с книжками, слушаем ИИ-подкасты, провоцируем шизофрению. Где-то год назад я открыл для себя NotebookLM*, это инструмент от гугла который достаточно сильно поменял мой подход к изучению информации. Фактически это, да простят меня технари, RAG-модель от Google. Она превращает ваши документы в умного собеседника. Теперь не надо листать книгу или PDF, в поисках цитаты. 🥸 Как это работает: 1. Загружаешь до 50 источников — Книги, статьи, видео YouTube, Google Docs. 2. Спрашиваешь что угодно — он отвечает ТОЛЬКО на основе загруженных документов. 3. Получаешь точные ответы со ссылками на источники! 💡Мои сценарии использования: - Изучаю как разные источники рассматривают одну и ту же проблему — закидываю, к примеру, книги по платформенным командам: Team Topologies, Platform Engineering, Scaling Teams (изучаю тему платформ). - Product research — собираю пользовательский фидбек на разные инструменты, нахожу паттерны - Academic Research - можно не грузить самому, а попросить инструмент походить по академическим источникам и составить список материалов, на которые он будет опираться. 🍰 В итоге: Экономия времени, никакого муторного поиска. И всегда супер-явно можно сослаться на данные из конкретных источников. 🎧 ИИ-подкасты А еще там есть генерация подкастов из ваших материалов! Это уже совсем космос и шизофрения, но я этим пользуюсь. Закинул три книги по теме, попросил сделать подкаст - и там два ИИ-хоста обсуждают твой материал * чтобы пользоваться из России, надо зайти "не-из-России"

Маленький пост, важная и очень простая тема. 🦾 Закон Литтла - универсальная взаимосвязь метрик потока Мы с вами прошлись по Throughput, Lead Time - а как они взаимосвязаны, есть ли формула? Да, закон Джона Литтла! В следующий раз, когда ваш менеджмент/команда будет говорить "да давайте напихаем побольше в спринт" - покажете что это приведет к определенным последствиям. 📜 Чем больше у вас элементов в работе (Work In Progress, WIP) - тем дольше вы делаете каждый элемент (Lead Time) и тем меньше элементов выпускаете (Throughput). 🍣 Что такое WIP на примере суши‑ресторана WIP — это сколько заказов одновременно «висят» в работе на кухне: повара режут рыбу, варят рис, собирают роллы. Если взять в работу слишком много заказов сразу, очередь расползается, каждый заказ «готовится» дольше, клиенты ждут и нервничают. Если удерживать разумное число параллельных заказов, кухня идёт ровнее и предсказуемее: гости получают еду быстрее, а команда — меньше стресса. 💻 А в IT? В айти также. У команды куча недоделанных задач? Ну так а зачем размывать фокус и брать все подряд, контролируй количество параллельной работы! 👌 Простота и универсальность Логика закона Литтла тривиальна в использовании и не требует спецподготовки. В практике она превращается в один вывод: чтобы lead time был меньше, а throughput — выше, нужно не раздувать параллельную работу. Слишком много начатого — значит, мало законченного и долгое ожидание. 🛣 С чего начать с WIP‑лимитов - Базовая настройка: стартовать с WIP примерно «размер команды + 1». - Наблюдать пару итераций: если throughput растёт и lead time сокращается — можно пробовать аккуратно снижать WIP дальше. - Если при снижении WIP throughput падает — лимит задушили, верните на шаг назад. 👨‍🦰Так что наматываем на ус правило: ограничивая параллельную работу, мы управляем и временем поставки (lead time), и пропускной способностью (throughput).

Пятничный лайтовый-пост. Самые нестандартные (и местами трешовые) метрики. Из коллекции “2 Dozen Weird Agile Metrics Ideas” — это подборка странных и забавных способов замерять "эффективность" команд, которой поделились PM-ы, agile-практики и коучи на projecttimes.com. Всё серьёзно: авторы статьи честно пробовали внедрять эти метрики в реальной жизни — иногда для фана и командного духа, иногда чтобы взглянуть на процессы с необычного ракурса. Вот топ-10 из подборки “2 Dozen Weird Agile Metrics Ideas”: 🗑 Количество фич, удалённых (не отмененных) из бэклога (а может, и из прода) — иногда главное не сделать, а вовремя удалить ❌ Количество остановок продакшна (stop the line events)? ❓ Сколько пунктов из ретро реализуют реально? (Легенда гласит, что кто-то доводил до 3 из 10) 🤟 “Коэффициент user stories с нулём багов” — чем ближе к 100%, тем веселее обсуждение! 🤣 Время до первой шутки на дейли — автоматизация для души. ☕️ “Индекс кофеина” — сколько кофе на команду за спринт vs сколько багов в релизе? 🐞 Число багов, найденных после релиза vs до — здесь всегда есть над чем посмеяться и задуматься. ✍️ Дедлайны, на которые подписались абсолютно все… Если такое было — команда получает +10 к карме! А если еще и смежным командам было ок, это какие-то единороги. 🔥 Количество историй, переписанных после демо PO — "индекс выгорания продакта". ✋ Число креативных ICE-breakers подряд на ретро (иногда с этим очень перебарщивают). С одной стороны это забавные показатели на поржать (и про процессы в организации где такое вводят, и просто). С другой - можно посмотреть на команду под новым углом, и с шутками-прибаутками вовлечь команду в обсуждение реальных проблем. Они отлично подходят для ретро, помогают снять напряжение и поднять важные темы, но не должны становиться самоцелью или поводом для токсичности. Главное не вести по ним отчетность :) ❓ У вас был опыт с какой-нибудь упоротой метрикой?)

Часть третья про Lead Time (база тут, про связь cycle time+lead time+time to market тут). Обсудим кластеризацию типов работы, динамику, гистограммы и диаграммы рассеивания, end 2 end. Дорогой друг, давай прям на практике пройдёмся по показателям: - Открываем в хроме https://predictable.team, нажимаем на Try with Demo Data, и кликаем на вкладку Lead Time. На графике Scatteplot показывается, за какое время завершается 50% задач (median), а за какое 85%. 🏄‍♂️ В Lead Time динамика всегда важнее текущего состояния Один раз замерить lead/cycle time полезно. Но если хочешь реально улучшать показатели надо смотреть в динамике на типы работы (прямо как в throughput). 🎳 Кластеризуй Lead Time по типам работы (потому что они все разные) На практике, чаще показывают гистограмму Lead Time. Но мне субъективно кажется что в ней не хватает временной динамики, поэтому я люблю диаграмму рассеивания (scatterplot, control chart в Jira). - Баги — обычно устраняются быстрее (у них часто самые короткие lead time). - Полноценные end-2-end стори — куда длиннее, иногда с кучей согласований. - Инциденты — вообще особый поток, SLA, жёсткое реагирование. Посему смотрим на динамику в два шага: 1. Общая динамика (вкладка Lead Time) 2. Динамика по классам задач. Для этого в верхнем меню можно менять набор "Issue Types". Так мы поймем - на общую динамику повлияло просто то что у нас стало больше багов, которые мы решаем за короткий срок, или все таки стори стали меньше и эффективнее проходят через цикл разработки. 🧩 Цикл твоей команды ≠ end-to-end всего потока ценности. Оптимизировал поток своей команды вместе с ребятами, далаете свои задачи быстрее? Молодцы, но зачастую на всем end-2-end потоке работы ваша оптимизация будет локальной (то есть расширить самые медленные бутылочные горлышки и простои в сквозной системе всегда будет эффективнее, чем оптимизировать какую-то только подконтрольную вам часть). Мыслите системно: что надо сделать чтоб вся система быстрее работала, а не только ваш кусок, который потом упрется в соседний отдел. Обычно сэкономленное время (благодаря вашей оптимизации) меньше, чем время которое вы теряете из-за простоя задачи между смежными командами (делающими со-зависимый функционал). #leadtime #cycletime #timetomarket #метрики #metrics #flowmetrics

👀️️️️️️ Друзья, делюсь планом контента с отпускными фото из Приэльбрусья ❤️🏔 - Посты про метрики были подготовкой к нашему митапу @agileufa в воскресенье. Уже 70 человек зарегистрировалось! Планирую завершить темы Lead Time, Aging и закон Литтла к концу недели. - Хочу реже публиковать посты (раз в неделю) и больше обсуждать оргизменения, исследования и прогнозирования. Проголосуем? - 👍 за посты реже - 🔥 и так норм частота - Метрики важны как база, в том числе чтоб делать разбор в моем инструменте прогнозирования: https://predictable.team - Есть темы (кейсы / советы / обзоры), которые интересно было бы обсудить?

🚦Time to Market, Lead Time, Cycle Time и почему они про одно и то же? Расставим точки над "i" после вчерашних дискуссий в @agileufa с Сережей (организатором @UfaJS) 🏗 Базовый термин времени производства: Cycle Time. Это супер-простая идея: выбери любую пару точек на процессе (начало и конец) и посчитай, сколько времени проходит между ними. Главное, после слов Cycle Time указать начало и конец цикла. В этом его сила и универсальность: не важно, что считать — можно измерять любые циклы или стадии на пути создания пользовательской ценности. 🧱 Как это работает на практике: В IT и продуктовых командах часто под термином Cycle Time подразумевают время от момента, когда задача переходит в состояние “В работе”, до момента “Готово”. Это отражает длительность всех активных действий по задаче, исключая время, когда она находилась в бэклоге. ✅ Чтобы быть более точным, стоит обозначать этот показатель как Cycle Time (In Progress -> Closed), а не просто Cycle Time. Какие еще циклы бывают? - От “Идея!” до “Go Live” — Time to Market (общая скорость реакции компании на рыночные изменения). - От “Будет сделано” до “В проде!” — Lead Time (качество планирования и уровень доверия клиентов). ❓ Зачем нам все это? Если Time to Market, Lead Time не соответствуют нашим ожиданиям, то конкретные циклы внутри них (In Progress -> Closed, а может еще глубже: отдельно цикл Code Review / Ready for Testing / Testing) подсвечивают узкие места. Это наш базовый инструмент диагностики для понимания затыков в работе. Что для нас по-настоящему важно: скорость вывода фичи на рынок, ведь это наша конкурентоспособность (будь мы внутренним продуктом/платформой или публичной компанией). А еще большинство времени фича вообще ждет реализации в беклоге. Принимая решения на основе данных (время в беклоге или цикл Created -> Committed) мы можем существенно оптимизировать и балансировать наш поток работы. 🍰 TLDR Cycle Time — универсальная линейка. Смотри на него под любым углом и всегда находишь способ точечно диагностировать, что реально происходит с вашей командой или продуктом. ⚠️ Очень важно, что Time to Market (а зачастую и Lead Time, и Cycle Time (In Progress -> Done) и мы все таки считаем у фичей (новый функционал приносящий ценность), а не у рядовых задач, которые делает кусочек нового функционала. #timetomarket #cycletime #leadtime #metrics