2012-06-25: ЛАФ-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 Оба рассказа были приняты хорошо, темы были актуальны и вызвали много вопросов и обсуждений.

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

Do you want to try some new features? By joining the beta, you will get access to experimental features, at the risk of encountering bugs and issues.

Ок Нет, спасибо

Доклады

Хочется отметить доклад Константина Быченкова "Цели проекта. Что? Зачем? Как?". Которые часто пишут невнятно, а они представляют собой важный и юридически значимый раздел документа, содержание которого может сильно аукнуться при сдаче. Особенно для государственного заказчика, потому как согласно ГОСТ 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 фактов. Когда мы идем логикой, мы в малом решении.

На этом - все.


[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.