Сейчас будет сложно. Краткий обзор на Социократию 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 месяцев - просто не реально, будет либо по верхам, либо с пробелами.

И на сон грядущий, прямо шикарная статья про то, как писать документацию. Во-первых, написано профессионалом и ее приятно читать и стилистически и с точки зрения содержания. Во-вторых в сжатом виде дан огромный объем информации, да еще и со ссылками на огромное количество источников и доп. материалов. Терпеть не могу писать документацию, но если писать - то такую! https://habr.com/ru/post/698046/

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

Прекрасная статья годичной давности с перечнем хороших и полезных книг, посвященных организации работы команд, как с инженерной, так и мотивационной точек зрения. Если хотите расти в сторону лидерства и управления командами, то почитать хотя бы часть из книжек стоит (у меня уже парочка есть) https://medium.com/the-serverless-edge/engineering-leadership-here-are-my-go-to-books-64f5b1ed971d

И вообще в другую степь - в визуализацию данных. Если честно, никогда не представлял себе, что отображение в виде дерева можно обогатить еще и набором слоев, которые будут дополнительно подчеркивать те или иные характеристики данных. Забрал идею в нашу команду DWH и BI, вдруг пригодится. https://habr.com/ru/post/672184/

Интересная шпаргалка про REST

А ваш покорный слуга снова на обложке)

Хотим поделиться что мы свели рассказы спикеров с предыдущей встречи в октябре в подробную статью 🌟📄
В лонгриде можно найти дополнительные инсайты, освежить память, а также почитать о чем мы говорили если вы вдруг не смогли прийти.
Читать здесь: Medium

А я снова про аналитика в скраме: https://premieragile.com/where-does-a-business-analyst-fit-in-a-scrum-team/#:~:text=A%20Scrum%20Business%20Analyst%20is,members%20of%20the%20Scrum%20Team. На этот раз почитал статью коллег с запада и они таки считают, что он нужен. Здравое зерно в их словах есть, как я давно утверждаю, изначально команде обязательно нужен аналитик, но по мере погружения в предметную область - необходимость в нем постепенно снижается, как и необходимость в подробных постановках etc. Но то, что его обзывают бизнес аналитиком уже вселяет радость!

И теперь немного в другую сторону. Про Enterprise и API. Т.к. раньше работал в телеком операторе, с интересом почитал статью коллег из Deutsche Telekom про построение корпоративного API шлюза в логике описанной умными дядьками из TM Forum. Сложно, тяжело, занудно, но в таком контексте необходимо, в нашем операторе было так же. С болью мы делали такой слой, но потому он даже начал приносить определенную пользу, хотя копий по пути к этому сломали немало. https://habr.com/ru/company/deutschetelekomitsolutions/blog/600189/

Только ленивый не прокомментировал ТЗ, написанное ChatGPT под руководством Юрия Куприянова https://www.youtube.com/watch?v=HkRAtRCXGbU. Ну что я вам говорил - писать ТЗ в современном мире уже не нужно, за вас это сделает нейросеть. А вот описать ей бизнес задачу - нужно! И тут то и нужен аналитик. Поэтому все идем думать, а не писать лишние бумажки, рутину - нейросетям!