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

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

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

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

А что от нас?

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

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

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

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

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

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

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

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

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

Ольга Матушевич, наставница на курсе «Аналитик данных» в Практикуме проанализировала 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
}

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

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

Уверен чтение будет интересно и полезно всем, кто сталкивается с необходимостью заниматься документированием проекта, библиотеки, фреймворка.

There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.

They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation - often immensely.

https://documentation.divio.com

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

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

// Controller
class Users_resource {
	GET() {
		return User.all.map( user_brief )
	}
}

// View
function user_brief( user: User ) {
	return {
		id: user.guid,
		name: user.passport.name_full,
	}
}

// Model
class User {
	
	static all = [] as User[]
	
	guid: GUID
	passports: Passport[]
	resumes: Resume[]
	
	get passport() {
		return this.passports[0]
	}
	
}

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

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

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

// View
<li class="User_card" model="User_card_model">
	<img src={ image } />
	<p>{ message }</p>
</li>

// ViewModel
class User_card_model {
	user = User.current
	get image() {
		return this.user.avatar
	}
	get message() {
		return this.user.nickname
	}
}

// Model
class User {
	avatar: string
	nickname: string
	static current = new User
}

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

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

Код работы с моделями пишется прямо в отображении.

// View
function Task_list() {
	return <ul>{
		Task.list.map( task =>
			<li><Task_row {task} /></li>
		)
	}</ul>
}

// Model
class Task {
	static list = [] as Task[]
}

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

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

Модель знает как себя по разному представлять.

class User { // Model
	
	_id: bigint
	_nickname: string
	
	toString() { // View
		return 'user=' + this._id
	}
	
	toJSON() { // View
		return {
			id: String( this._id ),
			name: this._nickname,
		}
	}
	
}

✅ Удобно из модели получать любые отображения.
❌ Добавление нового отображения требует изменения модели.
❌ Отображение полностью определяется одной основной моделью.
❌ Загрузка модели вытягивает по зависимостям и все её отображения.
❌ Двух слоёв слишком мало на больших масштабах.