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

#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, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

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

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

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

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

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

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

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

Правильный пост от Тиграна

Всем привет! Выхожу из отпускного анабиоза и возвращаюсь к вам с новыми статьями. https://habr.com/ru/articles/146647/. Для тех аналитиков, которые хотят расти в архитектуру - достаточно неплохо расписана разница между Solution и Enterprise архитекторами

За что я обожаю Александра Бындю, популяризатора гибких методологий, Impact mapping и осознанной работы с заказчиками, так это за умение простыми словами и метафорами объяснять сложные вещи. Например, в этой статье https://habr.com/ru/articles/743034/ он очень круто рассказывает про способы организации инкрементальной доставки продуктов и ценности и подходы к гибкому планированию. Настоятельно рекомендую к прочтению

Тут увидел очень крутое выступление про стили управления: классический и ситуативный или адаптивный. Спикер затрагивает и тему аджайла, но лишь мельком, обозначая ее лишь как сильного предвестника текущих изменений в мире. Рекомендую к просмотру всем менеджерам и лидам. https://youtu.be/Qj0pBJrH14A

Я тут с пачкой роликов)
Хороший и насыщенный ликбез по SSO. Спикер очень хорошо описывает и технологии и кейсы их применения. Подойдёт и тем, кто не в курсе про ССО и для тех, кто в теме. https://youtu.be/RXoSWhFk2X0

И третий ролик. Про брокеров, как писать к ним требования, если разработчики в них не умеют. И про то, какие параметры действительно важные, как с точки зрения техники, так и с точки зрения бизнеса, и их надо подсветить в постановке. https://youtu.be/64v2tP3JVRU

Немного двойственные ощущения от статьи про документирование фронта на ASIIDOC. Я с ним не работал, чтал, что он менее удобен. А вот ребята из Альфы пропилотировали и собрали отзывы, получилось, что не очень получилось, примерно половина людей сказала, что инструмент неудобен и сложнее конфлюенса (хотя, что уж может быть хуже). https://habr.com/ru/companies/alfa/articles/745776/. Даже грустно немного, потому что я верю в Doc as Code, думаю, что у просто надо время, чтобы к нему привыкнуть

Прекрасное выступление от Дениса Бескова, не потеряло ни грамма актуальности за 5 лет. И все то, что Денис обозначает как ошибки предпроекта можно спроецировать и на продуктовую разработку. Особенно про те же цели из головы топ менеджеров. https://www.youtube.com/watch?v=hErMe9DC18I