Мастерская бизнес-анализа

Конференция ReqLabs 2011 “Требования в IT-проектах”

10.04.2011 at 01:31 Оставить комментарий

Конференция прошла в Киеве 25 марта, собрав более 200 участников и была международной. Программа конференции здесь. Выложены презентации
По отзывам (пока к сожалению немногочисленным) участников конференция была « она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг, народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек.», среди множества докладов приходилось выбирать самые интересные.
Конференция длилась с утра до позднего вечера (включая пиво-party) и даже продолжилась на after-party.
Все доклады записывались на видео и организаторы обещали выложить их на сайте конференции через некоторое время.
Были приглашенные звезды – доклады сделали Адриан Рид и Пауль Тернер, и чтобы их послушать не хватило даже сидячих мест на всех желающих. А Пауль разыграл среди слушателей свою книгу по техникам бизнес анализа.

Как обычно, наиболее интересно «Впечатления о REQ-Labs 2011» изложил Макс Цепков.

Он оценил выступление «Turner Paul The Evolving role of the Business Analyst» как  “живой и экспрессивный рассказ, с выражением”, но, требующий очень хорошего понимания английского, так как был исполнен в очень бойком темпе. (доклады на английском шли без перевода).
Сергей Кадомский  пишет: « Уже на первых минутах выступления господину Тёрнеру удалось расположить к себе аудиторию, и следующие 45 минут я с удовольствием слушал захватывающую историю с примерами из жизни и вовлечением слушателей. Господин Тёрнер рассказывал о важности роли и раннего вовлечения в проект бизнес аналитика, о развитии его карьеры от создателя документов с требованиями до консультанта, управляющего изменениями процессов в организациях. Немалую часть его доклада была уделена академической составляющей бизнес анализа на базе SFIAFoundation. Данный доклад стал для меня очередным подтверждением того, что по мере развития технологий и внедрения их в нашу жизнь, роль бизнес аналитика будет становиться еще более важной и интересной».

Про доклад «Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers» Цепков написал так:
“Речь как журчание ручейка. В целом все правильно, но без вдохновения… (Может быть, я пристрастен — потому что язык чужой, и для понимания нужно больше энергии, чем для доклада на русском — соответственно, требования для меня выше)”.
В отчете Сергея Кадомского об этом  докладе “Вовлечение Заказчика: Успешное завершение проекта при неблагоприятной обстановке”: «Основным посылом доклада являлся тезис о том, что раз люди делают проекты, то им стоит уделять особое внимание. Были рассмотрены методики идентификации, классификации, вовлечения и управления заинтересованными лицами, а также даны практические советы о том, как сделать заинтересованных лиц действительно заинтересованными в успешном завершении проекта. Несмотря на то, что доклад читался на английском языке, зал бы забит до отказа и докладчика еще долгое время не отпускали, задавая ему вопросы”.

Максим Цепков разделил те доклады, что он слушал, на Замечательные доклады и Остальные доклады.

Из  Замечательных Максиму Цепкову  больше всего понравился доклад Ефименко Дмитрия “Метод от целей при анализе требований и управлении рисками программного обеспечения”, поэтому уделю автору и докладу больше внимания.
Дмитрий (директор харьковского офиса компании Unitecsys) уже несколько раз выступал на эту тему, так:
- в апреле 2010г он проводил в ИТ сообществе Харькова дискуссию: «Неадекватные заказчики – кто, почему, как бороться». «Во время последних встреч IT Talk красной нитью обсуждений проходят мнения: “мой заказчик неадекватен”, “он не знает, чего хочет”, “он губит проект”. Именно о том, откуда у компаний берутся неадекватные заказчики, каковы причины того, что казалось бы вменяемый бизнесмен превращается в убийцу собственного проекта, как с этим бороться, хотелось бы обсудить в рамках этой дискуссии».
В сентябре 2010г он писал у себя в блоге: «выступал на IT Jam на провокационную тему “Заказчик часто меняет требования и не спасает любимый agile,…?»
Эта тема заинтересовала слушателей и просто требовала продолжения, и она получила продолжение в виде Open Talk, которые проводит Дмитрий: в ноябре 2010г – «С учетом, то половина пришедших не была на IT-Jam, пришлось таки повторить свой доклад. В результате, до ролевых игр так и не добрались по причине взорванности мозга половины присутствующих Может быть, в другой раз. В силу того, что про Kanban особо и говорить нечего – это не методология, а просто практика и к разработке ПО притянута явно искусственно, просто как антипод SCRUM, то основное время я уделил методу “от целей” и двойным стандартам. Как всегда, возникло отвлечение на острую, но незапланированную тему – таки да, нужно жестче модерировать процесс,.
Затем в феврале 2011- можно почитать здесь и в последующих постах, а также в отзыве ИТ леди “Задача декомпозирована до соплей… и все равно не работает“. 
О Дмитрии и раньше были прекрасные отзывы:
« г-н Ефименко ака Damiano – харизматичная личность, тут не поспоришь, со своей специфической манерой общения с залом и людьми, мастер метафор – любит говорить красиво, человек эрудированный и в ИТ достаточно опытный, если Вы его не слышали – стОит послушать, чтобы составить свое мнение».

Тезисы доклада на REQ-Labs 2011 «Метод “от целей” при анализе требований и управлении рисками программного обеспечения»:
• Краткий обзор основных проблем в работе с требованиями.
• Критика “кладоискательского” подхода в модных и не очень методологиях.
• Практика – взгляд с другой стороны и другие неприятные реалии жизни.
• Работа от бизнес-целей в решении основных проблем работы с требованиям и управлении рисками.
• О “страшных” изменениях требований.
• Вопросы ритма доставок и длительности итерации.
• Применение метода “от целей” в тру-планировании, сравнение с классическим “не стыдно заказчику показать и руководство впечатлить”.
То есть, здесь прозвучала большая часть того, что обсуждалось последний год в Харькове. Максим Цепков об этом докладе пишет: «Докладчик — достаточно харизматичный человек, а сам доклад был о том, что не надо сотворять кумира из любой методологии. (хотя Максим слушал не сначала, и такую цель в явной формулировке не услышал). А услышал прилично подтвержденные тезисы, касающиеся конкретных методологий, о том, что они не работают. Но в провокационной форме с сильным преувеличением. Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи — предлагалось проектирование по бизнес-целям, и заявленное в названии доклада. Думаю, именно потому, что погружаться в бизнес-область до уровня понимания и бизнес-целей и способов их достижения больше всего не любят. Более того, из зала были возгласы, что нельзя оттяпывать хлеб бизнес-консультантов, это их поляна и незачем IT-шникам туда лезть. Но зал докладчика в целом поддерживал.»
У Макса к каждому докладу – заметки. К этому докладу их много и довольно интересные.

Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО
Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. Цепков отмечает, что «в целом все правильно, просто для меня — очевидно, ситуация нечетких требований, которые надо выявлять и уточнять — типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать».
Сам Александр доволен конференцией, его презентацию можно скачать, предварительно получив пароль доступа Вдогону конференции Александр написал пост “Место под солнцем или размышления об аналитиках, архитекторах и тест-дизайнерах…” На взгляд С. Кадомского, «информации было слишком много для 45-минутного доклада, и воспринимать данные с той скоростью, с которой они подавались, мне было тяжело. Несмотря на это, доклад оставил очень приятные впечатления и добавил несколько монет в мою копилку знаний аналитика».

Якима Александр. Lean: Эффективное управление требованиями
Анонсированное содержание:

• Как управлять очередями требований и что означает закон Литтла
• Разница между пользовательскими историями и MMF
• Управление требованиями в Канбан
• Время такта/цикла/доставки и приоритеты требований в очереди
• Как использовать (а не бороться) с неизбежно нарастающей сложностью системы
• Как балансировать входной поток требований и загрузку команды
• Структура требований при масштабировании разработки

Докладчик — украинец, но сейчас работает в Индии, Германии, США. Продуктовая разработка, в компании десятки-сотни команд. По отзыву Максима: «Хороший рассказ, но негладкий по речи и до Книберга ему далеко. Поскольку я хорошо представляю процесс, то, как мне кажется, понял и оценил содержимое доклада. Однако, по отзывам других слушателей, они эти мысли не уловили, на мой взгляд — как раз из-за сумбурности изложения». – и много заметок.
Однако и С. Кадомский «уверен, что докладчику удалось убедить слушателей, что приведенные им методики управления требованиями позволяют эффективно применять гибкие методологии разработки даже на больших и сложных проектах».
Блог Александра  - много докладов на разные темы проектирования.

Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков
Анонсированное содержание:
Что такое система квалификации? Актуальность создания. Зачем она нужна: для компании, для аналитиков, для остальных?
История создания. Что было до? Первая проба: подход, результат, плюсы и минусы, почему отказались. Вторая проба: подход, результат, почему сработало.
История внедрения. Как планировалось? Как было на самом деле? Трудности и подводные камни. Выводы.
Как она должна работать и как работает? Как аналитики (и остальные) должны были ей пользоваться? Что действительно происходило после внедрения? Какие трудности и подводные камни? Выводы.
Планы на будущее. Обратная связь внутри компании. Сбор внешнего мнения и новой информации (другие компании, IIBA и т.д.). Периодическое обновление системы.
В декабре 2010г Ю.Веденин разместил у себя в блоге подробные соображения: Как производить оценку трудозатрат . Цепков: «Вполне понятный рассказ о формальной системе. Правда 5 уровней при 10 аналитиках, причем высшая не заполнена — как-то этого чересчур, по-моему. А еще — система совсем свежая, 3 месяца. По ней еще не нанимали внешних людей. Так что пионерский доклад в этом смысле. Но — они сделали, договорились с руководством, начальную оценку получили — повод для доклада есть. И он не стесняясь говорит, что система новая, и многое впереди. Мы сами это делали на первом этапе работы с разрядами, и сейчас в сторону большой формализации не копаем, а используем как повод для разговора — а они пока копают именно в формальную часть. Но это может быть уместно в их компании».

Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания
Анонсированное Содержание:
В этом докладе рассматривается работа с требованиями на примере проекта разработки коммерческого (тиражного, «полу-коробочного») программного продукта для западной софтверной Компании.
Что это, и зачем оно нужно?
В конце 2009-го года, мы начали работу по созданию принципиально новой версии программного продукта в области обработки неструктурированных данных, для европейской софтверной Компании.
В процессе работы, была использована короткоитерационная модель организации процесса, включая работу с требованиями.
Итерация закончена, сейчас мы заняты уже следующим этапом разработки.
Вот этим опытом и хотелось бы поделиться.
Специфика продуктовой модели;
Продуктовая модель имеет отличия от рядового аутсорсинга, что накладывает отпечаток и на организацию процесса.
Так, в ряде случаев клиент не имеет возможности описать детальные и подробные требования, особенно на начальном этапе.
Если масштаб продукта и размер команды позволяет, в этом случае хорошо работают короткоитерационные методики, с промежуточными деливери и ревью.
То же касается и работы с требованиями, которые более не являются статическими, а меняются и прирастают в процессе работы.
Подробные требования vs high-level vision – где компромисс?
На самом деле, истина находится где-то между этими крайностями.
Требования должны обрисовывать хотя бы тезисно, основные функции и юс кейсы, которые должна предоставлять система.
Причем не всегда хорошо иметь более подробные требования – см ниже.
Уточнение и «развитие» требований в процессе разработки – плюсы и минусы;
Этот путь позволяет решить ряд вопросов лучше, чем это мог бы изначально придумать самый умный и толковый аналитик.
Минус : сложно указать точный дедлайн без соблюдения определенных правил и договоренностей. Стабильность и предсказуемость также более низкие.
Инициатива «снизу», или идеи команды/разработчиков;
“Wear customer hat”, командное продуктовое мышление, фокус-группы, и обратная связь – вот ключевые факторы успеха.
Нужно, чтобы люди не боялись высказывать мнение и предлагать идеи.
Само собой, что прежде чем включить их в скоуп, зачастую нужно получить аппрувал от клиента/того, кто платит.
Риски подхода, и управление ими. Компромиссы;
Размывается треугольник «объем работы – сроки – качество» (точнее, он становится гибким).
При планировании требуется больше времени закладывать в резерв.
Нужны четкие договоренности с клиентом о plan reviews, и сохранении реалистичного скоупа (даже, и особенно, если в какой-то момент его придется «резать»).
Результаты.
Кратко – таким способом часто получается не совсем то, что думали в начале
Но! Это всегда классные конкурентоспособные продукты.
Так получилось и в нашем случае.
Цепков: «Основная идея доклада — работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile — быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным.»

Горенко Ольга. Интерфейс бизнес-целей “Доклад был очень креативный, а зал – переполнен.  Доклад был о том, как выяснять у заказчика цели для проектирования хороших интерфейсов. И вообще о технике интервью с сотрудниками заказчика. В частности, они обязательно спрашивают, чем человек занимаются, и часто из ответов соседи сотрудника по комнате узнают много нового и интересного. А для хороших интерфейсов надо представлять бизнес-цели, как пользователя интерфейса, так и – если есть маркетинговая нагрузка – то цели заказчика интерфейса. Все это с конкретными примерами, основанными на реальных сайтах”.

Остальные прослушанные доклады Максим Цепков оценил как «приличные». (заметки тоже есть к большинству докладов).

Бондаренко Мария. Управление требованиями в условиях неопределенности
Некоторый общий ликбез. Опыт явно присутствует, но где-то на заднем плане, излагается обезличено, с высоким уровнем абстракции, однако соотнесения с мировым опытом нет. Меня лично не вдохновляет подход работы с требованиями мелкой россыпью, а доклад был об этом.
Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании
Лекция. Ровная. Скорее по чужим учебникам. Слайды отсутствуют… Народу было интересно, и докладчик, наверное, разбирается в материале, но все это можно прочитать в книгах, и лучше — у того же Книберга.
Сайт Тимофея (и Марии).
Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде
Какие-то известные вещи из книг про коммуникации. Например, что надо комбинировать слух и визуальный канал. Виды восприятия и прочее. Аудиал-визуал и т. п. Для меня — все знакомо и достаточно очевидно, я даже подумал, может, слышал их на другой конференции — нет, не слышал.
(С. Кадомский тоже этот доклад слушал: «доклад хоть и сначала и заинтересовал меня своей актуальностью, но, к сожалению, не оправдал надежд».)
Материалы авторов: http://cmcons.com/, http://anovichkov.msk.ru/ http://infiniti-gk.livejournal.com/
Erasmus Michiel The Real World Business Analyst
Рассказ весьма не по делу. С детства и со школы, и об этом долго… Это не для начинающих бизнес-аналитиков, а для школьников, …
Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов
Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формальной форме, в результате — овладел предметной областью лучше многих специалистов заказчика. Но в этом для меня ничего особо удивительного — хороший аналитик так или иначе овладеет предметной областью, с которой он работает. А вот про то, что знаниями предметной области овладел кто-то другой, базируясь на его описании — в докладе не было. Равно как и о том, что его сложной формальной системой пользовался кто-то из заказчиков. Так что есть сильное ощущение, что все это было системой одного человека-автора.
Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я допускаю такое только при реализации силами неквалифицированных кодеров по низкоуровневым постановкам — то есть не на современных языках, которые не допускают неквалифицированных кодеров ввиду сложности заложенных концепций.
Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией — очень творчески перерабатывает термины, работает почти по своими.
Зато в целом в докладе был достаточно хороший обзор истории развития практики usecase, это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. А Якобсон его не оценил, сказав лишь, что «подход Коберна не противоречит его подходу». Классическая книга по usecase, признанная Якобсоном очень хорошей — Битнер и Спенсер (2002), также игнорирует новое от Коберна. А книга Коберна (2000) — очень тяжелая, поэтому ее не слишком читают. Вот так.
Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует — насколько легко взаимодействовать со Сбером и госзаказчиками и т. п.
Зезин Василий. Онтологический взгляд на инженерию требований
Докладчик — из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.

От компании CustIS выступал Михаил Заборов, но Цепков на его докладе не был. По отзывам, принимали хорошо.
Доклад назывался: «Заказная разработка.Системная архитектура вместо требований»
На похожую тему Михаил делал доклад Большие проекты в Agile (AgileDays-Екатеринбург-2010)» – Как правильная архитектура позволяет сделать большие проекты в Agile.
Его (видео в 2 вариантах и слайды можно посмотреть здесь.

 Про круглый стол на тему “Детализация требований. Что? Где? Когда?”, где в роли экспертов выступали Александр Байкин (Автомир, Москва), Михаил Заборов (CustIS, Москва), Александр Якима, а также англоговорящие гости мероприятия Адриан Рид, Пол Тёрнер и Михель Эразмус, мнения в отчетах также разделились:
С. Кадомский: «… круглый стол прошел в непринужденной обстановке на русском и английском языках, при непосредственном участии аудитории в обсуждении. Тема была детально обсуждена, в том числе с точки зрения гибких методологий разработки и с учетом психологии заказчиков, разработчиков и других вовлеченных в проекты лиц. Лейтмотив обсуждения: “Классифицируйте пользователей вашей спецификации на группы (бизнес овнеры/ пользователи/ разработчики/ тестировщики) и детализируйте требования в объеме, необходимом и достаточном для каждой группы”.
М. Цепков: «Не очень удалось с круглым столом. Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений — не было. Так что тайм боксинг на круглых столах и запрет монологов — критично».

Остались пока «за бортом» доклады: Рыжанкова Наталья Управление командой аналитиков. Развитие аналитика, Кумсков Михаил Процессы и люди, Лапыгин Дмитрий Работа с требованиями в небольших командах – Agile подход от IBM Rational, Зарецкий Алексей Испытание боем. Влияние политических реалий проекта на процесс управления требованиями, Елена Голубенко, Петр Лобода Бизнес-анализ в сфере телекоммуникаций.

Дополнение: 13 апреля

Оказывается еще 26 марта был отзыв Николая  Войнова:

“…все прошло довольно хорошо – активно, весело, иногда задиристо. Но ощущение осталось немного странное. От конференции обычно ожидаешь чего-то нового, неожиданного; структурируешь и по новому осознаешь некоторые известные темы;  уходишь с новыми идеями. Но ничего из этого не случилось…”

 

Entry filed under: Бизнес/аналитик, Конференции, Обзоры. Tags: .