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

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

Скорость, фокус, результат!

Хочу поговорить о методах выявления ожиданий и требований к несуществующему продукту.

Что делать, если у заказчика есть Идея и... всё. А. Деньги у него тоже есть :)

Откуда черпать вдохновение при описании концепций, требований и ограничений и вот этого всего? Как победить всю эту неопределенность? (Спойлер! У вас есть заказчик и будущие пользователи! ;) )

Аннотация

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

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

План доклада

Контекст

Имеется отдел системного анализа численностью около 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

Воркшоп/мастер-класс : 1.5 часа

Для кого:

Ведущих и главных аналитиков, владельцев продукта, руководителей проектов.

Цель:

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

Структура:

1. Вступление;
2. Представление метода;
3. Имитационная игра с участниками;
4. Разбор результатов с демонстрацией приемов эффективной работы;
5. Моделирование ситуации и самостоятельное применение метода;
6. Рефлексия.

Описание:

В чем проблема?

1. Базы знаний доменных областей отсутствуют, плохо структурированы, не актуализируются или попросту не используются, т.е. их ценность не ясна.
2. Обучение происходит силами сотрудников компании.
3. Запросы на обучение могут не поступать со стороны сотрудника (не знает, что обучение есть, не желает учиться в рамках текущих обязанностей и т.д.)
4. Не у всех компаний есть стратегия по повышению квалификации сотрудников.
5. Существующее внутреннее обучение низкого качества.

Зачем нужен календарь?

У каждой компании/коллектива/команды свои уникальные особенности и трудности по ходу работы над проектами/продуктами. Поэтому не смотря стандартизированные или наработанные подходы (методологии), используемые в той ли иной компании практики, приобретают свою рабочую форму и содержание только в процессе адаптации. Следовательно сотрудники обладают неоднородным опытом и степенью погружённости в работу всех подразделений компании.

Одним из способов обучения и погружения в предметные области является «Календарь непрерывного обучения». Для чего он может быть нужен:

• Пополнение базы знаний проекта/продукта для подготовки учебных курсов корпоративных университетов.
• Адаптация новых сотрудников подразделений.
• Адаптация новых участников команд или формирования контекста в уже существующих командах.
• Для долгих проектов.
• Для демонстрации ценности проекта/продукта.

Почему аналитики/PO?

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

А кто должен заниматься непосредственным обучением?

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

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

Суть метода:

1. Посредством ретроспектив выявлять потребности на уровне: Человек/Процесс/Компания.
2. Управлять календарем непрерывного обучения.
3. Участвовать в организации обучение и MeetUP’ов.
4. Фиксировать результаты встреч/церемоний в базе знаний (WiKi).
5. Использовать WiKi.

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

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

Можно подискутировать на тему, а нужно ли готовить дипломированных аналитиков или вполне достаточно иметь в дипломе любую ИТ-специальность?

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

Основные тезисы доклада: 

• Особенности проектирования медийных продуктов. 
• Что может удержать пользователя в приложении, а что оттолкнуть и навсегда забыть про продукт. 
• Какие бывают технические ограничения, как стоит их учитывать и на что могут повлиять, если закрыть на них глаза. 

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

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

В нашем совместном с Ириной Суровой выступлении мы надеемся выделить моделе-ориентированное мышление в чистом виде, и поговорить о подходах к его обучению. Примерно это же сейчас делает Анатолий Левенчук совместно с рационалистами, выделяя курс "мыслительного фитнеса", основ мышление на моделях как базу для курса системного мышления (https://thpectrum.livejournal.com/3514.html).

По формату, скорее всего, это будет диалог Максима Цепкова и Ирины Суровой у флипчарта с подключением зала. Но в процессе подготовки могут появиться слайды, тогда формат может приблизиться к более традиционному выступлению. Примерная продолжительность - 40 минут.

Длительность - 2 часа.

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

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

Игра-симуляция. Время - 3 часа.

Соведущий - Юлия Смирнова.

"Начальник отдела - это не профессия"

Из разговоров программистов 90-х годов

Кто лучше других аналитиков должен обладать компетенциями отдела?

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

Кто обязан «держать руку на пульсе», знать, предвидеть, предотвращать?

И при этом - оставаться нормальным человеком, понимать, сочувствовать, переживать, помогать, утешать...

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

Формат: Пести у костра

Описание:

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

Управлять доверием важная составляющая работы с людьми, но для управления нужна осознанность.

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

Центральные вопросы:

Как доверие коррелируется с лидерством.

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

Как доверять заинтересованным лицам и коллегам и не получить «нож в спину».

Аннотация

Цель мастер-класса — показать взаимосвязь и «взаимопомощь» модели предметной области, системного и бизнес анализа, выполняемых в визуальной нотации UML (Unified Modeling Language), а также получение радости в ходе тренинга.

            Будут рассмотрены три основных темы:

1. Системный Анализ. Выявления функциональных требований (сценариев использования) к информационной системе на основе запроса заинтересованного лица. Построение UML Use Case (UC) диаграммы.  Структура UC-спецификации: основной и альтернативные потоки. Пред- и пост- условия. -
2. Модель предметной области. Построение на основе запроса заинтересованного лица и ее связь с идентификацией сценариев использования. Построение семейства UML Class диаграмм. Использование CASE инструмента.
3. Бизнес Анализ. Выявления  требований к организации (к бизнес системе), в которой будет внедряться ИС.  Понятие процессного управления. Построение UML Use Case (UC) диаграммы и UML Activity диаграммы.  Выявление «точек автоматизации» в бизнес процессах.

ожидаемая длительность - "одна пара" - 90 минут

            Будет рассмотрено два примера. Первый пример будет разобран по шагам ведущим, а второй - разбирается слушателями как упражнения в группах по 2-3 человека. 

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

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

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

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

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

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

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