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

📕 Илья  Отькало.  «Автоматизация бизнес-процессов», 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 года.

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

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

«Архитектура программного обеспечения» — обновлённый курс Яндекс Практикума

В рамках курса мы фокусируемся на тех 20% архитектурных задач, проблем и инструментов, которые встречаются в 80% случаев на практике. Это позволяет сделать курс достаточно коротким для такой области, но при этом отвечающим главным запросам студентов.

Основное про курс:

• Много практики: по окончанию курса вы сможете добавить в портфолио 11 проектов.

• Качественная обратная связь: все работы будут проверять специалисты с опытом создания распределённой и высоконагруженной архитектуры.

• Диплом о профессиональной переподготовке или сертификат по окончанию обучения.

Вы научитесь:

• Проектировать и реализовывать микросервисные архитектуры, управлять ими.

• Применять паттерны масштабируемости, устойчивости и взаимодействия между сервисами.

• Развёртывать приложения в облачных средах с помощью Kubernetes, Docker и Terraform, управлять ими.

• Выстраивать стратегии миграции в облако и управлять большими объёмами данных.

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

• Создавать решения для мониторинга с помощью Prometheus и Grafana.

• Применять лучшие практики в области безопасности, включая управление идентификацией и доступом (IAM).

• Интегрировать функции безопасности в дизайн и развёртывание приложений.

• Общаться с бизнесом на одном языке и помогать выбирать оптимальную технологическую стратегию.

Ближайший старт обучения — 27 июня и 25 июля.

Узнать о курсе подробнее и начать учиться бесплатно →

Story Map может стать более углубленной и проработанной, если добавить форматы "Jobs Story", "System Story", "Изменение", "Описание изобретения".

Jobs Story
Когда <ситуация, контекст>, Я хочу <мотивация>, так что <ожидаемый результат>
Пример:
Когда сбоят системы отправки, выгружаю уведомление в формате XLS, чтобы отправить клиенту и регулятору вовремя

System Story
Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением:
<Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>).
Пример:
Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.

Изменение
<вместо того, чтобы>, старый способ действия, <новый способ действия>
Пример:
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить

Описание изобретения
<Полезное действие/ Отрицание нежелательного эффекта> в <контекст> за счёт <принцип работы>
Пример:
Быстрее нахожу какой статус выбрать в колонке-фильтре статусов за счёт вывода их в идеальном хронологической последовательности

Подсмотрено тут:
https://medium.com/serious-scrum/unheralded-alternatives-to-user-stories-f1d787fc2278
https://speakerdeck.com/ashapiro/mastier-klass-po-user-story-mapping?slide=17

Приходит потенциальный клиент к разработчику…

— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.

И клиент идёт к проектировщику интерфейсов. Например, ко мне.

— Мне бы сайт спроектировать! Можете сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.

Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Вот вам видеоролик, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.

О дуализме качественных и количественных исследований в UX

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

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

Об этом можно почитать у Джеффа Соро, известного аналитика: «Вам не нужно думать об этом как о ситуации или-или. Всегда можно использовать микс методов».

Он предлагает 3 различных дизайна исследований, при которых можно комбинировать методологии:

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

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

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

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

P. S. Это часть статьи Кати Патрикеевой о мифах в UX — полную версию читайте тут.

Короткий анонс про One Day Offer для системных аналитиков

? Альфа-Банк приглашает системных аналитиков на One Day Offer 13 апреля. Все этапы собеседованияя и возможный оффер за один день. 

Оставляем сразу ссылку на форму регистрации.

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

Ожидания от кандидатов:

• Опыт работы системным аналитиком от 2 лет.

• Навык писать базовые SQL-запросы.

• Понимание принципов межсистемной интеграции.

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

Формат работы — на выбор: полная удалёнка, гибрид или офис в Москве, Санкт-Петербурге или Екатеринбурге с гибким графиком.

⏰ One Day Offer Альфа-Банка пройдёт в онлайн-формате 13 апреля. Подавайте заявку до 11 апреля, чтобы принять участие в мини-игре с призами и получить приглашение на собеседование.

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Шаблон декомпозиции Model-View-Presenter

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

// Presenter
class User_preview {
	user: User
	card = new Card({
		image: ()=> this.user.avatar,
		message: ()=> this.user.nickname,
		color: ()=> this.user.skin.color,
		click: ()=> this.skin_change(),
	})
	skin_change() {
		this.user.skin = Skin.random()
	}
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
	<img src={ image } />
	<p>{ message }</p>
</div>

// Model
class User extends Model {
	avatar: string
	nickname: string
	skin: Skin
}

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.