Владислав Шелупин. Переход с SAP на 1С. Опять наступаем на те же грабли?

Ограниченный набор решаемых задач и консерватизм мышления часто мешают 1С-программистам выйти за рамки базового функционала и расти как техническим специалистам. Одним из ключевых решений этой проблемы может стать целенаправленное развитие фундаментальных IT-знаний: алгоритмов, паттернов проектирования, смежных технологий и практик. На реальных кейсах рассмотрим, как это расширяет возможности и повышает эффективность, а также определим, для кого такой путь развития критически важен, а кому достаточно стандартных навыков поддержки типовых конфигураций. Доклад в виде статьи: https://infostart.ru/pm/2410072/

Когда нужно сесть и заполнить заявку на доклад, все мысли почему-то пропадают из головы, а всё, что приходит на ум, кажется уже известным и скучным. Расскажем о том, как избежать типичных ошибок начинающих докладчиков. Доклад в виде статьи: https://infostart.ru/pm/2408174/

На многих предприятиях процессы управления качеством входящего сырья до сих пор существует на правах «Золушки» – незаметной, но и незаменимой, которая работает в лучшем случае в Excel, а в худшем – на бумаге. Как понять, что пора переходить от таблиц к автоматизированным системам? И какие подводные камни ждут на этом пути? Разбираемся в докладе. Доклад в виде статьи: https://infostart.ru/1c/articles/2405186/

Разрабатывая открытые решения, мы внимательнее относимся к коду, интерфейсу, документации и оформлению. А изучение чужого кода вдохновляет и открывает новые подходы. Расскажем об опыте создания открытых решений для 1С, ценности open-source и роли сообщества. Доклад в виде статьи: https://infostart.ru/public/2402661/

В разработке программного обеспечения командное взаимодействие играет ключевую роль. Однако многие разработчики скептически относятся к регулярным встречам – дейли-митингам, ретроспективам и другим форматам, считая их пустой тратой времени. Почему же возникает это непонимание? Разбираемся, как сделать встречи действительно полезными для всех участников, и какую роль в этом играет модерация и позиция руководства. Доклад в виде статьи: https://infostart.ru/pm/2401186/

Как реагировать на ошибки сотрудников: наказывать или давать шанс? Стоит ли извиняться за свои ошибки руководителю и как это делать правильно? Как принять и проанализировать ошибки, чтобы двигаться дальше? В этом докладе будет немного теории, практические рекомендации и размышления о том, как превратить ошибки из источника стресса в инструмент развития команды. После просмотра вы, возможно, посмотрите на свои и чужие промахи под другим углом – и даже измените подход к работе и управлению. Доклад в виде статьи: https://infostart.ru/pm/2400435/

Харизма помогает руководителю вдохновлять команду, влиять без давления и выстраивать доверие. Это не врожденное качество, а ресурс, который нужно подпитывать и развивать. Те, кто сможет развить в себе харизму, станут не только уверенными руководителями, но и свободными, по-настоящему счастливыми личностями. Расскажем о том, как харизма руководителя влияет на успешность проекта. Доклад в виде статьи: https://infostart.ru/pm/2387563/

После года интенсивной работы в управленческой базе 1С накапливается большое количество информации. Алчные до анализа аналитики загружают разработчиков 1С большим объемом работ по созданию разных отчетов из базы данных. Это нужно, чтобы получить крупицы «золотой» информации, необходимой для принятия правильного управленческого решения. Как результат, загружены разработчики, нагружено железо, перегружены регистры, чешут голову администраторы по железу..... бюджет поддержки такой системы летит к небесам… Расскажем о том, как выгрузить данные из 1С в BI и передать настройку произвольных отчетов в руки аналитиков и юниор разработчиков, чтобы они сами могли вывести отчеты и взаимосвязи с помощью Yandex datalens. Доклад в виде статьи: https://infostart.ru/pm/2396729/

Как известно, рекомендуемый состав Agile-команды – не более 10 человек. Но что делать, если для разработки продукта нужно больше, или гораздо больше? Scaled Agile Framework (SAFe) помогает в этом случае выстроить взаимодействие между командами. И PI-планирование (от слов Program Increment, а вовсе не Pi – пирог) – это ядро SAFe, когда за короткое время командам нужно состыковать между собой запросы менеджмента, свои возможности, риски и зависимости от других команд. На примере вымышленного продукта рассмотрим, как провести сокращенное PI-планирование. Доклад в виде статьи: https://infostart.ru/pm/2393248/

Как превратить хаос идей в понятный бэклог и совместно с заказчиком выбрать самые приоритетные задачи для реализации в продукте или проекте? Расскажем о практике формирования MVP с помощью User Story Mapping – от первых пользовательских историй до приоритизации релизов. Доклад в виде статьи: https://infostart.ru/pm/2386996/