Недавно вернулись из Киева, посетив конференцию по бизнес-анализу Reqlabs 2012. Несмотря на то, что у конференции есть еще заметный запас роста,впечатления сложились весьма положительные. В этом обзоре мы поделимся впечатлениями, расскажем о понравившихся докладах.
Основной день конференции начался, конечно же, со вступительного слова. Но с этим затягивать не стали, и первые доклады начали читать уже через полчаса.
Конференция проходила в 2 потока. Первыми выступали Пол Тернер (Paul Turner) и Артем Сердюк. Мы отправились поддержать Артема. Как оказалось, не зря, поскольку из его доклада вынесли полезные идеи касательно создания карты бизнес-эффектов: Артем рассказал о спиральной динамике развития мотивации и о том, как это можно использовать в постановке задач, а также о составляющих счастья применительно к аналитику.
Доклад Вадима Мустяцы из Молдовы про «людей-батареек» подкупал в первую очередь харизмой докладчика. Вадим построил фабулу своего рассказа на 12 принципах Agile Манифеста, которые (руководствуясь той самой вездесущей гибкостью) аналитик не должен воспринимать буквально. Конечно же, нарушать правила Вадима научил собственный профессиональный опыт. Наглядные (иногда даже чересчур) примеры сотрудничества Вадима с государственными инстанциями Молдовы, в сочетании с непередаваемой манерой исполнения докладчика сделали своё дело: публика восприняла доклад очень позитивно, а обсуждение было оживленным, но конструктивным. На удивление, практически никто не пытался троллить Вадима =)
В общем, Вадим оказался живым воплощением своей идеи аналитиков как “людей-батареек”, которые замыкают “электрическую цепь” проекта и “зажигают” его, как лампочку.
Доклад Андрея Курьяна заранее интриговал названием «Противоречивые требования: проблема или возможность». Людей, желавших узнать ответ на данный вопрос, собрался полный зал. К сожалению, Андрей несколько обманул ожидания собравшихся: большей частью он немного сбивчиво рассказывал про теорию ТРИЗ, а когда попытался привести пример противоречивых требований про документооборот (посмотреть можно в конце этой статьи), то получил из зала логичный, но неожиданный для себя ответ, который привел докладчика в некоторое замешательство. Оставшаяся часть доклада, к сожалению, не позволила получить четкое понимание того, как можно справиться с противоречивыми требованиями.
Стоит отметить, что Андрей частично реабилитировался, увлеченно отвечая на вопросы после доклада и на круглом столе.
Дмитрий Безуглый, пользуясь заслуженным статусом “гуру” представил доклад в стиле “коней в вакууме” – абстрактный, и от этого совершенно неоспоримый =)
По мнению Дмитрия, качество работы аналитика не нуждается в определении, если customer happy. Если же он не happy – причина не обязательно в том, что аналитик плохо сделал свою работу. Качественная работа аналитика подразумевает несколько обязательных составляющих:
- «Правильные» люди
- «Правильный» процесс
- «Правильная» методология
- «Правильная» культура
А у кого хоть что-то из этого списка “неправильно” – пусть посыпает голову абстрактным вакуумным пеплом. Шутка.Такой вердикт конечно не был озвучен, но понятно, что способы решения этих проблем лежат уже в других плоскостях и требуют отдельного рассмотрения.
Доклад другого гуру сообщества uml2.ru Александра Байкина стал рекордсменом в номинации “самый быстрый доклад ever”. Тему сисек «Описание бизнес-правил и дополнительных требований в вариантах использования (use cases)» Александр раскрыл за 10 минут. Конечно же, описывать их полагается в виде отдельных разделов со ссылками из юзкейсов. Спасибо за внимание. Приходите еще.
Зато, благодаря беспрецедентной краткости Александра, слушатели его доклада получили возможность послушать параллельного докладчика – Дмитрия Приймака, который попытался (вполне убедительно, кстати) ответить на извечный вопрос о том, кто же такой аналитик – технарь или психолог? Навыки/характеристики идеального аналитика, по мнению Дмитрия – это:
- Говорить на языке stakeholder’ов и уметь «видеть» их глазами
- Уметь быстро учиться
- Быть свободным от стереотипов
- Уметь излагать свои мысли доходчиво
- Быть грамотным (в устной и письменной речи)
- Обладать хорошими коммуникативными навыками (найти общий язык и с грузчиком, и с миллиардером)
- Уметь находить решения
Исходя из перечисленных характеристик, ответ на исходно поставленный вопрос про психолога vs технаря становится очевидным (облегченно вздохнули те, кто не может похвастаться мощным техническим бэкграундом).
Интересным оказался и доклад Натальи Руколь, посвященный тестированию требований. Были рассмотрены основные проблемы при работе с требованиями:
- разработчики делают «не то»
- требование реализовано, но не работает
- требования часто меняются
- разработчики допускают ошибки
- Product owner заводит много багов в task tracking системе, которые на самом деле багами не являются.
Помочь могут следующие методы:
1. Субъектинвая оценка
Аналитик может руководствоваться вопросами: Кто использует требования? Довольны ли они? Если нет, то где сосредоточена проблема? Что мы с этим можем сделать?
2. Анализ дефектов
Разработчик может сам определять причину бага: неправильно написанный код, изменения требований, неправильное понимание требований. Конечно, сработает это только в том случае, если никто не будет пренебрегать честностью.
3. Проверка требований по чек-листу
Тестировщик проверяет требования на соответствие заранее установленным командой критериям: на полноту, «понятность», отсутствие двусмысленности и т.д.
Также Наталья поделилась советами по минимизации рисков, связанных с требованиями:
- Аналитик может презентовать требования, при этом имея четкий план презентации.
- Следует использовать разные форматы документирования, заранее обсудив этот момент с командой
- Исполнитель должен фиксировать требования. Хорошо работает способ «Повтори, пожалуйста, что я тебе только что рассказал».
- Все требования должны быть трассируемыми.
Во второй половине основного дня конференции состоялся круглый стол на тему «Менеджер продукта и аналитик: зоны ответственности и взаимодействие». И хотя к четкому выводу прийти так и не удалось, разделение обязанностей явилось поводом для бурного обсуждения.
Заключительной частью первого дня конференции мини-доклады в формате печа-куча и аналитические поединки. Примечательно, что большая часть участников отправилась на мини-доклады, и только горстке энтузиастов довелось послушать опытных аналитиков, которые сравнивали инструменты управления требованиями Sparx Enterprise Architect, IBM Rational Requisite Pro, PowerDesigner. Поединком данный формат был назван не зря: основной задачей было показать преимущества одной системы управления требованиями над другими. Получилось содержательно. Мы узнали о некоторых продвинутых функциях Enterprise architect, и, хотя можно долго спорить о целесообразности использования этих функций (и инструментов в целом), получилось весьма познавательно.
Ну а завершил первый день конференции, конечно же, нетворкинг в виде посиделок в баре и общения между участниками и докладчиками. Как уже было отмечено, общее впечатление сложилось однозначно положительным. В качестве способа повышения квалификации аналитиков данную конференцию можно рекомендовать.
По поводу моего доклада и неожиданного ответа…
«Логичный» ответ дала женщина, работающая в автомобильной отрасли в Германии. В этой отрасли действительно выработаны стандарты, регулирующие отношения между контрагентами (см., например, ISO 16949). Стандарты содержат достаточно жесткие требования к отношениям организации с поставщиками, в том числе, в соответствии со стандартом производитель может потребовать у поставщика нормировать сроки обработки документа. Более того, стандарт предполагает специальную процедуру выбора поставщика и выстраивания отношений с ним, в том числе, согласования параметров поставок продукции, параметров документооборота и т.п.
А если речь идет о других отраслях, где нет таких жестких требований? А если речь идет о ситуации, когда компания NoName хочет работать с компанией MegaBrend? И куда пошлет MegaBrend требования NoName нормировать сроки обработки проекта договора?
Хочется донести до аудитории важную мысль: не существует идеальных решений вообще; существует идеальное решение для данной конкретной ситуации и данной конкретной системы. Если ситуация меняется, то меняется и содержание идеального решения.
Прошу рассматривать мой пост, как существенный комментарий к моему неудачному докладу. :)
Эх, Андрей, это надо было в ответ сказать, и дальше разобрать кейс! А получилось, что ни первый, ни второй пример нормально разобран не был :( Как я тебе и говорил — если не понятно, в чем же проблема, то нет интереса и к решению кейса.
А со вторым кейсом что не так?
У меня стойкое ощущение, что его тоже не поняли.
Вообще надо видео увидеть, может я не прав.
ИМХО, проблема не не в кейсах. Кейсы предназначены для демонстрации того, как инструменты ТРИЗ могут использоваться аналитиками в повседневной работе. Публика же, которая собралась на докладе, либо ничего не слышала о ТРИЗ, либо что-то слышала, но не знает, тем более, не пользуется. В течение 15 — 30 мин сложно уловить особенности работы этих инструментов в том или ином кейсе.
Это я так, размышляю о причинах реакции публики.
Андрей, спасибо за классное общение в кулуарах. Поделись, пожалуйста, именем товарища, который ТРТЛ сейчас разрабатывает?
О, ещё. Хочется больше фот! Юля очень много снимала, я видел! ))
Артем, и тебе спасибо!
Игорь Викентьев. Сайт: vikent.ru
Артем ? У меня даже фотоаппарата с собой не было =)
Юля, а кто же была та девушка с фотоаппаратом? Я её Юлей назвал.
(facepalm) мне так стыдно )))
Девушка была, помню. Мне показалось, что это был официальный фотограф. =)
Ребята, спасибо вам огромное! Единственно, от «чересчур наглядных примеров» насторожился )) Кабы я там не переимпровизировал, а то ведь на записи уже не оправдаться… )))
Лично мне конференция пришлась по нраву, за что моя горячая благодарность организаторам и всем собравшимся, в особенности Артёму за мощный зелёный заряд, всей белорусской делегации за их беспрецедентную дружность и неизменное остроумие, а также неожиданно посетившей мой доклад Ирине Чубуковой (по её книге в магистратуре я готовился к экзамену по Data mining (sic!)), которая так заразительно и мило улыбалась, что мне хотелось приводить всё больше чересчур наглядных примеров ))))
Люди и их взаимодействие важнее… чего бы то ни было +)
Вадим, у меня есть много цитат тебя из твиттера благодарных слушателей ))
В своем докладе вставлю! ))
Какой доклад ты имеешь в виду, Тём? ) Лишь бы меня в Молдове за эти цитаты волчьим билетом не наградили ))) Хотя я, вроде, пока ещё не так далеко зашёл +)
тьфу. имел в виду — в своем отчете о конфе (если он будет)
Как же мне не хватает «Like» здесь в комментах =)
+1! Нужно лоббировать эту фичу для следующего релиза )))
Но ещё приоритетнее, ИМХО, уведомления о новых комментариях в теме. На «низковисящий плод» смахивает, если я правильно понимаю трудоёмкость ))
Почему только эти доклады освещены? Я полагаю, хоть кто-нибудь из наших да успел побывать на каждом из докладов.
Рома, а даму из машиностроения ты решил не поминать? :)
Но доклад ее, безусловно, был многообещающим.
Вы меня так заинтриговали, что это видео я буду смотреть первым делом )))
Вадим, если хочешь бесполезно провести 30 минут жизни — обязательно посмотри! %)
Я бы с большим удовольствием посмотрел на лица людей, сидящих в зале ))
Вадим, скушай лимон и посмотри в зеркало. Получишь общее представление о лицах в зале. :)
:-D
Обзор очень неформальным получился : )
«Интересным оказался и доклад Натальи Руколь, посвященный тестированию требований.»
- вообще-то это просто название доклада. Про собственно тестирование требований в презентации ничего не было. Но это не отменяет того факта, что сам доклад был полезным и интересным и сама Наталья приятным докладчиком : )