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