Доклады с конференций Инфостарта для специалистов 1С
INFOSTART EVENT — это конференции сообщества 1С, которые мы проводим с 2012 года. За это время они стали крупнейшей площадкой для обмена опытом между профессионалами отрасли.
На наших конференциях выступают настоящие практики из ведущих компаний России и СНГ, а не бизнес-тренеры. Доклады отбираются голосованием сообщества, а качество контента контролируют независимые эксперты. Каждая конференция охватывает интересы разных ролей:
для программистов — разработки и архитектурные решения, новые технологии и инструменты,
для аналитиков — методологии, работа с требованиями, анализ данных, управление изменениями,
для руководителей проектов и ИТ-менеджеров — управление командами, рисками, проектами и продуктами,
для специалистов по ИБ и администрированию — практики защиты, эксплуатации и поддержки систем,
для HR и тимлидов — развитие команд, soft skills и современные управленческие подходы.
За годы существования INFOSTART EVENT накопился большой объём уникального контента для всех специальностей из мира 1С. Практически по всем докладам мы готовим подробные транскрибации: они позволяют узнать суть докладов в удобное время и внедрить лучшие практики в своей работе.
Все материалы БЕСПЛАТНЫЕ в открытом доступе и помогают специалистам находить решения, обмениваться опытом и двигать отрасль 1С вперёд.
над каждым докладом работает минимум 6 человек.
За много лет существования Infostart Event у нас накопилось большое количество качественного и уникального контента, и мы рады представить вам эти материалы!
Рассказываем, как использовать библиотеку искусственного интеллекта для 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. Также делимся чек-листом адаптации нового РП и критериями, по которым можно оценить самостоятельность, скорость включения в работу и качество взаимодействия с командой.
После замены устаревшего Java-модуля и реализации высоконагруженного биллинга на 1С 8.5 система обрабатывает более 1 миллиарда событий в месяц, формирует около 3 миллионов актов для 700 тысяч клиентов и работает в inFrame-режиме внутри корпоративной ERP. Разбираем архитектуру решения: слои данных, ретроспективность, drill-down до первичной операции, многопоточный конвейер, RabbitMQ, REST API, Grafana, партиционирование и охлаждение данных. Объясняем, почему именно архитектура данных стала ключом к производительности, масштабируемости и устойчивости системы.
Парсинг техжурнала 1С – это не просто «распарсить JSON» или CSV, а работа с множеством неочевидных особенностей формата. Показываем, какие проблемы могут возникнуть из-за дублей свойств и событий, «полей-призраков», нестандартных имен свойств, разрозненного контекста, кавычек, апострофов и других нюансов, которые легко ломают парсеры и искажают результаты анализа. Объясняем, чем может помочь ИИ при работе с техжурналом и почему даже при использовании современных инструментов важно понимать внутреннюю логику логов. В статье собраны главные правила надежного парсинга и примеры ситуаций, где техжурнал может неожиданно показать свою «темную сторону».
Показываем, как встроить ИИ-помощника в code review 1С без Git, SonarQube и EDT – только с Конфигуратором, RAG-контекстом и набором MCP-инструментов. Разбираем архитектуру решения на Open Web UI и OpenRouter, методику сравнения моделей по Precision, Recall, BonusRate и PenaltyRate, а также объясняем, почему контекст влияет на качество ревью сильнее, чем выбор самой модели. На реальных примерах показываем, какие ошибки ИИ находит хорошо, где все еще нужен архитектор и почему на старте пилота время ревью может не сократиться, а вырасти. В финале делимся метриками внедрения и выводами для команд, которые хотят повторить такой подход у себя.
Разбираемся, почему ИИ-агенты теряют контекст, путаются в инструментах и возвращают неполный результат, если всю задачу пытаться решить одним большим промптом. Показываем, как цепочки пошаговых промптов помогают сделать работу агента повторяемой: каждый шаг выполняет одно действие, имеет понятный вход и выход, отдельно проверяется и при необходимости исправляется. Объясняем, как применять этот подход в задачах 1С: анализировать действия пользователя, подбирать инструкции через RAG, работать с журналом регистрации, MCP-инструментами и локальными моделями. На примерах показываем, как снизить непредсказуемость ИИ-агента и превратить его из «угадывающего помощника» в надежный инструмент для бизнес-процессов.
Разбираем, что на самом деле стоит за образом «руководителя с большой буквы»: личные качества человека, культура компании или сочетание этих факторов. Показываем, как руководителю работать с коллективом через ясность, ритмы, автономию, обратную связь и управление результатом, чтобы команда не жила в постоянных пожарах. Объясняем, почему руководителю не обязательно быть экспертом во всем, но важно понимать предметную область, задавать правильные вопросы и выстраивать процесс принятия решений.
Разбираемся, как уверенность руководителя влияет на управленческие решения: работу с изменениями, требованиями, критическими инцидентами и сроками. Показываем, почему уверенность связана не с внешней жесткостью, а с предсказуемостью, спокойствием, надежностью и умением выстраивать доверительные коммуникации со стейкхолдерами. Объясняем, какие ситуации чаще всего триггерят неуверенность и как через чек-лист определить свои болезненные зоны. Отдельно рассматриваем практики восстановления уверенности – через тело, ментальное состояние, энергию и экспертность.
Кажется, что code-review с помощью искусственного интеллекта устроено просто: достаточно отправить код в LLM, задать промт и получить список замечаний. На практике такой подход быстро упирается в недетерминированность результата, неверную оценку критичности ошибок в 1С-коде и рекомендации, которые сложно отличить от полезных замечаний. Описываем гибридный подход к автокод-ревью: статический анализатор работает вместе с LLM, а база знаний из стандартов 1С превращается в набор машиночитаемых норм. Такая архитектура помогает снизить количество галлюцинаций, точнее определять критичность нарушений и постепенно развивать качество ревью через итеративное пополнение правил.
Когда доработанную 1С не обновляли годами, начинать приходится не с переноса кода, а с разбора того, что вообще накопилось в базе. Там могут быть десятки обработок, расширения, правки типовых объектов, а документации либо нет, либо она давно не актуальна. На примере реального обновления разбираем, как кодовые агенты, MCP-серверы и языковые модели помогают навести порядок в доработках, собрать план миграции, понять, где при переносе будут проблемы, и автоматизировать часть исправлений.
Разбираем AI-навыки, которые помогают специалисту работать с нейросетями не на уровне разовых экспериментов, а как с полноценным рабочим инструментом. Показываем, почему не стоит искать «идеальную нейросеть», как комбинировать разные модели в цепочки и подбирать инструмент под конкретный этап задачи. Отдельно объясняем, как проверять достоверность ответов ИИ, работать с источниками, использовать мультимодальность и передавать контекст через скриншоты, голос, файлы и видео. Также разбираем, почему критическое мышление остается ключевой компетенцией: именно оно помогает формулировать управляемые запросы, находить допущения модели и не попадаться на убедительные, но неверные ответы.
Расскажем, как создать ИИ-помощника внутри 1С без Python и другого внешнего кода – только на базе 1С, HTTP-запросов и необходимой инфраструктуры. Разберем универсальный шаблон RAG-системы, который можно адаптировать под разные задачи: от поддержки пользователей и поиска по базе знаний до работы с регламентами и инструкциями. На живом примере соберем минимальный рабочий прототип помощника, который умеет работать с данными, искать релевантный контекст и формировать ответы. Отдельно объясним, почему самым сложным этапом оказывается не архитектура, а качество подготовки данных и чанкинг.
Любая информационная система имеет ценность только тогда, когда она соответствуеи потребностям и интересам бизнеса. Для этого необходимо разбираться в специфике компании, которую нужно автоматизировать, начинать проект с целей бизнеса и бизнес-требований. В этой статье я помогу разобраться с тем, как подойти к решению этой задачи – как с позиции бизнес-заказчика, так и с позиции представителей ИТ команды. И надеюсь, что она поможет обеим сторонам лучше понимать ожидания и возможности друг друга, делать автоматизацию успешнее
Рассматриваем переход от классической инфраструктуры к облачным моделям и причины, по которым бизнес все чаще выбирает PaaS: скорость внедрения, снижение затрат и отказоустойчивость. Разбираем, какую роль Kubernetes играет в автоматизации, масштабировании и управлении контейнеризированными приложениями, а также можно ли считать 1С Cloud Native-приложением. На примере архитектуры кластера 1С показываем, как компоненты сервера упаковываются в контейнеры, какие ограничения возникают из-за монолитной природы 1С и как их можно обходить. В финальной части объясняем, как Prometheus, Grafana, Loki/ELK и другие инструменты мониторинга помогают контролировать состояние сервиса и делать облачную платформу удобнее для бизнеса.
Архетипы систем помогают увидеть структуру повторяющихся проблем и понять, почему устранение симптомов не всегда приводит к желаемому результату. На примере архетипа «Подмена проблемы», рассмотрим как возникают задержки, уравновешивающая и усиливающая обратная связь, побочные эффекты и зависимость от постоянного «тушения пожаров».
Разбираем, как за пять лет удаленной работы изменились управленческие подходы в ИТ-проектах и какие риски чаще всего возникают у распределенных команд. Проверяем на данных, действительно ли перенос офлайн-подходов в удаленный формат снижает управляемость проектов, увеличивает количество коммуникационных ошибок и замедляет выявление проблем. Отдельно рассматриваем факапы удаленки: расхождения в понимании договоренностей, встречи без камер, сложности с заказчиками, которые по-прежнему предпочитают офлайн, а также влияние удаленного формата на трудозатраты, сроки, текучесть и ФОТ. Статья будет полезна руководителям проектов, тимлидам и руководителям направлений, которые работают с удаленными или распределенными командами.
Разбираем, почему классический бизнес-анализ, построенный вокруг сбора требований и написания ТЗ, все чаще не помогает попасть в реальную проблему бизнеса. На практических кейсах показываем, как переводить требования в гипотезы, проверять их через эксперименты, метрики и данные из системы, а не только через интервью с пользователями. Отдельно рассматриваем, как логи 1С и машинное обучение помогают находить скрытые факторы, убирать лишние функции и улучшать процессы без долгих обследований. Статья будет полезна аналитикам, архитекторам и руководителям проектов, которые хотят перейти от фиксации пожеланий к исследованию того, что действительно работает.
