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

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

Этот же вопрос беспокоил Владимира Маяковского еще в 1925 году

Этот же вопрос беспокоил Владимира Маяковского еще в 1925 году

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

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

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

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

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

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

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

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

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

Достаточно повернуть голову - и 6 превращается в 9. Рост на 50% без усилий!

Достаточно повернуть голову — и 6 превращается в 9. Рост на 50% без усилий!

Часто вижу, как в ходе оценки одни аналитики оценивают других аналитиков исключительно по профессиональным качествам: кто знает больше видов диаграмм 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. В долгосрочной перспективе простая стратегия, с моей точки зрения, более эффективна.

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

Всем настоятельно рекомендую!

Всем настоятельно рекомендую!

© Habrahabr.ru