Комментарий очевидца: Раннее субботнее утро, промышленный район города Киева, на обочине изредка встречаются пустые автомобили. В одной из машин, припаркованных возле здания из стекла и бетона, замечены девушки модельной внешности. Промелькнула мысль: аналитики, не похожи, но точно аналитики, больше в такой час тут быть некому. На рецепшн БЦ "Ирва" догадка подтвердилась...
В качестве приветствия Вячеслав Панкратов показал ролик об управлении проектами:
Казалось бы, детский мультфильм, а как точно иллюстрирует распределение ролей внутри IT-команды.
Ирина Крючкова рассказала об инструменте Аналитика - проектировании пользовательских интерфейсов. В докладе были рассмотрены виды прототипов, преимущества и недостатки прототипирования, инструментарий для прототипирования пользовательских интерфейсов.
Прототипы пользовательских интерфейсов можно использовать для изучения доступного и подходящего проекта пользовательского интерфейса, который удовлетворяет требованиям, что помогает устранить разницу между тем, что требуется (выражено посредством выявления требований), и тем, что осуществимо. Основным назначением создания прототипа пользовательского интерфейса является возможность "тестирования" проекта пользовательского интерфейса, включая удобство работы, до начала фактической разработки. Таким образом, можно убедиться, что будет создана правильная система, до того, как будет затрачено слишком много средств и ресурсов на разработку. В то же время прототип может стать хорошим инструментом для согласования и даже выявления требований.
По мнению Ирины условиями успеха прототипирования являются:
Прототип должен быть похож на будущую систему.
Прототипирование должно быть значительно дешевле разработки конечного продукта.
Пользователи, с которыми будет обсуждаться прототип, должны быть заинтересованы в системе / обсуждении / прототипе.
Прототип не должен быть очень громоздким.
Создавать прототип стоит не совсем «с нуля», не имея четкого представления о будущей системе.
Александр Байкин, при активном участии присутствовавших аналитиков подчеркнул: Преимущества прототипирования
Визуализация требований.
Быстрая и осознанная обратная связь.
Гибкость, легкость внесения изменений.
Тестирование требований заказчика.
Прототип служит входящей информацией для тестировщиков и разработчиков.
Более точная оценка трудозатрат на разработку решения (продукта).
Снижение риска получения результата несоответствующего требованиям заказчика, объема доработок и переделок системы.
Облегчение процесса создания спецификаций системы.
Выявление недочетов и скрытых бизнес-правил на ранних стадиях проекта.
Простой метод вовлечения заказчика в обсуждение требований.
Недостатки прототипирования
Риск обманчивости величины затрат труда и степени готовности к сдаче проекта.
Риск обманутых ожиданий заказчика (функционал прототипа может позволять больше чем функционал системы).
Прототипирование требует владения инструментарием и затрат труда.
Риск необдуманного использования.
Риск несогласованности, не документирования запросов на изменение системы.
Ограничение применения (невозможно создать прототип для встроенных систем).
Риск увлечения заказчика деталями реализации, а не целями проекта.
Дмитрий Мороз затронул вопросы выявления и документирования требований. Цель выступления Дмитрия – снабдить минимально необходимым набором теоретических знаний и показать, как применить на практике положения теории. В докладе были рассмотрены типы и зоны ответственности аналитиков в IT-проектах, типы и взаимосвязь требований, даны рекомендации по выявлению и управлению требованиями:
Что понимается под бизнес аналитиком. Какие типы аналитиков бывают в IT и что они делают?
В своем докладе Дмитрий выделяет следующие типы аналитиков:
Бизнес-аналитик.
Системный аналитик.
Аналитик требований .
Бизнес-аналитик отвечает за общение с Заказчиком и выявление Бизнес-требований, так же он (аналитик) является источником детализации требований заказчика для Системного аналитика. Системный аналитик может при необходимости общаться с Заказчиком и Бизнес-аналитиком, должен преобразовать Бизнес-требования в Спецификацию системы. Аналитик требований встречается только в США, в его обязанности входит документирование требований выявленных Бизнес- и Системным аналитиками, с Заказчиком не общается.
Зачем вообще нужен БА на проекте? Как начинается проект: причины и цели.
Проект обычно начинается с желания заказчика решить проблему или улучшить уже существующий бизнес-процесс (информационную систему). От бизнес-аналитика требуется выявить требования заказчика (в том числе и скрытые), проанализировать их, исключить противоречивые и заведомо нереализуемые требования, предложить заказчику варианты достижения целей проекта. По мнению Дмитрия, хороший Бизнес-аналитик составляет 50% успешности проекта.
Какие типы требований бывают?
Дмитрий выделяет следующие типы требований:
Бизнес-требования (отвечают на вопрос "почему?" и выражают интересы заказчика).
Пользовательские требования (отвечают на вопрос "что можно сделать?", детализируют Бизнес-требования).
Функциональные требования (отвечают на вопрос "что должен сделать разработчик?", детализируют Пользовательские требования).
Характеристики (отвечают на вопрос "какой характеристикой должна обладать система, чтобы выполнять требования пользователей?", детализируют Пользовательские требования).
Нефункциональные требования (атрибуты качества; дополнительное описание продукта и \ или его характеристики, важные для пользователей продукта или разработчиков).
Бизнес-правила (ограничители, корпоративные политики, принятые практики и правительственные постановления, влияющие на способ функционирования системы).
Написать требования – полбеды. Но как их получить и осмыслить.
Процесс получения требований:
Правильно сформулировать цель, очертить образ и установить границы проекта.
Правильно определить источники требований.
Собрать и обработать требования.
Достичь баланса между желаемым и реальным.
Выявить скрытые требования и найти ограничения.
Получить полную базовую версию требований.
Управлять требованиями и не давать границам проекта "расползаться".
Каждое функциональное требование, атрибут качества и ограничение должны быть:
Количественно определены – указаны единицы измерения и требуемые значения.
Приоритизированы – сгруппированы в соответствии с важностью.
Как добиться идеальных требований, какие они?
Строго говоря, требования никогда не бывают идеальны. Но достижение начальной готовности можно понять по следующим признакам:
Пользователи уже не могут придумать новых вариантов использования.
Пользователи повторно описывают уже обсуждавшиеся проблемы.
Предлагаемые новые функции, пользовательские или функциональные требования выходят за границы проекта.
Новые предлагаемые требования имеют низкий приоритет.
Пользователи предлагают возможности, которые имеет смысл реализовать "когда-то позже", а не включить в "конкретный продукт, который мы сейчас обсуждаем".
Какие требования бывают скрыты и как их определить?
Что традиционно забывают:
Интерфейс администратора
Фильтры и поиск
Импорт\экспорт
Отчеты и аналитика
Печатные формы
Вылить в PDF\XLS\TXT
Для поиска неучтенных требований необходимо:
Разложить требования высокого уровня на простейшие составляющие – это позволит понять, чего же именно просят пользователи.
Убедиться, что все группы пользователей предоставили вам информацию и для каждого варианта использования определена по крайней мере одна роль.
Подробно документировать, на каких пользовательских требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила.
Внимательно слушать – искать упоминания сущностей, отсутствующих в текущей версии требований.
Использовать разнообразные формы представления информации о требованиях.
Представлять сложную логику с помощью таблиц и деревьев решений.
Основные ошибки бизнес-анализа и как их избежать?
Избежать ошибок можно соблюдая следующие правила:
Любое требование должно быть описано.
То, что не описано в явном виде, не существует.
Должна существовать процедура внесения изменений в базовую версию требований.
Ни одно изменение не может произойти в обход процедуры внесения изменений.
Александр Байкин провел круглый стол посвященный проблемам выявления и анализа требований и их решению. Участникам круглого стола были предложены следующие проблемы:
Пропасть между Аналитиком и Заказчиком
«Да, но …» синдром
Заказчик не знает что хочет
Нет доступа к Заказчику
Заказчики противоречат
Нет Заказчика
Нет Документации
Требования постоянно меняются
Необнаруженные Требования
Распределенная команда
Заказчику ничего не надо
Руководство гонит
Иногда бывает невозможно увлекательно пересказать фильм - его нужно посмотреть. Так и круглый стол Александра Байкина. Все пришедшие на семинар, активно предлагали решения проблем, спорили, приводили примеры. В качестве панацеи было предложено:
Изучать нормативную документацию.
Изучать предметную область.
Анализировать аналогичные продукты, разрабатываемые конкурентами, Best Practices.
Привлекать экспертов.
Налаживать контакт с Заказчиком.
Фиксировать требования и запросы на изменения требований.
Использовать прототипы.
Предлагать готовые (коробочные) решения.
Это далеко не все "серебряные пули" из обоймы предложенной присутствовавшими аналитиками. Надо отметить, что Александр предлагал и свои способы решения проблем выявления и анализа требований. И каждый раз казалось, что это решение естественно в данной ситуации, но почемуто никому не приходило в голову озвучить его во время обсуждения проблемы.
Хочется поблагодарить организаторов семинара: Ирину Крючкову и Елену Голубенко за интересный семинар, Вячеслава Панкратова - за предоставленное помещение, Григория Печёнкина - за видеосъемку, докладчиков - за поднятые темы и вопросы, которые дали возможность узнать что-то новое, заставили задуматься о некоторых аспектах работы аналитика. И, конечно же, несколько вопросов:
организаторам - "А когда следующий семинар?"
докладчикам - "А будут ли статьи по темам докладов?" Интересно было бы прочитать и, возможно, подискутировать.
