Рассказ про работу “интеграционного” аналитика. Хорошее введение в тему, если раньше не приходилось сталкиваться с задачами интеграции.

https://www.youtube.com/watch?v=yxo0Hk7bIPU&t=1s

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

https://www.youtube.com/watch?v=8YD0-fF7g9Y

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

Программа и презентации:
https://yadi.sk/d/mzj4OrkwOnNrdQ

Как подключиться:
1. Зал №1: https://zoom.us/j/319709967…
или на сайте zoom.us через идентификатор конференции: 319 709 967, пароль: 374704
2. Зал №2: https://zoom.us/j/432022821…
или через Идентификатор конференции Zoom.com: 432 022 821, Пароль: 813497

Грядет русскоязычная версия BABOK, обещают цену 50-60$. А в ближайшее время должна появиться электронная версия за меньшие деньги, для членов IIBA - бесплатно.

https://m.facebook.com/groups/136900003158362?view=permalink&id=1471979642983718&ref=m_notif&notif_t=group_activity

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

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/