Во втором выпуске четвертого сезона подкаста Радио “Аналитик“ обсудили, когда и почему в сфере 1С задумались про DevOps, есть ли отличия в практиках DevOps для 1С от практик других стеков, какие инженерные практики сейчас наиболее распространены и что нас ждет в будущем.
Гость эфира: Алексей Лустин, директор по развитию, Инфостарт
Ведущая подкаста: Мария Серёгина
О чём поговорим:
00:00 - Про профессиональный путь Алексея.
03:00 - Как Алексей познакомился с DevOps.
07:21 - Есть ли отличия в практиках DevOps для 1С от практик других стеков.
12:57 - В какой момент в сфере 1С задумались про DevOps.
43:00 - Почему инструменты, которые создавались для аналитиков, стали инструментами для инженеров и QA.
57:12 - Какие инженерные практики сейчас наиболее распространены и что нас ждет в будущем.
Каждый архитектор и руководитель 1С-проектов рано или поздно сталкивается с выбором: продолжать латать старую систему или снести всё до основания и заложить правильный фундамент.
Что делать, если появились "золотые гвозди"?
Когда система на "пластырях" не работает.
Клиент может попросить оценку уже на первой встрече, когда вместо ТЗ есть только общее описание задачи, а внутри действующего проекта от команды обычно ждут намного более точную цифру. На основании своего опыта, описала, какой информации достаточно для предварительной оценки, что должно быть проработано перед финальной, какие допущения нужно фиксировать и в какой момент вместо точного количества часов лучше назвать диапазон.
Во втором выпуске пятого сезона подкаста Радио “Аналитик“ поговорили про связь ML с LLM, какие метрики используются при работе с LLM и какие знания и навыки нужны, чтобы внедрять ML и LLM в ИТ-продукт.
Когда я работала специалистом по системе менеджмента качества в компании, занимающей внедрением 1С, регулярно сталкивалась с такой ситуацией - в базе знаний может лежать десяток регламентов, шаблонов и методичек, однако аналитики продолжают оформлять ТЗ по-разному, оценки собирать в переписке, а важные договоренности искать в старых протоколах. Из аудита в аудит всплывали одни и те же несоответствия и одни и те же причины. Став уже позже бизнес-аналитиком, я поняла, что проблема часто не в дисциплине сотрудников, а в самих стандартах, которые существуют отдельно от ежедневной работы. В статье постаралась разобрать, какие документы действительно приносят пользу и помогают аналитикам в ежедневной работе.
Описание крупного процесса может согласовываться месяцами: пока аналитик уточняет исключения в одном блоке, устаревают решения по другому, а разработка ждет финальную версию документа. В статье разберу, как делить требования на самостоятельные пакеты, определять границы приемки, фиксировать зависимости и запускать работу, не дожидаясь идеального описания всего процесса.
Компромиссы в проектах автоматизации часто не решают конфликт, а лишь откладывают проблему и оставляют под угрозой потребности обеих сторон. На трех типичных ситуациях – споре с заказчиком об оценке, конфликте с разработчиком вокруг требований и сопротивлении пользователя новой версии – показываем, где участники на самом деле спорят не о действиях, а о неопределенности. Объясняем, как в теории ограничений работает инструмент «туча» и почему любая проблема в ТОС рассматривается как конфликт. Показываем, почему в возможность win-win-решения выгоднее верить и как такой подход помогает искать не компромисс, а более устойчивое решение.
Финансы, юристы, продажи, кадры и разработка могут смотреть на один процесс по-разному. В статье разбираю, почему конфликт требований появляется еще до разработки, чем опасно просто собрать пожелания всех сторон и как аналитику сделать спорные места видимыми до приемки и релиза.