Недавно я послушал подкаст “Идеальный бизнес-аналитик глазами разработчика” своего очень хорошего друга. Не со всеми тезисами я был согласен, однако подкаст побудил меня начать обсуждение с участниками подкаста. А потом еще и сам побывал в этом подкасте в качестве гостя.

Чтобы понять, кто такой “идеальный аналитик”, важно определиться с набором требований. Что я жду от аналитика как разработчик? А как тимлид? А как менеджер проекта? Сколько людей, столько и мнений, и я тоже хочу порассуждать о том, каков он - этот неуловимый идеальный аналитик.

Идеальный аналитик…

…глазами других участников проекта

  • Аналитик глазами разработчика. Для разработчика важно, чтобы тикет был понятен, краток и емкий. Так разработчик реализует тикет без переделок, тестировщик понимает, как нужно тестировать максимально эффективно, а тимлид и менеджер проекта не страдают.
  • Аналитик глазами тимлида и проектного менеджера. Для тимлида важно, чтобы тикет был реализован вовремя и в соответствии с планом. А это достигается, если тикет прописан максимально качественно. Проектному менеджеру это так же важно, как и тимлиду.

В целом, аналитик идеален тогда, когда результат его работы - тикеты - идеален.

…пишет качественные тикеты

Но что же за зверь такой, этот “качественный тикет”? Этот тикет отвечает на все вопросы разработчика, какие бы у него они не возникли. Тут важно соблюсти баланс: тикет можно перегрузить так, что у любого читающего будет возникать вопросов больше, чем их было до его прочтения. Любой тикет должен содержать критерии приемки, которые будут полезны и разработчику, и тестировщику, и тимлиду, и проектному менеджеру. Без них, на мой взгляд, сложно понять, что же хочет увидеть в конечном итоге заказчик функциональности. Если тикет привносит новую функциональность, то критериев приемки будет достаточно.

Если тикет меняет предыдущую функциональность, то лучше всего написать требования в формате “было → стало”. Нужно не забыть и о ссылках на связанные ресурсы. Так читающий получит возможность прочесть больше контекста измененной бизнес-фичи.

…общается эффективно

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

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

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

…отдает все свои усилия проекту

Выше я затронул очень важный момент - отдача проекту. Каждый ее участник должен вкладываться в проект максимально. Цель участия в проекте каждого - улучшение этого проекта, и никаких других целей не должно быть.

Мотивация у каждого может быть своя - деньги, знания, расширение компетенций. Но все эти варианты мотивации абсолютно не противоречат цели самого проекта. Я не понимаю людей, которые говорят “я на проекте только из-за денег”. Мысленно я продолжаю их мысль так: “... поэтому вкладываться я не буду, даже и не ждите”. А зачем еще человеку говорить подобное? Если ты хочешь денег больше, новых знаний или прокачаться в программной архитектуре, то ты сможешь это реализовать, отдавая проекту все свои усилия. Как тимлида, меня приводит в уныние работа, сделанная вполсилы.

Аналитик тоже может прокачаться в новой для себя бизнес-сфере проекта. Но идеальный аналитик - как раз тот, кто отдается проекту на все 100%.

…с чувством юмора (опционально)

Это качество желательно, но не обязательно. Как бы ни было странно, но все мы - люди, и мы хотим общаться с приятными нам людьми. На мой взгляд, если у человека есть чувство юмора, то он адекватен в общении. Не обязательно общаться с аналитиком вне рамок работы и рабочего проекта, но если есть возможность перекинуться парой слов с ним в курилке, то это - приятно и благоприятствует дружелюбной атмосфере в команде.

Не обязательно, чтобы человек всем нравился. Главное - чтобы он выполнял свои задачи эффективно. Однако мы ведь говорим об идеальном аналитике, поэтому я отметил это качество. Если уж не повезло настолько, что аналитик оказался токсичным человеком, то только верно выстроенная система коммуникации убережет остальных членов команды от его токсичности. Если уж не повезло с чувством юмора, то, благодаря правильной письменной коммуникации, атмосфера в команде не пострадает.

А тяжело ли найти идеального аналитика

Да, тяжело. Как и идеального разработчика, тестировщика или проектного менеджера. Хорошо, что уже имеющийся аналитик на проекте может прокачаться до уровня, близкого к идеальному. Поэтому не все так страшно и депрессивно, как может показаться. На поиск или взращивание идеального тиммейта может уйти вся жизнь, но я думаю, что оно того стоит.