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

Две буквы, на которых держится российский бизнес. В новом выпуске подкаста «Программный комитет» говорим об 1С — системе, которая помогает автоматизировать процессы в тысячах компаний. Анастасия Штей, руководитель отдела сопровождения финансового учёта ecom.tech/1C и автор телеграм-канала «Нет глупых вопросов», расскажет, какие навыки требуются для работы с программой, зачем она нужна бизнесу и как развивается платформа сегодня. ▶️ Смотреть | ▶️ Слушать 😮 Мы снимали этот подкаст на международной IT-конференции «Стачка»! В этом году она пройдёт 10-11 апреля в Ульяновске и 3-4 октября в Петербурге.

Если вы интересуетесь темой развития себя и сотрудников, значит этот пост для вас! ⤵️ Сегодня мы открыли запись круглого стола «Индивидуальный план развития: взгляды с разных сторон» с конференции Saint TeamLead Conf 2025 🔥 Этот круглый стол — диалог о роли ИПР в современных IT-командах. Особое внимание уделено практическим аспектам внедрения ИПР в рабочие процессы. Как найти баланс между долгосрочными целями развития специалистов и сиюминутными проектными задачами? Как избежать превращения ИПР в галочку в системе оценки? Участники вместе с экспертами разобрали реальные кейсы успехов и неудач при реализации программ развития в командах разного масштаба. Эта дискуссия — отличная возможность услышать об опыте коллег, получить новые идеи для своей команды и взглянуть на привычные инструменты с неожиданной стороны. P.S. Не обошлось без азарта — в команде спикеров присутствует тот, «кто против». Удалось ли ему переубедить коллег и зрителей? ✋ Если у вас есть своя тема для круглого стола — отправляйте заявку в программу на Saint TeamLead Conf 2026 ⏳ Дедлайн приема заявок — 20 февраля

Опубликовали запись вебинара в формате круглого стола на тему «Круглый стол: Искусственный интеллект в работе 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-бота. Технологии работают на вас — используйте их с умом! 🟧

🔍 Чек-лист внедрения культуры документирования: путь к прозрачности в 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 — классика бессмертна 🗑⚡️ #СловоДня #КопилкаЗнаний

🌷 Кто сказал, что документация на проектах 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С не стоял на месте, а использовал лучшие практики ИТ-мира. Но горящие сроки, авралы, есть в любой профессии. И не важно, откуда пришел термин, важно помнить, что для всего есть время!