BRS, BRD, SRS, FRS, PRD, ФТ, ФЗ, ТЗ — у нас так много названий документов! Каждый раз, когда я прихожу на тренинг в новую компанию, сталкиваюсь с какими-то своими названиями.

А как у вас называются основные документы, которые вы разрабатываете?

Сталкивались ли с тем, что при переходе из одной компании в другую названия документов меняется? Остается ли при этом суть, или тоже меняется? И как во всём этом не запутаться?

Какая у меня складывается картина по результатам обсуждения документов, тезисно:

1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.

2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)

3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.

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

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


В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.

В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.

На канале Systems.Education опубликован мой доклад на Flow'23: https://youtu.be/HzynqWGKehQ Enjoy!

А вот к нему слайды

Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?

В общем, ловите презентацию, там есть немного ссылок по темам.

Нашел отличную формулировку для записи архитектурного решения, ADR (для бизнес-решения тоже подходит).

+ варианты и аргументы (и движущие силы решения), +ограничения, + последствия и влияния, + дата и участники.

В нескольких обсуждениях ценности системного аналитика проскользнул аргумент "один системный аналитик обеспечивает работой 5-6 разработчиков, а то и 8", — поэтому, получается, такое разделение труда выгодно.

Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️

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

А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?

Пост про виды документов оказался самым комментируемым за всё время ведения канала!

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

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

Между тем почти все книги и стандарты у нас родом из 90-х, когда такой проблемы в принципе не было — системы в основном создавались с нуля, ну или переписывались целиком (тот же "Мифический человеко-месяц" — про переписывание системы).

А у нас сейчас в основном либо интеграция существующих систем, либо развитие существующих систем, либо надстраивание и конфигурирование коробочных решений и фреймворков (говоря языком ГОСТов — сборка и адаптация).
А эта тема так хорошо не отрефлексирована и не проработана. Не будешь же на каждую доработку расписывать полный пакет документов бизнес-уровня, да с анализом всех влияний и альтернатив! Быстрее просто сделать.

Интересная мысль, надо поискать целенаправленно именно такие книги/статьи/исследования.

На прошлой неделе был на конференции Infostart Tech Event. Это одна из крупнейших конференции по 1С. Сообщество 1С сейчас развивается с потрясающей скоростью, там много интересного. Но меня в основном интересовали доклады, не относящиеся напрямую к технологии, а рассказывающие про процессы и организацию работы. Посмотреть удалось не очень много, но вот что я для себя отметил:

1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.

Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.

Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).

Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)

Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).

В обсуждении не мог удержаться, чтобы не спросить -- раз всё в итоге к agile сводится, почему бы сразу с него не начать?

Тут мнение докладчика таково, что не всегда можно сразу "продать" agile (ну да, заказчик сначала настроен оптимистично и не хочет сильно вкладываться), и что не всем проектам agile подходит, а вот есть радар выбора подходов к управлению проектами от PMI. Ну, я заодно нашел отличный сайт с картинками: https://www.pmillustrated.com/2-13-determine-project-approach/ , там есть картинка про выбор подхода, на основе трех областей и 9 показателей:

✅ команда (компактность, опыт, доступность клиентов/пользователей),
✅ проект (вероятность изменений первоначальных требований, безопасность проекта, возможность частичной поставки),
✅ культура (готовность заказчика к agile, доверие между стейкхолдерами и командой, готовность заказчика передать часть решений команде).

В зависимости ответов на эти вопросы строится "паутинка" - и по её виду можно понять, какой подход вам более подойдёт -- agile, плановый, или гибридный. Сам автор как раз предлагает на впадать в крайности и ориентироваться на гибридные подходы, но это уже за рамками доклада.

2. Доклад Евгения Мазуренко из Ozon Tech "Как управлять проектами и не терять связь с заказчиком". Рассказ про устройство процесса, люблю такое.

У них это сделано так: на каждый домен (почти продукт, но это внутренняя разработка; в общем — то, что решает определенный набор задач бизнеса) имеется технический комитет, собранный из представителей бизнес-заказчиков. ИТ-шники тоже в нём участвуют, но в роли наблюдателей и консультантов. А вот представители заказчиков между собой определяют приоритеты задач, предварительно оцененных разработкой. То есть, задачи могут прилетать от разных заказчиков, но всё равно все рассматриваются через техком, и никак иначе в работу не попадают. Для рассмотрения на техкоме задачи оцениваются по значимости — по системе влияния на метрики с весами метрик. Каждый техком формирует набор таких метрик самостоятельно, силами представителей заказчиков. Метрики стараются приводить к деньгам. Чтобы уровнять фичи с коротким сроком окупаемости и с длинным, берут оценку денег в расчете на 3 года.

Сложность задач команда оценивает в "майках" — от XS до XXXL, которым соответствуют человеко-дни. Задачи размера XS на техкоме не приоритизируются, просто берутся в работу, когда есть окно. Кроме того, у команды есть зарезервированное время на погашение техдолга и на поддержку. Фичи, рассмотренные на техкоме, то есть проекты, связываются с задачами в Jira. Сами заказчики в Jira не ходят, отслеживают записи техкомов, для этого есть специальный софт. В этом софте видны статусы всех проектов. Разработчики должны обновлять статус проекта каждые две недели. Если ничего не изменилось -- пишут, почему ничего не изменилось (например, более срочные задачи или ждут другой домен). Так бизнес всегда в курсе, что происходит.

Теперь самое интересное: где тут аналитики (это я потом в кулуарах спрашивал, в докладе этого нет). А аналитики тут в самом начале! То есть, приходит заказчик с запросом, и аналитик прорабатывает этот запрос до такого состояния, чтобы команда могла его оценить. Если техком собирается раз в две недели, у аналитиков есть две недели на то, чтобы разобраться с новыми запросами. Число аналитиков разное в зависимости от домена, но их много, 1/2-1/3.

В общем, процесс выглядит очень разумно. Записей докладов с Infostart Tech Event пока нет, но я нашел запись того же доклада с недавнего митапа: https://www.youtube.com/watch?v=E7mOy2vr2hc&t=1080s

Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно бывает найти нормативный документ, и увидеть, что практика с ним серьёзно расходится.

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

Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."

Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.

Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.

То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

Немного об интеграциях:

— У нас на проекте Кафка.
— Для маршрутизации сообщений?
— ...
— Для маршрутизации сообщений, верно ведь?..

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

🔥 Подборка материалов от телеграм-канала Системный Аналитик

📚 20 лучших книг для развития аналитика — можно скачать бесплатно

📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit

🏭 PlantUML с нуля

📌 Подброка бесплатных материалов базам данных и SQL

▶️ Подборка бесплатных вебинаров по основам интеграции систем

📎 Подборка материалов по изучению REST

🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений

🌐 HTTP. Что нужно знать аналитику

⚙️ Интеграция через API. Кратко

🤓 Задачник для системных аналитиков от Тинькофф

🧿 Виртуализация, контейнеризация и оркестрация

💪 Карта навыков системного аналитика

🧮 Про нефункциональные требования

🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST

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

И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx

Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика).

А потом, с 2:18:50 — наш круглый стол.

Сформулировал в одной дискуссии положения про метрики API:

1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).

2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).

Если есть кеш — число попаданий/промахов.
Если есть требования к безопасности — число [неудачных] попыток авторизации, ошибки шифрования, ошибки сертификата, число выданных токенов;
Если есть есть требования по гарантированной доставке — число перепосылок, счетчики успешных/неуспешных перепосылок.

Соответственно, настраиваем мониторинг и алерты этих показателей на выход за установленные пределы или на приближение к пределам (например, при определенном числе фейлов перепосылок за какое-то время).

Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/

А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).

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

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

1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.

Вот, кстати, отличная статья Анны Овзяк про проектирование интеграций: https://habr.com/ru/companies/alfa/articles/770184/

Там подробно, с чек-листом, расписано, как при проектировании интеграции идти от юскейсов пользователей, и как прорабатывать архитектуру интеграций при помощи модели C4.