Мастерская бизнес-анализа

ИТ-аналитик: От линии фронта до модели компетенций

20.12.2010 at 18:41 4 комментария

Долго я собиралась, но потом все-таки посмотрела видео с круглого стола 2010-10-28 сообщества системных аналитиков на тему «Модель компетенции аналитика», ну и постоянно слежу за всеми обсуждениями этой темы.

Толчком к тому, чтобы уже сесть наконец за пост, в котором собрать мнения и выразить свое, послужила статья Андрея Вербицкого «Анализ. Основы и философия» в №3 журнала AnalyzeIT Сообщества Системных аналитиков.

Сама я термином «философия» по отношению к нашей профессии никогда не пользовалась, да и сейчас считаю, что это немного перебор – привыкла относиться к предмету философии с особым пиеететом. Но в данном случае –термин – это не суть. Мне показалось, что подход Андрея мне наиболее близок, видимо потому что не сводит нашу профессию к формализму техник и инструментов, которым страдают очень многие формулировки и описания, не смотря на декларируемую НЕ приверженность этим самым техникам и инструментам.

В обсуждении на форуме после круглого стола на тему «Модель компетенции аналитика», возникла такая фраза: «..на просторах Интернета была обнаружена статья «Бизнес-аналитик – свой человек за линией фронта». Статья эта «обнаружилась» еще в 2005г., принадлежит перу Б. Шлаина, независимого консультанта , (часть сайта, посвященая бизнес-анализу сейчас не доступна) и широко гуляет по разным сайтам, почти всегда одной первых выдается в поиске.

И еще одну статью я использую в сегодняшнем обзоре – она гораздо меньше известна и цитируема, опубликована в декабре 2009г: «Бизнес-аналитик: инженер, врач или шаман?».Автор Петр Газарян.

Сразу отмечу: ни в одной из трех статей, которые я взяла для первого обзора, термин «компетенции» не употребляется. Ну и я пока не буду.

Зато и Б. Шлаин и П. Газарян используют сравнение с профессией врача, и это мне кажется и не случайным, и очень почетным. Шлаин пишет: «Бизнес-аналитик – это, с точки зрения клиента, еще или уже не программист. Это человек, которому можно рассказать о бизнесе примерно так же, как пожаловаться своему врачу – и он должен где-то посоветовать лекарство, а где-то просто успокоить словом».

Газарян в этом вопросе более подробен: «Иногда бизнес-аналитик – это действительно врач. Врач, который выслушает, правильно поставит диагноз и составит курс лечения, либо просто скажет клиенту – вы здоровы, у вас все хорошо». А дальше – очень правильный пример-аналогия: «Знакомый врач-педиатр как-то рассказывал мне, что маленькие дети говорят, что у них болит живот, даже если на самом деле болит спина. У педиатров есть определенные методики определения того, что же на самом деле болит у маленького ребенка – ведь ребенок не может выразить это на понятном врачу языке. Это, между прочим, хороший подход к клиенту – я бы назвал его pediatric-approach».

Еще одна медицинаская аналогия – это Денис Бесков, 2008г (здесь большая и довольно любопытная дискуссия).

Пациент приходит к врачу:

Пациент: Здравствуйте, доктор! Вы знаете, у меня что-то плечо болит. Я хочу, чтобы оно перестало. Дайте мне пожалуйста рецепт на что-то типа Бисептола.

Доктор: Ага, так и запишем — «Иванов А.Е., болит у него нечто». Вот вам рецепт.

Спустя несколько дней: Пациент: Добрый день. Вы знаете, ни черта не помог этот Бисептол, только сильнее болеть стало. Дайте мне пожалуйста какой-нибудь Фервекс.

Доктор: Ну что ж, Фервекс так Фервекс, держите. Проходит ещё несколько дней, новая сцена с похожим паттерном.

Что думает пациент? «Вот идиот этот доктор, даёт всё время что-то бестолковое»?

Что думает доктор? «Вот идиот этот пациент, сам не знает, чего хочет»?

Возможна такая сценка только при том условии, что доктор — никакой не доктор, а в лучшем случае — лаборант, и даже не врач. Потому что мы понимаем, что для успешного излечения нужно: 1. Исследовать историю болезней пациента; 2. Установить текущие симптомы; 3. Выполнить необходимые анализы и обследования; 4. Установить на основе вышеизложенного диагноз; 5. Назначить соответствующее лечение. Причём это обязанности врача, в широком смысле – медицинского учреждения.

И Шлаин, и Газарян, и Бесков говорят о «бизнес-аналитике в ИТ», и я склонна с ними согласиться, исходя из того, что в нашем традиционном словесном обиходе «системный аналитик» — это все же специалист больше работающий с инструментами, моделями и разработчиками. Хотя это обсуждение — БА или СА – не прекращается (вот один из последних примеров ), но это все же наш «внутриайтишный вопрос».

Вербицкий формулирует это так: «Часть школ в отрасли поддерживает несколько искусственное, но принятое сейчас деление на системных и бизнес аналитиков». Будем считать, что я тоже принадлежу к этой части, и дальше буду везде писать (или иметь ввиду) что речь идет об ИТ бизнес-аналитике.

При этом, Газарян использует фразу, которую мне за свою жизнь в профессии пришлось произнести наверное не одну сотню раз: «истина где-то посередине». Но с его следующей фразой, которая в среде ИТ профессионалов уже стала притчей во языцах: «… в большинстве случаев наши клиенты не знают чего они хотят на самом деле!», я никак не могу согласиться (и Бесков в приводимом выше посте не соглашается).

Если продолжить аналогию с ребенком и педиатром – ребенок ведь знает, что у него болит, или тут точнее сказать – чувствует. Он не может высказать это на языке понятном взрослому. Наши клиенты всегда знают что они хотят. Это мы не понимаем их в силу нескольких причин. И одна из основных причин — разные языки. Клиент говорит, и говорит, как правило, превосходно, на своем профессиональном языке. А мы–то говорим на другом языке (некоторые его птичьим называют). Я даже не беру во внимание нашу приверженность к английскому языку.  Прислушайтесь как мы говорим на своих мероприятиях – это ведь уже не русский… (на последнем круглом столе одни «скилы» чего стоят). Но и по-русски мы говорим так, что люди из других сфер нас не понимают. Они даже иногда комплексуют по этому поводу. И часто стараются изучать сферу ИТ, много читают рекламные бумаги разных ИТ фирм. Это порой приводит к тому, что клиенты говорят нам не то, что отражает их реальные потребности (говорят, что живот болит, а на самом деле – спина). «Бизнес-аналитик приходит к клиенту, выслушивает его, определяет истинные потребности, которые зачастую не совпадают с высказываемыми вслух, и это позволяет построить именно такое решение, которое необходимо пользователю».

Последняя аналогия с медициной у Газаряна – про специализацию. У врачей она есть, но у российских врачей она, в большинстве случаев, черезмерна. Поэтому здесь я бы прямую аналогию Газаряна (и пожелания к бизнес-аналитикам хорошо разбираться в предметной области заказчика) с врачами-специалистами проводить не стала бы. Остается – надо «знать основы построения бизнеса. Это конечно приходит с опытом, как и у врача». Метафора Шлаина с «линией фронта» мне представляется хоть и удачной для популярности публикации, но не совсем правильной с точки зрения системы отношений между участниками процессов создания ИТ систем. Правда, судя по тексту, автор применил все же эту метафору больше «для красоты». «… для руководителя группы разработки и архитектора бизнес-аналитик – это такой агент, шпион, которого можно «забросить за линию фронта» в компанию-клиента, чтобы он добыл ценные сведения о пожеланиях клиента и его стратегии развития своего бизнеса».

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

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

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

Это и у Шлаина, и у многих других: «Бизнес-аналитик в информационных технологиях – это человек, выступающий в роли интерфейса между ИТ и бизнесом, который может говорить на одном языке с представителями обеих областей и может организовать совместную работу над предметной областью. Его главная задача – сделать так, чтобы информационная система отвечала потребностям бизнеса». У Азаряна: «Бизнес-аналитик – это посредник между заинтересованными лицами для сбора, анализа, коммуницирования и проверки требований по изменению бизнес-процессов, регламентов и информационных систем» — определение со ссылкой на Международный институт бизнес-анализа. «Фредерик Брукс в своем знаменитом эссе «Серебряной пули нет: сущность и акциденция в программной инженерии» писал, что «наиболее сложная часть разработки программной системы – это решить, что же собственно необходимо разработать». Как раз в решении этого вопроса и состоит работа бизнес-аналитика».

 Снова Шлаин (и ни с чем не поспоришь): «Основная роль бизнес-аналитика – это разработка непротиворечивой и достаточно полной модели требований реального бизнеса. Это задача не столько описательная и созерцательная («просто напишите, как у нас все происходит и автоматизируйте»), а творческая. Уже расхожим стало выражение об «автоматизации беспорядка», которая только ухудшает общую ситуацию. Но и «прямолинейная автоматизация» очень часто исключает из процесса те самые «отдушины» и «обходные пути», которые и обеспечивают известную российскую «нестрогость законов» и позволяют бизнес-системе в целом работать. И клиент вправе ожидать от бизнес-аналитика наличия систематизированных знаний о предметной области, а также опыта аналогичных проектов в других предприятиях. Иногда бизнес-аналитику приходится предлагать организационные схемы за рамками автоматизированной системы – «а как же отдел будет работать, пока ваш модуль еще не внедрен». Соавторами бизнес-аналитика при разработке модели требований являются ключевые пользователи (или потенциальные пользователи).»

И я бы продолжила эту мысль так: и задача бизнес-аналитика помочь пользователям изъяснить и описать свои проблемы, потребности, преобразуя их в требования так, чтобы «сблизить языки», мягко и аккуратно преодолевая языковые проблемы. (похожая мысль тоже есть у Бескова).

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

«Когда бизнес приходит и говорит – мне нужно это… Почему мы должны еще выяснять, что конкретно нужно? Очевидно, что потому, что сама по себе разработка программ – достаточно сложная и дорогая штука. А мы хотим, чтобы программа понравилась покупателю. Кроме того, IT-проект это не только софт. Это еще и его внедрение. Использование. Поддержка. Наконец, это прекращение его использования – а почему нет? Ведь это тоже часть жизненного цикла. Поэтому – мало сделать ПО. Надо еще сделать его так, чтобы оно вписывалось в бизнес нашего заказчика, чтобы использование программы приносило ожидаемую выгоду. Для этого мы формулируем бизнес-требования, занимаемся описанием бизнес-процессов. (Программный продукт – это некий набор функциональности. Но бизнес не работает через «фичи» и функциональность. Бизнес хорошо описывается как набор процессов).

А вот дальше уже вступает вторая метафора Газаряна: «Бизнес-аналитик – это инженер. И результат его труда вполне осязаем. Как и у врача, у аналитика есть свой бумажный рецепт – это документ с описанием требований к разрабатываемой системе. Все техники, приемы и методологии анализа предметной области заказчика, выделения, анализа, документирования и управления требованиями хорошо описаны.

Аналитик на проекте по разработке ПО должен:

1.  Выделить, задокументировать и согласовать и утвердить со всеми заинтересованными сторонами требования к разрабатываемому продукту
2.  Наладить процесс управления требованиями и обеспечить его выполнение всеми сторонами
3.  Поддерживать команду проекта во время разработки приложения

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

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

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

А теперь посмотрим на третью метафору Газаряна – «Шаман».  Он приводит свой личный пример, личную победу и комментирует: «Маленькая победа после пляски с бубном и раскуривания трубки мира. В этом и состоит сущность работы бизнес-аналитика: уметь задавать правильные вопросы, и задавать их так, чтобы получить на них правильные ответы. А надо помнить, что правильно заданный вопрос – это половина ответа».

 И я приведу личный пример. Это из давних начала 90-х. Мы приехали в другой город смотреть систему, аналогичную той, что мы разрабатываем. Но «у них» — нет ИТ-аналитика (тогда были довольно маленькие системы, часто их делалали на пару – будущий конечный пользователь и программист/ы). Я начинаю задавать вопросы. Программист, демонстрирующий систему, по началу бойко пытается отвечать, но потом входит в ступор и тихо говорит: «а нам раньше таких вопросов никто не задавал». Немного жаль этих программистов – они пытались делать систему «с голоса пользователя», а это совсем не есть хорошо. Никогда даже самый лучший эксперт предметной области не сможет задать вопросы и получить ответы на них, которые полностью позволят опеделить требования.

«Шаманство заключается в том, — продолжает Газарян- что вы обладаете каким-то набором личных качеств – как и в любом другом деле. Для аналитика эти качества это конечно же аналитический склад ума, терпеливость, хорошие навыки общения, внимание к деталям, которого обычно не хватает, умние задавать правильные вопросы, умение подняться над деталями технической реализации, посмотреть на проектируемую систему глазами заказчика, пользователя, а не разработчика. Шаманство в том, что хотя мы и говорим о процессе разработки ПО как об инженерии, наибольшее количество проблем, с которыми сталкиваются софтверные проекты, лежит вовсе не в области инженерии, а в области общения между людьми. А общение между заказчиками и разработчиками всегда трудно, так как различны цели, различно восприятие мира. Бизнес-аналитик это посредник между клиентом и разработчиком, переводчик, и что еще?… Переговорщик.

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

А теперь приведу мнение и формулировки А.Вербицкого:

 «Технической базой для аналитика являются три ключевых навыка:

1. умение общаться;
2. умение работать с информацией;
3. умение «смотреть на ситуацию чужими глазами».

Однако, одной только технической базы еще не достаточно для того, что бы быть действительно хорошим аналитиком. Требуется нечто большее – определенная система взглядов или, если хотите — определенная философия. Настоящий аналитик – это искусный, внимательный наблюдатель. И не просто наблюдатель, а наблюдатель, который может рассуждать о явлении или объекте как в терминах их предметной области, так и в терминах любого другого явления или объекта. Он способен свободно менять «горизонт» и «позицию», «систему координат» и «сектор» своего наблюдения, при этом всегда оставаясь за границами наблюдаемого явления. Аналитик может описать наблюдаемую им картину в статике и динамике, с нужной степенью детализации или абстракции, он обладает интуицией, позволяющей ему видеть не только видимые части мозаики явления, но также скрытые или отсутствующие фрагменты и силы, может давать им оценку. Аналитик всегда может легко расширить предлагаемую ему систему координат, если она недостаточна для описания явления или наоборот – ограничить ее, если она слишком обширна. Аналитик видит объект или явление как сами по себе, так и как часть системы, может понять и описать ее закономерности и правила. При этом, он – талантливый повествователь, который может легко и ярко передать свои наблюдения как устно, так и на бумаге для самой разной аудитории. Он – интересный собеседник и может расположить к себе людей, сделав так, чтобы они захотели с ним говорить. Для развития этих качеств, требуется много упорных и целенаправленных усилий, освоение новых знаний и специальных практик, их постоянная тренировка и поддержка».

И еще А.Вербицкий сформулировал мысль, которую я давно вынашивала:

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

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

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

Роль и название должности ИТ бизнес-аналитика могут изменяться от компании к компании и даже от проекта к проекту.

И стандарта на эту профессию/должность/роль? нет.

Вот такой пока получился первый обзор на тему ИТ бизнес-аналитиков. Точно не последний.

Entry filed under: Бизнес/аналитик, Обзоры. Tags: ИТ специалист, Термины, бизнес-анализ, бизнес-аналитик.