Нет глупых вопросов


Гео и язык канала: Россия, Русский
Категория: Познавательное


Не бывает глупых вопросов. Глуп тот вопрос, который не был задан. Группа для обсуждения про мир 1С, айти (ИТ/IT 😀) и все, что крутится вокруг этого. Анастасия Штей aka НастяШ

Связанные каналы

Гео и язык канала
Россия, Русский
Статистика
Фильтр публикаций


Репост из: Терменвокс 🎧
Две буквы, на которых держится российский бизнес. В новом выпуске подкаста «Программный комитет» говорим об 1С — системе, которая помогает автоматизировать процессы в тысячах компаний.

Анастасия Штей, руководитель отдела сопровождения финансового учёта ecom.tech/1C и автор телеграм-канала «Нет глупых вопросов», расскажет, какие навыки требуются для работы с программой, зачем она нужна бизнесу и как развивается платформа сегодня.

▶️ Смотреть | ▶️ Слушать

😮 Мы снимали этот подкаст на международной IT-конференции «Стачка»! В этом году она пройдёт 10-11 апреля в Ульяновске и 3-4 октября в Петербурге.


Репост из: TeamLead Сonf
Если вы интересуетесь темой развития себя и сотрудников, значит этот пост для вас! ⤵️

Сегодня мы открыли запись круглого стола «Индивидуальный план развития: взгляды с разных сторон» с конференции Saint TeamLead Conf 2025 🔥

Этот круглый стол — диалог о роли ИПР в современных IT-командах. Особое внимание уделено практическим аспектам внедрения ИПР в рабочие процессы. Как найти баланс между долгосрочными целями развития специалистов и сиюминутными проектными задачами? Как избежать превращения ИПР в галочку в системе оценки?

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

P.S. Не обошлось без азарта — в команде спикеров присутствует тот, «кто против». Удалось ли ему переубедить коллег и зрителей?


✋ Если у вас есть своя тема для круглого стола — отправляйте заявку в программу на Saint TeamLead Conf 2026
⏳ Дедлайн приема заявок — 20 февраля
Круглый стол «Индивидуальный план развития: взгляды с разных сторон»
Приглашаем на самую крупную мультиформатную конференцию для тимлидов и руководителей не только из IT — TeamLead Conf 2025, которая пройдет 10 и 11 ноября 2025 в Москве. Подробнее о конференции: https://clck.ru/3NUaBv ________ Единственная профессиональная конференция для тимлидов и руководителей..


Репост из: Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Опубликовали запись вебинара в формате круглого стола на тему «Круглый стол: Искусственный интеллект в работе 1С аналитиков»

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

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

#конференция@systems_education


➡️ Не замечали усталость от огромного количества вкладок, приложений, программ?

App sprawl (англ. букв. "разрастание приложений") означает, что в организации накопилось слишком много разных программных приложений и инструментов, что снижает эффективность процессов, приводит к операционным проблемам, повышает расходы и создает риски безопасности. Это происходит из-за быстрого технологического развития, децентрализованных закупок и роста компании.

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

Как итог, App Sprawl — это наше состояние: усталость от вкладок, мессенджеров и программ.

💬 Кто замечал такое?

#СловоДня #КопилкаЗнаний


▶️ Вы точно умеете работать с техдолгом в 1С?

13 ноября я и мой коллега Андрей Литвинов при поддержке Питерского клуба одинэсников и Selectel провели очень камерный воркшоп "Что такое долг в ИТ и как с ним работать?".

⏩ Почему про долг?

2025 год уже близится к концу. И мы задумываемся о подведении итогов этого года. Но итоги разные... Накоплкнный тех долг — это тоже итог. А только ли тех долг? А как его/их распознать? И что с этим всем делать? Вот на эти вопросы, мы и искали ответы. И что-то даже нашли.

⏩ Почему воркшоп?

Доклады — это круто. И Дмитрий Земляченко, старший фронтенд-разработчик Angular (Selectel) перед нашим воркшопом рассказал как раз о тех долге. Но мы хотели, что бы была не просто рефлексия после доклада, а реально пошуршать своими мозгами и попробовать разобрать пример. И... сформировать план, как действовать в том случае, если долг (и тех тоже) уже есть.

⏩ Почему камерный?

Потому что так получилось))) Вечер четверга, дождливый Питер, но мы не унывали, подкреплялись пиццей и рассуждали о долгах в ИТ)) получилось 🔥

🔔 И в следующем году мы вас ждем на продолжении. Следите за анонсами)

⏩ Что получили?

— Разбрали, только ли тех долг существует? А нет ли каких еще? (мини теория).
— Разобрали виды долгов на кейсе.
— И получили чек-лист, как с этим бороться и не копить.

➡️ А кто как считает, кто не был у нас на воркшопе, только ли техдолг есть в 1С/ИТ?


🟧 ИИ и документация: как аналитику 1С использовать искусственный интеллект для создания документации

Документирование бизнес-процессов, написание технических заданий, создание инструкций для пользователей — рутинные, но критически важные задачи в работе аналитика 1С. Искусственный интеллект может значительно ускорить эти процессы и повысить качество документации. Давайте разберём пошаговый план внедрения ИИ в работу с документацией.​

🟧 Выбираем ИИ-помощника

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

Для технической документации подходят: ChatGPT, Claude, DeepSeek и проч.

Есть, специализированные решения, например, Docsie или Mintify.

🟧 Создаём правильный промпт

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

Структура эффективного промпта для документации:

🟧 Контекст: "Ты — технический писатель, специализирующийся на документации для систем 1С".
🟧 Задача: "Создай техническое задание на доработку модуля складского учёта".
🟧 Требования к формату: "Используй структуру: описание проблемы, требования к функционалу, сценарии использования, критерии приёмки".
🟧 Стиль и тон: "Пиши чётко, структурировано, избегай сложных конструкций. Целевая аудитория — программисты 1С и заказчик".
🟧 Ограничения: "Не используй технический жаргон без пояснений"​.

Пример:

Создай пользовательскую инструкцию по работе с документом 'Приходная накладная' в 1С:Управление торговлей. Включи скриншоты [описание], пошаговые действия и раздел 'Частые ошибки'".


🟧 Наполняем базу знаний (при необходимости)

Для получения точных и релевантных ответов ИИ-ассистенту нужна база знаний — это ваши корпоративные документы, регламенты, примеры и шаблоны.​

Что включить в базу знаний:

🟧 Шаблоны технических заданий и инструкций.
🟧 Регламенты оформления документации в вашей компании.
🟧 Примеры успешно выполненных ТЗ.
🟧 Справочники терминологии 1С.
🟧 Описания типовых конфигураций.
🟧 FAQ по распространённым запросам пользователей.
🟧 Внутренние стандарты кодирования и именования объектов​.
🟧 Форматы для загрузки: TXT, DOCX, PDF, таблицы Excel, презентации​.

Важно: структурируйте документы — разбивайте большие файлы на логические блоки, используйте заголовки, создавайте отдельные файлы под конкретные задачи (например, "Стандарты_ТЗ.docx", "Термины_1С.pdf").​

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

🟧 Создаём Telegram-бота для документации

Финальный шаг — сделать ИИ-ассистента доступным для всей команды через Telegram-бот.​​

Зачем нужен бот:

🟧 Быстрый доступ к шаблонам и примерам документации.
🟧 Автоматическая генерация типовых документов (акты, отчёты, инструкции).
🟧 Ответы на вопросы по стандартам оформления.
🟧 Проверка документов на соответствие регламентам.
🟧 Помощь в составлении ТЗ прямо в мессенджере​​.

Пример:

Аналитик вводит описание бизнес-процесса — бот генерирует черновик ТЗ с соблюдением корпоративных стандартов​.


🟧 Важные замечания

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

🟧 Подведём итог

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

362 0 14 3 13

🔍 Чек-лист внедрения культуры документирования: путь к прозрачности в 1С-проектах

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

1️⃣ Начать с себя — личный пример

Руководитель задает стандарты работы команды. Хотите, чтобы команда документировала? Начните сами! Ведите записи встреч, фиксируйте решения по проекту внедрения 1С, создавайте понятные описания процессов и настроек. Когда сотрудники видят, что лидер сам следует правилам, они естественным образом перенимают эту практику. Личный пример руководителя — самый мощный механизм управления.​

2️⃣ Сделать документацию частью рабочего процесса

Документирование не должно быть "потом" или "когда будет время". Встройте его в каждый этап работы с 1С:​

▪️ При обследовании — создавайте отчеты и реестры бизнес-процессов​.
▪️ При разработке — пишите техническое задание и частные ТЗ​.
▪️ После внедрения — составляйте инструкции для пользователей​.

Сделайте документацию обязательным пунктом Definition of Done для любой задачи.

3️⃣ Мотивировать команду

Люди не документируют не из вредности, а потому что не видят ценности или не имеют времени.

Покажите выгоду:​

▫️ Хорошая документация 1С-процессов сокращает количество повторяющихся вопросов.
▫️ Она помогает быстрее адаптироваться новичкам​.
▫️ Она защищает от "эффекта автобуса" — когда ключевой сотрудник уходит​.

Внедрите систему поощрения: отмечайте тех, кто ведет качественную документацию, включите это в критерии оценки эффективности.

4️⃣ Внедрить правило чтения документации

Культура документирования неполна без культуры чтения. Установите правило: перед тем как задать вопрос — проверь документацию!​

Для 1С-проектов это критично:

🔸 Прежде чем спрашивать про настройку — загляни в техническую документацию проекта​.
🔸 Перед обращением в поддержку — изучи инструкции пользователя​.
🔸 Перед началом работы с новым модулем — прочитай описание бизнес-процессов​.

Структурируйте документацию так, чтобы её было легко найти и читать. Используйте четкие заголовки, оглавление, визуальные схемы процессов 1С.​

5️⃣ Автоматизировать

Документирование должно требовать минимум усилий. Используйте подход Docs as Code — храните документацию в Git, генерируйте её автоматически из комментариев в коде.​​

Для 1С-команд:

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

Автоматизация снижает ручной труд и улучшает качество документации.​​

🔮 Главное

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

⏮Начните сегодня. Начните с себя. Остальное приложится.⏭


🗑 А вы знаете что это за принцип?

GIGO (Garbage In, Garbage Out) — «мусор на входе, мусор на выходе».

💭 Простыми словами

Если вы загружаете в систему неправильные данные, то и результат получите неправильный. Даже если сама программа работает идеально.

🔍 Откуда взялся принцип?

Придумал ещё Чарльз Бэббидж в 1864 году, а современный вид концепция приобрела в конце 1950-х благодаря инструктору IBM Джорджу Фьючелу.

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

🖥 Как это работает на практике?

Пример 1: Вводите в CRM неправильный email клиента → письма не доходят → клиент уходит к конкурентам.

Пример 2: В 1С указали неверную ставку НДС (а все знают об изменениях в 2026 году?) → отчётность сформировалась с ошибкой → налоговая выписывает штраф.

Пример 3: В аналитику попали кривые данные о продажах → руководство принимает решения на основе фантастики → стратегия проваливается.

‼️ Главное правило

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

💡 Вывод

Прежде чем автоматизировать процессы, наведите порядок в данных. Иначе вы просто автоматизируете хаос.

Garbage In, Garbage Out — классика бессмертна 🗑⚡️

#СловоДня #КопилкаЗнаний


Видео недоступно для предпросмотра
Смотреть в Telegram
🌷 Кто сказал, что документация на проектах 1С нужна? Полная ерунда!

Зачем тратить драгоценное время на описание алгоритмов, когда можно просто написать комментарий "//TODO: разобраться потом"? Ведь через полгода ты точно вспомнишь, зачем создавал эту процедуру на 500 строк с загадочным названием:
ОбработкаДанныхВариант2_Копия_Финальная_НеТрогать


➕ Преимущества отсутствия документации

✅ Гарантия занятости — только ты знаешь, как работает система. Увольняться? Ни за что!
✅ Развитие интуиции — новые сотрудники учатся читать мысли через код. Почти магия!
✅ Элемент квеста — каждое исправление бага превращается в увлекательное детективное расследование.
✅ Проверка на прочность — если разработчик не может разобраться в коде без документации, значит, он недостаточно крут.

Особенно шикарно, когда единственная документация — это сообщение в чате: "Ваня делал, но он уволился. Код вроде работает, не трогайте".

➕ Если кто-то всё-таки решит писать документацию — помните, лучший комментарий к коду:
НоваяПроцедура() // Новая процедура

Кристально ясно! 🙂

🚨 А если серьезно: реальные риски отсутствия документации

1⃣ Финансовые потери

👉 Затраты на поддержку. Разработчики тратят уйму времени на поиск информации по незадокументированным системам, что при зарплате, например, в 150 тыс. руб./мес. означает потерю 93 тыс. руб. ежемесячно на каждого специалиста.
👉 Стоимость исправлений. IBM Research показывает, что исправление дефектов возрастает в 10 раз, когда они обнаруживаются поздно из-за плохой документации.
👉 Расходы на сопровождение. Стоимость сопровождения ПО без документации может достигать 15-25% от первоначальной стоимости разработки ежегодно.

2⃣ Критический Bus Factor

👉 Зависимость от одного человека. Если только один разработчик знает ключевые части системы, его увольнение может остановить проект на месяцы.
👉 Время адаптации новичков.
Без документации новый сотрудник тратит 3-6 месяцев на изучение системы вместо 2-4 недель.

3⃣ Проектные риски 1С

👉 Провал внедрения. Отсутствие документации входит в топ-10 причин срыва ERP-проектов.
👉 Рост стоимости проекта. Незадокументированные требования могут увеличить бюджет проекта на 25-30%.
👉 Технический долг. Каждая незадокументированная доработка создает долг, который растет экспоненциально.

4⃣ Операционные последствия

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

5⃣ Юридические и регулятивные риски

👉 Проблемы с аудитом. Отсутствие документации усложняет прохождение внутренних и внешних аудитов.

6⃣ Репутационные потери

👉 Потеря доверия заказчика при невозможности объяснить работу системы.
👉 Сложности передачи проекта другому подрядчику.
👉 Негативные отзывы от команд разработки в профессиональном сообществе.

🫡 Вывод

Экономия на документации оборачивается потерями, которые в 5-10 раз превышают изначальные затраты на ее создание. В мире 1С, где проекты живут годами и обрастают доработками, документация — не роскошь, а необходимость для выживания бизнеса.

👍 А если документация есть — это хорошо или плохо?

Что бы узнать ответ, приходите 24 октября на Желтую конфу! Подробнее о программе и регистрация
тут.


Discovery Phase в проектах 1С: почему это важно? И что бывает, когда пропускаешь этот этап?

👀 Предисловие: когда «сразу к делу» превращается в театр абсурда

Представьте: заказчик звонит в 9 утра понедельника и говорит: «Нам нужна 1С, завтра начинаем!» Именно в этот момент опытный консультант понимает, что впереди его ждет увлекательное приключение в стиле «Алиса в стране чудес», где каждый этап проекта будет преподносить новые сюрпризы.

🔵 Что такое Discovery Phase и зачем она нужна

Discovery Phase (или предпроектное обследование) — это подготовительный этап перед разработкой, когда команда изучает бизнес-процессы, выявляет требования и планирует архитектуру будущей системы. Это как медицинское обследование перед операцией — можно, конечно, сразу хирурга позвать, но лучше сначала понять, что именно болит.

Основные задачи Discovery Phase включают:
- Детальный анализ текущих бизнес-процессов.
- Выявление «узких мест» и проблемных зон.
- Формулировку четких требований к системе.
- Оценку рисков и технических ограничений.
- Планирование архитектуры и технологического стека.

🗣 Причины важности Discovery Phase: когда «экономия» оборачивается катастрофой

1⃣ Туманные требования = бесконечные доработки

Пример из жизни. Компания решила внедрить 1С:УТ «по-быстрому». Через месяц выяснилось, что их система ценообразования настолько уникальна, что стандартный функционал не подходит. Результат: 6 месяцев доработок вместо планируемых 2 недель настройки.

Влияние на последующие этапы:
- Постоянные изменения в техническом задании.
- Рост стоимости проекта в 3-4 раза.
- Демотивация команды и конфликты с подрядчиком.

2⃣ Неправильный выбор конфигурации = дорогая переделка

Реальный кейс. Торговая компания выбрала 1С:БП вместо 1С:УТ, потому что «дешевле и проще». Через полгода поняли, что система не умеет работать с многоуровневыми скидками и программами лояльности.

Последствия:
- Полная замена платформы через год.
- Двойные затраты на внедрение.
- Потеря времени на неработающей системе.

3⃣ Игнорирование бизнес-процессов = хаос в работе

Классический пример. Производственная компания внедрила 1С:ERP без анализа производственных циклов. Система считала, что изделие производится за день, а на самом деле цикл занимал 3 недели с учетом сушки и контроля качества.

Результат:
- Неточное планирование производства.
- Постоянные срывы поставок.
- Недоверие к автоматизации среди сотрудников.

🔔 Примеры влияния пропуска Discovery Phase на этапы внедрения

⏺Этап моделирования превращается в хаос

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

Что получается без Discovery. Каждая встреча с заказчиком — это открытие новых «особенностей» бизнеса. «А, кстати, у нас еще есть филиал в Казахстане с особым налоговым режимом» — говорят на 5-й неделе моделирования.

⏺ Настройка системы = бесконечный цикл правок

Нормальный сценарий. Система настраивается согласно зафиксированным требованиям.

Реальность без анализа. «Можете сделать так, чтобы кнопка была зеленой? А отчет — как в Excel? А чтобы НДС считался по-особому?». Каждая правка тянет за собой 10 новых.

⏺ Обучение пользователей = миссия невыполнима

По плану. Пользователи изучают систему по заранее подготовленным инструкциям.

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

✏️ Заключение: инвестиции в здравый смысл

Discovery Phase — это не «лишняя бюрократия», а инвестиция в успех проекта. Да, придется потратить 10% от времени всего проекта на анализ. Но альтернатива — потратить 300% времени на бесконечные переделки и объяснения заказчику, почему «простая задачка» превратилась в космическую одиссею.

🤝 Помните. Хороший врач сначала ставит диагноз, а потом лечит. Хороший автоматизатор сначала проводит Discovery, а потом внедряет систему. Все остальное — это не экономия времени, а инвестиции в будущие головные боли.

Расскажите, а у вас был смешной случай с Discovery Phase? 🚀


👨‍👩‍👧 Есть ли особенности планирования коммуникации в инхаус командах 1С?

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

🎯 Почему планирование коммуникации критично для инхаус команд?

1. "Эффект близости" — проклятие или благословение?
Инхаус команды знают бизнес изнутри, но это создаёт ложное чувство понимания. "Мы же в одной компании работаем, зачем формализовать очевидное?" — типичная ошибка, приводящая к недопониманию на 40% чаще, чем при работе с внешними подрядчиками.

2. Баланс между срочностью и планомерностью
Внутренние заказчики часто воспринимают инхаус команду как "скорую помощь". Без чёткого планирования коммуникации команда разрывается между "горящими" задачами, теряя фокус на стратегических проектах.

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

Решить эти вопросы можно с помощью специальных методов организации коммуникации.

Методы организации коммуникации для инхаус команд

📜 Структурные решения

🔘 Визуализация потока для всех внутренних заказчиков.
🔘 Распределение по сервисам — разделение на развитие vs поддержку.
🔘 Система приоритизации, например, "светофор":

🔴 Красный: критичные сбои в работе (реагирование в течение часа).
🟡 Жёлтый: плановые доработки (в рамках спринта).
🟢 Зелёный: развитие функционала (по roadmap).
🔘 "Продуктовое мышление" внутри компании:

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


💬 Коммуникационные практики

🔘 "Открытые коммуникации" с границами:
- Любой может задать вопрос любому, НО через систему задач.
- Обсуждение проблем приветствуется, но в отведённое время.
- Запрет на "срочные звонки" без фиксации в системе.

🔘 Регулярные ритмы для разных аудиторий:
- Еженедельные статус-коллы с продакт-оунерами.
- Ежемесячные демо для всех пользователей.
- Квартальные планирования с участием топ-менеджмента.

🔘 "Инженерные часы"
2-4 часа в день, когда команда недоступна для срочных вопросов и сосредоточена на разработке.

📊 Специфические инструменты

🔘 Централизованная система управления всеми внутренними задачами на базе 1С:
- Единое окно для всех запросов.
- Автоматическая маршрутизация по типам задач.
- Встроенная аналитика загрузки команды.

🔘 Матрица компетенций и доступности:
- Кто что умеет делать в команде.
- Текущая загрузка каждого специалиста.
- Планы отпусков и обучения.
- Зоны ответственности по системам.

🔘 База знаний с ИИ-помощником:
- Часто задаваемые вопросы с автоответами.
- Видеоинструкции по типовым операциям.
- Чат-бот для первичной фильтрации запросов.

💬 Особые практики для инхаус команд

✔️ "Договор о сотрудничестве" между 1С-отделом и бизнесом — внутренний SLA с понятными обязательствами сторон.

✔️ "Внутренний консалтинг" — инхаус команда не только исполняет, но и предлагает улучшения бизнес-процессов.

✔️ Система внутренних кейсов — документирование и тиражирование успешных решений между отделами.

✖️ Не становитесь "службой быта" — чётко разграничивайте, что входит в зону ответственности ИТ, а что нет.

🤟 А если интересно послушать реальный кейс автоматизации, приходите на мой доклад 17 октября на конференцию Fin Conf 2025 в Сколково.


➕ Круглый стол о тестировании в 1С: когда серьезные профессионалы говорят о серьезных вещах

В мире 1С есть вопросы, которые заставляют даже бывалых разработчиков почесать затылок. А тестирование 1С — это тот самый вопрос, который превращает спокойную IT-конференцию в настоящее поле для дебатов. 2-3 октября прошла конференция Стачка и я вела круглый стол "Нужно ли тестирование в 1С и кто его должен делать и как?". Что же получилось?

1⃣ Классическая ситуация: "У всех по-разному, но всем нужно"

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

🪄 И все правы! И все неправы! Именно в этом вся соль дискуссии.

2⃣ Почему тестирование 1С — это не шутки?

Несмотря на иронию ситуации, давайте признаем суровую реальность: в 2025 году бизнес продолжает терять миллионы рублей из-за того, что "в 1С что-то пошло не так". Один не может отгрузить 700 заказов в пиковый день после обновления, у другого зарплата сотрудников "улетела" в прошлый квартал после внедрения доработки.

🪄 Звучит смешно, пока это не случается с вами.

3⃣ Главная проблема: все говорят на разных языках

Парадокс тестирования 1С заключается в том, что не только каждая компания понимает под этим что-то свое, но и команды 1С тоже понимают это по-разному:

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

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

4⃣ Реальность круглого стола: расширение кругозора vs решение проблем

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

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

5⃣ Что обсуждали на круглом столе

Основной фокус был на определении — что такое тестирование в 1С.

И тут началось самое веселое — когда теория встречается с суровой реальностью рисков и денег.

🟨 Золотое правило: определяй риски и считай деньги

6⃣ Итог: серьезность под маской легкости

Да, мы можем иронизировать над тем, что у каждого свое понимание тестирования в 1С. Но за этой иронией скрывается серьезная проблема: отсутствие единых стандартов и подходов приводит к реальным потерям.

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

➕ Если на следующем круглом столе кто-то снова скажет "у нас нет времени на тестирование", напомните ему о том, сколько времени уходит на исправление багов на проде. Math doesn't lie, а культура тестирования — это инвестиция в будущее всей индустрии.

🌷 А какой у вас самый острый вопрос в процессах тестирования 1С?


🍸 Вам мартини взболтать или смешать?

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

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

Сценарий №1: "Полное доверие"
Вы: "Вася, делай как считаешь нужным, я в тебя верю!".
Вася: *исчезает на неделю и возвращается с проектом "а-ля натюрель"*
Результат: дедлайн горит, нервы на пределе.

Сценарий №2: "Тотальный контроль"
Вы: *устанавливаете 47 контрольных точек и требуете отчет каждые 15 минут*
Сотрудник: *теряет всякую мотивацию и творческий потенциал*
Результат: формально всё в порядке, по факту – серая масса.

А теперь серьёзно: найти баланс между доверием и контролем – это не просто "управленческая фишечка". Это критически важный навык, от которого зависит:
- Мотивация и вовлеченность команды.
- Качество результатов.
- Ваше собственное психическое здоровье.
- Успех бизнеса в целом.

Золотая середина существует! И она не в том, чтобы "немножко доверять и немножко контролировать". Это совершенно другая история о том, как создать систему, где доверие и контроль работают синергично, а не противоречат друг другу.

P.s. "Люди не стулья", как правильно подмечено в докладе. Стулу позволительно вчера, сегодня, завтра оставаться одинаковым, а люди все разные и разные в каждый момент времени!

➡️ А как вы находите этот баланс?


🪶 Мерч — это носитель ценностей или искусство правильного лутания?

Вчера на Стачке была на докладе "Мерч - как главный носитель ценностей. Кейс Illan Communications", и теперь понимаю: мы все это время неправильно лутали корпоративные футболки! 💡

Оказывается, есть целая практически методика превращения коллектива в команду через HR-брендинг и ребята из Otvetdesign рассказывают об этом. Между "взял стикеры с конференции" и "стал лояльным сотрудником" может быть научно обоснованная связь. И это не шутка.

Ключевые инсайты с доклада (серьёзно):

😀 HR-брендинг ≠ красивые картинки — важно не только создать бренд работодателя, но и эффективно внедрить его через реальные взаимодействия (а не просто раздать всем одинаковые рюкзаки).

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

☕ Team Relations как продукт — авторское решение, объединяющее корпоративную культуру и EVP через креативную рамку и gift-стратегию.

Мораль истории. Правильный мерч — это не просто способ потратить маркетинговый бюджет на "что-то осязаемое". Это инструмент, который может реально работать на команду и культуру.

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

P.S. Если ваш мерч используется сотрудниками как тряпка для протирания мониторов — возможно, стоит пересмотреть gift-стратегию ⭐


🗓 ДЕДЛАЙН: что общего у современного ИТшника (или 1Сника) и заключенного времен Гражданской войны в США?

Краткий ответ: правильно — оба знают, что такое deadline! 🔥

Ну, а сейчас подробный ответ, с исторической справкой.

Детальная история для ценителей мрачного юмора

➡️ 1864 год, США, Гражданская война. Командир Генри Вирц в печально знаменитой тюрьме Андерсонвиль (Джорджия) издает приказ: провести "линию смерти" в 20 футах от стены тюрьмы. Охранникам дана простая инструкция: "fire upon and kill any prisoner who might touch, fall upon, pass over or under the said dead line".
И эта практика была известна в США не только в Андерсонвиле.

➡️ Поздний 19-й век. Капиталисты подхватили идею! Теперь "deadline" — это возрастной лимит для фабричных рабочих. 35 лет? Извини, старичок, ты уже "мертв" для производства.

➡️ 1919 год. Американские журналисты окончательно "приручили термин". Теперь deadline — это "absolute last minute when copy can be sent to the printer". Опоздал с материалом — номер выходит без тебя. Не расстрел, конечно, но карьерная смерть.

🔔 А теперь про IT-боль. Современные разработчики довели концепцию до совершенства! Теперь у нас есть "crunch time" — когда программист превращается в зомби, работая 60+ часов в неделю. Потому что "надо было еще вчера", а ты только сегодня понял техзадание.

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


📋 Документация в 1С: вы ее писали, вы ее читали, вы ее видели?

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

Перед нами семь ключевых вопросов, ответив на которые, можно смело утверждать, что сформировано понимание — для чего же нужна нам в 1С документация:

1️⃣ Какая цель документации?

Краткий ответ: «Создать иллюзию, что мы понимаем, что делаем» — так честно ответил бы каждый второй аналитик 1С после третьей чашки кофе на 105-ый день проекта внедрения 1С.

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

2️⃣ Для чего документация?

Документация нужна для того, чтобы (и это лишь некоторые варианты, на самом деле их гораздо больше):
- Передать проект новому разработчику без риска получить от него месть.
- Объяснить бизнесу, почему "простая" доработка займет 3 недели.
- Защититься от менеджеров фразами типа "Это не было в техзадании!".

Как говорится: "Нет документации — нет проблем. Есть документация — проблем в разы больше".

3️⃣ Для кого документация?

Краткий ответ: для всех и для никого одновременно! 😋

- Для разработчиков — чтобы понимать, что творили предшественники.
- Для пользователей — чтобы не звонили каждые 5 минут с вопросом "А где кнопочка?".
- Для менеджеров — чтобы было что показать клиенту и сделать вид, что деньги потрачены не зря.
- Для всех-всех-всех!

Парадокс: документацию пишут те, кто в ней не нуждается, для тех, кто ее не читает.

4️⃣ Кто пишет документацию?

Краткий ответ: вот тут начинается самое интересное! По идее — технический писатель.
🔜 Кто это такой в 1С?!? 🔙

На практике:
- Программист — со слезами на глазах и проклятиями.
- Аналитик — который "быстро накидает" на 50 страницах.
- Стажер — потому что "ему надо набираться опыта".
- Тот, кто не успел сбежать с совещания 🤩

А, технический писатель на 1С-проекте — это как единорог: все о нем слышали, но мало кто видел.

5️⃣ Что содержится в документации?

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

А еще: техзадания, инструкции, схемы интеграций, и обязательно — раздел "Известные проблемы", который занимает 80% всего документа.

6️⃣ Критерии оценки документации?

Хорошая документация — это когда:
- Новый сотрудник может разобраться в проекте за неделю, а не за месяц.
- Количество вопросов "А как это работает?" снижается с 50 до 30 в день.
- Заказчик перестает говорить "Но мы же договаривались по-другому!".

Плохая документация — когда проще переписать систему с нуля, чем понять, как она работает.

Критерий оценки: "документация как вино: чем старше, тем менее соответствует действительности" ☕️

7️⃣ Как правильно оформлять документацию?

Золотые правила оформления документации в 1С:

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

🔸 Если тема интересна приходите 24 октября на Желтую конфу! Подробнее о программе и регистрация тут.

❔ Ну а как вы считаете, документация — это зло или польза для всех?


🎙️ Пять типов бизнес-правил (подходят и для 1С). И как это все применять?

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

🤍 Факты (Facts) — "очевидные" истины бизнеса

Это базовые утверждения о предметной области, которые всегда верны. Например, "ведение бухгалтерского/налогового учета предприятия" — неоспоримый факт российского бизнеса.

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

🤍 Ограничения (Constraints) — железные рамки системы

Определяют границы допустимого поведения. Пример: "система ограничивает возможность ввода информации исполнителями согласно установленным для них должностным обязанностям".

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

🤍 Активаторы операций (Action Enablers) — триггеры бизнес-логики

Правила, которые при выполнении условий инициируют определенные действия. Например: "система осуществляет автоматический расчет НДС к вычету на основании данных введенных операций".

В 1С это: обработки событий, автоматические операции при проведении документов. Поступил товар — рассчитался НДС, закрыт месяц — пересчиталась себестоимость.

🤍 Выводы (Inferences) — умные заключения системы

Логические заключения на основе имеющихся данных и правил. Пример: "автоматический расчет постоянных и временных разниц" между бухгалтерским и налоговым учетом.

В 1С это: расчет итогов, формирование отчетов на основе накопленных данных. Система сама "понимает", какие проводки делать и как формировать баланс.

🤍 Вычисления (Computations) — математика бизнеса

Формулы и алгоритмы для расчета значений. Пример: "автоматический расчет налога на прибыль на основании данных введенных операций".

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

🤍 Практическая магия: как применять в реальных проектах 1С

Шаг 1: Выявите истинные бизнес-цели

Не принимайте на веру фразы типа "нам нужна 1С". Копайте глубже:
- Зачем вам автоматизация?
- Какие проблемы решаете?
- Как будете измерять успех?

Шаг 2: Декомпозируйте цели в требования

Каждая бизнес-цель должна породить 3-7 конкретных бизнес-требований с критериями успеха.

Шаг 3: Выделите бизнес-правила

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

Шаг 4: Проверьте покрытие

Убедитесь, что каждая бизнес-цель покрыта требованиями, каждое требование — правилами, каждое правило — функциями в 1С.

🤍 Заключение: от хаоса к системе

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

Помните золотое правило:
- Бизнес-цели отвечают на "ЗАЧЕМ?"
- Бизнес-требования — на "ЧТО?"
- Бизнес-правила — на "ПО КАКИМ ЗАКОНАМ?"
- Ну а функциональные требования — на "КАК?" (о них, я думаю, поговорим в следующий раз).

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

И да, когда в следующий раз заказчик скажет "хочу как у конкурентов", спросите: "А какую бизнес-цель это поможет достичь?" Возможно, ему нужно совсем другое решение.

🤍 И важный вопрос, а какие типы бизес-правил были в вашей практике?

Ставьте лайк, если было полезно! 😉


🔊 Бизнес-правила в действии: когда "константы" оказываются переменными

Друзья-автоматизаторы! Вчера был задан очень хороший вопрос: могут ли бизнес-правила меняться, а до реализации бизнес-цели, что же делать в этом случае?

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


✏️ Могут ли бизнес-правила меняться? Еще как могут!

Короткий ответ: Да, и еще как!

Длинный ответ: 30-45% бизнес-правил меняются относительно быстро, некоторые — даже быстрее, чем выходят релизы нашей системы. Это зависит от природы правила:

🔸 Неизменные правила (0,1% от всех)
Примеры: математические формулы, физические константы.
Подход: можно жестко закодировать в системе.

🔸 Редко изменяющиеся (10-15%)
Примеры: налоговое законодательство, отраслевые стандарты.
Частота: 1 раз в несколько лет.
Подход: вынести в настройки системы с возможностью обновления.

🔸 Периодически изменяющиеся (40-50%)
Примеры: корпоративные политики, лимиты, ограничения.
Частота: 1-2 раза в год.
Подход: конфигурационные файлы или настраиваемые переменные.

🔸 Часто изменяющиеся (25-30%)
Примеры: коммерческие условия, тарифы, акции.
Частота: ежемесячно.
Подход: удобный интерфейс для бизнес-пользователей.

🔸 Очень изменчивые (5-10%)
Примеры: операционные настройки, временные правила.
Частота: еженедельно или чаще.
Подход: максимально гибкая система управления правилами.

✏️ Что делать, если правило изменилось ДО автоматизации?

Тут два сценария, и оба неприятные:

🔹Сценарий 1: изменилось внешнее правило.
Пример: НДС изменился с 18% на 20% во время проекта.
Что делать: обновить требования и все расчетные алгоритмы ДО запуска.
Влияние: средневысокое — придется пересматривать формулы и тестировать заново.
Убрать нельзя: Это требование закона, игнорирование чревато штрафами.

🔹Сценарий 2: бизнес передумал.
Пример: фирма изменила политику скидок с 10% на 15%.
Что делать: пересмотреть алгоритмы расчета, обновить ограничения в системе.
Влияние: среднее — в основном настройка параметров.
Убрать можно: это корпоративное решение, бизнес вправе его изменить.

Главное правило: лучше изменить правило ДО запуска, чем потом долго и мучительно переделывать рабочую систему.

✏️ Что делать, если правило изменилось ПОСЛЕ автоматизации?

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

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

✏️ Заключение: правила как живая система

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

Важно помнить:
- Правила меняются — это факт жизни, а не исключение.
- Внешние правила (законы) убрать нельзя, но можно адаптировать их.
- Корпоративные правила можно менять, но с пониманием последствий.
- Хорошая архитектура системы решает 90% проблем с изменениями правил.

И да, когда заказчик в следующий раз спросит: "А можно это правило убрать?", не впадайте в панику. Спросите: "А что конкретно это правило мешает достичь?" Возможно, проблема не в правиле, а в том, как оно реализовано.

ℹ️ Если после внедрения системы заказчик ни разу не попросил изменить бизнес-правило — у вас два варианта: либо вы создали идеальную систему, либо бизнес умер. Статистика говорит, что второй вариант более вероятен.

Ставьте лайк, если было полезно! 😉 И пишите в комментариях, когда бизнес-правило у вас на проекте менялось сразу после запуска системы и приходилось все переделывать. Было же такое?


🤍 Бизнес-правила К. Вигерса в автоматизации 1С: когда правила игры становятся правилами кода?

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

Священная иерархия: от "хотелок" к коду

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

🤍 Бизнес-цели (Business Objectives) — "светлое будущее" компании.

Отвечают на сакраментальный вопрос "ЗАЧЕМ?". Это высокоуровневые стратегические цели организации, которые должны быть измеримыми и достижимыми.

🤍 Бизнес-требования (Business Requirements) — конкретизация мечты

Бизнес-требования отвечают на вопрос "ЧТО нужно достичь?". Они берут абстрактные цели и превращают их в конкретные, измеримые результаты с критериями успеха.

Как бизнес-цели становятся бизнес-правилами: практическая магия

Теперь внимание! Здесь происходит самое интересное.

🤍 Бизнес-требования порождают бизнес-правила. Это не одно и то же, хотя многие путают эти понятия из-за общего слова "бизнес".

Бизнес-правила — это внешние ограничения, которые говорят системе "по каким законам жить". Они существуют независимо от того, автоматизируете вы их или нет.

🤍 Критерии успеха: когда цели становятся результатами

Каждое бизнес-требование должно иметь измеримый критерий успеха. Это мостик между абстрактными целями и конкретными результатами.

Почему эта иерархия критична и для 1С тоже?

Во-первых, без понимания бизнес-целей вы рискуете автоматизировать не то, что нужно. Заказчик просит "систему для учета", а на самом деле хочет "снизить трудозатраты на отчетность на 50%".

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

В-третьих, бизнес-правила — это константы вашего проекта. Они не меняются от релиза к релизу, в отличие от функциональных требований. НДС 20% — это бизнес-правило, а кнопка "Рассчитать НДС" — функциональное требование.

🤍Пример🤍

Бизнес-цель: сократить срок формирования отчетности по МСФО.
🤍
Бизнес-требование: система должна обеспечивать формирование отчетности по МСФО.
🤍
Бизнес-правила:
- Доступ к данным ограничен должностными обязанностями (тип правила: ограничения).
- При вводе операций автоматически формируются проводки по МСФО (тип правила: активаторы).
- Отчеты формируются по формам, утвержденным на группу компаний (тип правила: факт + вычисления).
🤍
Критерии успеха: система должна обеспечивать возможность подготовки и формирования отчетности по МСФО в срок до N дней после завершения отчетного периода.

🤍 А в следующем посте расскажу пяти типах этих самых бизнес-правил и как это реализовать на практике.

🤍 А вы описываете бизнес-правила, бизнес-требования на проектах 1С?


⭐️ Кто куда, а я на Стачку!

📍 2 октября в 14:05 я организую круглый стол "Нужно ли тестирование в 1С и кто его должен делать и как?"

⭐ Уже вечный спор в 1С

- Тратить время на тестирование или быстрее сдавать проект?
- Кто должен тестировать — разработчик, тестировщик или аналитик?
- Как не превратить тестирование в пустую формальность?

⭐ Обсудим жаркие вопросы

- Баланс качества vs скорости разработки.
- Универсальные принципы или индивидуальный подход.
- Реальные кейсы успехов и провалов.
- Практические советы для команд.

⭐ Для кого это будет полезно

- Разработчики 1С (от джунов до архитекторов).
- Тестировщики и QA.
- Руководители проектов и техлиды.
- Владельцы IT-бизнеса.

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

💬 Будет интерактивно: живое обсуждение, кейсы из практики, QR-код для ваших вопросов.

↗️ Билеты уже доступны на сайте. Https://nastachku.ru/bilety

🌱 Ну а для моих подписчиков есть промокод на скидку 10% - Спикер10.

Ставь реакцию, если тема актуальна для тебя!

Показано 20 последних публикаций.

271

подписчиков
Статистика канала