Опыт обучения руководителей проектов на практических кейсах. 

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

Про что я собираюсь рассказать:

Как можно организовать повышение квалификации проектных команд в компании?
Какие инструменты, рассмотренные на курсах, лучше всего зарекомендовали себя в реальной проектной работе?
Кейсы:
Как лучше внедрять 1С:ERP: по «Agile» или «традиционными методами»?
Что помогает превратить Заказчиков и Исполнителей из противоборствующих лагерей в единую команду?
И многое другое (что успею за 30 минут)

Что сделали за год?
Стандартизировали подходы к разработке
Запустили автотестирование как системный процесс по двум направлениям
Наладили процесс набора (собеседования и адаптации) специалистов в наши продукты
 
Уроки и кейсы
Надо ли отходить от четко сформулированных требований к вакансии?
Продуктовый подход vs проектный подход.
Работа в иерархии vs работа в плоской команде.
 
В чем ценность центра компетенции?

Резюме

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

Хотим поделиться опытом по обслуживанию инфраструктуры. 

Что имеем: 

• под каждый проект своя среда   

• CI/CD работает в Docker на Linux

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

При этом разворачивание вручную имеет следующие недостатки:

• нужны специальные знания и навыки

• занимает много времени

• ошибки за счет человеческого фактора

• неповторяемость среды между проектами    

Насколько я знаю, большинство руководителей команд разработчиков 1С сталкиваются с вопросом «Как мотивировать команды изучать новые технологии? Как перевести разработку на Git? Ведь часто разработчики изо всех сил активно сопротивляются новому». 
В 2022 году называть Git новой технологией – уже смешно,  но ведь это действительно «новое и неизведанное» для многих компаний. 
В докладе я постарался передать «компиляцию» наших корпоративных мотивирующе-убеждающих митапов. Постарался беспристрастно оценить плюсы и минусы двух главных систем контроля версий в мире 1С: Git и хранилища.
Расскажу об инструменте,  с помощью которого я сам и наши разработчики сливают изменения из разных веток – наш монолит на ОФ и его разработка на EDT невозможна – а также о том, что нам помогает преодолевать сопротивление мистеров «Нет-нет» и медленно, но верно переводить разработку 1С на использование Git в команде из 100 программистов 1С.

1. Нафига козе этот баян ?
2. Действительно ли нас обходят на поворотах ?
3. Когда этот хайп закончится ?
4. Остановите землю, я сойду
5. …потому что ты 1С-ник
6. Это не диагноз, а приговор(зачеркнуто) призвание
7. Мимо пройти нельзя участвовать
8. Всем шампанскоеи еще более десятка веселых и интересных слайдов на тему "Кто виноват и что делать нам с этой цифровой трансформацией".

• Рассмотрим тему «Проектные качели», которая актуальна для многих предприятий: то проектов много и делать некем, то проектов мало и ресурсы простаивают.
• Взглянем на аспекты проектной деятельности от потока заказов до потока проектов.
• Посмотрим, что можно типизировать и технологизировать по проектам и проектным командам. А так же, как можно сбалансировать те самые «Проектные качели» - от годовых планов по организации до оперативных проектных совещаний.

• Нестандартные решения на 1С:ДО – кейсы «Уралхим»

• Автоматизация материальных пропусков с использованием мобильного приложения

• Личный кабинет сотрудника. Сложные сервисы в пару кликов

• НСИ: ядро корпоративной шины данных и внутренняя разработка

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

Кому будет полезен мастер-класс: 

1. Начинающим карьеристам
2. Руководителям команд 
3. Не рекомендуется посещение занятия коллегам из одной организации. (Серый кардинал может быть только один)

Что получите?  Алгоритмы усиления влияния, универсальные скрипты для общения с подчиненными.  

Темы, которые разберем: 

•  На чем строится власть руководителя. Как быстро приобрести авторитет в новом коллективе. 5 источников власти в компании
•  Что такое сила переговорщика, как за нее идет борьба, когда ее правильно отдать противнику
•  Алгоритмы разговора с нелояльным подчиненным, усиление давления при сопротивлении. 
•  Разработка индивидуального плана по усилению своего влияния в организации.
•  Кейс на отработку темы -  «Саботажник»

1. Доработки 1С.ERP на крупных проектах можно организовать не внося изменения в саму типовую конфигурацию, используя только расширения и отдельные "микроконфигурации". Расскажем как на наших примерах
2. Для версионирования исходного кода удобно использовать GIT. Причем это можно делать без EDT и используя процесс разработки GitHub Flow. Расскажем как это сделано у нас
3. При использовании Gitа можно организовать автосборку и доставку релизов заказчику. Расскажем на нашем примере с использованием GitHub Actions
4. Можно выпускать "типовые конфигурации" в виде расширений, а на проектах делать "расширения на расширения". Расскажем как у нас это делается на примере БИТ.МДТ

Доклад поднимает проблему, есть ли место умным домам на базе 1С.
Наглядно продемонстрирую, как сделать умными относительно недорогие устройства, управлять всей логикой на 1С.
Возможности огромны: управление светом, включением-выключением розеток. 
В контексте частных домов (или дачных участков): поддержание температуры,  управление уровнем воды в бочке, автополив по расписанию или по уровню влажности почвы. И это только то, что на поверхности, а стоит подключить воображение, придумать
то, что облегчит быт, и будет служить вашими удаленными руками,  как под  эту задачу найдется механизм, которым несложно управлять из 1С.
Как легко самому сконструировать своё мобильное приложение на базе 1С,
помогающее управлять всем этим.
Тема умного дома не нова, уже никого не удивишь решениями от
Яндекс, Сбер, Mi и др. - но если встают вопросы:
1.я не хочу выкладывать свои данные на сторонний сервис.
2.как не зависеть от работоспособности сторонних сервисов.
3.как сделать так же, как у них, но дешевле.
То решение на 1С - вам в помощь.
А если вы сами хотите погрузиться в тему устройств управления, но вам кажется, что 
это сложно - то этот доклад точно для вас.
А вдруг вы хотите реализовать нестандартную логику управления устройствами, а решения
известных брендов не дают возможность управлять кодом, и вы в 1С, как рыба в воде, то
тоже рекомендую хотя бы взглянуть на предлагаемый инструмент.

Что такое кризис и критическая точка. Каковы основные типы кризисов, какое влияние кризисы оказывают на реализацию проектов, программ и портфелей.

На примере портфеля проектов создания, развития и сопровождения ЕИС управления финансово-хозяйственной деятельностью региона (количество работающих юридических лиц 2500+; активных пользователей 13000+), рассмотрим кейсы:

«Пока гром не грянет, мужик не перекрестится»

Принятие решений в критических точках. Эволюция от одного проекта к портфелю проектов. Балансировка портфеля. Формирование портфеля проектов, принятие решения о включении проекта в портфель или исключении из него.

«На товарища надеешься – сам его выручай»

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

«Один за всех и все за одного»

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

• что драйвит меня и других руководителей 1С-Рарус

• как наши интересы и предпочтения влияют на компанию

• как я принимаю решение, что важнее: рост прибыли или новая разработка

• как в 1С-Рарусе появилось приложение для фитнеса, и сколько человек в мире его используют

• зачем 1С-Рарус ездит на экскурсии или проводит конференции для технических специалистов, клиентов и партнеров

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. 
Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

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

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

В докладе расскажу о технической стороне: что потребовалось настроить и доработать (1C, oscript). Также расскажу о том, что это дало, как мне помогает эта информация.

• 1С как сервис: суть сервиса, 

• DBaaS&k8s, 

• сценарии использования

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

В 14-й версии Postgres, которая вышла прошлой осенью, и в 15-й, которая ожидается в этом году, реализовано много интересных важных обновлений: часть из них повышает производительность Postgres, часть — необходима для наиболее удобной работы, а некоторые, в дополнение, весьма полезны и для платформы 1С.

Иван Панченко, заместитель генерального директора Postgres Professional, расскажет о новшествах последних обновлений, уделяя особенное внимание тем, что влияют на производительность СУБД. Например, Postgres стал лучше работать с большим количеством одновременных соединений. Будут приведены практические примеры и результаты оригинальных тестов.

1. Разделяем риски проекта с Заказчиком. Как избежать +1000 часов разработки на старте проекта и грамотно составить Устав.
2. Обозначаем зоны ответственности и фиксируем ресурсы на реализацию. Практический опыт составления план-графика, или как мы нарвались на претензию и заплатили Заказчику за воздух.
3. Определение границ проекта. Кейс про разработку ТЗ, которое вылилось нам в лишний месяц написания кода.
4. Внедрение в государственном учреждении. Опыт длительного согласования проектной документации, или почему не стоит обследовать бизнес-процессы в 100500 подразделениях.

• Нестандартные решения на 1С:ДО – кейсы «Уралхим»

• Автоматизация материальных пропусков с использованием мобильного приложения

• Личный кабинет сотрудника. Сложные сервисы в пару кликов

• НСИ: ядро корпоративной шины данных и внутренняя разработка

1. Проект ограничен по времени. Через 2 месяца со старта проекта физически выключают M3 Infor
2. НСИ. 200 SCU готовой продукции, 7500 SKU инструмента, больше 10 000 спецификаций
3. Подсистемы: Закупки, Продажи, Склад, Производство, Расчет себестоимости, Планирование, Интеграция с 
4. Методика перевода клиента в кратчайшие сроки
4.1. Работа в формате T&M спринтами по 2 недели
4.2. Максимальное вовлеченье заказчика в проект
4.3. Последовательность запуска и приоритизация задач
4.4. Загрузка НСИ, документов, остатков с первого дня работы
4.5. Разработка функционала без фиксированного ТЗ
4.6. Адаптация под существующие бизнес процессы компании
4.7. Минимизация «бумажной» документации
4.8. Разработка АРМов вместо обучения работы типовым документам

Что такое DDD?
Зачем изучать DDD?
Чем DDD поможет в разработке на 1С?
Почему DDD это про 1С?
Где в 1С модульная архитектура?

Вот на все эти вопросы и еще на несколько других я постараюсь ответить на докладе.

Где заканчивается внедрение и начинается сопровождение?
Как безболезненно для заказчика подменить проектную команду на сотрудников сопровождения?
Лайфхак: способы задержать проектную команду после внедрения, и есть ли в этом прок?

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

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

«Не бывает незаменимых людей, есть цена замены».
Не согласна с утверждением. С таким подходом команду звезд не собрать, уж тем более не удержать. 
В кризисные времена еще важнее делать фокусы на талантах, чьи способности не просто спасают бизнес, но выводят его на новый уровень.
В докладе расскажу, какие акценты делать в разработке системы управления талантами:
1.  Позиционирование и EVP в текущих реалиях
2.  Рекрутмент. Какие компетенции востребованы, как отбирать и как оценивать (пройдемся по матрице компетенций)
3.  Онбординг. Как внедрить в команду нового сотрудника: ожидания vs реальность
4.  Оценка итогов работы и обратная связь (performance review, 1to1, ИПР)
5.  Менторство, коучинг и развитие. 
6.  Забота и поддержка сотрудников. Новые тренды
7.  Услуга аутплейсмента (помощь в увольнении и сокращении)

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

Со стороны Владельца продукта и Scrum-мастера осветим следующие аспекты:
-пресейл;
-формирование целей и работа с ожиданиями на разных уровнях;
-выбранная технология (микс Waterfall и Agile);
-особенности внедрения;
-философия международного внедрения (отличия от «домашнего»).

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

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

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

Как мотивировать не мотивируемых на совершение подвигов
Как после подобной мотивации не набирать новую команду
Что общего между типичным ИТ-департаментом и персонажами Warcraft III

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

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

Всем известно, что автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. 
А дорабатывать типовые механизмы 1С:ERP – не самое лучшее решение.

Зачастую проект внедрения 1С:ERP останавливается после внедрения подсистем бухгалтерского учета, зарплаты и складской логистики, несмотря на то, что задач на автоматизацию у Заказчика остается еще очень много: производственный учет, управленческий учет, управление имуществом, управление оборудованием, … почему?

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

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

На докладе разберем:
1.Как провести обследование, чтобы разработать Матрицу процессов.    
        Матрица процессов – это основа для планирования разработки Рабочих мест
2.Какие Рабочие места необходимо, создать и в каком порядке, чтобы заработала вся система целиком
3.Этапы разработки рабочего места
4.Как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

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

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

Так же разберем пример проблемного запроса, найдем его в коде 1С и исправим его.

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

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

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

- Зачем считать NPS, кто на него влияет и как его поднять?
- Реорганизуем работу: кто, что и зачем делает?
- Как, зачем и куда развивать сотрудников?
- Как найти баланс в проектной деятельности и при чём здесь ячейки?
- "Лучше гор могут быть только горы" или где взять руководителей?

Отлаживая взаимодействие с базой данных, мы регулярно сталкиваемся с зависающими или подозрительно долго выполняющимися обращениями, негативно влияющими на производительность. Важно выявить подозрительные запросы, основываясь на доступной о них информации, например: время запуска, число обработанных блоков памяти, дерево планировщика. 
Я расскажу о том, как узнать степень завершённости, диагностировать ошибки в написании и выполнении, не убивая уже запущенный процесс, встроенными инструментами PostgreSQL и его open source-расширениями. Применяем сборщик статистики, представления pg_stat_progress_*, модуль pg_query_state и другие.

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

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

* WTF Service discovery
* Зачем придумали Service Discovery
* Когда TEST пушит в PROD и как с этим бороться.

* Готовы ли 2500 пользователей к испытанию Linuxом?
* Правда ли, что 1С сложнее использовать в Linux?
* Всё ли программное обеспечение можно импортозаместить?
* Какой софт нужен для кластера 1С? Так ли он свободен?
* Не забыли ли мы про Единый Центр Обслуживания? Как там с СПО?

Поговорим о проблеме обновления различных статистик большой таблицы (привет регистру бухгалтерии в конфигурации БП Корп) и рекомендации вендора использовать опцию FULLSCAN.
Расскажем с какими проблемами столкнулись и какие результаты получили.
- плюсы данного решения
- почему используем FULLSCAN а не SAMPLE
- каких показателей получилось достичь на практике
- какие существуют ограничения и недостатки
- что мы написали для управления потоками

- Куда расти 1С-нику?
- Что мы знаем про тимлидов?
- Виды тимлидов
- Команда слезам не верит. Как развиваться тимлиду
- Атрибуты счастливой команды

 - С чего начать? Схемы работы
 - Что такое карточки товаров?
 - Как технически может быть организована интеграция?
 - Лайфхаки по отдельным маркетплейсам (СберМегаМаркет, Вайлдбериз, Озон, Яндекс.Маркет)
 - Несколько советов по маркетингу на маркетплейсах и при чем тут интеграция
 - Обзор бесплатных возможностей (готовых модулей) для интеграции с маркетплейсами

-«зоопарк» систем: ошибка архитектора или новая реальность?
-знание бизнеса или технические навыки: в чём наша ценность?
-«лучший код – это код, который не написан»
-Hyperautomation как общемировой тренд
-AI и ML в каждый дом. Быстро, дешево, вчера.

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

• История появления продукта
• Возможности
• Планы развития
• Сравнение с текущими решениями

- Архитектура BI решений на базе платформы 1С
- Возможности 1С:Аналитики и варианты внедрений
- 1С:ЗУП КОРП и возможности анализа HR данных
- HR данные. Аналитические панели в BI системе, на базе 1С:ЗУП КОРП и 1С:Аналитики

1. Как гарантировать актуальную документацию
2. Как превратить ваши тесты в красивый фильм
3. Как помочь пользователю самому изучить вашу конфигурацию
4. Onboarding - это просто

В своем докладе я расскажу про то, как добиться простой и невозможной цели - чтобы документация к вашему продукту соответствовала ему.
Берём тесты, сценарии, Vanessa Automation,  перемешиваем, но не встряхиваем и рецепт готов.

1. Расчет плана проекта перехода с УПП на ERP
2. Управление рисками при переходе
3. Типовые сложности перехода с УПП на ERP
- Сложности сопоставления документов и других объектов конфигураций
- Настройки отражения в регл.учете. Используем исключения
- Закрытие месяца в ERP. Другие правила
- Отличия в плане счетов и как с этим работать?
- Плавный переход по подсистемам. Порядок перехода. Подводные камни
- Перенос зарплатной и кадровой информации
- Внедрение складского учета в ERP
- Внедрение прочих подсистем

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

Я расскажу о трех проектах, в основе которых лежит Система взаимодействия: двусторонняя связь скайпа с 1С, уход от библиотеки для работы с Asterisk, использование системы взаимодействия для обслуживания клиентов. Вы узнаете о том, почему мы решили использовать новый механизм, с какими сложностями сталкивались и как их решали. В завершении доклада я расскажу, почему один из проектов уже устарел, а второй пора переделывать.

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

Как в Почте России эксплуатируются высоконагруженные и распределенные системы на платформе 1С. Задачи мониторинга и методы их решения. Использование в работе ЦКК, Grafana, ElasticSearch и др.

В рамках 1С я прошел путь Программмст -> Аналитик -> Функциональный архитектор.

В проектах я занимаюсь в том числе:

• контролем за ходом  этапов проекта и выходной документации на соответствовали технологиям компании;
• адаптацией технологии под конкретный проект;
• усовершенствованием проектной технологии компании с учетом опыта завершенных проектов.

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

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

• Реестр требований – основной Источник ошибок системы. Определение важности реестра требований в масштабе всего проекта.
• Иерархия требований. Какие еще требования бывают кроме функциональных.
• Первичный сбор требований, создание реестра требований. Откуда возникают требования?
• Минимальный жизнеспособный продукт и критически важные требования.
• Атрибуты требований. Какие необходимые и достаточные колонки включать в реестр требований.
• Ненадлежащее управление требованиями. Какие последствия?
• Управление требованиями – что за зверь?
• Переход от реестра требований к управлению. Как работу с реестром требований превратить в управление требованиями?
• Категории управления требованиями:
  • Первичный сбор и отслеживание состояния требований
  • Группирование и упорядочение требований
  • Разрешение проблем с требованиями (дубли, неправильные, отсутствующие требования и т.п.)
  • Анализ и определение приоритетов требований
  • Управление зависимостями
  • Мониторинг и отчет о ходе выполнения

• Инструменты управления требованиями

SOLID – принципы проектирования программных структур (модулей). Акроним S.O.L.I.D. образован из первой буквы пяти принципов. Эти принципы делают код более гибким, упрощают разработку. Принято считать, что принципы SOLID применимы только в объектно-ориентированном программировании. Но я докажу, что и в 1С их можно успешно использовать. Каждый труженик конфигуратора и EDT может применять в своей работе SOLID, надо лишь разобраться в этих принципах. Чем мы и займёмся. Примеры кода – будут.

Какие подводные камни ждут внедренцев?
В чем отличие мировосприятия Сапера и 1С-ника?
Дорожная карта - минимум воды.

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

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

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

Рассмотрим процесс, риски, вопросы возникающие при переводе базы данных с MS SQL на Postgres:
- Примерный план работ:
   * дорожная карта
   * команда
   * ресурсы
- Рассмотрим обзорно инструменты помогающие в этом процессе;
- Подготовка заранее до предстоящей миграции;
    * выявление текущих проблем,
    * доработки, оптимизация,
    * подготовка,
    * проведение нагрузочного тестирования и др.
- Работа продолжается после перехода - начинается самая жара;
    * выявляем проблемы,
    * доработки, оптимизация,
    * горячие исправления и др.
- Сколько это может стоить? Риски, команда, проблемы.
- А стоит ли это все делать?
- Практические советы и рекомендации.

Закупки – больная тема для многих компаний. Особенно в последнее время. Но как правильно подойти к автоматизации закупок, чтобы проект не оказался «провальным»? Основная проблема – широта предметной области и разница в понимании "что такое закупки" разными участниками этого проекта.

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

Выступление построено на технологиях, наработанных мною на проектах за последние 10 лет совершенствования процессов закупок для производственных и производственно-торговых компаний, направлений НИОКР и исполнения Гособоронзаказа.

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

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

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

- Что такое «Профессиональное профилирование» и зачем это нужно
- Пошаговая методика составления профессионального профиля для 1С-специалистов
- Техника верификации субъективных оценок на практическом примере
- Масштабирование профессионального профиля от отдельного специалиста до уровня команды/отдела/департамента/etc.
- Как интерпретировать составленный профиль; какие решения можно и нужно принимать, основываясь на этой информации

Поделимся практическими горячими советами и примерами оптимизации конфигураций 1C ERP/УТ/КА для 
высоконагруженных баз и не очень на СУБД Постгре: 
- Что нужно знать и уметь. Минимальные требования;
- Инструменты, метрики, подход; 
- Классический набор ошибок, проблем, задач оптимизации – для любой конфигурации и СУБД;
- Специфические моменты при оптимизации для СУБД Postgres;
- Рассмотрим разнообразные интересные примеры реальных кейсов и решений (закрытие месяца, 
тормозные списки, оптимизация RLS, декомпозиция и много другое);
- Как влияют разные версии платформы 1С на работу в базе;
- Как влияют разные версии Postgres на работу пользователей в базе.
- Чем отличается работа с Postgres от MS SQL. 

Аналитики, занимающиеся внедрением 1С, не всегда хорошо представляют, как устроена платформа 1С:Предприятие. Как следствие – технические задания часто получаются не понятными для разработчиков.

В докладе расскажу о том, почему аналитику имеет смысл хотя бы в какой-то степени разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными. Затрону и другие темы.
Дам ссылки на литературу, куры и другие ресурсы, которые помогут «подтянуть» знания.

Каждый кто либо дорабатывал типовые формы, либо разрабатывал свои при групповой разработке сталкивался с болью объединения доработок элементов форм.
Самые частые примеры таких болей:
- Вы добавили свои элементы, будь то поля ввода, кнопки, таблицы на форму самому популярному документу конфигурации. А Любимый вендор выпустил обновление, где тоже в этот документ подсыпал изменений.
- Есть несколько задач на доработку формы самого популярного документа. Одну делаете сами, вторую отдали на сторону. Разработчик на стороне работает с локальным cf.  Без доступа к хранилищу. Через неделю все молодцы, с задачами справились. И настало нелегкое время, объединить все наработки.
И ответом на эти боли будет - программное управление элементами формы. 
В своем докладе, я расскажу Вам о нашем подходе к решению этих проблем. Я прошел долгий путь, в несколько итераций. И пришел к элегантному (на мой взгляд) решению. Где делался упор на наглядность и читаемость кода.
Вот маленький пример для затравки.
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
п_РаботаСФормамиСервер.НовыйПостроительФорм(ЭтаФорма)
.Кнопка("КнопкаПрограммная")
.Заголовок("Программная кнопка")
.ИмяКоманды("Команда1")
.Применить();
КонецПроцедуры

Hard skills, Soft skills… Знакомо? Но все гораздо сложнее. Есть «мягкие навыки» - т.е. то, что может нарабатываться. А есть «личные особенности» и «модели поведения». Навыки ли это? Не совсем. Но именно эти факторы являются наиболее критичными при отборе сотрудников. И именно их оценить наиболее сложно.
Многие кандидаты научились демонстрировать «желаемую модель поведения». То, что от них ожидает работодатель. Можно ли заранее оценить реальный профиль будущего сотрудника и учесть скрытые подводные камни в работе с ним? Ответ- да, можно! И для этого необязательно применять сложные инструменты типа ассессмент-центра.

Какими инструментами готова поделиться я:
1.Как правильно читать резюме «между строк» и по нему выстраивать интервью
2.На что обращать внимание в истории и поведении кандидата и какие выводы из этого нужно или не нужно делать
3.Какие «нерабочие» вопросы задавать, чтобы в непринужденной беседе получить больше информации, чем при профессиональном отборе 

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

Участникам мастер-класса предстоит:
1. Воспроизвести ошибку при перестановке границы итогов.
2. Обсудить причину, рассказать решение.
3. Протестировать исправление.

Во всех вакансиях есть требование - умение читать код. Однако нигде этому специально не учат. В рамках доклада рассмотрим:

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

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

1. Недооцененные концепции «сервис» и «мастер-данные» и что из этого следует.
2. Виртуальный монолит. Проблемы интеграции точка-точка. Чем это чревато
3. Middleware концепция. Сервисная шина данных и в чем отличие от брокеров сообщений.
4. Интеграции это скучно. Зачем разработчику нужен low-code инструмент в интеграциях, и какие опасности у его использования.
5. Вспоминая ITIL. Кто должен отвечать за поддержку интеграций и минорные корректировки, вроде правки атрибута?

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

- Подписки на события - проблемы и подход
- Массовая обработка данных - архитектура с примерами
- Обработчики обновления - нюансы при 5 релизах в неделю
- Настройки подсистем - избыток констант, и что с ним делать
- Разработка расширений - доработка типового кода и отказ от демонических обновлений
- Регламентные задания - настройки "из коробки"
- Архитектура СКД-отчетов - управление поведением при формировании
- Индексация таблиц базы данных - оптимизация для последующего использования
- Реструктуризация базы - критерии и порядок тестирования

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

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

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

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

#Тезисы (через риторические вопросы):
* Виды данных в компании и кто с ними работает, какие существуют потребители данных в data -driven компании
* Методики работы и подготовки данных 
* Что будет, если неправильно работать с данными и как это может повлиять на результат

#Аннотация
ИТ - кровеносная система бизнеса, а data-driven вектор у любой соверменной компании, которая хочет не выживать, а получать сливки. Но вот вопрос, а про данные забыли? Умеют ли ваши сотрудники работать с ними? Предлагаю погрузиться в изумительный мир данных и посмотреть основные методологии. 

#План_доклада
1. Кто я, зачем меня слушать, боли. Данные для аналитика/разработчика/тестировщика/девопса/менеджера
2. Что такое мир данных
3. Какие Данные существуют
4. Как подготавливать данные и основные патерны работы над ними
5. Инструменты работы с данными
6. При чем тут ML и есть ли связь с АД
7. Негативные сценарии работы с данными
8. Бест практика работы с данными
9. Портрет СА/БА/DS/ДА (для аналитических секций)
10. API/Интеграции/Реплики - боль?
11. Рекомендации
12. Итог

Наш небольшой коллектив иногда называют "IT-извращенцы" и это прозвище получено вполне заслуженно. Способы взаимодействия с платформой 1С, опробованные нами на практике, способны удивить даже IT-спецназ, а новичков валят в обморок. Зато при правильном использовании эти способы существенно повышают безопасность разработки и эксплуатации ПО, предоставляя возможности, недоступные при "классическом кодинге".
Доклад будет про:
- распределенные конфигурации 1С (не базы, а именно конфигурации)
- работу с базой 1С без тонкого клиента 1С и даже без компьютера
- защиту от кражи кода чужими и своими разработчиками
- безопасное предоставление доступа к базе 1С внешним пользователям
- уменьшение нагрузки на оборудование (безопасный код должен быть безопасным и для серверов)
- масштабирование учетных систем 
Готовы погрузиться в недетское программирование шКОДИТЬ по-взрослому? Тогда приходите, будет интересно!

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

  Итак, лендинг-страничка нашего курса «Изучаем ИТ-анализ»:

• Продолжительность курса – около 200 часов.
• Стоимость курса – бесплатно или необходимы минимальные вложения.
• Для кого курс – без опыта работы, студенты, стажеры, аналитики, бизнес-аналитики, консультанты, люди с опытом работы и все те, кто хочет узнать что-то новое и «подтянуть» свои знания.
• Чему вы научитесь – искать и систематизировать нужную информацию в ИТ-анализе.
• Как проходит курс – в любое удобное время вы прокачиваете свои знания по чек-листу.
• Начальные требования  –  ваше желание и упорство.

• обзор модулей ФинОфис,
• особенности использования.

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

Примеры кейсов для разбора:

Как общаться, когда подписанное и заверенное ТЗ имеет мало отношения к реальности?
Что делать, если Исполнитель в ходе работы подменил команду сениоров на джуниоров?
Как быть, когда Заказчик не считает возможным подписать акты, а Исполнитель предлагает идти в суд?
Как перенести устные договоренности при смене руководителя проекта?
Как наладить отношения, если Заказчик и Исполнитель не могут договориться о соответствии результата требованиям: например, Исполнитель считает, что все сделано, а Заказчик считает, что нет?
Как сохранить отношения и деньги, если Заказчик остановил проект по внутренним причинам, например, реорганизации?

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

1. Шина 1С, это больше чем RabbitMQ. Принципы работы (схема потоков данных)
2. Для интеграций больше не надо поднимать Веб-сервер и следить за совпадениями версий платформы
3. Опыт эксплуатации - как мы передаем все журналы регистрации из 17 баз ( а это  10,5 млрд записей за 30 дней)
4. Варианты практического использования шины внутри экосистемы 1С
5. Варианты практического использования шины с другими системами (не 1С)

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

В последние пять-десять лет появились инструменты автоматизированного тестирования продуктов написанных на 1С. Некоторые из них стремительно развиваются, по ним есть и подробная инструкция и масса докладов разного уровня. Стало понятно как автоматизировать. Но все так же остается масса вопросов разряда: с чего начать? что и в каком объеме автоматизировать? Как выстроить сам процесс и расставить приоритеты, учитывая при этом различные риски и их оценку? И наконец: как построить тестовую модель на основе анализа рисков качества.

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

За 30 минут мы развенчаем миф и выясним:
- почему бизнес-анализ – один из самых недооцененных в 1С-сообществе процессов
- в чем ценность этапа выявления истинной проблемы на фазе пресейла
- как меняется ценность работы бизнес-аналитика в жизненном цикле проекта
- как связаны теория ограничений Голдратта и конфигурация 1С
- при чем здесь творчество?

• Виды сотрудничества с Инфостарт, 
• Как стать автором за стартмани, 
• Виды заработка на площадке Инфостарт: статьи, форум, обработки,
• Возможности для авторов за стартмани,
• Партнерская программа для разработчиков,
• Что получает разработчик,
• Что предоставляет Маркетплейс,
• Что требуется для заключения партнерства.

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

Только вот, к сожалению, наши любимые учителя литературы забыли нам объяснить:
- как правильно читать книгу?
- как книга вообще влияет на человека, как она "работает"?
- как найти "свою" книгу?
- и главное: зачем мне вообще читать эти книги, если я программист, сисадмин, аналитик?

Я бы хотел разложить всё это по полочкам. Без пустой теории и поэзии, на понятных примерах и на знакомых ситуациях объясню - зачем программисту книжки читать. Спойлер: очень много зачем.

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

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

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

Вы когда-нибудь задумывались, почему одни it-компании растут из года в год минимум по 30%, а другие считают за счастье повторить показатели прошлого года?
Одни ищут возможности как выйти на новые проекты, адаптироваться к очередному кризису, и нарастить объемы. Другие ищут оправдания - дефицит специалистов на рынке, гонка зарплат, клиенты в кризис экономят деньги...
Когда-то мы были командой, которая делала небольшие проекты на 1с в своём регионе. Но мы пошли по первому пути - пути поиска возможностей, концентрации усилий на самом важном. Современная наука учит нас, что у хорошего управленца всегда в дефиците 3 ресурса - люди, время, деньги. Мы нашли для себя методику стратегического планирования, которая позволяет управлять имеющимися ресурсами и выжимать максимум из того, что есть. И сейчас, мы - it компания LAD, - международная it компания. Внедрение 1С - одно из направлений. Мы успешно работаем с крупными федеральными заказчиками. Про успехи можно говорить долго. Но везение ли это, или хорошо продуманная стратегия? Решать Вам. 
В своем докладе я расскажу про:
1. Наш опыт стратегического планирования,
2. Конкретные проекции планирования на примере проектного офиса по 1С,
3. Контроль исполнения стратегии,
4. Результаты.

Настольная игра по внедрению 1С-продукта на основе игры TWIG. Познакомит с Канбаном тех, кто с ним еще не знаком. А тем, кто хочет внедрить Канбан в своей команде - освоить полезный инструмент, который можно потом использовать для обучения.

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

Чек-лист для перехода на EDT (+GIT) на вашем проекте:
1. Качество кода и соблюдение стандартов,  (SONAR, код-ревью)
2. Нужно больше хранилищ. Насколько прозрачен коммит?
3. GIT vs Хранилище 
4. Готовность команды: обучение, торг, смирение, принятие 
5. Готовность инфраструктуры

Может казаться, что после 20 лет инвестиций в ИТ, на предприятиях стоит ожидать высокого уровня автоматизации. Но это совсем не так! Достаточно поговорить с менеджерами, почитать описания вакансий, побыть на оперативках - и увидишь, насколько далека реальность от ожиданий. 

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

Выход - есть. Но начать придётся, как обычно, с себя. И в дороге будет тяжело. Приз - долгосрочное конкурентное преимущество, которое будет трудно скопировать другим.

•  Внедрение программных продуктов 1С
•  Проектная деятельность в различных отраслях
•  Работа с партнерами

• Принятие решений в неопределенности 

• Почему слово “надо” не работает? 

• Источники энергии - как с ними работать

• Для интроверта - где взять энергию в общении с людьми

Пишете много тестов - хорошо. Покрытие достаточно высокое - отлично. Но все равно попадаются баги - плохо.

Юниты и фича-файлы - это ведь код. А значит и их можно протестировать. 

Расскажу о подходе "мутационное тестирование", которое позволяет оценить насколько тесты надежные. 

Минимальные изменения кода -> прогон тестов -> анализ результатов тестов

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

1. Почему модель Time&Materials показала себя самой оптимальной в период турбулентности 2022 года.

2. Как за счет трекинга и отчетов по выполненным задачам и можно поднять стоимость часа на 25%

3. Как правильная методология оказания услуг и организация ServiceDesk позволяет повысить LTV клиента вдвое.

4. Как правильная система отчетов позволяет увеличить производительность отдела в 1,5 раза без увеличения количества человек.

5. Договора, база знаний, тестирование без отдела тестирования. Как вспомогательные истории влияют на экономию денег и времени.

6. Почему 30% компаний не могут исполнить заявленные SLA, и как этого избежать.

7. Как правильно составленный договор позволит вам снизить количество не оплаченных счетов на 25 процентов.

8. Про бизнес, масштабирование, партнерки, лиды. Как зарабатывать?

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

• кто, как и когда становится автором и тренером на курсах,
• как создаются курсы,
• причем тут Инфостарт,
• финансы и прочие юридические вопросы.

1. Мобильное приложение обладает особенностями: нет встроенных в платформу средств логирования, количество мобильных устройств может быть большое/неопределенное
2. Облачные провайдеры, например Yandex.Cloud, предоставляют готовые средства, для асинхронной загрузки логов через http с авторизацией и помещению их в базу данных
3. Логи можно собирать структурировано, в какую-нибудь колоночную СУБД, например ClickHouse, и затем по ним собрать аналитику
4. Это легко реализуется в коде 1С мобильного приложения и настраивается в Yandex.Cloud, покажем на примере БИТ.MDT с анализом результатов

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

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

Мы формируем команды, подбираем себе близких по духу и нужных для решения задач людей. Нашли, он пришел в команду – что дальше? Хорошо, если новый сотрудник полностью компетентен по всем направлениям и сразу готов «идти в бой». Но часто новый сотрудник не обладает всеми нужными компетенциями на все 100% или вообще может обладать только желанием и стремлением расти и развиваться в выбранной области. Это «больные точки», если говорить о скиллах и их развитии. Однако самым болезненным может быть то, что сотрудник не хочет брать на себя ответственность за свою работу, считая, что руководитель/наставник/куратор проверит, поправит, исправит и всегда поможет. И тогда, насколько бы ни был такой сотрудник компетентен, вся работа ляжет в итоге на его руководителя.
В своем докладе я расскажу, как, на примере джуна-аналитика 1С, можно:
- Сформировать карту компетенций сотрудника и дальнейшую ее оценку;
- Подготовить план индивидуального развития (ПИР) для развития новых компетенций сотрудника;
- Корректно ставить задачи сотруднику для развития компетенций на практике;
- Мотивировать и направлять.

1. 5 шагов для выявления ограничения
2. Кто среди ваших людей – ограничение
3. Как управлять сложной системой
4. Подчинить систему ограничению – не значит подчиняться ему
5. Возможности Теории ограничений и её ограничения

В среде 1С есть уникальная возможность быстро собрать интерфейсы и сразу сделать работающее приложение. Зачем тогда выделять отдельный этап и рисовать прототипы?
Разберем, когда использование прототипов положительно сказывается на процессе разработки, а когда вредит. Как организовать работу с прототипами эффективно и удобно.
 
– Особенности подхода к разработке интерфейсов в 1С
– Плюсы и минусы прототипов
– Выбор инструмента прототипирования: конфигуратор, онлайн-сервисы, графические редакторы
– Использование Figma и UI kit элементов интерфейса 1С на практике
– Как встроить прототипы в рабочий процесс

Есть несколько способов разработать мобильное приложение с использованием нативных средств платформы «1С:Предприятие». Результат разработки решит задачу бизнеса. Однако сценарии применения таких приложений чаще всего ограничены использованием внутри компании. Интерфейс мобильных приложений сильно отличается от привычных. В докладе расскажу несколько способов разработки современных мобильных приложений. Обсудим подводные камни и ограничения. Разберём кейс, когда мобильное приложение выгодней заменить веб-приложением.

* Ограничения платформы 1С:Предприятие в области разработки мобильных приложений.
* Веб-технологии и мобильные приложения. Переиспользуем опыт.
* Нативные приложения против гибридных. Плюсы и минусы. Когда и какой вариант выбирать.
* Веб-технологии спешат на помощь: React Native, Framework7.
* Как соединить с 1C:Предприятие. Разбираем несколько решений.
* Разработка интерфейса для Android и iOS.
* Производительность. Ограничения гибридных мобильных приложений.
* Как начать разработку мобильных приложений.
* Автоматизированное тестирование.

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

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

В своем докладе я расскажу об инструменте, который был разработан для выполнения модульного тестирования, предоставляющий разработчику 
- написание и выполнение тестов в конфигураторе и ЕДТ, а также их прогон на CI
- текучие выражения (настоящие)
- плагин для ЕДТ, сильно облегающий написание и выполнение тестов

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

На сопутствующем мастер-классе, мы с коллегой покажем реальные сценарии применения модульного тестирования.

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

Мастер-класс с активным участием всех слушателей.

Теория ограничений утверждает, что работа в режиме бешеной белки ведёт лишь к ухудшению положения.

Каждая компания видит десятки проблем у себя, но назвать одну корневую может крайне редко.

На практикуме покажут, как ТОС выявляет такое ограничение, и помогает значительно вырасти результату системы без его устранения.

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

Программа на Windows, берите с собой ноутбуки.

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

ТОС чаще всего применяется на производстве, наш докладчик Тертычный Глеб – один из немногих в стране, кто помогает использовать ТОС в IT.

Кейсы применения ТОС будут из сферы веб-студий, инвестфондов, банков и телекома.

Громкие споры, созвоны и встречи, которые не приводят к результатам, стресс, бессилие. 
Итог: потеря интереса к работе.
Можно ли добиваться лучших результатов без лишних нервов?
Есть несколько интересных способов, которыми я хочу поделиться.
Никакой магии - чистая логика.

На прошлом Infostart Event 2021 Moscow я поделилась опытом, инструментами и основным исходным кодом разработки мобильного приложения на 120 000 пользователей.
Сейчас я решила поделиться подробными кейсами того, как организовать быструю разработку и публикацию мобильного приложения от имени Заказчика, как поставить разработку приложений на поток.
И, конечно, будет много исходного кода! 
И не просто код, на этот раз готовый шаблон приложения, который позволит сразу собрать и показать прототип решения Заказчику, чтобы тот быстрее принял решение о приобретении Ваших услуг. В нем будет несколько вариантов авторизации, красивое меню, push-уведомления, чат и настройки обмена.
Расскажу пару слов о том, как мы продолжаем использовать все сервисы в обход санкций - не отказались ни от одного из используемых нами инструментов .
Также обсудим формирование стоимости приложений, какие услуги еще можно предложить Заказчику
Все это на примере приложения, которое я недавно разработала для транснациональной Европейской логистической компании.

На мастер-классе вы попробуете писать тесты и узнаете, что это не так сложно.
1. Поговорим о принципах тестирования.
2. Установим в EDT и рассмотрим функциональность тестового движка.
3. Научимся готовить тестовые данные.
4. Напишем тесты примитивной функции, проведения документа и взаимодействия с REST-сервисом.
5. Научимся пользоваться моками.

Время проведения - 1 ч. 
Данный мастер-класс является продолжением доклада «Много разговоров о тестировании, но в основном о тестировании сценарном, пользовательском»

Ни для кого не секрет, что бухгалтер лучше всего чувствует себя в конфигурации 1С:Бухгалтерия, но что бывает, если такого бухгалтера перевести с 1С:Бухгалтерии на ERP?
Разберемся:
- как помочь бухгалтеру преодолеть трудности при переходе c 1С:Бухгалтерии на ERP;
- как построить эффективное взаимодействие между аналитиком и бухгалтером;
- основные ошибки бухгалтера после перехода, о которых важно знать аналитику;
- и как наиболее безболезненно донести до бухгалтера, что ОСВ теперь не на первом месте.

- Почему мы задумались о применении Agile при разработке 1С:Бухгалтерии? Какие были ожидания и оправдались ли они?

- Что делать, если все планы рушатся?

- От SCRUM к KANBAN: в чём практическая выгода?

- Анализ задачи как часть разработки: сколько времени остаётся на кодирование?

- Квинтэссенция опыта разработки

На мастер-классе последовательно систематизируем методики по управлению конфликтами на проектах.

Разберем конструктивную и деструктивную составляющие конфликта.

Обсудим влияние типов личности участников конфликта на способы его разрешения и на мотивацию в целом.

Отработаем на практике стандартные инструменты работы в конфликтной ситуации.

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

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

DevRel (developer relations, или деврел, или просто технический пиар) - направление развития и поддержки IT-бренда компании:  почти как PR (Public Relations), только в центре внимания находятся технические процессы, технологии, а не маркетинг. DevRel — это рассказ миру разработчиков о своем продукте или команде; DevRel - это политика компании, направленная на коммуникации с внешними разработчиками, техника продвижения компании как IT-бренда. DevRel - это представление продукта, команды или услуг компании не для конечных пользователей, а для разработчиков. DevRel делает акцент на создании отношений, основанных на доверии к ним.

В докладе мы поразмышляем на тему: зачем это компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом. 

Участники:

• Артур Аюханов
• Александр Кунташов
• Алексей Корякин
• Никита Иванченко
• Александр Синиченко
• Владимир Трушников
• Сергей Голованов
• Павел Филатов
• Виталий Онянов
• Максим Нифонтов
• Валерий Дыков
• Андрей Крапивин
• Артем Беленцев
• Сергей Крайнев
• Юрий Жердецкий
• Андрей Полетаев
• Юрий Лазаренко
• Артем Кузнецов
• Виталий Черненко
• Валерий Максимов
• Александр Пузаков

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

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

* на что влияет обслуживание индексов?
* когда надо и когда не надо его выполнять?
* если надо - как это сделать так, чтобы никому не помешать?

1.Разбор кейсов: «Доктор, меня игнорируют», «Меня никто не понимает», «Я думал, будет быстрее»
2.5 причин, из-за которых ваши письма отправляют в «корзину»
3.С чего начать приучение коллег правильно общаться через почту
4.Составляем письма, чтобы их читали и понимали: тема, содержание, оформление
5.Структура основных видов писем: 
•протоколы - фиксируем договорённости, чтобы их не забывали
•просьбы - как писать, чтобы вас понимали и программисты, и бухгалтеры, и финансисты
•сопроводительные письма - зачем, если все есть в прикрепленном файле
•информационное письмо - как уместить все важное в одном абзаце
4.Тонкости взаимодействия - мотивируем коллег предоставлять нужную информацию в письме
5.Как повысить эффективность общения через почту: инструменты и лайфхаки
6.Тяжелая артиллерия. Как влияет на результат присутствие руководителя в копии 

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

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

«Интегрируй это!» слышал я на одном из ранее прошедших Infostart Event. Сейчас без интеграций, уже, наверное, не существует ни одного программного решения 1С. Часто даже пишутся отдельные «прослойки» на 1С (и не только), которые используются для интеграций. Но оптимально ли такое? А как логи там?
Хочу продолжить свой «путь» докладов о паттерне проектирования ESB. 
MuleESB как ядро интеграции любой логики внутрь системы учета. Быстро, легко, оптимально и красиво (на любителя, конечно). Ну и ClickHouse, Elastic, RabbitMQ, Redis, Grafana.
А также много…много логов.

• Почему гибкие подходы провоцируют выгорание? Шкала прочности и лебединая песня разработчика.
• Чек-лист руководителя: как понять, что наступил @#$%#
• Почему выгорание - это вредно? Ущерб проектному треугольнику: выгорание и бюджет, выгорание и качество, выгорание и процессы.
• За agile погонишься, ни agile не поймаешь. Как быть гибким и здоровым?

1. Введение:
- Чат-боты, что это и какие возможности?
- Кейсы эффективного применения ботов в связке с 1С
- Проблемы при реализации чат-ботов для различных каналов и описании логики их работы

2. Эффективное использование:
- Подходы при разработке решения, способного с легкостью создавать и поддерживать чат-ботов в 1С
- Пример создания чат-бота и описание его поведения

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

Это и многое другое на бизнес-симуляции. 
Приходите, будет полезно, весело и задорно.

В качестве бонуса проработкой ваших софт-скилов по и небольшой практический мастер-класс по теме публичных выступлений.

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

* Приемы оценки проекта при недостаточной входящей информации
* Составляющие оценки проекта
* Расчет резерва под риски
* Оценка по требованиям, календарно-сетевому графику и ресурсным методом
* Приемы и методы кросс-проверки оценок 

0. Немного вводных слов;
1. Схема интеграции;
2. Формат сообщения;
3. Архитектура подсистемы для 1С от простого к сложному;

• Работа с одной входной очередью:
• Простой обмен "Источник - Приемник";
• Обмен "Источник - Приемник", когда не доверям источнику;
• Обратная интеграция:
  
• Регистрация объектов;
  
• Формирование исходящих сообщений;
  
• Работа со множеством очередей. Обмен "Несколько источников - Несколько приемников"
  

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

Есть разные способы «подружить» мобильное приложение с 1С:Предприятия. У каждого свои плюсы и минусы. А ещё есть подводные камни, которые вылезают в середине проекта… В докладе поделюсь практическими кейсами интеграции мобильных приложений с 1С:Предприятие 8. Разберём плюсы и минусы: REST, ODBC, ESB-шина и других способов.

- Интеграция мобильного приложения с 1С:Предприятие 8;
- Способы интеграции: REST, ODBC, ESB и так далее;
- Практический опыт: подводные камни;
- Советы и рекомендации.

Любой проект внедрения системы управления и учета, это проект организационных изменений. Меняются процессы, роли, требования к сотрудникам компании, распределение задач. Неавтоматизированные ранее участки - подлежат автоматизации. Работа людей систематизируется и часто перестраивается. Как следствие, успех проекта в целом существенно зависит от того, какие изменения в организации должны произойти, а какие на произошли. И насколько сотрудники компании-заказчика этим изменениям помогали/сопротивлялись.

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

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

- обмен данными в сервисе 1С:Fresh;
- проблемы, с которыми столкнулись при разработке;
- стало быстрее или медленнее?
- пример простого обмена данными в сервисе;
- пример разрабатываемого механизма для сбора данных с областей данных БГУ и ЗКГУ.

1. Различные теории и значение их в личностном развитии
2. Теория Спиральной динамики, базовая модель смыслов
3. Значение теории спиральной динамики в построении осознанной корпоративной культуры
4. Развитие себя и компании при помощи новых знаний
5. Лайфхаки 

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

• Выжимаем все соки из 1С.
• Локальный кеш - наше все.
• Моментальный обмен данными с мобильным приложением на Java даже на сетях 2G.
• 1000 строк документа за 190 мс.

-Как выбрать подрядчика и на что обратить внимание
-Где Вас могут "провести"
-Что вы в праве требовать от Подрядчика и на что рассчитывать
-Как подготовиться к Проекту внутри Компании
-Как сформировать Проектную команду и сколько времени от кого потребуется
-Какие Риски есть по ходу выполнения Проекта и как с ними бороться
-Как подстраховаться при Запуске

* Проектирование. Усложнение, устремленное к простоте.
* Архитектура решения. Конвейеры обработки данных и внутренние интерфейсы.
* История реализации и внедрения. Развитие успехов и борьба с ошибками.
* Аппетит, приходящий во время еды. Незапланированные дополнения."

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

Решение «в лоб»: настраиваем несколько эндпоинтов в разрабатываемом приложении. 

В реальности такой подход сложно масштабировать. При изменении API одного из сервисов не всегда возможно оперативно обновить приложение. Другой минус: структура данных с бэкенда не всегда совпадает с желаниями моб/фронтенд-разработчика. Зачастую приходиться делать трансформацию на стороне клиента. Это неудобно.

BFF (API Gateway) — одно из гибких решений для подобных задач. В мастер-классе разберём решение практической задачи: создадим BFF на платформе Node.js, узнаем как строить гибкую архитектуру бэкенд-приложения, расширим кругозор знакомством с альтернативными технологиями и попрограммируем. На выходе получим готовый шаблон сервиса.

Что будет в мастер-классе: немного теории, Node.js, TypeScript, подход IoC, DI и живой кодинг. Много кода с комментированием. За один час разработаем рабочий сервис.
Продолжительность - 1 час.

• Что необходимо заказчику: продукт или проект?
• Бюджет agile-проекта может быть только фиксированный. Как не ошибиться в оценке?
• Импортозамещение инструментария внедренцев: Jira, Confluence, отчетность
• Квалификация заказчиков. Как заказчику набрать необходимую экспертизу для проекта и выбрать подходящего подрядчика. Как подрядчику оценить экспертизу заказчика

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

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

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

Участники круглого стола:

Евгений Винниченко
Владимир Ловцов
Владислав Маковеев
Андрей Путин
Никита Перевозчиков
Александр Запольский
Дмитрий Круглов
Николай Желнин
Сергей Сорокин
Игорь Левин