В апреле наши коллеги побывали на международной конференции по системному и бизнес-анализу Analyst Days 2017, проходившей в Москве. Под катом — впечатления от самых интересных, на наш взгляд, докладов этой конференции.

Тематический блок «Качество требований»

Елена Горопека, «Тестирование требований. Находим проблемы до их появления»

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

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

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

Таисия Толстунова, «As large as life. Полнота требований и способы ее проверки»

Таисия начала свой доклад с описания того, что мы имеем ввиду под «полнотой требований», как мы её определяем. Мы можем рассматривать это понятие с точки зрения классиков, таких каr Вигерс и Коберн, использовать определения Babok и SWEBOK, и так далее. Неполнота требований приводит к потере качества, времени работы всей команды и профессиональной самооценки. А значит стоит постараться избежать этих последствий. Докладчик предложила использовать следующие техники:

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

Тематический блок «Повышение эффективности, специализированные навыки»

Ольга Самарина, «Дизайн-мышление. Что это и могут ли аналитики его применять?»

В рамках своего доклада Ольга пошагово рассмотрела весь путь от постановки задачи до создания её решения. Важно с самого начала выявить реальную проблему людей, и в поисках решения не следовать стереотипам. Пользователь не всегда может сказать, что нужно сделать иначе. Генри Форд, например, мог бы быть коневодом.



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



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



Ещё в этом блоке был очень интересный мастер-класс.

Сбор требований и описание видения решения (сокращенная версия)

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



Нам нужно было выделить основные потребности наших клиентов — NEEDS. Это краткое описание текущего состояния имеющихся у клиента потребностей. В качестве примера можно привести потребности в коммуникации, формировании финансовой отчетности, продаже билетов и так далее. Приятные дополнения — WANTS, это то, что не решает основную проблему пользователя, но может быть удобным, полезным, радовать его. После того, как мы определились с первыми двумя пунктами, надо было определить, что именно мы будем реализовывать — JOBS TO DO. И сразу разбить их на три группы: функциональные, эмоциональные и социальные. Мы учитывали также, что нужно будет сделать кроме основного функционала: нужно ли готовить документацию, проводить сертификацию, обучение персонала и так далее. И для каждой конкретной задачи нужно было прописать критерий приёмки, критерий качества, ожидаемый результат, риски, связанные с её реализацией. Это было интересное творческое задание, в ходе которого небольшая группа незнакомых друг с другом аналитиков смогла договориться и найти ответы на все эти вопросы.

Тематический блок «Коммуникации»

Очень запомнилась лекция Сергея Крупенина «PM vs BA vs World. Как ведут себя люди, которым вы ставите задачи + Управленческие поединки. Суровая практика». Кстати, по итогам голосования именно Сергей был выбран лучшим докладчиком конференции.

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



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



Определить, какую реакцию проявляет человек на требования руководителя, поможет эта таблица. Рассмотрим пример с определением порядка. Руководитель принял решение о том, что команда будет работать по SCRUM с двухнедельными итерациями. А один из подчинённых начинает рассказывать о том, что KANBAN лучше, и стоило выбрать его. Можно определить реакцию сотрудника как «перехватывающий управление».



Руководителю стоит внимательно наблюдать за реакциями подчиненного в разных ситуациях. Наиболее частая реакция — это и есть его характер. В зависимости от этого стоит скорректировать своё поведение с ним, чтобы стремиться привести его к лояльным реакциям.