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