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

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

Хорошая новость — мы все разные. И хорошо известное одним будет новостью для других.

Важнее не то, о чем я скажу слушателям, а есть ли в сказанном важное лично для меня. Выступления, лишенные смысла для выступающего, тоскливы и унылы.”

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

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

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

https://youtu.be/mK5NLd6xb_Q?t=3495

Душевная история из недр Райфа о том, как и о чем аналитику разговаривать с людьми.
https://www.youtube.com/watch?v=sJP13audmBk

Пара мыслей из доклада. Но лучше посмотреть целиком - Анна приятно рассказывает.

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

Не бойся быть идиотом.
Очень часто аналитик боится показать нехватку знаний в вопросах бизнеса или техники. Самый простой способ лечения - с самого начала заявить о своей полной некомпетентности, и смело задавать самые глупые вопросы. Почти наверняка к вам отнесутся с пониманием. Как минимум, бизнес - ты ж технарь. Как минимум, разработка - ты ж аналитик.

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

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

Наконец-то конфа не из Москвы-Петербурга. Теперь есть повод скататься в Екатеринбург:

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

https://kontur.ru/2020-conference-analyst-ekb

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

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

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

И пересказать ее всем подписантам и согласовантам!

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

Пассивный залог
Аналитик: “Список жертв волколаков должен формироваться после каждого полнолуния”

Старейшина: “Кто в нашей деревне составляет список погибших? Кого казнить, если списка не будет?”

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

Не-событие
1. Отец ликанов воззвал к мирозданию: “Что я такое?!”
2. Но оборотень не получил ответ.

Часто, когда рассматриваем конкретное событие А, конструкция NOT A является не противоположным событием, а некоторым множеством событий. Это нормально, если нам важно лишь то, что событие А не произошло. Но иногда мы работаем на более высоком уровне детализации. Тогда надежнее сразу рассматривать конкретные исходы, избегая не-событий

1. Отец ликанов воззвал к мирозданию: “Что я такое?!”
2. Но
2a. мироздание не ответило в течение ночи
2b. мироздание подало знак, окрасив луну в цвет крови. Жаль, что оборотни дальтоники
2c. мироздание грязно выругалось на неизвестном языке

Система не должна
Аналитик: “Охрана не должна пропускать в деревню незнакомцев с признаками ликантропии”

Старейшина: “А что она должна-то делать? Конвоировать к инквизитору? Сжечь на месте? Вежливо указать дорогу к соседям?”

При виде фразы “система НЕ должна”, возникает ощущение, что какой-то инфы нам не додали. Ибо интереснее узнать, что же система должна делать. Также это может быть признаком того, что мы имеем дело с бизнес-правилом, которое мы не зафиксировали в явном виде.

Пользователь может
Аналитик: “Крестьянин может принести жертву богам, чтобы красная луна не взошла”

Старейшина: “Что значит может? Есть вероятность, что принесет? Он способен это сделать? Боги предоставляют такую возможность?”

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

Необходимо реализовать
“Необходимо реализовать трансформацию ликана в волка при свете луны”

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

Терминология
В чем главная беда первого оборотня? Нет, не холодное безразличие вселенной. Обидели его аналитики - в документе постоянно называют разными именами: ликан, оборотень, волколак. Это привело к разночтениям и неправильной реализации. Поэтому и вышел дальтоником.

Звучит интересно

16 июля, в четверг вечером, Ксения Теселкина поделится своим опытом Разработки Требований к Международным Системам на примере трех проектов из разных сфер: социальные сети, фин.тех и корпоративные системы.
https://sysanschool.timepad.ru/event/1354359/

Посмотрим, что будет. Уже сегодня.

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

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

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

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