Зачем вообще нужны бизнес аналитики

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



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

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



Аналитик в Agile

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

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

Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.

В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:
  • ­Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
  • ­Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
  • ­Использовать больше визуальных образов, схем, графических нотаций.


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

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


Возможные функции аналитика в Agile

Связующее звено между разработчиками и заказчиками

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

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


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

Контроль качества

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

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

Достаточно очевидно, что вместо (или совместно с) владельцем продукта эта почетная обязанность может быть возложена на аналитика

Схемы взаимодействия аналитик – команда

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

Владелец продукта — аналитик

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

Т. ч. можно решить: функции аналитика исполняет владелец продукта. Или, если угодно, наоборот — аналитик исполняет роль владельца продукта.

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

Недостатки:
  • ­Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
  • Экстремальная незаменимость — а если в отпуске, а если заболел.
  • Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
  • Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.


Аналитик — помощник владельца продукта

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

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


Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:
  • Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
  • Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
  • Работа аналитика учитывается при планировании итерации.
  • Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.


Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:
  • Одной предметной областью (или сильно похожими) занимается несколько команд разработчиков, т. ч. держать по аналитику в каждой команде нет смысла.
  • В проекте так много технических и технологических тонкостей и сложностей, что команда в основном сконцентрирована на них, а аналитик в такой команде оказывается инородным телом.
  • Нехватка квалифицированных аналитиков.


Заключение

Так есть разница между аналитиком в Agile и не-Agile (например, в водопаде или другой тяжеловесной методологии)? Однозначный ответ — есть!

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

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

Аналитик в Agile — золотая середина между крайностями:
Одна крайность
Золотая середина
Другая крайность
 
Команду не допускают к аналитической работе.
Agile
Разработчикам самим приходится полностью прояснять, что же нужно.
Аналитик мало общается с заказчиком.
Agile
Аналитик всё время проводит у заказчика.
Подробные спецификации перед началом итерации.
Agile
Отсутствие какой-либо проработки требований до постановки их в итерацию.
Команда «с придыханием» относится к установкам аналитика.
Agile
Команда не доверяет результатам работы аналитика (не использует их).
Аналитик не участвует в тестировании (QA).
Agile
Аналитик вынужден постоянно «протыкать» много старых интерфейсов.
Команда воспринимает аналитика как руководителя.
Agile
Аналитик для команды — мальчик/девочка «на побегушках».
Аналитик взаимодействует с командой исключительно при помощи документации и баг-трекера.
Agile
Аналитик взаимодействует с командой исключительно посредством устных коммуникаций.
С заказчиком и пользователями общается только аналитик.
Agile
Все члены команды вынуждены плотно общаться с заказчиками и пользователями.

 

Автор: Ольга Азимбаева, Senior Business Analyst.

Комментарии (9)


  1. ihs
    12.06.2015 23:09

    Попытки найти место Аналитику в мире Agile, с аргументацией непонимания в принципе сути Agile. :)


    1. mcros
      18.06.2015 17:55

      У меня сложилось такое же мнение. К сожалению. Я как и автор работаю аналитиком в компании, где разработка идёт на основе Эджайл подходов, и могу сказать, что описанное практически не имеет связи с реальностью, во всяком случае нашей )) К примеру, ответственный за контроль качества — QA Engineer (inho это догма), ответственный за взаимодействие с командой — PM или Team Lead, ответственный за продукт — Product Owner. У BA свои обязанности, но в статье они раскрыты слабо. И слишком мало особенностей работы аналитика в Эджайл.


      1. ihs
        18.06.2015 18:44

        Например, если взять тот же Scrum, то в целом обязанности аналитика размазаны между PO и командой разработки. Теоретически-то человек с компетенциями Аналитика вполне может вписаться в команду разработки в случае, если команда разработки не справляется самостоятельно.
        А который из Agile-подходов у вас используется?


        1. mcros
          18.06.2015 18:56

          Lean, Scrum, свои наработки. Ничего не размазывается. Аналитик в команде.


          1. ihs
            18.06.2015 19:17

            У вас дикий какой-то замес получается. :)
            Просто исходя из поверхностной оценки складывается впечатление, что была когда-то классическая иерархическая система, на которую решили натянуть «модни-молодёжни» Agile, без понимания того, что при этом должны быть произведены в том числе и структурные изменения (не говоря о способе мышления в целом), а не некоторые событийные в виде Дейли скрамов и Спринтов, чтобы новые процессы привнесли свою пользу)
            Меня просто смущает, например, наличие одновременно и PO и PM — какие у PM обязанности? Lean повлиять на такую ситуацию не мог, а в Scrum подобного нет.


  1. Askofen
    22.06.2015 10:48

    В своё время в ТВ-рекламе стиральный порошок «Тайд» сравнивали с «Обычным стиральным порошком». Что это за «зверь» такой — было непонятно, кроме одного — «Обычный стиральный порошок» обладает всеми мыслимыми и немыслимыми недостатками.

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

    Если говорить о конкретных неточностях в статье, то вот это утверждение:

    «В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса»

    — является полностью недостоверным и непонятно, на основе каких данных автор делает такой вывод.

    Следующее за ним утверждение:

    «Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене»

    — тоже не является истиной.

    А вот это утверждение:

    «Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана»

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

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


    1. ihs
      28.06.2015 13:21

      Сам по себе Agile — это набор ценностей и принципов, а не подход к разработке. Ну и не говоря о том, что, не смотря на форму и качество, существует не только в аутсорсе. :)
      И водопад и гибкие подходы в разработке хороши каждый в своём случае и когда неверно делают выбор процесса — вот тогда и начинается неразбериха и недовольство выбранным подходом.
      У автора и с Agile тоже не всё будь здоров, так что статья и вышла половинчатой какой-то, с точки зрения знаний и правды :)
      Я так понимаю вы очень много работали по водопаду, а по какому-нибудь из Agile подходов вы работали?


      1. Askofen
        29.06.2015 00:52

        Поясню свою ремарку про аутсорс. Исходя из моего 19-летнего опыта работы, аутсорсер не обладает методологиями управления проектами. В аутсорсинговых компаниях проекты либо ведутся как попало, либо на проекте устанавливаются процессы заказчика. Если заказчик — продуктовая компания с богатым опытом разработки и выпуска ИТ-продуктов, то процессы на проекте поставлены хорошо. Если заказчик иной, то процессы не выстроены, и разработка ведётся как попало. Все же разговоры про «гибкие методологии» в данном случае ведутся с целью оправдания такого проектного бардака и нежеланием ставить процессы разработки.

        Если Вы понимаете под «водопадом» последовательность Концепция -> Дизайн -> Технический дизайн -> Реализация -> Тестирование и исправление ошибок, то мой ответ — «да». Хотя мой заказчик считает, что применяет «гибкие методологии». Что касается меня, то я считаю такую последовательность этапов обычным инженерным подходом.


        1. ViseMoD
          03.07.2015 18:01

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