В апреле наши коллеги побывали на международной конференции по системному и бизнес-анализу Analyst Days 2017, проходившей в Москве. Под катом — впечатления от самых интересных, на наш взгляд, докладов этой конференции.Доклады были сгруппированы по тематическим блокам. Начнём с краткого обзора докладов секции Качество требований, которая, как можно было судить по переполненным залам, вызвала большой интерес со стороны участников конференции, так как докладчики затрагивали одни из наиболее важных аспектов работы бизнес-аналитиков.
Тематический блок «Качество требований»
Елена Горопека, «Тестирование требований. Находим проблемы до их появления»
В кратком докладе Елена Горопека рассказала о том, кем и каким образом может проводиться тестирование требований.
Все знают, что чем раньше была выявлена ошибка при проектировании ПО, тем дешевле она обходится. Докладчик советует сделать тестирование требований обязательным шагом процесса работы над проектом. Его могут проводить следующие члены команды:
- Старший аналитик или руководитель, пожалуй, лучший кандидат на эту роль, так как он хорошо знает ваши слабые и сильные стороны, имеет большой опыт, и заинтересован в росте профессионализма сотрудников. Он также является тем человеком, который может способствовать установлению процесса тестирования требований на постоянной основе.
- Тестировщики проекта, так как они умеют копаться в мелочах, знают, на что обращать внимание, заинтересованы иметь хорошую документацию, по которой будут тестировать готовый продукт. Если тестировщик приступит к разработке тест-кейсов по написанной спецификации без доступа к тестовому окружению, в процессе он наверняка найдёт моменты, требующие доработки и детализации. То есть по сути он не делает двойную работу, но при этом изменения в процессе разработки принесут ощутимый результат.
- Бизнес-аналитик из соседнего отдела/проекта. Загрузка бизнес-аналитиков изменяется нелинейно, и стоит привлекать для тестирования требований коллег. Кроме прочего это также способствует распространению лучших практик разработки документации.
Типы проверки тоже могут отличаться в зависимости от ситуации.
- Экспресс-проверка может проводиться для выявления только явных ошибок. Или это может быть тщательная проверка, но лишь части требований, и по замечаниям автор может провести полный анализ самостоятельно.
- Базовая проверка проверяет требования только на соответствие стандартам их написания, принятых в компании (не проверяя полноту покрытия требований бизнеса и пользователей).
- Расширенная проверка применяется, когда Заказчик серьезно недоволен качеством требований. При этом типе проверяться будет всё. Это основательная работа, требующая погружения в проект и участия в сессиях с заказчиком. Эта услуга может быть заказана у профессионалов.
Внедрением в рабочий процесс тестирования требований мы повышаем качество итогового продукта, можем вовлекать в проект тестировщиков на более ранних этапах, развиваем сотрудничество аналитиков и даем возможность руководителю увидеть, что наша спецификация прекрасна :)
В NIX Solutions мы активно применяем тестирование требований в следующих ситуациях:
- проверка качества документации, пришедшей от клиента — детальная вычитка требований позволяет вовремя выявить проблемные места и дать более реалистичную оценку трудозатрат.
- ревью требований к проекту другим аналитиком перед стартом проекта — это обязательный этап, если документация разрабатывается на нашей стороне. Тестировщик и разработчики, участвующие в оценке трудозатрат, также вычитывают требования и дают обратную связь
- регулярные проверки качества требований руководителем аналитика — в основном мы используем подход тщательной проверки части требований, только для новичков может проводиться полная детальная вычитка.
Доклад подсказал и новые способы применить тестирование требований для улучшения качества требований, которые мы непременно опробуем на практике :)
Таисия Толстунова, «As large as life. Полнота требований и способы ее проверки»
Таисия Толстунова начала свой доклад с того, что мы имеем в виду под полнотой требований, и как её определить. Мы можем рассматривать это понятие с точки зрения классиков, таких как Вигерс, Коберн, использовать определения Babok и SWEBOK, и другие источники. Неполнота требований может привести к таким последствиям:
- Реализовано не то, что было нужно
- совсем не то, что просили;
- забыли что-то важное;
- «всё хорошо, но».
- Потеря времени всей команды
- Снижение профессиональной самооценки
Далее докладчик анализировала причины, которые к этому привели. Были названы следующие:
- Отсутствие выделенного времени в проекте на анализ
- Отсутствие возможности дополнительного согласования требований
- Занятость на других проектах
Чтобы избежать неприятных последствий Таисия предложила использовать следующие техники:
- Следить за перепиской на этапе сбора требований, внимательно всё собирать, уточнять с заказчиком и документировать
Пример:
«Мария, нам важно, чтобы доступ к системе имели сразу все сотрудники компании»
«Кроме нас этой системой никто не будет пользоваться, хотя...» - Проводить тестирование требований
- Перекрестное, внутри отдела
- “Tres amigos” — техника, которая позволяет весь набор требований проверить одновременно аналитику, тестировщику и разработчику. Обсуждение требований проводится после предварительного изучения командой из 3-5 человек, представляющих эти роли в проекте
- Использовать технику мозгового штурма для нахождения недоописанных частей процесса
- Разработать и использовать чек-листы:
- по стандартам написания требований
- по тому функционалу, который важен заказчику
- по процессу согласования требований
- на Ваш выбор!…
- Разрабатывать диаграммы, отображающие весь бизнес-процесс или отдельные его части. Проходя по диаграмме шаг за шагом весь бизнес-процесс, можно легче отследить его описание в требованиях.
Доклады блока перекликались и дополняли друг друга, формируя более полную картину того, как наладить в компании процесс тестирования требований в частности и поддержание качества разработки в целом.
Тематический блок «Повышение эффективности, специализированные навыки»
В этой секции участников конференции ожидали не менее интересные и познавательные доклады.
Ольга Самарина, «Дизайн-мышление. Что это и могут ли аналитики его применять?»
В рамках своего доклада Ольга Самарина познакомила аудиторию с методологией Дизайн — мышление. Вот как определяют ее в сети: это подход к решению инженерных, деловых и прочих задач, основывающаяся на творческом, а не аналитическом подходе. Главной особенностью дизайн-мышления, в отличие от аналитического мышления, является не критический анализ, а творческий процесс, в котором порой самые неожиданные идеи ведут к лучшему решению проблемы.
Вместе с Ольгой мы пошагово рассмотрели весь путь от постановки задачи до создания её решения. По словам докладчика, важно с самого начала выявить реальную проблему людей, и в поисках решения не следовать стереотипам. Пользователь не всегда может сказать, что нужно сделать иначе. Если бы создатели всегда следовали запросам клиентов, автомобиль могли бы никогда не изобрести, потому что люди просили о другом…
Наше видение того, как пользователи будут использовать предоставленные им средства, может отличаться от реальности. Поэтому при сборе информации о проблеме стоит понаблюдать за их работой, смотреть, что они НЕ делают и слушать, что они НЕ говорят. Если речь идет об усовершенствовании рабочего продукта, то нам очень важно мнение пользователей, которые НЕ любят наш продукт и редко им пользуются, или тех, которые перестали им пользоваться. Именно эти люди зачастую бывают источником новой и неожиданной информации.
Докладчик советует после сбора сведений о существующем решении сфокусироваться на конкретных проблемах, чтобы понять, что именно не устраивает пользователей, чего в системе не хватает для того, чтобы привлечь больше людей. Затем провести брейн-шторминг, по результатам которого выбрать конкретную идею — одно решение, которое мы посчитаем оптимальным. На следующем этапе проводится прототипирование и тестирование гипотез. И уже затем их проверка и тестовый запуск.
В конце докладчик перечислила преимущества методологии, ситуации, когда её стоит использовать, и когда метод неэффективен. Ольга привела пару интересных примеров. В первой ситуации команда Сбербанка искала решение для проблемы очередей к операционистам.
По словам докладчика, в ходе анализа сотрудники Сбербанка выяснили, что пользователю не нужен операционист, клиент морально готов изучить интерфейс банкомата, обращаясь за помощью к консультанту в зале, проводить операции самостоятельно.
Таким образом, для решения проблемы очередей не пришлось увеличивать штат сотрудников банка и расширять площадь отделения. И, похоже, это помогает, потому что сейчас отделение Сбербанка выглядит так:
Второй пример касался конфиденциальности при снятии денег в банкомате. Ольга рассказала, что в поисках лучшего решения Сбербанк пробовал разные варианты, проверяя их на пользователях. Это были непрозрачные перегородки между двумя рядом стоящими банкоматами, кабинка у каждого банкомата с закрывающейся дверью, видеокамеры, направленные на очередь. В результате было выбрано недорогое и простое в реализации решение — разделители между банкоматами и желтая ограничительная линия на полу.
Таким образом можно говорить об окупаемости проводимого анализа, ведь можно опробовать варианты на тестовой группе пользователей и затем уже проводить масштабные, требующие затрат, изменения.
Сбор требований и описание видения решения (сокращенная версия)
Ещё в этом блоке был очень интересный мастер-класс. После теоретической части мы разбились на команды, чтобы придумать продукт и описать его целевую аудиторию (с созданием персонажа).
Нам нужно было выделить основные потребности наших клиентов – NEEDS. Это краткое описание текущего состояния. В качестве примера можно привести потребности в коммуникации, формировании финансовой отчетности, продаже билетов и т.д. Затем — приятные дополнения — WANTS, это то, что не решает основную проблему пользователя, но может быть удобным, полезным, радовать его. После того, как мы определились с первыми двумя пунктами, мы можем определить, что именно мы будем реализовывать – JOBS TO DO. И сразу нужно было разбить их на три группы: функциональные, эмоциональные и социальные. Мы учитывали также, что нужно будет сделать кроме основного функционала – нужно ли готовить документацию, проводить сертификацию, обучение персонала и т.д. И для каждой конкретной задачи нужно было прописать критерии приемки, критерии качества, ожидаемый результат, риски, связанные с ее реализацией.
Это было интересное творческое задание, в ходе которого небольшая группа незнакомых друг с другом аналитиков смогла договориться и найти ответы на все эти вопросы.
Тематический блок «Коммуникации»
Сергеq Крупенин «PM vs BA vs World. Как ведут себя люди, которым вы ставите задачи + Управленческие поединки. Суровая практика». В блоке Коммуникации очень запомнилась лекция Сергея Крупенина. Кстати, именно он был выбран лучшим докладчиком в результате голосования.
Как видно из названия, доклад был об управлении людьми. Причем мы брали во внимание только персонифицированное управление, когда руководитель напрямую общается с подчиненными. Можно выделить 4 основные функции руководителя.
Подчиненные могут по-разному реагировать на каждом из этих этапов, и мы рассматривали 7 видов реакций людей.
Определить, какую реакцию проявляет человек на требования руководителя, поможет эта таблица. Рассмотрим пример с определением порядка. Руководитель принял решение о том, что команда будет работать по SCRUM с 2-х недельными итерациями. А один из подчинённых начинает рассказывать о том, что KANBAN лучше, и стоило выбрать его. Можно определить реакцию сотрудника как «перехватывающий управление».
Руководителю стоит внимательно наблюдать за реакциями подчиненного в разных ситуациях. Наиболее частая реакция — это и есть его характер. В зависимости от этого стоит скорректировать своё поведение с ним, чтобы стремиться привести его к лояльным реакциям.
В этой же секции особого внимания также заслуживает доклад Алексея Колоколова:
Как дашборды помогают бизнесу и аналитикам понимать друг друга
Алексей Колоколов из Института бизнес-аналитики (Москва) рассказал о тонкостях использования информационных панелей (дашбордов) в рамках своего доклада.
По мнению докладчика при создании информационной панели в первую очередь необходимо определить его целевую аудиторию (заказчика). От этого зависит, каким будет оформление и стиль дашборда. Далее в зависимости от поставленных целей аналитик работает над его содержанием.
Необходимо заметить, что в независимости от того, какая будет аудитория и какие задачи ставит перед собой автор, существует ряд правил, которым необходимо следовать при создании дашбордов. Правила эти оказались во многом схожи с правилами составления презентаций. Далее автор доклада предлагает готовый чек-лист из 9 пунктов, который аналитики могут взять за основу, при создании собственного дашборда.
Из приведённого списка, изображенного на картинке выше, хотелось бы подробнее остановиться на втором пункте. Визуальное восприятие играет большую роль во время ознакомления с информационной панелью. С помощью визуализации можно добиться ожидаемого эффекта, но в тоже время при неудачном выборе цвета, расположения, яркости или положения в пространстве, автор дашборда может столкнуться с тем, что информация будет воспринята неправильно. К примеру, взгляните на картинку ниже и попробуйте быстро дать ответ на вопрос «Кто работал лучше?».
У большинства людей мгновенно создаётся впечатление, что Петров показал лучшие результаты. И только более пристальный взгляд даст понять, что причиной неправильной трактовки слайда является шкала выручки, которая по-разному изображена для двух работников, что в конечном итоге и приводит к визуальному обману. Подобно тому, как визуальность имеет большое значение в построении дашборда, остальные 8 пунктов данного списка также заслуживают особого внимания при создании панелей.
Далее докладчик говорит, что одна из основных причин неудачных, а зачастую банально провальных информационных панелей — это разное восприятие аналитика и заказчика. Аналитик погружается в детали, в то время как заказчику важна общая картина. Нет смысла выдавать тонну информации, нужно всего лишь предоставить выжимку из неё в интуитивно-понятном формате.
Напоследок Алексей даёт важный совет: научитесь переключать в себе роли — попробуйте побыть не только аналитиком, но и представьте себя в роли заказчика, а затем почувствуйте себя дизайнером. Это поможет аналитику создать действительно успешную информационную панель.
Такой была конференция Analyst Days 2017: на выходе есть о чём поразмыслить, что взять на заметку и над чем поработать.
