TGTGInsightаналитика telegramLIVE / telegram public index
← Системный сдвиг
Системный сдвиг avatar

TGINSIGHT POST

Post #941

@systemswing

Системный сдвиг

Просмотры2,650Количество просмотров
Опубликован24 апр.24.04.2026, 16:57
Содержимое поста

Содержимое

Для лидов-аналитиков контента почему-то мало, попробую разбавить. Будет пост для лидов. Основная забота лидов — конечно, отслеживать производительность. Одновременно поддерживать командный дух и вообще хорошее самочувствие (well-being). Для разработчиков есть много фреймворков для оценки и производительности, и самочувствия, и других факторов. Есть DORA, SPACE, DevEx, а самый новый, 2025 года, объединивший их все — DX Core 4 Я (с помощью ИИ) попробовал адаптировать DX Core 4 для системных аналитиков. Вот что получилось. Фреймворк состоит из четырех блоков: 1. Скорость 2. Эффективность 3. Качество 4. Влияние Скорость Главная метрика: производительность, объем поставок — сколько аналитических артефактов передается разработчикам в неделю / месяц (смотря какие у вас характерные скорости). Это общая метрика на подразделения / гильдии, ни в коем случае не персональная! Вторичные метрики: - Скорость прохождения требований: Сколько времени в среднем проходит от постановки задачи до передачи итогового артефакта разработчикам. Так как задачи бывают очень разного объема и их сложно сравнивать, тут можно ввести категоризацию по масштабу (но не сильно сложную, . - Скорость согласования требований со стейкхолдерами (среднее время полного цикла согласования) - Воспринимаемая скорость поставки (оценочно, как аналитикам кажется: быстро они сдают свои артефакты?) Эффективность Главная метрика комплексная: AXI, Analyst Experience Index, Индекс опыта аналитика Собираем индивидуальные оценки удовлетворенности от каждого аналитика по шкале от "Совершенно не удовлетворен" до "Вполне удовлетворен" Компоненты AXI: - Доступ к стейкхолдерам и экспертам предметной области - Качество имеющейся документации - Инструменты моделирования и анализа - Процессы ревью требований - Взаимодействие с другими командами и ролями - Ясность целей и задач бизнеса - Наличие времени на глубокую проработку (против контекстных переключений) - Процессы управления изменением требований - Доступ к данным для анализа Дополнительные метрики: - Время до 10-го сданного артефакта (для новых аналитиков) - Легкость сбора требований (субъективная) - Частота ухода ценных аналитиковиз организации / команды Качество Ключевая метрика: уровень дефектов требований. Доля требований, потребовавших дополнительных уточнений или переделывания после передачи в разработку. Вторичные метрики: - Доля пропущенных требований (обнаруженных уже в процессе разработки/тестирования) - Удовлетворенность стейкхолдеров взаимодействием с аналитиками - Доля переделок в коде из-за ошибок анализа - Актуальность документации / архитектурных схем и т.п. Влияние (Импакт) Главная метрика: Доля времени, потраченная на принципиально новые функции (в отличии от времени на некоторое улучшение существующих функций или отработки дефектов) Дополнительные метрики: - Среднее соотношение времени на анализ и на разработку для одной единицы функциональности (пользовательской истории, фичи) - Ценность для бизнеса в пересчете на аналитика (очень сложно посчитать, тут если только вы считаете ROI конкретной фичи) - Соотношение выпущенных фичей (если у вас бывает, что аналитик работает "в стол") Как это применять: ну, в идеале, должна быть триангуляция, то есть получение объективных данных (из систем), субъективных (опросных), и взгляда с другой стороны (стейкхолдеры, разработчики). На практике можно для начала провести опрос, чтобы понять базовые значения, с которых стартуем. Вот ссылка на заготовку для опросов. Главное, нужно следовать нескольким правилам: 1. Это не оценка людей, это оценка процессов 2. Чинить нужно одну вещь за один раз (за квартал, например) 3. Метрики работают только вместе (чтобы не ухудшать одну метрику за счет других) Вот такой инструмент, как вам? Я бы с большим интересом поговорил про опыт внедрения!