Зачем вообще нужны бизнес аналитики
Большинство людей считают, что для разработки какой-то программы нужны только программисты, ведь именно они пишут код и воплощают мечту заказчика в реальность. Но между тем, что говорит заказчик и тем, что в итоге сделает программист, — целая пропасть. Не потому что они — плохие люди или не хотят общаться и понимать друг друга, а потому что заказчик мыслит в масштабе цели, думает, что должна делать программа, для чего он хочет ее использовать. А программист обязан думать, как программа должна работать, откуда брать данные, как назвать новую колонку в таблице данных и т. д., проще говоря, думать о деталях реализации.
Поскольку и программисты, и заказчики — люди занятые, выяснение деталей проходит в форме раундов «вопрос — ответ», при этом нигде не фиксируется, когда и почему было принято такое решение или как оно изменялось со временем. Но главный минус такой коммуникации — разработчик спрашивает «как?», а заказчик может ответить только на «зачем?», а остальное его уже мало интересует. Более того, обычно, отвечая на «как?», заказчик заводит себя в тупик, потому что не может и не обязан знать, сколько вариантов существует для выполнения его потребности и какой оптимален. Программист же всего лишь делает, что ему сказали. В итоге складывается ситуация, когда недоуменный клиент спрашивает, почему приложение не вписывается в его картину мира, а недоуменный программист отвечает, что так и просили сделать.
Даже из названия профессии аналитика видно, что в его обязанности входит не только сбор требований, но и их анализ, а именно — выбор оптимального пути выполнения поставленной цели. Т. е. аналитик должен знать, и зачем клиенту та или иная функциональность, и как она сделана у конкурентов, чтобы проанализировать возможные пути реализации, выбрать оптимальный и описать программистам в деталях.
Аналитик в 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.