Опыт имитационного моделирования бизнес-процессов методом системной динамики

Скачайте презентацию доклада

Статья здесь:
/kcfinder/upload/files/%20%D0%B8%D0%BC%D0%B8%D1%82%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2%20%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BC%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D0%BE%D0%B9%20%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D0%BA%D0%B8.pdf

Всем привет!

За время своей 15-летней проектной деятельности, работала как в роли Аналитика на стороне Исполнителя, так и в роли Аналитика на стороне Заказчика. Должность - одинаковая. Цели и задачи разные =)

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

Приходите! До встречи на ЛАФ ;)

Просматривая вакансии системных аналитиков, мы все чаще видим востребованность аналитиков, имеющих опыт работы или понимание REST API.
Но что такое REST? О чем думает разработчик, архитектор или другой аналитик, когда говорит: "REST-сервис" или "API"? Как связаны REST и HTTP? На докладе мы разберемся с терминологической путаницей, чтобы лучше понимать коллег и говорить на понятном им языке.

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

P.S. Обратите внимание, что мы не будем разбирать, что такое POST, PUT, GET, и как правильно их использовать;)

Только практика, только хардкор!

 

Основная задача, которую пытаются решить компании в части автоматизации договорных процессов: «Как сделать подписание по EDI частью процесса заключения договора?».

 

За выделенные 40 минут поделюсь с вами опытом проектирования интеграции между системами EDI (ЭДО) разных провайдеров и корпоративной системой заключения договоров. Основные вопросы, подводные камни, схемы взаимодействия.

 

Также готовьте свои вопросы, постараюсь ответить по максимуму, поскольку тема полна сюрпризов.

Как сделать так, чтобы новичку было все понятно и ясно, а у вас нашлось время, чтобы все рассказать и при этом еще успеть сделать свои текущие задачи? А если таких новичков несколько? А если у вас задач больше, чем обычно?

Расскажу про:

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

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

О спикере:
Вагина Тамара. Текущая позиция - менеджер проектов в комании Сдэк (логистика). Ранее опыт работы на позиции бизнес- и продуктового аналитика в сфере ритейла. Доп. образование - психолог в социальной сфере. С 2018-го года участвую в ЛАФ в качестве участника. Влюблена в мероприятие с первого дня))

О докладе:
Тема - выстраивание коммуникаций с бизнес-заказчиками при отсутствии продуктового подхода. Ситуация, когда от ИТ хотят "всё и завтра", не ведётся учёт трудозатрат, не выполняется оценка выгоды от запуска фичи, а для одной команды около 5-ти разнонаправленных заказчиков. В докладе опираюсь на теорию конфликтологии из соц.психологии.

В своем докладе я хочу рассказать о наставничестве:
1) Кто такие наставники и чем они обычно занимаются?
2) Что отличает хорошего наставника?
3)3 лайфхака для наставника
4) 3 лайфхака для ученика

По времени пока точно не уверена, т.к. не делала пока подробный план с черновой раскладкой в презентации.

Кто для нас заказчик? Бизнес-пользователи, стейкхолдер, или множество людей с противоречащими интересами и запросом к продукту? Или еще интереснее: без конкретного видения, product-owner`a, и дорожной карты, но продукт встал за крепкой спеной Enterprise и все хотят от него чего-то великого.  Хочется сделать, чтобы все эти люди, влияющие на решение, были нашими партнерами, которые понимают важность, цели и имеют взвешенные ожидания.
 

Этот доклад о том, как стараться минимизировать риски: 

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

 

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