Системный сдвиг

Сформулировал в одной дискуссии положения про метрики 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, там метрики универсальные).

В пятницу побыл в непривычной для себя роли — ведущего круглого стола. В гостях у Самоката обсуждали требования к роли системного аналитика, грейды, матрицы компетенций и возможный рост. Получилось интересно и содержательно! И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика). А потом, с 2:18:50 — наш круглый стол.

🔥 Подборка материалов от телеграм-канала Системный Аналитик 📚20 лучших книг для развития аналитика — можно скачать бесплатно 📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit 🏭PlantUML с нуля 📌Подброка бесплатных материалов базам данных и SQL ▶️ Подборка бесплатных вебинаров по основам интеграции систем 📎 Подборка материалов по изучению REST 🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений 🌐 HTTP. Что нужно знать аналитику ⚙️ Интеграция через API. Кратко 🤓 Задачник для системных аналитиков от Тинькофф 🧿 Виртуализация, контейнеризация и оркестрация 💪 Карта навыков системного аналитика 🧮 Про нефункциональные требования 🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST

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

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

Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно бывает найти нормативный документ, и увидеть, что практика с ним серьёзно расходится. И у меня этот рефлекс часто срабатывает в обычной жизни. Иногда находится прекрасное. Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно: "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать. Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг. То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

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

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

На прошлой неделе был на конференции 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 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).

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

В нескольких обсуждениях ценности системного аналитика проскользнул аргумент "один системный аналитик обеспечивает работой 5-6 разработчиков, а то и 8", — поэтому, получается, такое разделение труда выгодно. Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️ Наоборот, людей удивляет, что число разработчиков может быть больше. Кажется, что если в процесс уж встроены аналитики, то их нужно прямо много. Что опровергает гипотезу об экономической выгоде чисто по соотношению ролей. Видимо, дело в чем-то другом. А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?