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

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

Рассмотрим подробней.

Привет, Хабр! Представляю вам перевод статьи "How Uber Serves Over 40 Million Reads Per Second from Online Storage Using an Integrated Cache" автора Preetham Narayanareddy. Из неё вы узнаете, как в Uber проектировалась система кэширования на основе Redis, с какими сложностями и тонкостями пришлось столкнуться разработчикам, и как в итоге им удалось создать действительно высокопроизводительное решение.

Привет, Хабр! Меня зовут Ольга Матушевич, я наставница на курсе «Аналитик данных» в Яндекс Практикуме. Большая часть наших студентов в качестве цели обучения указывает успешное трудоустройство в новой профессии. Поэтому мы внимательно отслеживаем, у кого из выпускников получилось устроиться на желаемую должность, сколько времени это заняло и сколько усилий потребовало. На основе этих данных мы строим наши продуктовые обещания студентам.

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

Ставится задача повторить доселе непревзойдённый ARIS SmartDesign, который по табличному представлению процесса автоматически рисует схему процесса (структуры чего-либо). Схемы процессов желательно строить в нескольких процессных нотациях (EPC, VAD и т.п.). ARIS SmartDesign также умеет по табличному представлению орг-структуры (другой древообразной взаимосвязи) строить иерархическую схему (тут рассмотрим только процессные схемы).

Системы / Инструменты ВРМ (Business Process Management System/Tool) часто представляют из себя что-то очень сложное и дорогое. Чтобы работать с ними для формализации (моделировании, описании) даже простых процессов нужно много учиться, включая зазубривание различных нотаций. Ниже показан вариант как на простом инструменте можно составить схему своего процесса «с нулевой» подготовкой в области BPM. Достаточно заполнить несложную табличку и получить схему процесса в нескольких нотациях, как это показано на заставке. Инструменты типа SmartDesign реализуют подход «таблица с процессом в схему процесса».

Работа с рассмотренными ниже инструментами SmartDesign – чрезвычайно проста и не требует никаких навыков. Статья может показаться сложной, вследствие того, что в ней много посвящено сравнению ARIS SmartDesign vs DOT SmartDesign и рассмотрены технологические аспекты обоих инструментов, которые рядовому пользователю не понадобятся. Однако в сущности нам нужно просто заполнить таблицу и мы сразу получаем его схему.

Только в системе ARIS (самая известная BPM-система) ранее была представлена реализация SmartDesign, концепцию которого можно назвать инструментом «моделирование без моделирования», по аналогии «программирование без программирования». Несмотря на долгое существование и наличие его не только в платной версии ARIS, но и в ARIS Express – этот инструмент остается недооцененным и поэтому в целях его популяризации предлагается альтернативная реализация DOT SmartDesign, причем в нескольких вариациях (excel, javascript).

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

Меня зовут Мочалин Евгений. Я работаю в технической команде фронтенда медицинской компании СберЗдоровье. В этой статье я хочу поделиться историей, как мы выстроили процессы внутри команды, чтобы работа со всеми продуктами компании была прозрачной, стандартизированной и очевидной для всех сотрудников.

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

Нужна ли аналитику креативность? Работодатели, похоже, считают, что нет или что креативность не важна. Например, на hh.ru всего 10 вакансий «с креативностью» по всей России на момент написания статьи. И только в двух из них (Ozon и «Ростелеком») говорят напрямую, что креативность нужна.

Я работаю с данными почти 20 лет, и из них семь набирала и растила джунов, три — наставник в Практикуме на курсе «Аналитик данных». Предлагаю вместе подумать, а нужна ли нам креативность, как проверить, есть ли она, можно ли её чем-то заменить и как прокачать.

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

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

Идеальная документация должна выполнять две основные функции...

Гайд для самопроверки бизнес-историй перед отдачей их на ревью лиду аналитики и команде

Достаточно большой опыт работы с бизнес-историями помог мне сформировать список правил для их самопроверки перед финальным показом команде. И в этой статье я хочу поделиться ими с вами.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

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

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?

Всем привет! Делюсь очередным выпуском нашей рубрики «Открытый микрофон», тема этого выпуска — «Как написать свою первую спецификацию на REST API».

Спикером стала Мария Яковлева. Маша — ведущий аналитик Платформы Сфера, НОТА (Т1 Консалтинг). В интернете много описаний особенностей архитектурного стиля REST, но мало информации о том, как аналитику начать создавать качественные спецификации на REST-методы. Маша поделилась своим опытом и, что особенно ценно, ошибками, допущенными в работе. А ещё Маша систематизировала их, чтобы уберечь вас от них)

Ниже предлагаю расшифровку трансляции, ссылку на сам выпуск оставлю в конце статьи.

На одном из недавних проектов снова встал вопрос регионального продвижения. Проект уже имел региональный функционал на основе поддоменов. О том что нас не устраивало и как мы нашли win-win способ для поисковиков от Yandex и Google.

Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям. 

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

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

A/B тестирование позволяет принимать обоснованные решения о том, какие функции или изменения наилучшим образом способствуют улучшению пользовательского опыта и повышению конверсии. Однако, несмотря на кажущуюся простоту проведения таких экспериментов, существует ряд подводных камней, которые могут серьезно исказить результаты. Один из самых заметных и опасных — это так называемая проблема peeking или подглядывания. Эта проблема возникает, когда аналитики и маркетологи начинают слишком рано анализировать данные теста, не дожидаясь его завершения. Такое поведение может привести к неверным выводам и решениям, которые, в свою очередь, могут нанести ущерб бизнесу.

В статье рассмотрим, что такое проблема подглядывания в контексте A/B тестирования как ее решить.

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

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

Всем привет! На связи мы, Мария и Яна из самой драйвовой IT-команды «БАРС Груп». В этой статье расскажем, как создавали инструмент эффективного взаимодействия в IT-команде — базу знаний постановок задач, которые реализует проектная команда. По порядку разберем, почему мы решили создать шаблон, как разрабатывали и как доводили до ума после внедрения и, конечно, о результатах.

Чем похожи дашборд и рекламный баннер? 

У нас упала конверсия из просмотров в клики! У нас не продаются товары! Два йогурта по цене одного! Оба привлекают внимание, содержат и картинки, и текст и реже, чем хотелось бы, приводят к действию.

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

Этот материал может быть полезен для COO, бизнес-аналитиков и топ-менеджеров компаний. Хотя в тексте присутствуют некоторые технические детали, надеюсь, они не будут слишком сложными. Цель материала: показать общую логику, которую мы использовали для извлечения и анализа данных.

Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.

Всем привет!

Меня зовут Рыловникова Татьяна. Я ведущий аналитик в компании Ви.Тех, а еще идейный вдохновитель клуба Питерских одинэсников, ведущая и автор подкаста «Аналитики у микрофона», докладчик и модератор на конференции АиУП.

Уже несколько лет для профессионального развития мне не хватает только курсов, аттестаций, видео и книг, я бы хотела поделиться с вами моими способами развития, расскажу на своем примере 5 способов, как еще может развиваться аналитик:

1. Обратиться к ментору

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

2. Самому стать ментором

Как говорится «Лучший способ чему-то научиться – начать учить этому других». Во-первых, вы понимаете, с какими сложностями сталкиваются ваши коллеги по цеху. Во-вторых, развиваете навыки коммуникации и обучения других людей. В-третьих, вы и их опыт в ответ тоже получаете. Да, скорее всего у вас в целом опыта больше, но у каждого человека есть какой-то свой уникальный опыт, и в этом общении вы его так же можете получить.

3. Книжный клуб

Я столкнулась с тем, что чем более я погружаюсь в профессию, тем более объемной становится литература. Так, например, долго ходила вокруг книги Карла Вигерса «Разработка требований к программному обеспечению». Даже купила ее, начала читать, но, учитывая объем материала, я в нем терялась. Тогда я подумала, чтобы было бы классно читать книгу с коллегами. Сделала на работе книжный клуб для аналитиков, мы читаем по 2 главы раз в 2 недели и обсуждаем их. Главный профит: ребята рассказывают то, что пробовали или хотели бы попробовать и как на самом деле это выглядит на практике. Материал воспринимается намного лучше. А еще у меня прокачиваются организационные навыки.