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

В различных дискуссиях о применении в компании наставничества (менторинга) я часто наблюдаю, что наставничество рассматривается строго, как синоним слова «обучение», вследствие чего считается применимым исключительно к новичкам в компании или профессии.
На деле же, наставничество куда более мощный инструмент, который может использоваться для достижения различных целей и решения широкого круга задач – от повышения квалификации персонала (в том числе "точечной"), развития позитивного отношения к работе и лояльности к компании, до сокращения длительности адаптационного периода и экономии времени руководителей.
Мне посчастливилось поработать в компаниях с разным подходом к наставничеству, побывать и подопечным, и, собственно, наставником, поэтому с удовольствием поделюсь собственным опытом и взглядами.
В ходе доклада поговорим о том:
- как может быть выстроена система наставничества;
- какие цели и задачи может преследовать;
- какую непоправимую пользу наносить;
- какие требования могут выдвигаться к наставникам;
- как поддерживать дальнейшее развитие сотрудников, прошедших период наставничества.
Если вы задаётесь вопросом, нужно ли организовывать систему наставничества в вашей компании - приходите за аргументами в пользу и за практическими советами.
Также, доклад будет интересен и новичкам, которые увидят реальные примеры существования подобных программ, как таковых, и смогут в дальнейшем обращать на это внимание при поиске работы.

Слабонервным и начинающим аналитикам просьба не читать дальше … 

Хотя я сам выступал несколько раз с темой перспектив развития дисциплины Бизнес и Системного Анализа, все указывает на то, что все очень серьезно. Проектная парадигма больна и достаточно давно. 

“Заказчик всегда просит не то что он хочет,
а хочет, всегда не то, что ему нужно”

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

В конце 2020 года IIBA выпустило брошюру в которой, просто,  открытым текстом написано: “большинство компаний переходят на продуктовую модель разработки”,”давайте посмотрим что из BABOK может вам пригодится”...  Это говорит о том,  что в тренд исхода с проектной парадигмы на продуктовую охватил позднее большинство. Что особенно удручает,  что с точки зрения IIBA полезного  нашлось немного. В рамках доклада рассмотрим плюсы и минусы перехода предлагаемого IIBA  и здоровую альтернативу “психбольнице”.

Я - тимлид быстрорастущей группы системных аналитиков в Lamoda. За последний год мы выросли в 3 раза с 3 системных аналитиков до 9. За это время я была на 60+ собеседованиях, в процессе которых я знакомлюсь с разными системными и бизнес аналитиками, а также подходами к системному анализу в разных компаниях.
Я работаю в системном анализе 10 лет. 5 лет работала в ЛАНИТ на проектах ЕМИАС, с проектами РСА (единая база ОСАГО, электронный ОСАГО, бюро страховых историй), ЦБ, крупных банков.
Вторые 5 лет я работаю в Lamoda. В Lamoda помогала запускать новые сервисы, связанные с различными методами оплаты, рефакторила процесс возврата денежных средств, запускали систему доставки в Казахстане и многое другое.
Сейчас занимаюсь развитием нашего отдела и немного проектной деятельностью.
В личной жизни обожаю проводить время с дочкой и мужем. Люблю искусство в любом его проявлении и спорт.

Опыт спикера:
2 доклада внутри Lamoda (ссылки кидать не могу),
1 доклад в 2020 году на конференциях Knoleadge conf и ЛАФ:
https://knowledgeconf.ru/2020/abstracts/6758
https://conf.uml2.ru/index.php?all_classes&class_id=kak-pisat-kachestvennyi-tekst

1. интервьюировать заказчика
2. выявлять требования к решению
3. применять продуктовый подход (или нет)
4. презентовать концепцию решения заказчику

1. Знакомство с правилами игры. Вы узнаете правила игры и познакомитесь с помощником, который будет сопровождать и поддерживать вашу команду во время игрового проекта.
2. Интервью с заказчиком. Каждая команда по очереди проведет интервью с заказчиком и получит ответы на заданные вопросы.
3. Анализ требований и хотелок. После интервью у команды будет время на анализ полученной информации и разработку границ проекта.
4. Проектирование решения. Концепция, а может быть сразу ТЗ? Все в ваших руках.
5. Документирование решения. Способ документирования выбирает команда. Разрешены даже комиксы. Никаких ГОСТов, но, если хочется, то и их тоже можно.
6. Подготовка к презентации и представление результатов. У команды будет время подготовиться, организовать встречу с заказчиком и рассказать о своем решении.

А так же, заданий на скорость, силу, ловкость и сообразительность. Обратная связь от заказчика гарантируется!

Будет организована запись на эстафету. Количество мест ограничено. Для участия вы можете собрать команду заранее или объединиться перед стартом.

Аналитическая мастерская с щепоткой рефлексии — 1.5 часа
 

Аннотация

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

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

 

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

Спойлер — на утюге можно жарить яичницу, но предназначен он для глажки белья) Так и с техниками. Пример, не надо ждать от блока помодорро результатов для творческих и исследовательских задач, потому что нельзя сказать мозгу «вот тебе 3 раза по 25 минут, быстренько выдай гениальную идею, а то мне пора переходить к следующей задаче».

 

Что вас ждет:

1. Индивидуальная работа со списком дел и рефлексия.
2. Групповые активности по разбору техник тайм-менеджмента.
3. Теплая, ламповая поддержка и понимание :-)
4. Составленный план дел на следующую неделю.

 

Предварительная подготовка. Эти материалы только для вас. Мне или всем их показывать не надо. Но они помогут понять вам, где и что пошло не так:

1. Будет отлично, если вы придете с перечнем дел за последние 3-7 дней в хронологическом порядке. Учитывайте все, даже «полистал ленту фейсбука», «почистил зубы» и «поставил задачу в джира».
2. Напишите, что за последнюю неделю вы хотели успеть сделать, но не успели. Или чем недовольны — просчитались в оценке, забыли, недоделали.

Существует пять универсальных требований, применимых к любым информационным системам, работающим с большими данными. За 20 минут посмотрим, что это за требования, почему они не важны пока данные «маленькие», но стремительно поднимаются в приоритете с переходом к парадигме Big Data. Аналитики, осваивающие работу с Big Data, смогут добавить их в свой чек-лист для проверки полноты требований. А опытным специалистам, работающим с большими массивами данных не первый год, будет любопытно узнать, что бета-версия этого набора требований была сформулирована еще в Древнем Риме.

Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся.
Всё то же самое применимо и в Agile, но там есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов.

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

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

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

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

Я покажу быстрые, грязные и дешевые инструменты визуализации, выявления и анализа требований для таких ситуаций.
Среди них:
- Бизнес канвас
- Карты и эскизы процессов
- Двумерный мапинг историй
- Карты влияния (Impact mapping)
- Изображение системного ландшафта и архитектуры в стиле 4Context
- CQRS и другие паттерны, дополняющие и заменяющие CRUD+
- Сценарии или диаграммы взаимодействия для систем и компонентов

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

В докладе будет обзор использования ГОСТ-ов 2.105, 34.603, 34.602.

Многие считают ГОСТ-ы полной ерундой. Пусть считают.

Я вот не умею пилотировать вертолет. Значит я должен считать, что они не могут летать? Что это полная ерунда? Но они летают. Это очень неожиданно. А ничего, что пилотированию надо учить? И без этого они не летают. А еще их надо заправлять топливом. Внезапно, без этого они тоже не летают.

С ГОСТ-ами ровно тоже самое. Это великолепные инструменты. Просто их использованию надо учить. И тогда они позволят вам "летать". Например, они позволяют резко повысить точность расчета продолжительности проекта, точность расчета бюджета проекта. Допустить меньше переделок после выхода в эксплуатацию, уменьшить стресс и переработки проектной команды. И, наконец, уменьшить число мата со стороны заказчика.

Сказка? Вовсе нет. Просто кроме UML, BPML, ER и прочего аналитик должен еще знать и владеть правилами оформления текста и создания структуры аналитической документации. Это резко снижает риск что нибудь пропусть.

Кто-то спросит, а какже юзерстори? Коллеги, юзерстори это про ПО. А ГОСТ-ы это про системы. Совершенно другой зверь. Это как болонка рядом с кавказкой овчаркой. И никто вам не мешает использовать юзерстори как один из разделов ТЗ по 34.602. А 2.105 резко снижает вариации в большом коллективе. "Все дело в уменьшении вариаций" говорил великий Деминг.

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

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

В чем аналитики, разработчики, тимлиды и руководители проектов выиграют, если станут думать об интерфейсах как системные инженеры?

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

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

Я расскажу вам о плюсах коронавируса. А именно — о том, какие проекты появились в нашей компании благодаря эпидемии.
"Доктор на работе" — это интернет-платформа для врачей. Как вы знаете, три последних месяца медики активно спасали жизни пациентов от ковида. Мы, как IT-компания, помогали врачам информационно: предоставляли свежие данные и регламенты лечения, связывали с волонтёрами и даже создали мемориальный проект в память погибших медработников. Сориентироваться в быстро меняющейся обстановке и сделать верный прогноз было непросто, это стало одной из ключевых сложностей.
О том, как мы решали проблемы, и подробнее о проектах с точки зрения аналитики я расскажу вам в докладе.