AnalystDays-1

В пятницу был на первой конференции аналитиков AnalystDays в Минске. Конференция определенно удалась. Было более 250 участников, 4 трека и многие из них очень интересны, а залы — переполнены. Так что я думаю, что за первой конференцией последуют другие, конференция AnalystDays продолжит работу.

Отдельной фишкой был начатый ремонт во втором зале, о котором организаторов просто поставили перед фактом. И предложили замену — шатер во дворе. С погодой — повезло, поэтому он оказался, скорее, фишкой, чем неудобством. Хотя Саша Байкин, который докладывал там первым, пострадал сильно — как оказалось, проектор там не виден совершенно, и приходилось делать доклад фактически без слайдов, переключая их для записи. Между слотами вместо проектора поставили телевизор, так что Дима Безуглый читал уже с приемлемым показом слайдов.

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

Начну я с докладов Ани Рид и Вали Ломаевой из нашей компании, CUSTIS. В обоих основной темой является DDD (domain driven design), но под совершенно разными углами зрения. Аня — HR и она рассказывала, как связаны практики DDD и развитие аналитика, включая набор персонала, начальное погружение в проект и процесс дальнейшего развития. Аня очень волновалась, потому что когда HR рассказывает аналитикам о методике их профессиональной деятельности — можно ожидать всяких сюрпризов. В общем-то волнение ее отчасти подвело — доделывая презентацию перед самым докладом она переписала на комп конференции не последнюю версию, но обнаружила это только в середине доклада. Несмотря на это, в целом доклад, на мой взгляд, удался и вызвал интерес. А Валя рассказывала об опыте применения DDD для работы с требованиями на примере конкретного крупного проекта для Росатома в условиях постоянного и изначально заложенного в проект их активного изменения из-за параллельно выполняющейся доработки законодательной и нормативной базы. Идея — показать, как применяя DDD можно вселить в заказчика уверенность, что разрабатываемая система удовлетворит их требованиям, даже в условиях, когда эти требования с определенностью неясны, а имеются только общие представления или многие варианты решений и бизнес-процессов, которые лишь предстоит согласовать. Если я Вас заинтересовал — смотрите видео.

Дальше хочется отметить доклад Пола Тернера The impact of Systems Thinking on the Business Analyst role. Пол говорил о ментальных моделях и о мышлении. О тех изменениях, которые меняют верхнеуровневую картину системы и потому подлежат особому контролю. О малых решениях из локальной оптимизации, за которые приходится платить большую цену, потому что они ломают цельность. К сожалению, на мой взгляд, в докладе не хватает более конкретных примеров, потому что на уровне слов и общеизвестных историй про слепых, осматривающих слона это понятно, а в практике, тем не менее, возникают проблемы. Однако, я по своему опыту знаю, как сложно такие реальные примеры делать — потому что для понимания они часто требуют большого контекста из конкретного проекта, а его у аудитории, естественно, нет

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

А после обеда Пол Тернер и Адриан Рид проводили большой мастер-класс Practical Techniques for early use in BA cycle на 4 слота. У меня получилось быть маленьком кусочке и надеюсь, что посмотрю запись полностью. Они рассказывали большое количество техник, по которым группы последовательно шли по разным проектам, выполняя задания. Среди них: PESTLE analysis; five forces analysis; MOST; Resource audit; SWOT analysis; kind business problem — actualy, risk, opportunity; способы визуальной работы над решением проблем — rich picture, mind map, fishbow; работа со stakeholder в зависимости от их роли… И это — сильно неполный список.

Дальше пойдем по порядку докладов.

Вадим Мустяца, Deeplace. Живые вики как оперативные базы знаний. Рассказ был основан на опыте внедрения на конкретном большом проекте вики как системы ведения материалов. При этом докладчик пришел на проект, которому было уже два года, и получил на входе файловое хранилище документов различного качества и слабой систематизации, и задачу — закрыть аналитику и сделать еще 160 отчетов. Он поставил использование rizzoma.com, которая тогда была еще google wave. В докладе Вадим не просто рассказал об использовании, он сопоставил вики с общим контентом верхнего уровня — онтологию представления знаний. А вот сопоставления с другими вики-системами и практиками их использования — нет. Это определенный недостаток для тех, кто этого контекста не знает — потому что по ряду пунктов будет смещенное знание. Но для итого, кто контекст представляет, такой взгляд показывает неожиданные грани предмета. Как пример такого взгляда — вики как месседжер, что достигается через совместное редактирование.

Оксана Сергеева, EPAM. Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий (мастер-класс). Я заглядывал кусочками, зал мастер-класса был переполнен. Основная мысль была очень правильная — процесс управления должен быть адекватен потребностям конкретного проекта, и процессы могут быть сильно различны, в то время как на практике об этом задумываются редко, менеджеры предпочитают использовать знакомые процессы. Но вот позиционирование практики в теорию — оно забавно: «возьмем итеративный процесс, например RUP». Ему противостоит Agile, о котором сказано «наверное, доморощенный», и без деталей «каждый проект что-то свое придумывал». С моей точки зрения, это — еще одно свидетельство того, что практики — не слишком склонны разбираться в тонкостях теории, применяя слова как мемы, за которыми стоит не определение, а набор ярлыков-ассоциаций. Это явление хорошо известно по массовому сознанию и, собственно, мемы и являются способом управления современным обществом (доклад Дмитрия Пескова на KM Russia-2011), и оно же работает в профессиональной среде.

Юлия Михайлова, EPAM. Записки аналитика: как бежать впереди паровоза и не попасть под него. Хорошая и понятная success story с выводами. Аналитик доказывал нужность и роль — на входе его воспринимали как технического писателя, по опыту предыдущих аналитиков. А проект — большой, с внешним большим заказчиком, у которого некоторые фичи не имеют единого владельца. Контент мне лично понятный, но наверняка очень полезный для людей с меньшим опытом, и не только начинающих.

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

Николай Киреев, ИИТ БГУИР. Практический анализ по RUP (мастер-класс) Сюда я тоже зашел на маленький кусочек, и зал тоже был переполнен. На примере конкретного проекта докладчик рассказывал, как проводить анализ, создавая модель из обычного текстового описания, получаемого из заказчиков. Как правильно классифицировать сущности, отличать важное от неважного в контексте конкретного проекта, избегая, например, излишне подробного атрибутного описания, не соответствующего роли объекта, а это типичная ошибка. Целевой рамкой модели выступала модель с точки зрения RUP и, с моей точки зрения, в этом есть определенный недостаток — потому что RUP-модель сама по себе сложна и многообразно, и требует хорошего владения. Но все равно, конкретные примеры анализа с примерами — они ценны и, думаю, не только для начинающих аналитиков, но и для более опытных.

Денис Гобов, Арт-мастер. Выстраиваем процесс управления требованиями. Перед организацией стояла вполне конкретная задача — выстроить свою систему управления требованиями таким образом, чтобы проходить аудит соответствия CMMI и RMM-6. И они сделали систему управления требованиями на базе Jira, которая это обеспечивала? выдавая нужные отчеты с трассировкой и детализацией. О которой и было рассказано в докладе. Очень полезно для тех. перед кем стоит задача сертификации, но и остальным может быть интересно потому что управление на основе интегральных показателей из системы ведения дел — в любом случае актуальная задача и опыт — полезен.

Денис Бесков, Школа Системного Анализа. Управление требованиями VS Разработка требований. Принципы и инструменты Основная мысль доклада состояла в том, что управление требованиями, в отличие от их разработки, является не аналитической, а менеджерской задачей. Потому что включает вопросы границ проекта, а это бюджет, scope против денег. И вопрос релизов, приоритеты требований — тоже связаны с управленческими согласованиями. Поэтому когда управление требованиями полностью передают аналитикам без соответствующих полномочий, оно не работает. Хотя аналитическая часть работы безусловно присутствует.

Александр Кондаков. Оценивания по CMMI как… источник вдохновения. Неожиданно интересный доклад, что не предвещалось ни названием, ни аннотацией. Он наполнен историями, с которыми автор сталкивался, проводя оценки по CMMI и gap-анализ перед оценкой. О том, почему не делают те или иные практики: некогда, работу делать надо; у нас люди умные — им не надо учиться. О том, какие практик обычно есть и в каком виде. О результатах хорошей оценки, которая обычно стимулирует реальный рост компании, а не просто выдает гору бумаг. А еще — о графике роста профессионала-аналитика и новой интересной позиции CPO, Chief Process Officer, которая появилась недавно.

Екатерина Макаренко, TEAM International. Техники аналитика — CATWOE, H-METHOD, MOSCOW, SQUARE. Начало доклада я пропустил, а зря. Екатерина рассказывала о большом количестве конкретных методов аналитика, которые, собственно, перечислены в названии доклада. Например, MOSCOW, который по ее опыту позволил обеспечить реальную приоретизацию требований в контексте релизов. А SQUARE представляет собой фреймворк для требований по безопасности, который позволяет перевести эти требования в разряд функциональных. Эта часть рассказа была на примере конкретного проекта, который изначально был сделан вообще без требований по безопасности, а потом оказалось что они есть и жесткие, проект — банковский. Что ценно — это не методика, а фреймворк, имеющий шаблоны и поддерживающие средства, что позволяет пользоваться даже новичками, набираясь опыта. А еще в методе есть довольно много практик, которые применимы не только к требованиям по безопасности, а могут использоваться для других видов требований. А еще — был рассказ про способ трейсинга требований и их изменений по функциям, причем в условиях. когда за время развития проекта было использовано несколько вики-систем и систем ведения дел, и там были конкретные приемчики, сильно облегчающие работу. Например, при изменениях не только ссылаться в новом деле на предыдущее, но и цитировать формулировки — чтобы поиск это подхватывал.

На этом — все. Впечатления от Минска — в личном блоге.