Налаживаем коммуникацию между бизнесом и UX: набор артефактов в помощь аналитику / Блог компании red_mad_robot / Хабр

Налаживаем коммуникацию между бизнесом и UX: набор артефактов в помощь аналитику / Блог компании red_mad_robot / Хабр Аналитика

Основная часть

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

Делюсь результатами своих поисков.

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

Почему именно такое разделение

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

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

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

При этом есть и ограничения. У БА — это рамки доменной или изученной отрасли (например: глубокое знание правил банковской деятельности), у СА — технологий и системы (например: выдающийся опыт работы с продуктами oracle). Эти ограничения могут быть препятствием при переходе между командами, проектами и компаниями, но быстро устраняются при желании и помощи коллег.

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

Это не нарушает правила, а говорит о совмещении ролей, уровне зрелости и ценности конкретного специалиста. В случае опытного работника — это вполне нормально, но странным выглядит вакансия «junior BA» со знанием SQL, JS и API на всем известном сайте.

Описание сущностей

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

Список Entities

Vision/виденье проекта

Это первый артефакт, который возникает в проекте. Представляет собой текстовый документ, который кратко описывает основную идею проекта. Он на верхнем уровне определяет продукт, который требуется разработать с учётом потребностей заинтересованных сторон.

Проще говоря, в Vision формулируется:

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

В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.

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

Пример Vision

Абстрактный пример:

Иван — БА компании «Исполнитель».


Ева — системный аналитик компании  «Исполнитель».

Компании «Заказчик» нужна крупная доработка имеющейся системы. 

В этой ситуации задачи Ивана (БА): выявить функциональные и нефункциональные требования Заказчика и Исполнителя, устранить противоречия между заинтересованными лицами для  определения  приемлемого решения, создать прототипы, взаимодействовать с заказчиком процессе разработки, осуществить демо-показ и приемку работы. Делать все это сообща с Евой.

Задачи Евы (СА): спроектировать доработку оптимальным образом, описать ее влияние на систему, ограничения и возможные улучшения, создать спецификацию, декомпозировать и передать в разработку задачи, проконтролировать их своевременное выполнение в соответствии с требованиями. Делать все это сообща с Иваном.

Аналитик в agile

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

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

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

В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:

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

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

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

Блок-схемы

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

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

Ещё с помощью блок-схемы можно показать карту экранов или любую другую диаграмму — например, Use Cases. По сути блок-схема — это диаграмма с уникальной легендой. Она помогает визуально представить систему с определённой точки зрения.

Блок-схема алгоритма платежей

Вайрфреймы

Вайрфрейм — это изображение экрана с минимальным количеством деталей. Он показывает:

Мы обычно используем вайрфреймы в двух случаях:

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

Диаграмма бизнес-процессов

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

Налаживаем коммуникацию между бизнесом и UX: набор артефактов в помощь аналитику / Блог компании red_mad_robot / ХабрДиаграмма процесса

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

Диаграмма развертывания

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

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

Диаграммы компонентов

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

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

Таким образом, диаграмма компонентов помогает:

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

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

Дизайн

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

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

Допущения

В этой статье говорится больше про ИТ-сферу.

Рассматривается «дистиллированное» значение должностей. В реальной жизни, особенно в командах, где развивают T-shaped skills (модель развития у сотрудника компетенций из смежных профессий), всё сложнее и запутаннее, но, если ваш аналитик не многоликий Янус, то переход между разными обязанностями представляет непростую задачу.

Интеллект-карта

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

Налаживаем коммуникацию между бизнесом и UX: набор артефактов в помощь аналитику / Блог компании red_mad_robot / ХабрИнтеллект-карта будущего набора функций, которые UX-проектировщик хочет включить в дизайн

Карта экранов

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

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

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

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

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

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

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

Мифы и легенды системного анализа или чем занимается аналитик в банке

Привет! Меня зовут Настя, я аналитик мобильного приложения Альфа-Бизнес. Иногда меня спрашивают о том, чем я занимаюсь на работе. Друзья, родные и, как это ни странно, разработчики. Каждый раз я отвечают по-разному, пытаясь привести наиболее близкие собеседнику примеры.

«Системный аналитик переводит требования пользователей с человеческого языка на разработческий…» — звучит довольно понятно для человека, не связанного с ИТ. Но если ты непосредственно участвуешь в разработке, вряд ли такого определения будет достаточно. Ради небольшого эксперимента я задала своей команде вопрос: «Чем занимается системный аналитик?». Читаем под катом, что из этого получилось.

Для меня системный аналитик — это человек, который может дать ответ на любой вопрос: от «Как должна работать фича», до «Почему Земля круглая» (с) тестировщик


Насчёт Земли, может, и перебор, но в остальном довольно точно. Где хранить данные, как их передавать, как работает фича, почему фича не работает… Каждый раз, когда в бэклоге продукта обнаруживается что-то непонятное, следует фраза «нужна аналитика».

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

Уверенное использование систем логирования может сократить чтиво с 30-страничного ТЗ до нескольких запросов. Главное — знать, что искать. В логах содержится информация о вызываемых методах, входных и выходных параметрах, причинах ошибок. Если сервис композитный — о пошаговом выполнении операции. Аналитику нужно разбираться в структуре логов и уметь их фильтровать: логируется обычно огромный объем данных.

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

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

Дополнительный анализ:  Технический писатель или аналитик? — Хабр Q&A

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

Аналитик как навигатор, прокладывает путь до цели, огибая препятствия, и постоянно ищет более короткие пути (с) фронтенд-разработчик

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

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

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

Ну не знаю, ты для меня просто тестировщик. Ну, или смесь продакта с тестировщиком, как-то так (с) бэкенд-разработчик

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

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

Собирает информацию о продуктах, проектах и системах банка, занимается ее актуализацией и распространением, находится на острие информационного ножа (с) скрам-мастер

С документации все начинается, ей же и заканчивается. Она готовится для внутреннего использования и, где это применимо, для Заказчика. Документы создаются в соответствии с ГОСТ-ом или по внутренним стандартам. Способы документирования также могут отличаться по слоям систем.

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

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

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

Насколько карта универсальна, мне судить сложно. Поэтому жду комментариев от разработчиков и аналитиков из других организаций 🙂

Налаживаем коммуникацию между бизнесом и UX: набор артефактов в помощь аналитику / Блог компании red_mad_robot / Хабр

Подытожим

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

Пользовательские инструкции

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

Примеры данных и логическая модель данных

Важным для дизайнеров является не только соблюдение бизнес логики, но и понимание с какими данным придется иметь дело. Будет ли удобно просматривать список из 3 наименований. Думаю, что да. А если этих наименований будет 1000, подойдет ли все тот же простой список? Для передачи данных у нас принято использовать следующие артефакты:

  • Логическую модель данных
  • Примеры данных

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

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

NB! Важно помнить один момент. Аналитик должен вовремя выявлять и сигнализировать о будущих изменениях в требованиях PM-у проекта. Передать знания в виде диаграмм бизнес-процессов и логической модели с примерами данных недостаточно. Важно понимать, что полученная информация адекватно воспринимается участниками команды.

Проблема

У некоторых моих знакомых, коллег, руководителей, эйчаров, представителей «бизнеса» в головах образовалась путаница между видами аналитиков. Понятие «аналитик» используется для совсем не похожих друг на друга профессий — бизнес-аналитик (БА), системный аналитик (СА), дата аналитик, UX-аналитик, аналитик информационной безопасности, аналитик бизнес-процессов и ещё 5–10 других, все эти виды имеют массу различий. Сейчас про конкретные два, наиболее спутанные между собой, но сильно различающиеся в отечественных IT-реалиях.

Кому будет полезна эта статья:

Дополнительный анализ:  1С-Битрикс - Веб-Аналитика


В общем, «Счастье для всех, даром»

Прототипы

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

Таким образом, он помогает:

  • оценить содержание и интерфейс;
  • протестировать основные способы взаимодействия, как если бы это был готовый продукт.

Прототипы модуля “Мониторинг продавца” на проекте iFarm

Сквозная, маркетинговая, продуктовая и мобильная аналитика | медиа нетологии: образовательная платформа

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

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

Другой вопрос, может ли компания охватить сразу весь объём инструментов аналитики. Например, настройка сквозной аналитики в самой простой вариации занимает 1–3 месяца. Но потом ее всё равно нужно поддерживать и корректировать на постоянной основе.

Выбор вида аналитики зависит от продукта.

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

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

Если помимо продукта на сайте компания выпускает дополнительно мобильное приложение, то к системе из продуктовой и маркетинговой аналитики добавляется и мобильная аналитика.

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

Установочная встреча между дизайнерами, аналитиками, pm-ами

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

  • Функции особенные, со сложной бизнес-логикой. У заказчика есть представление как это должно работать и эти знания нужно получить. Аналитик в первую очередь начинает работу по задачам такого типа. Неопределенности нужно снять в первую очередь, если этого не сделать, то о дальнейших работах и речи быть не может.
  • Функции, которые должны быть удобны для пользователя. Заказчик имеет свое представление, но ожидает от нас экспертизу как сделать лучше. Такие задачи отдаются UX- проектировщику, который готовит концепции TO BE.
  • Функции, которые повторяются из приложения к приложению. Как правило они уже описаны в виде требований, есть представление какой будет дизайн, готов код для реиспользования. Такие вещи откладываются на последние этапы проекта и могут выполняться дизайнером и аналитиком практически параллельно с периодической синхронизацией.

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

Финальный набор экранов и валидация

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

Вместо вывода

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

Сложившаяся ситуация требует от ИТ аналитиков (1) глубокого познания предметной области бизнеса, особенностей внутренних процессов, внешней среды и трендов, (2) не менее глубоких знаний технологий, часто практического их использования.

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

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

Коллегам, нашедшим себя или планирующим работать БА или СА, советую провести такую же процедуру и честно понять для себя, хотите ли вы (1) искать зерно истины в часто не поддающемся алгоритмам и логике, постоянно изменяющемся бизнесе или (2) исследовать и проектировать сложные, запутанные, но интересные системы.

Заключение

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

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

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

Аналитик в Agile — золотая середина между крайностями:

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

Appendix

Ну что, Главред, теперь понятнее? =)

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector