Рассмотрим на примере вымышленной ситуации
Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, порассуждал о роли аналитика в команде и для этого смоделировал ряд ситуаций, когда к работе над проектом стоит привлекать таких специалистов. О том, что из этого получилось — читайте в статье.
— Аналитики не нужны! — лицо Лаврентия, нового менеджера проекта по внедрению информационной системы по управлению всем (ИС СУВ) не выражало никаких эмоций, а степень решимости была сродни количеству лошадиных сил у грузового локомотива. За плечами Лаврентия — опыт разработки в IT‑гиганте из Fortune 500, с коллегами он изобретал свой особенный форк gRPC и участвовал в эксперименте по переходу на трехчасовые спринты.
— Это же пустая трата времени. Лиды встретились, договорились по параметрам API, реализовали и в прод, — продолжил он и сдвинул брови.
— А документация... — начал было тимлид аналитики Савелий. За его плечами — десятки часов чтения ГОСТ и семь аналитиков.
— Скормим ChatGPT, потом студенты на аутсорсе поправят, — парировал Лаврентий.
— А веб‑интерфейс?
Над Савелием будто сгустились тучи.
— Останемся на прежнем, а если что, — кнопки покрасить не проблема, — отрезал менеджер проекта и кивнул на fullstack Прасковью.
— Да, — отозвалась Прасковья, его вторая жена.
— А…
— Все, за работу! — отчеканил Лаврентий в ответ на пробившиеся было сквозь поток негодования Савелия аргументы и вышел.
В переговорке воцарилось тяжкое молчание. Казалось, тишину нарушает лишь шум разогнавшихся синапсов в головах членов команды.
Савелий украдкой гуглил книгу «Освоить python за 24 часа», а лид разработки Иннокентий задумчиво поглаживал на экране смартфона таблицу с бэклогом в Jira, прикидывая, в какую из ближайших ночей он приступит к приоритетным таскам, и втайне мечтал о времени на рефакторинг.
***
Ситуация в этом проекте получилась не из приятных.
Аналитики как часть команды разработки прочно закрепились на заре развития IT и отвечали за построение бизнес‑процессов, общение с заказчиком, изложение их желаний в понятной программистам форме. Сейчас, когда порог входа в языки программирования снизился, а REST‑интерфейс для простейших CRUD‑операций делается в контекстном меню СУБД, желание срезать косты проектов за счет некодеров все чаще посещает руководство компаний.
В идеальном мире атомарность и спектр задач разработчиков не превышает по сложности конструкторы Lego. Остается только распределить приоритеты в зависимости от уровня должности стейкхолдера в иерархии организации и менять выгоревших разработчиков, словно лампочки. Но всегда есть несколько «но», о которых мы бы хотели поговорить.
Допустим, наш воображаемый ИС СУВ — типичная корпоративная информационная система на базе микросервисов, часть логики которых может через внешние шлюзы использоваться смежными корпоративными ИС. Главная задача ИС СУВ — извлечение прибыли. Делается это ровно до того момента, когда операционные расходы на поддержку и развитие системы ее не превысят.
Микросервисы реализованы на Python, Ruby, Go. (Была замешана даже Java, но только об этом никому не говорите.) Общение между микросервисами происходит по REST, но есть потаенные желания перевести все на gRPC.
Бардак, скажете вы. Нет, это Agile, — скажу я. Когда в ходе разработки испытывались различные гипотезы, наиболее удачные получили свое место в SOA. Конечно, должен быть и архитектор, который бы увековечил стек в граните и отстаивал бы его. Однако в случае с ИС СУВ таковым стал первый разработчик системы, который сделал ее пре‑пре‑бету для автоматизации собственных рутинных задач, будучи еще молодым «зеленым» сотрудником набиравшей обороты корпорации.
Решение получило признание среди руководства, и его вывели в продуктивную среду, а самого разработчика сделали ответственным за ее развитие. Позже место архитектора занял религиозный адепт решений корпорации Google. Затем отставной военный, затем приятель руководителя направления, затем…
Хоровод микросервисов ИС СУВ должен органично встраиваться в технологический ландшафт корпорации и удовлетворять тысячам страниц нормативной документации, которая постоянно дополняется. А еще быть доступным в филиалах корпорации, в том числе и за рубежом с учетом особенностей на местности.
За каждый микросервис отвечает группа разработки, участники которой могут быть в любой момент перетасованы между задачами разных компонентов. Упомянутый выше Иннокентий распределяет задачи исходя из удаленности сотрудников, загрузки, опыта, отпуска, при этом сам не выпускает из рук IDE.
Казалось бы, что может пойти не так?
1. Именование
Базовую сущность ИС СУВ назовем просто «вещь». Как вы думаете, сколько идентификаторов «вещи» будет в нашем зверинце спустя несколько лет гибкой разработки? Они ведутся и в IT Service Management‑системе, дополняя перечень идентификаторов своими внутренними конфигурационными единицами.
В БД компонентов «вещь» зовут vestch_id, thingUUID иногда ID. Просто и понятно.
По соглашению сторон в каждый метод API добавлены поля со временем создания и изменения объекта «вещь». Здесь к списку имен полей его сущности добавляется набор поддерживаемых форматов отображения времени. Изначально использовались вариации ISO 8601, но с выходом ИС СУВ на международную арену стали появляться поля с unixtime.
В зависимости от ситуации пользователи могли опознаваться через UUID, логином в IDM, табельным номером и идентификатором из монструозной кадровой системы (далее — МКС). Даже был мрачный период внедрения, когда идентификатором из МКС служил СНИЛС, который, как выяснилось при миграции данных, присвоен далеко не всем учетным записям. И были технологические учетные записи, но это уже другая история.
Какова роль аналитика?
При должном подходе он чаще остальной команды сталкивается с несовершенством компьютерного диалога и может поднять насущные вопросы типа «а этот ваш vestch_id соответствует thingUUID?». А самое главное, в его власти прописать в постановке тот вариант, который наиболее приемлем и привычен.
Разработчики будут получать линейкой по рукам от тестировщиков за отход от написанного в постановках. Новые аналитики могут опираться на постановки предшественников и перенять ту самую верную формализацию, немного снизив энтропию.
Одни плюсы, никаких минусов и немаловажное следствие: именно аналитик несет ответственность за принятые решения, что позволяет избежать прямых конфликтов конечных пользователей с разработчиками.
2. Обработка ошибок
Формально любое обращение к ИС СУВ, за исключением вопросов прав доступа и аутентификации, может возвращать всего два кода ответа: 200, если все хорошо, и 500, когда нет. Для пользователя вне системы ошибки при взаимодействии между компонентами внутри ИС СУВ вполне удовлетворяют определению HTTP‑ответа с кодом 500.
Истинная причина кроется в логах компонентов, хотя последние тоже могут придерживаться принципов дуализма сообщений в зависимости от дисциплины разработчиков.
Долгое время при минимуме задействованных кодов удавалось играть значениями error message, в котором выводилось кратко, что произошло. Причина на 100% была понятна самому разработчику компонента, на 20% тестировщикам и на сдачу — всем остальным.
Беда пришла откуда не ждали. Новый отдел качества продавил собственную систему оценки KPI сервисов корпорации, который бы позволял оценивать, насколько хорошо ведется разработка систем. В базовом наборе KPI присутствовала метрика в виде числа ошибок 500 сервисов на единицу времени.
ИС СУВ в неравной схватке выбрался в лидеры. Пришлось в срочном порядке вспоминать коды HTTP или экстренно порождать монстров вида {”code”: 200, “message”: “ошибка пятьсот, клянусь”}. Неуместно говорить о навыках разработчиков или о спорных решениях в корпорации, когда на кону премия всего отдела.
Какова роль аналитика?
В обязанности аналитиков входит проработка всех возможных ситуаций и описание соответствующего поведения, а также корректного трейсинга внутренних ошибок компонентов на UI/API. Обжегшийся прежде аналитик будет обязательно учитывать, что если что‑то явно не описано в постановке, то оно не будет реализовано, даже если напрашивается.
Разработчики тоже вносят свою лепту, когда им непонятно, как себя вести при специфичном наборе параметров, но есть и те, кто стремится на скорость закрыть задачу. Поэтому комично‑трагичных ситуаций, как было описано выше, можно отчасти избежать. Или хотя бы не оказаться в топе антирейтинга информационных систем корпорации.
С пресловутым ростом масштабов системы беды не окончились. Когда было принято решение перейти на обмен данными через корпоративную шину данных, появилась задача категоризации и кодирования ошибок от всех потребителей из нее, а стандартный набор кодов HTTP уже не вмещал всей логики.
В этом случае пришлось придумывать свою номенклатуру ошибок и закреплять ее на уровне департамента по развитию IT. Было больно, однако разработка системы не затормозила, поскольку бремя согласования схемы взял на себя аналитик.
3. Бизнес-логика
Как и все вещи на земле, «вещь» может сломаться. Казалось бы, что тут сложного: завел заявку на ремонт, добавил в согласование текущего владельца, после жди выполнения.
Куцая статусная модель и отсутствие видимых поводов для беспокойства позволили создать первую реализацию подсистемы ремонта довольно быстро. Шестым чувством аналитик Савелий почувствовал подвох (из‑за которого был уволен с прошлого места работы) и настоял на добавлении составного поля с маршрутом согласования, а также функции прикрепления документа‑обоснования произвольного формата, на базе которого «честные» 500-ки могли существовать, однако не должны были сказываться на KPI. Ибо мы тут вещи ремонтируем, а не плохо кодим.
Пока ИС СУВ делал робкие шаги в статусе корпоративной системы, тратить значительные усилия на дополнительные задачи (помимо номинально функционирующей логики) казалось избыточным. Разработчики ругались на ненужные необязательные поля, которые усложняли им оперативное закрытие таски, а тестировщики постоянно обнаруживали новые баги в процедуре загрузки документов. Сам формат документов‑оснований не был до конца определен.
Какое‑то время все шло своим чередом, но в один день пришла новость о том, что необходимы ремонт и замена «вещей» в регионах. Позднее была добавлена транспортировка запчастей, в том числе и за границу, и маршрут согласования разросся. Статусная модель, пустив корни в почву, начала уверенно обрастать ветвями, торчащими во все стороны. Был обнаружен побочный эффект — внезапный аудит прошлых заявок, которые не согласовывались с финансистами по очередной форме, однако свой процент у бюджета отделов забирали.
Несомненный успех задумки был омрачен, но не так сильно, как мог бы, поэтому Савелия в этой корпорации увольнять не стали. Переработка имеющейся логики без заложенного базиса наводнила бы отчетность новой порцией 500-к, а премии отдела таяли, как пломбир в жару.
Впрочем, впоследствии логика продемонстрировала плохую гибкость, и было решено доработать ее, когда появился способ по обоснованию приостанавливать функционирование системы без риска получить просадку по KPI отдела сопровождения ИС СУВ.
Какова роль аналитика?
Аналитик несет персональную ответственность за принятые решения, верные и ошибочные. Сложно ругать разработчиков за реализованный код, если он работает стабильно, но делает не то, что требовалось. В случае выше решение аналитика встретило сопротивление со стороны команды, но было продиктовано неудачным опытом на прошлом месте работы. Все подводные камни, «собранные» аналитиком в ходе работы над проектами, формируют уникальный подход к решению задач. А еще отчасти позволяют избежать ситуаций, когда заказчик или вышестоящие сотрудники будут противодействовать внедрению решений.
4. Взаимодействие со смежными командами
UI — отдельная веха развития. Веб‑интерфейс первых релизов ИС СУВ был по‑спартански лаконичен. Автор вдохновлялся новой на тот момент концепцией Material Design. При выходе системы на уровень корпорации ИС СУВ стала белой вороной в прямом смысле этого слова из‑за несоответствия фонового цвета большинства страниц корпоративному брендбуку.
Мало кто всерьез воспринял первую просьбу «поиграть с цветами» от отдела маркетинга, не говоря уже о контрастном тексте для слабовидящих, «ночных» темах и прочем. Отдел маркетинга упрямо доказывал, что просто перекрасить «шапку» страниц и добавить логотип в угол мало, а нужно полноценное оформление по гайдлайнам корпорации, иначе пользователи в незнакомой среде будут путаться и совершать ошибки, стоящие денег. Началась эскалация с последующей раздачей кар небесных.
Задаче повысили приоритет. Савелию совместно с frontend‑разработчиками Прасковьи удалось стрясти оформленный корпоративный UI Kit для стандартизации интерфейса и успокоения буйства отдела маркетинга. Благо Савелий, обивавший пороги отдела маркетинга, был в курсе прогресса в ходе разработки гайдлайнов и держал руку на пульсе сторонней для его отдела активности. Удалось выкроить какое‑то время на маневры с переработкой визуального интерфейса, когда на общей планерке отдел маркетинга сознался, что брендбук сейчас не утвержден.
Но не маркетингом единым жив человек. ИС СУВ оперировала в числе прочего и финансовой информацией, а значит, требовалась специфичная отчетность. После получения первых требований в ближайший спринт была подготовлена выгрузка нужных полей, таск закрыт, все счастливы. До первого финансового мероприятия.
Всего полей в выгрузке было 37, и при печати на листе A4 текст в них напоминал татэгаки, а при ручной разлиновке листа в Excel для печати 4–5 колонок на страницу больше стал походить на пазл. В бухгалтерии твердили какие‑то странные буквосочетания, на поверку оказавшиеся нужной формой отчета, содержащей готовый шаблон компоновки данных.
Дергать разработчиков с просьбой собрать шаблон не было возможно, — когда еще пожар с KPI не потушен. Зато нашему геройскому аналитику Савелию пригодились знание SQL и опыт в%вставь_своего_вендора% Reports. Пускай отчеты строились не в ИС СУВ, но вопросы по оформлению удалось закрыть, а впоследствии и автоматизировать генерацию красивых таблиц на листах A4.
Какова роль аналитика?
Аналитик должен общаться со смежными отделами, выявлять источники требований и согласовывать пути решения. Сложно представить себе выполнение подобной работы руками того же Иннокентия, тимлида разработки, в задачи которого входит сделать сразу и качественно, но не обязательно в срок.
5. Документирование
Корпоративные системы должны сопровождаться определенным пакетом документации, поэтому технический писатель просто взял и написал его. Но не сразу.
О документировании системы пришлось крепко задуматься при передаче ИС СУВ в виде нематериального актива на баланс корпорации. Тогда появились на первый взгляд невзрачные сотрудники из архивного отдела. Они требовали малого — соблюдения правил обслуживания информационных систем, включавших в себя согласование с нормоконтролерами пакета документации.
Каких‑то правил оформления документации, кроме одобрения НК, не прослеживалось, и пришлось погружаться чудесный в мир ГОСТ 19 с элементами ЕСКД, а то и в ISO/IEC FDIS 18 019:2004. Однако ни одно из предлагаемых решений не устроило нормоконтроль. После нескольких итераций было утверждено, что эта задача решается исключительно жестким корпоративным стандартом вплоть до особенных межстрочных интервалов и полей документа, о который все технические писатели смежных систем в свое время поломали зубы и знали как отче наш.
Формальная документация со ссылками на внутреннюю базу знаний отметалась, как что‑то неприятное, пакет из ГОСТ не подходил, потому что корпорация была мало того что коммерческая, так еще и международная.
Согласование затягивалось, писались письма. Но в конце было принято решение сесть и основательно собрать все имеющиеся знания в одном пакете документов по соответствующим разделам.
Савелий, варившийся в среде разработки, обладал компетенциями по сбору информации, а технические писатели занимались оформлением и вколачиванием полученных текстов в шаблоны, да и нормоконтроль уже подустал разворачивать новые версии пакета документов исполнителям. В итоге распечатанная, подписанная и сшитая документация нашла свое место в архиве.
Какова роль аналитика?
Документацию писать не любят. Да и зачем, если у тебя в течение нескольких спринтов в системе постоянно что‑то изменяется, а над головой не висит дамоклов меч государственной приемки. Там, где можно обойтись только пользовательской документацией, привлекают технических писателей. (И перед сном крестятся, чтобы не пришлось готовить пакет сопровождения системы.) Тем не менее незадокументированный проект рано или поздно все же начнет портить кровь руководителям.
С другой стороны, аналитику чаще всего необходимо отвечать на вопросы, откуда взялось то или иное требование, или объяснить соглашения, принятые внутри команды. После череды полученных вопросов Савелий решил размещать ответы на часто задаваемые вопросы в базе знаний и отправлять коллегам ссылки на нее. Был составлен глоссарий проекта, потому что новые сотрудники не сразу могли постигнуть суть «вещей». В отдельном подразделе размещались предложения по доработкам от смежных сотрудников отделов.
Позднее Савелий стал фиксировать схемы решений, которые рисовал не столько ради выполнения задач, сколько для собственного понимания устройства ИС СУВ. Впоследствии накопленной в базе знаний информации хватило, чтобы заполнить ожидаемый комплект документации на 80%. И был человек‑аналитик, ориентирующийся в ней как рыба в воде.
Вместо итога
Чем закончилась эта история? Пожалуй, вымышленный Лаврентий в итоге все же пришел к тому, что аналитики нужны. Пусть и не сразу. И, может, даже не на нынешнем месте работы.
***
Вотчина аналитика — понимание как регламентов организации, пользовательских процессов и решаемых задач, так и работы внутри своей команды.
Действия Лаврентия же не основаны на личных конфликтах или недальновидности. Главная задача вымышленной ИС СУВ — извлечение прибыли, и она может быть решена оптимизацией расходов на ее эксплуатацию.
На разных этапах жизненного цикла любой ИС аналитика может показаться излишней, ведь код не пишется, иных значимых артефактов не появляется, основные угрозы премиям отдела нейтрализованы. Но это не так.
Главная ценность аналитиков — их опыт, накопленные знания и компетенции. Они, конечно, не основа разработки, а скорее штурманы корабля, ориентирующиеся на местности.
Конечно, задачи аналитика могут быть дискретно распределены между другими участниками команды, однако брать на себя какие‑то сторонние задачи захочет не каждый, а тем более нести за них персональную ответственность. В то же время без анализа задач есть риск хождения по чужим граблям снова и снова.
Когда время и деньги позволяют, есть возможность передать задачи анализа, например, лиду разработки Иннокентию из вводного раздела, но последствия этого шага непредсказуемы.
***
Статья носит юмористический характер. Сама ИС СУВ — это собирательный образ из различных кейсов, с которыми сталкивались аналитики в нашей команде. К реальной жизни ни сама система, ни абстрактная корпорация с вещами не имеют никакого отношения: это художественный вымысел, призванный продемонстрировать ситуации, в которых аналитик полезен.
А если говорить о ChatGPT, для эффективной работы с ИИ нужны грамотные вопросы и базовая оценка адекватности полученных ответов. Именно на этом опытные аналитики собаку съели. ИИ предлагает некую абстракцию, собранную из исходных данных. Приземление абстракции на конкретную инфраструктуру должно сопровождаться потоком уточняющих вопросов. Именно поэтому делаем вывод —
Аналитики нужны!
