Достаточно абстрактная статься про архитектуру бизнес процессов. Самое ценное - список реферальных моделей процессов по аналогии с eTOM для телекома. https://www.comindware.ru/blog/business-process-architecture/?ysclid=lhgic0xnha885585381

Неплохой чек лист по проработке интеграции. https://habr.com/ru/articles/735332/
Из минусов: я бы не стал называть описание интеграционного сценария Use Case, все же это другая сущность.
Прорабатывать архитектуру интеграционного решения в виде С4 диаграммы для меня выглядит странно, а еще более странно не видеть в этом описании Sequence диаграммы, которая в большинстве случае заменит то, что называется Use Caseом.

Коллеги из школы системногг анализа написали хорошую базовую статью про User Story, DoR, DoD, Acceptance criteria. Если пока плавание в теме, то рекомендую почитать. https://systems.education/definition_of_done

Сегодня день статей в стиле Капитан очевидность (надеюсь, что я не один такой старый, что помню такого персонажа, сейчас вместо него пояснительная бригада). Так вот, ребята из симбирсофт собрали в одну статью всю базу про аутентификацию и идентификацию. Вроде все очевидно, а иметь такой чек лист под рукой полезно. https://habr.com/ru/companies/simbirsoft/articles/735608/

Прекрасное выступление от Кати Лысенко про то, что куда ни кинь, везде клин. https://youtu.be/iZx4HCqEV-o
Вроде думаешь, запускаешь, а потом или бизнес подкинул идею или сам что то забыл. Но основная мысль, кмк, что надо постоянно думать о том, куда дальше будет расти твой продукт стараться подстелить соломки

Если вы хотите объяснить своей бабушке, как работают нейросети в принципе и генеративные сети, в частности, то рекомендую эти два видео. Сильно нового ничего нет, но если вы не сильно в теме, то материал очень хорошо структурирован.
https://youtu.be/VVfFf_XW8zw
https://youtu.be/Aaaf6CzG_3Y

Короткое выступление про парную архитектуру. Командное выполнение задачи (в первую очередь, кончено, парное программирование), один из основных инструментов Экстремального программирования Кент Бэка. Но ведь эти коллаборативные практики хорошо работают и в архитектуре им в анализе. Ведь каждый сталкивался с тем. что сидишь над задачей и пришел человек со свежим взглядом, дал два совета и все, ты пошел дальше. В этом и прелесть настоящей командной работы.
А самое главное - такие практики позволяют шарить знания на всю команду, таким образом, чтобы уход, например, аналитика не стал бас-фактором даже без подробнейшей документации ( в чем меня убеждают многие коллеги по цеху, которые топят за подробную документацию в постановках и везде).
https://youtu.be/qlqYKguUV-4

Очень крутая статья от Максима Цепкова про разницу в бизнес процессах и процессах согласования документов. Я почти 10 лет так или иначе работал с внутренними бизнес процессами и процессами согласования документов и могу с уверенностью сказать, что Максим абсолютно прав. Да, есть организации и госструктуры, в которых согласование документов это основной процесс, но самое главное,что это внешние для организации документы. А вот если говорить про внутренние процесс от заявок на оборудование до заявлений на отпуск, то тут реально заменить согласование даже не цифровизацией, а автоматизацией. Проверили уровень сотрудника, наличие оборудования и все, не надо согласовывать - сразу в работу. Заявка на конференцию? Проверили бюджет и уровень сотрудника, ну максимум за аппрувом к его начальнику сходили. https://vc.ru/hr/716180-processy-soglasovaniy-vmesto-realnyh-processov-dlya-biznesa

Судя по описанию Максима, очень интересныц доклад. Надеюсь, смогу посмотреть в записи

#lafest Сегодня на ЛАФ-2023, это интересная и содержательная конференция. Первый доклад Сергей Нужненко. Занимательная картография и археология для аналитиков. По системам часто нет документов или громадное количество доков с инкрементом без целостного описания. Это может быть и с легаси, и с относительно свежей системой - пара студентов за год могут очень многое написать. И получается змея, кусающая хвост: бизнес спрашивает у аналитиков, аналитики - у бизнеса. Реверс за 10% затрат для системы которую 6-10 человек писали 10 лет - не реалистичен. Надо уметь понять существующее относительно дешево. Как сделать обрывочную, неточную, но полезную карту. Часто именно такую задачу ставят аналитикам. Об этом - доклад, это и есть картография и археология. Проблема типична, потому что постоянная актуализация - она тяжелая.

Что нам надо картировать, описывает V-модель, к которой сейчас наверху надо достроить бизнесовую часть. И дальше был краткий рассказ про карты, которые прижились.
* Короткая бизнес-модель
* Карта деятельности: CJM + Service, BluePrint, Карта процессов; Value stream maping. B все это - на встречах
* Карта пользователей историй Story map
* Карта системного ландшафта - потоки данных
* Карты систем: функциональная; информационная; развертывания доступа и обслуживания -- это архитектура

Бизнес-модель схематезирована по Остервальдеру, хотя Сергей на него не ссылалася.
* Какую ценность несем, кому несем, в каких юридических отношениях мы с ними находимся.
* Клиентский путь: узнать, пройти воронку продаж, подключиться (попал в систему) - дает доходы
* Кто помогает нам: тоже юридические отношения - дает расходы

Карты деятельности: Карта процессов и Цепочка прибавленной стоимости; Customet Journey Map + Service BluePrint - что за сценой.

Из CJM получается Story map. Есть еще Impact Mapping: цели, деятельность. Но на ней можно потерять важное.

Раньше аналитик описывал поведение системы в целом, и команде было достаточно для разработки. А сейчас требуется перевести это во взаимодействие сервисов, фронта и бэка. Это DataFlow диаграмма. Что сервис хранит, что он получает, что выдает другим. Форматы, что передается, интерфейсы.

Археология выкопать как сейчас - это будет на мастер-классе.
* Потоки данных между системами
* Контейнерный уровень - отдельно развернутые приложения (сервер, броузер и т.п.). И потоки данных между ними.
* Компоненты.
* Код.
Постепенное погружение по уровням.

Функциональные карты: use case, DFD, User story mapping, Sequence, Robustness...
Информационная карта. Функции меняются, информация живет годами.

Получаем карту с белыми пятнами: здесь копали, здесь не копали. Но она - корректная.

Я отмечу, что тут все равно много получается. Но! Это дешевле, чем полное описание "по старым канонам", и реально можно делать неполно.

Всем привет! Готовлюсь к докладу на Flow в сентябре. Очень нужна статистика по тому, как вы ставите задачи своим разработчикам. Не сочтите за труд заполнить, не больше 5 минут займет https://forms.gle/yRuvgwRcPNrURJUu6

Очень крутой совет, не буду врать, я им тоже пользовался для саморазвития)

Техника обучения Фейнмана

Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:

1️⃣Запишите все, что вы знаете о теме, как будто вы объясняете ее кому-то.
2️⃣Отметьте все пробелы в рассуждениях, и вернитесь к изучению темы, пока не закроете их.
3️⃣Переписывайте свое объяснение, заменяя сложные идеи более простыми, пока оно не станет очевидным.

А вообще, если вы не читали «Вы, конечно, шутите, мистер Фейнман», закрывайте Телегу, покупайте книгу, и, я гарантирую, это будет лучшее вложение вашего времени.

Видео про OAuth2.0 и OpenID, в котором про них рассказывается простыми словами. Если вы слабо знакомы с этой технологией - то это видео - отличный старт https://www.youtube.com/watch?v=W_ffwyefi8A

Очень хорошо про DoR

Как использовать Definition of Ready

Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.

Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.

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

Но проблем от использования DoR в таком формате больше, чем пользы. Вместо итеративной разработки фичи с быстрым фидбэком DoR провоцируют появление этапов работы. Условно говоря, вместо совместной работы разработчика и дизайнера над фичой, у нас появляется два этапа – дизайн и имплементация, между которыми появляется дополнительный гейт в виде ревью макетов. Если макеты не соответствуют DoR, работа над фичей не начинается, пока дизайнер не внесет все правки. А это, конечно, сильно увеличивает среднее время разработки.

Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:

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

Очень крутой пост от Дмитрия Филлипова про типы сотрудников. На какой уровне вы? Я вот на третьем и пытаюсь подступиться к четвертому)

Уже все, наверное видели, но вот тут коллеги из школы системного анализа сделали оооочень крутую подборку статей по системной интеграции
https://systems.wiki/integration

В ходе конференции ЛАФ сделал наблюдение, которое, на мой взгляд, заслуживает отдельного обсуждения. У многих аналитиков неявно есть "учебный" взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка "по умолчанию" считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

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

Чтобы перейти от такого подхода к реальной работе на достижение результата надо менять мышление. Такие тренинги есть для руководителей, это переходе понимания ответственности от responsibility к accountability, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

Регулярная рубрика субботние #мемы

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

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

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

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

и да, берегите себя и своих близких.

❤️ все будет хорошо, главное спокойствие