IT-стандарты *

Привет, Хабр! На связи Дмитрий Секачев — корпоративный архитектор службы развития ИТ-архитектуры ВТБ. Я занимаюсь корпоративной архитектурой в дочерних компаниях банка. Сегодня расскажу вам про новый архитектурный продукт — «Референтная прикладная архитектура как АрхПродукт» (РПА как АрхПродукт).

Мы с коллегами готовим серию статей, в рамках которых вы узнаете, как применять данный продукт в процессах слияния/поглощения компаний, построения целевой прикладной архитектуры своей организации, как сократить объем «выборочных» процедур по выбору ИТ-решения и многие другие интересные аспекты применения референтной прикладной архитектуры. Поехали!

Устал от стандартного подхода к саппорту своего продукта через Jira? Надоели миллион уведомлений на почту о изменениях в таске? Раздражает скорость ответа на тикет? Тогда мы идем к тебе...

Привет всем! Меня зовут Таня Конюшенко, и я — продуктовый дизайнер в Купере. В этой статье я рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в моей продуктовой команде. Мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.

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

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

Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?

Привет, Хабр! На связи C#-разработчик компании SimbirSoft Георгий. В этой статье поговорим о том, как с помощью комментариев кода можно ускорить погружение новых разработчиков в проект, упростить написание документации и найти общий язык с коллегами-разработчиками.

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

Привет, Хабр! Я Константин Сошнев, бизнес-аналитик портфеля продуктов «Цифровой вагон» в ПГК-Диджитал. Мы занимаемся созданием цифрового двойника грузового вагона, повышаем точность информации о текущем состоянии вагона, помогаем своими инструментами снижать совокупные расходы на ремонт и увеличивать производительность вагона.

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

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

Project scope, или границы проекта, путем декомпозиции глобальной задачи, показывают нам, какая часть конечного продукта будет реализована в текущем проекте. Проще говоря, определяем черту между тем, что реализовываем сейчас и тем, что отложим на потом или от чего вовсе откажемся. Границы проекта помогут нам не только помочь качественно спланировать объем работ, но и пригодятся для удержания непомерных желаний заказчика. Самое главное, что при определении границ проекта нужно использовать функции, а не сущности предметной области, которые могут привести к ряду негативных последствий.

Есть мнение, что ИТ-сообщество можно условно поделить на тех, кто знаком с пакетом маршрутизации FRRouting, и тех, кто никогда о нем не слышал. Мы решили обсудить его возможности, мнения комьюнити, а также отличия от пакета Quagga.

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

Привет, меня зовут Марина Гончарова, я старший менеджер проектов в Купере (ex СберМаркет). Я работаю в IT с 2008 года, а проджектом — с 2015, и за эти годы у меня накопилось много знаний, приёмов и лайфхаков, которыми хочется делиться. Одна из таких животрепещущих тем — как сделать даже короткие встречи эффективными и результативными для всех участников. 

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

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

Цифровая трансформация 一 одна из 5 национальных целей развития страны до 2030 года. В ее реализации участвует сразу несколько государственных органов и организаций, среди которых АНО «Аналитический центр при Правительстве Российской Федерации», АНО «Цифровая экономика», а также Минцифры РФ, второй год подряд выпускающие объемное исследование под названием «Белая книга цифровой экономики».

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

Встречаем по одежке, а провожаем по уму или что такое мягкие навыки?

Привет, Хабр!

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

Привет!
Коротко о себе:

Мой опыт в разработке ПО насчитывает порядка 18 лет, и 6 из них пришлись на работу в качестве Data Scientist. За это время я прошел путь от научного работника, аналитика данных, дата-сайентиста до Chief Data Scientist в банке. Сейчас я работаю в Синимекс, мы занимаемся разработкой ИТ-систем для бизнеса.

В этой статье я бы хотел обозначить и обратить внимание сообщества на проблемы, а также побудить коллег по Data Science инженерии подключиться к инициативе развития MLOps, чтобы совместными усилиями улучшать IT- ландшафт.

Введение

Представление моделей бизнес‑процессов на основе онтологий (онтологическое моделирование) эквивалентно Semantic BPM. Введение в семантический BPM (Business Process Management) см. «Semantic BPM. Семантика и синтаксис бизнес‑процессов» [semBPM24]. Если кратко, то можно провести аналогию: если классическая BPM система (BPMS: ARIS, бизнес‑студия, fox‑manager и т. п.) — это технологический аналог mediawiki (wikipedia), то Semantic BPM — это технологический аналог semantic mediaWiki (Wikidata), т. е.

IF MediaWiki → Semantic MediaWiki then BPM (ARIS, BPMS, EA) → Semantic BPM

Основной замысел (цель) семантического представления процессов (BPM, EA) не классическими BPM‑системами, а семантическими (Linked Data) — такой же, как и у семантических wiki

Одно из ключевых дополнений к wiki‑гиперссылки (html) это указание не просто что «ОбъектА связан с ОбъектомБ» (т. е. просто «связано») и соответствующий кликабельный переход (wiki‑ссылки, markdown syntax), а указание, что «ОбъектА связан с ОбъектомБ» такими‑то типом отношения (впрочем, как и задание других свойств объекта через отношения).

Изначально все BPMS (изначально называемые CASE‑средствами) — семантические, т.к. их суть — это отношения между объектами, только в них семантика глубоко спрятана «под капотом» BPMS и нестандартная (собственная, проприетарная). Semantic BPM «поднимает» семантическую составляющую на поверхность (возможность работы с семантическим слоем) и использует стандартные сематические технологии Linked Data.

В основе RDF (Resource Description Framework) — триплеты «субъект — отношение — объект» лежит ERD: Entity Relationship (ER) diagram. RDF \ ERD — это способ формализации знаний на основе атома знания — триплета. Вообще ER, subject, predicate, типы рассуждений и другие базовые элементы для работы со знаниями в СССР содержались в школьных учебниках [Логика54].  

Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? 

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

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

В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

Привет, Хабр! Это Оля Муттер, руководитель IT-проектного офиса в Купере (ex СберМаркет). Жизнь заставила меня научиться настраивать процессы как боженька. Я стартовала карьеру в роли бизнес-аналитика, доросла до директора продукта в финтехе, успела побывать наставником для проджектов, создать несколько проектных офисов и центров компетенций — всего за десять лет.

Сейчас я рулю проектным офисом в Купере (ex СберМаркет) — это 1300+ человек в IT-команде. Как понять, работает ли такая большая система эффективно? И что делать, если какая-то веточка этого гигантского дерева растет не в ту сторону? Об этом моя сегодняшняя статья. 

Спойлер: надо дебажить процессы, а для этого придется много работать с цифрами и общаться с людьми. За это у нас в компании отвечают delivery-менеджеры.

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

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

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

Привет, Хабр! Меня зовут Виктория Юльская, и я старший системный аналитик в Ozon.

Я думаю, здесь найдётся много людей, которые хоть раз работали с документацией API в Confluence. Да-да, те самые километровые страницы на каждый метод — с описанием всего и вся в виде текста, таблиц, диаграмм последовательности и т. д.

Зачастую такая документация API в Confluence устаревает ровно в тот момент, как её закончили писать. После передачи задачи в разработку, как только что-то непонятно, куда все идут? Правильно, к аналитику — «А как это работает? А что это значит? А что если...?».

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

Есть ли более эффективный способ ведения и поддержания документации API в актуальном состоянии? Давайте разбираться.