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

Чудная статья от Яндекс.Практикума про типы интеграций. Написана как будто специально, чтобы поиздеваться над аналитиками: у нас есть два способа классификации интеграций и по нескольку видов интеграций в каждой классификации. Объединим обе классификации в единый нумерованный список и расскажем вам про них по очереди! 🤯 Считаю, что зря они только две классификации взяли. Нужно было расстараться и штук пять взять! И по одному примеру из каждой классификации в список добавить! В общем, какое-то "системный аналитик изнасиловал журналиста" получилось. https://practicum.yandex.ru/blog/sistemnaya-integraciya

Практикум радует (правда, статья-то ещё прошлогодняя). А давайте поможем Даше накидаем разные способы классификации интеграций? Вот вы какие знаете?

В общем, как видите, тема неочевидная, и лучше в проекте договориться на старте (или в рамках всей организации), чтобы не получилось у одних так, а у других эдак. Одинаковые вещи должны выглядеть одинаково, это дает возможность предположить и угадать, а не бегать каждый раз в документацию. Документ, в котором описываются эти принципы, называется "Соглашение об именовании". Программистам с этим проще — у них есть линтеры, которые проверяют исходный код на соответствие установленному стилю. Для спецификаций я такого пока не видел. Но хотя бы договориться об этом стоит. Ссылки на стили наименования, сборники лучших практик и посты по этому поводу: https://github.com/RootSoft/Database-Naming-Convention https://dev.to/ovid/database-naming-standards-2061 https://www.belgif.be/specification/rest/api-guide/#resource-archetypes https://restfulapi.net/resource-naming/

Пост по заявкам читателей (да, так тоже можно!) про названия. Тема-то актуальная, регулярно в чатах кто-нибудь спрашивает. Итак, мы проектируем системы и даём названия разным элементам. В основном это: * таблицы в базах данных * поля в таблицах * индексы, ограничения и бизнес-правила * эндпоинты API * поля в JSON * названия файлов Есть ещё, конечно, названия модулей, функций и переменных, но это область программистов, туда не лезем. Что же у нас с рекомендациями? Удивительно, но они разные :) Вот какие вопросы обычно обсуждают. Во-первых, у нас есть разные способы записи названий, состоящих из нескольких слов. Пробелы мы почти никогда использовать не можем, остаются варианты: 👨‍🎓 PascalCase (без пробелов, с большими буквами в начале слов) 🐫 camelCase (без пробелов, с большими буквами в начале слов, начиная со второго, как горбы у верблюда) 🐍snake_case (вместо пробелов используется подчеркивание, всё маленькими буквами) 🍢kebab-case (вместо пробелов используется "минус", слова нанизаны на шампур) Во-вторых, какие части речи использовать — глаголы, существительные? Особенно актуально для эндпоинтов API В-третьих, для существительных — во множественном или в единственном числе их называть? В-четверых, словарь. Какими словами вы называете объекты, и как переводите на английский (надо ли говорить, что называть все объекты нужно на английском, если только у вас не 1С). Как вы назовете счет клиента? Account, Check или Schet? Любопытно, что рекомендации и лучшие практики для API и для БД иногда противоположны! Для БД советуют использовать snake_case (так проще различать слова). Для эндпоинтов API — kebab-case, т.к. в вебе ссылки принято подчеркивать, и значок "_" может потеряться. Почему не camelCase? Потому что труднее различать слова и нужно переключать регистр (URI регистрозависимые). В обоих случаях рекомендуется использовать в качестве названий существительные во множественном числе (для ресурсов REST API и для названий таблиц в БД). Один из аргументов для БД — меньше риск, что имя таблицы совпадет с зарезервированным словом. Хотя есть и контраргумент: давать таблицам и представлениям названия в единственном числе, чтобы не думать, как переводить во множественное (person — это persons или people?). Холиварная тема! Следующая тема — идентификаторы. Должны ли они называться просто id, или повторять название сущности (team_id?) Есть аргументы за и против. Внешние ключи, понятно, должны назваться по названию внешней таблицы+id. Названия таблиц и полей должны содержать полные слова, не сокращения. Нет ничего хуже таблицы pmnt23, состоящей из полей P1, NMT, ABBR14, FIELD28, ACC_NO и т.д. Названия типов также не должны становиться именами полей: DATE, TEXT или TIMESTAMP не дают никакого объяснения смысла. Также стоит подумать над более конкретными названиями — source_warehouse_id а не просто source_id. Для API, кроме того, нужно понимать — запрашиваем ли мы коллекцию или единичный элемент? Если это элемент из коллекции, то будет существительное во множественном числе / id (users/{id}), но это может быть и служебное слово, указывающее на особенный элемент коллекции (users/me). Про глаголы в REST писать не буду, пуристы скажут, что никаких глаголов в названиях эндпоинтов быть не может, но вот Google, например, считает иначе. Ну а если у вас не REST, а наоборот даже RPC, то названия методов рекомендуется писать в PascalCase по формату "ГлаголСуществительное" — что мы делаем и над чем мы это делаем, причем существительное должно указывать на тип передаваемого объекта (GetBook возвращает объект Book). Ну и пока нам не встречался camelCase, куда же без него. Он у нас живет внутри JSON — так записываются названия полей.

Если бы Ивар Якобсон создавал диаграмму устойчивости сейчас, он бы назвал её "диаграммой антихрупкости". Звучит модно, не то что какая-то там робастность! На самом деле нет. Термин "антихрупкость" (antifragile) ввел и раскрутил в одноименной книге Нассим Талеб, трейдер и риск-аналитик (до этого он так же раскрутил термин "черный лебедь"). И в книге он много пишет об отличиях антихрупкости от устойчивости: устойчивость — это способность выдерживать шоковые воздействия и восстанавливаться после них, а антихрупкость — не просто восстанавливаться в то же состояние, а становиться лучше. Как это обеспечить в реальности? Система должна иметь возможность изменять своё поведение без радикальной перестройки внутренней структуры. То есть, структура системы должна обеспечивать возможность таких изменений. Например, один из вариантов — избыточность. Мы почти всегда боремся за отсутствие избыточности и дублирования (принцип DRY), но в случае потенциальной высокой изменчивости среды это может выйти боком (например, см. заметку про это в блоге Гугла). Антихрупкая система допускает избыточность, и при изменении внешних условий какой-то вариант реализации может оказаться более подходящим. Сюда же можно отнести несколько альтернативных вариантов выполнения одного юскейса, что часто забывают. Юскейс — это набор сценариев, ведущих к достижению цели, а не один сценарий. У вас поломался пользовательский интерфейс, но остается чат, в котором ту же задачу можно решить через оператора. При этом часть функций системы может отмереть, перестать использоваться. А часть — соединиться в другой последовательности для выполнения задачи в изменившихся условиях. Это как раз позволяет проследить диаграмма устойчивости — можно ли соединить её элементы (сущности, контроллеры, интерфейсы) другим способом? На этот вызов отвечает (микро)сервисная архитектура. Для этого нужен HATEOAS с набором ссылок в REST. А жестко зафиксированный сценарий юскейса наоборот мешает. Сюда же относятся различные средства мониторинга, автоматические размыкатели и балансировщики. У аналитиков есть проблема: смотреть на сценарий юскейса, как будто это единственный экземпляр юскейса в системе. На самом деле почти все интересные системы сейчас многопользовательские, и каждый раз имеет смысл подумать, что будет, если много экземпляров юскейса выполняется параллельно в одно и то же время. Опять же, на диаграмме устойчивости это можно отметить: сколько экземпляров контроллера запущено (и какая очередь перед ним может возникнуть), есть ли конкурирующие обращения к одной и той же сущности. В антихрупкой системе всё это под мониторингом с цепями обратной связи, то есть регулируется само в положительную сторону, и останавливает каскад ошибок при развитии ситуации в отрицательную сторону. На какой диаграмме можно наметить точки мониторинга?.. Талеб также описывает "стратегию штанги", которая рекомендует фокусироваться только на супер-безопасных выборах (безрисковых) и на супер-рискованных (но потенциально приносящих большой эффект), убирая середину и сбалансированные по риску выборы. Это уже к вопросу про выбор фич. Не нужно делать что-то среднее — нужно прокачивать то, что не меняется и гарантировано приносит пользу, и что-то безумное, что скорее всего зафейлится, но если взлетит — окупит предыдущие фейлы. Но это уже тема для отдельного поста.

Опубликовали статью Юрия Куприянова на тему «Скрытая работа аналитика по проектированию систем» В этой статье рассказано о том: — как системные аналитики незаметно для себя могут принять проектное решение при анализе требований — где проходит грань между требованиями и проектными решениями — что такое скрытая работа аналитика по проектированию — какие компетенции развивать системному аналитику, чтобы проектные решения были качественными. Статья будет полезна системным аналитикам уровня junior и middle Содержание: 1. Что такое системный анализ — Парадокс системного анализа — Требования вместо системы — Граница требований и проектных решений 2. Проблемы требований к ПО — Существуют ли требования? — Иллюзия требований к ПО — Рекомендации по работе с требованиями 3. Компетенции аналитика в проектировании — Проектирование взаимодействие пользователя с системой — Проектирование хранения данных — Проектирование интеграций, взаимодействия с внешними системами — Архитектура системы 4. Что делать системному аналитику? Переквалифицироваться в проектировщики или в архитекторы? Почитать можно тут

Опубликовали статью по мотивам выступления на Flow'2023 (вот тут в формате видео https://www.youtube.com/watch?v=HzynqWGKehQ)

Главное слово кандидата на собеседовании: «НАПРИМЕР» 📌 Никто не телепат. К сожалению, если вы не будете приводить примеры из своего опыта, нанимающий менеджер не сможет оценить, насколько вы действительно реализовывали те задачи, про которые говорите. Сравните: ❌ Я закрывала сложные вакансии быстро и качественно. ✅ Я закрывала сложные вакансии быстро и качественно. Например, однажды нам в компании срочно потребовался ещё один разработчик баз данных, а подходящих кандидатов на рынке не было, сроки поджимали. В итоге я лично опросила всех имеющихся в команде разработчиков баз данных и попросила рекомендаций на их бывших коллег, получила контакты 10 кандидатов, с каждым связалась и нашла троих, кто был готов не только рассмотреть нашу вакансию, но и выйти в короткие сроки. Всех трёх мы отсобеседовали за 2 дня, выбрали одного, который вышел сразу после согласования оффера. Весь процесс занял у меня неделю. 📌 Примеры нужны для иллюстрации каждой компетенции или ключевого тезиса, которую вы презентуете работодателю. Пример: ❌ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи. ✅ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи. Например, я вижу в вашей вакансии, вы решили внедрить Confluence в качестве единой базы знаний. У меня есть похожий опыт в предыдущей компании, где я, в качестве бизнес-аналитика, помогала внедрять эту систему в команду из 3000 человек. Я хорошо знаю плюсы и минусы этой системы, например, у Confluence есть проблемы с производительностью и я знаю, как их решать. 📌 Любое утверждение становится весомее и понятнее, если вы подкрепляете его примером. Например: ❌ Что я больше всего не люблю в работе? Когда внутренний заказчик возвращается с правками 🙁 ✅ Что я больше всего не люблю в работе? Расскажупример: мы работали как внешний подрядчик и я, как проджект, очень много внимания уделил брифингу клиента, выявлению потребности и формированию полного ТЗ, которое полностью устроит клиента. Каждые 2 недели мы сверялись с клиентом по процессу, чтобы сразу же выявлять проблемные места. Всё шло гладко, мы резво двигались по плану, клиент вносил минорные правки и мы уже подошли к финалу проекта. И тут, когда до дедлайна оставался месяц, на стороне клиента поменялся руководитель, который остановил весь процесс, а потом кардинально поменял ТЗ и потребовал, чтобы мы уложились в изначальные сроки. Я очень не люблю такие ситуации. Хорошо, что я внимательно документировал каждый шаг и мы были документально защищены от такой ситуации. В итоге, я смог наладить контакт с новым руководителем, обсудить с ним его пожелания и наши возможности. Мы сформировали новый план действий и смогли реализовать то, что клиенту было необходимо. 👉 Быстрый совет: напишите на бумажке слово «НАПРИМЕР», приклейте возле экрана на время собеседования, чтобы почаще использовать это слово и подкреплять свои слова наглядными примерами 🙏

Я редко делаю репосты, но тут просто огненная тема! Ну и Киру в принципе рекомендую, если интересуетесь процессами найма и HR. Для аналитиков, о чем можно рассказать, помимо примеров в посте, и что меня бы, например, интересовало при собеседовании аналитиков (кстати, меня, если что, можно звать на собеседования, чтобы оценить кандидата): ⭐️ пример автоматизации бизнес-процесса или отдельной функции (сквозное описание: от выявления требований до технических решений и тестирования, если было); ⭐️ пример участия в проектировании технической архитектуры (или выбора способа реализации, выбора готового решения с учетом технических требований); ⭐️ пример задачи описания требований для проектирования интеграции систем или API; ⭐️ пример решения какой-то сложности в проекте — когда было непонятно, что делать, или заказчик не мог сформулировать требования, или когда требования были противоречивые; в общем — когда вы пришли и поправили всё, спасли бизнес и/или команду разработки; ⭐️ пример применения какой-то техники бизнес- или системного анализа (например, того же DDD или Impact Mapping) — с обязательным указанием, в чем была польза, в чем положительный эффект; ⭐️ пример организации управления требованиями: как фиксировали, как согласовывали, как управляли версиями, как передавали в работу, как принимали выполненную работу. В идеале, всё это нужно раскладывать по методу STAR: Ситуация — Задача — Действие — Результат, прямо так и рассказывать. Я рекомендую при подготовке к интервью составить себе несколько таких примеров, расписанных по STAR, заучить и при случае вставлять. Рекрутеры сами по этому STAR работают, им зайдет. (то есть, если вы нанимаете людей, вы из спрашивать можете в той же логике!) Как вариант, можно использовать метод PARLA: Проблема — Действие — Результат — Опыт — Применение. Последние два — это Learned и Applied: что вы вынесли из этой ситуации, чему научились, и как теперь это применяете. В принципе, даже без задачи подготовки к собеседованию это хорошие вопросы для ретроспективы любого проекта или его этапа.

Я изучаю довольно много информации, в основном статей: научных и постов на сайтах. Далеко не каждая статья становится поводом к посту, и даже наоборот — когда я пишу пост, сначала возникает идея, а потом я ищу материалы. Ну и просто вкидывать в канал ссылки мне не кажется правильным, тут в основном мои персональные мысли. Но если вам вдруг интересно, что мне интересно и что я читаю каждый день — я создал отдельный канал https://t.me/yksdailylinks. Там как раз наоборот — будут только ссылки с небольшими комментариями. Возможно, что-то их этих ссылок когда-нибудь превратится в отдельный пост. А какие-то ссылки будут дополнениями к посту в основном канале. В общем, если вам вдруг любопытны ссылки от меня — welcome!

А вот что меня натолкнуло на написание предыдущего поста. Это из таблицы с бизнес-требованиями, столбец с обоснованием требования. Фактически, ответ на вопрос "Зачем мне, как <роли> это нужно?". Это работа аналитика-стажера, но я видел такое и у штатных аналитиков. Это мощный сигнал! Если вы видите такое — это повод разобраться, что тут происходит. Простое повторение не несет новой информации. Если несколько требований нужны для одного и того же — может быть, это одно требование и оно зря разбито на несколько? А может быть, обоснование взято слишком высокоуровневое, пропущен уровень один рассмотрения. В любом случае, так быть не должно, это недоработка.

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном. Задача аналитика — снизить неопределенность при проектировании системы, чтобы выйти на ограниченный набор возможных решений. Важное слово здесь — "ограниченный", потому что чем больше неопределенность (непонятно, что нужно), тем больше вариантов решений. Фактически, речь идёт об энтропии — числе способов, которыми можно расположить и связать компоненты системы. А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное. Интересное нам нужно, чтобы можно было выбирать обосновано. Если все варианты решений одинаковы — энтропия максимальна, это хаос, ну или нормальное распределение — верно нечто среднее. Такую картину мы получим, если требования собраны случайным образом, бессистемно: будет средняя система, непойми что, информации мало. Если вариантов нет и всё очевидно — энтропия будет минимальной или нулевой, но и информации никакой нет — нечего решать. Мы обычно находимся в интересной промежуточной ситуации, когда расхождение между очевидным и хаотичным велико. А значит, нужно много информации для снятия неопределенности. Поэтому требования должны быть неожиданными! Если вы читаете требования, и всё выглядит усредненно-понятным, значит, требования не передают много информации. То ли система очень простая (нет), то ли работа аналитика выполненная так себе. Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид. А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка). Скольким требованиям в документе вы может поставить такие значки? Конечно, удалять все дубли опасно, тут сразу можно вспомнить про избыточность информации — ведь информацию специальную дублируют при передаче, да и естественный язык у нас крайне избыточен. Но это делают в случае зашумленных ненадежных каналов — когда мы знаем, что часть информации будет потеряна или воспринята неверно. Тут, конечно, нужно смотреть по фактическому положению дел — насколько часто у вас такие проблемы в принципе возникают, и какую степень избыточности вам требуется предусмотреть в требованиях, чтобы информация из них всё-таки дошла.