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

https://habr.com/ru/company/hflabs/blog/431376/

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

https://youtu.be/89LCXdwuQCA

Должно быть интересно

[online] IT talk SPb «Анализ заинтересованных сторон при входе в новую команду». Анна Абрамова

Для кого и с кем мы собираемся работать — естественные вопросы при начале любого дела. В то же время, «инструменты анализа заинтересованных лиц» — звучит громоздко и кажется, что к этим инструментами стоит прибегать только когда проект уж очень большой и этого не избежать.
Бизнес-аналитик DataArt Анна Абрамова на примерах покажет, как при входе в новую команду можно применять два инструмента анализа заинтересованных лиц — матрицу ответственности RACI и реестр заинтересованных лиц. Обсудим, как с их помощью сделать ожидания от совместной работы более явными.

Анна Абрамова: более 17 лет в ИТ, 12 лет в роли аналитика. Тренер по бизнес- и системному анализу. Работала в предметных областях: медицина (радиология), телеком (управление фродом), интернет вещей (построение платформы управления сетью), платёжные системы и др. Организатор сообщества аналитиков Санкт-Петербурга. Создала профессиональную конференцию аналитиков Санкт-Петербурга — Точка сборки.

Подробнее:
https://www.dataart.ru/events/online-events/online-it-talk-spb-analiz-zainteresovannykh-storon-pri-vkhode-v-novuyu-komandu/

Участие - БЕСПЛАТНО!

Зарегистрироваться можно тут: https://dataart-spb.timepad.ru/event/1271844/

Ссылка на онлайн трансляцию: https://www.youtube.com/watch?v=c9yo_gqeZ2g&feature=youtu.be

15 апреля в 19 часов Татьяна Ефимова расскажет, как она разрабатывала требования к интеграциям и пользовательским взаимодействиям в проекте по автоматизации банка: https://sysanschool.timepad.ru/event/1293952/

#анализ
Анти-паттерны использования аналитиков на проектах, и когда они не такие уж анти.
https://youtu.be/QbWqK2jPXF8

Истории, до боли знакомые тем, кому приходилось поработать в кровавом энтерпрайзе:

- Техпис. Занимаешься разработкой и оформлением документации в промышленных масштабах, потому что: “А кто ж еще?”

- Секретарь-менеджер. Бессмертная классика, когда нет явной роли менеджера, или у него есть более важные дела.

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

- Разработчик в ворде/конфлюенсе. Тоже классика - разработку ведет аналитик, а разрабы работают переводчиками с русского в код.

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

От себя добавлю еще кейс:

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

Что реально мне нравится на удаленке - это онлайн встречи. Причем преимущества обеспечиваются именно техническими средствами.

Меньше балагана
Если говорить одновременно и пытаться перекричать друг-друга, то никто ничего не поймет, и нормальный срач устроить не получится. Всем невольно приходится соблюдать очередность и меньше перебивать коллег, иначе вас не услышат.

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

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

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

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

Главный вопрос - как сохранить эти плюшки после возвращения в офисы?

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

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

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

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

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 и вот это все. После просмотра карты контекстов не покидало ощущение чего-то явно наигранного и искусственного. «Не верю!» - вопил внутренний Станиславский. После я долго ходил по сети, конференциям в безуспешных поисках инструментов и конкретных подходов для выявления контекстов.

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

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

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