Анализ и проектирование систем *

— Голдстейн. 

— Да, мистер Старк. 

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

©Железный человек

Привет, Хабр! Меня зовут Дмитрий Сушков, последние 5 лет работаю железным человеком бизнес-аналитиком. Сегодня поговорим про одну из самых важных задач бизнес-аналитика (BA) — сбор и приоритизацию требований. Эта область довольно мутная, ибо редко бывает единый правильный подход. На каждом проекте есть свои «острые углы»: как договориться с заказчиком, прояснить его реальные потребности, оформить требования так, чтобы их поняли все участники, и при этом успеть всё в срок. Это как разжигать костёр в ливень, в открытом поле, пробовали?) И не стоит. 

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

Эта статья будет полезна:

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

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

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

Не поверхностно, а с разбором боевых кейсов, с примерами и выводами, которые можно вполне себе использовать, как чек-лист. Чтож! Щас выскажусь!)

Привет, Хабр! Я Сергей Гайдамаков. Уже 28 лет я занимаюсь проектированием и разработкой программных систем различного масштаба. Сейчас работаю в Т-Банке системным аналитиком и проектирую системы, которые в совокупности составляют большую распределенную систему. 

Несмотря на большое число статей про CAP-теорему, есть трудности ее практического применения при создании распределенных программных систем. Я описал результаты тестирования набора реплик MongoDB в штатных и аварийных ситуациях, параметры запросов для достижения требуемых свойств CAP-теоремы. А еще развенчал некоторые заблуждения и мифы относительно базы данных MongoDB. 

Привет, Хабр! Меня зовут Андрей Бирюков, я СTO Сервисной цифровой платформы в Газпромбанке. За свою карьеру поработал в нескольких компаниях — от стартапов до крупных корпораций — и видел разные архитектурные подходы.

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса. 

Недавно сходил c Витей на запись подкаста на эту тему и настолько преисполнился, что  решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.

Ваш планинг — фикция? Перестаньте гадать на кофейной гуще: как декомпозировать сложную задачу и оценить сроки, нырнув прямо в код. Инструмент и методика внутри.

Привет! Меня зовут Дмитрий Бандурин, я заместитель директора департамента биллинговых решений в компании «СИГМА». Моя команда регулярно выполняет нетривиальные задачи для стабильной работы высоконагруженных систем. Сегодня расскажу, как мы переработали логику обработки пакетных процессов в нашей системе массовых операций, на примере расчета дебиторской задолженности. Нам было необходимо, чтобы она справлялась с возрастающим объемом данных — и всё это в жестких временных рамках и в условиях многопоточности.

Что такое коннектор? Как выглядит код коннектора? И как коннекторы могут использоваться в различных сценариях?

Когда в этом году была выпущена Camunda Platform 8, мы анонсировали коннекторы и предоставили несколько предварительных версий коннекторов в нашем SaaS-решении, например, отправка email через SendGrid, вызов REST API или отправка сообщения в Slack.

С тех пор многие задавались вопросом, что такое коннектор, как он разрабатывается и как его можно использовать в Self-Managed-окружении. Мы пока не публиковали много информации о технической архитектуре коннекторов, поскольку она всё ещё находится в разработке. Тем не менее, я отлично понимаю, что вам может быть интересно узнать больше, чтобы вдохновиться коннекторами так же, как и я.

Зачем программисту алгоритмы?

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

Однако сами программисты нередко удивляются, зачем всё это? Действительно, работа наших коллег часто заключается в поиске и устранении ошибок в залежах legacy кода. Какие уж там алгоритмы? Даже те, кому посчастливилось участвовать в новом проекте знают, что зачастую новый проект состоит на 80% из чужого, уже кем-то написанного и найденного на просторах гитхаба кода, а новый код - это, по сути, клей и обёртки, которые позволяют склеить эти уже готовые запчасти между собой, чтобы получить заданный продукт.

Сегодня я прочитал на Хабре статью о подготовке к алгоритмическому собеседованию в Яндексе. Видно, что ребята относятся к делу всерьёз. Однако на вопрос, зачем всё таки это нужно, статья отвечает в том духе, что алгоритмическая подготовка показывает полезную готовность кандидата поотжиматься (отмечу при этом, что это не мнение Яндекса, а личное мнение человека, получившего этот опыт с обеих сторон - и кандидата и интервьювера).

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

На работе была поставлена задача: в главное веб-приложение нашей фирмы добавить метод формирования бланка в формате PDF «как вот в том микросервисе».

Форма бланка регулярно изменяется, и копировать её в веб-приложение означало нарушить принцип DRY («Не повторяйся») и обречь себя на постоянную двойную работу. Поэтому я решил оставить генерацию бланка в «том микросервисе».

«Тот микросервис» написан на PHP с использованием фреймворка Laravel, содержит большое число доменных объектов, экземпляры которых хранятся в БД MySQL, и имеет развитую систему API для обращения к своему функционалу.

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

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

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

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

Когда мы начали проект и приступили к работе, неожиданно столкнулись и с проблемами в подготовке качественных артефактов — тех самых User Story, которые нужно было передать разработчикам. На груминге (у нас в команде «Story Refinement») постоянно возникали вопросы: истории одна за другой отправлялись на доработку по разным причинам. Позже, уже на этапе разработки, часть требований вновь возвращалась с замечаниями: требовались дополнительные уточнения. 

Мы начали анализировать ситуацию и осознали, что команда теряет очень много времени. Например, на груминг собирались все 9 участников, обсуждали User Story, но в итоге понимали, что она не готова — её нельзя отдать в разработку, а значит, нужно вернуть аналитикам на переработку. Нас это категорически не устраивало: такие циклы требовали огромных затрат времени. 

Сталкивались ли вы с тем, что открывая сайт или приложение приходилось долго и мучительно искать нужный раздел? Бывало ли так, что, работая с определенной программой, приходилось пройти несколько, на первый взгляд, избыточных шагов, прежде чем удавалось добиться своей цели?

Пользовательский путь закладывается на этапе работы с требованиями. И, помимо UX/UI, важным этапом проработки является формирование сценариев использования системы. В этой статье разберем теоретическую часть и определим, что же такое Сценарий использования.

Исследование принципов Domain-driven Design (DDD) на примере кейса "Аутсорсинг"

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

Мы определились как оценивать системы: получаем оценки функциональной части системы, оценки ее технологического совершенства, после этого продукт и его оценка попадает в следующий модуль системы «Федерация» — каталог групповых решений. Структуру и принцип построения этого, последнего, компонента «Федерации» нам осталось рассмотреть.

Для общего понимания каталог «Федерации» — это магазин технологических продуктов Gруппы, в котором есть свои специализированные отделы (АБС, CRM, ДБО), на витринах которого представлены ИТ‑решения в уже проведенной оценкой, которую нужно применить для конкретную организацию.

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"

Pro-code — наше сердце и душа, но люди и процессы бывают разными. Наши необязательные low-code-функции расширяют спектр применений, не мешая разработчикам.
 
Разработчики часто спрашивают меня о стратегии развития продуктов Camunda. Особенно во время запуска Camunda 8 они выражали обеспокоенность тем, что мы якобы «забыли свои корни» или «отказались от удобства для разработчиков» — именно те качества, за которые нас любят. Появилось мнение, что мы «прыгнули в поезд low-code», потому что у нас теперь есть финансирование и мы хотим «гнаться за большими деньгами». Как разработчик в душе, я могу вас уверить — это совсем не так. Позвольте объяснить нашу стратегию в этом посте.
 
TL;DR: Мы остаёмся на 100% дружелюбными к разработчикам, и pro-code — это наше всё (можно сказать, наш хлеб с маслом). Но люди, создающие процессные решения, бывают разными — как и сами процессы, которые нужно автоматизировать. Для некоторых сценариев low-code действительно имеет смысл, и здорово, что мы можем их поддерживать. Но low-code-функции в Camunda являются необязательными и никак не мешают pro-code-разработке.

Вам надоело, что бизнес приходит с абстрактными проблемами, или того хуже с готовым решением? В итоге ограничивая работу отдела разработки в принятии решений? Как сделать сложные требования понятными и структурированными, чтобы они работали быстрее и эффективнее для решения задач бизнеса?  

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

Формат Use Case помогает избежать этих проблем. Он описывает сценарии взаимодействия пользователей и систем в четкой, последовательной форме. Это не просто техническая документация, а «инструкция» для всех участников проекта: аналитиков, разработчиков, тестировщиков и бизнес-пользователей.

Автор: Борис Абрамов, lead system analyst

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

Сегодня рассмотрим, как на голом SQL построить полноценный когортный анализ: определим дату первой покупки, сгруппируем пользователей по когортам, посчитаем удержание (retention), оценим LTV по месяцам жизни и сделаем RFM-сегментацию.

Бизнес без устали тестирует разные гипотезы о том, как логично внедрять customer experience (CX) в производство своих продуктов. От команды к команде опыт подхода к этому «снаряду» отличается. Даже в рамках одной компании бывает, нет единого представления, как «сочетать несочетаемое»: ориентироваться на клиента и при этом зарабатывать деньги.

В RUTUBE мы нашли свой путь: пригласили в продуктовые стримы отдельных сотрудников. Их задача — погружать продуктовую команду в пользовательские запросы и потребности. А фоном — продвигать стратегию (и идеологию) классного клиентского опыта. Мы назвали себя Customer Journey Experts.

Здесь не будет пропаганды и пустых лозунгов — только конкретные действия, которые мы предпринимаем каждый день.

Знаете, как часто бывает: читаешь чей-нибудь умный труд (например, прекрасную книгу Карла Вигерса «Разработка требований к программному обеспечению»), всё вроде понятно — требования должны быть полными, корректными, осуществимыми… Теория отличная, хорошо описаны процессы, связанные с коммуникациями с заказчиком (как проводить интервью, какие бывают требования к информационной системе и как их выявлять). 

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

Это первая статья в блоге нашего стартапа, надеюсь, что не последняя. Мы разрабатываем инструмент моделирования и будем делиться нашим видением идеального продукта, рассказывать про наши успехи и неудачи, надеюсь, что будем получать критику и в итоге у нас получится что‑то полезное.