Карьера аналитика

🤔Что такое JSON и в чем его отличие от JSON Schema JSON - это один из самых популярных (а скорее всего и самый) форматов обмена данными на данный момент и он используется повсеместно. Также его можно встретить в требованиях к кандидату для любой вакансии системного аналитика. ❔Что же это такое? JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт. Где используется JSON независим от языков программирования и часто используется для, например: 💩при обмене данными через API. Например, в качестве одного из вариантов передачи body HTTP-запроса - мы можем использовать формат JSON (но это может быть также XML); 💩при создании конфигурационных параметров систем и (микро)сервисов. Например, достаточно часто мы хотим не хардкодить какие-то переменные значения и не зашивать их в код, а сделать их динамическими, для того чтобы не требовалось при изменении этих атрибутов каждый раз привлекать разработчкиов. Для этого, "под ногами" у сервиса создается конфигурационный файл формата .yaml, в котором в формате json указываются необходимые нам настройки. И при необходимости их изменить, поддержка (обычно) изменяет конфигурационный файл, после чего перезапускает сервис, который, в свою очередь, подхватывает обновленный файл и использует уже новые настройки - удобно и быстро. 💩в NoSQL базах данных, например, в MongoDB. Т.е. мы можем хранить прям объект или массив объектов целиком в формате JSON в нереляционных базах. Синтаксис Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}. ➖Ключ – это название параметра, пишется в двойных кавычках; ➖Значение для ключа указывается после двоеточия; ➖Между парами ключ-значение ставится запятая. После последней пары запятая не ставится; ➖Писать ключи можно в любом порядке. Типы данных ➖Строка – "name": "Сергей" ➖Число – целое или с запятой – "years": 24 ➖Логический тип, boolean – true или false – "active": true ➖Массив – "names": [ "Сергей", "Алексей" ] ➖Объект – "person": { "name": "Сергей", "age": 29 } ➖null – пустое значение – "children": null Как нам указывать поля с типом “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке, например, "2008-01-21T11:25:43-05:00". JSON Schema JSON Schema – это способ описания структуры и ограничений JSON-документов. В большинстве случае применяется для валидации данных при обмене информации между разными системами (часто можно ее встретить в том же swagger). С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей. Пример такой схемы:

{ "$schema": "http://json-schema.org/draft-04/schema#", "title": "Product", "description": "A product from Acme's catalog", "type": "object", "properties": { "id": { "description": "The unique identifier for a product", "type": "integer" }, "name": { "description": "Name of the product", "type": "string" }, "price": { "type": "number", "minimum": 0, } }, "required": ["id", "name", "price"] }

Эта схема нам говорит о том, что у объекта "Продукт" есть три атрибута: идентификатор, название и стоимость, каждый из которых обязателен и при этом стоимость не может быть отрицательной. Что позволяет нам валидировать этот объект если, например, ожидаем его получить на вход какого-нибудь нашего метода. Если этот объект не будет удовлетворять указанным требованиям, то мы смело вернем ошибку валидации на такой запрос.

По выходным делаю для вас контент в новом, для себя и канала, формате. После большого зимнего перерыва снова нашел в себе мотивацию и силы для творчества, чего мне не хватало последнее время. Поэтому снова горю, генерирую идеи, кайфую от процесса. А под такое настроение всегда находятся возможности, которые позволяют все эти идеи реализовать (и как всегда они сильно ближе, чем мы думаем, но об этом расскажу в другой раз), и которые мы обычно не замечаем из-за усталости\переживаний\проблем. Считайте это анонсом >3

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

❗️Завышение стажа в резюме: работает или нет? Я думаю многие из вас так или иначе сталкивались, либо слышали, про такой прием при поиске работы - как завышение своего стажа (либо накручивание его вообще, если его совсем нет). А одна из последних прочитанных мной новостей (реальных или нет - это уже другой вопрос), сподвигла меня написать свое мнение на этот счет. Вообще, за 2023 год история с накруткой опыта набрала прям очень большую популярность, потому что было много успешных кейсов, о которых многие спешили поделиться в соц сетях. Появились даже несколько каналов, в которые такие истории регулярно публикуются (рекламировать, конечно не буду). Некоторые из них правда заканчивались очень неудачно для решивших поделиться, потому что их работодали наткнулись на эти посты и неприятно удивились. Поэтому если уж вы воспользовались таким способом, то хотя бы не распространяйтесь об этом =) И подобные методики даже полу-официально предлагали некоторые известные и крупные курсы, которые обещали своим студентам гарантию трудоустройства, а тут, как известно, все способы хороши. Как это работает? На самом деле очень просто, т.к. основная проблема это не пройти техническое собеседование, а именно дойти до него. Прорваться сквозь труднопреодолимый барьер рекрутеров\HR, которые часто даже не смотрят резюме в котором нет хотя бы года релевантного опыта. Поэтому люди просто добавляют некий выдуманный опыт строчкой в резюме и это сразу же повышает конверсию просмотров, заинтересованность рекрутеров и соответственно количество "проходок" на собеседование. А всё потому, что у работодателя нет возможности убедиться в реальности того опыта, который указан в резюме. По крайней мере на уровне HR, а иногда и на уровне СБ, насколько я понимаю. А уж спустя несколько собесов, научиться отвечать социально одобряемым образом на вопросы интервьюера (благо они очень часто одинаковые) - достаточно не сложно. Особенно если ты за энное количество собесов научился держаться уверенно, прокачал скилл их прохождения ив целом производишь благоприятное впечатление. Даже если у тебя слабенькая база. Если ты еще и действительно учился, понимаешь тему, готовился и так далее - то это еще сильнее облегчает собес. Поэтому данный способ достаточно часто срабатывает в плюс и ты начинаешь получать офферы. Не буду давать моральную оценку данному способу, потому что все хотят найти достойную работу, а конкуренция далеко не маленькая. Если есть лазейка чтобы попасть на работу и начать зарабатывать деньги - ну что ж, дело сугубо материальное, осуждать это я не в праве. ❕Однако, лично мое мнение в том, что не нужно перебарщивать. Я имею ввиду то, что если у вас совсем нет опыта - не нужно сразу устраиваться на миддла или сеньора, накручивая слишком большой опыт (такое, судя по некоторым историям, тоже реально). Одно дело без опыта начать работать джуном - от тебя многого ждать не будут, вполне может прокатить и тебя не "раскроют". Но если ты пройдешь на того же миддла и даже не сможешь разговаривать с командой на одном языке - то в чем смысл? Не говоря уже о том, что ты не сможешь выполнять свои задачи самостоятельно, чего ждут от специалиста этого уровня. Испытательный вы вряд ли пройдете, да еще и информация о вас может распространиться в разнообразных чатиках. Поэтому единственный совет - подходите ко всему разумно. P.S. своим студентам я такое не рекомендую и даже не упоминаю такой вариант. Я предпочитаю вариант с повышением конверсии и внимания со стороны рекрутеров через улучшения качества резюме. Добавление ключевых слов, переиспользование текущего опыта, казалось бы не релевантного, в рамках новой профессии и так далее. Все это вполне возможно через консультацию с хорошим карьерным консультантом. И никакого обмана (хотя, конечно, возможно не так эффективно как докрутить себе год или два и придется искать работу месяц, а то и два=) ).

❕ Схемка для решения задачи, которую описывал выше Как и обещал, нарисовал обезличенную схему решения задачи по интеграции двух систем с целью подписания документов (КК и ДБО), про которую рассказывал выше. Она не очень красивая, сделанная на скорую руку, без линий жизни, без использования различных видов стрелочек, которые бы рассказывали о том, синхронное тут взаимодействие или нет, и без много чего еще (возможно). Но для наглядности процесса более чем пойдет. Кстати очень рекомендую, в рамках проработки своих диграмм последовательности не игнорировать указание линий жизни, это прям важно, как минимум для визуального понимания того, на каком этапе взаимодействия включается тот или иной участник взаимодействия. Кроме того, что уже рассказывал, могу добавить, что такие кросскомандные задачи, зачастую обладают еще повышенной сложностью за счет того, что с этими самыми командами бывает трудно найти общий язык или вообще хотя бы время для обсуждения задачи. Да и в целом, в рамках таких задачи, обычно, больше всего времени тратится именно на обсуждение решения\его согласование и при оценке, кстати, стоит его закладывать. Тут только могу посоветовать быть настойчивым, напирать на сроки\важность задачи и всё-таки договариваться о встречах, обсуждать решение и (обязательно) фиксировать его в почте после встречи. Ну а если и после этого ничего не получается, то не стесняться решать эту проблему через своего руководителя. Но конкретно с этой задачей мне повезло, смежная команда была отличной и даже самостоятельно предлагали доработаться под нас, чтобы нам было удобно (😨). И не только предлагали, но и доработались в кратчайшие сроки. Благодаря такой помощи, плюс консультациям по процессу в целом - получилось довольно быстро реализовать эту достаточно большую межсистемную интеграцию. P.S.: Не сжал картинку, потому что иначе телеграм ее сильно шакалит. P.P.S.: Напишите в комментариях, были ли у вас на практике проблемы с кросс-командными задачами или вам попадались только лапушки, которые всегда шли на встречу.

❕Немного о событиях последних двух месяцев (и не только) Как обычно, перед новым годом и своим днем рождениям у меня случилась пауза в ведении канала и любых других активностей, кроме работы. 1️⃣Во-первых потому что этой самой работы было достаточно много (как всегда под конец года); 2️⃣Во-вторых потому что перед свои днем рождения у меня силы обычно на полном нуле и особо нет возможности их распылять на что-то еще. Правда сейчас эта пауза уже достаточно затянулась, поэтому пытаюсь вернуться в своё продуктивное русло. Зато за это время было много интересных задач, много интеграционных историй, которые успешно получилось реализовать (или вступить на путь к их реализации, что тоже не мало =) ). Подумал, что надо больше рассказывать о каких-то практических примерах задач, в обезличенном виде, и примерных вариантах их решения, потому что это может быть полезно для понимания того, какую работу мы (аналитики), вообще выполняем и может иметь практическую пользу для кого-то из вас в том числе. Например, одна из интересных задач, которая была у меня на практике - это интеграция нашего кредитного конвейера с ДБО для того, чтобы клиент мог удаленно подписывать свой КОД (кредитно-обеспечительную документацию) удаленно, в своём мобильном приложении, без необходимости личного присутствия в офисе. Сейчас это не новость и в принципе это реализовано уже много где, да и в целом мы все с большой силой стремимся в цифровизацию, безбумажность и вот это всё новое, удобное и красивое. А всё для того, чтобы людям было удобно и просто пользоваться любыми ресурсами (круто же иметь Госуслуги, личные кабинеты во всех сервисах\банках, которые предоставляют огромное количество функций и возможностей решить почти любые вопросы удаленно? А это всё мы, команды разработки. Ну и наши любимые заказчики, которые все эти идеи круто накидывают на вентилятор). По-моему я только из-за этого до сих пор держусь и не выгораю. Кхм, да, отвлекся. С точки зрения бизнеса задача была предельно понятна. Взять те документы, которые сформировал наш Кредитный конвейер (КК) и отправить их в систему ДБО, чтобы они отобразились у клиента и он мог ознакомиться с ними, нажать на кнопочку и подписать. Ну и потом эти документы должны были отправиться к нам, чтобы мы узнали о том, были ли они подписаны или нет и далее пользоваться уже подписанной версией. С технической точки зрения всё было несколько сложнее. Начнем с того, что у нас разные файловые хранилища (что плохо, но уж как есть) и соответственно нам надо было брать документы из нашего ФХ, сохранять их в ФХ ДБО и только после этого отправлять определенный список документов в ДБО для подписания. Первая часть интеграции, по получению\сохранению документов, должна была идти синхронно, вторая уже асинхронно, потому чтоэто надежно, ну и с бизнесовой точки зрения у клиента было время на подумать, хочет он вообще это подписывать или не особо. Поэтому ответ нам приходил уже также асинхронно. И вот задача как раз заключалсь в том, чтобы придумать это решение (архитекторов не было, но в данном случае он и не особо нужен был, потому что решение лежало на поверхности), проработать все нюансы (как загружать в ФХ, как оно вообще работает, какой набор документов, как скачивать, какой атрибутивный состав сообщения для ДБО должен быть, что мы ждем в ответ и когда и т.д.) и описать это решение, что занимает не так мало времени. Но ковыряться со всем этим достаточно интересно. В следующей части поста набросаю примерную схемку этого решения и дам еще пару комментариев. P.S. Кстати, результаты опроса, который я закидывал позавчера достаточно ожидаемы почти во всем, но я таки удивлен, что аж 40% людей нравится рисовать диаграммы, а 42% нравится консультировать команду. Я думал тут будет значительно меньше голосов, но это интересно, в любом случае. Спасибо, что вы остается активными, даже спустя такой перерыв в постинге ❤️

Пример отрисовки диаграммы последовательности с помощью PlantUML из их справочного руководства.

📊Диаграммы, часть 7. Где рисовать? Сегодня не надолго вернемся к диаграммам - был ряд вопросов на тему того, какой инструмент лучше использовать для отрисовки той или иной диаграммы. Что касается UML - если не брать сложные архитектурные инструменты, типа Enterprise Architect, Archimate и вот это вот всё, то системному аналитику для использования будет достаточно одного из следующих: 1️⃣Visio - хорошо подходит для отрисовки диаграмм UML (и не только) любой сложности. Платный. 2️⃣ Lucidchart - аналогичный онлайн-инструмент, который поддерживает не только UML, но и всякие там диаграммы Ганта (если они вдруг кому-то еще интересны), mindmap'ы и так далее. Условно-бесплатный. 3️⃣ Creately - тоже не могу чем-то выделить, все эти инструменты достаточно похожи. И так далее. На самом деле достаточно вбить в поисковую строку запрос "UML online" и там будет достаточно много выбора из платных или бесплатных инструментов. Но этими я пользовался, они хорошо заходят и достаточно удобны в освоении. Но! Кроме этого, если возможность отрисовывать UML-диаграммы не только через графические редакторы, но и через письменные движки. Это такие инструменты, которые обрабатывают написанный вами текст и преобразуют его в ту или иную uml-диаграмму. Кто еще не пробовал - очень рекомендую. Лично я пользуюсь именно этим способом, потому что для меня он более ламповый и уютный. Хотя не могу не сказать, что с непривычки он будет более медленный, чем набрасываение различных компонентов UML с графической формы (но, что интересно, многие аналитики пользуются именно им - хотя я сам для себя не могу объяснить, почему я выбираю этот способ). Основной инструмент подобного типа - это, конечно же, PlantUML. Он поддерживает любые диаграммы UML и даже больше. Плюс у него есть очень понятное справочное руководство для каждой из типов диаграмм. Пример скину в следующем посте картинкой. Поэтому - если вдруг не пользовались и хотите что-то новое, то welcome. Что касается BPMN - тут все аналогично, вбиваете запрос "BPMN онлайн" и выбираете приглянувшийся инструмент. Из тех что я пользовался, это: 1️⃣bpmn.io 2️⃣Camunda Но в целом тут порекомендую скачать десктопную версию camunda modeler - что особенно актуально, если у вас на проекте применяется BPMN-движок бизнес-процессов, а не просто рисуете BPMN схемы для заказчика или команды. P.S. Недавно находил еще один аналог PlantUml из свежих, который меня зацепил не только функционалом, но и дизайном, но я забыль как он называется. Если найду - напишу. А какие инструменты вы используете?

🤔Подходы к детализации проработки ТЗ системным аналитиком Давненько я тут ничего не писал - навалились личные дела, много работы и учеников. Да и в целом, у меня периодически бывают периоды застоя, когда я в очередной раз не знаю о чем писать - возникает ощущение, что я уже обо всем столько всего написал, а о чем можно еще - идей нет. Но потом это проходит и эти идеи так или иначе генерятся. Но как раз по этой причине часто прошу вас выдвигать свои темы для обсуждения - поэтому всегда добро пожаловать в комментарии с какими-то идеями или запросами на освещения каких-либо тем. Это всегда приветствуется, т.к. снимает меня часть нагрузки по придумыванию следующих тем 😅 Т.к. пост получился очень большим и не влезает в стандартный формат телеги - то оформил его в телеграфе. После прочтения - оставьте свой комментарий о том, в рамках какого процесса из перечисленных четырех вам довелось работать и какой из них вам наиболее комортный? Несмотря на то, что я топлю за псевдокод, полноценное, супер детальное описание и вот это всё - вполне могу понять, когда комфортно работать по-другому. Поэтому с удовольствием обсужу плюсы и минусы любого подхода. А в следующих постах попытаюсь порассуждать на тему того, почему вообще получилась настолько большая разница в степени участия системных аналитиков в тех или иных проектов.