Перейти к основному содержимому

4 записи с тегом "productivity"

Посмотреть все теги

Chrome-расширение для инженерных метрик: трекинг из браузера

· 9 мин. чтения
Artur Pan
CTO & Co-Founder at PanDev

Большинство платформ для engineering analytics требуют выходных, прежде чем вы увидите первый график. OAuth в GitHub. Подключить Jira. Подождать следующего деплоя, чтобы DORA дочиталась. Уговорить безопасников одобрить webhook. К моменту, когда всё взлетит, исходный вопрос «мы реально стали быстрее отгружать после реорга?» уже устарел на два спринта.

Chrome-расширение меняет порядок: установить, залогиниться один раз, и в течение 30 секунд у вас есть сигнал из GitHub, GitLab и Jira. Без backend, без согласования интеграций, без Looker-лицензии. У этой скорости есть жёсткие ограничения. Этот пост о том, что Chrome-расширение для инженерных метрик реально умеет, где оно выигрывает у SaaS, и какой пласт работы оно никогда не увидит.

Jira-автоматизация для EM: 12 правил, экономящих часы

· 7 мин. чтения
Artur Pan
CTO & Co-Founder at PanDev

Средний engineering manager тратит 4 часа в неделю на перетаскивание тикетов в Jira. Не планирование, не 1:1 — сортировку, напоминания, закрытие stale и гонки за полями, которые забыли заполнить. Мы опросили 31 EM у B2B-клиентов; 27 назвали Jira главной временной дырой после встреч.

Atlassian поставляет довольно мощный engine автоматизации в каждом плане Jira (да, даже в Standard). Команды его игнорируют. Или, что хуже, используют для одного правила — auto-close на "Done" — и упускают 11, которые имеют значение. Ниже — набор 12 правил, которые вместе сокращают admin-нагрузку EM с 4 ч/нед до ~40 минут. Мы используем варианты у себя в PanDev Metrics и у трёх on-prem клиентов.

Управление 5 проектами для 5 клиентов одновременно: подход на основе данных

· 10 мин. чтения
Artur Pan
CTO & Co-Founder at PanDev

Исследования переключения контекста показывают, что в среднем требуется 23 минуты для полного восстановления фокуса после прерывания. Теперь умножьте это на пять проектов, каждый со своим Slack-каналом, Jira-доской и ожиданиями стейкхолдеров. Вы — менеджер проектов в аутсорсинге, ведущий пять проектов для пяти разных клиентов. Каждый клиент считает, что его проект — ваш главный приоритет. И каждый понедельник утром вы тратите первые два часа, пытаясь вспомнить, на чём каждый проект остановился в пятницу.

Знакомо? Это проблема мультипроектного управления — и она является определяющим вызовом для менеджмента в аутсорсинге.

Утилизация разработчиков в аутсорсинге: как рассчитать и оптимизировать

· 9 мин. чтения
Madiyar Bakbergenov
CEO & Co-Founder at PanDev

Исследование McKinsey по продуктивности разработчиков показало, что software-инженеры тратят только 25-30% рабочего времени на активный кодинг. Остальное уходит на встречи, планирование, ожидание и переключение контекста. В аутсорсинге, где каждый час имеет прямое влияние на выручку, это распределение крайне важно. В вашей компании 40 разработчиков. Вы выставляете клиентам счета за их время. Но какая часть доступного времени каждого разработчика реально оплачивается? Если ответ — «не уверен», у вас есть слепое пятно в рентабельности, которое может стоить сотни тысяч долларов в год.

Утилизация разработчиков — самая важная финансовая метрика в аутсорсинге. И большинство компаний измеряют её неправильно — или не измеряют вовсе.