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