Критерии качества аналитиков

Всем привет! Меня зовут Коля, и я аналитик. Помимо этого, я являюсь руководителем отдела анализа в компании. По роду службы меня занимает вопрос критериев оценки аналитиков – как понять, аналитик «хороший» или «плохой»? Надо повысить зарплату или уволить? Давайте разбираться в этом непростом вопросе.

Сразу скажу, что никакой серебряной пули в этой статье не будет (и не надейтесь!). Давно мечтаю о формальной процедуре, которая выдавала бы объективную оценку сотрудника и справедливый уровень оплаты труда – но увы. Приходится во многом полагаться на субъективные оценки.

Контекст и точка зрения

Очевидно, что ответ на вопрос «хороший это аналитик или не очень» зависит от контекста (что это за аналитик, в какой компании он работает, какие задачи решает) и от точки зрения (кто оценивает, по каким критериям).

Поскольку я нахожусь внутри конкретного контекста, то просто опишу его:

• Заказная разработка.

• РФ. Существует мнение, что за рубежом содержание работы аналитиков значимо отличается от РФ. Мой опыт данное мнение не подтверждает, но и не позволяет опровергнуть (т.к. выборка слишком мала).

• Совмещенная роль «бизнес-аналитик + системный аналитик» с уклоном в сторону системного анализа.

В других контекстах материал данной статьи применим с ограничениями – может меняться как набор критериев, так и их приоритеты. Например, с продуктовой разработкой, вероятно, есть существенная разница.

Также много зависит от точки зрения – кто оценивает. Аналитик взаимодействует с людьми, у каждого из которых есть свои ожидания и критерии оценки.

Часто вижу, как в ходе оценки одни аналитики оценивают других аналитиков исключительно по профессиональным качествам: кто знает больше видов диаграмм UML — тот и круче. Мнение других членов команды при этом учитывается мало — «да что они понимают в работе аналитика».

Я совмещаю много ролей в компании, в которых сталкиваюсь с аналитиками. Какие-то роли ситуативные, какие-то – постоянные. Это позволяет смотреть на вопрос оценки аналитиков шире – примерно как «оценка 360».

Разберем отдельно по каждой роли – каковы мои цели в этой роли, и что мне нужно от аналитика чтобы я мог достичь этих целей. Статья на 100% состоит из личного опыта, поэтому мои цели в некоторых ролях могут показаться наивными (т.к. это второстепенные роли для меня).

Руководитель проекта

Мои цели как руководителя проекта:

• Уложиться в проектный треугольник – функциональность, время и бюджет, при соблюдении приемлемого уровня качества.

• Удовлетворенность заказчика – чтобы он хотел и дальше работать с нами.

• Удовлетворенность команды – чтобы она не разбежалась и не говорила «никогда больше с этим идиотом работать не будем».

Проекты бывают как по фиксированной цене (fix price), так и на «почасовке» (time & material). Цели в обоих случаях одни и те же – только в первом случае наиболее приоритетна цель про проектный треугольник, а во втором – цель про удовлетворенность заказчика.

В большинстве случае в команде есть один или более аналитиков. Что я как руководитель проекта от них ожидаю?

• Длительное сотрудничество – как минимум до конца проекта или хотя бы этапа проекта. Смена аналитика в середине проекта – это огромный риск.

• Соблюдение сроков. Если аналитик сказал что «задача будет готова через 2 дня» — то я ожидаю, что она будет готова через 2 дня. Если этому препятствуют какие-то объективные факторы – я хочу как можно раньше про них узнать, чтобы выработать «план Б».

• Обеспечение уровня качества, достаточного для реализации целей проекта.

• Нетоксичность, способность находить общий язык с членами команды и представителями заказчика. Внутренние конфликты в команде – риск для проекта.

• Границы. Разработка ПО – не конвейер, технологические операции не настолько формализованы и не так четко отделены друг о друга. Важно, чтобы аналитик понимал, где его зона ответственности (согласно правилам, принятым в этой команде), где зона ответственности другого члена команды, а где – серая зона, где они совместно решают возникающие задачи.

• Компетентность. Аналитик – лицо компании, он часто взаимодействует с заказчиком и другими внешними по отношению к команде лицами. Не хочется краснеть, если аналитик начнет нести какую-то дичь. Репутацию сложно заработать, но легко потерять.

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

Ресурсный менеджер

Как ресурсный менеджер, я выступаю в качестве «поставщика рабочей силы» (как бы грубо это не звучало) для проектов. Мои клиенты – это руководители проектов и лиды аналитики проектов. Как ресурсный менеджер, я хочу чтобы мои клиенты были довольны – т.к. в том числе на основании оценок от них вышестоящий руководитель оценивает меня.

Что я как ресурсный менеджер ожидаю от аналитиков?

• Длительное сотрудничество. Я хочу, чтобы аналитик работал в компании долго, так как новый сотрудник первое время неэффективен (как правило), что вызывает понятное недовольство клиентов. Люди, которые рассказывают про необходимость смены работы раз в 2-3 года, для меня (в ипостаси ресурсного менеджера) – мексиканские негодяи.

• Универсальность. Нежелательно, если аналитик имеет узкую специализацию – его гораздо сложнее «пристроить» в проект. Быть экспертом в строительстве вантовых мостов – это прекрасно, но в строительной компании общего профиля больше пользы принесет крепкий универсал-середняк.

• Эффективность – см. предыдущий раздел про цели руководителя проектов. Понятно, что все руководители проектов разные, но цели у них плюс-минус одинаковые. И качества от аналитика нужны примерно те же.

• Умение оставить хорошее впечатление от сотрудничества. Хочется не допускать ситуации, когда руководитель проекта говорит «не, мне Петю на новый проект не надо, мне на предыдущем с ним не понравилось работать». В существенной части это покрывается предыдущим пунктом, но есть и субъективный фактор – насколько приятно было иметь дело с этим человеком.

• Гибкость. У разных руководителей проектов бывает разное представление о том, что такое хорошо, и что такое плохо. Понятно, что внутри компании есть общий фарватер (который задаётся топ-менеджментом), но в пределах этого фарватера могут быть любые варианты.

Аналитик

Периодически я участвую в различных проектах в роли аналитика. Как правило, это не роль ведущего аналитика проекта, а временное усиление проблемных проектов в качестве «пожарной команды». То есть связь с другими аналитиками на проекте – горизонтальная.
В роли лида аналитики проекта я выступаю редко, так как это роль требует погружения и желательно полной занятости на проекте.

Интересным парадоксом являются взаимоотношения с ведущим аналитиком данного проекта. С одной стороны, я являюсь его непосредственным руководителем. С другой стороны, на данном проекте я выступаю как один из членов команды и уступаю право принятия ключевых решений. Это выглядит как раздвоение личности, и необходимо в каждый момент времени четко понимать – а в какой роли я сейчас нахожусь?

Что я как аналитик на проекте ожидаю от коллег?

• Компетентность. Всегда приятно работать с умными людьми, у которых можно что-то подчерпнуть. Ну или хотя бы чтобы не было необходимости вставать в позицию наставника и объяснять очевидные вещи (когда при этом сроки горят).

• Нетоксичность. Без комментариев, кажется что это очевидно.

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

• Аккуратность и внимание к мелочам. Если мы вместе работаем над документацией к одному продукту, то хочется чтобы у нас были сопоставимые представления о требуемом уровне качества. Если в требованиях, написанных другим аналитиком, всё «мутно», не совсем актуально и с кучей помарок – возникает желание всё это переписать. Что противоречит предыдущему пункту о границах.

• Отсутствие избыточного перфекционизма. Этот пункт является обратным к предыдущему. Если у другого аналитика требования к качеству выше чем у меня (и я считаю их избыточными в данной ситуации), то всевозможные «придирки» в процессе ревью вызывают только раздражение. Не всегда это правильно, но такого природа человека.

Разработчик

Разработчик для меня – это эпизодическая роль, иногда пишу ETL-процессы на PL/pgSQL. Полагаю, что у «настоящих» разработчиков цели более глобальные, чем у меня в этой роли. Итак, что же я как разработчик ожидаю от аналитика?

• Границы – между «что делать» и «как делать». Поиск наилучшего технического решения для реализации требований – это моя задача как разработчика, не хочу чтобы аналитик диктовал технические решения. Надо отметить, что отделять этап анализа от этапа проектирования – это совсем не просто.

• Отсутствие короны на голове. Несколько раз встречал аналитиков, которые занимали позицию – «я аналитик, я решаю что делать, а вы все исполнители». Это близко к предыдущему пункту, но в предыдущем был вопрос процессный, а здесь – личностный.

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

• Качество требований в технической части. Здесь я имею в виду точность формулировок, непротиворечивость, отсутствие «воды» — текста, который можно удалить без потери смысла. Тратить когнитивный ресурс на то, чтобы понять что имел в виду аналитик – непродуктивно.

• Качество требований в бизнес-части. Здесь я имею в виду, что в требованиях описано именно то, что нужно заказчику. Изменение и уточнение требований на основании обратной связи от пользователей – это нормально. А вот если в требованиях описано совсем не то, что нужно заказчику, и реализация идёт в корзину – это демотивирует.

Заказчик

Для реализации узкоспециализированных частей проектов мы периодически привлекаем субподрядчиков. Если это аутстафф (т.е. «аренда людей») – то см. пункт про руководителя проектов. В данном пункте про привлечение субподрядчиков по модели fix price. Моя цель как заказчика – чтобы было сделано то что нужно за адекватные деньги и без лишней головной боли.

Что я как заказчик ожидаю от аналитика подрядчика?

• Опять же границы, но уже другие. С одной стороны, я ожидаю что аналитик подрядчика не будет задавать кучу вопросов, ответ на которые очевиден или может быть найден на первой странице выдачи поисковой системы. С другой стороны, я ожидаю что аналитик подрядчика не будет пытаться домысливать ответы на вопросы, которые относятся к специфике нашего продукта, и ответы на которые не очевидны. Такие Сцилла и Харибда – надо пройти по грани.

• Экспертность. Как правило, субподрядчиков привлекаем, если сами не обладаем достаточными компетенциями в данной области. Например, я понятия не имею как сделать «правильный» лендинг, и поэтому ожидаю что аналитик подрядчика будет в этом экспертом.

• Сотрудничество. См. предыдущий пункт – если аналитик подрядчика – это эксперт в лендингах, то я – эксперт в предметной области нашего продукта. И нужно совместить это две экспертизы. Для этого нужна готовность к взаимодействию и умение слышать друг друга.

• Знание нотаций и стандартов. Если мне нужно договориться с подрядчиком о том, как будет реализовано интеграционное взаимодействие, то я скорее всего нарисую UML Sequence. Хочется, чтобы аналитик подрядчика умел по меньше мере читать общепринятые нотации, а желательно еще и составлять.

Понятно что от подрядчика есть и другие ожидания, но они относятся к подрядчику в целом (или в команде подрядчика в целом), а не конкретно к аналитику.

Выгодоприобретатель

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

Моя цель как выгодоприобретателя – максимизация прибыли в среднесрочной перспективе. Что для этого нужно от аналитика?

• Длительное сотрудничество. Я хочу, чтобы аналитик работал в компании долго, так как замена сотрудника – это очень дорого.

• Окупаемость. Компания тратит на сотрудника деньги (ФОТ, соцпакет, иные расходы) и получает от деятельности сотрудника доход. Важно чтобы доходы были выше расходов.

• Cпособность идти в ногу со временем. Содержание работы и инструментарий аналитиков постепенно меняются (хоть и не быстро), если аналитик отстаёт от времени – его ценность на рынке снижается. И тогда его приходится либо увольнять (см. «длительное сотрудничество»), либо мириться со снижением эффективности (см. «окупаемость»). Понижать зарплаты в IT как-то не принято.
  Если аналитик способен идти в ногу со временем (и особенно если он способен делать это самостоятельно) – это большой плюс.

Потребитель

Часто слышу тезис: «наши лучшие показатели – довольные покупатели» (т.е. пользователи), но мне кажется что для оценки качества аналитика это не имеет смысла. Как потребитель, я не сталкиваюсь непосредственно с аналитиком (и даже не знаю что он вообще существует), а использую продукт, в создании которого участвовал аналитик.

Продукт – результат работы команды, не стоит переоценивать роль аналитика: связь между «качеством» аналитика и качеством продукта крайне опосредованная.

Заключение

Какие из всего это можно сделать выводы?

1. Аналитик – не червонец, чтобы нравиться всем. Есть много заинтересованных лиц, у которых пусть и схожие, но всё же разные требования к аналитику. Противоположными они бывают редко, но приоритеты и нюансы отличаются.

2. В статье приведены требования одного человека, пусть и выступающего в разных ролях. При этом общее «ядро» всё равно есть. Если это разные люди, выступающие в разных ролях — то разброс будет еще больше.

3. Есть две стратегии, как быть «хорошим аналитиком»:
   3.1. Простая стратегия – хорошо делать свою работу и быть нормальным договороспособным человеком.
   3.2. Сложная стратегия – выбрать целевую аудиторию (чья оценка наиболее важна), узнать цели этой аудитории и действовать в соответствии с ними.

4. Простая стратегия в большинстве случаев достаточно эффективна (если не брать во внимание организации со специфической корпоративной культурой) и безупречна с морально-этической точки зрения.

5. Сложная стратегия имеет узкую применимость – например, можно рассмотреть ситуацию, когда решение о повышении заработной платы или должности зависит от одного конкретного человека. В такой ситуации может быть разумным работать на цели именно этого человека.
   При этом сложная стратегия может иметь морально-этические изъяны – разделение людей на «важных» и «неважных», игнорирование мнения и потребностей тех, кто признан «неважным».

6. В долгосрочной перспективе простая стратегия, с моей точки зрения, более эффективна.

И напутствие для всех аналитиков: