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

юбиквотус...

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

И, да, Эрик Эванс крутой чувак...
Но он не придумал с точки зрения английского языка ничего нового - Ubiquitous - это всего-лишь "вездесущий" (*с одной С:)), или, если переводить ближе к изначальному замыслу в контексте его подхода - то "всеобщий" (т.е. применимый везде, понятный всем - существующий в сознании всех участников проекта)...

От того, что на конференциях/вебинарах/на работе вместо "всеобщий язык" (ну, ладно - пусть даже "вездесущий язык") люди гордо говорят "юбикуитос лэнгуидж" (а на одном вебинаре - как в сказано в начале поста - "юбиквотус") становится только хуже, потому что:

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

• говорящий часто сам до конца (до глубины) не понимает, о чем речь, он не чувствует термин

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

P.S.: на картинке UL как его понял ИИ

Мастер-класс: «Как оптимизировать операционную деятельность компании на базе low-code BPM-системы»

Кто проводит: Бауманский учебный центр «Специалист»

Почему это важно:

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

Поэтому российские компании все чаще используют в качестве единой информационной системы low-code BPM-решения. ПО такого класса позволяет быстро оцифровывать любые процессы без привлечения программистов. Такие системы уже используют «Спортмастер», «ВкусВилл», «Академия РосАтома», «Сколково».

Чему научатся участники:

• узнают, как устроена панель администратора, где настраиваются бизнес-процессы;

• какие знания нужны для работы с low-code конструктором;

• какие бизнес-процессы можно оцифровать в одной системе;

• как интегрировать BPM-систему с другими источниками корпоративных данных.

Вам будет интересно и полезно, если вы:

Бизнес-аналитик, системный аналитик, руководитель предприятия, руководитель службы компьютерного обеспечения.

Как попасть:

Участие бесплатное, по предварительной записи.

Волшебник Изумрудного города, или Как тестировать MVP сложного продукта

Расскажем об интересном методе тестирования продуктов. Он называется — «Волшебник страны Оз».

Если вы помните, волшебник в одноименной сказке оказался фокусником. Такую же роль для респондента при этом подходе выполняет исследователь.

Например, компания разрабатывает голосовое управление для онлайн-кинотеатра, но в приложении такого функционала пока нет. Приглашают пользователя для теста. Он говорит: «Хочу посмотреть сериал "Друзья"».

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

Обычно этот метод используют для продуктов, в которых сложный функционал. Интегрировать такой в MVP дорого и накладно. Это может быть то же самое голосовое управление, AI-поиск, VR/AR.

Метод также может быть открытым, закрытым и смешанным.

✓ Открытый — когда у исследователя нет готовых реакций/ответов.

✓ Закрытый — когда они уже четко проработаны.

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

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

Больше о тестировании MVP и UX-исследованиях читайте в нашем Телеграмм-канале.

Как загрузить csv-файл в базу данных. Четыре разных способа

В новой, но уже такой родной рубрике «Базировано» мы рассказываем о базовых вещах, которые должны уметь ИТ-специалисты. В этот раз системный аналитик «Технократии» Руслан Степанов рассказывает о разных способах загрузки csv-файла в базу данных.

Надеемся, что YouTube поправится, и вы сможете познакомиться с тайными знаниями аналитиков «Технократии».

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

1. Погружение в профессию сделали более плавным — начнаем с простых инструментов, сложность нарастает постепенно. Теперь совмещать работу с учёбой станет проще.

2. Ещё больше практики: квиз или тренжер в каждом уроке; кейс-проекты после всех спринтов и большие проекты после каждого модуля. Добавили форматы воркшопов с упором на групповую работу: лайв-кодинг, разбор кейсов, симуляция решения задач в команде. Будут проекты реальных заказчиков и дополнительная практика на кейсах компаний.

3. Дополнительная специализация в расширенной версии: выберете между продктовым и BI-аналитиком.

4. Основы линейной алгебры, машинное обучение, алгоритмы — 3 темы в расширенной версии курса, чтобы решать более сложные задачи.

Практикующие эксперты с разным опытом, отдельный модуль по работе с нейросетями и помощь с трудоустройством — всё это тоже будет!
→ Подробнее о курсе

Сперва определяем ценность для пользователя, потом придумываем решения

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

Посмотрим на примере: на картинке — стратегическая пирамида для условного интернет-магазина, в который решили добавить ленту новостей.

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

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

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

P. S. Это часть статьи о ловушке форм-фактора, читайте ее полную версию тут.

📺 Сегодня в 15:00 МСК мы проведём собеседование middle бизнес-аналитика в прямом эфире!

Всё будет как вы любите — лид бизнес-анализа из X5 Tech будет собеседовать кандидата уровня мидл напрямую, без участия HR. Собеседование будет техническим и проходить в виде кейсов.

→ Чтобы подключиться к эфиру, нужно просто перейти по этой ссылочке

P.S. Нам по секрету рассказали, что сейчас в X5 Tech нужны специалисты уровня мидл+ и через эту вакансию распределяют аналитиков по различным продуктам.

📕 Илья  Отькало.  «Автоматизация бизнес-процессов», 2024 

Кратко: добротная ознакомительная экскурсия по 1С-автоматизации предприятий

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

Структурно книга делится на следующие части:

▶️ знакомство с понятием “бизнес-процессов”, с их автоматизацией, моделированием, способами и инструментами описания

▶️ виды учета, типовые и отраслевые решения 1С, подходящие для их автоматизации,

▶️ корпоративная архитектура

▶️ основы интеграции и обмена данными в решениях 1С

▶️ проекты внедрения ПО: основы проектных технологий 

😊 Плюсы:

🔹 идеальная книга для курса молодого бойца при онбординге и введении в профессию аналитиков и РП в 1С: Франчайзи

🔹дает хорошее представление о подходах  к внедрению и проектам 1С для тех, кто из другой сферы

🔹здоровая и, в целом, удачная попытка интегрировать аналитику 1С в современный IT-ландшафт

😐 Особенности:

🔹неглубокое погружение в предмет (скорее всего, не подойдет для профессионалов)

🔹немотивированные акценты на отдельно взятых инструментах и методологиях (в ущерб другим)

🔹недостаток примеров артефактов и документации (можно было бы вынести их в приложение или комплект для скачивания)

Более подробный обзор - в "Проектном дайджесте".

Синхронизированный процесс комплексной охраны от чрезвычайных ситуаций обеспечивает уникальный роботизированный комплекс «Еловой» (от англ. «YellowBoy», код. назв. проекта - Китаец) - роботизированный комплекс нового поколения, работающий на основе технологий виртуализации, шаблонного проектирования, многопоточного исполнения и исследования результатов нейросетевого творчества.

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

Приглашаю обсудить в комментариях ваши мысли и идеи.

Привет, Хабр! Сегодня делимся ссылками на недавние материалы для аналитик и дата-сайентистов. Говорим о том, что происходит на рынке труда для начинающих; разбираем, какие задачи выполняют специалисты и без каких навыков не обойтись.

→ Перспективы профессии Data Science: ликбез для джунов
→ Чем на самом деле занимается специалист по Data Science
→ За что аналитику данных платят зарплату
→ Собеседования джуна аналитика данных: чего ждут и что спрашивают работодатели
→ Рынок вакансий для аналитиков данных в 2024 году

А тут собрали подборку небольших бесплатных курсов, которые помогут освоить базовые навыки для этих профессий:

→ Основы работы с базами данных и SQL
→ Основы анализа данных и Python
→ Основы математики для цифровых профессий
→ Основы статистики и A/B-тестирования

О целях интерфейсов

Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.

Фишка в том, что во многих случаях цели владельца интерфейса будут отличаться от целей пользователей. Да, когда речь идёт, например, о посадочных страницах, у всех почти всегда одна цель — чтобы сделка состоялась. Ну или, на худой конец, целевое действие было совершено (например, заявка улетела на почту).

Сегодня же у меня на аудите интерфейс мобильного приложения производственного календаря. И цель его создателя (помимо прочего) — заработать на рекламе. А цель пользователей — … ну, их несколько. И чьи же цели учитывать аудитору и как?

Об этом рассказываю в новом ролике.

Почему у китайского FineBi от FanRuan на Гартнер всего 2(!) отзыва против тысяч отзывов у PBI, Qlik, Tableau?

Официально на сайте китайского вендора написано от 9 апреля 2024 года: «Стоит отметить, что FanRuan в очередной раз удостоилась почетного упоминания после того, как была признана в 2021 и 2022 годах. FanRuan остается единственным независимым поставщиком бизнес-решений из Китая, который был включен в отчет, что еще раз подчеркивает ее достижения и присутствие в отрасли».

Упомянули уже три раза, в квадрант не включили, условия попадания в квадрант выполнять даже не пытаются … не ужели это заградительные барьеры от китайской экспансии на северо-американский рынок и, понимая это, вендор просто не тратит денег на накачку отзывами свой аккаунт-бренд на Gartner.com Или там нет шансов просто продать свой продукт?

https://www.gartner.com/reviews/market/analytics-business-intelligence-platforms/vendor/fanruan-software/product/finebi

Подружим аналитиков с лизинговым проектом через собес

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

Опыт в финтехе или близких сферах – твоя суперсила.

А что от нас?

Киллер-фичи этого проекта:

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

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

Киллер-фича нашей команды:

– Теплый прием, общительные коллеги и центр компетенций по аналитике, в котором ты будешь расти профессионально.

Как стартануть процесс?

Откликнись на вакансию здесь. 

Или напиши Ольге в телеграм.

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

Ольга Матушевич, наставница на курсе «Аналитик данных» в Практикуме проанализировала 1 239 вакансий на hh.ru аналитиков данных. Вот такие рекомендации джуниорам можно дать на основе исследования:

Советы для джуниоров

• В первую очередь учите SQL и Excel. Только за их знание вас могут нанять — хотя выбор вакансий будет довольно узким. 

• Освоив SQL с Excel и начав рассылать резюме, вы можете приступить к изучению Python и BI-систем (лучше начать с Power BI или Tableau) для построения дашбордов. Это сильно расширит количество подходящих вакансий.

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

• Развивайте аналитическое мышление и навык коммуникации.

• Повышайте свой грейд. Хотя бы до джуниора+. Для этого выполняйте пет-проекты, участвуйте в хакатонах и стажировках.

Советы для джуниоров+

• Сконцентрируйтесь на изучении Python — теперь он для вас важнее, чем Excel.

• Продолжайте развивать свои навыки в BI-системах и SQL. 

• Помните, что «мягкие» навыки для вас всё ещё важны.

• Начните изучать теорию по базам данных. Просто писать запросы уже недостаточно.

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

→ Посмотреть полное исследование

Всем привет! 

Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи. 

Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...". 
Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.

А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈
То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️

А раньше эта сказка мне казалась просто сказкой ... ☀️

Мы провели исследование  и выяснили, что курс «Управление командой разработки» подходит руководителей DevOps, QA, DS и аналитиков. Сейчас 12% покупателей курса — проджект-менеджеры, а 14% — тимлиды различных направлений.

Приоритеты менеджеров:

• Стать более технически подкованными, чтобы лучше понимать разработчиков;

• Частично или полностью заменить тимлида, если в компании нет отдельной позиции;

• Стать увереннее, объективно оценивать свои навыки;

• Научиться оценивать время на выполнение задач;

• Повысить авторитет среди разработчиков.

Приоритеты тимлидов DevOps, QA, DS и аналитиков:

• Лучше справляться с текущей ролью (нет цели начать руководить разработчиками);

• Улучшить навыки управления и систематизировать знания;

• Проработать слабые стороны;

• Убедиться в своём подходе, не опираться на интуитивные решения. 

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

• Управлять ресурсами и временем. Делегировать, планировать, находить баланс;

• Нанимать, адаптировать и мотивировать сотрудников, давать обратную связь;

• Ставить выполнение задач на поток, применять Scrum и Kanban;

• Проводить встречи результативно, находить подход ко всем в команде, взаимодействовать с заказчиками, решать конфликты.

Всем привет!

Попробую немного развить тему с законом Конвея из предыдущего поста. Я достаточно много раз за свою карьеру в разработке сталкивался с упоминанием данного закона. Уже не вспомню где конкретно, но у меня осталось стойкое впечатление, что отношение к нему было как к неизбежности, с которой нужно бороться. Способы борьбы можно вспомнить такие:

• корпоративные архитекторы, выравнивающие архитектурные шаблоны

• внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования

• техрадар как способ ограничить технологический стек

• единые практики найма и онбординга

• корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

ГАС Правосудие взломали. В Багдаде всё спокойно.

На моей практике возникла весьма интересная ситуация, связанная с тем, как дело в районном суде могут отдать нужному судье, а затем просто "потерять" из статистики и учёта в апелляции и кассации. И всё это связано с работой в АИС, ГАС или тем, что объединено под названием ГАС "Правосудие".

И так. Решив всё же описать ситуацию, я с огромной долей вероятности предполагаю, что подобные технические манипуляции с ГАС Правосудие, АМИРС, МРД и прочими многочисленными и таинственными составляющими электронного правосудия в России, позволяют успешно "решать вопросы" по заказу (по звонку или как там ещё было когда-то принято).

Связано это с уникальным идентификатором дела (УИД), который был введён в 2019 для привязки всех производств к единому номеру, с целью контроля и учёта.

В районном суде делу в 2021-м году был присвоен "УИД 0". Дело с номером "2-...". Модулем автораспределения (МРД) не пользовались. Протокола распределения нет. Клиент не заметил этого, прошёл апелляцию и кассацию (безуспешно и очень удивительно, что там не заметили нарушение).

Но! Самое интересное. В ВС РФ (Верховный Суд Российской Федерации) жалобе присвоили УИД от другого дела, не имеющий к нашему делу никакого отношения. Как?

Видимо это нормальная практика, когда Верховный Суд РФ, не имея возможности просто проставить "0" в системе в поле УИД, присваивает производству какой-то левый номер?

Сталкивались ли вы с такими казусами, и есть ли в таких трюках состав 274 УК РФ?

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

P.S. Интересно и то, что в 1967 году разработка как отрасль уже достигла уровня, позволяющего формулировать определенные принципы.

Никогда такого не было и вот опять (с) Черномырдин

Олды из 90-х помнят про чеченские авизо в системе Госбанка, когда благодаря концепции безопасности "Джентельменам верят на слово", в Чечню уходили караваны денег.

История повторяется ...

https://www.rbc.ru/politics/24/05/2024/665086f09a79473be1adc6dd?from=from_main_2

 Через единую систему электронного документооборота ПФР были сформированы реестры поручений с внесенными в них «заведомо ложными сведениями» о начислении разовых выплат до 2020 года.

Уверен - "систему электронного документооборота ПФР" обладает всеми справками по безопасности, которые можно и нужно получить для госконтракта. Я сам сталкивался с ТЗ от заказчика, когда "начальника" в Мухосранске обладает полной возможностью рулить всей системой ...

ха-ха-ха неудачники