Привет, коллеги! Меня зовут Юля, я системный аналитик в компании EvApps.

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

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

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

Именно здесь на сцену выходят UX (User Experience) и UI (User Interface) — два фундаментальных направления дизайна, которые, как инь и ян, дополняют друг друга, но решают принципиально разные задачи.

В данной статье разберем:

- UX-дизайн = логика, удобство и функциональность

- Тепловая карта (heatmap) — цифровой детектор лжи для вашего сайта

- Современные тренды UX-дизайна

- UI-дизайн: визуальная магия цифровых продуктов

- Современные тренды UI - дизайна

- Как UX и UI дизайн дополняют друг друга

и почему «нравится» — не аргумент

Разбираюсь, по каким критериям отсеиваю слабые продуктовые решения — не на уровне «нравится», а на уровне «живёт или не живёт». С наблюдениями, которые, возможно, кому-то помогут пересобрать свою систему оценки.

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

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

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

Для себя и, надеюсь, кого-то ещё, я предлагаю эти три разбора, на мой взгляд, основополагающих статей мира ML. Приятного прочтения.

Я отчётливо помню, как сидел на втором курсе на лабах по БД и долго и мучительно методом научного тыка подбирал порядок слов в SELECT-запросе с GROUP BY, чтобы он вернул нужный мне преподу результат. Потому что я не понимал, как работает SELECT, хотя был прилежным (на программистских курсах) студентом, ходил на все лекции и делал лабы за себя и пару "тех парней".

Двадцать лет спустя, когда я встал по ту сторону баррикад и начал сам вести лабы по БД, я столкнулся с той же самой проблемой уже у своих студентов. И, так как за двадцать лет я всё-таки понял, как работает SELECT, то придумал для них способ объяснения, который работает хорошо (в моей практике).

Что, если пользовательские истории не работают? Что, если заказчик не понимает, чего он хочет, а команда тонет в предположениях? Андрей Шапиро  @xraizor — дизайнер интерфейсов и соавтор фреймворка проектирования социотехнических систем — рассказывает о «Карте реализации историй» (КРИ) — практическом методе проектирования, который помогает вытащить смысл из хаоса, превратить знания в структуру и наконец-то начать делать сложные продукты осознанно.

Привет! Меня зовут Катя Халитова, я исследователь из Контур.Фокуса. Cегодня поговорим про важное для бизнеса взаимодействие исследователей и продакт-менеджеров. Эта статья основана на десяти экспертных интервью со специалистами из ритейла, финтеха, телекома и других сфер. 

Мы затронем следующие вопросы:

– Как распределяется зона ответственности в discovery между продактом и исследователем? Есть ли чёткие рамки?

– Какие ожидания есть у продактов и исследователей друг от друга?

– Должен ли продакт валидировать исследования, когда проводит их самостоятельно? 

– Какие факторы влияют на внедрение результатов исследования?

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Несмотря на то, что UML-диаграммы являются популярным и востребованным инструментом, не все системные аналитики используют его в своей работе. Одной из причин может быть непонимание пользы для требований и проработки задачи.

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

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

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

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

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

Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта.

На текущем этапе проектирования воспользуемся Алгоритмизацией, еще одним приемом дисциплины «Системный Анализ».

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

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

1)    Экстраполяционная модель

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

В результате этого оценивания уже можно “поиграть” показателями: время, ресурсы, качество (содержание) и приступить к подбору наиболее подходящего их сочетания. Так же, выявленные объемы и зависимости функциональности позволят делить будущий продукт на модули, подсистемы, контуры и прочие части, обеспечивая поэтапное воплощение, распределение ресурсов и ответственности, снижая риски провала благодаря дроблению. Для решения подобных задач нам очень пригодится умение эффективно определять Границы проекта и управлять ими.

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

Представьте: у вас что-то ноет. Мышца тянет после спорта — само пройдет. Зуб уже третий месяц шепчет: «Отведи меня к стоматологу». В груди где-то тревожный звон, с которым всё нет времени разобраться.

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

UX-долг, о котором дальше пойдет речь, из той же категории. Он может быть мелким и почти незаметным. Может болеть, но терпимо. А может быть критичным — просто ещё не вскрылся до последнего. Проблема не в том, что UX-долг существует. Проблема в том, что его часто не замечают, не фиксируют и не лечат, пока не станет слишком поздно.

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

В этом посте я расскажу, как мы в RuStore выстроили процесс, который помогает не просто «признавать боль», а системно с ней работать: выявлять, приоритизировать и закрывать. И почему UX-долг — это про деньги и эффективность, а не просто «чтобы было красиво».

Одним из основных признаков системы, отличающим ее от #НЕСистемы, является подчиненность всей структуры некоторым целям. Проектная работа команды представляет собой тоже некую систему и, следовательно, должна «идти на поводу» у какой-то цели. Потому установив коммуникации между участниками проекта, начнем вместе с ними определять цели, которые каждое из заинтересованных лиц хочет достичь в результате создания нового продукта.

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

Поскольку мы постоянно оперируем очень сложными конструкциями и понятиями для эффективного управления ими, на протяжении всего курса мы будем использовать прием «Классифицирование» объектов анализа.

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

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

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

Цикл продуктовой разработки часто напоминает весы: с одной стороны, системное проектирование, подбор основополагающих инструментов, масштабные рефакторинги. С другой — совокупность локальных решений, принимаемых для точечных улучшений в системе. И самое сложное тут: соблюдать баланс. Как понять, когда имеет смысл вмешаться «хирургически», а когда — предпочесть вместо конкретной проблемы решить (или предотвратить) целый класс проблем?  

Иногда нащупать границу между «масштабом» и «целесообразностью» получается почти что случайно. Однажды мы в Сравни подступились к переделке чата в нашем мобильном приложении, и на старте расценивали задачу как «ещё один рядовой продуктовый кейс». Но планы по модификации фичи быстро переросли в создание универсального инструмента: конструктора сценариев на базе Backend Driven UI.

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

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

В этой статье я не теоретизирую. Каждый из блоков — это то, что работает. Если вы разработчик, который хочет думать как архитектор — статья для вас.

Если вы архитектор, которому надоело рисовать схемы ради схем — этот список тоже для вас.

А если вы просто строите что-то серьёзное — сохранить, перечитать, внедрить. Это основа.

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

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

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

Предыстория

У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что‑то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.

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