1. Дорожная карта сертификации
2. Основные документы
3. Аспекты сертификации
4. Сложности и как их преодолеть
5. Практические кейсы

 Двое докладчиков.

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что аналитик не до конца выдавил из заказчика и стейкхолдеров все требования, оставив множество умолчаний ("как нет этой функции? а мы думали, она будет! разве о ней нужно было отдельно говорить?")

Я расскажу и покажу техники, позволяющие задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, и обсудить нужность этих требований и их приоритеты заранее, а не при сдаче-приемке. Как правило, после применения всех техник объем требований и юзкейсов для обсуждения возрастает в 1.5-2 раза.

Возможно, многие техники вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

Вот некоторые техники (только названия!): анализ именованных сущностей, расширенные матрицы CRUD, контекстный анализ/user centered design, анализ жизненного цикла и т.д.

Аннотация

Что может быть общего у нескольких десятков аналитиков, разбросанных по проектам большой компании? Как быстрее и легче понимать другу друга при передаче требований, работая в разных командах, с разными процессами, продуктами и потребностями в компетенциях?

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

План доклада

Контекст

Имеется отдел системного анализа численностью около 100 человек. Аналитики распределены по проектам компании. При этом проекты имеют совершенно разные черты, потребности, особенности и т.п.

Есть проекты продуктовые (и продукты тоже сильно отличаются по рынкам или устройствам, на которые ориентированы), есть внутренние продукты или компоненты, есть сервисы внутренние и облачные.

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

Проблема

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

Мы часто по-разному понимаем одни и те же процессы или регламенты, которым должны следовать (эффект ложного консенсуса, известный в социальной психологии)

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

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

Если все это помножить на динамику происходящего:

• На появление новых людей, новых инструментов, новых проектов
• Изменение процессов
• Развитие предметной области

То проблема оказывается довольно серьезной. Хотя конечно почти никогда не выглядит острой или срочной.

Решение

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

В первую очередь мы выбирали формат мероприятия. Рассматривали варианты «электронного вестника отдела» или внутренней конференции, но отложили. Первый, потому что писем (особенно длинных) никто не читает, второй как слишком трудозатратный как для организатора, так и для докладчиков.

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

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

Процесс воплощения выглядел так:

1. Самореклама. Мы ходили к сотрудникам отдела, рассказывали про инициативу, спрашивали, какие темы будут интересны, кто хочет участвовать и т.д. Естественно на этом шаге мы встретили определенный скепсис, однако небольшая подборка тем и вопросов собралась.
    
2. На ее основе мы составили опросник, который был разослан по всему отделу. Цель опросника состояла в том, чтобы выяснить популярность тем, выявить фокус группы, которые будут участвовать в мероприятиях по конкретным темам, а также собрать новые темы, которые людям пришли в голову после нашего очного обхода. Так и получилось.
    
3. По результатам опроса мы выявили темы-лидеры, сопоставили с имеющимися кандидатами в докладчики, у которых уже были какие-то отправные материалы, с того и начали.
    
4. Собственно, организация, подготовка, проведение и фасилитация мероприятия.
   В зависимости от темы мы пробовали различные форматы:
   1. Дискуссионный клуб на небольшое количество людей (не более 12 чел). На таком мероприятии удобно обменяться действующими практиками двум командам, сравнить свое понимание схожих процессов разными командами или обсудить, что мы имеем в виду под одними терминами
      Дискуссия – инструмент превращения неявного опытного знания отдельных людей, больше похожего на мнение, в общее знание отдела, которое можно материализовать в процесс, практику и транслировать на отдел.
       
   2. Доклад с сессией вопросов и ответов. На такое мероприятие можно позвать больше народу, но такое мероприятие требует подготовки и экспертизы от докладчиков. Такое мероприятие отлично подходит чтобы задать вопросы эксперту, собрать в единую картину взаимодополняющие знания нескольких людей, или просто рассказать впечатления от посещения конференции.

В ряде случаев одной теме приходится посвящать целую серию мероприятий.
 

5. После мероприятия – обязательно опрос для получения обратной связи. Оказалось, что такие мероприятия довольно востребованы и положительно оцениваются участниками.
    
6. Для распространения материалов мероприятий я веду небольшой сайт на портале отдела. К таким материалам относятся презентации, повестки и минутки встреч, выявленные темы и вопросы для последующих встреч.

Достоинства, недостатки, границы применимости

Достоинства

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

Трудности (недостатков пока не выявили)

• Довольно сложно обосновать руководству нужность/ценность на начальном этапе развития идеи.
• Нужен очень мотивированный драйвер (им оказалась я)
• Активность требует времени и ресурсов от организатора, докладчиков и слушателей.
• Есть ли граница между обменом опытом и обычным обучением?
• Пока нет понимания как наиболее эффективно сохранять результаты сессий по обмену опытом для последующего использования.

Как преодолевать трудности:

• По модели Кано это скорее «привлекательная характеристика» или «задача ублажитель», отсутствие которой не приводит к явному негативу. Зато наличие дает позитив, что было видно в опросах сотрудников ближе к концу года.
  • для инициации активности нужен прецедент факапа, вызванного непониманием, или набор вопросов/проблем
  • в процессе нужно обязательно обеспечивать видимость результатов и обеспечивать обратную связь (материалы, опросы, предпринятые действия по результатам)
• Чем можно замотивировать драйвера? Для меня лично эта активность оказалась
  • Незаменимой площадкой для тренировки навыков презентации и фасилитации, что пригождается в повседневной работе аналитика.
  • шансом удовлетворить любопытство, что же происходит в других проектах
  • Возможностью сопоставить свое мнение и способы работы с другими аналитиками
  • Способом познакомиться и пообщаться с большим количеством интересных людей в отделе, с которыми я раньше не сталкивалась, или научиться лучше понимать тех, с кем сталкиваюсь в межпроектных активностях.
  • Тема для дискуссии с аудиторией: что замотивировало бы вас?

• Как разумно расходовать ресурсы?
  • Встречи для фокусных групп, отобранных на основании предварительных опросов или инициативы самих сотрудников
  • Поддержка руководителей групп, которые могут помочь с подбором и мотивацией докладчиков (отдельное спасибо Ирине Суровой, благодарности Марине Вовк и Мише Герберу)
• Формат фокусного взаимообучения между аналитиками с большим опытом, которых часто трудно удивить чем-то новеньким в профессии.
  • Можно проиллюстрировать на популярной модели T-person: как легко расширять свой поверхностный кругозор, но как трудно найти того, кто поможет расширить и углубить свою глубокую экспертизу
  • Тема для дискуссии с аудиторией: как углубить свои узкоспециальные познания? Что если эти познания специфичны для отрасли/компании? (интернет хорошо помогает расширить поверхностные, а вот с углублением – все гораздо труднее).
• можно обсудить статью Shindler, Eppler 2003 о вариантах фиксации и систематизации опыта.
  • Тема для дискуссии с аудиторией: есть ли какая-то подобная практика у вас?

Итоги:

Обмен опытом это:

1. Общение с коллегами и руководством, выявление проблем, превращение неявного знания в явное, обмен профессиональными мнениями и новостями.
2. Возможность повышения квалификации даже для опытных аналитиков за счет фокусного отбора участников
3. один из форматов кросс проектной коммуникации, командообразования.
4. А еще источник тем для конференции J

Это воркшоп на 2.5-3 часа. Раз на прошлом ЛАФе он выиграл приз зрительских симпатий, то почему бы его и не повторить (:

Расскажу о принципах успешных компаний, которые не конкурируют в кровавом море, а находят свою нишу на просторах голубого океана.

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

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

В докладе будут раскрыты следующие темы:

1. Отличие кровавого моря от голубого океана

2. Метод разработки стратегии голубого океана

3. Методы выхода за привычные границы рынка

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

Поговорим о том, как можно помочь команде выявить ошибки, до того как она их совершит. (Доклад/ Мастер-класс)

На круглом столе поговорим о планировании работ аналитиков, об оценке трудозатрат, сроках выполнения.

Как Вы расчитываете трудозатраты? Как определяете сроки выполнения? Есть ли методики расчета или используете экспертные оценки? Какова необходимая точность расчетов? Что делаете, если работы растягиваются, сроки нарушаются, возникают дополнительные работы?

Почему аналитики не любят оценку трудозатрат? Почему не любим указать сроки? Можно ли превратить оценку трудозатрат и сроков из дамоклова меча в помощника?

Рассмотрим наиболее распространенные методики оценки трудозатрат. И поделюсь успешным опытом (около 10 лет) планирования работ аналитиков. 

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

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

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

Я расскажу про эволюцию методов прогнозирования (сценарии, форсайт, имитационное моделирование), поговорим о сейчас и о будущем. Также я затрону тему инструментов аналитика в свете быстро наступающего будущего.

Это игра-симуляция, позволяющая испытать на себе процесс Behaviour-Driven Development и научиться использовать язык Gherkin для спецификации целевого поведения своих программных продуктов. В основе симуляции лежит фабула фантастического фильма «День независимости» и элементы одной из самых сложных и интересных командных настольных игр «Космическая тревога» (Space Alert).

Многим знакома ситуация, когда в команде аналитиков появляется тим-лид, который и как аналитик - профессионал, и управляет в соответствии с умными книжками, а работа команды не спорится. Или ситуация, когда аналитиками начинает рулить менеджер с большим управленческим опытом, но не аналитик, а работа команды все равно не спорится. В своем докладе я расскажу:

• Что не так с управлением в обеих этих ситуациях.

• Что такое недирективное управление.

• Когда эффективно использовать недирективный подход.

• Какие навыки и инструменты нужны.

• Как эти же навыки применять в других сферах: наставничестве, работе с заказчиком, да и просто в повседневном общении.

Доклад рассчитан на слушателей c любым опытом и ролью, но наиболее полезен может быть тим-лидам, руководителям отделов аналитики, руководителям проектов.

Анализируя отклики зрителей на вебинар «Одиннадцать простых фишек BPMN-моделирования» (2015), вопросы, звучащие в ходе тренингов, и личный проектный опыт, нам удалось идентифицировать, описать и систематизировать джентельменский набор шаблонов (паттернов) моделирования на языке BPMN 2. Актуальность запроса практикующих аналитиков на каталог шаблонов обусловлена отсутствием в русскоязычном сегменте Сети какой бы то ни было эталонной библиотеки типовых «строительных блоков», аналогичной каталогам GoF, GRASP или PoEAA для программной архитектуры; немногочисленные же попытки создания аналогичного каталога англоязычными специалистами малоизвестны и подчас содержат откровенно спорные результаты.

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

Каждый шаблон, сборник которых мы хотели бы вынести на суд участников ЛАФ, будет проиллюстрирован фрагментом BPMN-модели, а также нашим видением его ограничений и преимуществ. По окончании мастер-класса (1,5 часа) возможно продолжение обсуждения материала в формате barcamp’а.

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

• Коммуникация на проекте внутри команды. Как удовлетворить требованиям заказчика и не поссориться с командой разработки.

• Работа с заинтересованными лицами. Выявление и работа с возможными заинтересованными лицами проекта.

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

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

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

Совместно с Николаем Фатеевым (Игротехник) . 

Продолжительность 2-3 часа.

Как показала практика работа со стратегией требует стратегического мышления. Одного знания понятий и рынка недостаточно для того чтобы эффективно работать с целями.

Игра задумана как  легкая среда для изучения и понимания закономерностей по работе с трендами и развитию продуктов. 

В работе будут использованы актуальные тренды. Остальное пока секрет.

Желающим играть в эту игру просьба записаться