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

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

10.04.2011 at 01:31 1 комментарий

Конференция прошла в Киеве 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: Бизнес/аналитик, Конференции, Обзоры.