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

Технология "1С:Предприятие. Элемент" позволяет нам создать приложение которое, по умолчанию, опубликовано в Интернет - не нужно поднимать отдельный сервер, публиковать базу и т.д. Воспользуемся этим и реализуем персонального ассистента, которого можно использовать как из телеграмма, так и из Алисы, голосом.
Рассмотрим все что нужно сделать - создание вебхуков для проброса сообщений, обработка логики, отправка сообщений в бота, ответ голосом в Алисе.
В итоге, можно получать любую информацию из базы не только в текстовом виде, но и "голосом" из любого устройства с Алисой.

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

География проекта:
Сеть аптек "Мелодия Здоровья" - федеральная сеть по всей территории РФ: от Санкт-Петербурга до Владивостока. Более 1200 аптек, более 30 филиалов. 2000 автоматизированных рабочих мест.

Цели:
- Автоматизировать процессы управления инцидентами, запросами, изменениями и активами с применением лучших мировых практикам и рекомендаций ITIL/ITSM
- Внедрить портал самообслуживания для прозрачности услуг и повышения эффективности диспетчеризации (автоматически)
- Автоматизировать смежные службы для управления обращениями

Результаты:
- Улучшили взаимодействия и коммуникации в компании.
- Сделали удобным обращения в сервисные службы компании в рамках единого окна
- Предоставили личный кабинет с детализацией всех заявок
- Появилась возможность расчета трудозатрат и показателей эффективности работы.
- Сократили время обращения исключив ручную диспетчеризацию заявок на 30%
Автоматизированы процессы:
- Управление каталогом и уровнем услуг
- Управление обращениями (инцидентами и запросами на обслуживание)
- Управление задачами
- Управление ИТ-активами и конфигурациями
- Управление изменениями
- Управление релизами

Уникальность проекта:
- Доработали системы для автоматизации бизнес-процессов. Создали системы управления запросами на изменение в рамках Agile подходов и автоматизация работы со спринтами (SCRUM)
- Доработали систему отчетности по показателям
- Доработали системы показателей KPI и интеграцию с 1С КА для расчета заработной платы
- Доработали систему по части SLA с применением подходов ITIL.
- Автоматизировали процессы смежных подразделений (HR, АХО, Бухгалтерия, Управление ассортиментом, НСИ, Юридическая служба)

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

Мы подключили GigaChat в помощь бухгалтеру для обработки платежей в 1С:ERP. Это легко повторить. Расскажу как)
Обсудим возможности технологии и ее ограничения.
Вместе с вами придумаем новые варианты применения языковых моделей в 1С.
Будет интересно.

1. Что значит "сильная" команда.
2. Как определить способности участников команды.
3. Как использовать сильные и слабые стороны участников команды на пользу общего дела.
4. Постановка задач и приемка выполнения работ от команды.
5. Как правильно поощрять и правильно наказывать участников команды.
6. Приемы и "фишки" тимлида команды, используемые в работе.
7. Какая литература помогла мне в становлении тимлида - рекомендации.

Формат: участники работают в командах
Структура сессии:
1. Определение областей применения практик ИТ-аудита. Рассматриваем: бизнес-процессы, система управления, люди (пользователи, исполнители), оборудование, материалы (комплектующие), информация. Участники в командах определяют что должно входить в аудит в каждой области.
2. Описание процесса ИТ-аудита. Участники в командах обмениваются опытом и в формате мозгового штурма определяют типовой процесс ИТ-аудита. По итогам обсуждения вместе с модератором унифицируется процесс. Участники работают с библиотекой практик в качестве подсказок.
3. Описание этапа подготовки к аудиту. Команды готовят карту практик для подготовки к проведению аудиту, предлагают: документационное обеспечение, процедуру согласования, систему управления командой аудита, подход к управлению проектом, основные метрики. Участники работают в специалильном шаблоне для упрощения работы.

1.  Встречи 1:1 как инструмент управления командой – в чем их ценность и результативность.
- подробнее о том, какие цели преследуют встречи 1:1, и как помогают в достижении бизнес-результатов.
2. Опыт внедрения встреч 1:1. Ожидание и реальность.
3. Структурный подход к встречам 1:1.
- как спланировать ход разговора;
- в какой последовательности общаться с сотрудниками и почему;
- как работать с сопротивлением сотрудников.

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

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

Доклад охватывает следующие темы:
- Основные концепции и инструменты Lean, применимые к ИТ-проектам,
- Методы выявления и устранения ключевых видов потерь,
- Практические кейсы применения Lean в реальных ИТ-проектах.

На какие вопросы получит ответ и про какие инструменты узнает участник:
- Как понять, что с вашим процессом разработки что-то не так?
- Какие виды потерь есть в современной ИТ-сфере и как их выявить?
- Как построить карту потока ценности и что это дает (инструмент VSA)?
- Как организовать рабочее место по методике 5S, для оптимизации своей личной работы?

Актуальные регламентирующие документы
Документы, вышедшие в 2024 году и новинки/планы 2025 года
Ответственность по итогу 2024 года и чего боятся в 2025 году
Кому и Что делать обязательно нужно

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

В докладе отвечу на вопросы:
0. Что такое APDEX и чем он будет полезен руководителю?
1. Откуда его брать?
2. Как считать?
3. Что показывает?
4. Как интерпретировать?
5. Можно ли ориентироваться на эту цифру?
6. Подводные камни?

- Чем «лидерство» отличается от «менеджмента». Мой главный в жизни полезный лайфхак «лидерства».
- Принцип «навяжи свою повестку»
- Командный тайм-менеджмент: как ускорить работу и улучшить координацию, не отягощая команду слишком сложными инструментами

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

Сейчас часть компаний находится в ситуации, когда "и хочется, и колется". 
В своем докладе я расскажу:
1.  какие вызовы подвигают к гибким методам.
2. с какими препятствиями сталкивается внедрение в корпоративных командах и какие ментальные ограничения это накладывает на людей
3. что может помочь стартовать гибким методам в жестких структурах?

Работая в IT-компании, мы столкнулись с проблемой отсутствия четких требований со стороны бизнеса. Обычно от нас ожидают, что мы просто сделаем так, чтобы всё работало: "Вы же самые умные, сами знаете, что делать — разберетесь." Знакомо?

Но мы хотим признания и заслуженных дивидендов. Возникает вопрос: за что нам просить и требовать?

В докладе расскажу про наш кейс, где получилось договориться, а где не вышло, а также:

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

2. Примеры реализованных показателей для самых уязвимых сотрудников ИТ — специалистов технической поддержки, системных администраторов и их руководителей. Как мы смогли повысить скорость решения обращений до 20% от SLA, а процент обратной связи — до 75% и предоставив возможность дополнительной мотивации главным системным администраторам, повысили скорость реакции по инцидентам во внерабочее время, что повысило уровень доступности до 97-98%.

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

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

ChatGPT все больше входит в нашу жизнь по обычным бытовым вопросам. Но в связи с появлением высококачественных отечественных on-prem  LLM моделей появилась возможность использовать их в задачах автоматизации бизнеса.
В докладе разберем:
1. Реализованные проекты внедрения с использованием LLM.
2. Варианты применения LLM моделей.
3. Принципы когда применение LLM модели возможно, а когда нет. 

1.Как управление продуктом сделать частью управления? Как определить, какие области управленческих практик потеряны и куда их вставить в общей системе? Участники работают в командах с игровым полем и фишками. Отмечают секторы управления, в которых у них в компаниях "пробелы". Определяем самые спорные и проблемные секторы. Небольшое обсуждение, что с этим делать
2. Описание процесса управления продуктом - матрица продуктовой ответственности. Покажу 4 распространенных моделей управления продуктом (не идеальные) и 1 идеальную. PCM - модель создания продукта как часть проектной деятельности. (*если будем успевать - Конфликт по целям и ресурсам между функциями. Например, как продуктологу поделить маркетолога или главного бухглатера или генерального директора со всеми остальными нуждающимися). Шаблон для заполнения участниками в командах - как на их взгляд должно быть. Обсуждаем, почему так редко бывает.

В этом докладе я поделюсь реальным опытом нагрузочного тестирования сильно кастомизированной системы "1С: Управление торговлей 11" на PostgreSQL 16 для оценки возможности перехода с MS SQL Server.
Что вы узнаете:
- Как подготовить инфраструктуру для нагрузочного стенда
- Методология разработки сценариев нагрузочного тестирования для бизнес-критичных операций
- Особенности миграции данных больших БД
- Реальные кейсы проблем производительности и их решения
- Честное сравнение производительности PostgreSQL и MS SQL Server 2019

Этот доклад будет полезен, если вы:
- Планируете миграцию 1С на PostgreSQL
- Работаете с высоконагруженными системами 1С
- Интересуетесь темой нагрузочного тестирования

Инструменты автоматизации тестирования для 1С:Предприятия 8 силами сообщества развиваются уже больше десяти лет, среди них давно определился лидер, диктующий правила - Vanessa Automation. Но до сих пор эти правила распространяются в формате "мифов и преданий, не высеченных в камне". Между тем, в профильных чатах все регулярно возникают вопросы, есть ли уже готовые стандарты/требования к разработке сценариев проверки поведения на ТурбоГеркине.

Мы в ИТ-Лаборатории Инфостарта проанализировали наиболее популярные и исторически сложившиеся приемы и "лучшие практики" создания сценариев проверки поведения, переосмыслили критерии, предъявляемые сценариям на классическом Gherkin, примерили на свой опыт и на основе этого сформулировали правила разработки сценариев на ТурбоГеркин, которыми хотели бы поделиться с сообществом.

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

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

Платформа 1С прошла несколько этапов развития: 
- где-то давно у нас был "Построитель отчетов", ну как был, он и сейчас есть. И возможно им кто-то пользуется;
- потом нам дали "Схему компоновки данных". И с тех пор никто не помнит как писать отчеты без нее;
- где-то позже появилась "Схема запроса". Страшно подумать, как работал конструктор запросов без нее...
Есть и другие интересные объектные модели, вокруг различных механизмов. Но эти я выделил, как достаточно значимые, он позволили взглянуть "иначе" на привычные объекты.
И вот на дворе без пяти минут как 8.3.30, а может и 8.4 когда-то будет (ведь были такие слухи), а схемы печатной формы по прежнему нет. А я уверен, спросите любого программиста, он вам скажет - "это невозможно". Наверняка то же самое было и с отчетами, и с запросом...

Так вот, конструктор Printwizard на самом деле, это не только завернутые пользовательские инструменты для быстрой, удобной и универсальной разработке печатных форм. Я расскажу что под капотом и во что превращаются печатные формы. Немного затрону тему как я шел к объектной модели, какой инструментарий использовал. И нет, это не рекламный пост о том, что PrintWizard это классный инструмент. Это рассказ о технологиях, решениях и опыте... 

1. История о том, как мы боролись с нехваткой специалистов на первой, второй и третьей линий и открыли для себя продуктовый подход в поддержке и развитии информационных систем;
2. Что такое продуктовая команда;
3. В чем отличии первой, второй и третьей линий поддержки от «продуктовой команды»;
4. Состав и роли Продуктовой команды;
5. Лидер Продуктовой команды – кто он?
6. Как «свести разведенных»? Коммуникации, взаимодействие между ПК.
7. Место главного архитектора при продуктовом подходе и команда интеграции.
8. Супер лидер;
9. Эффективность применения подхода: «ожидания» vs «реальность».

Самое эффективное управление информационной безопасностью - риск-ориентированное. Это мы знаем из университетских курсов и отвечали так на экзаменах. Но как конкретно это применить в практике? 

Разберем в докладе:
1. Базовые термины и принципы управления рисками. 
2. Дашборд принятия решений по управлению рисками и пример работы с ним
3. Примеры принятых решений ИТ-руководителями на основе риск-ориентированного управления и полученный эффект от данных решений в рублях. 

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

1) Почему появление ИИ способсутвет деградации знаний и понимания процессов у джунов
2) Необходимо ли поднимать порог входа в сферу разработки 1С для новеньких? 
3) Почему люди, которые используют ИИ для генерации кода 1С могут быть неэффективными для компании
4) Можно ли использовать ИИ для автоматизации рутинной работы в 1С (в части кода) и не повлечет ли это некоторые риски

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

Большинство людей не справляется с оценкой даже небольших задач. Из-за этого стараемся перестраховываться на 100%, 200 %. Но,   несмотря на это, сроки оказываются неверными. И дедлайн “подкрался незаметно”...

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

Про что я расскажу в своем докладе:

• Как рассчитать оценку времени в условиях высокой неопределенности?
• Принципы адекватной оценки
• Абсолютные и относительные оценки. Planning Poker, декомпозиция.
• Как построить вилочные и точные сметы.
• А если проект “нетиповой”?

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

Команды разработки и поддержки ИТ-услуг обычно сопротивляются ведению и актуализации базы знаний.
Обычный аргумент, не лишенный оснований - нет времени, много задач.
Как сподвигнуть на создание, наполнение - и самое главное - регулярное обновления базы знаний.
Обычный подход - должно приносить пользу самим сотрудникам, быть удобным в каждодневном применении.
1. Выявить потери от дублирования, ошибок, затраты времени на поиск и исследования очевидных вопросов.
2. Выявить неудачный опыт.
3. Совместно с опытными сотрудниками выработать максимально простую процедуру обновления базы знаний.
4. Развернуть простейшее ПО. Давайте посмотрим примеры такого ПО.
5. Минимальные требования к ПО ведения базы знаний
6. Первичное наполнение - используем ТЗ, бэклоги и комментарии
7. Варианты структурирования информации в БЗ, чтобы не превратить ее в "свалку"
8. Вводим KPI на пополнение и проверку статей в базе знаний при выполнении регулярных задач - решение инцидентов, проблем, обновления, изменения.
9. Демо - период. KPI считается, сотрудники информируются, но KPI не применяется.
10. Применяем KPI - элементы принуждения.
11. Теперь мы работаем эффективней! База накоплена, сотрудники сами ощущают пользу - минимизируются ошибки, рутина, выше производительность.
12. Некоторые трюки и "фишки".

Команда - это нечто большее, чем набор индивидуальностей. Всегда хочется набрать себе в команду лучших из лучших. Но если в команде будет 10 Месси, кто будет таскать рояль?
Менеджерский опыт очень похож на тренерский. Не случайно в Англии футбольных тренеров тоже называют менеджерами.
Что важнее, хард или софт скиллы? На что обращать внимание при рассмотрении кандидатов? Я поделюсь своим опытом формирования команды разработки в Т-Банке, расскажу, насколько релевантны сравнения команд разработки со спортивными, и насколько функции тимлида сопоставимы с работой тренера.

В докладе будет рассмотрено применение концепции Zero Trust (ZT) для решения задач кибербезопасности.
Рассмотрим историю и основные принципы концепции, на какие элементы кибербезопасности (силы и средства) воздействует концепция.  
Также посмотрим, как внедрить концепцию ZT в своей организации и какие преимущества она даст, как отделу ИБ, так и организации в целом.

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

• Как при работе с кризисными проектами/направлениями, не уйти в  личный кризис
• Где найти опору, когда нет результатов
• Как быть не затянутым в хаос
• Мои ошибки в управлении кризисными проектами/направлениями
• Как понять, что кризис миновал и наступила эпоха развития…и что дальше…

Интерфейсы уходят, остаются сервера с командными интерфейсами. Это создает дополнительные сложности и временные трудозатраты для рядовых 1С-специалистов, которым привычнее работать с элементами управляемых форм, чем с командами и linux-терминала. Поэтому мы адаптировали Центр администрирования из Корпоративного инструментального пакета (КИП)  так, что теперь одно нажатие кнопки решает задачи, на которые у меня и моих коллег уходило по 2-3 часа. Такое решение помогло нам убрать из связки “аналитик - инженер технической поддержки - технический архитектор” двух последних и пустить аналитика в свободное плавание. 

Пояснение:
Корпоративный инструментальный пакет - набор конфигураций, поставляемых 1С для использования на крупных проектах внедрения.
Центр администрирования - название одной из конфигураций, входящих в КИП.

Расскажу:
– Что умеет Центр администрирования 
– Как внедрить ЦА в вашу работу
– Какие сценарии использования ЦА на практике 
– Какой результат получили от использования ЦА на проекте внедрения ERPУХ+ДО+ТОИР+ТМС 

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

В рамках доклада расскажем о нашем опыте применения ИИ для автоматизации услуг кейтеринга в условиях Крайнего Севере.

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

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

1. Блиц-обзор управленческих навыков. Какие из них можно и нужно тренировать?
2. Опасная и безопасная среда для оттачивания навыка постановки задач.
3. Структура грамотно поставленной задачи (контекст, результат, срок и другие составляющие).
4. Тренируемся вместе: увидим на примерах когда GPT-чат "халтурит", а когда исполняет задачу.

1. Почему это важно:
Любой процесс можно угробить некомпетентными исполнителями. Компании страдают от того, что специалисты с рынка никогда не соответствуют их ожиданиям на 100%. Центры компетенций позволяют минимизировать влияние этой проблемы. 

2. Роль центров компетенций:
Ресурсный центр для команд: определение требований к кандидатам, найм и онбординг, обеспечение готовности сотрудников к выполнению задач, управление компетенции сотрудников на всем жизненном пути.
Хранилище эталонных знаний: создание обучающих программ, проведение обучений, учебные ресурсы.
Процессный офис: стандартизация и унификация процессов, внедрение в команды, контроль метрик, анализ эффективности, работа с командами над оптимизацией.
Исследовательская лаборатория: исследование и внедрение практик и инструментов, обучение сотрудников новым подходам.

3. Преимущества:
Унификация знаний и навыков сотрудников.
Объективная оценка, позволяющая отслеживать профессиональный рост сотрудников. 
Гибкое перераспределение ресурсов между командами.
Единые метрики производственных процессов.
Оптимизация взаимодействия специалистов разного профиля.
Постоянное повышение квалификации через индивидуальные планы развития.

4. Практический пример:
Опыт внедрения центров компетенций в финтехе: результаты, проблемы, перспективы применения в ИТ-компаниях.

5. Для кого доклад:
ИТ-менеджмент, руководители команд разработки, менеджеры по персоналу, директора по процессам, которые заинтересованы в стандартизации процессов, повышении квалификации сотрудников и создании централизованного хранилища знаний.

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

Что такое личный бренд
Важность личного бренда
Ключевые элементы личного бренда
Инструменты для создания личного бренда
Примеры успешных личных брендов в 1С
Стратегии продвижения личного бренда
Риски и вызовы
Заключение

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

Поговорим о процессе разработки на реальных примерах.
Обсудим проблемы использования существующих механик,  познакомимся с альтернативами объектов 1С в ОС Android.
Поразмышляем над ошибками разработки и методах их устранения

1) Мобильная разработка на 1С: отличия, особенности и ограничения
2) Область применения и основные механизмы
3) Разберем "непривычности" для "десктопных" разработчиков
4) Альтернативные механизмы выполнения задач
5) Способы взаимодействия мобильной базы с другими базами
6) Взаимодействие с периферийным оборудованием - наступание на "грабли" и успешный обход препятствий
7) Интерфейс - главные отличия от компьютерной версии
8) И все таки этого 1С не умеет... Что не удалось реализовать средствами 1С и пришлось дописывать "прослойку" в Android Studio.
9) Тенденция изменений мобильной платформы от версии к версии. Что же нас ждет в итоге?

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

Какие правила необходимо соблюдать при разработке расширений.
Как лучше делить расширения и зачем это вообще делать.
Как разрабатывать расширения, чтобы они умели взаимодействовать между собой.
Рассказ опыта взаимодействия более 10 расширений в одной базу (при общем количестве расширений около 30).

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

В докладе расскажу, как искусственный интеллект помогает:

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

А также дам немного теории о больших языковых моделях, Fine-tuning и RAG: особенности технологий, нашей архитектуре работы ИИ-ассистентов, ручной оценке качества работы ИИ, автоматической оценке качества работы ИИ.

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

• основными определениями ИБ
• элементами, на которых строится вся защита
• фундаментальным принципом безопасности "Defence in depth"
• различными классами технических средств защиты

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

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

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

Как устроена сборка продуктов 1С:
- кратко о продуктах
- инструменты разработки (что используем при разработке кроме конфигуратора)
- из чего состоит сборочная линия
- сборка разных продуктов из множества репозиториев и одних и тех же/разных областей кода
(как мы собираем сложные пазлы из кода, переиспользуем одну и ту же область в разных модулях с разным контекстом, переопределяем области) 
- контроль качества кода
- автотесты

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

Расскажу про проблемы и сложности, которые у нас возникли в задачах обновления сложных, больших конфигураций уровня ERP.
Мы прошли долгий и трудный путь. Были сладкие победы, были и неудачи.
В докладе планируем обсудить следующий набор вопросов:

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

- О чем надо подумать, когда планируешь переезд в облако (как получить доступ к 1С, как обновлять, бекапы, печать документов и так далее)
- Почему чаще всего после миграции 1С начинает работать медленнее? (переподписка процессоров и памяти, старое железо, дисковая система не рассчитанная на высокие нагрузки)
- А что делать людям, которым нужна геораспределенная 1С? (такое тоже бывает)
- Почему мы решили строить свое облако для клиентов?
- Экосистема для 1С в облаке - личная мечта, которую реально реализовать

Я расскажу о проекте импортозамещения 1С на примере 1С ЗУП, как у нас проходил проект по миграции с MS SQL на Postgre SQL и с MS Windows на Linux, с какими проблемами мы столкнулись и как решали.

1. Исходные данные:
    - сколько баз 1С ЗУП, их размеры
    - сколько пользователей по разным категориямх (кадровики, расчетчики, аналитики)
    - сколько специалистов 1с это все поддерживает
    
2. Подготовительный этап:
    - аналитика текущей базы данных, оценка возможностей PostgreSQL и минимизация рисков
    - планирование работ по времени и ресурсам
    - техническое планирование нового стека
    - взаимодействие с командой инженеров sre
    - взаимодействие с другими командами (как командами 1с, так и с командами других сервисов)
    - какие были ожидания и требования по проекту

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

4. Выводы:
    - на каких решениях мы в итоге остановились и почему
    - какие советы мы можем дать для проектов импортозамещения 1С ЗУП
    - что стоит учесть при переходе, чтобы не допустить наших ошибок

1 Понятие «Информационная безопасность» (ИБ).
• «Три кита» информационной безопасности – конфиденциальность, целостность, доступность.
• Безопасность – сведение к разумному минимуму потерь конфиденциальности, целостности, доступности.
• Понятие «Риск» и концепция приемлемого уровня риска.
2 Системный подход к информационной безопасности.
• Методы Cyber Security как конкретные инструменты обеспечения информационной безопасности.
• ISMS (Information Security Management System) как система, обеспечивающая интеграцию и совместное применение инструментов Cyber Security на основе менеджмента рисков.
• Основные свойства ISMS: сбалансированность, воспроизводимость, динамичность.
4 Подход к управлению рисками в ISMS (стандарт ISO 27001).
• Концепция PDCA применительно к риск-менеджменту.
• Модель «Актив – Угроза – Уязвимость» для оценки рисков (методика «Галстук-бабочка»).
• Общая структура риск-менеджмента в ISMS.
• Алгоритм управления рисками: Анализ контекста => Идентификация активов => Выявление угроз => Анализ существующих мер управления => Оценка рисков => Решение о необходимости дополнительных мер (план обработки рисков) => Внедрение дополнительных мер => Мониторинг результативности.
5 Приложение А стандарта ISO 27001
• Приложение А – предопределённый набор мер управления (контролей) для минимизации рисков информационной безопасности.
• Связь рисков, методов обработки и контролей в «Положении о применимости» стандарта ISO 27001.
• Необходимость обоснования применимости и неприменимости контролей.
6 Пример управления рисками, инцидент с трояном-шифровальщиком
• Актив – база данных 1С.
• Угорзы: нелояльный персонал; доступ хакетров внутрь периметра; мейл-рассылки вредоносных программ.
• Меры защиты: firewall, антивирус, регламенты действия пользователей, резервное копирование.
• Уязвимость – отсутствие контроля за действиями пользователей, отсутствие проверки целостности резервных копий.
• План обработки рисков: внедрение SIEM системы; увеличение частоты резервного копирования; внедрение инструментов контроля целостности резервных копий.
• Реализация плана и мониторинг результативности мер (отслеживание эволюции риска).
7 Заключение
• ISMS – инструмент оптимизации затрат при обеспечении приемлемого уровня информационной безопасности.

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

В докладе мы поговорим о том как по другому организовать команду проекта, а именно обсудим следующее:

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

И все мы это сделаем на примере проекта имплементации 1С:Корпорации, а в качестве методички - будем использовать SAFe 6.x

1. Какие задачи пробовали решить с помощью GPT моделей?
2. Расскажу какие GPT модели протестировали, приведу сравнительный результат.
3. Важность роли, контекста и требований к выходному результату при работе с генеративными языковыми моделями.
4. Обучение GPT модели, что это дает? Спойлер: попытка создать корпоративную базу знаний.
5. Как интеграция сервиса MAKER и GPT ускоряет разработку требований к программному продукту.

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

В докладе я расскажу:

- Как построить отдел сопровождения с нуля
- Как организовать работу в распределенных и глобальных командах
- Как избегать частых ошибок в построении и управлении командой
- Примеры ITSM не на стандартах, а на реальных кейсах
- Как управлять сервисом при команде более 70 человек (как внутри команды, так и на проекте)
- Итоги и примеры успешных и неудачных проектов по сопровождению и предоставлению услуг

Доклад состоит из двух частей:
1. "Разбор полетов". Мы получили от экспертов отрасли обратную связь по докладу "15 мифов о платформе 1С", перепроверили часть мифов на других исходных данных с помощью иных алгоритмов и готовы представить полученные данные аудитории.
2. "Продолжение". В ходе разбора еще 9 мифов вы узнаете, что работает быстрее - http- или web-сервисы, действительно ли снижается нагрузка на сервер при использовании веб-клиентов, каковы преимущества использования микросервисов в 1С, что лучше: xml или json и почему перепроведение одним сотрудником документов на файловой базе, опубликованной на веб-сервере, подвешивает работу остальных пользователей.
Приходите, будет интересно!

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

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

В работах совмещаем технологии 1С и научную деятельность в сфере ИИ. Некоторые из решенных задач через градиентный бустинг:
- триаж пациентов на плановую операцию сердца; 
- прогнозирование состояния коечного фонда; 
- прогнозирование ухудшения состояния здоровья пациентов с сердечно-сосудистыми заболеваниями; 
- прогнозирование перевода пациента в реанимацию.

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

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

1. Сколько прав доступа ДОСТАТОЧНО, чтобы пользователь увел вашу базу обработкой в 50 строк?
Почему достаточно прав на использование обработок, чтобы все пошло кувырком

2. РИСКОВАТЬ! Нельзя терпеть!
Стандартное поведение бизнеса в условиях аврала и реакция разработчиков.
Подходы, на которые не обращают внимания.

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

4. Где КОРП с профилями безопасности не панацея?
Сильные и слабые стороны профилей КОРПа, где они помогут и где нет, а также:
КОРП и импортозамещение несовместимы?

5. РИСКОВАТЬ нельзя. Терпеть!
SonarQube и его реакция. Почему code-review актуален как никогда.

Все неправильно! Системные администраторы работают в 1С 10 лет.
Базовый функционал сети на аппаратном уровне маршрутизаторов (~1000 IP-устройств). 
Управление инфраструктурой всех IP-устройств из единого флакона 1С: удаленный помощник, Web-интерфейс, доступ устройств в интернет, автоматическая регистрация изменений аппаратной части у клиентов, интеграция с ЗУП...

Когда в проекте сроки доработки постоянно откладываются, команда разработки просит выделить больше времени, возникает логичный вопрос: «А что и в какой момент пошло не так?».

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

Расскажу:

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

Рано или поздно все начинают решать вопросы безопасности  внутри 1С приложений и около них. 
В багаже есть пул кейсов, которыми хочется поделиться.
Попробуем поговорить о безопасности в рамках: 
1. интеграций
2. удаленного доступа к информации внутри 1С
3. журналирования доступа к конфиденциальной информации (методами платформы)
4. цена безопасности в активной фазе разработки
5. цена безопасности по итогам проникновения в контур злонамеренного ИТ-специалиста.

В докладе планирую рассказать:
1. Что такое "сплит обращаемости".
2. Как мы к нему пришли, что нас мотивировало на его использование.
3. Как мы подбирали аналитику для формирования сплита обращаемости.
4. Как убеждали сотрудников, что нужно заполнять новую аналитику для "сплита".
5. Какие мероприятия придумали на основе данных, полученных при анализе сплита обращаемости. 
6. Какой эффект получили (снизилось количество обращений пользователей в helpdesk на 30% + консультанты стали быстрее отрабатывать обращения, что позволило улучшить общие показатели по работе с обращениями, и также снизить количество единиц на поддержку первой линии с 13 до 12 человек, без увеличения нагрузки на остальных) *одну единицу перевели в аналитики, для работы с запросами на развитие системы.

В своем докладе я кратко расскажу о том, как внедрение SAFe® помогло трансформировать подход к управлению проектами и программами в крупном банке, объединив Agile и Lean-практики для поддержки стратегических инициатив и ускорения выпуска продуктов.

1. Что такое SAFe® и зачем он нужен: основные принципы методологии, которые помогают крупным организациям синхронизировать команды, быстрее адаптироваться к изменениям и выпускать качественные продукты.
2. Путь от проектов к Agile Release Trains: организация работы ARTs в банке для управления множеством инициатив и улучшения взаимодействия между командами
3. Практические результаты внедрения: ускорение вывода продуктов на рынок, улучшение клиентского опыта за счет цифровых решений и поддержка стратегических задач через гибкие и прозрачные процессы
4. Реальный кейс запуска Agile Release Train в технической поддержке
5. Инструменты эффективной работы в SAFe®: PI-планирование, метрики производительности и подходы, которые помогают справляться с масштабированием Agile и сложностями управления проектами.

Для кого доклад: руководители, программные и продуктовые менеджеры, Agile-коучи, которым важно узнать о практическом применении SAFe® для синхронизации команд, ускорения работы и повышения гибкости крупных организаций.

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

• Про командное планирование непонятных проектов
• Про исследования рабочих процессов
• Про проведение ретроспектив
• Про построение звёздной карты команды

Переход на Linux и PostgreSQL — серьезный шаг для любой компании! Как избежать падения производительности и сбоев в работе системы? Ключ к успеху — проведение предварительного нагрузочного тестирования.

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

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

2. Подходы к нагрузочному тестированию. Что делать, если система уже стабильна и просто переезжает на новую инфраструктуру? А как быть, если идет внедрение, и система активно разрабатывается? Разберем различные стратегии тестирования для разных этапов проекта.

3. Планирование ресурсов и времени. Сколько специалистов нужно привлечь и сколько времени заложить на проведение? Поделюсь своим опытом и дам практические рекомендации по оптимальному распределению ресурсов.

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

1. Итерационное уточнение образа решения или правильно бегаем кругами между бизнесом и подрядчиком
2. Собираем образ MVP
3. Что подать на вход тендера чтобы потом не было мучительно больно сравнивать оценки между собой
4. Успешный кейс: расскажу как мы перестраивали план проекта "на ходу" чтобы спасти заваливающийся проект
5. Неуспешный кейс: расскажу как по настоянию Заказчика мы жестко следовали плану и требованиям из контракта и что из этого получилось (спойлер - ничего хорошего)
6. Правила хорошего документирования или бойтесь больших документов
7. Успешный кейс: расскажу как мы "на ходу" перестраивали схему документирования и успешно завершили проект

В ходе доклада поделюсь нашим опытом использования СППР при оценках проектов и чем она нам помогает. Опыт вполне может быть применен ин-хаус подразделениями как для оценки внутренних проектов так и для подготовки тендеров.

Что уже произошло. Западные методологии управления ИТ ушли с российского рынка. Сертификация специалистов либо отозвана, либо возможна только за границей. Сертификация и единая оценка функциональных возможностей российского ПО невозможна, в качестве ориентира есть только Реестр отечественного ПО. Аналитические агентства, такие как PinkVerify, Gartner, Forrester и другие закрылись. Нет методологической базы для построения системы оценки зрелости компаний и оценки качества их цифровых услуг. К устранению «зазоров» и противоречий между западными моделями и адаптации их к российским реалиям, добавилась задача развития внутрикорпоративных методологий (свой Agile, TOGAF, ITIL , DAMA). 

 В результате пропадает единая мера знаний для специалистов, размывается мера зрелости для цифровых продуктов и организаций в области ИТ, найм и развитие высококвалифицированных специалистов серьезно усложняется. Сложнее переиспользовать лучшие практики. Нет гармонизированной базы знаний, нужно всё узнавать лично, выверять терминологию, самостоятельно строить единую и согласованную управленческую архитектуру для ИТ. Снижается уровень стандартизации в области ИТ. Тратятся ресурсы на «изобретение велосипеда» и создание общих словарей, теряется динамика развития, растут потери времени и финансов.

Что мы делаем в этой ситуации? В докладе я расскажу как мы разработали архитектуру РИТМа, запустили в работу проект по созданию РИТМа. Расскажу как мы объединяем лучших - лучшие методологи, архитекторы ИТ, практики управления ИТ-услугами и ИТ-процессами в стране, создают материалы в каждой из областей РИТМа . 80+ второв из разных компаний уже работают совместно. Согласуем между собой то, что уже работает , устраняем зазоры и согласуем между собой популярные методологии управления ИТ, дополняем Российскими реалиями, проверяем методы и техники совместно с теми, кто их будет использовать. Раз в квартал месяца собираем Топов ИТ для обсуждения и проверки результатов на стратегических сессиях, убеждаясь в том, что РИТМ реально обеспечивает ценность. 

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

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

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

На основе личного опыта – включая первые шаги в роли тимлида, руководство отделом разработки 1С в крупном ретейле, опыт руководства тимлидами в e-comm компании и возврат к управлению командой – поделюсь реальными кейсами, когда правильный фокус на ключевых аспектах приводил к успеху, а ошибки становились ценными уроками. Присоединяйтесь, если хотите узнать, как успешно пройти путь от новичка до уверенного лидера!

Что такое безопасная конфигурация?
Почему важно писать безопасные конфигурации.
Разбор требований к безопасным конфигурациям.
О модулях с флажком Вызов сервера.
О хранении паролей.
О запуске приложений.
Об исполнении произвольного кода.
О внешних компонентах.

Время руководителей ИТ в компаниях стоит дорого, поэтому тратить его надо пользой.
Из доклада вы узнаете:
- как проводить интервью быстро и эффективно, чтобы удовлетворены остались обе стороны, и руководитель ИТ подразделения не превращался в HR-а;
- как правильно построить взаимодействие, чтобы успеть всё за 1 час;
- как принимать решение о найме;
- что можно получить из собеседований для себя и своей команды.

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

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

Команда любого проекта автоматизации состоит из специалистов и управленцев. При этом, зачастую, руководитель проекта не является прямым тимлидом для каждого участника.
Поговорим в докладе о:
- Может ли быть руководитель проекта тимлидом (пусть и временным) для специалистов команды;
- Должен ли быть руководитель проекта выполнять функции тимлида для специалистов команды;
- Лидерство и наставничество - это про одно и то же или про разное;
- Можно ли завоевать уважение команды при условия отсутствия специфических знаний по предметной области;
- Как выстроить взаимоотношения руководителю проекта с командой, назначенным тимлидом специалиста в команде;
- Как работать с позицией специалиста "Ты РП, что ты можешь в этом понимать?".

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

Рефакторинг — это когда ты улучшаешь код, но не меняешь его поведение. Это как навести порядок в комнате: ты убираешь вещи на свои места, но комната остаётся такой же.
Иногда рефакторинг может пойти не так. Вот несколько ситуаций, когда рефакторинг может навредить:

1. Рефакторинг старого кода. Если не планируем развивать старый код, то менять его не стоит.
2. Рефакторинг непосредственно перед релизом. Мелкие правки могут обернуться большими проблемами. Лучше не рисковать.
3. Рефакторинг ради рефакторинга. Пытаемся усложнить свою жизнь на ровном месте. Потратим время для получения сомнительного эффекта
4. Рефакторинг без тестирования. Поправили небольшую опечатку в имени переменной и полностью сломали расчет себестоимости.
5. Рефакторинг "про запас". Прикрутили к запросу на получение данных кэширование. Сейчас оно не используется. Непонятно, понадобится ли оно в будущем.
6. Выделение похожей функциональности в универсальный мегаметод. Такие методы в перспективе превращаются в монстров Франкенштейнов с костылями в виде бесконечных Если Тогда ИначеЕсли КонецЕсли.

Когда рефакторинг действительно нужен?
  
Из доклада можно узнать, когда рефакторинг нужен, а когда нет. Это поможет избежать ошибок и сделать код лучше.

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

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

Берем раздаточный материал, ручку и создаем себе 1,5 дополнительных часа в сутках.

В рамках интерактивного доклада, мы ответим себе на вопросы:
1. Чем отличаются решения, которые вы принимаете утром и вечером?
2. Как принять сложное решение, когда на него не осталось сил?
3. Какие решения проще вообще не принимать?
4. На каких этапах принятия решения "застреваете" лично вы и чего с  этим сделать?

Я руковожу командой специалистов 1С – разработчики, консультанты, аналитики. Большинство сотрудников работают в удаленном формате из разных городов России. Последние несколько лет я замечаю в нашей сфере тенденцию легкой смены места работы. Это и понятно – для сотрудника при удаленном формате работы, с точки зрения организации труда мало что меняется при смене работодателя. При этом, в нашей компании конкурентная зарплата, есть множество «плюшек» и бонусов. Так почему сотрудники уходят? Наши HR-специалисты провели анализ причин увольнений и выяснили, что большинство можно объединить фразой «не хватало внимания от руководителя».

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

Искусственный интеллект в код-ревью — это не фантастика, а реальность, которая уже сегодня помогает разработчикам улучшать свои проекты. Хотите узнать, как ИИ может автоматически находить баги и предлагать улучшения, экономя ваше время и ресурсы? Тогда этот доклад для вас!

Что обсудим:
    •    Как ИИ помогает выявлять ошибки, улучшать стиль и производительность кода
    •    Популярные инструменты для анализа кода: GitHub Copilot, SonarQube, CodeRabbit
    •    Интеграция ИИ в существующие процессы разработки
    •    Удачные и неудачные примеры проведения ревью кода с помощью ИИ
    •    Преимущества и ограничения ИИ: что может, а что не заменит искусственный интеллект?

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

Доклад будет рассказывать о личном опыте архитектора на примере компании ИЕК. 
Будет представлен в виде концепции "айсберга", где вершина - это самые прозрачные задачи для архитектора (производительность, СУБД, поиск узких мест, блокировки), а под толщей воды находятся все более неявные темы, такие как мониторинг, интеграции, ДевОпс, управление и выстраивание разработки, огромный пул дополнительных инструментов и технологий (S3, Vault, Docker, Grafana, Prometheus, Onescript/1С Исполнитель), особенности работы платформы (Регламентные и фоновые задания, HTTP), а также перечень психологических трудностей как самого архитектора так и всей команды.

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

Доклад продемонстрирует путь систематизации и внедрения подходов разработки, мониторинга и управления производительностью, а также предложит пул необходимых для этого инструментов. Будет наглядная оценка результатов реформ (как было до и стало после). 
Также отдельное внимание будет уделено не менее важной стороне вопроса: как самому не потерять мотивацию и не уволиться, как разрешить споры в команде при внедрении новых подходов и технологий, как не поругаться с ДБА и админами, как повысить инициативность команды и открыть путь в современные практики.

В современным мире руководители разных уровней, в той или иной степени, обладают навыком «стихийного управления порядком», что не позволяет им окончательно утонуть в потоке задач и обязательств. Проблема хаоса в задачах и обязательствах часто приводит к перегрузке и, как следствие, стрессу и тревожности. Когда в этой ситуации оказался я, то приступил к изучению методик и существующих инструментов. 
Пройдя путь от привычных календарей и органайзеров до «Todoist» и «ЛидерТаск». Погрузившись в Матрицу Эйзенхауэра, одновременно жонглируя «Pomodoro» с Getting Things Done (GTD) – я открыл для себя «Хаос-контроль» и его лаконичную философию. 
Данным докладом хочу призвать коллег обратить внимание на необходимость управления ежедневным потоком задач, предложить минимально необходимые инструменты и методики, поделиться своим практическим опытом перехода на «контроль хаоса» вместо, уже ставшей привычной, ежедневной тревожности.

Для кого: для лидов групп и руководителей направлений, стремящихся к профессиональному и командному росту своих сотрудников.
На докладе поговорим о том, как специальным образом организованные встречи - ретроспективы помогают анализировать проекты и использовать полученный опыт для развития команды.
А именно: как фиксировать и использовать ценные знания, полученные в процессе работы, как улучшать коммуникацию, укреплять командный дух и предотвращать конфликты.
Что будет:
- Примеры ретроспектив из практики 1С КОРУС Консалтинг.
- Разбор целей, задач и структуры ретроспективы.
В итоге вы сможете определиться, подходит ли вашей команде формат ретроспектив. А если подходит - наметить план изучения и внедрения

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

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

В составе группы компаний «Доброфлот» 22 судна, и в современных условиях каждое из них представляет собой набор передовых информационных технологий, без которых наш моряк не видит своей вахты.
Мы активно развивали наши сервисы и в рамках доклада хочу рассказать о:
1.  Как "ковалась" основа в виде в спутниковой связи: от чего отказались в виду неэффективности, а что у нас до сих пор копируют конкуренты.
2. Как на этой основе развернулись 1С сервера - почему на части судов отказались от своего сервера и как мы проводим обслуживание, когда судно в открытом море.
3. Какие на эти сервера развернули базы 1С и почему их так много. Как задачи пытались решить и что было решено плохо. 
4. Как происходит обновление этого количества баз и почему у меня не болит голова каждый понедельник после новых релизов наших разработчиков.
5. А также о том, что сопутствующего из сервисов у нас появилась и что мы планируем еще доделать.

Сейчас существует несколько подходов к организации разработки в 1С и множество инструментов.
Зачастую выбор того или иного подхода или инструментов неочевиден, и самые эффектные и современные инструменты могут оказаться не эффективными для целого класса проектов.
В рамках выступления автор расскажет о критериях выбора тех или иных подходов к разработке и инструментов в зависимости от проекта: целей, сроков, участников, бюджета на примере двух успешных "противоположенных" кейсов:
1. Разработка коробочного продукта: разработка в ветках в т.ч. с использованием EDT, с большим покрытием BDD тестами, и статическим анализом кода для каждого pull requestа и покрытием кода
2. Разработка крупного решения под заказ на базе типовой конфигурации: разработка в хранилище с gitsync, с дымовыми тестами и периодическим статическим анализом кода
А также расскажет про "не успешные" кейсы, где выбор подходов к разработке и инструментов был не удачным, или не столь полезным или эффективным.

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

Три сценария использования BI-систем для управления ИТ на основе данных:

1. Переход на гибкие методологии разработки и внедрение модульного тестирования в команде разработки показал в модели BI следующую динамику за год:
  - Увеличение количества запросов на 37%.
  - Ускорение решения запросов на 10%.
  - Снижение количества дефектов на два порядка.
  - Повышение удовлетворенности клиентов на 2%.
  - Снижение средней трудоемкости запроса на 19%.

2. Реинжиниринг процесса управления запросами на изменения проводится сейчас с использованием BI на всех этапах работ:
  - Визуализация данных помогла выявить падение скорости решения запросов на ретроспективе команды разработки.
  - Детализация и анализ данных при помощи bi модели помог в анализе текущего процесса и выявления проблем эскалации.
  - Изменения в процессе и разработка новых метрик, таких как "время передачи запросов на 2 и 3 линии" и "назначение ответственного на 2 линии" были реализованы единовременно.
  - Сейчас мы ведём контроль за новыми и ранее используемыми показателями, для последующей оценки результата изменений процесса. Результаты озвучу на митапе.

3. BI как инструмент отчетности перед комитетом по изменениям:
  - Сбор данных о количестве реализованных задач.
  - Анализ фактического времени на реализацию задач.
  - Оценка удовлетворенности клиентов 

Платформа 1С активно развивается в сторону крупного корпоративного сегмента, и это отчётливо видно по разнообразию способов аутентификации в последних версиях платформы.
В докладе мы подробно рассмотрим все доступные методы аутентификации — от самых старых до самых современных.
Вы узнаете об особенностях, плюсах и минусах каждого способа аутентификации.

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

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

Расскажу как с помощью ServiceDesk и регламентов внедрить использование базы знаний на новом уровне. 

- Две проблемы любой базы знаний. Не заполняют и не пользуются. Как победить?
- Как база знаний помогает снижать нагрузку на техническую поддержку и ускорять решение проблем.
- База знаний для проектов на поддержке. Связка с service-desk
- Регламенты работы по наполнению и использованию базы знаний которые будут исполнятся исполнителями.
- Фиксация изменений проектов на поддержке
- Контроль на этапе внедрения. Какие метрики и контрольные точки.
- Повышение лояльности клиента и стоимости нормочаса через услугу описания проекта. Вы удивитесь, как это востребовано.
- Инструментарий для работы. От простого “гугл докс” до сложный систем с кучей интеграций.
- Сколько денег приносит база знаний?

Доклад будет интересен руководителям компаний и подразделений, которые хотят перевести внутренние процессы отдела на новый уровень. Буду особенно счастлив, если по результатам родятся новые идеи о том, что и как прокачать в Service Desk, чтобы работалось еще комфортнее и прибыль компании росла.

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

• Адекватность используемых решений по детектированию уязвимостей
• Анализ уязвимостей и заведение задач на устранение уязвимостей
• Охват инфраструктуры, качество работы с активами и ответственными за устранение уязвимостей
• Отслеживание выполнения SLA по задачам на устранение уязвимостей для скоупов активов