Конференция Req-Labs в Киеве прошла хорошо. Есть мелкие проблемы, которые я перечислю сразу - чтобы организаторы их учли, если прочтут мой отзыв. WiFi практически не работает, так что за докладчиков - я так и не голосовал. Залы - очень длинные и экран сзади видно плохо и мелко, можно, наверное, было попробовать повернуть расположение, повесив 2-3 экрана. А еще - не хватало указателей на улице к конференции для новичков в Киеве - в парк Пушкина в первый день и к нужной двери бизнес-центра во второй. А так - организация достойная. Два трека, большие перерывы для общения. Отдельный зал для общения с докладчиками, правда там было не слишком много народа.
А главное - достойное качество докладов. Много практических докладов, мало теоретиков. При этом, что характерно, эти авторы практических докладов теорию знают на высоком уровне. Поэтому рассказ практик идет в контексте современных теорий. Или наоборот, теории сильно иллюстрируются практиками. Что на современных конференциях встречается не так часто, как хотелось бы. О ценности докладов говорит то, что я очень много конспектировал на ноуте. Может быть, кончено, что я просто был на лучшей половине докладов. Но, с другой стороны, лучший по итогам голосования на facebook в день конференции докладе я пропустил. Это "Бизнес-аналитик или бизнес-синтетик? Или как сделать бизнес-анализ чуть менее унылым" Артёма Сердюка (ISM Ukraine, Украина), который шел параллельно с докладом Пола Тернера. Буду будет смотреть видео.
Что интересно - организаторы говорят, что при организации Конференции были воплощены многие идеи, высказанные участниками мозгового штурма на мастер-классе в рамках AnalystDays в Минске.
Дальше - краткий обзор докладов.
Why is an understanding of Business Architecture important to Requirements Engineers? Paul Turner (AssistKD, Business & IS Skills, Великобритания).
В докладе много схем, структурирующих область ведения проектов и работы бизнес-аналитика с разных точек зрения. И эта структура отличается от того, который у меня лично сформирован преимущественно IT-шыми источниками, и это - интересно, потому что расширяет и дополняет представления. Правда, примерно до середины эти представления были на достаточно высоком уровне абстракции, что не столь интересно. Но потом - было несколько более глубоких схем. Существенным недостатком этого доклада была быстрая речь докладчика. которую я понимаю только полностью концентрируясь. Поэтому когда на слайдах возникала интересная схема, в которую вчитывался - я терял часть доносимого устно смысла. Так что тоже буду смотреть видео.
Схемы пересказывать глупо и бесполезно - надо смотреть презентацию. Но кое-что отмечу тезисами.
Enterprise Analysis: The importance of the ‘why’ and the ‘what’. Adrian Reed (Blackmetric Business Solutions, Великобритания).
Я третий раз слушаю доклад Адириана и, надо сказать, их уровень растет, этот доклад был лучше и живее. В этот раз он достаточно плотно рассказывал про Enterprise Analysis - subset of BA, и создание project concept.
Problem description frame.
И далее анализ целей.
Техники:
В докладе был пример, достаточно хороший. Неожиданный успех маркетинга привел к тому, что call-центр по приему заказов захлебнулся, и был придуман несимметричный ответ - переход к заказам по e-mail. Интересно, что Адриан попытался показать, как возникает эта трансформация, поднимается уровень целей - потому как в начальной задаче речь, естественно, шла о мерах по повышению производительности call-центра.
Requirements Engineering in Automotive Industrie: From the practice – for the practice. Irene Koschel (XTRONIC, Германия), Sergej Schmidt (SMR Automotive Mirrors Stuttgart, Германия). Докладчики - двое русских, работающих в Германиском автопроме в разных фирмах, но на совместном проекте. Была только Irene, Сергей приехать не смог.
Интересно, что кроме гигантов производства в Германии, множество (700+) небольших фирм, которые аутсорсят, в том числе - дизайн и тому подобное. Она - в небольшой фирме, которая подрядчик Даймера, плюс выпускает e-roller. Их E-roller 20 км/ч и это - уникальная скорость для электромобилей. А еще - бортовые компьютеры. Фирам интернациональная, 18 национальностей. А он - из немецкой фирмы, которую пару лет назад купили индусы. Производят зеркала и смежные системы - сенсоры, видеокамеры с выводом на бортовой комп, и там тоже много софта, надо отслеживать парковку, движение в мертых зонах и прочее. Совместный проект возник потому, что SMR умел делать зеркала, а XTRONIC - нужные сертификаты по процессам для серийного проекта.
Современный автомобиль - это не только hardware, это более 2М строк кода, который обеспечивает работу двигателя, тормозов и всего остального - без софта он не едет. Вообще самолеты уже давно ведет автопилот. А сейчас - тренд к автоводителю. Потому что без него - плохо для людей с плохим зрением и прочими проблемами, плюс больше рисков. В 15 году Германия вводит правило - система автоторможения автомобиля по препятствиям (и еще что-то?).
К софту автомобиля - очень жесткие требования, это работа в реальном времени и без ошибок. При этом там много процессоров в разных устройствах, но все они должны работать согласованно. И идеей доклада было рассказать о схеме работы с требованиями в этих проектах. К сожалению, в тайминг уложиться не получилось. Была большая вводная историческая и общая часть, очень интересная, но из за этого слайды про ведение требований пришлось проходить в бешеном темпе, а на живую демнострацию вообще времени не было. Но интересующиеся могли найти докладчицу в перерывах и посмотреть.
В докладе была интересная история старой пикировки GM vs Microsoft. Ее надо посмотреть на слайдах. А всерьез на автомобиль 500 документов, около 300 страниц в каждом.
Требования:
В конце был headhunting на работу в Германию в автопром, облегченный greencard. И замечательная врезка о женщинах в автопроме. Первые права - женщина, первый штраф за превышение скорости - тоже, и первый автопробег вокруг Земли... В общем, женщины - рулят. Она - в чужой стране и мужской отрасли.
И пара штрихов.
Как всегда, очень живой и доклад. Я, правда, был не сначала - общение затянуло. Идея - про улучшение процесса. Которое всегда должно начинаться с анализа причин. А кроме мер - должно быть понимание, как будем оценивать успех.
И все это - на конкретном кейсе, проект в котором 2.5 разработчика, а аналитик занят сильно не полностью. И в какой-то момент - обнаруживаем что слишком много багов на проекте. Как способ - классификация багов: Ошибка/Не понял/Не было требования/Изменение требования.
Вопрос был - а не будет ли читерства? В их коллективе - не будет. Но если подозреваете - можно двухстороннее ревью.
Навели статистику, поняли измеримо, что проблемы - не в 2.5 разработчиков, а в том, что всего 20% аналитика. И тут получается реальный ROI. Правда пока с этим примером - ROI не подтвержден, но проблема - уже решена.
Методы:
Выводы. Все компании - разные, и проекты тоже, поэтому требования - разные. Но вот улучшения - общее. Начинаем с анализа, и потом - придумываем решения, а потом - проверяем эффективность.
Дима рассказывал о том, что говоря о качестве работы с требованиями, люди часто подразумевают поиск ответа на вопрос "кто виноват". И даже когда формулируют "как улучшить?", подразумевают, что это просто надо что-то сделать с аналитиком, чтобы от него получались хорошие требования. А реально качество требований имеет четыре составляющих:
И важны все четыре, поэтому на этапе анализа они должны быть рассмотрены, и выявлены наиболее проблемные места, с которыми нужно работать. Особенно часто забывают культуру, а именно она обеспечивает что делаем то, что нужно. Без нее будет идеальная поставка качественного ненужного продукта.
В докладе было много историй и примеров из опыта.
Упоминавшиеся техники и подходы.
И отдельные тезисы.
Ирина достаточно детально рассказывала, как устроено у них ведение требований. Без особых обоснований. Но от уважаемой фирмы этот детальный процесс интересен сам по себе.
Продукт в Касперском, опыт за 3 года, когда перестали вести требования в Word. За это время вышли три релиза. Продукт - входит как часть в большой продукт.
Первый этап - надо было организовать репозиторий требований, которые ранее вели в Word. Надо поделить по функциональным областям (например, родительский контроль), и соотноситься требования из разных областей. Выбрали EAP, это до нее и почему - сказать не может. Он используется до сих пор, и требования - покрывает.
Слайд - структура модели, дерево. С учетом релизов. Источник - трекер бизнес-требований их дивизиона. В корневом требовании - ссылка и краткое содержание, полностью - в исходной системе.
Основа ведения требований - usecase модель, а функциональные и нефункциональные требования ее дополняют. Каждая фича по ним разложена. Еще есть инфраструктурные требования - другой слой, он представляет требования самого продукта к инфраструктуре. Например, требования к серверам и софту раздачи обновлений. Бизнес-требования - в контексте релиза, инфраструктурные - к системе целиком, так проще. В этой же модели у них описаны требования на само ведение требований.
Отделено хранение требований от представления требований. Для представления для большинству заказчиков - генерация документов, Word и заметки к нему. И для разработчиков - тоже Word. А аналитики работают с моделью. UML-профиль требований инструмента - они доточили, дополнительные поля и еще местами. И подготовили шаблоны на общий (полный документ) и частный (по фиче и т.п.) SRS.
SRS публикуются в SharePoint портал как doc-файлы, контроль версий ведет Sharepoint и история - поддерживается. Программистам идут частные SRS, и есть дополнительные настройки - кому-то больше картинок, другим - текст. Диаграмма трассировок: Бизнес-требование - UseCase - Дополнения. Еще есть html-генерация, фактически получается readonly-копия базы.
У них PDK - с их продуктом поставляется набор библиотек, версионируются вместе. Разрабатывают отдельные команды, и надо согласовывать. Где будет реализовано требование, в продукте или PDK - это зона ответственности архитектора, а не аналитика. Требование посылается архитектору, он их мапирует - на 1-3 части (продукт и PDK). Компонентные требования - в этом же репозитарии, но в отдельных продуктах. И получается нормальная трассировка. Внешние взаимодействия с инфраструктурой. Выявляют инфраструктурно-зависимые требования. И требования к инфраструктуре учитываются. Инфраструктура - она ведет требования по-разному.
Когда идут изменения - учитывают область влияния, это обеспечивают трассировки в инструменте. Генерят документ и выкладывают на Sharepoint как новую версию. А Sharepoint - он умеет сравнивать версию. Поскольку один шаблон - структура сохраняется, левых изменений не появляется. Так что в целом - удобно.
Требования на задачи в этом проекте не трассируются, Задачи - комплексные. И на тесты тоже. У нее опыт проекта, где трассировка полноценная, но это - отдельно.
Как происходит переход на новую версию продукта? Тестировщики и Заказчик - хочет видеть все полностью. А разработчики - хотят только изменения. Они выделяют цветом - добавление, изменение и удаление на диаграмме. Раскрашенная диаграмма, цвета - жестко. Важно, что на диаграмме есть и удаленные элементы. А в тексте - новые требования синим плюс курсивом. До настроили шаблоны, а версии по релизам - выкладывают snapshot. И после фиксации версии делают обесцвечивание.
Планы на будущее - массовый переход на TFS, работа разработчиков с атомарными требованиями там.
Это был эксперимент. Формат предполагает доклад из 20 слайдов по 20 секунд на каждый, итого меньше 7 минут, а слайды переключаются автоматически. Формат хороший и содержательный. И я хочу высказать уважение дкладчикам, которые это сделали, независимо от того, что получилось внутри.
А еще - идеальный формат для холиварных тем. С каждого участника стола по такой презентации. И для презентации методологий и стандартов - тоже хорошо :) А модератор говорил, что он знает компании, где такой формат применяли для годовых отчетов подразделений.
Записывать во время докладов невозможно - большой темп. Так что я лишь оценю результат.
Был рассказ о ТРИЗ - как он может помочь бизнес-аналитику. Если по требованиям получается придумать решения - хорошо, даем задание разработчику. проблема, когда известные решения - не позволяют удовлетворить требования. И тогда уместен ТРИЗ. Правда, с примерами и конкретными техниками - было не слишком хорошо, были ссылки на сайт, где "все написано" (докладчиком?). И это - печалит, потому что если нечто докладчик может рассказать только длинно, значит оно смутно и непонятно. Из техник был упомянут RCA+ (Root Conflict Analysis Plus) и Идеальный конечный результат. Примеры - были, но тоже не слишком хорошие, по ним докладчика тролили. Потому что проблема, веременного регламента для обработки документа из-за необходимости ответа контрагента - она известная, и решения - известны, то есть это уже не проблема.
На мой взгляд, получился весьма нечеткий доклад, наполненный формальными аналогиями, которые были поверхностными. Например, о том, что команда программистов - как спортивная команда и есть роли, а дело передается как мяч. Ну и что? О паттернах, но при этом докладчик легко переходил между design pattern, ALM process pattern, или шаблонами представления требований, смешивая их и перенося вещи, справедливые для одних, на другие виды паттернов без всяких обоснований (они же тоже паттерны). Увы.
Я заходил фрагментами, параллельно слушая доклады. Хорошего обсуждения не получилось. Потому что тема - холиварная, у людей - есть свои мнения и понятия, и перейти на общие термины, пусть в рамках данного обсуждения - они не готовы, готовы говорить только в своих терминах (у нас аналитик - тот кто делает это, а PO - тот кто делает то). При этом очень хотят некоторого "оптимального" и "правильного" решения, освященного если не методологами, то хоть экспертами круглого стола. Кстати, это желание у некоторых экспертов - тоже было.
Если говорить о проблемном поле, то вопрос в том что есть Product Owner, Product Manager, Product Director - со своими ответственностями. А есть бизнес-аналитик, и другие аналитики, и области перекрываются. Дима высказывал радикальное мнение: аналитик готовит информацию, аргументирует, но не принимает решения - они за другими. Но такая постановка не нравилась: одни ее не понимали: "как так, не принимает решения?", другие - хотели какой-то ответственностью обязательно нагрузить, рассказывая как у них.
В целом, такие обсуждения надо проводить гораздо более сфокусировано и с жесткой модерацией - если это вообще возможно.
Этот доклад был заменой Григорию Печенкину в связи с болезнью. Основной идеей было то, что от аналитика требуется много коммуникативных, психологических аспектов. Умение учиться, умение разговаривать на разных языках, вживаться в разные языки - заказчик, разработчик. Свобода от стереотипов, чтобы не влияло кривое зеркало личных предпочтений. Умение излагать мысли доходчиво. Правильно структурировать, выдержать терминологию. Выдерживать нотацию - и в диаграммах и в письмах и в контрактах. Орфография, осторожно использовать слэнг. И так далее. Мысли правильные, но, на мой взгляд, поверхностные и очевидные. По-моему, аналитиков, ориентированных исключительно на "правильное проектирование" уже нет. А может у меня слишком идеализированное представление.
Тренинг был на следующий день, в субботу. Очень содержательный, как и было обещано в программе. К сожалению, у Димы не получилось сделать сбалансированный тайминг: первые два модуля заняли почти 6 часов, и остальные четыре Дима рассказывал в бешеном темпе, за 3.5 часа. Но рассказал, хотя общее время увеличилось и закончили в полдевятого, а потом еще были ответы на вопросы. Но все равно, тренинг получился очень хороший и ценный. А рассказывать его я не буду. Потому что программа - она подробная, и упомянутые методики - они легко ищутся. А наполнение примерами и личным опытом - его воспроизвести нельзя.