Доклады с конференций Инфостарта для специалистов 1С
INFOSTART EVENT — это конференции сообщества 1С, которые мы проводим с 2012 года. За это время они стали крупнейшей площадкой для обмена опытом между профессионалами отрасли.
На наших конференциях выступают настоящие практики из ведущих компаний России и СНГ, а не бизнес-тренеры. Доклады отбираются голосованием сообщества, а качество контента контролируют независимые эксперты. Каждая конференция охватывает интересы разных ролей:
для программистов — разработки и архитектурные решения, новые технологии и инструменты,
для аналитиков — методологии, работа с требованиями, анализ данных, управление изменениями,
для руководителей проектов и ИТ-менеджеров — управление командами, рисками, проектами и продуктами,
для специалистов по ИБ и администрированию — практики защиты, эксплуатации и поддержки систем,
для HR и тимлидов — развитие команд, soft skills и современные управленческие подходы.
За годы существования INFOSTART EVENT накопился большой объём уникального контента для всех специальностей из мира 1С. Практически по всем докладам мы готовим подробные транскрибации: они позволяют узнать суть докладов в удобное время и внедрить лучшие практики в своей работе.
Все материалы БЕСПЛАТНЫЕ в открытом доступе и помогают специалистам находить решения, обмениваться опытом и двигать отрасль 1С вперёд.
над каждым докладом работает минимум 6 человек.
За много лет существования Infostart Event у нас накопилось большое количество качественного и уникального контента, и мы рады представить вам эти материалы!
Рассказываем, как подразделение из 75 человек с выручкой около 25 млн рублей в месяц встроило GenAI в подготовку проектной документации, разработку и тестирование и превратило эксперименты с ИИ в измеримый бизнес-эффект. Разбираем результаты: экономию около 320 человеко-часов в месяц на работе с документацией, сокращение одной итерации тестирования, ускорение выхода на SLA и дополнительную непроектную выручку. Показываем, как внедрять и масштабировать инструменты с минимальным CAPEX через вовлечение и нематериальную мотивацию команды, а также преодолевать сопротивление изменениям. Объясняем, почему не стоит усложнять промпт-инжиниринг, и делимся готовыми шаблонами промптов, системой метрик и принципами безопасной работы с данными в открытых нейросетях.
Разбираем, почему проекты внедрения ESB, MDM и BI нельзя вести по тем же правилам, что и ERP: их промежуточный результат часто остается невидимым, зависимости проявляются слишком поздно, а привычные burn-down charts показывают активность команды, но не реальную готовность системы. На практических кейсах показываем, как отсутствие ключевого архитектора, скрытая связанность систем и одна ошибка в формате данных могут запустить каскад проблем и привести к серьезному перерасходу времени и бюджета. Объясняем, почему для технологических проектов нужен фазовый подход – от проверки концепции на реальных данных до MVP и полноценного запуска – с совместными контрольными точками и метриками по фактическому результату. Отдельно отмечаем, где ИИ-инструменты действительно помогают развивать аналитику и инновационные сценарии, а где не способны компенсировать ошибки архитектуры и низкое качество данных.
Пентест – это не только поиск уязвимостей, но и сложный проект, в котором ошибка может привести к простою, инциденту и потере доверия заказчика. Рассказываем, как правильно определить цели и границы работ, распределить ответственность, выстроить коммуникации и сделать неизбежные риски и изменения контролируемыми. На реальных кейсах разбираем, почему задержка с сообщением о критической уязвимости способна перечеркнуть технический успех, как управленческая рамка помогла разобраться в остановке турбины и когда выход за пределы скоупа приносит пользу бизнесу, а когда становится нарушением договоренностей.
Разбираем, почему привычная модель найма перестает работать и как компаниям выстраивать развитие специалистов в условиях дефицита кадров и новых ожиданий сотрудников. Показываем, как связка HR и тимлида помогает превращать новичков без проектного опыта в самостоятельных специалистов без перегрузок и потери качества. Объясняем, как сетка грейдов, ABC-классификация задач, индивидуальные планы развития и регулярная обратная связь делают рост прозрачным, помогают вовремя выявлять зоны развития и повышают мотивацию. Материал будет полезен тимлидам, HR-специалистам и руководителям IT-направлений, которые хотят сократить текучесть, сформировать кадровый резерв и не допустить кадрового голода в ближайшие годы.
Рассказываем, как превратить обучение аналитиков в полноценный проект и за полгода вырастить из джунов самостоятельных специалистов, готовых включаться в работу на разных этапах внедрения. Показываем, как практика, командные задания, жесткий темп, сквозной сюжет и реальные ситуации с заказчиками помогают быстрее развивать навыки и учиться на собственных ошибках. Разбираем, зачем будущим мидлам нужны не только знания 1С, но и умение проводить интервью, ставить задачи, тестировать, взаимодействовать с командой и справляться со стрессом. Объясняем, как оценивать прогресс с помощью матрицы из 40 компетенций, собирать регулярную обратную связь и выстраивать обучение, которое приносит пользу реальным проектам.
Разбираем, как манипуляции маскируются под взаимопомощь, командность и заботу – и почему даже в сплоченной команде они постепенно забирают время, энергию и доверие. На реальных кейсах из IT показываем, как распознавать лингвистические и психологические крючки, отделять эмоциональное давление от рабочего запроса и отвечать так, чтобы не разрушать отношения с коллегами. Объясняем, почему одной личной защиты недостаточно и как прозрачная нагрузка, четкие протоколы и регулярные ретроспективы помогают выстроить культуру, где помощь остается осознанной, а отказ не превращается в обвинение в некомандности.
В условиях удаленной работы, растущей нагрузки и хронической усталости трудные разговоры становятся одним из главных инструментов руководителя – особенно когда речь идет о сроках, качестве работы, повышении или поведении сильного, но конфликтного специалиста. Разбираем пять типичных ситуаций и показываем, как перевести разговор от оценок и взаимной защиты к фактам, последствиям и совместному поиску решения. Объясняем, как работают рамки ожиданий, «техника цифр», модель «факт – эффект – значение», метод «по одну сторону стола» и «Контракт» с конкретными договоренностями. Рассказываем, как сохранить доверие, избежать демотивации и превратить сложный разговор в точку роста для сотрудника и команды.
Разбираем, как в крупных компаниях регуляторные требования, постмортемы и внутренние ограничения постепенно превращаются в многоуровневую систему инструкций, в которой разработчику все сложнее понять, что и когда нужно проверить. Показываем opensource-сервис внешних проверок для GitLab, который автоматизирует часть этой бюрократии и сводит результат к понятному сигналу: зеленое – все в порядке, красное – нужно обратить внимание на конкретное требование. Объясняем, как такие проверки помогают «сдвинуть влево» контроль задач и снизить риск отказа во внедрении задачи в последний момент перед релизом. А заодно смотрим, может ли связка Autumn + «Вино» + немного разработческого энтузиазма превратить обязательные инструкции в инструмент, который команда сама захочет развивать.
Delivery – это не доставка еды, а доставка ценности в продакшн: разбираем, как выстроить процесс поставки на примере команды, работающей с 1С:ЗУП. Показываем, как за пару лет удалось почти вдвое сократить срок поставки решений, увеличить количество релизов с пяти до двенадцати в месяц и уменьшить периоды бизнес-фризов – за счет процессов, автоматизации и фокуса, а не переработок. Объясняем, как Lead Time, предсказуемость и другие метрики помогают находить узкие места и оценивать эффективность команды. Делимся практическими кейсами, сложностями и результатами – без лишней теории, только опыт.
Почему процессы, которые отлично работали в одной небольшой команде, перестают справляться с ростом, а увеличение штата не ускоряет поставку, а лишь усложняет коммуникацию и размывает ответственность? Рассказываем, как перейти от одной функциональной команды к системе автономных доменов, распределить архитектурную экспертизу и избежать ситуации, когда архитектор или платформенная команда становятся «бутылочным горлышком». Разбираем принципы Team Topologies с учетом специфики 1С, рабочие способы межкомандной синхронизации и трансформацию ролей руководителей, тимлидов и архитекторов. Показываем, как выстроить устойчивую ИТ-экосистему, в которой автономия не превращается в анархию, а координация – в бюрократию.
5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.
Разбираем новые, более дешевые и эффективные паттерны работы внешнего 1С:Эксперта, а именно – прямое использование LLM-ассистентов и создание с их помощью инструментов для аудита производительности и нагрузочного тестирования. Показываем, как модели помогают анализировать таймауты и взаимные блокировки по технологическому журналу, проверять сложные запросы, а также находить неочевидные взаимосвязи между показателями загрузки оборудования. Рассказываем о создании скриптов для построения графиков по данным atopsar и для поиска и визуализации стеков горячих запросов, а также о создании неинвазивной оснастки для реалистичных нагрузочных и сценарных тестов без программирования на 1С. Отдельно разбираем антипаттерны и ограничения такого подхода. Делаем вывод, что LLM остается лишь помощником, не превращает джуна в сеньора, а ответственность за итоговый результат по-прежнему несет 1С:Эксперт.
Рассказываем, чем оценка руководителя ИТ-проекта отличается от оценки других участников команды и почему для РП важны не только профессиональные знания, но и системное мышление, переговоры, управление рисками и ожиданиями. Разбираем, как выстроить сбалансированную систему мотивации, которая учитывает продуктовые метрики, сроки, качество, удовлетворенность клиента и рентабельность проекта. Объясняем, когда уместны оценка 360 градусов и обратная связь от заказчика, а также всегда ли ошибки команды находятся в зоне ответственности руководителя. Также продемонстрируем, какие косвенные показатели – от текучести и переработок до повторных контрактов и характера эскалаций – помогают оценить реальную эффективность РП.
Разбираем разницу между проектным и продуктовым подходами в управлении и причины того, почему они редко существуют в компаниях в чистом виде. Объясняем, когда достаточно процессного подхода, когда нужен проектный, а когда без продуктового управления уже не обойтись. Показываем ключевые критерии каждого подхода: жизненный цикл, роль команды, метрики успеха, организационную структуру и фокус управления. Отдельно разбираем риски неправильного выбора подхода – от лишних затрат до конфликтов ролей между руководителем проекта, владельцем продукта и менеджером по продукту.
AI-разработка становится повседневной практикой, но правовое регулирование только формируется, и цена ошибок уже измеряется штрафами, исками и репутационными потерями, которые могут превысить бюджет проекта. Рассказываем, как встроить правовой комплаенс в жизненный цикл AI-системы, не превратив разработку в бесконечное согласование, и как выбрать подходящую модель проверки с учетом уровня риска. Разбираем российскую судебную практику, распределение ответственности между разработчиком, заказчиком, пользователем и владельцем системы, а также показываем практические инструменты: карту рисков, контрольные точки, чек-листы и договорные механизмы защиты.
Рассказываем, как использовать библиотеку искусственного интеллекта для 1С не просто как инструмент генерации кода, а как основу для новых бизнес-решений. Показываем, как с ее помощью строить BI-систему на естественном языке: пользователь формулирует вопрос по продажам обычным текстом, а система генерирует запрос к базе и возвращает результат в виде таблицы или графики. Разбираем пример торгового бота-продавца, который общается с покупателем, консультирует по товару и отправляет платежную ссылку, а также объясняем, зачем в таких решениях нужны границы, точки контроля и обычное программирование. Отдельно показываем, как векторные базы и нечеткий поиск помогают создавать помощников менеджера (например, для подбора аналогов), и почему новые задачи лучше решать новыми методами, а не пытаться применять ИИ только к старым сценариям.
Рассказываем, как в условиях кадрового дефицита отдел 1С-разработки отказался от ставки на поиск готовых специалистов и выстроил автономную систему выращивания программистов – от вакансии и отбора до адаптации, обучения и работы на реальных проектах. Эксперименты с вакансиями, проверкой способности учиться и собственными форматами развития помогли обеспечить стабильный поток подходящих кандидатов и постепенно расширять компетенции команды.
Разбираем ISO/IEC 42001:2023 – самостоятельный стандарт по системам менеджмента искусственного интеллекта, построенный на логике ISO/IEC 27001 и расширяющий привычные подходы информационной безопасности на разработку, поставку и использование ИИ-систем. Показываем, как типовая модель оценки рисков дополняется анализом воздействия на бизнес и общество, а приложение А объединяет меры управления рисками в десять групп контролей. Объясняем, чем отличаются требования к разработчикам, поставщикам и пользователям систем искусственного интеллекта и какие риски каждая из сторон должна учитывать на своих этапах жизненного цикла. Материал будет полезен специалистам по информационной безопасности и разработчикам информационных систем, интегрированных с ИИ.
Разбираем, как быстро понять, чем занят SQL Server, кто создает блокировки и почему запросы 1С внезапно начинают тормозить. Показываем, какие настройки сервера и базы данных стоит проверять, как анализировать ожидания, планы запросов, статистику и индексы, а также переводить сырые данные SQL на понятный 1С-нику язык. Объясняем, как наладить предметный разговор с DBA и перейти от диагностики к конкретным рекомендациям. В статье также представлена бесплатная обработка для 1С, которая автоматизирует основную часть анализа для MS SQL Server и PostgreSQL и формирует готовые к применению SQL-скрипты.
Разбираем, что на практике скрывается за нормализацией НСИ и почему она нужна не только для наведения порядка в справочниках. Показываем, как единые и качественные данные помогают сокращать издержки, принимать управленческие решения и выстраивать бизнес-процессы компании. Объясняем, почему нормализация становится важным условием успешной автоматизации, и как она связана с качеством данных. Также рассматриваем основные инструменты работы с НСИ: методологию, классификацию, шаблоны описания, поиск дублей и подготовку данных к миграции.
Главная иллюзия ИТ-управления – вера в то, что правильные процессы, модные технологии и подробные регламенты сами приведут к результату. Показываем, как эта иллюзия разбивается о реальность. Результат создают мотивированные и компетентные люди, которым процессы помогают работать, а технологии решают конкретные бизнес-задачи, а не просто выглядят современно. Объясняем, почему ИТ-руководитель – это прежде всего лидер, который синхронизирует людей, процессы и инструменты в условиях ограниченных ресурсов, давления бизнеса и постоянных изменений. В статье разбираем типичные ловушки найма, мотивации, контроля, Agile, сервисности, планирования, внедрения ИИ, работы с вендорами и техническим долгом – и показываем, как сохранять романтику управления без розовых очков.
Разбираем, как подготовить Шину 1С к промышленной эксплуатации и обеспечить непрерывность интеграционных процессов при сбоях, обновлениях и недоступности отдельных узлов. Показываем варианты отказоустойчивой архитектуры – от подтверждения обработки сообщений до активно-пассивной и активно-активной схем с двумя экземплярами шины. Рассказываем, как контролировать инфраструктуру и потоки сообщений с помощью штатных и пользовательских метрик, а также как защитить продуктовую шину от случайного подключения копий баз с теми же учетными данными.
Универсальные «лучшие практики» в IT не работают одинаково везде. Финтех-стартап, лицензированный банк и большая банковская корпорация – это три разные среды. В каждой по-своему распределяются скорость, риск и доверие. Стартапу нужна максимальная скорость и готовность жить в неопределенности. Банку важнее управляемость, документация, процессы и след для аудитов. В статье разбираем, как по мере роста бизнеса меняются IT-стратегия, операционная модель и требования: к команде, к информационной безопасности, к архитектуре, к работе с вендорами и SaaS. Формулируем прикладные правила, которые помогают выбирать подход под контекст, не переносить опыт механически из одной среды в другую и ускоряться без потери контроля.
Разбираем, почему ERP-проекты не всегда идут по плану и какие «грабли» чаще всего мешают добиться целей: от неподготовленной НСИ и недостоверных начальных данных до слабых коммуникаций и отсутствия плана Б. Показываем, почему мировая статистика и российская практика сходятся в одном: ключевые проблемы чаще лежат не в технологиях, а в организации процессов, роли руководителя проекта и вовлеченности заказчика. Объясняем, как управлять завышенными ожиданиями, человеческим фактором и соблазном «запрограммировать все», не превращая типовую систему в дорогого монстра. А также рассказываем, какие шаги помогают пройти путь от предпроектного обследования и моделирования до опытной и промышленной эксплуатации без отката назад.
Сравниваем два подхода к созданию мобильных приложений в экосистеме 1С: классическую разработку на платформе и набирающую популярность технологию 1С:Элемент. Разбираем, какие возможности доступны из коробки, чем отличаются готовые интерфейсы и сколько времени занимает подготовка приложения к выпуску. На примере приложения «Показания тонометра» показываем, что потребуется для старта: материалы, инструменты, знания и этапы сборки. В финале сравниваем технологии по простоте разработки, внешнему виду, функциональности, перспективам развития и масштабируемости.
Разбираем, как объективно сравнивать нейросети и агентные подходы на типовых задачах разработки 1С, а не выбирать инструмент интуитивно. Показываем практический бенчмарк моделей и open-source-агентов: от написания и доработки кода до генерации Unit-тестов, документации и работы с метаданными конфигурации. Объясняем, как на результат влияют контекст, инструменты, обратная связь от тестов, системные промпты и особенности самих агентов. На примерах ошибок показываем, почему без правильной инфраструктуры нейросети могут не ускорять разработку, а создавать дополнительные затраты на исправление кода.
В современных 1С-проектах граница между разработчиком и аналитиком становится все менее очевидной: аналитик все чаще работает с техническими инструментами, а разработчик глубже погружается в бизнес-процессы, учет и регламенты. Разбираемся, где проходит разумная граница между ролями, какие задачи аналитик может брать на себя без риска для качества, а где начинается зона ответственности разработчика. Показываем, как технические навыки, автоматизация и ИИ-инструменты помогают команде работать эффективнее, не размывать ответственность и не создавать технический долг. Объясняем, как распределять задачи в команде так, чтобы ускорять разработку, сохранять качество продукта и не превращать специалистов в «универсальных солдат» без четкого фокуса.
Почему разработчики не всегда начинают пользоваться ИИ-инструментами, даже если у них уже есть доступ к GPT-чату, Copilot, OpenCode и 1С:Напарнику. Показываем, как через личные разговоры, короткие воркшопы и понятные аналогии – калькулятор, поисковик, автодополнение и Dota 2 – можно снизить страхи, скепсис и недоверие к генеративным нейросетям. Разбираем, почему одних рассылок и лозунгов про «будущее» недостаточно, и как маленькие быстрые победы помогают людям попробовать ИИ в рабочих и бытовых задачах. Статья будет полезна руководителям и тимлидам, которые сталкиваются с сопротивлением сотрудников и хотят привести команду к спокойному, практичному отношению к современным ИИ-инструментам.
Финансовая открытость помогает команде лучше понимать, как ежедневные решения влияют на бюджет, рентабельность и итоговый результат проекта. Показываем, почему формула «ставка для клиента минус зарплата сотрудника» не отражает реальную экономику бизнеса, и объясняем, какие скрытые расходы, риски и простои остаются невидимыми для рядовых специалистов. Разбираем, как вовлечь аналитиков и разработчиков в управление бюджетом без раскрытия коммерчески чувствительной информации: через финансовые пятиминутки, дашборды, участие команды в оценке и понятные правила работы с изменениями. Отдельно поговорим о том, почему финансовая прозрачность снижает влияние циничных настроений в команде и работает лучше, чем формальные KPI на финансовых показателях.
Компромиссы в проектах автоматизации часто не решают конфликт, а лишь откладывают проблему и оставляют под угрозой потребности обеих сторон. На трех типичных ситуациях – споре с заказчиком об оценке, конфликте с разработчиком вокруг требований и сопротивлении пользователя новой версии – показываем, где участники на самом деле спорят не о действиях, а о неопределенности. Объясняем, как в теории ограничений работает инструмент «туча» и почему любая проблема в ТОС рассматривается как конфликт. Показываем, почему в возможность win-win-решения выгоднее верить и как такой подход помогает искать не компромисс, а более устойчивое решение.
Чтобы перейти от тушения инцидентов в 1С к превентивному подходу, нужно заранее видеть рост данных, блокировок, времени выполнения операций и другие признаки будущих проблем. Разбираем, какие метрики технологического журнала 1С и СУБД стоит мониторить в реальном времени и как использовать простые ML-модели – регрессию и классификацию – для прогноза падения производительности. Объясняем, как автоматически выявлять аномалии в поведении пользователей и фоновых заданий, настраивать proactive-алерты за часы или дни до инцидента и создавать тикеты в ITSM-системах на превентивные действия.
Техническая поддержка может быть не просто службой для обработки заявок, а стратегическим центром цифровой культуры в организации. Показываем, как команда поддержки выстроила работу с разными аудиториями – сотрудниками, студентами и преподавателями, запустила внутренние мини-сообщества, внедрила ИИ-инструменты и начала переходить от SLA к XLA. Разбираем, почему современная поддержка должна не только решать обращения, но и учить пользователей, помогать соседним подразделениям, развивать Customer Service внутри IT и менять отношение людей к информационным системам. В статье – живой опыт крупнейшего вуза Европы: с цифрами, практическими кейсами и честным рассказом о том, как поддержка постепенно становится драйвером цифровых изменений.
Осознанное программирование помогает разработчикам принимать более взвешенные решения, понимать ценность своей работы и снижать вероятность ошибок. Показываем, как этот подход естественным образом сочетается с библиотечным методом разработки, особенно когда стандартных инструментов, таких как БСП, уже недостаточно. На примере создания библиотеки 1С Ozon демонстрируем, как единый компонент может ускорять проекты, повышать качество и уменьшать bus-фактор. Также объясняем, какие практики помогают развивать осознанность в профессиональной деятельности и применять ее в ежедневной работе.
Все больше и больше встречается использование мощной технологии расширений от 1С в корпоративном секторе. Однако, когда речь заходит о масштабных, бизнес-критичных системах, ее применение требует особой «гигиены». Неучтенные нюансы могут создать из суперудобного механизма точки отказа: нарушить и остановить весь бизнес клиента. Рассмотрим технические особенности использования расширений на больших корпоративных продуктивах 1С и выработаем оптимальный сценарий работы с ними.
Юнит-тестирование в 1С – тема, о которой много говорят, но внедряют далеко не везде: для одних это признак зрелой разработки, для других – избыточная формальность или лишняя трата времени. Разбираем, почему классическая пирамида тестирования в 1С часто оказывается перевернутой, какие ограничения накладывает платформа и почему юнит-тесты в реальных проектах нередко смешиваются с интеграционными. Показываем, где юнит-тесты действительно помогают ускорить разработку, упростить проверку логики и повысить качество кода, а где их применение превращается в хрупкую и дорогую поддержку. Отдельно разбираем типичные ошибки: зависимость тестов от данных и окружения, избыточное мокирование, тестирование платформы вместо бизнес-логики и отсутствие негативных кейсов.
Разбираем, зачем бизнесу переходить с MS SQL на PostgreSQL и какие риски сдерживают миграцию больших баз 1С. Показываем основные этапы перехода: от предварительного тестирования и конвертации через ibcmd до синхронизации данных с помощью DBReplication и других технологий. Объясняем, как выполнить миграцию с минимальным технологическим окном, сохранить возможность отката при непредвиденных ситуациях и подстраховать бизнес от простоев. Отдельно рассматриваем методику и инструменты обеспечения производительности после перехода.
Перегруженные формы в 1С могут превращаться в «стену плача»: пользователи теряются, дольше обучаются, чаще ошибаются и чаще обращаются в поддержку. Разбираем, чем хороший UI отличается от просто «красивого» интерфейса, как UX помогает выстроить понятный пользовательский сценарий и какие стандарты 1С стоит учитывать при проектировании форм. Показываем типичные признаки плохой формы – хаос, перегруз, отсутствие логики и единообразия – и объясняем, как поэтапно привести интерфейс в порядок. На практических кейсах «до/после» показываем, как выделить основной сценарий, убрать лишний шум и сделать формы удобнее для пользователей.
Синдром самозванца часто маскируется под перфекционизм, ответственность и высокие требования к себе, но постепенно начинает мешать работе, карьерному росту и взаимодействию в команде. Разбираем, почему в ИТ он встречается особенно часто, а именно: из-за постоянных изменений, сильной профессиональной среды, ревью, критики и ощущения, что «знать все» невозможно. Показываем, как синдром самозванца проявляется в поведении специалистов: от переработок и страха задавать вопросы до избегания сложных задач, обесценивания успехов и выгорания. Объясняем, какие практические техники помогают опереться на факты, заметить собственную компетентность и постепенно снизить влияние внутреннего критика.
Ручное управление, постоянный контроль и героизм отдельных специалистов перестают работать в 1С-командах, которые живут в условиях сложных проектов, ускоренных релизов и постоянных изменений. Инженерное лидерство помогает сместить фокус с контроля людей на управление системой: процессами разработки, CI/CD, окружениями, автоматическими проверками, ритуалами и прозрачными метриками. Объясняем, как выстроенные процессы снижают управленческую нагрузку, уменьшают стресс в команде и позволяют лидеру перейти от роли «бутылочного горлышка» к сервисной поддержке команды. Отдельно разбираем баланс hard и soft skills руководителя и показываем, почему современному лидеру важно уметь работать и с технологиями, и с людьми.
Как выстроить адаптацию нового руководителя проекта, чтобы быстро понять, подходит ли он компании и справляется ли с реальными задачами? Показываем, как квалификационный план помогает снизить неопределенность для сотрудника, сократить нагрузку на тимлида и не растягивать оценку управленца на месяцы. Объясняем, из каких этапов состоит онбординг: от Welcome Bot и вводных материалов до обучения в LMS, проектных кейсов, контрольных точек и обратной связи 360. Также делимся чек-листом адаптации нового РП и критериями, по которым можно оценить самостоятельность, скорость включения в работу и качество взаимодействия с командой.
