В докладе Анны приведено огромное количество практической информации и реальных примеров, помогающих Аналитику работать с требованиями к ИБ, быстро распознавать будущие проблемы, приведены удачные примеры их решения. Алгоритмы действий и чеклисты, представленные в докладе, помогут вам не только пройти ревью в ИБ, но и снизить бизнес-риски связанные с защитой данных в системе. А за качественную проработку требований по советам из доклада вам скажут отдельное спасибо не только ваши PM и специалисты по ИБ, но и PO. А значит вы снова самый востребованный и знающий специалист. Регистрация на AM7 для физических лиц
Региcтрация на AM7 для юридических лиц

Публикуем точный тайминг мероприятия, чтобы вы смогли спланировать, на какие доклады точно хотите попасть. После каждого доклада будет 10-15 минут на сессию вопросов/ответов со спикером.

10 ноября, время по Москве.
10:00 Открытие. Максим Хлопонин, организатор конференции.

10:05 Иннокентий Бодров - Lead Analyst STENN
Почему и без ТЗ результат будет

10:50 Михаил Максимов - Product owner, business analyst SberTECH
Как подойти к проработке нефункциональных требований, если ты аналитик

11:35 Анна Вязанкина - лидер экспертизы по бизнес- и системному анализу Иннотех
Актуальные требования к ИБ при разработке банковских систем

12:40 Сергей Нужненко - системный архитектор, Agile coach, руководитель экспертной группы обновления профстандарта «Системный аналитик» редакции 2022 года
Чем полезен профстандарт СА

13:25 - 14:00 Перерыв

14:00 Валерий Разномазов - ведущий аналитик, дтн, доцент кафедры автоматизации и бизнес-процессов в ЮФУ, Совкомбанк Технологии
Онтологические подходы для аналитики банковских ИТ-проектов

15:00 Ирина Матвеева - бизнес-коуч, фасилитатор, HR и CX эксперт, консультант по орг.развитию, Escalate
Как сохранить разум и работоспособность. Собираем «в кучу»: себя, команду, смежников

15:50 Наталья Крикун – лидер компетенции по системному анализу, АТБ (Азиатско-Тихоокеанский Банк)
Что делает аналитик на больших интеграционных проектах

16:45 Закрытие события.


Завтра всех ждем в прямом эфире!🔥
Просто в 10:00 переходите по вашей персональной ссылке полученной при покупке билета.

Если вы еще без билета: https://bit.ly/3De6rt6

Наткнулся на полезный пост. Сам читал далеко не все, так что и себе памятка!

Подборка книг по Системному мышлению 📖

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

Делимся подборкой лучших книг, которые помогут самостоятельно изучить системное мышление и приглашаем на наш тренинг Professional Systems Thinker.

Ссылки на сами книги 📚

Читаешь вот иногда статьи, вроде все по умному и коротко написано, а потом понимаешь, что это просто Вигерс в вольном изложении. В целом, вроде и ничего страшного, всем наши материалы это так или иначе компиляция ранее изученного, приправленная нашим мнением и опытом. Но все же хочется чуть больше мнения и чуть меньше Вигерса:) https://habr.com/ru/post/697066/

Читаешь вот такие статьи и удивляешься, чему людей учат в London Business School... Говорить, что мы сделали коробочный продукт и теперь у нас продуктовый продукт это просто смешно. Хорошо хоть про исследования рынка упомянули. Но забывают про самое главное, что продуктовый подход это в первую очередь про быструю проверку гипотез, постоянное изучение своих клиентов и накопление знаний в принципе для принятия решений. В целом, когда видите, что вам пытаются вот такое продать под видом продуктового подхода - не верьте
https://rb.ru/opinion/project-to-product/

Уже не первый раз вижу публикации данного автора и вынужден рекомендовать относиться к ним с определенной долей скепсиса.
Во-первых, само описание Use Case как средства моделирования и проектирования в корне не верно, Use Case это средство фиксации требований к взаимодействию. Тот же Коберн предостерегал от детального описания интерфейсов и привнесения деталей реализации в интерфейс. Тем самым вы сильно сужаете возможности реализации для команды разработки.
Во-вторых, фраза "Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс," сразу говорит о том, что автор не понимает принципиальных различий бизнес-процесса, как последовательности взаимодействия нескольких акторов, и Use Case как средства описания взаимодействия конкретного актора с системой.
В-третьих, указание на то, что пользователь должен именно нажимать кнопку, а не просто добавить товар в корзину сразу лишает ваш документ гибкости и делает хрупким.
В целом подобный подход может быть оправдан только в том случае, если у вас есть практически неограниченный ресурс даже не аналитика, а техписа. Но подобное описание на мой вкус избыточно.
Ну и заказчикам компании, в блоге которой это публикуется стоит задуматься о том, на что тратятся бюджеты их проектов.
https://habr.com/ru/post/699522/
#badsmell #article

​Cравнение наиболее популярных технологии интеграции ИС (gRPC, SOAP, REST, GraphQL, Apache Kafka и Rabbit MQ)

Привет всем! Крутая статья про Agile и почему по нему никто не работает. Не со всем согласен, но основная мысль, что Agile внедряют менеджеры (привет SAFe), а не разработчики, наводит на определенные, немного грустные мысли. В первую очередь о том, что далеко не всем разработчиками это надо (они хотят кодить по ТЗ, а не головой думать, это не только про разработчиков, это многим людям свойственно). И как следствие все внедрение Agile без правильного персонала превращается в Cargo культ и танцы с бубнами, что полезно не бывает никогда. https://telegra.ph/U-vas-ne-Agile-10-27

Если вы только начинаете работать с визуализацией данных, то эта статья для вас! Многие решения, описанные в ней, как, например, моноширинный шрифт лично я усвоил на своих ошибках и страданиях. А тут все базовые советы по полочкам. И про цифры и про текст и про фон и шум. https://habr.com/ru/company/agima/blog/692032/

И еще одна статья про интеграцию. Скорее с точки зрения организационного обеспечения этой самой интеграции и правильного выстраивания взаимодействия с заказчиком. Все пункты кажутся очевидными, но на старте своей карьеры я бы много отдал за подобный чек-лист, не пришлось бы страдать на проектах.
https://habr.com/ru/company/unidata/blog/696102/

И завершим вечер базовых знаний статьей про архитектурные паттерны. От общей БД до брокера сообщений в формате "для чайников". Коротко и по делу. https://habr.com/ru/company/ruvds/blog/699648/

Продолжаю делиться своими выступлениями. На этот раз с недавнего аналитического марафона (10.11.22) - про то, почему можно и нужно работать без ТЗ https://youtu.be/16FCcIETp-c
#myvideo

Раз у же пошел такой разговор, ретроспективно выложу и свое выступление с Analyst Days 13 про поведение в кризисных ситуациях. https://youtu.be/Zx-H3UEZSb8
#myvideo

Подборка книг для Владельца Продукта 📖

Ищите, что прочитать по продуктовке? Тогда для вас поборка книг для Владельцев продуктов от scrum.org

Ссылки на сами книги 📚
#книги

Если вам интересно, как устроен WhatsApp под капотом - то вот вам статейка, правда на англицком https://medium.com/interviewnoodle/whatsapp-system-architecture-8df0250d572f
#article

Интересный обзор на книгу “Web Scalability for Startup Engineers” by Artur Ejsmont. Добавил себе в вишлист
https://medium.com/@olgamitroshyna/software-architecture-i-wish-i-had-known-about-this-earlier-4df43eae57db

Сейчас будет сложно. Краткий обзор на Социократию 3.0 от Макса Цепкова. Ничего не понятно, но очень интересно. Пойду читать полный гайд) https://telegra.ph/Sociokratiya--istochnik-praktik-po-organizacii-IT-proektov-07-27

Внезапно достаточно толковая статья про гибкие методологии (ну или хотя бы вариации на тему) от представителей банковского сектора, обычно считающегося наиболее консервативным. Ребята из Ак Барс банка рассказывают про использование User Story Mapping и чем он лучше классических ТЗ. Конечно не обошлось без гротеска про то, что аналитик в гордом одиночестве пишет ТЗ и ни с кем не общается, но от этого концептуально описание вышло не хуже. Так что рекомендую https://habr.com/ru/company/akbarsdigital/blog/699950/

Почему я в предыдущем посте писал внезапно про банки? Потому что сегодня был на открытом уроке у конкурентов: https://education.dhabits.ru/systems_analyst_course. Почему пошел туда? Потому что ребята программу наполовину списали с моего курса. Понимаю, что это можно считать признаком популярности моего курса (на текущем запуске, кстати, 100 человек в группе, что объективно много, поэтому запускаться будем теперь чаще). Но все же настолько в наглую копировать формулировки это перебор.
Но про сам открытый урок:
Лектору из зеленого банка еще надо очень много работать как над своей манерой вести занятия (обычно приходит с опытом), так и работе с аудиторией (первый блок вопросов только через час, все вопросы уже контекст потеряли). Ну и материалы были достаточно скучные.
Про что рассказывал спикер? Я так и не понял, пытался что то про классическое оформление документации (упоминал ГОСТы и BRD), но признался, что не знает что такое SRS. Потом было про какую то мешанину из ТЗ, задач, US внутри задач, Acceptance criteria, которые упорно назывались DoD, но при этом детальное описание всего и вся с согласованием с кучей стейкхолдеров. Если это и есть знаменитый сберджайл, то я разочарован. Взяты далеко не лучшие черты обоих подходов. А, и конечно, все это исключительно оформляется в Конфлюенс, который в РФ как бы уже не очень актуален.
Целевая аудитория не очень понятна. Ребятам с опытом 2-3 года будет скучно, а новичкам не понятно, особенно учитывая отсутствие какой либо теоретической базы, как в материалах, так, похоже и лектора, который Use Caseом упорно называл диаграмму Use Case, при этом даже не особо оговорившись, что основной цимус далеко не в диаграмме. В общем мой вердикт - моему курсу это не конкуренты. + дать за 6 недель то, что мы в Отус еле впихнули в 6 месяцев - просто не реально, будет либо по верхам, либо с пробелами.