22 июля с 14:30 до 16:00 мы проводим мозговой штурм. Будем искать "Быстрые выигрыши" — дешёвые, но выгодные для компании, изменения в области Управления Знаниями.

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

Ждём всех, кому не безразлична тема управления знаниями и кто хочет изменить что-то к лучшему в своей компании. Уверены, что идеи, которые мы сформулируем, помогут вам в вашей работе.

Запись обязательна: https://tsupko-tech.timepad.ru/event/1357069/

Про поиск ограниченных контекстов в DDD

Когда мы впервые пытались использовать DDD на проекте, мы очень много заморачивались над выделением контекстов. Мучали бизнес бесконечными встречами, развешивали рулоны бумаги по стенам, клеили стикеры, играли в event storming и вот это все. После просмотра карты контекстов не покидало ощущение чего-то явно наигранного и искусственного. «Не верю!» - вопил внутренний Станиславский. После я долго ходил по сети, конференциям в безуспешных поисках инструментов и конкретных подходов для выявления контекстов.

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

Похоже, таков путь.

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

Solution-аналитика - это что-то новое, или жизнь проходит мимо? Еще и community-driven формат обещают, будем ждатьс

https://itanalyst.online/?utm_source=community&utm_campaign=analystru

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


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

Кажется, автор пропустил важный вопрос: нужна ли нам документация, описывающая состояние системы AS IS после завершения проекта? А через 2-3 года? Если да, то что заменит нам спеку?
С другой стороны, написание таких доков можно отдать техническому писателю. Не исключено, что получится лучше и дешевле.

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

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

Избыточные требования
Лучше набрать заведомо больше требований, чем мы можем или планируем реализовать. Таким образом мы стремимся достичь полноты требований. Чем больше требований собрали, тем выше вероятность, что не пропустили важное/необходимое.

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

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

Выявление конфликтов
И докину вариант от себя.
Cпецификацию можно использовать как способ выявить противоречия между стейкхолдерами. Либо, если уже знаю о существовании противоречий, столкнуть их напрямую.
Сценарий прост:
1. Фиксируем версию одного из оппонентов
2. Выкладываем на общее ревью с просьбой прокомментировать.
3. Запасаемся попкорном

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

https://youtu.be/zVtTrXcHH2M

Продолжим тему конференций и митапов.

Через неделю, 22 сентября сообщество системных архитекторов Райффайзенбанка приглашает на открытый онлайн-митап.

Константин Густов (@Kesteem) расскажет о своем опыте применения Domain-Driven Design, какие хорошие практики они используют, какие ошибки допускали и какие выводы из этого сделали.

Александр Лукашин (@kerhoff) расскажет о практиках, которые они используют для старта разработки в новых предметных областях. Подробно остановится на том, как могут помочь принципы Domain-Driven Design.

Подробное описание и регистрация https://raiffeisen-events.timepad.ru/event/1417351/

#интеграция #конференция

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

Service Design Patterns
http://www.servicedesignpatterns.com
Начинать знакомиться с подходами к интеграции, имхо, лучше с нее. Книга написана больше для разработчика, и 50-70% аналитику можно пропустить. Зато в ней можно найти практически все базовые понятия: синхронность, асинхронность, идемпотентность и т.д.
Особенно удобно, что все они хорошо проиллюстрированы, и начинать можно просто с пролистывания картиной. Русского перевода, на сколько я знаю, нет.

Enterprise Integration Patterns
https://www.enterpriseintegrationpatterns.com
Обычно на вопрос: “Что почитать по интеграции” - рекомендуют именно это. В большей степени посвящена месседжингу, и рассматривает более высокоуровневые шаблоны, чем предыдущий лот. Написана в формате справочника, поэтому лучше не читать ее сразу от корки до корки, а просмотреть по диагонали.

Денис Котов. Что и как спросить у бизнеса, чтобы проработать ИТ-решение.

Еще одна ссыль по следам Точки Сборки. Вспоминал в контексте вопроса про выделение сервисов с относительно чистого листа с помощью тактических шаблонов DDD. Здесь больше об общем подходе, чем о проектировании конкретных взаимодействий и API. Важно, что Денис рассказывает о практическом использовании шаблонов, а не об абстрактных идеях.

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

https://youtu.be/NBo0qtMKwWo?t=3933

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

⁃ Там тестирование скоро, хочешь молоток?
⁃ Не, не нужен

⁃ Релиз через два спринта, у тебя точно есть все инструменты?
⁃ Да, все хорошо

И вот, в день выхода он прибегает с выпученными глазами:
⁃ Гвозди! Стена! Бить!

#коммуникации #мышление
Минутка снобизма и брюзжания. Мало, что так усложняет и замедляет рабочие коммуникации, как мессенджеры.

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

1. Нужно описать техническую/архитектурную проблему, которая влияет на ход всего проекта.
2. Проблема имеет несколько решений, у каждого свои плюсы и минусы.
3. Бизнес ничего не знает о твоей технике, поэтому нужно описать все на человеко-понятном языке.
4. Описание должно быть кратким. Длинный текст проигнорируют, либо не дочитают.
5. Если что-то будет непонятно, то тебе зададут вопрос. В ответном письме. Напоминаю, каждая итерация - один-два дня.

Прелесть в том, что 2/3 написанных писем я никогда не отправил. Потому что с такими жесткими ограничениями мысли начинают очень хорошо упорядочиваться по мере генерации текста. На эту тему есть много техник про мышление письмом и около того.

Так что первое, что забирают мессенджеры - это привычку думать и структурировать мысли. Возможно, и способность.

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

Групповые чатики - это вообще мрак. В начале удаленки они достали на столько, что я даже сделал в компании доклад “Как выбесить коллег в переписке”.

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

Пишите письма, мелким почерком.

#API #интеграция #архитектура
Если сейчас интеграция - один из топовых баззвордов среди аналитиков, то пару лет назад это были микросервисы. Теперь можно совместить приятное с полезным:

https://microservice-api-patterns.org

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

Аналитикам можно смело читать все подряд, особенно разделы Structure и Quality.
Очень понравились ссылки на публичные примеры использования - можно поковырять реальные сервисы

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

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

https://podlodka.io/166

#инструменты

Подкинули ссылку на Plant UML редактор с подсветкой синтаксиса, удобненько: https://plantuml-editor.kkeisuke.com

Порой думаю, что живу в мире, где уже Все As Code. Мы в компании используем Plant UML для отрисовки UML-диаграмм, в основном это диаграммы последовательности и диаграммы состояний, иногда майндмапы. Он умеет намного больше, но не особо не нужно как-то.

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

Если кто-то не знаком: https://plantuml.com

#интеграция #API
Наглядная и веселая статейка о том, как “правильно” исспользовать http, чтобы делать “правильные” RESTful сервисы

https://habr.com/ru/company/yandex/blog/265569/

https://habr.com/ru/post/526336/

Думаю, эта статья прошла уже по всем каналам аналитиков, но проигнорировать ее я не могу - слишком сильно резонирует с моими мыслями и опытом. Я уже приводил пример, как мышление письмом помогает решать вопросы и сильно упрощает коммуникации с коллегами https://t.me/another_sa/37

Здесь же автор распространяет практику на более интересные рабочие ситуации. В главе про “письменные” встречи я вообще рыдал от восторга.

С переходом на удаленку даже самый ленивый успел провести какой-нибудь онлайн митап или где-нибудь выступить. А если не успел - то самое время. Имхо, дебютировать онлайн намного проще, чем вживую. Да, нет контакта с аудиторией, не видна ее реакция, но для первого раза это огромный плюс - ничто не отвлекает и не сбивает с мысли. Плюс, нет подсознательного страха перед ЖИВЫМИ ЛЮДЬМИ.

Эти две статьи мне нравятся за то, что относятся к выступлению и подготовке очень просто, не нагнетая. Когда-то они подтолкнули меня к первому внутреннему выступлению в компании.
https://habr.com/ru/post/289144/
https://habr.com/ru/post/289742/

А эту ссылку я уже давал, но повторюсь. Здесь автор хорошо ответил на: “Зачем я буду что-то рассказывать, что все уже знают?” Не знают. Не все. Расскажите.
https://habr.com/ru/post/501854/

#реклама #интеграция #API
Осторожно, реклама!

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

https://bit.ly/348n6we

#конференции #интеграция
На вчерашнем Analyst Marathon 3 был огненный доклад Валерия Разномазова, как с помощью стат методов получить стандартизированную модель бизнес-объектов в большой компании, где у нас 100500 систем с разными моделями. И как сократить за счет этого интеграцию и разработку преобразований. Особо проникся этим подходом как человек, пережевавший тонну маппингов на банковских проектах.

Видео будет только для участников, но есть статья от автора:
https://habr.com/ru/company/accenture/blog/523414/

Что ребята сделали:
1. Собрали описания всех моделей в банке.
2. Из каждого объекта извлекли текстовые человеко-читаемые описания каждого атрибута.
3. Векторизовали все такие описания, получив набор векторов в 33-мерном пространстве. Если по-русски: посчитали количество всех букв в описаниях и получили 33-числа для каждого.
4. Дальше посчитали расстояния между векторами и получили набор кластеров.
5. На основе этих кластеров разработали “идеальные” модели для всех объектов.
6. Скорректировали ручками.

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

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

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

https://youtu.be/HjiE3n4_6zI

#agile #scrum #процессы

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

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

А теперь посмотрим, что зачастую называют скрамом в нашей уютной it-шечке:
1. Живем двухнедельными спринтами
2. Выпускаем новые фичи для пользователей раз в 2-3-6 месяцев
3. В начале работы над крупной фичей оцениваем (а лучше сразу коммитимся на них) сроки, когда она будет готова

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

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

Почему так происходит?
1. Обычный карго-культ, когда берем внешние атрибуты методологии, не вникая в ее суть.
2. Последствия быстрого роста. Когда были маленькими, все получалось, но на фоне взрывного роста процессы как-то поломались. Даже заметить не успели.
3. Скрам в компании - это не более, чем маркетинг и следование трендам, чтобы завлекать сотрудников. Тогда вопросов нет. Только не забудьте про смузи.
4. Самый очевидный вариант, который я не увидел.