2016-06-21: ЛАФ-2016 - много позитива и новых мыслей

Короткая ссылка: LAF-2016

Ссылки сюда (4) →

О других конференциях

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

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

Фото Ирины Скрыпник

И я зову присоединяться - приезжайте, окунитесь в эту атмосферу. ЛАФ будет развиваться - в конце второго дня провели ретро в формате World Cafe с профессиональной фасилитацией Ирины Скрыпник, которая заодно была представлена участникам в виде практического инструмента. И организаторы учтут порожденные идеи в следующих фестивалях.

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

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

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

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

Инструменты аналитика

User Story Canvas. Макс Гапонов

Макс рассказывал шаблон (Canvas), в который стоит укладывать мутные, слабо определенные пользовательские истории или просто области требований для того, чтобы их структурировать и разобраться. А так же структурировать совещания и обсуждения.

Конструкция основана на 3C - Card - Conversation - Confirmation (критерии приемки), предложенных Ron Jeffries для User Storyб которые Jeff Patton дополнил еще двумя Construction и Consequences.

Состав User Story Canvas - записан со слов, реально надо смотреть презентацию, когда она будет.

• Кто вовлечен
  • Ключевая персона - пользователь
  • Консультанты - эксперты вокруг истории, включая коллег, решавших аналогичное
  • Заказчики
  • Заинтересованные лица
• Что окружает - контекст
  • Определение потребности. Адресует, почему мы это делаем
  • Контекст использования - что окружает, что делает ДО, что ПОСЛЕ - как используется результат
• Что делаем
  • История - куда копать
  • Критерии приемки - где остановиться
  • Возможные решения (их обычно несколько)
• Реализуемость
  • Ограничения
  • Необходимые данные (реальные данные. которые надо получить)
  • Зависимости с другой функциональностями
• Результат
  • Как будем мерить пользу? (если мы снижаем количество ошибок в бизнес-процессе - как узнаем, что оно снизилось)
  • Обратная связь, как ее будем собирать

Особенности проведения аналитики при разработке мобильных продуктов. Гузель Рахимова

Рассказ о проектировании функционала и UX для мобильных приложениях на двух кейсах сильно разных приложений.

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

Второе - публичное приложение работы с циклами для девушек, ведение дневника самочувствия в течении дня. Фокус-группа девушек и врачей-гинекологов - они заинтересованы, потому что будет история о пациентках, когда они придут. Сравнение с альтернативами. Около 50 уникальных экранов. Фишка - цель, которая может меняться - хочу забеременеть или не хочу.

В обоих случаях - интерактивные прототипы, это непросто и трудоемко, но дает существенный профит. А еще - работа с разными размерами устройств. И был обзор существенных аспектов и инструментария для такой работы.

OMG DMN: язык моделирования решений и бизнес-правил. Алексей Петров

Мастер-класс про новый язык Decision Model and Notation (DMN) от OMG, предназначенный для моделирования процесса принятия решений. Относительно простой формализм из 4 типов элементов, в которые мы втискиваем реальность, чтобы визуально представить ее верхнеуровневую структуру.

Decition model

• Decision Requirement Level
  • DRG - Decision Requirements Graph
• Decision Logic Level
  • Язык FEEL Friendly Enough Expression Language.
    • SFEEL - Simple. Язык записи модели уровня логики.

Графическая нотация.

• Решение - прямоугольник
• Входные данные - прямоугольник со скругленными краями - чтобы полукруги.
• Знания - Прямоугольник с 2 косыми краями. В отличие от входных данных, носят постоянный характер, а не используются для решения - хотя разделение не строгое.
• Лица, источники знаний, или оказывающие влияние на решение - прямоугольник с нижней волнистой границей -

Чтобы иллюстрировать нотацию - строили модель решения приехать на ЛАФ, потом участники делали свои модели.

Мастер-класс. Визуализируй это! Юрий Веденин

Замечательный мастер-класс с конкретными задачами на визуализацию от Юры Веденина. Я заглянул на маленький кусочек, шла практическая работа по визуализации с последовательным нарастанием сложности объектов, при том, что требовалось выдерживать тайминг на задание. Он шел полдня, с утра и до обеда.

Ловушки аналитика на проекте с историей. Екатерина Герт

Рассказ о том, какие ждут аналитика, когда он приходит на проект с историей, и пробует, как должно, принять на себя целостную ответственность за текущее развитие проекта. И что с ними делать.

Нефункциональные требования. Наталья Желнова

Основная ошибка аналитика - подменять нефункциональные требования просто атрибутами качества. Кое-кто (в том числе из Карнеги-Мелон) именно так и делает, в то время как атрибуты качества - лишь часть нефункциональных требований. А помимо их источником служит окружение, среда исполнения; интерфейсы с внешними системами и ограничения, в контексте которых система должна работать. В докладе источники разбираются подробно и с примерами.

Ведение и устройство бизнеса

Борьба за доверие Заказчика. Почему её надо вести? Как её надо вести? Сергей Рассамакин

Теоретическая часть доклада основывалась на книге Стивен Кови младшего о доверии - "Скорость доверия", "Разумное доверие", в которых говорится о Доверии как объекте управления.

Кови делит общества на холодные общества, где договорились о правилах игры, и не нуждаются в налаживании отношений, и теплые - где формальных правил игры нет, и потому необходимо доверие.

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

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

Кови предлагает формулу для учета результативности с учетом доверия. К традиционной формуле "Результат = Стратегия * Исполнение" он добавляет коэффициент доверия и говорит о налоге, меньшем результате при недостатке доверия или дивиденде за счет высокого доверия.

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

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

Но если нужно - то есть практики, которые позволяют это делать. И в выступлении был обзор этих практик. Доверие обеспечивает предсказуемость и надежность взаимодействия. Доверие измеримо, есть модель Д. и М. Рейна. Уровни - контрактное, коммуникационное и компетентностное. Анкета 54 вопроса по формированию доверия и его разрушению. Есть индекс лояльности потребителей (Net Promote Score). И разные другие опросные листы.

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

В выступлении был личный опыт повышения доверия с Заказчиком. 2 трехмесячных итераций, конкретный кейс - и это очень ценно. Цели - понятны

• Привлечение команды к решению важных вопросов по система
• Сокращение сроков согласования оценки (докапывались)
• Наработать собственные навыки и инструменты для работы с доверием

По всем целям били метрики, которыми измерялось продвижение.

Гибкий бизнес и принципы постановки задач для ПО. Дмитрий Безуглый

Название поменялось, было "Гибкий бизнес и системный анализ!? Правильный ответ - Да!". Потому что понятия enterprise-архитектуры и системного анализа будут не слишком популярны, как несущие коннотации неизменно-вечного, статично функционирующего бизнеса.

Ранее компанию строили как долго-функционирующую. Бизнес (Operations) в центре, остальное - вокруг обеспечение, проектным образом, в том числе - внешними консалтерами (например, одни писали стратегию, другие - перестраивали процессы). Это перестало работать из-за непрерывных изменений, такт - 2 месяца. Мы перешли в VUCA-мир, подробнее Дима об этом рассказывал на AnalystDays (мой конспект). Консалтинг так часто не позовешь, да и проекты, когда их одновременно становится много - мешают друг другу.

И теперь возникает вызов: перейти от традиционной run-организации к change-организации, способной на быстрые изменения. И именно об этом вызове говорит Греф. Дмитрий ссылается на статью Марка Розина "Как внедрять инновации и при этом не разрушить бизнес", у того же автора есть книга со знаковым названием "Успех без стратегии.Технологии гибкого менеджмента".

Далее Дима рассказывал про три волны Agile.

1. Agile Teams
2. Agile at Scale
3. Business Agility

Диаграмма была со ссылкой на Тимофей Евграшин Agile в головах и компаниях (v2). Я глянул - презентация очень интересная, а вот видео, увы, нет.

Первая волна практически прошла, и уже не несет ничего нового. Вторая тоже началась давно, и сейчас есть ряд зрелых фреймворков. В презентации - ссылки и более подробное рассмотрение Scaled Agile Framework (SAF), масштабирующего Agile-разработку на большой продукт или даже совокупность больших систем. Схема интересная и многослойная, выделяется уровни Value Stream, Solution, Agile release train и Agile Team, соответствующий первой волне. И, что интересно, Agile на уровне команды по всей компании, в общем-то не является обязательным в зрелом состоянии, однако трансформацию организации необходимо начинать именно с внедрения этого уровня - это обеспечивает ознакомление менеджеров к принципам change-организаций.

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

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

Итого.

• Втягиваем источники изменений
• Продуктовизация, команды по доменным областям
• Digital-единицы

Уровень зрелости процессов постановки задачи. Дмитрий Безуглый

Дима задал две базовых схемы:

• Различение для команды логического (явного, артифицированного), культурного (неявного), и внешнего, который тоже можно разделить на явное и неявное
• Модель уровней зрелости по CMM, которая направлена на обеспечение уверенности достижения результата, устранение непредсказуемости. Отмечу, по методам CMM предполагает, что инструментом повышения зрелости является повышение доли именно логической составляющей процесса, а это вовсе не обязательно так.

А далее было сформулировано, что задачу повышения уровня работы аналитика нельзя рассматривать изолированно. Потому что он работает как коммуникатор между Бизнесом (Заказчиком) и командой, и уровень зрелости надо оценивать для пяти процессов, выстроенных в линейку

• работа бизнеса внутри себя, над собственными изменениями
• взаимодействие бизнеса с ИТ (то есть с аналитиками)
• собственная работа аналитика
• взаимодействие команды с аналитиком, работа с требованиями
• разработка у команды внутри

Уровень зрелости этих процессов не должен слишком отличаться.

Хотя основной материал выдавал Дима, понятийные конструкции не были четко зафиксированы, а наоборот, требовали раскрытия и обсуждения, в котором принимали активное участие Макс Гапонов, Юра Куприянов, я и другие. И целью был синтез введенных схем в целостную конструкцию.

Истории проектов

История одного проекта - построение бизнес анализа с нуля. Татьяна Довгалова

История проекта EPAM Беларусь для одной голландской кабельной компании (кабельное телевидение и т.п.), которая разрабатывает приставки и другое оборудование, 16 стран, 8 вендоров. Начиналось все с запроса на разработку единого стандарта документации. Для 20-50 Product Owner, которые до этого использовали Word. Предложили Confluence + Jira. После перевода первого проекта признан успех и пошло развитие - не только на другие проекты, но и углубление задачи - процесс ведения документации и бэклога, организация процесса в целом. И расширение области использования с ИТ до бизнес-уровня проработки проектов. Первоначально на проекте она была одна, теперь 7 аналитиков, за год 37 командировок в Амстердам, 144 воркшопа. Проект интересный не только своей полезностью, но и тем, что компания-заказчик работает на фронтире отрасли, и ты в проекте - участвуешь в этом движении.

Сбор требований в проектах, где пользователи не настроены действовать добросовестно. Лузгарев Николай

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

В докладе был рассказ о действиях в этих условиях. Логи и анализ данных, выявление нестандартных и неочевидных ситуаций, фактически, ведут реестр обманов со стороны пользователей, разные группировки. Были разные любопытные кейсы, например, обнаруженная необходимость изготовление кальянов как составной части производства грузовиков. Часть кейсов получается устранить административно, но основной массе надо противодействовать на уровне системы. Формы подбираются экспериментально. На той стороне люди - умнее, опытнее и противодействуют. Они делают "нейтрализовать Петровича 245" - и смотрят по косвенным данным, потому что контакта с ними нет.

Волшебное путешествие от аналитика к менеджеру по продукту и обратно. Юрий Куприянов

Совершенно роскошный доклад с визуализацией по Властелину колец (или Хоббиту?) - история Юры в OpenEdu и самого проекта. Он начинал как системный аналитик-проектировщик, которому главный визионер заказал проект продукта - российский EDx. А потом стал Директором по продукту. Хорошие слайды с обязанностям, различение разных групп - Директор по продукту, Менеджер продукта, Менеджер проекта, PO.

А дальше - выяснилось что Продукта - нет, система является Решением и не является Продуктом. Различение этих двух ситуаций. Важнейшее отличие - на пользователей (студентов и препов) - плевать, от них не зависит счастье. Потому что по бизнес-модели 5% в отличие от 40% Coursera, и это - копейки. Будут перенаправлять потоки.

И пошел откат назад к аналитику. Вляпался - потому что бизнес-анализ проведен не был, а проведен он не был - потому что главный визионер его не заказывал, он считал очевидным, что создается именно продукт. А вот другие стейкхолдеры считали иначе.

Игра Аналитик на пивзаводе. Юра Веденин и со-товарищи

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

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

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

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

— Максим Цепков • 04:13, 21 июня 2016 • нет комментариев