Print Friendly, PDF & Email

Кто такие бизнес-аналитики

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

При работе над большинством проектов в IT возникает два главных вопроса: Сколько это будет стоить и Сколько на это уйдет времени? Проектные менеджеры сразу вспомнят проектный треугольник, про который я уже писал не один раз:

Проектный треугольник

При разработке ПО необходимо сосредотачиваться на том, что нужно предоставить то что необходимо, вовремя и по средствам

Проекты можно вести по разному, но в последнее время широкую популярность получили Change Driven подходы, которые подразумевают итерационный подход. Самым популярным из них есть Agile.

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

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

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

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

Бизнес-аналитик это человек, который может спасти проект от провала, от “сделали, но не то что нужно”.

Пример:

Представьте ситуацию, заказчик отправляет разработчику ссылку на конкурентов и говорит: «Мне нужен сайт! Точно, как вот этот!» Программист: «Я не понимаю, что значит “точно”. Дайте ТЗ, меньше придется перерабатывать».

Заказчик идет к своему другу, по совместительству бизнес-аналитику, пожаловаться на программиста. Далее – диалог между заказчиком и бизнес-аналитиком.

Заказчик: Вот ты мне скажи, ЧТО ЗДЕСЬ НЕПОНЯТОГО? Взять и сделать точно такой же сайт, неужели так сложно повторить?
Бизнес-аналитик (печальным голосом): Ну, вообще-то, я на стороне программиста. Непонятно в твоем запросе все. Сейчас докажу. Давай вместе посмотрим, что тебе нравится в этом сайте. Здесь есть кнопка Сравнить, она тебе нужна?
Заказчик: Нет, не нужна .
Бизнес-аналитик: У этих людей на сайте отдельная страница для доставки и еще одна – для оплаты, тебе точно нужно две страницы или можно доставку и оплату объединить в одну страницу?
Заказчик: Можно соединить, мне действительно две страницы нечем заполнять.
Бизнес-аналитик: Видишь, уже выходит не один в один, правда?
Заказчик: Я наверняка имел в виду скорее визуальное оформление.
Бизнес-аналитик: А программист говорил о функционале.

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

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

Чего хочет клиент?

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

Но в итоге вы должны сделать такое ПО, которое будет соответствовать всем требованиям заказчика.

У бизнес-аналитиков (давайте все таки подразумевать, что в проекте есть такая отдельная роль) в арсенале есть множество техник сбора требований:

  • анкетирование – составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.
  • интервью – беседа “по душам” с заинтересованным лицом, тет-а-тет. Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований.
  • автозапись – работа с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер).
  • изучение существующей документации
  • повторное использование существующих спецификаций – конечно если есть уже завершенные один или несколько подобных проектов. Техническое задание, подготовленное на предыдущем проекте может быть использовано для другого проекта с целью сократить продолжительность сбора, анализа и разработки требований, что позволит быстрее начать разработку.
  • работа в “поле” – наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении
  • обучение – процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.
  • мозговой штурм – собирание множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно.
  • совещание – встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее
  • use-case – позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать.

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

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

Требования

Согласно определению Institute of Electrical and Electronics Engineers, Inc , ведущей мировой профессиональной ассоциации по развитию технологий, требование — это:
(а) условие или способность, необходимая пользователю, чтобы решить проблему или достигнуть цели;
(б) условие или способность, которыми должны обладать система либо компонент системы для удовлетворения контракта, стандарта, спецификации или другого формально установленного документа; (в) документированное представление условия или способности, показанной в определении «а» или «б»

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

Требования должны:

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

Требования не должны:

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

Например требование “Для пользовательского интерфейса будет использован Ajax для оптимизации работы сайта” не имеет отношение к требованиям, а скорее относится к дизайнерскому решению (то есть каким образом будет оптимизирована работа сайта).

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

Немного серъезности

Требования бывают разных типов и порой среди них можно запутаться. Я уже писал про это здесь. Но давайте их снова классифицируем.

Название требования Аббревиатура Краткое описание/назначение
Ответы и собранная ин
формация — Answers
ANSW Сохранить оригинальный ответ, проследить, как он учтен в требованиях, обосновать принятие решений и формулировку
требований
Запросы заинтере
сованных лиц —
Stakeholders’ Requests
STKR Сформулировать непротиворечивый
и полный перечень запросов заинтересованных лиц.
Трассировки на BR и BRULE являются проверочными
Бизнес-требования —
Business Requirements
BR Сформулировать непротиворечивый
и полный перечень бизнес-требований (высокоуровневые цели организации в качестве заказчика системы, которые определяют, почему организации нужна такая
система, то есть описывают бизнес-цели, которых организация намерена достичь с ее помощью)
Бизнес-правила —
Business Rules
BRULE Сформулировать непротиворечивый и полный перечень бизнес-правил (положения, определяющие или ограничивающие какие-либо стороны бизнеса с целью защитить структуру бизнеса, контролировать или влиять на его операции)
Глоссарий —
Therminology
TERM Термины и понятия системы
Ограничения и допущения — Assumptions ASSUM Выявленные системным аналитиком внешние ограничения на систему со стороны заинтересованных лиц, бизнес-требований и бизнес-правил
Технологические особенности — Technology
Characteristics
TECH Внутренние ограничения системы — результат анализа технологий, платформ разработки и инструментальных средств для
разработки продукта. Анализ проводится системным архитектором
Требования сертифи
цирующих органи
заций — Sertification
Requiurements
SERT Выявленные требования сертифицирующих организаций, которым должна отвечать система
Стандарты и ГОСТы —
State Standarts
STSTD Выявленные в ходе первичного и бизнес анализа требования ГОСТов, которым должна отвечать система.
В эту категорию не попадают архитектурные ГОСТы и RFC
Характеристики ана
логичных/наследуе
мых систем — System
Characteristics
CHAR Выявленные полезные свойства/характеристики систем, которые должна унаследовать система
Концепция создания
и развития продукта —
Business Vision
BVISION Выявленное видение развития/создания продукта с точки зрения бизнеса, ожиданий ЗЛ, требований к стандартизации и полезных/ценных для пользователей характеристик сторонних систем
Концепция системы —
Technical Vision
TVISION Техническая концепция реализации
выявленного бизнес-видения с учетом
выявленных ограничений с точки зрения бизнеса и ожиданий ЗЛ, современных технологий, платформ разработки и инструментальных средств разработки
Пользовательские
требования — User
Requirements
UREQ Требования к системе, сформулированные непосредственно ее будущими пользователями
Варианты использова
ния — Use Cases
UC Вариант использования системы
каким-либо актором: набор последовательных действий, приносящих актору — инициатору выполнения варианта использования — значимый и ощутимый результат
Функциональные тре
бования — Functional
Requirements
FR Тестируемые утверждения, отвечающие на вопрос «Что может делать система?» и описывающие функциональность системы в стиле «Система должна делать то-то и то-то…»
Нефункциональные
требования —
Non-functional
Requirements
NFR Тестируемые утверждения, часто содержащие количественные показатели, которым должна удовлетворять система после реализации ее требуемого поведения

А что после?

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

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

Приведу пример. Заказчик хочет какой-то новый функционал в ERP-системе (например Odoo) и запрос на оценку идет разным специалистам. Опытный бизнес-аналитик прочитав требование понимает, что для его реализации уже в системе есть все необходимое и просто нужно поставить модуль, неопытный бизнес-аналитик начинает придумывать как требование можно реализовать в системе, ставит задачу и дает ее на оценку разработчику и тот ее оценивает в 5 дней работы.

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

Уточнение требований может занимать прорву времени. Офис заказчика может стать вторым домом бизнес-аналитика и все равно по итогу может не получиться то, что нужно. Это тоже риск.

Чем больше оценка, тем меньше вероятность, что она точная.

Для уменьшения таких рисков и применяются итерационные подходы. Собрали требования, реализовали часть из них, показали заказчику, он одобрил – погнали дальше, не одобрил – уточняем что не так. Исправили – погнали дальше.

Предоставленная оценка – это обещание заказчику выполнить работу в указанный срок.

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

Например разработчики оценили проект в 500 дней разработки, а заказчик хочет все сделать за 90. Понятно, что все чего хочет заказчик за 90 дней ты не сделаешь и как-то не хочется работать бесплатно. Наступает время уменьшить scope (то есть объем работ) и откинуть ненужный на первом этапе функционал. И это должен сделать клиент.

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

Мифический человеко-месяц, или Как создаются программные системыКнига Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы» об управлении проектами в области разработки программного обеспечения (на основе опыта IBM OS/360) впервые была опубликована в 1975 году. В 1995 году было добавлено несколько новых глав, актуализирующих книгу.

Фредерик Брукс сделал вывод: «Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере, по двум причинам:

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

Если есть N специалистов, то количество пар специалистов (для взаимодействия между собой, в нашем случае «консультант – разработчик») равно N(N–1)/2, то есть с ростом числа участников проекта затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N рост числа участников проектной команды замедляет выполнение проекта».

Фактический пример из реальной оценки одной проектной задачи. Есть задача на 320 ч, один разработчик делает ее за 8 недель. Привлекаем второго разработчика, задача делается за 4 недели (линейный прирост). Далее привлекаем еще специалиста, результат уже не кратный, а те же 3–4 недели. А если добавить сюда еще кого-то (явно лишнего), то срок будет такой же (3-4 недели, если не будет мешать работать остальным своим желанием «помочь») или увеличится до 6–8 недель, т. к. время на коммуникацию всех со всеми начнет расти в ущерб самой задаче.

Если сроки сорваны, наем новых специалистов замедляет выполнение проекта по причине того, что новичкам требуется время на изучение текущего состояния задач, подходов к разработке. В книге сформулирован закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше».

В примере, что был рассмотрен выше, где 1 специалист делал задачу за 8 недель, предположим, что он уже потратил 4 недели, 4 остается, но очень хочется ускорить процесс за счет привлечения дополнительных сил. Добавим еще одного специалиста – в идеале можно было бы поделить оставшиеся 4 недели на два, но фактически экономия будет где-то 1 неделя, т. к. половину времени новый специалист будет «въезжать» в задачу, а тут еще и 50-процентная готовность, чужой код… А если привлечь двух специалистов в помощь? Тогда срок будет 9+ недель, то есть вырастет! Срок не изменится, если эти новые специалисты не будут мешать первому и он продолжит делать все сам, но если задачи поделить и «ускорять», то будут накладные расходы на интеграцию наработок и коммуникацию.

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

Можно привести любимую руководителями проектов цитату, когда нужно это все обосновать в одном предложении: «Даже если собрать вместе 9 беременных женщин, то ребенок через месяц не родится».

Подытожим

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

Требование заказчика описывают одну опцию с точки зрения клиента. Требования должны быть короткими и отвечать на вопрос “Что” и желательно “Зачем”, ни никак на вопрос “Как”. Требования должны легко поддаваться оценке. Если требования оценивается как большое – его нужно разбить на мелкие. Во время работы над проектом нужно держать требования под контролем и своевременно вносить в них изменения. И помните, что требования это по сути Scope проекта, а его нужно контролировать, так как он непосредственно влияет на срок его выполнения.