Use cases

Кратко. PanDev Metrics раскрывается, когда у вас 10+ инженеров, есть привычка к data-driven подходу и нужны ответы, которых Git + Jira сами по себе не дают. Ниже — истории, которые чаще всего звучат в разговорах с клиентами: по ролям и по размерам команд.

Когда PanDev — правильный инструмент

Продукт лучше всего подходит, если одновременно верны две вещи:

1. У вас минимум ~10 инженеров, и оргструктура начинает ощущаться как «я уже не уверен, кто реально что делает».
2. Существенная часть работы идёт в IDE на поддерживаемом стеке — JetBrains, VS Code (или его форки Cursor/Windsurf), Visual Studio, Xcode, Eclipse-family.

Если обе верны — остальное на странице будет полезно.

Истории по ролям

Engineering manager — «кто сейчас перегружен?»

Вы ведёте три команды. Стендапы рассказывают вчерашнюю историю; Jira показывает, кто утверждает, что занят. Ни то, ни другое не говорит вам, кто реально провёл вчера десять часов в коде, а кто — два часа в коде и остальное в созвонах.

Что PanDev подсвечивает для этой роли:

• Нагрузку по людям и командам — реальные IDE-часы, переработки, фокус-блоки.
• Где работа стоит — долгие PR'ы, время ожидания ревью, тикеты, висящие в In Progress.
• Кто дрейфует к выгоранию — хронические переработки, работа по выходным, падающее фокус-время.
• Кривую онбординга — время новичка до первого нетривиального PR, скорость рампа от недели к неделе.

Задача — не слежка. Задача — «дайте мне цифры, с которыми я могу прийти на 1:1, а не ощущения».

CTO / VP Engineering — «а чем эта компания вообще занимается?»

Вы отчитываетесь перед советом директоров, CEO или остальной командой. Им нужно знать: мы поставляем?, сколько это стоит?, куда идёт тренд?

Что даёт PanDev:

• DORA метрики с performance bands. Deployment frequency, lead time for changes, change failure rate, MTTR — по всей компании или с разбивкой по командам.
• Real-time видимость. Живой срез того, кто над чем работает, по командам, репозиториям и трекерам.
• Cost per feature. Та самая цифра, которую вы реально называете в бюджетном разговоре: «эта фича стоила нам $42,000 инженерного времени». Этого нет ни у одного другого вендора.
• Headcount planning на данных. Реальные часы кодинга, пропускная способность и DORA-полосы вместе говорят, куда добавить людей, а куда — не нужно.

Типовой паттерн: CTO еженедельно открывает платформу ради трендов и ситуативно копается в командных дашбордах для вопросов «что у команды X в этом квартале происходит».

Finance / Operations — «какова unit economics инженерного часа?»

Роль Finance в PanDev открывает доступ к зарплатному слою. Hourly или monthly ставки, USD, персональные графики сотрудников, которые приоритетнее календаря компании, гос-праздники, которые вы задаёте вручную.

Какие цифры получает Finance:

• Прямую стоимость задачи — (время на задачу × ставка) + пропорциональная доля неатрибутированного времени инженера.
• Агрегаты по проекту и департаменту.
• Ставку задним числом. Повысили зарплату? Историческая стоимость пересчитается по всему таймлайну.
• XLSX-экспорты для остального финансового стека. Интеграций с payroll-системами (1C, QuickBooks, Sage, Bamboo) нет — XLSX это мост.

HR — «объективный вход для Performance Review»

HR использует платформу, чтобы заземлить разговор о ревью в фактах, а не в субъективных впечатлениях. Карточка сотрудника агрегирует активность, историю работы, распределение времени и (с ролью Finance) зарплату. Вид оргструктуры показывает департаменты и вложенные команды ровно так, как реально устроена компания.

Платформа не про «ранжирование» сотрудников. Она поставляет вход; что с этим делать — решает компания.

Разработчики — «верните мне время, которое я трачу на табели»

Для самих инженеров выигрыш — в автоматизации. IDE-плагин собирает реальную активность сам — никаких ручных тайм-логов, никакой возни со статусами Jira ради «зачёта» сделанного. Персональный дашборд показывает свои тренды; у каждого свой кусок ответственности.

Режим Personal workspace позволяет инженеру использовать PanDev в одиночку, без корпоративного tenant'а. Полезно фрилансерам и тем, кто хочет, чтобы данные ходили с ним между работами.

Истории по размерам команд

10–30 инженеров — точка хаоса

Это тот размер, на котором фаундер/CTO теряет способность держать всю компанию в голове. Платформа ставится сильно меньше чем за день и окупает себя тем, что из десятка ваших тревог называет ту, которая реальная.

Выигрыши на этом размере:

• Засечь блокеры (долгие ревью, стоячие тикеты) до того, как они станут квартальными проблемами.
• Построить первую внутреннюю историю cost-per-feature.
• Зафиксировать первый DORA baseline, чтобы будущим кварталам было с чем сравниваться.

30–100 инженеров — стандартизация

На этом размере каждая команда придумала свой Jira-workflow, свои конвенции именования, своё определение «готово». PanDev даёт согласованный слой над всем этим — Git-события, IDE-события и события трекеров, нормализованные в один таймлайн, независимо от того, как команда работает локально.

Выигрыши на этом размере:

• Сравнение DORA между командами, которое не «apples-to-oranges».
• Балансировка нагрузки на уровне компании — видно, кто на дне, а кто нет.
• Реальный датасет cost-per-feature, накопленный за год-два.

100+ инженеров — cost-of-feature как инструмент бюджетирования

Для enterprise стратегическая ценность в финансовом слое. «Проект X стоил $1.4M инженерного времени в этом году и поставил Y фич» — это фраза, которая заканчивает спор. На этом размере обычно критичен on-prem; PanDev уезжает в Docker или Kubernetes в вашем периметре.

Выигрыши на этом размере:

• Cost per feature как вход в разговор о capital allocation.
• On-prem с LDAP SSO внутри security-периметра.
• DORA на уровне компании для совета директоров, по командам — для операционки.

Сравнения по use-case'у

Несколько честных one-liner'ов. Q120 разрешает прямые сравнения по именам.

• vs LinearB / Jellyfish / Faros AI. Они все хорошо делают Git + трекеры. У них нет on-prem, нет нашей глубины IDE-телеметрии и нет расчёта себестоимости фич. Если ни одно из трёх вам не нужно — это норм выбор. Если нужно — мы единственный вариант.
• vs Swarmia. Сильный продукт по team-health. Те же пробелы: ограниченная глубина IDE, нет on-prem.
• vs WakaTime. WakaTime — отличный персональный/командный time tracker. Мы — платформа: трекеры + Git + IDE + finance + AI, плюс on-prem.

Когда PanDev — не тот инструмент

Лучше вы у нас не купите, чем купите и сразу уйдёте. Мы честны про misfits:

• Компании не на разработке. Маркетинг, продажи, ops как ядро — это не для PanDev.
• Стеки, которые мы не покрываем по IDE. Без IDE-слоя вы платите за половину продукта.
• Security / DevOps-only команды. IDE-сигнала недостаточно; дашборды будут пустыми.
• Совсем маленькие команды. Меньше 5–10 инженеров — ценность есть, но разговор «цена vs накладные» обычно не сходится.

Связанные материалы

• Обзор продукта — общий контекст и позиционирование.
• Возможности — полный функциональный охват.
• Роли и разрешения — какая роль видит какие данные: Owner / Admin / Maintainer / Viewer на уровне tenant и роль Finance для финансовых данных.
• On-prem развёртывание — установка внутри периметра.