Comments 15
Статья интересная, эмоциональная, поучительная.
Но такое впечатление, что вы всё-таки не о бизнес-аналитиках, а о системных аналитиках рассказываете. ?
Добрый день!
Большое спасибо, рад был быть полезным :)
Коллега на проекте из кейса выполняла роль именно БА. И отталкивался я от метрик, которые именно к KPI БА можно привязать.
Скажите, почему именно такое впечатление сложилось у вас после прочтения статьи?
Сразу скажу - то, что я напишу ниже - это моё субъективное мнение (кроме БА и СА) и его нельзя рассматривать как придирки (у кого-то другого будет иное мнение и так далее).
Начну с конца.
слова "честно", "кинут" - явно носят сильную эмоциональную окраску и не имеют никакого отношения к системе оценки KPI, которые направлены на достижение конкретных целей, поэтому в целом субъективны и не могут учитывать всех ньюаснов и аспектов;
"экспертное мнение руководителя в нашем случае было всегда обоснованным и справедливым" - аналогично, мнение любого человека субъективно и он его не должен обосновывать, а понятие "справедливость" - это отдельная тема и к KPI опять таки отношения не имеет;
"ответственность за продукт - она, командная, да" - это всё так, но если мы не будем доискиваться до причины конкретного бага, то они так и будут повторятся (пример - именованные (номерные) инструменты авиамехаников в довоенной авиации и не только):персонификация ответственности улучшает качество.
А про БА и СА - вы можете и сами погуглить (системные аналитики vs бизнес-аналитики). Вкратце: бизнес-аналитики к ИТ не имеют отношения никакого, только если как заказчик, но имеют отношение к бизнес-процессам.
P.S. И ошибки типа "вовлеченность аналика" поправьте, пожалуйста.
бизнес-аналитики к ИТ не имеют отношения никакого
Не соглашусь, уж простите.
Анализ бизнес-процессов организации - управление требованиями уровня БТ и ПТ - моделирование процессов (любимые наши BPMN и UML), разработка документа BRD - это все зона ответственности БА. СА вступает чуть позже, на этапе разработки SRS.
https://www.google.com/search?q=системные+аналитики+vs+бизнес-аналитики
Вы точно уверены, что БТ и БП - это то, чем за что отвечает ИТ?
Забавно.
В термине "Бизнес-аналитик" присутствует некоторая семантическая неоднозначность.
С одной стороны, профстандарт говорит нам, что основными функциями БА являются:
Работа с заинтересованными сторонами
Обеспечение изменений в организации
Выявление бизнес-проблем или бизнес-возможностей
Обоснование решений
Управление бизнес-анализом
Аналитическое обеспечение разработки стратегии изменений организации
С другой стороны, работодатель ждет от кандидата на вакансию БА в сфере разработки ИТ таких навыков, как:
Сбор требований, формализация и согласование требований с заказчиком
Работа в распределенной команде заказчика, по его процессам и приоритетам
Составление User Stories и написание US спецификаций
Опыт описания процессов в нотации BPMN2.0
(цитата просто из случайной вакансии на должность БА в ИТ-компании).
Разумеется, роль БА в ИТ может выполнять и продакт, и проджект, и СА, и даже разработчик, которого не стошнит общаться с заказчиками. Однако в крупных проектах под фазу анализа и моделирования as is/to be все-таки выделяют конкретные ресурсы, у которых "бизнес-аналитик" написано и во внутреннем реестре ресурсов, и в трудовой книжке.
Поэтому я и уверен, что описание БП, формирование требований и такого документа, как BRD, при разработке/доработке информационных систем - это вполне себе делянка БА.
Вот здесь еще статья про это, с которой можно согласиться.
Сколько людей - столько и мнений.
Но по моей практике БА анализирует бизнес, а СА - системы (поэтому и системный), а технический проект на будущую систему разрабатывает архитектор вместе с дизайнером и тим-лидами.
Более-менее нормальное определение ВА и СА данное в Википедии:
Business analysis has been defined as "a disciplined approach for introducing change to organization"[1] through management, processing, and interpretation of data in order to "identify and define the solution that will maximize the value delivered by an organization to its stakeholders".[1]
A systems analyst, also known as business technology analyst, is an information technology (IT) professional who specializes in analyzing, designing and implementing information systems.
А то, как эти понятия в организация понимаю и кого куда относят - вопрос отдельный.
Возможно, KPI по количеству багов это попытка руководства завернуть в BA процессы Problem Management (я имею ввиду ITIL), чтобы разобраться как можно минимизировать импакт дефектов на организацию. В любом случае, грамотный BA может проанализировать ситуацию и предложить руководству свой вариант. Вариант делегировать баги в "команду" звучит скорее как отказ выполнять такую работу.
KPI - всего лишь инструмент перераспределения прибыли в карман заинтересованного лица(владельца) . Остальное информационный шум.
KPI это "офисная чума", сильно переоцененный и опасный инструмент, распространяется семинарами. Однако она все же лучше интуитивного управления по "трем П", кумовства и самотека. По крайне мере пока не придумали что-то получше.
Собственников, поддавшихся на уговоры внедрить KPI, с самого начала напрягает то что нигде нет устоявшихся практик и стандартов, приходится выдумать каждую метрику самим и с нуля.
Сбалансированность самопридуманных показателей - спорна, подконтрольность метрик исполнителям часто не превышает 50%, а 80% персонала после увольнения не могут объяснить как они могли влиять на них. Но все безусловно рады когда KPI и премия синфазно растут. В некоторых случая подсознательно люди становятся добрее (сейлзы с CSI - так те вообще превращаются в сладкоречивых, но кто бы им сказал что это быстро надоедает и работает на ограниченном контингенте покупателей, никак не укладывающемся в букву ABC/XYZ-анализа).
Хорошо когда, как в статье, есть корректирующие коэффициенты от топ-персоналий, позволяющие обмануть скрыть главное противоречие и хоть как-то оправдать систему (ес-но, недешевую, основанную на дорогих эффективных менеджерах, новом ПО и тотальной цифровизации).
Противоречие это в том что если фирма прибыль не получила, но KPI высокий - то и стимулировать "нет денег", а значит "системность" KPI нарушена. Раз системность нарушается - то KPI не может и не должна становиться главной системой управления и мотивации (но только так ее и позиционируют).
Альтернатив KPI немного, но они есть, и даже более эффективные, при этом практически бесплатные. Например, внезапное обследование домашних холодильников персонала даст руководителю куда более точные, веские и действенные персональные поправочные коэффициенты к базовой премии, чем все эти KPI , КТУ и прочие эрзац-КПД.
Считаю, что будет правильно дать ссылки на первоисточники.
Статья начинается с того, что к автору обратились за помощью с рабочим кейсом.
Подоздеваю, что обсуждаемый кейс - это тот, который на скриншотах из нашего чата (но это неточно).
Однако, я точно знаю источник ментальной карты, которой иллюстрирвоанна данная статья. Ее составил Дмитрий Савченко во время нашей встречи в сообществе аналитиков, где мы обсуждали KPI. В данном артефакте зафиксировано не совсем то, что происходило на встрече. Это мысли конкретного человека на конкретную тему, которые приходили ему во время встречи и которые он фиксировал в виде ментальной карты. Вот тут он делится картой с сообществом https://t.me/sys_analyst_chat/3363
Есть запись встречи, но она пока в обработке.
Игорь, привет!
Спасибо за комментарий. Касательно кейса - да, совершенно верно, это тот кейс. Только фишка в том, что коллега обратилась сначала ко мне, а потом уже в ваш чат :) ну или это было сделано параллельно. И ответил я в личке первым.
Просто в какой-то момент я понял, что тема будет интересна всем подписчикам, поэтому выложил статью на своем канале. И в том числе тут на Хабре.
Статья моя уже разошлась по многим каналам по системному анализу в ТГ.
В встрече вашего клуба я не участвовал, хотя очень хотелось. И вы об этом знаете.
Использование ментальной карты с Димой я согласовал. Так что пытаться уличить меня в чем-то не нужно. И карта отлично отражает суть проблемы KPI в моем понимании.
К слову, очень жду запись встречи. Все еще интересно послушать мнения коллег!
Значит вопрос обсуждался и в чате и в личной переписке.
Ментальную карту Дима готовил по результатам встречи в чате и разрешил ее использовать. При использовании чужого материала, я его не выдаю за свой и указываю автора материала и в каком контексте он применяется автором (конечно если источник известен).
Это наверно самый идиотский KPI о котором я слышал.
Аналитику, за баги, найденные в течении двух недель. Просто сюр.
Почему 2 недели? А если фича не затронута последующими обновлениями, но баги находятся? Что если баги косвенно аффектят фичу? Что если баги вне фичи, но при внедрении фичи - проявились? Баги из-за third party софта используемого в коде фичи? А если девопс не правильно кеш (varnish, nginx, cloud) поставил, потому что красноглазил? А если эффективный манагер который придумал этот KPI - заебал звонками разраба и тот забыл фиксануть ошибку перед релизом?
Как вообще аналитик относится к багам? Как можно считать поведение системы - багом, если система ведёт себя в соответствии со спекой аналитика, которую апрувнул продакт, но мы видим что тут явно "шото не то"?
Гоните эффективных палкой и ссаными тряпками, они не понимают что делают и не хотят понимать.
KPI внедрили, а аналитика спросить забыли…