Обновить

Как измерить работу системного аналитика: метрики, которые говорят на языке бизнеса

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели4.5K
Всего голосов 2: ↑1 и ↓10
Комментарии10

Комментарии 10

Мне вспоминается как мужик описывал свою работу в гугле и объяснял, почему он оттуда уволился. Там был какой-то email-сервис, который слал слишком много нотификаций и всех бесил. Деталей не помню, но короче можно было слать меньше. Наивный работник просто бы пришел и починил сервис. Email'ов стало бы меньше, процессы бы стали чуть лучше, но наверное, никто бы этого даже особо не заметил. Наш герой был не таков.

Сначала он запрограммировал систему мониторинга этих самых нотификаций (руками, дело было лет 10 назад). Затем в течение месяца собирал данные с этой системы мониторинга. Затем опросил тех, кому нотификации приходят и аккуратно задокументировал ущерб и важность задачи. После за пару дней сделал фикс. Затем подождал еще пару недель, собирая новые данные, где нотификаций стало меньше.

В процессе работы отсылал коллегам промежуточные отчеты. В финале оформил финальный отчет, разослал всем и подшил к себе для того, чтобы показать на employee performance evaluation. Мужика страшно бесило осознание факта того, что лишь так можно получить столь любимые менеджерами измеримые результаты.

На реддите угорали над этим бюрократическим цирком и думали, что бы стало с их компаниями, поступай работники так же. А я пока гуглил эту байку, две иишки мне сказали что она вошла в Google SRE Handbook уже не как пример сливания девелоперского таланта на фигню, а как пример отличного и правильного поведения.

Хорошая история. :-)
Метрики ради метрик могут быть и такими, да.
Но моя статья немного о другом.

Кстати, Ваша история напомнила мне наш случай. Когда выпускали новый функционал, заказчики попросили присылать им нотификации в мессенджер. Так вот я, как аналитик, прикинула, и мне показалось, что слать им все нотификации - плохая идея, будет реально много спама. Но заказчики настаивали. Ну, ок, хозяин - барин. Но флаг в сеттинги для оперативного отключения нотификаций в ТЗшечку заложила. И что? В первый же день работы нового функционала аналитики завопили о спаме, и волшебный флажок (продуманный аналитиком) спас всех.

Аналитики же не нужны...
Если появился системный аналитик, значит надо смотреть почему он появился, какую проблему решает, исходя из этого и можно ставить метрики.

А вот сейчас обидно было. 😁

Считаю, что мы нужны и даже очень. Но статья не об этом. И как раз привожу метрики для разных вариантов работы аналитика.

Ну в целом все метрики, касающиеся скорости разработки, доработки и прочее вполне распространяются на всю команду, не только на аналитика.

Не поспоришь.

Но мне часто задавали вопросы, как доказать руководству, что аналитик в команде нужен. Вот про это и статья.

У вас есть подушка.

Она либо удобная либо нет.

Но конечно же, надо правильно измерить пушистость, почасовую ночную степень уплотнения, составить график износа, ассиметричности при попоротах головы и ещё 20-30 полезных атрибутов, чтобы подушки, наконец-то, можно было сравнить между собой. А то что они без шилдиков ходят...

Видимо, я не донесла свою мысль в статье. Речь не о метриках ради метрик.

Подумаю, почему уже второй комментарий не по теме статьи, поработаю над изложением своих мыслей.

Интересно, в какой команде и какой системный аналитик может показаться лишним или не эффективным? В моей практике во мне как в аналитике ни разу не усомнились, т.к. разрабы и бизнес никогда не могли сами договориться и сразу получить нужный результат. В разработке я с 2011 года.

Увы и ах, много таких команд. Я в разработке с тех пор, когда такой специальности ещё даже не было. 😁

Почитайте, я описывала, как в одной из команд аналитику строила с нуля: https://habr.com/ru/articles/974272/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации