С ростом популярности Agile-архитектур за последнее десятилетие многие отрасли промышленности, включая производство программного обеспечения, внедрили Agile в свои предприятия. Поскольку компании стали отдавать предпочтение Agile-методу работы, было отмечено множество преимуществ, касающихся доходов, удовлетворенности сотрудников и клиентов, бесперебойного функционирования процессов разработки продуктов и повышения потенциала членов организации. Когда компании использовали традиционную методологию, многие из этих достоинств не были видны, а также возникало много проблем, касающихся сроков вывода продукта на рынок, удовлетворенности сотрудников работой и творческой атмосферы. Таким образом, переход многих компаний с традиционной на Agile-методологию не только устранил проблемы, вызванные обычным способом, но и улучшил организацию благодаря преимуществам, которые она предлагает.
В традиционной методологии программного обеспечения существует множество ролей, которые не похожи на действующие в секторе Agile. Многие роли, такие как менеджер продукта, на плечи которого ложилась вся ответственность за разработку продукта, перешли к разработчику, где ответственность и владение проектом распределяются между членами команды поровну. Многие члены компании часто задают вопросы о том, какую роль выполняет бизнес-аналитик в Scrum-команде и каковы возможные результаты от его найма. В таких случаях важно понять, в чем же конкретно заключается роль бизнес-аналитика в Scrum-команде, чтобы бизнес-аналитик, а также все сотрудники организации четко понимали свои обязанности в Agile-команде.
Роль бизнес- аналитика в SCRUM-команде
Что такое бизнес-аналитик?
Бизнес-аналитики — это умные, основательно ориентированные профессионалы, являющиеся высокоэффективными специалистами и обладающие должностными полномочиями для построения прочных взаимоотношений и глубокого понимания бизнеса таким образом, чтобы это приносило максимальную пользу организации. Бизнес-аналитики отвечают за проведение семинаров и совещаний, которые становятся для членов организации платформой по передаче своих идей и концепций, таких как подробные технологические процессы.
Бизнес-аналитик, также называемый БА, играет чрезвычайно важную и значимую роль в Scrum-команде, хотя во фреймворке Scrum официально она не определена. Они выступают в качестве связующего звена между владельцем продукта/заказчиком и технической ИТ-командой.
Основная роль БА заключается в том, чтобы составить оценочное мнение о технических процессах продукта и объяснить разработчику. Они не занимаются бизнес-процессами, как это делал бы владелец продукта, но при этом выполняют важную роль в этом. Роль бизнес-аналитика не определена и может сильно варьироваться. У БА имеются определенные обязанности, и он является неотъемлемой частью Scrum-команды.
Обязанности бизнес-аналитика
Бизнес-аналитик в Scrum-команде должен выполнять ряд обязанностей. Среди них можно выделить следующие:
- Обзор историй пользователей, созданных владельцем продукта, для убеждения в том, что они соответствуют критериям приемки. БА должен удостовериться, что все бизнес-правила учтены, а функциональность пользовательской истории удовлетворяет требованиям.
- Предвидение и анализ потребностей клиентов, чтобы найти решения для устранения их проблем.
- Организация бэклога продукта на основе приоритетов, предоставленных владельцем продукта.
- Создание пользовательских историй в соответствии с требованиями и обеспечение их соответствия критериям приемки. (Необходимо сделать, если это не было выполнено владельцем продукта).
- Предложение требований или их улучшение, во время работы с владельцем продукта и заинтересованными сторонами (стейкхолдерами), при этом полностью понимая их сферу применения.
Бизнес-аналитик играет важную роль в мозговых штурмах во время обсуждения предстоящего бэклога спринта. Иногда от бизнес-аналитика требуется одобрить реализацию инкремента продукта, поскольку он понимает все технические возможности, связанные с ним. Они также помогают разработчику разобраться в требованиях к продукту.
Роль аналитика в SCRUM
Бизнес-аналитик также тесно сотрудничает с аналитиком качества и анализирует тестовое покрытие, преобразует реальные варианты использования в тестовые примеры, предоставляет идеи и объяснения для текста сложной функциональности и т.д. В обязанности бизнес-аналитика также входит планирование встреч, чтобы помочь команде в оценках, давая им возможность получить четкое представление о зависимости, уровне сложности и потоке продукта. Бизнес-аналитик всегда изучает новые тенденции на рынке и продолжает внедрять инновации, оставаясь в курсе событий в той сфере бизнеса, для которой был создан продукт.
Каким должно быть место бизнес-аналитика в Scrum-команде?
Бизнес-аналитик не имеет конкретной постоянной роли в Agile-среде. Их обязанности динамичны и корректируются в зависимости от обстановки, в которой работают, и ситуации, с которой имеют дело. Вот несколько характеристик и моделей работы бизнес-аналитика в любой организации, которые описывают, как БА впишется в Scrum-команду.
Бизнес-аналитик как владелец продукта
В небольших компаниях, в зависимости от заказчика и предприятия, бизнес-аналитики часто выполняют роль владельца продукта. Они становятся посредником между командой и стейкхолдерами, являясь контактным лицом для всех вопросов, возникающих по поводу разрабатываемого продукта. БА должен понять требования стейкхолдеров и составить план развития бизнеса. Они создают пользовательские истории, документы, расставляют приоритеты и помогают команде изучить продукт. От БА требуется непосредственное присутствие в компании, так как при перемещении в другой часовой пояс может образоваться коммуникационный разрыв.
БА может выполнять функции владельца продукта, будучи легкодоступным и владея продуктом от имени стейкхолдеров/клиентов. Они должны принимать соответствующие решения, обучаться новым навыкам и развивать технические знания о разрабатываемом продукте. Если компания имеет более многочисленный штат и занимается сложными проектами, целесообразно нанять двух разных специалистов. Однако в рамках несложных проектов наличие владельца продукта является дополнительным преимуществом, поскольку бизнес-аналитик хорошо понимает продукт и может согласовать объем задач и определить порядок приоритетов пользовательских историй.
Бизнес-аналитик как член команды
Бизнес-аналитик — это специалист, обладающий превосходными знаниями о техническом процессе разработки продукта. Бизнес-аналитик, выступающий в качестве члена команды, поможет разработчику хорошо понять продукт и обсудить новые идеи для создания инкремента продукта. Техническая команда чувствует себя комфортнее, информируя о сложностях, с которыми они сталкиваются в процессе работы. Команде легче сотрудничать с человеком, который открыт для разъяснений и обсуждений технической стороны продукта. БА также может помочь команде в составлении бэклога продукта, когда владелец продукта недоступен.
Как члены команды, бизнес-аналитик Scrum может также тесно сотрудничать с QA-командой для проверки анализа и охвата, рассмотренных случаев использования, любых скрытых требований, а также зависимостей или эффектов. Бизнес-аналитик и разработчик могут подробнее остановиться на критериях приемки и объяснить, что от них ожидается. Если команде нужна дополнительная информация, они могут предоставить ее и помочь им получить определенность в отношении работы, которая ведется. Создание варфрейм-документов, потоковых документов и т.д. также может помочь команде понять требования к продукту для разработчика.
В сложных проектах, состоящих из нескольких модулей, распределенных между командами, наличие одного и того же бизнес-аналитика для множества коллективов является преимуществом. Когда один и тот же специалист по бизнес-анализу работает в разных командах, он способен продумать взаимодействие модулей, т.е. как новые фичи или обновления повлияют на другие модули. Следовательно, компании всегда должны учитывать такой аспект найма бизнес-аналитика, вместо обычного подхода к пользовательским историям или критериям приемки.
Почему бизнес-аналитик важен в Scrum-команде?
Бизнес-аналитик играет решающую роль в успехе любого Scrum-проекта. Его участие в проекте начинается с понимания потребностей заказчика и продолжается до демонстрации спринта. Бизнес-аналитик Scrum является основным контактным лицом разработчика, когда он сталкивается с какими-либо препятствиями в процессе создания проекта. Важность бизнес-аналитиков Scrum возрастает, особенно на начальных этапах нового проекта и при реализации крупномасштабных проектов.
Владелец продукта не всегда имеет техническое образование, поэтому роль бизнес-аналитика заключается в понимании требований к продукту и составлении описаний, критериев приемки и электронных схем, которые могут быть реализованы технической командой. В то время как владелец продукта может составить описания и документ в 2-3 строках простыми словами, а критерии приемки — в 1 строке, бизнес-аналитик должен копнуть глубже и заставить команду лучше понять пользовательские истории и технические условия. В некоторых других случаях владельцы продуктов могут писать длинные пользовательские истории, которые должны быть разбиты БА на части, чтобы расставить приоритеты в соответствии со спринтом.
Один из примеров, позволяющих понять важность бизнес-аналитиков, — когда в команде нет бизнес-аналитика, а владелец продукта создал историю пользователя, например, «Как клиент интернет-сайта электронной коммерции, я хотел бы выполнить все эти операции с моим счетом». А технические условия таковы:
- Клиент должен иметь возможность войти в систему.
- Клиент может просматривать различные категории электронного оборудования на разных страницах.
- Клиент должен иметь возможность оплатить счет, привязав свою кредитную и дебетовую карту.
Такая пользовательская история будет содержать различные этапы и не может быть выполнена за один раз. Следовательно, бизнес-аналитик Scrum должен разбить ее на части, поскольку в противном случае ситуация для разработчика ухудшится, так как не будут представлены надлежащие потоковые диаграммы и экраны пользовательского интерфейса. Результатом станет неудачный спринт и провальный проект. Следовательно, если владелец продукта не является квалифицированным бизнес-аналитиком, компании настоятельно рекомендуется нанять в свою команду такого специалиста.
Бизнес-аналитик Scrum — это высокоэффективный профессионал, разбирающийся в технической стороне процесса разработки продукта. Они помогают на различных должностях и несут большую ответственность по сравнению с другими членами Scrum-команды.
Бизнес-аналитик может выступать в качестве владельца продукта во многих компаниях в зависимости от размера и характера проекта и масштаба организации. Они являются отличными профессионалами, с которыми связывается разработчик для обсуждения сложностей, с которыми сталкивается команда в процессе проектирования. Они также становятся отличными членами Scrum-команды, поскольку обладают превосходными знаниями о технической стороне продуктов. Наличие одного и того же бизнес-аналитика одновременно для работы в нескольких командах также может стать дополнительным преимуществом, поскольку он может взаимодействовать с различными фичами и обновлениями и анализировать степень надежности продукта. Таким образом, бизнес-аналитик является неотъемлемой частью любой Scrum-команды и важнейшим участником успеха любого проекта.
Приглашаем всех желающих на открытое занятие «Фиксация требований с помощью Use Case», которое пройдет в рамках специализации «Системный аналитик». На этом уроке узнаем:
— как описать взаимодействие Актора и Системы;
— как отобразить все процессы и всех Акторов и не запутаться;
— кто в команде скажет спасибо за Use Case;
— как выбрать между Use Case и User Story.
Также приходите на завтрашний урок «Выбираем технологию для API». На занятии посмотрим, как можно работать с классическими REST и SOAP, попробуем заменить их на gRPC и GraphQL. А также разберем несколько кейсов и решим, в каком из них какую технологию лучше применить. Записаться можно на странице онлайн-курса «Системный аналитик. Advanced».
Источник: temofeev.ru
Нужен ли аналитик команде?
В идеальном IT-мире в каждой команде есть аналитик, а лучше несколько, под разные задачи: системный аналитик для формулировки задач разработчикам, бизнес-аналитик для совершенствования процессов, интеграционный аналитик для координации задач по интеграции программных продуктов и так далее до бесконечности. Найти хорошего аналитика — сложно, внедрить его в рабочие процессы — болезненно и не всегда удается с первого раза. Но основная проблема не в этом, а в том, что далеко не всем и не всегда аналитик вообще нужен.
В этой статье мы вместе с бизнес-аналитиком Катей Выстребовой разобрали типичные ситуации для диагностики ваших рабочих процессов и понимания, есть ли у вас реальная потребность в аналитике или это очередной карго-культ, которым часто грешат IT-компании.
Меньше карго-культа, больше осознанности
Если вы прямо сейчас ищете аналитика, поделимся с вами собственным опытом: не стоит ждать чудес от появления этого специалиста в вашей команде. Процесс разработки вряд ли ускорится (скорее даже наоборот), непосредственной прибыли от появления аналитической единицы тоже мгновенно не будет. Главные бонусы от аналитика для компании — прозрачность процессов и эффективная коммуникация с заказчиком — работают исключительно на долгосрочную перспективу, позволяя экономить ресурсы в будущем.
Перед тем, как начать размещать вакансии, проанализируйте: какие задачи вы хотите решить с помощью аналитика, в чем реальные проблемы вашей команды и решит ли их аналитик. Возможно, вам нужно заняться реструктуризацией компании или нанять хорошего менеджера проектов, а не аналитика.
Анализируем аналитиков
На самом деле без аналитической деятельности не обходится ни одна компания. Если у вас нет такой формальной должности, работу аналитика, скорее всего, просто выполняет другой специалист. Если выполняет хорошо и без угрозы для основной деятельности, то, возможно, не стоит рушить этот хрупкий самоорганизовавшийся баланс. Основными симптомами, свидетельствующими об острой нехватке аналитика в команде, являются проблемы со сбором и адаптацией требований и выраженные сложности с коммуникацией. Если у вашей компании присутствуют эти проблемы, значит, стоит бить тревогу и подыскивать человека, который профессионально выстроит адекватное общение между разработчиками, менеджерами и заказчиком.
Для того, чтобы вы смогли диагностировать дефицит аналитика, ниже приведены 4 типичные ситуации с разными вариантами их разрешения: силами команды или силами аналитика.
Аналитический траблшутинг
Давайте проведем небольшой траблшутинг и пройдемся по типичным проблемам, с которыми сталкиваются IT-компании без аналитика, а также рассмотрим, как их можно преодолеть. Спойлер: с аналитиком проще, но и самим вполне можно справиться. Для каждого типа аналитика мы предложили свое наименование, в зависимости от той функции, которую он решает.
Трабл 1: Потребность в адаптации требований
У вас есть довольно грамотный заказчик, который приносит достаточные и понятные требования. Ваши разработчики выполняют их в полном объеме. Получив результат, заказчик видит, что все работает так, как ему хотелось, но пользоваться продуктом неудобно, потому что требования не адаптированы под пользователя.
Кто вам нужен в идеальном мире: «аналитик-адаптер».
Как эту проблему можно решить без аналитика:
Если в вашей команде есть опытные разработчики или технически подкованный отдел продаж, они могут мотивировать заказчика глубже продумывать свои запросы и адаптировать их под качественный конечный результат. Также, возможно, в команде есть самоназначенный “адаптер”, который выполняет эти действия.
Как эту проблему решит аналитик:
Если у вас недостаточно активная или коммуникабельная команда разработки (что в принципе нормально), а продажники не готовы работать с продуктом, вам стоит внедрить аналитика, который поможет задать уточняющие вопросы типа: “Зачем это нужно?”, “Какую проблему бизнеса это решает?”. В такой ситуации «аналитик-адаптер» предложит варианты по изменению бизнес-процесса, продумает, как средства автоматизации упростят рутинные действия, а не продублируют их в системе.
Трабл 2. Потребность в коммуникации между командой и заказчиком
Разработчики любят термины и рабочий сленг (им, правда, так удобнее), заказчик не любит чувствовать себя глупым и хочет, чтобы исполнитель с полуслова ловил суть проблемы.
Кто вам нужен в идеальном мире: «аналитик-коммуникатор».
Как эту проблему можно решить без аналитика:
Здесь два варианта. Первый — научить разработчиков разговаривать с клиентом на одном языке и делать это так же результативно, как писать код (то есть, практически невыполнимая миссия). Второй — передать роль «коммуникатора» руководству, которое подковано в технической стороне и умеет излагать свои мысли доступным для заказчика языком. Второй вариант чаще всего и встречается в IT-компаниях.
Как эту проблему решит аналитик:
Если руководство не готово становиться «коммуникатором», а среди разработчиков нет уникума-экстраверта, то без аналитика не обойтись. Только он сможет добыть информацию и преподнести ее в понятном виде, переводя язык разработчиков заказчику и наоборот.
Трабл 3. Преодоление конфликтных ситуаций
Заказчик трепетно отстаивает, что та самая кнопка — нужнее некуда, без нее продажи падают и лояльность пользователя улетучивается. Разработчики упрямо настаивают, что это не целесообразно/не реализуемо. Разногласия достигают масштабов боевых действий и заканчиваются крахом и без того хрупкой коммуникации.
Кто вам нужен в идеальном мире: «аналитик-арбитр».
Как эту проблему можно решить без аналитика:
Если у вас небольшой стартап и вы готовы легко и гибко реагировать на “хотелки” заказчика, то конфликтные ситуации могут и не возникнуть. Еще один вариант: у вас есть специалист, умеющий нежно “продавить” заказчика и сделать так, как правильно, а не так, как хочется.
Как эту проблему решит аналитик:
В идеальном мире споров не должно быть вообще, в реальной жизни — каждый день война. «Аналитик-арбитр», владея опытом и умением внушать доверие, умея разговаривать с заказчиком на одном языке, решит такой конфликт быстро и безболезненно.
Трабл 4. Контроль работы команды
Даже если заказчик адекватный и команда супер-опытная, без предварительной аналитики при передаче в тестирование почти наверняка возникнет вопрос типа: “Почему окно кривое?” , и вы никогда не найдете виноватых. Потому что дизайнер окно не рисовал, у разработчика не было дизайна, а заказчик хотел, чтобы этого окна вообще не было.
Кто вам нужен в идеальном мире: «аналитик-конструктор».
Как эту проблему можно решить без аналитика:
Конечно, основную работу по контролю и конструированию процессов осуществляет менеджер проекта, но далеко не каждый менеджер может проанализировать бизнес-требования на старте и будет ими успешно управлять до самого финиша проекта.
Как эту проблему решит аналитик:
Аналитик изучает бизнес-процессы и декомпозирует бизнес-требования до уровня пользовательских и функциональных, управляет их оценкой и активно взаимодействует как с командой, так и с заказчиком, обеспечивая качественную коммуникацию.
Вместо вывода
Если вам кажется, что в этой статье мы активно склоняем вас к найму аналитика, то в этом есть доля истины. Виной тому наш собственный опыт, в Devim без аналитика непросто: сложная финтех-разработка без этого специалиста превращается в танцы с бубном.
Надеемся, вы “примерили” на себя 4 описанные ситуации и сделали правильный выбор: нужен вам аналитик или пока вы справляетесь собственными силами.
Источник: spark.ru
Менеджер проекта vs бизнес-аналитик: в чём разница между ролями
В цифровой разработке встречаются разные подходы к роли бизнес-аналитика (BA) и проектного менеджера (PM). Иногда эти роли совмещаются в одном человеке, где-то могут частично распределяться на всю команду, а ещё можно встретить разный набор зон ответственности и задач для этих ролей.
Руководитель отдела бизнес-аналитики Настя Романцова и руководитель отдела управления проектами Серёжа Шмаков рассказывают, как мы в red_mad_robot нашли свой путь, с какими проблемами столкнулись и что сделали, чтобы их решить.
Зоны ответственности бизнес-аналитика
Если говорить общими словами, то бизнес-аналитик связывает бизнес и команду разработки. Его основная обязанность — спроектировать цифровой продукт таким образом, чтобы задачи пользователя решались, цели бизнеса достигались, а интересы команды разработки и требования к удобству и простоте были учтены.
Важно отметить, что мы в red_mad_robot используем практику фулстек-аналитика, совмещая роль системного и бизнес-аналитика. Такой формат позволяет сократить время проектирования и количество коммуникации, а также позволяет одному человеку погружаться как в техническую, так и в бизнес-составляющую проекта.
Основные обязанности аналитика в red_mad_robot:
- Проведение вторичных исследований рынка.
- Анализ потребностей целевой аудитории.
- Интервьюирование бизнеса для понимания целей и задач.
- Проработка верхнеуровневой архитектуры продукта.
- Проектирование бизнес-процесса разрабатываемой функциональности.
- Проработка функциональных и нефункциональных требований к системе.
- Подготовка необходимых диаграмм для команды разработки.
- Передача материалов командам дизайна и разработки.
- Проектирование спецификаций API.
Зоны ответственности проектного менеджера
Проектный менеджер управляет процессами проектирования и разработки, устраняет узкие места и неэффективности. Он же транслирует в команду ограничения со стороны бюджета и сроков и следит за тем, чтобы принимаемые решения учитывали эти ограничения. А ещё обеспечивает клиенту прозрачность хода проекта и результатов и свободное движение информации между всеми участниками.
- Выбор подходящего фреймворка и адаптация производственного процесса под проект или команду.
- Выявление основных метрик проекта и управление ими.
- Повышение эффективности обмена информацией между участниками проекта, контроль за её систематизацией и тщательным сохранением.
- Формулировка цели вместе с командой и бизнесом, фокусировка команды на целях.
- Управление ожиданиями.
- Управление проектными рисками.
- Доведение всех задач проекта до результата.
- Критический взгляд на всё и регулярная рефлексия.