Содержание

Общие впечатления

25.03 в Киеве прошла конференция Req Labs 2011. Если кратко выразить мое впечатление о конференции, то она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек. Сами залы, кроме «Зимнего сада», не слишком удобны — вытянуты, а экран не очень большой. Перерывы сделаны достаточно грамотно.

Доклады — достаточно хорошие. Хотя я лично в докладах ничего существенно нового не услышал, основной массе участников было интересно их слушать. А еще лично я очень скептически отношусь к работе с требованиями мелкой россыпью, в которой многие работают, и это тоже повлияло на оценки. Но на моих впечатлениях, которые будут дальше, это скажется — получается, что я оценивал не столько содержание доклада, сколько форму его подачи. И много докладов было представлено в хорошей форме, во всяком случае практически на всех слотах мне было кого слушать.

От нашей компании выступал Миша Заборов, но я на его докладе я не был - решил, что лучше послушаю других. По отзывам, принимали хорошо.

Не очень удалось с круглым столом. Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений — не было. Так что тайм боксинг на круглых столах и запрет монологов — критично.

А в целом, организаторы и программный постарались и им спасибо.

Замечательные доклады

Это — доклады, которые мне понравились и формой и содержанием. Их, естественно, не слишком много.

Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения

Этот доклад мне понравился больше всего, поэтому я и поставил его первым. Докладчик — достаточно харизматичный человек, а сам доклад был о том, что не надо сотворять кумира из любой методологии.

Я слушал не сначала, и такую цель в явной формулировке не услышал. А услышал прилично подтвержденные тезисы, касающиеся конкретных методологий, о том, что они не работают. Но в провокационной форме с сильным преувеличением — следы этого есть в заметках далее. И у меня периодически создавалось впечатление, что докладчик видит методологию поверхностно — которое во многих случаях оказывалось неверным там где начиналось детальное рассмотрение.

Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи — предлагалось проектирование по бизнес-целям, и заявленное в названии доклада. Думаю, именно потому. что погружаться в бизнес-область до уровня понимания и бизнес-целей и способов их достижения больше всего не любят. Более того, из зала были возгласы, что нельзя оттяпывать хлеб бизнес-консультантов, это их поляна и незачем IT-шникам туда лезть. Но зал докладчика в целом поддерживал.

Далее — заметки.

Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО

Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. Я: В целом все правильно, просто для меня — очевидно, ситуация нечетких требований, которые надо выявлять и уточнять — типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать.

Далее — заметки.

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

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

Далее — заметки.

Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков

Вполне понятный рассказ о формальной системе. Правда 5 уровней при 10 аналитиков, причем высшая не заполнена — как-то этого чересчур, по-моему. А еще — система совсем свежая, 3 месяца. По ней еще не нанимали внешних людей. Так что пионерский доклад в этом смысле. Но — они сделали, договорились с руководством, начальную оценку получили — повод для доклада есть. И он не стесняясь говорит, что система новая, и многое впереди. Мы сами это делали на первом этапе работы с разрядами, и сейчас в сторону большой формализации не копаем, а используем как повод для разговора — а они пока копают именно в формальную часть. Но это может быть уместно в их компании.

Далее — заметки.

Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания

Основная идея доклада — работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile — быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным.

Далее — заметки.

Turner Paul The Evolving role of the Business Analyst

Живой и экспрессивный рассказ, с выражением. Но, к сожалению, в том темпе английского, когда я не успевают рефлексировать. Поэтому записи бедны…

Горенко Ольга. Интерфейс бизнес-целей

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

Остальные доклады

Большинство докладов можно было оценить как приличные. Одни я слушал все, другие — частично. Потому что когда не было замечательного доклада, то я старался побывать на всех трех треках.

Бондаренко Мария. Управление требованиями в условиях неопределенности

Некоторый общий ликбез. Опыт явно присутствует, но где-то на заднем плане, излагается обезличено, с высоким уровнем абстракции, однако соотнесения с мировым опытом нет. Меня лично не вдохновляет подход работы с требованиями мелкой россыпью, а доклад был об этом.

Далее — заметки.

Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании

Лекция. Ровная. Скорее по чужим учебникам. Слайды отсутствуют… Народу было интересно, и докладчик, наверное, разбирается в материале, но все это можно прочитать в книгах, и лучше — у того же Книберга. Может быть, я не досидел до того места, где пошел личный опыт.

Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers

Речь как журчание ручейка. В целом все правильно, но без вдохновения… Может быть, я пристрастен — потому что язык чужой, и для понимания нужно больше энергии, чем для доклада на русском — соответственно, требования для меня выше.

Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде

Какие-то известные вещи из книг про коммуникации. Например, что надо комбинировать слух и визуальный канал. Виды восприятия и прочее. Аудиал-визуал и т. п. Для меня — все знакомо и достаточно очевидно, я даже подумал, может, слышал их на другой конференции — нет, не слышал.

Erasmus Michiel The Real World Business Analyst

Рассказ весьма не по делу. С детства и со школы, и об этом долго… Это не для начинающих бизнес-аналитиков, а для школьников, по-моему… Я ушел достаточно быстро, а резюме тех, кто слушал до конца, потому что стеснялся вылезать из полного зала — на начало доклада пришли очень многие: «Докладчик родился в южной африке и делился трудным детством без компов. Сейчас приехал в Голландию и работает бизнес-аналитиком, и ему хорошо 0 о чем он и рассказывал».

Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов

Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формлаьной форме, в результате — овладел предметной областью лучше многих специалистов заказчика. Но в этом для меня ничего особо удивительного — хороший аналитик так или иначе овладеет предметной областью, с которой он работает. А вот про то, что знаниями предметной области овладел кто-то другой, базируясь на его описании — в докладе не было. Равно как и о том, что его сложной формальной системой пользовался кто-то из заказчиков. Так что есть сильное ощущение, что все это было системой одного человека-автора.

Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я допускаю такое только при реализации силами неквалифицированных кодеров по низкоуровневым постановкам — то есть не на современных языках, которые не допускают неквалифицированных кодеров ввиду сложности заложенных концепций.

Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией — очень творчески перерабатывает термины, работает почти по своими.

Зато в целом в докладе был достаточно хороший обзор истории развития практики usecase, это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. А Якобсон его не оценил, сказав лишь, что «подход Коберна не противоречит его подходу». Классическая книга по usecase, признанная Якобсоном очень хорошей — Битнер и Спенсер (2002), также игнорирует новое от Коберна. А книга Коберна (2000) — очень тяжелая, поэтому ее не слишком читают. Вот так.

Далее — заметки.

Тут я выходил на другой доклад…

Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета

В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует — насколько легко взаимодействовать со Сбером и госзаказчиками и т. п.

Далее — заметки — не с начала.

Зезин Василий. Онтологический взгляд на инженерию требований

Докладчик — из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.

Далее — заметки.