Всем привет! Меня зовут Коля, и я аналитик. Помимо этого, я являюсь руководителем отдела анализа в компании. По роду службы меня занимает вопрос критериев оценки аналитиков – как понять, аналитик «хороший» или «плохой»? Надо повысить зарплату или уволить? Давайте разбираться в этом непростом вопросе.
Сразу скажу, что никакой серебряной пули в этой статье не будет (и не надейтесь!). Давно мечтаю о формальной процедуре, которая выдавала бы объективную оценку сотрудника и справедливый уровень оплаты труда – но увы. Приходится во многом полагаться на субъективные оценки.
Контекст и точка зрения
Очевидно, что ответ на вопрос «хороший это аналитик или не очень» зависит от контекста (что это за аналитик, в какой компании он работает, какие задачи решает) и от точки зрения (кто оценивает, по каким критериям).
Поскольку я нахожусь внутри конкретного контекста, то просто опишу его:
Заказная разработка.
РФ. Существует мнение, что за рубежом содержание работы аналитиков значимо отличается от РФ. Мой опыт данное мнение не подтверждает, но и не позволяет опровергнуть (т.к. выборка слишком мала).
Совмещенная роль «бизнес-аналитик + системный аналитик» с уклоном в сторону системного анализа.
В других контекстах материал данной статьи применим с ограничениями – может меняться как набор критериев, так и их приоритеты. Например, с продуктовой разработкой, вероятно, есть существенная разница.
Также много зависит от точки зрения – кто оценивает. Аналитик взаимодействует с людьми, у каждого из которых есть свои ожидания и критерии оценки.
Часто вижу, как в ходе оценки одни аналитики оценивают других аналитиков исключительно по профессиональным качествам: кто знает больше видов диаграмм UML - тот и круче. Мнение других членов команды при этом учитывается мало - "да что они понимают в работе аналитика".
Я совмещаю много ролей в компании, в которых сталкиваюсь с аналитиками. Какие-то роли ситуативные, какие-то – постоянные. Это позволяет смотреть на вопрос оценки аналитиков шире – примерно как «оценка 360».
Разберем отдельно по каждой роли – каковы мои цели в этой роли, и что мне нужно от аналитика чтобы я мог достичь этих целей. Статья на 100% состоит из личного опыта, поэтому мои цели в некоторых ролях могут показаться наивными (т.к. это второстепенные роли для меня).
Руководитель проекта
Мои цели как руководителя проекта:
Уложиться в проектный треугольник – функциональность, время и бюджет, при соблюдении приемлемого уровня качества.
Удовлетворенность заказчика – чтобы он хотел и дальше работать с нами.
Удовлетворенность команды – чтобы она не разбежалась и не говорила «никогда больше с этим идиотом работать не будем».
Проекты бывают как по фиксированной цене (fix price), так и на «почасовке» (time & material). Цели в обоих случаях одни и те же – только в первом случае наиболее приоритетна цель про проектный треугольник, а во втором – цель про удовлетворенность заказчика.
В большинстве случае в команде есть один или более аналитиков. Что я как руководитель проекта от них ожидаю?
Длительное сотрудничество – как минимум до конца проекта или хотя бы этапа проекта. Смена аналитика в середине проекта – это огромный риск.
Соблюдение сроков. Если аналитик сказал что «задача будет готова через 2 дня» - то я ожидаю, что она будет готова через 2 дня. Если этому препятствуют какие-то объективные факторы – я хочу как можно раньше про них узнать, чтобы выработать «план Б».
Обеспечение уровня качества, достаточного для реализации целей проекта.
Нетоксичность, способность находить общий язык с членами команды и представителями заказчика. Внутренние конфликты в команде – риск для проекта.
Границы. Разработка ПО – не конвейер, технологические операции не настолько формализованы и не так четко отделены друг о друга. Важно, чтобы аналитик понимал, где его зона ответственности (согласно правилам, принятым в этой команде), где зона ответственности другого члена команды, а где – серая зона, где они совместно решают возникающие задачи.
Компетентность. Аналитик – лицо компании, он часто взаимодействует с заказчиком и другими внешними по отношению к команде лицами. Не хочется краснеть, если аналитик начнет нести какую-то дичь. Репутацию сложно заработать, но легко потерять.
Самостоятельность. Как менеджер, а не хочу думать о вопросах, которые аналитик может решить самостоятельно. Если для решения вопроса нужно участие других членов команды – то по меньшей мере первую попытку организовать обсуждение аналитик должен сделать самостоятельно.
Ресурсный менеджер
Как ресурсный менеджер, я выступаю в качестве «поставщика рабочей силы» (как бы грубо это не звучало) для проектов. Мои клиенты – это руководители проектов и лиды аналитики проектов. Как ресурсный менеджер, я хочу чтобы мои клиенты были довольны – т.к. в том числе на основании оценок от них вышестоящий руководитель оценивает меня.
Что я как ресурсный менеджер ожидаю от аналитиков?
Длительное сотрудничество. Я хочу, чтобы аналитик работал в компании долго, так как новый сотрудник первое время неэффективен (как правило), что вызывает понятное недовольство клиентов. Люди, которые рассказывают про необходимость смены работы раз в 2-3 года, для меня (в ипостаси ресурсного менеджера) – мексиканские негодяи.
Универсальность. Нежелательно, если аналитик имеет узкую специализацию – его гораздо сложнее «пристроить» в проект. Быть экспертом в строительстве вантовых мостов – это прекрасно, но в строительной компании общего профиля больше пользы принесет крепкий универсал-середняк.
Эффективность – см. предыдущий раздел про цели руководителя проектов. Понятно, что все руководители проектов разные, но цели у них плюс-минус одинаковые. И качества от аналитика нужны примерно те же.
Умение оставить хорошее впечатление от сотрудничества. Хочется не допускать ситуации, когда руководитель проекта говорит «не, мне Петю на новый проект не надо, мне на предыдущем с ним не понравилось работать». В существенной части это покрывается предыдущим пунктом, но есть и субъективный фактор – насколько приятно было иметь дело с этим человеком.
Гибкость. У разных руководителей проектов бывает разное представление о том, что такое хорошо, и что такое плохо. Понятно, что внутри компании есть общий фарватер (который задаётся топ-менеджментом), но в пределах этого фарватера могут быть любые варианты.
Аналитик
Периодически я участвую в различных проектах в роли аналитика. Как правило, это не роль ведущего аналитика проекта, а временное усиление проблемных проектов в качестве «пожарной команды». То есть связь с другими аналитиками на проекте – горизонтальная.
В роли лида аналитики проекта я выступаю редко, так как это роль требует погружения и желательно полной занятости на проекте.
Интересным парадоксом являются взаимоотношения с ведущим аналитиком данного проекта. С одной стороны, я являюсь его непосредственным руководителем. С другой стороны, на данном проекте я выступаю как один из членов команды и уступаю право принятия ключевых решений. Это выглядит как раздвоение личности, и необходимо в каждый момент времени четко понимать – а в какой роли я сейчас нахожусь?
Что я как аналитик на проекте ожидаю от коллег?
Компетентность. Всегда приятно работать с умными людьми, у которых можно что-то подчерпнуть. Ну или хотя бы чтобы не было необходимости вставать в позицию наставника и объяснять очевидные вещи (когда при этом сроки горят).
Нетоксичность. Без комментариев, кажется что это очевидно.
Границы – в данной случае не между ролями, а между задачами. Я занимаюсь этой задачей, аналитик рядом – другой задачей, и мы уважаем границы и компетенции друг друга. А вот здесь у нас пересечение, и мы совместно работаем над решением.
Аккуратность и внимание к мелочам. Если мы вместе работаем над документацией к одному продукту, то хочется чтобы у нас были сопоставимые представления о требуемом уровне качества. Если в требованиях, написанных другим аналитиком, всё «мутно», не совсем актуально и с кучей помарок – возникает желание всё это переписать. Что противоречит предыдущему пункту о границах.
Отсутствие избыточного перфекционизма. Этот пункт является обратным к предыдущему. Если у другого аналитика требования к качеству выше чем у меня (и я считаю их избыточными в данной ситуации), то всевозможные "придирки" в процессе ревью вызывают только раздражение. Не всегда это правильно, но такого природа человека.
Разработчик
Разработчик для меня – это эпизодическая роль, иногда пишу ETL-процессы на PL/pgSQL. Полагаю, что у «настоящих» разработчиков цели более глобальные, чем у меня в этой роли. Итак, что же я как разработчик ожидаю от аналитика?
Границы – между «что делать» и «как делать». Поиск наилучшего технического решения для реализации требований – это моя задача как разработчика, не хочу чтобы аналитик диктовал технические решения. Надо отметить, что отделять этап анализа от этапа проектирования – это совсем не просто.
Отсутствие короны на голове. Несколько раз встречал аналитиков, которые занимали позицию – «я аналитик, я решаю что делать, а вы все исполнители». Это близко к предыдущему пункту, но в предыдущем был вопрос процессный, а здесь – личностный.
Доступность. Если у меня возник вопрос, который блокирует мою работу, хочется максимально быстро получить ответ на него и двигаться дальше.
Качество требований в технической части. Здесь я имею в виду точность формулировок, непротиворечивость, отсутствие «воды» - текста, который можно удалить без потери смысла. Тратить когнитивный ресурс на то, чтобы понять что имел в виду аналитик – непродуктивно.
Качество требований в бизнес-части. Здесь я имею в виду, что в требованиях описано именно то, что нужно заказчику. Изменение и уточнение требований на основании обратной связи от пользователей – это нормально. А вот если в требованиях описано совсем не то, что нужно заказчику, и реализация идёт в корзину – это демотивирует.
Заказчик
Для реализации узкоспециализированных частей проектов мы периодически привлекаем субподрядчиков. Если это аутстафф (т.е. «аренда людей») – то см. пункт про руководителя проектов. В данном пункте про привлечение субподрядчиков по модели fix price. Моя цель как заказчика – чтобы было сделано то что нужно за адекватные деньги и без лишней головной боли.
Что я как заказчик ожидаю от аналитика подрядчика?
Опять же границы, но уже другие. С одной стороны, я ожидаю что аналитик подрядчика не будет задавать кучу вопросов, ответ на которые очевиден или может быть найден на первой странице выдачи поисковой системы. С другой стороны, я ожидаю что аналитик подрядчика не будет пытаться домысливать ответы на вопросы, которые относятся к специфике нашего продукта, и ответы на которые не очевидны. Такие Сцилла и Харибда – надо пройти по грани.
Экспертность. Как правило, субподрядчиков привлекаем, если сами не обладаем достаточными компетенциями в данной области. Например, я понятия не имею как сделать «правильный» лендинг, и поэтому ожидаю что аналитик подрядчика будет в этом экспертом.
Сотрудничество. См. предыдущий пункт – если аналитик подрядчика – это эксперт в лендингах, то я – эксперт в предметной области нашего продукта. И нужно совместить это две экспертизы. Для этого нужна готовность к взаимодействию и умение слышать друг друга.
Знание нотаций и стандартов. Если мне нужно договориться с подрядчиком о том, как будет реализовано интеграционное взаимодействие, то я скорее всего нарисую UML Sequence. Хочется, чтобы аналитик подрядчика умел по меньше мере читать общепринятые нотации, а желательно еще и составлять.
Понятно что от подрядчика есть и другие ожидания, но они относятся к подрядчику в целом (или в команде подрядчика в целом), а не конкретно к аналитику.
Выгодоприобретатель
Под этим термином я подразумеваю лицо, прямо заинтересованное в финансовых показателях компании. Это может быть как акционер, так и сотрудник, уровень дохода которого непосредственно зависит от финансового результата компании или подразделения.
Моя цель как выгодоприобретателя – максимизация прибыли в среднесрочной перспективе. Что для этого нужно от аналитика?
Длительное сотрудничество. Я хочу, чтобы аналитик работал в компании долго, так как замена сотрудника – это очень дорого.
Окупаемость. Компания тратит на сотрудника деньги (ФОТ, соцпакет, иные расходы) и получает от деятельности сотрудника доход. Важно чтобы доходы были выше расходов.
Cпособность идти в ногу со временем. Содержание работы и инструментарий аналитиков постепенно меняются (хоть и не быстро), если аналитик отстаёт от времени – его ценность на рынке снижается. И тогда его приходится либо увольнять (см. «длительное сотрудничество»), либо мириться со снижением эффективности (см. «окупаемость»). Понижать зарплаты в IT как-то не принято.
Если аналитик способен идти в ногу со временем (и особенно если он способен делать это самостоятельно) – это большой плюс.
Потребитель
Часто слышу тезис: «наши лучшие показатели – довольные покупатели» (т.е. пользователи), но мне кажется что для оценки качества аналитика это не имеет смысла. Как потребитель, я не сталкиваюсь непосредственно с аналитиком (и даже не знаю что он вообще существует), а использую продукт, в создании которого участвовал аналитик.
Продукт – результат работы команды, не стоит переоценивать роль аналитика: связь между «качеством» аналитика и качеством продукта крайне опосредованная.
Заключение
Какие из всего это можно сделать выводы?
Аналитик – не червонец, чтобы нравиться всем. Есть много заинтересованных лиц, у которых пусть и схожие, но всё же разные требования к аналитику. Противоположными они бывают редко, но приоритеты и нюансы отличаются.
В статье приведены требования одного человека, пусть и выступающего в разных ролях. При этом общее "ядро" всё равно есть. Если это разные люди, выступающие в разных ролях - то разброс будет еще больше.
Есть две стратегии, как быть «хорошим аналитиком»:
3.1. Простая стратегия – хорошо делать свою работу и быть нормальным договороспособным человеком.
3.2. Сложная стратегия – выбрать целевую аудиторию (чья оценка наиболее важна), узнать цели этой аудитории и действовать в соответствии с ними.Простая стратегия в большинстве случаев достаточно эффективна (если не брать во внимание организации со специфической корпоративной культурой) и безупречна с морально-этической точки зрения.
Сложная стратегия имеет узкую применимость – например, можно рассмотреть ситуацию, когда решение о повышении заработной платы или должности зависит от одного конкретного человека. В такой ситуации может быть разумным работать на цели именно этого человека.
При этом сложная стратегия может иметь морально-этические изъяны – разделение людей на «важных» и «неважных», игнорирование мнения и потребностей тех, кто признан «неважным».В долгосрочной перспективе простая стратегия, с моей точки зрения, более эффективна.
И напутствие для всех аналитиков:
