Что archimate грядущий нам готовит... #archi #archimate

https://habr.com/ru/posts/932602/

Про модель Кано

В бытность свою продуктологом я узнал, что есть такая прикольная штука - модель Кано. Японский профессор Нориаки Кано придумал её в 80-х годах для анализа лояльности и удовлетворенности клиентов продуктом. Он обнаружил, что не все фичи/характеристики одинаково полезны, и что с точки зрения влияния на лояльность клиентов их можно разложить на пять кучек.

Сейчас меня интересуют три из них:
- 🎉 Привлекательные (Attractive) — неожиданные или дополнительные функции, которые вызывают восторг при наличии, но отсутствие их не вызывает неудовольствия.
- 📈 Одномерные (One-Dimensional) — характеристики, которые прямо влияют на степень удовлетворённости: чем лучше, тем выше удовлетворение.
- 🧐 Обязательные (Must-be) — базовые характеристики, без которых продукт не приемлем, но их наличие воспринимается как должное и не повышает удовлетворённость.

Замечено, что есть тенденция постепенного переползания функций из привлекательной кучки в обязательные. Так, когда-то давным-давно наличие камеры в телефоне было дополнительной привлекательной фишкой, а сейчас телефон без камеры не воспринимается в принципе. Другой пример - группировка писем в цепочки, впервые сделанная в GMail, теперь является базовой функцией любого email-клиента. Эффект чисто психологический, что бы удивительное ни было предложено, клиенты к этому привыкают и постепенно начинают воспринимать как само собой разумеющееся.

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

Например, когда идет речь о разработке простенького микросервиса в составе большого решения, который принимает команды, скажем, по REST, сохраняет состояние в своей базенке и отправляет события в кафку, я почему-то ожидаю, что без дополнительных слов и указаний этот сервис будет:
- Реализован в концепции stateless, т.е. у него не будет своего состояния и его можно масштабировать без дополнительных приседаний
- Иметь базовый набор метрик (счетчики количества и длительности обработки запросов, обращений к БД, потребления CPU и памяти)
- Сохранять структурированные логи с атрибутом трассировки, позволяющим связать записи, относящиеся к одному запросу
- Реализовывать какие-то базовые механики устойчивости к сетевым сбоям, например Retry с переменным временем ожидания при обращениях по сети к кафке или СУБД.

Т.е. этот набор характеристик в моём восприятии уже относится к обязательным. А вот реализованный Circuit Breaker в этот набор не входит, я его воспринимаю как что-то среднее между привлекательными и одномерными характеристиками - хорошо (но не удивительно) если оно есть, но не так страшно, если его нет.

А у вас какие ожидания перешли из области удивительного в пространство обязательного?

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

http://agilemindset.ru/item-estimation/

А Саше спасибо за ревью статьи 🙂

Скажу честно, читать и изучать некогда. Но размах, масштаб и намерения Дениса вызывают восхищение и уважение.

Собрали с новейшей 5.1 Про
свежую нейрокнигу:

Проектирование баз данных для бизнес-аналитиков

Кому
- Бизнес-аналитикам, которые:
- уже пишут требования к данным, отчётам, интеграциям;
- регулярно страдают от «не так поняли», «не то посчиталось», «надо было ещё один разрез».
- Руководителям отделов бизнес-анализа, которым нужно «подтянуть» команду в понимании данных, но не делать из них админов/архитекторов.

После прочтения аналитик перестаёт говорить «ну вы там как-нибудь в базе сделайте», и начинает:
- формулировать требования в терминах сущностей, связей, событий и состояний;
- понимать, *почему* разработчики предлагают такую структуру данных;
- предвидеть типовые грабли в отчётности и интеграциях.

Книга не про то, «как писать SQL», а *«как думать о данных так, чтобы базы данных и отчёты потом получались адекватные»*.

---

Часть I. Как бизнес превращается в данные

1. Зачем бизнес-аналитику понимать базы данных
2. От бизнес-языка к сущностям и событиям
3. Концептуальная модель для бизнес-аналитика

Часть II. Логическая модель и основы реляционного мира

4. Реляционная модель простыми словами
5. Нормализация для тех, кто не хочет знать слово «нормализация»
6. Справочники, классификаторы, иерархии

Часть III. Типовые паттерны данных бизнес-систем

7. Транзакции, документы, движения
8. Состояния и жизненные циклы
9. Баланс, срезы, накопительные показатели

Часть IV. Проектирование для аналитики и отчётности

10. От требований к отчёту к структуре данных
11. Звёздочки, снежинки и хранилища
12. Качество данных: как аналитик может его не убить

Часть V. Как писать требования, которые не стыдно дать архитектору

13. Документы, которые помогают проектировать базы данных
14. Шаблоны описания данных для требований
15. Антипаттерны в требованиях к данным

Часть VI. Кейсы: от описания бизнеса до схемы БД

16. Кейс 1: Интернет-магазин
17. Кейс 2: Подписочный сервис (SaaS)
18. Кейс 3: Операционный учёт + управленческая отчётность
19. Типовые грабли и как их обходить

Приложения

А. Чек-листы для BA
Б. Мини-справочник терминов для BA
В. Рекомендуемая литература

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

О декомпозиции через Ограниченные Контексты

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

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

Давайте разбираться.

Традиционная «декомпозиция системы» в инженерном понимании почти всегда подразумевает:
1. есть единая целостная модель системы
2. мы делим ее на части
3. части в совокупности «покрывают» целое (часто еще и без пересечений или с минимальными пересечениями)

В таком понимании:
- есть единое целое,
- есть разбиение этого целого

Внезапно, Bounded Context так не работает. И переход от монолита к микросервисам так не работает :)

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

То есть мы не делим модель на куски, мы конструируем несколько моделей, которые опираются на:
- свой лексикон (Ubiq. Language)
- свои инварианты
- свой контекст применения

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

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

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

Друзья! Поздравляю всех присутствующих с наступающим новым годом!

Желаю всем в новом году здоровья, счастья, интересных встреч и удивительных событий. Обязательно научиться чему-нибудь новому и забыть что-нибудь старое 😊.

С Новым Годом и до новых встреч!
🎄🎄🎄

Я пишу и учу про требования не как про «документацию», а как про инструмент управления рисками.

Если требования сделаны правильно, вы можете:
— вовремя сказать go / no-go
— выбрать класс решения или вендора по делу (а не по маркетингу)
— удержать scope
— снизить риск «строим не то» и ROI<0

Что делаем за 2 недели (20 часов):
— соберём требования ровно той глубины, которая нужна вашему проекту (не больше и не меньше);
— пройдём 3 итерации: от целей/границ до критериев приёмки;
— отдельно покажу, как применять GenAI: генерация + проверки полноты/согласованности.

Февральский поток курса:
— Zoom
— 2 недели, 20 часов
— будни утро 9:00–11:00
— старт 09.02 пнд
— только 6 мест (потому что будет разбор/фидбек)

Стоимость: 60 000 ₽

———

Кому подойдёт:
— системным/бизнес-аналитикам, архитекторам, продактам и руководителям, кто отвечает за результат ИС;
— если вы сейчас выбираете решение / запускаете проект / хотите остановить «плохой» проект вовремя.

Кому НЕ подойдёт:
— если вам нужен «шаблон ТЗ» без привязки к решениям и рискам;
— если не можете участвовать в 9–11.

———

Анкета предзаписи откроется 23.01 (на 48 часов).

Если хотите — можете уже сейчас написать мне: @beskov

Последние пару недель активно использую OpenSpec при работе с курсором и вот что я могу сказать.

Если вы продукт менеджер:
- Без доступа к PNL
- Без доступа к метрикам
- Не понимаете как работает бизнес
- Не находитесь внутри рынка, для которого делаете продукт
- Не понимаете технических аспектов разработки

У меня для вас плохие новости.

Аналогично, если вы разработчик:
- Не умеющий задавать вопросы
- Не понимаете бизнес
- Не умеете общаться
- Читаете только Jira и Кабанчика
- Считаете, что тестировать должны куа, а деплоить ДевОпсы

То у меня для вас тоже плохие новости.

Понравилось