Кто такой аналитик 1С
Мы часто спорим про ответственность. Задаемся вопросом, чем должен заниматься аналитик, чем должен заниматься разработчик. Как только начинается такой спор, мне сразу вспоминается фраза, давно ставшая мемом: «аналитик не должен лезть в конфигуратор».
Но не в том ли причина бесконечности этих споров, что у нас нет четкого ответа на вопрос «кто такой аналитик», и поэтому мы определяем его роль через запреты: «нельзя в конфигуратор», «не лезь в код», «не проектируй»? Список того, что аналитику нельзя, у сообщества давно готов. Список того, что он должен уметь, почему-то нет.
Есть определенный стереотип, что аналитик – это бухгалтер, методист, консультант. Написал ТЗ, поговорил с заказчиком, нарисовал блок-схему, и на этом роль закончилась. Но я убежден, что этот стереотип устарел. Поэтому хочу обсудить, кто такой аналитик сейчас, какими современными навыками и знаниями он должен обладать, и почему они критичны именно в командной работе.
Первый вопрос, которым я задался: кто такой аналитик? Проследим эволюцию его роли – какой она была раньше и какой стала теперь.
Эволюция роли аналитика
Традиционно роль аналитика укладывается в понятную и известную всем фразу: «переводчик требований бизнеса». Это человек, который выступает посредником между бухгалтером, менеджером и разработкой. Он перекладывает неструктурированные ожидания и пожелания бизнеса в понятное разработчику описание функциональности и требования.
Также от аналитика всегда ждали экспертизы в той конфигурации, которую он сопровождает. Это логично: горизонт и стек его задач ограничивались только этой конфигурацией. В свою очередь, такая экспертиза приводила к тому, что человек настолько хорошо знакомился с бизнесом, что мог качественно исполнять функцию оптимизатора учетных задач.
Естественно, аналитику всегда поручалась подготовка документации. Это могли быть требования, инструкции для внутренних отделов компании, описания бизнес-процессов и работы с системой 1С.
Но мир изменился. ИТ-ландшафт компаний расширился: систем стало больше, объемы данных выросли, требования к устойчивости, безотказности и безопасности стали критичнее. Вместе с ними выросли и требования к аналитику.
Теперь зона ответственности аналитика выходит за рамки привычного ему стека. Он осознает или должен осознать, что 1С – это всего лишь один из компонентов IT-ландшафта компании.
Планируя реализацию какой-либо функции или доработки, особенно межсистемной, аналитику важно определять границы систем, зоны их ответственности и функциональное назначение, а также потоки данных, которые между ними перемещаются.
Поэтому описание бизнес-процессов уже не может ограничиваться одной конфигурацией 1С. Недостаточно нарисовать процесс внутри 1С и пометить, где данные входят и выходят. Диаграмму приходится продлевать на все системы, с которыми работает пользователь, и описывать сквозной сценарий целиком.
Когда систем много, перед аналитиком всегда встает задача их интеграции. Фокус внимания здесь смещается на выбор решений, которые обеспечат выполнение нефункциональных требований: к скорости передачи данных, доступности, надежности и, разумеется, безопасности.
Интеграции редко делает одна команда: привлекаются подрядчики или смежные отделы со своими стеками, и далеко не всегда они понимают, что такое 1С. Аналитику приходится координировать задачу с обеих сторон: объяснять «за 1С» и при этом самому понимать терминологию других стеков.
Все это приводит нас к выводу: аналитик 1С – уже не только 1С-аналитик и точно не просто «переводчик». Это проектировщик взаимодействий, который держит в голове логику бизнес-процессов, проходящих через всю ИТ-экосистему компании, актуальные архитектурные решения и технические ограничения как платформы 1С, так и других технологий.
В качестве аргументов приведу несколько источников. Профессиональный стандарт «Системный аналитик» (06.022) начиная с пятого квалификационного уровня, что примерно соответствует уровню middle, относит к трудовой функции аналитика выработку технических решений, включающих детали реализации, и описание программно-технической структуры (дизайна) системы с делением до уровня подсистем и элементов поставки.
Есть также несколько выдержек из материалов Университета Лимерика, посвященных обязанностям аналитика. Они указывают на то, что аналитик должен обладать широким набором компетенций и стратегическим видением.
Все эти компетенции я предлагаю разложить на три слоя.
Первый блок – фундаментальные, базовые технические компетенции, опирающиеся на специфику платформы 1С. Они позволяют аналитику лучше понимать свою команду и ставить перед ней реализуемые задачи.
Второй слой – глубокие технические навыки, нужные при проектировании задач, которые затрагивают множество систем и интеграции между ними. Главное здесь: понимать возможности технологий и расширять инструментарий за рамки стека 1С.
Третий слой – нетехнические навыки, которые превращают технические знания в практику. Без них весь технический инструментарий остается энциклопедическим знанием и не более.
Первый слой: технический фундамент 1С
Если говорить о техническом фундаменте, современный аналитик должен точно понимать, что такое метаданные, каково назначение объектов и какие базовые возможности у них есть: виртуальные таблицы регистров, режимы проведения документов, системные перечисления. Без этого не описать требование так, чтобы его действительно можно было реализовать.
Аналитику нужен язык запросов. Не для того, чтобы заменить разработчика при создании отчета, а чтобы самостоятельно анализировать данные в системе, проверять гипотезы и валидировать требования на корректность и реализуемость.
Навыки чтения кода и отладки дают аналитику техническую автономность. Чтобы понять, где именно болит у конфигурации, не нужно отвлекать дорогого старшего разработчика: достаточно открыть конфигуратор, включить отладку и пройти по стеку вызовов. Разработчику передается уже локализованное место в коде, а не только лишь описание симптомов.
Как бы странно и непопулярно это ни звучало, аналитику полезно знать стандарты разработки. Речь идет и о стандартах вендора (v8std), и о паттернах и лучших практиках, принятых в 1С-сообществе, в типовых конфигурациях и открытых библиотеках. Это дает два эффекта: аналитик описывает более реалистичные (а порой, уже существующие) способы и варианты реализации, а результат работы разработчика становится для него ожидаемым, потому что оба опираются на одни и те же паттерны.
Но, как я уже говорил, одной платформой 1С сыт не будешь. Поэтому необходимо выходить за ее рамки.
Второй слой: System Design
В качестве термина, который описывает глубокие технические знания и навыки, я выбрал достаточно популярное понятие – System Design.
System Design – это дисциплина, которая отвечает на ряд вопросов:
-
как системы интегрируются между собой,
-
как хранить и передавать между ними данные,
-
как управлять этими данными
-
и как обеспечить выполнение нефункциональных требований.
Уложить все многообразие технических направлений в одну статью невозможно. Поэтому дальше я ограничусь вопросами, на которые аналитику приходится отвечать при проектировании, и именами паттернов, по которым эти ответы легко найти самостоятельно.
Проектирование интеграций
Когда мы говорим о множестве систем в зоне ответственности аналитика, речь неизбежно заходит об интеграциях. При их проектировании всегда возникает ряд вопросов, на которые аналитик отвечает еще до передачи задачи в разработку. Все они вытекают из требований к самой интеграции.
Аутентификация. Как системы поймут, кто есть кто, и выдадут доступ к ресурсам? Варианты: API Key, Basic Auth на веб-сервере, JWT, OAuth 2.0 (и тогда какие scope нужны конкретной интеграции?).
Тип интеграции. Интеграции бывают синхронными (запрос и ответ в одном вызове), асинхронными (через очереди сообщений) и событийными, которые по механике тоже асинхронны, но инициируются событием в системе-источнике (webhooks). Выбор типа вытекает из требований к задержке и к допустимости ожидания ответа.
Обработка ошибок. Как не допустить ошибок или корректно их обработать? Здесь помогают три известных паттерна.
-
Retries: заложить ограниченное число повторных попыток, если запрос не получил положительного ответа.
-
Idempotency-Key: передавать ключ идемпотентности, чтобы повторная отправка того же POST-запроса не создала дубль данных.
-
Dead Letter Channel, если используется очередь: сообщения, которые не удается обработать, отводятся в отдельную очередь, а не блокируют основную.
Нагрузка. Как управлять нагрузкой при больших объемах? Rate Limiting ограничивает число запросов в единицу времени, Pagination разбивает большой ответ на страницы вместо выдачи всего объема одним ответом.
Визуализация. Как показать модель интеграции так, чтобы все участники, включая смежные команды, видели одну и ту же картину?
Для интеграций подходит диаграмма последовательности UML (Sequence Diagram), а в качестве инструментов – PlantUML и Mermaid: диаграмма описывается кодом (подход Diagrams-as-code). Бояться этого не стоит. Такие диаграммы версионируются, быстро создаются и легко исправляются. Это не пиксели, которые приходится передвигать в draw.io.
Контракт. Как договориться с другими командами о деталях, которых на диаграмме нет? Здесь работают контракты, одинаково читаемые всеми участниками интеграции: спецификация OpenAPI (Swagger) для синхронных API и AsyncAPI для асинхронных. Контракт хранится и версионируется как код (подход Docs-as-code).
Тестирование и проверка гипотез. Как проверить интеграцию до вывода в прод? Для API это Postman или Insomnia, для очередей - веб-консоли самих брокеров (RabbitMQ, Kafka) на тестовом контуре.
Управление данными в гетерогенном ландшафте
Современные задачи управления данными решаются в гетерогенном ландшафте: данные живут в 1С и одновременно в базах других систем.
При проектировании аналитику нужно разбираться, чем отличаются типы баз данных, когда каждый из них уместен и почему смежная команда выбрала именно свою базу.
Нужна строгая транзакционность: реляционные базы (PostgreSQL, MS SQL).
Нужна гибкая, меняющаяся структура записей: документные (MongoDB).
Нужна работа с большими объемами данных и аналитические запросы по ним: колоночные (ClickHouse, Apache Cassandra).
Нужна максимальная скорость чтения: in-memory хранилища «ключ – значение» (Redis).
При проектировании данных, в том числе при работе с API, необходимо помнить о паттерне CRUD. Он описывает базовые действия, выполняемые над объектом данных: Create – создание, Read – чтение, Update – обновление, в том числе обогащение, и Delete – удаление.
Ценность его не в расшифровке аббревиатуры, а в четырех вопросах, на которые при проектировании обязан ответить аналитик:
-
где и как объект создается;
-
кто имеет к нему доступ на чтение;
-
кто, где и как его обновляет, включая обогащение данными из других систем;
-
кто и как его удаляет.
Операция, которую не предусмотрели, обычно и становится источником кучи проблем на этапе эксплуатации.
Еще два паттерна – ETL и ELT (Extract-Transform-Load и Extract-Load-Transform). Они определяют, в какой момент данные преобразуются в формат системы-получателя: до загрузки в нее или уже внутри.
От этого выбора зависит, какая система несет ответственность за трансформацию и на кого ложится нагрузка: на источник, на приемник или на промежуточный слой.
Компромиссы при проектировании систем
При проектировании аналитик постоянно сталкивается с противоречиями между требованиями и вынужден идти на компромиссы.
Фундаментальный пример такого компромисса описывает теорема CAP: распределенная система не может одновременно гарантировать все три свойства, по первым буквам которых она названа.
Согласованность (Consistency). Данные в любой точке входа всегда актуальны, а если источник недоступен, система возвращает ошибку, а не устаревшие данные.
Доступность (Availability). Каждый запрос получает ответ, даже если данные в нем отстают от истины на некоторый лаг.
Устойчивость к разделению (Partition Tolerance). Система продолжает работать, даже если связь между ее узлами прервана.
Для интеграций устойчивость к разделению практически всегда обязательна: сеть между системами рано или поздно рвется. Поэтому реальный выбор аналитика лежит между согласованностью и доступностью.
Банальный пример: синхронизация остатков между 1С и интернет-магазином.
Путь согласованности: магазин при каждом обращении к остаткам вызывает сервис в 1С и, если 1С недоступна, показывает ошибку.
Путь доступности: остатки дублируются на стороне магазина и обновляются из 1С по регламенту; магазин работает всегда, но данные в нем отстают.
Какой путь правильный, решают не технологии, а требования: сколько стоит бизнесу продать товар, которого уже нет на складе, и сколько стоит не продавать ничего, пока 1С на обслуживании.
Отсюда практическое правило. Прежде чем выбирать тип интеграции и паттерны, фиксируются нефункциональные требования к ней: допустимое отставание данных (согласованность), доступность, нагрузка и безопасность. Именно эти характеристики проектируемого решения заслуживают внимания в первую очередь, потому что все дальнейшие технические решения из них следуют.
Инженерные практики
Последние по порядку, но не по значению: инженерные практики. Их часто считают делом разработчика, DevOps-инженера или системного администратора, но аналитик имеет к ним самое прямое отношение.
Тестирование. Аналитик автор требований, и именно он первым задается вопросом, проверяемы ли они в принципе.
Поэтому для каждого вида тестирования аналитик определяет критерии успеха: что считать ошибкой, а что ожидаемым поведением системы.
CI/CD и деплой. Аналитик чаще всего сдает работу заказчику, а значит, обязан понимать, когда и как изменение попадет в продуктивный контур, какие подготовительные действия для этого нужны (например, миграция данных), насколько быстро можно откатить изменение или выпустить хотфикс при инциденте.
Мониторинг и логирование. Именно аналитик знает, какие события в системе критичны для бизнеса. Поэтому требования к наблюдаемости формулирует он: что логировать, какие метрики собирать, кого и в какой момент алертить при сбое.
Третий слой: нетехнические навыки
Вы заметили? Чем глубже мы погружались в технические навыки, тем больше вопросов вставало перед аналитиком. Сами по себе технические знания на них не отвечают: они лишь помогают правильно сформулировать вопрос и увидеть варианты решения.
Как аналитик мыслит?
Самый опасный момент в работе аналитика наступает не тогда, когда он не знает, как ему поступить или как ответить на вопрос, а тогда, когда он на сто процентов уверен, что правильно этот вопрос понял.
Критическое мышление: рефлекс задавать вопрос «Зачем?» раньше вопроса «Как это реализовать?» и отказ принимать формулировку задачи за ее суть. Оно помогает правильно сформулировать проблему.
Системное мышление помогает увидеть сформулированную проблему в правильном контексте: не как изолированный объект, а как элемент системы с входами и выходами, обратными связями, смежными процессами и последствиями, которые проявляются не сразу.
Но и системному мышлению требуется топливо, и это топливо – насмотренность. Смотришь на новую задачу и ловишь себя на мысли: «Я где-то это уже видел». Это «где-то видел» не интуиция, а накопленная библиотека паттернов. Строится она целенаправленно: разбором архитектурных решений других команд и проектов и вопросами к собственной команде о технической реализации, не ради кода, а ради ответа «почему именно так».
Четвертый навык – прогностическое мышление. Он связан уже не с тем, как оглядываться назад и использовать собственный или чужой опыт, а с тем, как проектировать изменяемую систему, устойчивую к будущим изменениям.
Речь не о предсказании будущего, а о том, чтобы заложить в дизайн устойчивость к изменениям, которые с высокой вероятностью произойдут: рост нагрузки и объемов данных, новые требования, в том числе от регуляторов.
Как аналитик действует?
Понимая, как аналитик мыслит, перейдем к тому, как он действует.
В первую очередь хочется выделить фасилитацию и управление коммуникациями. Речь не столько о том, как правильно говорить и задавать вопросы, сколько о том, как создавать доверительную атмосферу при взаимодействии внутри команды или между несколькими командами.
Инструмент здесь простой: единый язык и глоссарий, исключающие двойные смыслы. Это не ради бюрократии, а ради исключения дорогостоящего недопонимания.
Принятие решений в условиях неопределенности. Даже собрав всех участников и выслушав каждого, аналитик обнаруживает, что информации все равно недостаточно. Отсюда два умения в одном навыке.
Первое: хорошее решение, принятое вовремя, лучше идеального решения, которое не будет принято никогда.
Второе – работать с компромиссами и trade-off’ами: своевременно фиксировать и описывать их.
Это не про документацию, а про управление: явно зафиксированный компромисс исключает повторные дискуссии и долгие разборы через год на тему «а почему мы так решили».
Заключение
Может показаться, что было перечислено слишком много всего и уместить все эти знания в одном человеке все равно что вырастить нового Эйнштейна. Но повторюсь: никто не просит аналитика быть экспертом во всех технологиях и иметь ученую степень в области мышления.
Все перечисленное укладывается в модель T-shaped-специалиста, и буква T здесь не метафора «немного обо всем», а описание структуры экспертизы.
Вертикаль буквы T обозначает глубину: собственный домен аналитика, то есть выявление, формулирование и интерпретацию требований, проектирование решений, аналитическое мышление.
Горизонталь обозначает ширину: интеграции, базы данных, инженерные практики и вся цепочка нетехнических навыков от критического мышления до принятия решений. Это не экспертиза, а та самая достаточность, чтобы вести продуктивный диалог с каждой командой на ее языке.
Так в чем же нуждается команда? В человеке, к которому приходят, когда решение нужно принять на пересечении бизнеса и технологий. Не потому, что он самый умный, а потому, что у него одновременно есть контекст задачи, кругозор и готовность взять ответственность за выбор. Именно таким человеком и становится T-shaped аналитик.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
