Сегодня мы поговорим о профессии аналитика, качествах, которыми должны обладать аналитики, а также очертим плюсы и минусы этого ремесла.
Итак, кто же такой аналитик? Наиболее простое и близкое к ИТ определение: аналитик – это промежуточное звено между заказчиком программного продукта (а также будущими его пользователями) и его разработчиками. Представьте, что вы решили построить дом и наняли для этого бригаду гастарбайтеров из недалеких солнечных стран. Какова вероятность того, что, объясняя им суть ваших пожеланий, вы не потратите себе нервы, стараясь донести до них мысль, что то, что они делают, не есть «красиво и удобно»? А как вы отреагируете на их заявления типа «вам конвектор в полу нужен»? Несомненно, вы, в конце концов, найдете с ними общий язык. Но теперь представьте, что в индустрии разработки ПО специализированный сленг/понятия/принципы построения систем в разы сложнее и объемнее, а программисты зачастую проявляют гораздо больше нежелания вас понимать и общаться с вами обыденным человеческим языком (извиняйте, читающие нас программисты; вы не все такие:)). Вот тут-то и приходит на помощь этот самый аналитик. Международный Институт Бизнес-Анализа (IIBA, International Institute of Business Analysis) определяет бизнес-аналитика как профессионала, который «понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей.»
На практике, суть работы аналитика может варьироваться в зависимости от роли аналитика на проекте. Наиболее часто встречающиеся разновидности IT-аналитиков это:
1. Бизнес-аналитик (Business Analyst, BA) – как правило, это специалист, занимающийся изучением и моделированием конкретной предметной области. Другими словами, он должен выяснить пожелания заказчика, проанализировать их, дополнить при необходимости, оформить определённым образом (построить модели, задокументировать хотя бы общие пожелания клиента) и передать команде разработки. BA – лицо команды, общительный, тактичный, легко находящий общий язык с заказчиком. Технические знания (или, пользуясь модным нынче словом, бэкграунд) бизнес-аналитику совсем не обязательны, гораздо важнее – знание языка заказчика и особенностей его культуры.
2. Системный аналитик (System Analyst, SA) – аналитик, значительно более приближенный к команде разработки, чем БА; специалист, который должен транслировать команде высокоуровневые требования к ПО, полученные от бизнес-аналитика, в виде детальных функциональных требований к системе, естественно, на языке команды разработчиков. Зачастую ему приходится также предлагать конкретное техническое решение и проектировать архитектуру системы.
3. Аналитик требований (Requirements Analyst, RA) – нечто среднее между BA и SA. В официальной классификации ЕКСД РБ эта должность отсутствует, однако во многих западных теориях RA присутствует как специалист, который отвечает за извлечение, анализ, документирование и моделирование требований, т.е., упрощенно, за написание спецификаций требований для их дальнейшей передачи разработчикам. В отличие от BA, аналитику требований недостаточно просто выяснить высокоуровневые требования – он еще отвечает за разработку детального описания проектируемой системы. В то же время, RA не обязательно обладать глубокими знаниями в IT и разрабатывать архитектуру системы, так как для этого среди программистов есть выделенные архитекторы и проектировщики систем.
Большинство аналитиков в любой аутсорсинговой компании в нашей стране (то бишь, компании, занимающейся разработкой ПО под заказ) – это именно аналитики требований. Редкая фирма в наших условиях может позволить себе держать «чистого» бизнес-аналитика, который хорошо разбирается в какой-то одной предметной области, плюс держать его в постоянных командировках, поближе к «телу заказчика». К тому же загрузить такого аналитика работой хотя бы на 80% будет весьма проблематично, в то время как затраты на его содержание довольно значительны. Хотя, стоит все же отметить, что такие компании и такие аналитики у нас есть. Что же касается системных аналитиков, то без наличия BA в штате они имеют мало смысла, за исключением случаев, когда попадается заказчик с бизнес-аналитиками со своей стороны или же заказчик-профессионал, знающий и умеющий донести до команды свои «хотелки» (да-да, далеко не все заказчики точно знают, чего хотят).