Все выступления

Вопрос № 1 для ИТ-компаний - это цифровизация. Цифровизация своей деятельности, цифровизация деятельности своих заказчиков. Огромная доля в этом процессе - это использование электронных документов.Чем принципиально электронный документ отличается от бумажного? Как правильно использовать электронные документы? Почему так важен формат электронного документа? Как обеспечить юридическую значимость электронных документов? Что нового в законодательстве об электронных документах и электронной подписи? Что за зверь такой - машиночитаемая доверенность? Как правильно хранить электронные документы? Эти вопросы встают перед аналитиками в ходе цифровизации, вот и поговорим, какие ответы есть на эти и ряд других вопросов.

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

Личный опыт и анализ опыта коллег дал понимание о не всегда очевидных сложностях процесса адаптации новичков и возможных способах их преодоления.

В докладе мы хотим подчеркнуть важность процесса наставничества как для нового сотрудника, так и для проектной команды и компании в целом. Дать мотивацию для внедрения процесса наставничества даже если руководству это кажется "непроизводительной тратой ресурсов". А также проанализировать некоторые широко распространенные сценарии интеграции новичков. Посмотрим на них со стороны наставника и со стороны новичка. Подумаем, что в этих сценариях хорошего, а что стоит счесть “антипаттернами”.

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

Черные лебеди сменяются друг другом, мы находимся в стремительно изменяющемся мире, где бизнес постоянно должен трансформироваться и адаптироваться к внешним вызовам, чтобы выжить. Глобальная цифровизация затрагивает и профессию аналитика, и нужно вновь задать себе вопрос, а кто же ты такой и каково твое место здесь? Рассмотрим эти вопросы через призму мира данных, допольнительно сделав акцент на ценности и принцапах работы с данными, цифровой нефтью 21 века,  а также о хронофагах.

Как организовать сотрудничество между командой проекта и бизнес-заказчиками? Рассмотрим эту классическую задачу "Дилемма заключённого" через призму теории игр на практике.

Формат мероприятия - командная игра.

1. Основные тезисы:

1.1. Работа с гос. заказчиками:

- особенности работы с гос.заказчиками: как найти подход к каждому

- как не дать бюрократической  машине закатать в асфальт ваши  идеи

- как найти баланс между функциями для пользователя и реализации букв закона

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

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

- почему так нельзя  и чем это закончилось

- о важности документации с самого начального этапа

- особенности работы в парадигме: нельзя ничего трогать, но все должно быть иначе.

2. Целевая аудитория: для аналитиков, руководителей проекта

3. Цель выступления для аудитории: Основная цель данного доклада рассказать об особенностях работы с государственными заказчиками и стейкхолдерами, т.к. сейчас все структуры массово переходят на цифровизацию. Чему может научить опыт работы в такой сфере, какие точки роста он дает и какие подводные камни имеет? Также обсудить навыки ведения переговоров и отстаивания свои личных границ (и границ проекта).

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

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

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

Расскажу про чат-ботов помощников, которых используем в компании.

Не хотите ходить по ссылкам от коллег? Бот пришлет всё самое важное. Нужно развернуть нужный билд на сервере? Просто напишите боту. Хотите узнать нагрузку на приложение, не анализируя большие логи? Бот всё сделает за вас. А еще - избавит  от мелких рутинных задач, которые в сумме занимают час или больше времени. И даже если вы просто хотите поближе узнать коллег, но стесняетесь, бот тоже поможет!

Остановлюсь на том, какой функционал есть в наших ботах:

• Валера — подскажет название статьи, задачи, какие тесты упали, а еще откроет дверь, расскажет, кто сегодня болеет.
• Долорес — развернет нужный билд.
• Марвин — посчитает доступное время команды, отправит статус по релизу, сделает запрос на нужное API и покажет ответ.
• random_lunch — подберет случайную пару на обед.
• secret_santa — поможет с организацией тайного Санты в компании.

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

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

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

Ирина в интерактивной форме раскроет следующие темы:

1. Насколько рациональны все наши решения?

2. Распространенные "когнтивные ловушки" и что нужно знать о принятии решений?

3. Способы обхитрить собственный мозг.

4. Как использовать когнитивные искажения в свою пользу?

5. Принятие решений в стрессе: "тупой и еще тупее"

6. Как достигать целей, используя знания о когнитивных искажениях?

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

Рассказать подробно о том, как правильно и быстро привлечь новых участников проекта с участием более 30 человек

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

1) Как коммуницировать и разделять ответствености с продактом. Как проводить встречи с продактом - на первой встрече знакомстве, на встречах 1-1, на встрече обратной связи.

2) Как работать с беклогом. Что делать аналитику, если пустой беклог или слишком перегруженный или слишком быстро меняем приоритеты. Как в этом случае поможет построение CJM и MVP.

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

На КС обсудим - что случилось с проектированием в разработке ПО и ИС?

Вопросы на КС:

1. Действительно ли так нужны требования, а не проект системы?

2. Кто и как может делать проект системы?

3. Нужны ли индустрии проектировщики?

4. Где взять проектировщиков?

5. Что нужно знать и делать аналитику, чтобы он смог делать проект системы?

• Прокрастинация…
• А нужна ли задача?
• А вдруг подобное уже реализовали?
• Как собрать воедино этот хаос?
• Как вписать в архитектуру?
• Когда, что и с кем согласовывать?
• А что от меня ждут на выходе?

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

Я прошла путь от осознания и принятия выгорания, потом «лечила» это долгим отпуском (5 месяцев). Нашла в себе силы и смыслы вернуться в аналитику и уже полгода работаю в команде мечты, контролирую свое состояние. 

Поговорим о том, всем ли подходит этот вариант «лечения», как к нему подготовиться, чем можно заняться и как потом вернуться к работе.

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

Поделимся опытом оптимизации и повышения эффективности в команде за счет развития своих навыков по модели T-Shaped.

На примере задач расскажем какие навыки и инструменты полезны системному аналитику. Также рассмотрим возможное участие аналитика в смежных ролях. Приведем преимущества такого подхода для специалиста и команды в целом.

Содокладчик: Любовь Кислова

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

Перед выступлением будет полезно ознакомится с текстом https://habr.com/ru/post/529236/ или видео https://youtu.be/TbDnSQbMGjg  о ценности, создаваемом ИТ аналитиком для бизнеса.

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

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

В основном мы будем говорить о заказной разработке.

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

Как проводить UX тестирование? На какие моменты обратить внимание? Об этом я расскажу в своём докладе.

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

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

На мастер-классе не будет теории.

1. Сначала мы разомнемся и выполним комплекс упражнений, которые включат ваш мозг в работу. Будет немного шумно и весело.

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

3. Освоим технологию, позволяющую очень быстро прорабатывать текстовую информацию.

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

Продолжительность 1.5.ч

Баттл с Сергеем Мартыненко про техники проверки требований.

Тезисы Сергея:

В кровавом энтерпрайзе есть задача — настроить загрузку данных из одной информационной системы в другую. Например, вы работаете в банке, и к хранилищу данных постоянно подключаются новые источники — личный кабинет, CRM, MDM, АБС и т.д.

Эта задача может легко превратиться в кромешный ад для всех участников. Например, бизнес ждет данные в онлайне, а у источника нет API для его передачи и идут регулярные пакетные загрузки. Результат – интеграция тормозит или вообще не реализуется, задача бизнеса не решена.

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

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

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

Доклад основывается на практическом опыте работы в роли системного аналитика на примере пилотного проекта по “распилу” монолита на микросервисы .