Версия для печати

Программный инструмент аналитика          Ключевые инструменты аналитиков          Облачный сервис Битрикс24

 

Вся правда об аналитиках


Настольная книга аналитика. Практическое руководство по проектированию бизнес-процессов и организационной структуры
Видео-курс "Ключевые инструменты аналитиков: описание и оптимизация бизнес-процессов с целью внедрения информационной системы (ИС)"
Программный инструмент аналитика "Бизнес-инженер"
Сергей Длужневский -
ведущий менеджер проектов
по проектированию, разработке
и внедрению информационных систем

Введение

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

Для большей части людей известно, что те, кто создают такие системы, называются программистами. Меньшая часть знает, что кроме программистов (разработчиков) есть еще тестировщики, архитекторы, дизайнеры, аналитики. Вот о последних и пойдет речь.

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

Какие бывают проекты, и какие бывают аналитики

Для начала давайте разберемся, какие бывают проекты, и какие бывают аналитики.

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

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

Кстати, нередко возникают ситуации, когда IT-проект становится прямым продолжением консалтингового проекта. И нередко оба вида деятельности, о которых мы поговорим позднее, выполняются одним аналитиком.

Какую же роль выполняют аналитики в одном и другом случае.

Задача аналитика в консалтинговом проекте – изучить текущую ситуацию в бизнесе и предложить способ эту ситуацию улучшить. Для этого аналитик изучает и описывает существующие бизнес-процессы компании, анализирует и находит слабые места, предлагает пути оптимизации. Естественно, делает он все это не один, а в тесном сотрудничестве с работниками компании. При этом аналитик может быть как экспертом в той предметной области, которой он занимается, так и не иметь об этой области никакого представления (естественно, речь идет только о начале проекта). Но имеющиеся у него методики, специфические знания и навыки позволяют ему быстро погрузиться в требуемую предметную область, а также быстро "вытягивать" требуемую информацию из настоящих экспертов.

Основная задача IT -аналитика – сбор и исследование хаотичной, неструктурированной и порой разрозненной информации об ожиданиях и потребностях заказчика с целью получения детальных, структурированных и непротиворечивых требований к системе, автоматизирующей оптимизированный (крайне желательно) бизнес-процесс заказчика. Аналитик – ключевая фигура проектной команды на аналитической стадии проекта и важная фигура на последующих стадиях. Он помогает заказчику определить, действительно ли то, что говорит заказчик, нужно воплощать в виде информационной системы, или может быть часть сказанного – лишнее, а несказанное – наоборот, очень важно. Аналитик выступает своеобразным интерфейсом между представителями заказчика и командой разработки. Каждая из этих сторон обладает своими знаниями и говорит на своем языке. Задачей аналитика является владеть обоими языками и необходимыми знаниями, чтобы обеспечить максимально точное соответствие того, что реализуется, тому, что требуется реализовать.

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

Бизнес-аналитик и системный аналитик – в чем разница

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

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

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

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

Не стоит забывать и о затраченном времени на передачу информации от одного узла другому.

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

Правда, существуют проекты и даже компании, где от аналитика требуют очень детального знания каких-то технологий. Фактически на уровне грамотного разработчика. И основные его задачи в этом случае сводятся как раз к изучению существующих технических решений и подготовке спецификаций требований, ориентируясь именно на текущую реализацию. Например, от пользователя поступил запрос на добавление или изменение какого-то поля экранной формы. Аналитик изучает, как устроена система, определяет взаимосвязи, начиная от уровня пользовательского интерфейса вплоть до уровня базы данных. Анализирует внутренние системные алгоритмы, часто даже в виде программного кода. После чего он готовит спецификацию на чисто техническом языке, где описывает названия полей, приводит конкретные запросы к базе и т.д. Насколько такой специалист является аналитиком – пусть каждый решает сам. В настоящее время придуманы различные именования, использующим слово "аналитик" (например, Performance Analyst, P rogrammer-Analyst), которыми называют специалистов, участвующих в разработке ПО, но мы говорим об аналитике, именно, как о постановщике задачи в классическом понимании этого термина.

Должен ли аналитик быть экспертом предметной области

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

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

Некоторые считают, что без постоянной актуализации знаний (особенно в областях, которые меняются очень быстро) такие "просроченные знания" для большинства проектов бесполезны и даже вредны. Поэтому, аналитик, длительное время не работавший с конкретной предметной областью, уже не может считаться предметником.

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

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

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

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

Зачем нужен аналитик на проекте

Рассматривая проект по созданию некоего программного обеспечения, мы сосредоточимся на стадии анализа, в которую включены два этапа. Первый – предпроектное обследование автоматизируемой области (в организациях, занимающихся разработкой ПО на заказ, такой этап часто называют "продажей проекта"). Второй - непосредственно сами проектные работы, в которые можно включить выявление, анализ и формализацию требований к будущей системе (см. схему 1).

Схема 1. Детализация аналитической стадии проекта

Схема 1. Детализация аналитической стадии проекта

Говоря в общем, можно утверждать, что стадия анализа является основополагающим участком процесса разработки ПО, на котором разрозненные и подчас не вполне определенные ожидания и пожелания Заказчика формализуются в виде детальных и структурированных требований к будущей системе. А эти требования, в свою очередь, являются тем фундаментом, на котором будет строиться вся дальнейшая разработка системы. Именно поэтому стадия анализа так важна. В свое время была очень популярная картинка, которая висела во многих комнатах, где размещались IT-отделы. На ней было изображено, как сформулировал задачу заказчик, как ее понял разработчик, что получилось в итоге, и что требовалось на самом деле. Сейчас ее, наверное, уже мало кто помнит, однако она максимально точно передает, что может получиться в результате проекта, на котором отсутствует аналитик (либо, если аналитик некачественно выполнил свою работу).

За годы работы мне приходилось общаться с огромным количеством самых разных людей со стороны заказчика. И порой, глядя на готовую систему и вспоминая, как формулировалась задача в самом начале проекта, оставалось только удивляться – как все это далеко друг от друга. Заказчик никогда не сформулирует четко, что именно и как именно он хочет. В основном, присутствует некая идея, некая концепция, для чего предназначена система и что она примерно должна делать. Как правило, эта идея выдается на переговорах руководством. Дальше к работе подключаются другие исполнители со стороны заказчика. У каждого из них свое видение и свое понимание, как это должно быть реализовано. И чем больше людей вовлечено в процесс постановки задачи, тем сложнее найти истину. Она оказывается, как всем нам давно известно, "где-то рядом". Отсутствие четкого понимания цели разрабатываемой системы, отсутствие единого согласованного мнения между всеми заинтересованными сторонами "как это должно работать" - вот основные риски аналитической стадии проекта, и как следствие, самого проекта целиком. И задача аналитика состоит в том, чтобы предупредить эти риски, попытаться их избежать или, если риск реализовался, максимально снизить его воздействие. Один мой коллега на тренингах приводил своим студентам пример, в котором проектная команда движется по минному полю, а впереди идет аналитик. Подорвется он – подорвется вся команда. Чем закончится такой проект – объяснять, думаю, не надо. Аналитические ошибки могут стоить проекту очень и очень дорого.

Что должен делать аналитик и чего он делать НЕ должен

Что должен делать аналитик.

Что не должен делать аналитик.

Говоря в общем, для аналитика система представляет собой некий "черный ящик", который должен преобразовывать определенные заданные входы в определенные заданные выходы, на основе заданных правил преобразования. Каким образом это будет реализовано технически – лежит вне зоны компетенции аналитика.

Если разделить всю задачу по автоматизации на две области – область проблемы, которая отвечает на вопрос, "что должно быть сделано?", и область решения, которая отвечает на вопрос, "как (каким образом) это реализовать?", то компетенция аналитика будет распределяться, примерно, как 80 на 20. Т.е., 80 процентов его деятельности лежит в области проблемы, а 20 – в области решения (см. схему 2).

Компетенция аналитика

Схема 2. Компетенция аналитика

Может возникнуть вопрос: если мы говорим о том, что аналитик не занимается проектированием системы и ее реализацией, то, что такое, эти 20%?

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

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

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

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

Что касается одного из качеств требований – РЕАЛИЗУЕМОСТИ, то здесь должны подключаться уже разработчики (технические специалисты). Правильным подходом считается параллельно с согласованием документов у заказчика осуществлять согласование у разработчиков. Естественно, что в ходе разработки периодически возникают ситуации, когда приходится менять некоторые требования, потому что технические специалисты в силу различных причин не могут реализовать так, как аналитик написал в спецификации. И в этом случае в результате сложных многоступенчатых переговоров приходится приходить к компромиссам. В этом случае аналитику приходится вникать в нюансы реализации.

 

Что должен знать и уметь аналитик

Перечень того, чем требуется владеть аналитику, может быть очень и очень большим. Намного больше, чем имеющиеся ограничения для данной статьи. Особенно, если рассматривать каждый навык подробно. Поэтому мы рассмотрим основные, базовые вещи, а нюансы при необходимости можно будет отыскать самостоятельно (см. схему 3).

Основные требования, предъявляемые к аналитику

Схема 3. Основные требования, предъявляемые к аналитику

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

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

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

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

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

Поскольку одним из основных направлений деятельности аналитика является моделирование, то знание различных методологий, нотаций и инструментов моделирования является жизненно необходимым. Среди методологий и нотаций нет худших или лучших, поэтому умение "играть" нотациями в ходе проекта, в зависимости от решаемой задачи – это то, что отличает специалиста от новичка. Необходимо уметь не только грамотно моделировать, но при необходимости также быстро обучить заинтересованных лиц читать модели. Иногда случается так, что моделирование становиться для аналитика самоцелью. Аналитик строит модель ради самой модели, и практическая ценность работы стремится к нулю. Перед началом моделирования важно четко определить цель, границы, а также аудиторию, для которой осуществляется моделирование. Аналитик должен всегда об этом помнить.

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

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

Аналитик должен грамотно писать, уверенно владеть текстовыми и табличными редакторами, уметь адаптировать под нужды проекта стандартные шаблоны документов, а при необходимости – разрабатывать новые.

С кем и как взаимодействует аналитик

В ходе проекта аналитику приходится взаимодействовать с самыми различными людьми, как по уровню компетенции, так и по уровню позиции, как со стороны заказчика, так и со стороны проектной команды. Естественно, что различные категории заинтересованных лиц требуют различных подходов в общении в зависимости от того, какие вопросы с ними обсуждаются. У различных сторон различное видение создаваемого продукта, поэтому одной из основных задач аналитика является формирование единого взгляда на продукт, за счет согласования требований с каждой категорией заинтересованных лиц. Подписываясь под требованиями к системе, заказчик подтверждает, что это именно то, что ему нужно и за что он готов платить, разработчик – что понимает, что требуется реализовать и может это сделать, тестировщик – что может обеспечить требуемое качество.

Давайте коротко рассмотрим, с кем в основном взаимодействует аналитик в ходе проекта (см. схему 4).

Лица, с которыми взаимодействует аналитик в рамках проекта

Схема 4. Лица, с которыми взаимодействует аналитик в рамках проекта

Со стороны заказчика.

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

С руководителями со стороны заказчика (если, конечно, они не являются пользователями системы) обсуждаются бизнес-требования. Это достаточно высокоуровневые пожелания, которые показывают, что именно требуется от системы, чтобы она принесла пользу бизнесу в целом. Фактически требования такого рода задают границы и масштаб системы. Все требования, которые лежат ниже этого уровня (пользовательские и детальные), должны укладываться в рамки, заданные бизнес-требованиями.

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

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

Со стороны проектной команды.

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

Разработчики (технические специалисты) являются основными потребителями результатов работы аналитика. В основном для них аналитик и готовит свои документы. Термин "технические специалисты" приведен не просто так. Помимо непосредственно разработчиков (программистов) в команде может быть выделены роли, например, архитектора системы и архитектор базы данных, которые непосредственно разработчиками не являясь, закладывают фундамент того решения, которое и будет в итоге выстроено. Технические специалисты не вникают в нюансы бизнеса, который требуется автоматизировать. Они работают с требованиями. Логичность и взаимосвязанность требований, как и результат, к которому приведет их совокупность, здесь не рассматриваются. Конечно, при реализации требований в виде кода, разработчики могут натолкнуться на какие-то ситуации, которые заставят их сформулировать к аналитику вопросы, а того, в свою очередь, пересмотреть спецификации.

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

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

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

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

Ошибки аналитика

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

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

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

Версия для печати
Яндекс.Метрика Rambler's Top100

Copyright © 2001-2024 БИТЕК (Бизнес-инжиниринговые технологии)