Кем может стать системный аналитик

Ведущие открывают выпуск тревожным вопросом: кто такой системный аналитик, справится ли команда без него и будет ли профессия существовать дальше. Гостя они представляют как человека, который сам занимался системным анализом недолго, но разбирается в архитектуре, управлении людьми и управлении айтишкой. Свою зону Александр описывает коротко: клиентские интерфейсы, маркетинг и вовлечение — то, через что клиенты и даже не клиенты взаимодействуют с компанией: реклама в интернете, мобильное приложение, веб. Плюс архитектурная функция — сделать архитектуру и проектирование в компании лучше. На просьбу объяснить, что такое архитектура, он отвечает, что книжки про архитектуру часто тратят первые пятьдесят страниц на определение: система состоит из частей, части взаимодействуют, а изменения в них дорогие и плохо обратимые. Поэтому проектирование — это способ заранее подумать о том, что тебя ждёт, и принять оптимальное решение.

Свой год в системном анализе Александр вспоминает как микс с бизнес-анализом: он уже побыл джуниор-разработчиком, пошёл в магистратуру по системному анализу и управлению, а руководителем оказался операционный директор. Домен — планирование сборки системных блоков: в группе компаний большая продавала комплектующие, а меньшая собирала из них блоки для розничных сетей. Самописная разветвлённая система хорошо поддерживала продажу запчастей, а сборка была сделана «сбоку»: ты договорился отгрузить полторы сотни блоков, а сосед из большой компании продал обещанные процессоры. Кончилось всё ответом со стороны ИТ: придумано классно, но делать не будем — оборот младшей компании был десятой частью от основной, и доработки не отбивали себестоимость инженерной команды. Отсюда решение отвечать за реализацию самому. Павел рассказывает зеркальную историю: он миновал программирование и анализ, попал сразу в solution-архитектуру и ушёл, потому что его решения реализовывались через годы или не реализовывались вовсе. Александр отвечает, что роль технического директора как раз соединяет проектирование с ответственностью за реализацию, хотя держать одновременно менеджерский и технический фокус тяжело.

Совет попробовать себя проджект-менеджером Александр расширяет: работать проектно полезно и инженерному менеджеру, и техническому директору. У любого инструмента есть границы применимости — спорят про продуктовый подход, Scrum, Kanban, SAFe и LeSS, — а проект хорош там, где зафиксированы объём и дата и есть команда. Большая часть продуктов банка так и запускалась: первую версию делали проектом — сначала инвестиции вместе с партнёром, потом собственный брокер, — а дальше внутри появлялись гипотезы и начинался продуктовый подход. Бывают и горизонтальные проекты вроде ребрендинга или смены дизайна, которые кому-то нужно драйвить. Аналитик, глубоко погружённый в домен и связанный со всеми стейкхолдерами, вполне может взять на себя проектное управление — «никакого rocket science там нет» — и выступить проджект-менеджером, а на следующих стадиях продакт-овнером; выступать, добавляет он, аналитик может почти кем угодно, был бы скилл.

В продукте меняется сам концепт ответственности: не срок сдачи проекта, а аудитория, сценарии, экономика и план развития; подходы гость перечисляет по памяти — user story, customer journey map, jobs to be done — и замечает, что айти цикличен и переобувает идеи, как магазин, где «теперь наш любимый цвет розовый». Другие траектории: аналитик, который лучше всех понимает сложную систему, становится её техническим продактом, а тот, кто знает «кубики» платформы, — solution-архитектором: к нему приводят бизнес-линию с запросом, и он понимает, что есть из коробки и сколько стоит доработать сценарий. На вопрос Есении про моду Александр отвечает, что идеальных решений не бывает — бывает набор компромиссов и понимание ограничивающего фактора; в пример он приводит Apple Newton, где распознавание рукописного текста делали, по его словам, ребята из России: концепт был верным, но тридцать лет назад технологии не позволяли его вытянуть. Продукты, по его наблюдению, живут по-разному: одни закрываются, потому что перестали быть актуальными, а другим внезапно нужно втрое больше фич, потому что прежний лидер решил уйти с рынка, — и нужно это было вчера.

Книжки Александр почти сменил на white papers: вместо двухсот-четырёхсот скучных страниц с повторами — десять страниц, которые проходишь с карандашом, отслеживая взаимосвязи, и инсайтов получается больше. От ведущих звучит возражение: white paper уже прошёл один фильтр — своего автора. В сумке у гостя лежит исследование Google про AI-enhanced API design: одной группе инженеров дали процесс и линтеры, другой — только процесс, третьей — ничего, и первая получила значимо лучшие спецификации при сопоставимых людях. В финальной части спеки, написанные генеративной моделью, оценивали около десяти экспертов с суммарным опытом порядка двухсот лет: пока модель пишет их не очень, но как помощник заметно усиливает автора. Отсюда вопрос ведущих: если ИИ пишет спеки, что остаётся аналитику? Александр советует не бояться, а привыкнуть, что вместе с компьютером человек сделает больше; его собственное опасение в другом — джунам не остаётся простых задач, на которых вырастают синьоры.

Дальше говорят про устройство разработки: западные бигтехи двигаются к модели, где есть инженеры и менеджеры и больше никого, поэтому безопасность, данные и качество приходится платформизировать, оставляя команде контракты, точки интеграции, метрики надёжности и базовое понимание модели угроз. Сильную сторону аналитиков Александр иллюстрирует разговором с CTO Яндекс Клауда Ваней Пузыревским: аналитиков там немного, но они разбирают зарегулированные области и переводят бюрократический язык инженерам на человеческий. Обратный пример — его собственный отдел: пока экспериментами в вебе и мобиле занимались несколько заказчиков, аналитики закрывали требования, но при раскатке А/Б-платформы на всю компанию концепцию пришлось собирать по white papers Google, Microsoft и других, а команды пересобирать. Универсального определения сильного аналитика нет: есть системное мышление, «Азбука системного мышления» Медоуз и типизация, которую начинала Оля Цыганова, — до грейда 14 технолог, дальше выбор между системным и бизнес-анализом.