ЛАФ-2012

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

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

В этом году было еще два сюрприза культурной программы. В первый день — вокальный концерт на площадке Консультанта, который регулярно организует культурные мероприятия, его директор Александр Иванников считает правильным поддерживать культуру. И в этот раз концерт был приурочен к первому дню, чтобы желающие могли послушать. Мне — понравилось. А второй сюрприз — в воскресенье в Малинках совершенно неожиданно выступала болгарская группа кантри-музыки Lilly of the West, которую случайным ветром занесло в российскую провинцию. И тоже было замечательно. Немного подробностей — в личном блоге, а здесь пора рассказать о докладах.

С докладами было несколько накладок, в основном из-за опоздания докладчиков, добирающихся из Москвы на машинах из-за пробок. Одного из них меня попросили заменить и совершенно неожиданно я сам оказался в числе докладчиков. Я рассказывал про Типы личности Майерс-Бриггс, семинар о которых читал в своей компании 2008 году, есть запись http://lib.custis.ru/2008-02-12-types-of-identity. И, забегая несколько вперед, во второй день я рассказывал про командные роль Белбина, тоже по мотивам семинара, который мы проводили в компании совместно с Аней Рид, и запись которого тоже опубликована http://lib.custis.ru/2010-01-19-belbin Оба рассказа были приняты хорошо, темы были актуальны и вызвали много вопросов и обсуждений.

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

Хочется отметить доклад Константина Быченкова «Цели проекта. Что? Зачем? Как?». Которые часто пишут невнятно, а они представляют собой важный и юридически значимый раздел документа, содержание которого может сильно аукнуться при сдаче. Особенно для государственного заказчика, потому как согласно ГОСТ 34.602-89 в разделе «Цели проекта» формулируются цели создания и с ними соотносится результат.

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

Но в обоих случаях — сохраняется общие критерии, которым должна отвечать сама цель — SMART (это PMBOK, Specific Measurement Achievable Realistic Timed). Правда в IT из цели часто исключают Measurement — его обеспечит ПМИ, и Timed — его обеспечит План проекта, но цель должна быть такова, чтобы и ПМИ и План могли быть сделаны. Зато добавляют еще

  • Flexible — гибкая по ходу проекта, среда и политика меняется, цель хочется сохранить
  • Safe — без ущемления наших интересов и интересов заказчика, часто конфликтует с Measurable
  • Valuable — дает конкретную ценность
  • Context — в контексте работы организации и заказчика

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

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

Юрий Химонин и Сергей Нужненко. Эффективность аналитических работ. Как следует из названия, доклад о том, что для аналитических работ надо смотреть на эффективность. А не закапывать пару человеко-лет в написание документации, наличие которой по факту сэкономит каждому из 2-3 человек приходящих на проект в год по одной неделе на включение в работу. Был спектр показателей. за которыми в принципе можно наблюдать — таких как дельта между выпуском релиза и его стабилизацией, число пропущенных или дефектных требований и так далее. Понятно, что наблюдать надо не за всеми, и наблюдение само по себе — ценности не представляет, нужны активные действия на основе наблюдаемых величин. Управление требованиями — менеджерская, а не аналитическая работа, но в ее ходе — надо анализировать показатели для принятия решений. А разработка требований отличается от других работ тем, что в ней может быть большая скрытая часть, а повышение уровня и качества требований, их детализация может сильно влиять на ее стоимость. Соответственно, нужен баланс между качеством и стоимостью. обеспечивающий разумный компромисс. Практически для ведения требований они используют TFS и новые возможности VS, обеспечивающие связь требований с WorkItem.

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

Алексей Смирнов. Реверс-инжиниринг требований в проекте по миграции КИС. Большую систему перетаскивают с PowerBuilder на Web+Java в догоняющем режиме. При этом контакта с бизнесами — нет, документации на старую систему — тоже нет, с разработчиками контакт слабый, а исходной информацией служит преимущественно код. В этих условиях они пришли к построению моделей, которые отражают старую и новую систему, между которыми поддерживается соответствие через требования (по сути есть две модели, реализующие одни и те же требования). При этом артефакты модели старой системы полуавтоматически получается из ее кодов скриптами, и это дает возможность выделить те фрагменты моделей, которые затронуты новым релизом — что важно при догоняющей разработке.

Используют Enterprise Architect — так исторически сложилось. Модель хранится в общей базе, с ней все работают. Широкое применение пакетов для классификации. Представляется с нескольких точек зрения, ориентированных на разных потребителей. Элементы не более, чем соседних уровней на одной диаграмме. Трассировка между уровнями.

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

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

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

Рустем Гайфутдинов. Почему у нас менеджеры прототипируют GUI? Компания Alee Software занимается заказной разработкой для производства — заводы и подобные заказчики. И они пришли тому, что эффективнее всего снимать требования и получать обратную связь через прототипирование интерфейсов. Посмотрев широкий спектр и поиспользовав некоторые они пришли к реализации собственной тулы, GUI machine. Но доклад был не столько про тулу, сколько про метод работы через прототипы интерфейсов, место их в процессе и те результаты. которые такой подход дает. Один из сильных плюсов, кстати — это способ выделиться на этапе коммерческого предложения!

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

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

Денис Бесков. Школа системного Анализа Денис с группой товарищей организовал школу системного анализа, потому как в образовании в России в этом месте — совершенно пусто. И обращение было не столько к потенциальным слушателям, сколько к тем, кто мог бы внести свой вклад в обучение в этом месте. во всяком случае, я так понял.

Александр Байкин. Use cases vs. User stories. Блиц, сравнение двух методов, Use case и User story. Детально и по делу. При этом что выбрать — зависит от проекта, а в обсуждении Ольга Подолина поделилась опытом — у них оба метода дополняют друг друга: простые случаи оформляют как user story, а по сложным делают use case.

Второй день. Второй день сложно пересказывать. потому что обсуждение носило менее структурированный характер, помимо основного флип-чата было несколько групп с независимыми обсуждениями, а перемещение между ними на свежем воздухе не способствовало ведению заметок. Основная ценность в том, что есть возможность предложить свою тему, по которой услышать экспертные мнения и обсуждения. Разбирали кейс, в котором разработчики утверждали, что аналитики им не нужны, потому как все равно все делают сами. Было много рекомендаций по организации работы, по необходимому пиару. Я рассказывал про командные роли Белбина.

Дмитрий Безуглый рассказывал про ведение интервью, его психологическую составляющую. Для начала — задал рамку: Заказчик знает проблему, Разработчик — строит Решение, но Критерии для выбора решения и его приемки — они снова у Заказчика, и это необходимо помнить. И все это надо сформулировать в Problem Statement, Executive summary на полстраницы, который реально писать не очень любят. А интервью — это не просто способ узнать новое, узнать предметную область, это еще и подготовка будущих отношений — почва для эмпатии, способ завоевать доверие. И один шанс у вас есть — потому что когда вы приходите к рядовому сотруднику компании, у вас есть интересная дял него инфа о будущем проекте. А чтобы этим шансом воспользоваться — нужна правильная самопрезентация. В целом презентация кино — это хороший образчик: сначала тизер, фраза-завлекалка «я делаю проект…», на который надо поймать реакцию (Как интересно или Еще один) и подстроиться. Потом — трейлер, нарезка фактов об успехах компании, проекте, и его будущем в том виде, чтобы интервьюируемый понял свое место и отношение в этом будущем. И на трейлер тоже обязательно поймать реакцию, об этом часто забывают, вываливая информацию непрерывным потоком. И это — именно нарезка фактов, а не их логичное стройное изложение. Потому как на все 5 минут, а лучше — быстрее. Можно почитать книжку «Пришел, увидел, победил» — как сценаристам презентовать свои сценарии, это о самопрезентации.

А еще Дима рассказал пару игр для аналитиков. Первая — угадать слово по классифицирующим вопросам, на которые надо отвечать да или нет, но можно критиковать вопрос, если ответ введет в заблуждение. Можно упрощать — задумываешь, что видишь или даешь первую букву. Профессионалу хватает 8-10 вопросов, гуру умудряются опознать слово за 5 вопросов. Во второй игре публика опознала Контакт. В продолжение темы — был выпад против логического мышления. Мозг сознательно держит 7+-2 фактора. Теория тонких срезов говорит что подвал мозга работает до 1000 фактов. Когда мы идем логикой, мы в малом решении.

На этом — все.

 

Добавить комментарий