разработка или анализ

Вспомним, в чем ценность системного аналитика

Аналитик уменьшает неопределенность в задаче достижения результата путем создания оптимальных моделей будущего решения и способа его достижения. Когда работа аналитика заканчивается ? Когда риск “не попасть” в ожидания приемлем, когда разработчик получает полную информацию о том, как это должно работать и понимает как ему это сделать.

Когда аналитик создает модель решения, он действует по определенной методике.

Если аналитик не создает модели, то он не уменьшает вариативность. Когда разработчик начинает писать код, то

И что делать?

Нет на свете хуже статей, чем те, в которых поднимается проблема, а в качестве решения говорится, что все случаи разные и надо смотреть по ситуации. Я хочу привести несколько приемов и рекомендаций из своей собственной практики, которые оказались полезны и действенны.

Рекомендация первая. Она звучит настолько банально и скучно, что кажется, что в ней нет никакой магии (а она есть): спросите у своих разработчиков, что они хотят или не хотят видеть в документации. Тут штука в том, что если спросить в лоб, то в 99% случаев будет ответ «Ну, чтоб было понятно, что делать». Более эффективно будет встретиться с лидом команды (или с основными ее участниками) и проговорить несколько ключевых моментов, которые встречаются почти в каждом проекте, особенно, в корпоративной разработке.

Приведу некоторые из тех вопросов, которые я стараюсь проговорить при взаимодействии с новой командой.

Одна такая сессия с конкретными разработчиками вашей команды даст ответов больше, чем стопка книг по системному анализу, потому что это будут максимально релевантные ответы под конкретный проект с конкретными людьми. Опытный системный аналитик может очень хорошо и правильно сформулировать набор требований к системе – непротиворечивых, атомарных, исполнимых и так далее, но для того, чтобы они были реализованы, их нужно донести до разработчиков. И вот такой экспресс-опрос повысит эффективность коммуникации между аналитиком и разработчиком как мало что другое.

Про урокцифры:  МУЗЫКА ВОКРУГ НАС ОТКРЫТЫЙ УРОК ЧТО РАССКАЗЫВАЕТ МУЗЫКА 1 КЛАСС

На мой взгляд, следующие факторы говорят в пользу подхода «Умный аналитик – глупый разработчик»:

Подход «глупый аналитик – умный разработчик» оптимален, как можно догадаться, в противоположных случаях:


РАЗРАБОТКА ИЛИ АНАЛИЗ

То же самое, но наглядно

Рекомендация третья. Спросите у разработчиков по итогам некоторого периода совместной работы, все ли им понравилось и нести ли десерт. Как правило, если разработчик получает необходимую ему информацию из спеки или ТЗ, он этим остается доволен, а лишнее просто игнорирует или приспосабливается к трансформации написанного в нужное. Выяснив по итогам релиза или какой-то крупной итерации, что было удобно и полезно, что было лишним, а что лучше излагать по-другому, можно сделать взаимодействие в последующих итерациях сильно более эффективным; там, как правило, выясняется, что часть вещей, которые вы описывали каждый раз, они давно не читают, на степень детализации это не влияет и можно в будущем просто сэкономить время.

Причем, если договариваться о правилах игры надо с лидом, то получать обратную связь лучше от рядовых разработчиков, так как лид сам может всего этого не прочувствовать. Кроме того, если лиду что-то не понравится, он, скорее всего, скажет сам, а рядовой исполнитель – нет.  Мне вот, после пары таких сеансов обратной связи, хотелось сказать: «что ж ты молчал все это время?»

Если история про «захватить проект и спекулировать на этом» – ваш случай, то положительная обратная связь только усилит ваши позиции: все всегда сможете сослаться на мнение команды разработки, заявив, что ваши решения проверены временем и их эффективность подтверждена командой.

На этом, пожалуй, все. Хочу еще раз обратить внимание, что как бы это ни звучало, но при разработке ПО в качестве роли системного аналитика быть полезным  лучше, чем быть «умным» – как по мне, так это самый главный признак профессионализма.

Отличия системного аналитика от других профессий

Похожий список обязанностей есть у менеджера проектов, менеджера по продукту, системного архитектора, бизнес-аналитика и технического писателя. В реальной жизни этой сферы часто не разделяются и получаются «люди-оркестры», но различия в профессиях есть.

Как прокачать навыки аналитики

На мой взгляд, академический подход к тестированию гипотез может быть очень полезен для выработки правильной методологии. Моей специальностью в универе были статистические маркетинговые исследования, что мне помогло более структурировано подходить к аналитике. Несмотря на то, что в университете мы изучали SPSS и Microsoft Access, на практике эти инструменты мне не пригодились в карьере.

Однако основы работы с базами данных довольно универсальны. Сначала я ограничивался Google таблицами и продвинутыми функциями вроде Importrange и визуализации в Google Datastudio. Потом мне приходилось на практике изучать Google SQL для решения практических задач, например, сведений баз данных контрактов с платежной системой. Также я запустил свой сайт (подробнее тут), и знания SQL мне пригодились для сведения баз данных пользователей сайта с дополнительными плагинами, обеспечивающих функционал. Что мне помогало в изучении – это наличие практической задачи. Поиск средств для ее решения я находил как на stackoverflow, так и советуясь с коллегами.

Таким образом, знание аналитики крайне полезно для продакт-менеджеров. Далеко не обязательно знать все технические инструменты и языки программирования, чтобы качественно выполнять работу. Однако основы работы с базами данных, знания о тестировании гипотез и желание разобраться в цифрах дают больше возможностей для творчества.

Аналитические способности можно прокачивать как самостоятельно, так и с помощью онлайн-обучения, которое сейчас очень актуально. Если вы чувствуете необходимость в прокачке ваших скиллов, в онлайн университете ProductStar есть разнообразие курсов по изучению аналитики и SQL: “Старт в SQL для анализа данных” или “Аналитика с нуля”. За 2 месяца вы научитесь получать и обрабатывать данные, визуализировать их, работать с SQL. Самое главное – обучение проходит сразу на практике, изучая реальные кейсы!

Если вас заинтересовала сфера продакт-менеджмента и вы хотели бы освоить для себя новую профессию, советуем обратить внимание на курс “Профессия: продакт-менеджер” от ProductStar. С нуля вы не просто научитесь навыкам продакт-менеджмента, а сможете трудоустроиться на позицию продакта по окончании обучения. С чем вам помогут наши эксперты из Центра Карьеры.

Умение для ИТ аналитика

Когда мы говорим про ИТ аналитика, то он создает, в том числе, модели создаваемой/изменяемой ИТ-системы и модели ее использования.

При проектировании в общем случае проектируются:

Для создания этих моделей требуется алгоритмическое и структурное мышление.


РАЗРАБОТКА ИЛИ АНАЛИЗ

Должен ли ИТ-аналитик создавать все эти модели IT системы ? Да, если эти модели уменьшают неопределенность. То есть не всегда.

Как развивать умение проектировать алгоритмы и структуры данных (развивать алгоритмическое и структурное мышление)?

Автор сталкивался с двумя вариантами.

Во втором случае аналитик сразу видит некоторые ошибки компиляции/интерпретации, а применяя практики тестирования, он сам проводит валидацию и верификацию решения и понимает как лучше проектировать алгоритм.

Второй случай позволяет получать более быструю обратную связь, (компьютер быстрее преподавателя) что сокращает цикл обучения и дает возможность решить больше учебных задач и отработать умение и навык.

Однако второго способа недостаточно в случае проектирования алгоритмов действий, когда один или несколько исполнителей – это люди, которые могут забыть, передумать, ошибиться и т.п. Такие алгоритмы встречаются при проектировании пользовательских usecase или бизнес-процессов. Поэтому важны оба варианта обучения.

Какие конкретно умения проектировать структуры данных и алгоритмов нужны? На самом деле, зависит от предметной области (в общем-то универсальных ИТ аналитиков не существует, чтобы это понять, достаточно посмотреть на карту всех компетенций ИТ-аналитика).

Например, учетные программы

Обязанности системного аналитика

Обычно процесс работы системного аналитика выглядит так:

Задачи системного аналитика разноплановые: общение с заказчиком, разбор пользовательских сценариев, анализ и описание требований, сопровождение процесса разработки.

Так выглядит часть работы системного аналитика

А теперь к заповедям

В начале карьеры я приставала ко всем коллегам, чтобы быстрее вникнуть в технические аспекты разработки. Подписалась, наверное, на миллион каналов. Сначала была каша, а потом все уложилось. Любопытство очень помогает в работе.

Чтобы задавать на встрече правильные вопросы и сделать переговоры продуктивнее, недостаточно мастерства интервьюирования. Изучение даже основных публичных материалов о компании и сфере заказчика даст информацию, которая погрузит в специфику. К тому же подготовка вопросов и предварительных схем ярко демонстрирует ответственный подход компании к каждому этапу работ.

Чем больше вопросов подготовлено к переговорам, тем лучше. С ними интервью пройдет продуктивнее, а оставшиеся вопросы можно направить заказчику для самостоятельного ответа. Даже если на вопросы ответят частично, это более полезно, чем ничего.

Владельцы любят говорить о своем бизнесе, и даже в удаленном формате получается собрать достаточно информации. Но к примеру, госсектор тяжело отвечает в переписке. Гораздо активнее работают на встречах-созвонах.

Считывать эмоции, подстраиваться под настроение и чувствовать контекст — важнейшие soft skills системного аналитика. Формальная отработка — не лучший подход. Боль и потребность заказчика необходимо прочувствовать. Нужно поставить себя на место конечного пользователя, увидеть продукт его глазами. Если подходить к заказчику с заботой, шанс создать классное решение намного выше!

В системной аналитике применяют огромное количество методов анализа. Это не значит, что надо использовать их все одновременно, но точно необходимо адаптировать прием под конкретный проект и заказчика. Кто-то хорошо пишет, кто-то говорит, кто-то думает и работает схемами. Если прием не работает, меняйте его.

Однажды я была на заводе на учебной практике. К нам прикрепили сотрудника, который понятия не имел, что с нами делать и что показывать. И завел он восемь молоденьких девчонок в какое-то техническое помещение, где один из работников ел борщ из контейнера. « Зачем ты их сюда притащил?» — и много слов со звездочкой, вот что мы услышали. С того момента я точно знаю — метод наблюдения подойдет далеко не везде и не всегда. Рядовые сотрудники часто не готовы к сотрудничеству и инновациям.

Спецификация от аналитика не должна дублировать макет, она должна его дополнять. Например, макет не расскажет вам, что при наведении курсора на элемент должна появиться подсказка (если это не прототип), поэтому такое стоит прописать в спецификации. А вот цвет кнопки на макете можно точно не описывать. Не стоит быть предельно дотошными или искусственно «раздувать» документ. Каждый пункт должен быть оправдан, краток и понятен.

Каждый проект обладает огромным количеством материалов: переписки, договоры, требования, макеты, записи встреч, заметки и пр. Лучше хранить материалы в одном месте с настроенным доступом для членов команды проекта. Так ничего не потеряется, будет возможность обратиться к любому этапу проекта, а новому сотруднику будет проще влиться. Если такой площадки в компании нет, создайте ее для себя.

Функция аналитика — перевод с человеческого на технический и обратно. Не надо делать из сложного еще более сложное. Необходимо, чтобы всем все было понятно. Даже тем, кто не обладает техническими компетенциями или не имеет понятия о языках программирования.

Все мы люди, а не СhatGPT. Можно ошибиться, неправильно расшифровать конспект или домыслить от себя. Системный аналитик — мост между заказчиком и командой разработки. Если ошибется он, есть риск неверного развития проекта. Перепроверяйте свои записи, советуйтесь с коллегами, слушайте записи разговоров и всегда добавляйте источники информации в документы.

Чтобы ускорить запуск процесса разработки, команда аналитики должна отработать быстро. А скорость лежит в дисциплине и декомпозиционном подходе. Всегда стоит быть реалистом и честно оценивать свои возможности — не стоит планировать на день 15 спецификаций, если в силах сделать только 5.

Если вы посмотрите скиллсет системного аналитика, там обязательно будет стрессоустойчивость и нейтральное отношение к критике. Системный аналитик взаимодействует с большим количеством людей. У каждого свое мнение, и не все умеют выражать его в деликатной форме. Надо быть к этому готовым и надо воспринимать любые переговоры как часть рабочего процесса. Не бойтесь показывать свою работу коллегам внутри проекта или более опытным аналитикам, чтобы они дополнили или покритиковали. Проекту будет только лучше.

Как оформить свои пожелания, чтобы получить максимально точную стоимость проекта?

Проект оценивается исходя из фичей и их описания, которые хочет заказчик.

Фича — совокупность функций, например, регистрация.

Либо с помощью требований. Они делятся на типы и виды по-разному, опять же в зависимости от школы, которой придерживается аналитик. Самое распространенное деление — на функциональные и нефункциональные требования.

Чтобы смысл проекта быстрее поняли, пишите сначала функции, которые будут выполняться людьми в системе или как система интегрируется с другими системами, как работает с пользователем.

Например, в первую часть документа поместить функциональные требования:

Во вторую часть документа поместить нефункциональные требования:

Коллеги аналитики сейчас ужаснулись от построения требований выше, но эта статья и не для них. При написании требований заказчику не стоит переживать о том, что он напишет требование в неправильном виде или что разделение требований — основное, что требуется для оценки проекта. Заказчику не нужно знать все тонкости разделения требований и как их записывать, хоть в чатике телеграмма, с помощью стикеров — оставьте это на совесть аналитика.

Не бойтесь отправлять всё, что хотите видеть в системе. Аналитик поможет вычленить необходимое и убрать лишнее. Однако заказчику важно понимать: чем лучше вы опишете свои пожелания, тем меньше аналитик потратит времени на анализ того, какая система нужна. Значит, сэкономит время, которое оплачивает заказчик.

Пример из практики

Иногда аналитик участвует в проекте, когда его еще не существует. Как-то раз к нам пришел старый клиент с запросом «хочу корпоративный чат». Звучит легко, на деле возникает масса вопросов. В этом чате:

И еще миллион вопросов.

У нас подкованные менеджеры, поэтому при первом намеке на корпоративный чат менеджер проекта выявил целевую аудиторию продукта, необходимые функции, причину запроса и узнал, что из-за санкций прошлый мессенджер клиента ушел из России. Затем полез в реестр российских ПО, все выходные искал российские аналоги и отдал пару хороших вариантов на аналитику.

Я составила таблицу преимуществ, недостатков и стоимости на человека для выбранных мессенджеров. Менеджер презентовал труды совместной работы, и заказчик решил сначала протестировать одну из представленных нами систем. На ней он и остался (на самом деле нет, ушел на свою, но в серую)

Что происходит на проектах без системного аналитика?

1. Работу аналитика берет на себя менеджер проекта. Для него это дополнительная нагрузка, поэтому страдает качество проекта: многое не протоколируется, техническая документация ведется несвоевременно, актуализацией существующей документации заниматься некогда.

Как результат: перегруженный менеджер, плавающие сроки у проекта.

2. Нет четкого понимания архитектуры сервиса и согласованной документации. Клиент не видит общую картину проекта, какая функция будет разрабатываться на каком этапе. Баз фиксированных требований любое изменение вносит хаос в проект, так как изменением нельзя управлять.

Как результат: недовольный заказчик, непопадание в изначальную оценку по срокам и стоимости, демотивированная команда — никому не хочется несколько раз переписывать код или перерисовывать макеты. Плюсом, никто не знает, что реализовано в системе, только разработчик, который непосредственно это делал.

3. Нет понятно описанных сценариев, которые учитываются при дизайне и разработке и описания проекта в целом. Поэтому возникают дополнительные вопросы и баги.

Как результат: увеличивается время на коммуникацию заказчика с исполнителем, повышается стоимость проекта при T&M.

Умный аналитик, глупый разработчик

Другая крайность при распределении функций – это слишком большая степень свободы для аналитика в части проектирования решения. Аналитик описывает алгоритмы на псевдокоде, пытается оперировать такими абстракциями, как слои приложения, описывает какие-то сервисные механизмы, определяет типы данных и формат обмена данными внутри приложения, суть требований скрывается за предложенными решениями. У этого подхода тоже есть серьезные минусы:

Нет возможности проверить корректность. Разработчик не видит картины в целом, не понимает, зачем он делает ту или иную задачу: ему приходит спецификация, содержащая алгоритм на псевдокоде, правильность/адекватность которого он не может проверить. Это повышает риск ошибки со стороны разработчика и не позволяет провести ревью (аналитики ошибаются и осознанное прочтение разработчиком документации позволяет это выявить);

Избыточная проработка. Системная спецификация может содержать детальное низкоуровневое описание алгоритмов работы с данными, которые разработчик не будет реализовывать. Например, не нужно описывать алгоритм вычисления количества дней между двумя датами или дня недели по дате (привет школьные олимпиады) – для большинства таких задач есть готовые решения;

Лишняя работа ради стройности описания. Хорошо и правильно, когда ТЗ или спецификация имеют примерно одинаковую глубину для всех функциональных блоков; в этом случае читающему проще понять, на какие вопросы документ может ответить, а на какие – нет. Этот подход очень быстро может затянуть аналитика в бессмысленный и беспощадный процесс описывания вообще всего на свете: как читать данные из файлов, как называть внутренние классы и т.п. Есть ряд задач, которые аналитик в большинстве случаев просто не должен описывать и сервисные/инфраструктурные функции – одна из них;

Риск потери актуальности документации. В случае если разработка решит провести рефакторинг, заменить фреймворк или какой-то модуль в приложении, слишком «близкая к коду» спецификация может стать неактуальной и неверной, причем в большом объеме. В каком-то объеме спецификации будут устаревать в любом случае, это процесс – как инфляция, но если можно не усугублять, то нужно не отказываться от такой возможности;

“Режим бога” и неадекватное восприятие границы компетенций. В ряде случаев аналитику может просто не хватить технических знаний или опыта, но так как он привык, что в его команде он «умный» и никто кроме него, он может поддаться соблазну изобрести свой собственный велосипед из костылей.  Этот аспект не совсем технический, но потому он особенно важен и коварен. Проблема оценки собственной компетентности вообще довольно остро стоит перед человечеством и системный анализ – не исключение.

«Аналитики не нужны» — действительно ли это так?

Время на прочтение


РАЗРАБОТКА ИЛИ АНАЛИЗ

Рассмотрим на примере вымышленной ситуации

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, порассуждал о роли аналитика в команде и для этого смоделировал ряд ситуаций, когда к работе над проектом стоит привлекать таких специалистов. О том, что из этого получилось — читайте в статье.

— Аналитики не нужны! — лицо Лаврентия, нового менеджера проекта по внедрению информационной системы по управлению всем (ИС СУВ) не выражало никаких эмоций, а степень решимости была сродни количеству лошадиных сил у грузового локомотива. За плечами Лаврентия — опыт разработки в IT‑гиганте из Fortune 500, с коллегами он изобретал свой особенный форк gRPC и участвовал в эксперименте по переходу на трехчасовые спринты.

— Это же пустая трата времени. Лиды встретились, договорились по параметрам API, реализовали и в прод, — продолжил он и сдвинул брови.

— Скормим ChatGPT, потом студенты на аутсорсе поправят, — парировал Лаврентий.

Над Савелием будто сгустились тучи.

— Останемся на прежнем, а если что, — кнопки покрасить не проблема, — отрезал менеджер проекта и кивнул на fullstack Прасковью.

— Да, — отозвалась Прасковья, его вторая жена.

— Все, за работу! — отчеканил Лаврентий в ответ на пробившиеся было сквозь поток негодования Савелия аргументы и вышел.

В переговорке воцарилось тяжкое молчание. Казалось, тишину нарушает лишь шум разогнавшихся синапсов в головах членов команды.

Савелий украдкой гуглил книгу «Освоить python за 24 часа», а лид разработки Иннокентий задумчиво поглаживал на экране смартфона таблицу с бэклогом в Jira, прикидывая, в какую из ближайших ночей он приступит к приоритетным таскам, и втайне мечтал о времени на рефакторинг.

Ситуация в этом проекте получилась не из приятных.

Аналитики как часть команды разработки прочно закрепились на заре развития IT и отвечали за построение бизнес‑процессов, общение с заказчиком, изложение их желаний в понятной программистам форме. Сейчас, когда порог входа в языки программирования снизился, а REST‑интерфейс для простейших CRUD‑операций делается в контекстном меню СУБД, желание срезать косты проектов за счет некодеров все чаще посещает руководство компаний.

В идеальном мире атомарность и спектр задач разработчиков не превышает по сложности конструкторы Lego. Остается только распределить приоритеты в зависимости от уровня должности стейкхолдера в иерархии организации и менять выгоревших разработчиков, словно лампочки. Но всегда есть несколько «но», о которых мы бы хотели поговорить.

Допустим, наш воображаемый ИС СУВ — типичная корпоративная информационная система на базе микросервисов, часть логики которых может через внешние шлюзы использоваться смежными корпоративными ИС. Главная задача ИС СУВ — извлечение прибыли. Делается это ровно до того момента, когда операционные расходы на поддержку и развитие системы ее не превысят.

Микросервисы реализованы на Python, Ruby, Go. ( Была замешана даже Java, но только об этом никому не говорите.) Общение между микросервисами происходит по REST, но есть потаенные желания перевести все на gRPC.

Бардак, скажете вы. Нет, это Agile, — скажу я. Когда в ходе разработки испытывались различные гипотезы, наиболее удачные получили свое место в SOA. Конечно, должен быть и архитектор, который бы увековечил стек в граните и отстаивал бы его. Однако в случае с ИС СУВ таковым стал первый разработчик системы, который сделал ее пре‑пре‑бету для автоматизации собственных рутинных задач, будучи еще молодым «зеленым» сотрудником набиравшей обороты корпорации.

Хоровод микросервисов ИС СУВ должен органично встраиваться в технологический ландшафт корпорации и удовлетворять тысячам страниц нормативной документации, которая постоянно дополняется. А еще быть доступным в филиалах корпорации, в том числе и за рубежом с учетом особенностей на местности.

За каждый микросервис отвечает группа разработки, участники которой могут быть в любой момент перетасованы между задачами разных компонентов. Упомянутый выше Иннокентий распределяет задачи исходя из удаленности сотрудников, загрузки, опыта, отпуска, при этом сам не выпускает из рук IDE.

Казалось бы, что может пойти не так?

Именование

Базовую сущность ИС СУВ назовем просто «вещь». Как вы думаете, сколько идентификаторов «вещи» будет в нашем зверинце спустя несколько лет гибкой разработки? Они ведутся и в IT Service Management‑системе, дополняя перечень идентификаторов своими внутренними конфигурационными единицами.

В БД компонентов «вещь» зовут vestch_id, thingUUID иногда ID. Просто и понятно.

По соглашению сторон в каждый метод API добавлены поля со временем создания и изменения объекта «вещь». Здесь к списку имен полей его сущности добавляется набор поддерживаемых форматов отображения времени. Изначально использовались вариации ISO 8601, но с выходом ИС СУВ на международную арену стали появляться поля с unixtime.

Какова роль аналитика?

При должном подходе он чаще остальной команды сталкивается с несовершенством компьютерного диалога и может поднять насущные вопросы типа «а этот ваш vestch_id соответствует thingUUID?». А самое главное, в его власти прописать в постановке тот вариант, который наиболее приемлем и привычен.

Разработчики будут получать линейкой по рукам от тестировщиков за отход от написанного в постановках. Новые аналитики могут опираться на постановки предшественников и перенять ту самую верную формализацию, немного снизив энтропию.

Одни плюсы, никаких минусов и немаловажное следствие: именно аналитик несет ответственность за принятые решения, что позволяет избежать прямых конфликтов конечных пользователей с разработчиками.

Обработка ошибок

Формально любое обращение к ИС СУВ, за исключением вопросов прав доступа и аутентификации, может возвращать всего два кода ответа: 200, если все хорошо, и 500, когда нет. Для пользователя вне системы ошибки при взаимодействии между компонентами внутри ИС СУВ вполне удовлетворяют определению HTTP‑ответа с кодом 500.

Истинная причина кроется в логах компонентов, хотя последние тоже могут придерживаться принципов дуализма сообщений в зависимости от дисциплины разработчиков.

Долгое время при минимуме задействованных кодов удавалось играть значениями error message, в котором выводилось кратко, что произошло. Причина на 100% была понятна самому разработчику компонента, на 20% тестировщикам и на сдачу — всем остальным.

Беда пришла откуда не ждали. Новый отдел качества продавил собственную систему оценки KPI сервисов корпорации, который бы позволял оценивать, насколько хорошо ведется разработка систем. В базовом наборе KPI присутствовала метрика в виде числа ошибок 500 сервисов на единицу времени.

В обязанности аналитиков входит проработка всех возможных ситуаций и описание соответствующего поведения, а также корректного трейсинга внутренних ошибок компонентов на UI/API. Обжегшийся прежде аналитик будет обязательно учитывать, что если что‑то явно не описано в постановке, то оно не будет реализовано, даже если напрашивается.

Разработчики тоже вносят свою лепту, когда им непонятно, как себя вести при специфичном наборе параметров, но есть и те, кто стремится на скорость закрыть задачу. Поэтому комично‑трагичных ситуаций, как было описано выше, можно отчасти избежать. Или хотя бы не оказаться в топе антирейтинга информационных систем корпорации.

С пресловутым ростом масштабов системы беды не окончились. Когда было принято решение перейти на обмен данными через корпоративную шину данных, появилась задача категоризации и кодирования ошибок от всех потребителей из нее, а стандартный набор кодов HTTP уже не вмещал всей логики.

В этом случае пришлось придумывать свою номенклатуру ошибок и закреплять ее на уровне департамента по развитию IT. Было больно, однако разработка системы не затормозила, поскольку бремя согласования схемы взял на себя аналитик.

Бизнес-логика

Как и все вещи на земле, «вещь» может сломаться. Казалось бы, что тут сложного: завел заявку на ремонт, добавил в согласование текущего владельца, после жди выполнения.

Куцая статусная модель и отсутствие видимых поводов для беспокойства позволили создать первую реализацию подсистемы ремонта довольно быстро. Шестым чувством аналитик Савелий почувствовал подвох (из‑за которого был уволен с прошлого места работы) и настоял на добавлении составного поля с маршрутом согласования, а также функции прикрепления документа‑обоснования произвольного формата, на базе которого «честные» 500-ки могли существовать, однако не должны были сказываться на KPI. Ибо мы тут вещи ремонтируем, а не плохо кодим.

Пока ИС СУВ делал робкие шаги в статусе корпоративной системы, тратить значительные усилия на дополнительные задачи (помимо номинально функционирующей логики) казалось избыточным. Разработчики ругались на ненужные необязательные поля, которые усложняли им оперативное закрытие таски, а тестировщики постоянно обнаруживали новые баги в процедуре загрузки документов. Сам формат документов‑оснований не был до конца определен.

Какое‑то время все шло своим чередом, но в один день пришла новость о том, что необходимы ремонт и замена «вещей» в регионах. Позднее была добавлена транспортировка запчастей, в том числе и за границу, и маршрут согласования разросся. Статусная модель, пустив корни в почву, начала уверенно обрастать ветвями, торчащими во все стороны. Был обнаружен побочный эффект — внезапный аудит прошлых заявок, которые не согласовывались с финансистами по очередной форме, однако свой процент у бюджета отделов забирали.

Несомненный успех задумки был омрачен, но не так сильно, как мог бы, поэтому Савелия в этой корпорации увольнять не стали. Переработка имеющейся логики без заложенного базиса наводнила бы отчетность новой порцией 500-к, а премии отдела таяли, как пломбир в жару.

Впрочем, впоследствии логика продемонстрировала плохую гибкость, и было решено доработать ее, когда появился способ по обоснованию приостанавливать функционирование системы без риска получить просадку по KPI отдела сопровождения ИС СУВ.

Аналитик несет персональную ответственность за принятые решения, верные и ошибочные. Сложно ругать разработчиков за реализованный код, если он работает стабильно, но делает не то, что требовалось. В случае выше решение аналитика встретило сопротивление со стороны команды, но было продиктовано неудачным опытом на прошлом месте работы. Все подводные камни, «собранные» аналитиком в ходе работы над проектами, формируют уникальный подход к решению задач. А еще отчасти позволяют избежать ситуаций, когда заказчик или вышестоящие сотрудники будут противодействовать внедрению решений.

Взаимодействие со смежными командами

UI — отдельная веха развития. Веб‑интерфейс первых релизов ИС СУВ был по‑спартански лаконичен. Автор вдохновлялся новой на тот момент концепцией Material Design. При выходе системы на уровень корпорации ИС СУВ стала белой вороной в прямом смысле этого слова из‑за несоответствия фонового цвета большинства страниц корпоративному брендбуку.

Мало кто всерьез воспринял первую просьбу «поиграть с цветами» от отдела маркетинга, не говоря уже о контрастном тексте для слабовидящих, «ночных» темах и прочем. Отдел маркетинга упрямо доказывал, что просто перекрасить «шапку» страниц и добавить логотип в угол мало, а нужно полноценное оформление по гайдлайнам корпорации, иначе пользователи в незнакомой среде будут путаться и совершать ошибки, стоящие денег. Началась эскалация с последующей раздачей кар небесных.

Задаче повысили приоритет. Савелию совместно с frontend‑разработчиками Прасковьи удалось стрясти оформленный корпоративный UI Kit для стандартизации интерфейса и успокоения буйства отдела маркетинга. Благо Савелий, обивавший пороги отдела маркетинга, был в курсе прогресса в ходе разработки гайдлайнов и держал руку на пульсе сторонней для его отдела активности. Удалось выкроить какое‑то время на маневры с переработкой визуального интерфейса, когда на общей планерке отдел маркетинга сознался, что брендбук сейчас не утвержден.

Но не маркетингом единым жив человек. И С СУВ оперировала в числе прочего и финансовой информацией, а значит, требовалась специфичная отчетность. После получения первых требований в ближайший спринт была подготовлена выгрузка нужных полей, таск закрыт, все счастливы. До первого финансового мероприятия.

Всего полей в выгрузке было 37, и при печати на листе A4 текст в них напоминал татэгаки, а при ручной разлиновке листа в Excel для печати 4–5 колонок на страницу больше стал походить на пазл. В бухгалтерии твердили какие‑то странные буквосочетания, на поверку оказавшиеся нужной формой отчета, содержащей готовый шаблон компоновки данных.

Дергать разработчиков с просьбой собрать шаблон не было возможно, — когда еще пожар с KPI не потушен. Зато нашему геройскому аналитику Савелию пригодились знание SQL и опыт в%вставь_своего_вендора% Reports. Пускай отчеты строились не в ИС СУВ, но вопросы по оформлению удалось закрыть, а впоследствии и автоматизировать генерацию красивых таблиц на листах A4.

Аналитик должен общаться со смежными отделами, выявлять источники требований и согласовывать пути решения. Сложно представить себе выполнение подобной работы руками того же Иннокентия, тимлида разработки, в задачи которого входит сделать сразу и качественно, но не обязательно в срок.

Документирование

Корпоративные системы должны сопровождаться определенным пакетом документации, поэтому технический писатель просто взял и написал его. Но не сразу.

О документировании системы пришлось крепко задуматься при передаче ИС СУВ в виде нематериального актива на баланс корпорации. Тогда появились на первый взгляд невзрачные сотрудники из архивного отдела. Они требовали малого — соблюдения правил обслуживания информационных систем, включавших в себя согласование с нормоконтролерами пакета документации.

Каких‑то правил оформления документации, кроме одобрения НК, не прослеживалось, и пришлось погружаться чудесный в мир ГОСТ 19 с элементами ЕСКД, а то и в ISO/IEC FDIS 18 019:2004. Однако ни одно из предлагаемых решений не устроило нормоконтроль. После нескольких итераций было утверждено, что эта задача решается исключительно жестким корпоративным стандартом вплоть до особенных межстрочных интервалов и полей документа, о который все технические писатели смежных систем в свое время поломали зубы и знали как отче наш.

Формальная документация со ссылками на внутреннюю базу знаний отметалась, как что‑то неприятное, пакет из ГОСТ не подходил, потому что корпорация была мало того что коммерческая, так еще и международная.

Согласование затягивалось, писались письма. Но в конце было принято решение сесть и основательно собрать все имеющиеся знания в одном пакете документов по соответствующим разделам.

Савелий, варившийся в среде разработки, обладал компетенциями по сбору информации, а технические писатели занимались оформлением и вколачиванием полученных текстов в шаблоны, да и нормоконтроль уже подустал разворачивать новые версии пакета документов исполнителям. В итоге распечатанная, подписанная и сшитая документация нашла свое место в архиве.

Документацию писать не любят. Да и зачем, если у тебя в течение нескольких спринтов в системе постоянно что‑то изменяется, а над головой не висит дамоклов меч государственной приемки. Там, где можно обойтись только пользовательской документацией, привлекают технических писателей. ( И перед сном крестятся, чтобы не пришлось готовить пакет сопровождения системы.) Тем не менее незадокументированный проект рано или поздно все же начнет портить кровь руководителям.

С другой стороны, аналитику чаще всего необходимо отвечать на вопросы, откуда взялось то или иное требование, или объяснить соглашения, принятые внутри команды. После череды полученных вопросов Савелий решил размещать ответы на часто задаваемые вопросы в базе знаний и отправлять коллегам ссылки на нее. Был составлен глоссарий проекта, потому что новые сотрудники не сразу могли постигнуть суть «вещей». В отдельном подразделе размещались предложения по доработкам от смежных сотрудников отделов.

Позднее Савелий стал фиксировать схемы решений, которые рисовал не столько ради выполнения задач, сколько для собственного понимания устройства ИС СУВ. Впоследствии накопленной в базе знаний информации хватило, чтобы заполнить ожидаемый комплект документации на 80%. И был человек‑аналитик, ориентирующийся в ней как рыба в воде.

Вместо итога

Чем закончилась эта история? Пожалуй, вымышленный Лаврентий в итоге все же пришел к тому, что аналитики нужны. Пусть и не сразу. И, может, даже не на нынешнем месте работы.

Вотчина аналитика — понимание как регламентов организации, пользовательских процессов и решаемых задач, так и работы внутри своей команды.

Действия Лаврентия же не основаны на личных конфликтах или недальновидности. Главная задача вымышленной ИС СУВ — извлечение прибыли, и она может быть решена оптимизацией расходов на ее эксплуатацию.

На разных этапах жизненного цикла любой ИС аналитика может показаться излишней, ведь код не пишется, иных значимых артефактов не появляется, основные угрозы премиям отдела нейтрализованы. Но это не так.

Главная ценность аналитиков — их опыт, накопленные знания и компетенции. Они, конечно, не основа разработки, а скорее штурманы корабля, ориентирующиеся на местности.

Конечно, задачи аналитика могут быть дискретно распределены между другими участниками команды, однако брать на себя какие‑то сторонние задачи захочет не каждый, а тем более нести за них персональную ответственность. В то же время без анализа задач есть риск хождения по чужим граблям снова и снова.

Когда время и деньги позволяют, есть возможность передать задачи анализа, например, лиду разработки Иннокентию из вводного раздела, но последствия этого шага непредсказуемы.

Статья носит юмористический характер. Сама ИС СУВ — это собирательный образ из различных кейсов, с которыми сталкивались аналитики в нашей команде. К реальной жизни ни сама система, ни абстрактная корпорация с вещами не имеют никакого отношения: это художественный вымысел, призванный продемонстрировать ситуации, в которых аналитик полезен.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *