Тут коллеги из Отус запилили статью про BRD (business requirements document) https://habr.com/ru/companies/otus/articles/733432/. И совершили ключевую ошибку, отразив в BRD функциональные требования. На уровне бизнеса (а BRD это же его требования) любые функциональные требования являются решением. Да, это классический проектный подход - когда не надо думать, надо делать то, что бизнес сказал, но мир то меняется и сразу прописывать ФТ в BRD кажется достаточно сложной, затратной, да и лишней идеей.
Пожалуй, можно добавить пожелания по наличию определенных функций, но вот такое в BRD - это нонсенс, кмк:
"Должно быть создано новое главное хранилище виджетов для размещения записей имен и ссылок на объекты виджета."
А как вы пишете BRD?

Почитал тут статью про OpenAPI и про то, как ребята над ним свою обертку сделали. Занимательно, потом попробую собрать их проект и внимательно посмотреть, но в целом не увидел сильных преимуществ перед сваггером. Ты один раз делаешь документ, а дальше корюпируешь куски и все ок, или вообще генерирует из кода, если API first. А если у тебя настолько с арый фреймворк, что не поддерживает openAPI, то может и не надо не нем делать описание или уже поменять на что то современнее. https://habr.com/ru/articles/732572/. А у вас были проблемы с документированием API?

Тут оказывается в ЛинкедИне тоже годный контент бывает, например, вот

Короткая вводная статья по техникам приоритезации задач, дальше каждую технику можно и нужно изучать глубже https://habr.com/ru/companies/yoomoney/articles/733564/

Тут запахло радикализацией! https://habr.com/ru/articles/733786/
Амазон Prime отказались от микросервисов в пользу монолита и понеслась. Да, монолиты и правда хороши в начале. И да, редкая система дорастает до необходимости распила на микросервисы. Но мне кажется, что истина где то по середине в наборе достаточно крупных сервисов, которые выстроены на базкэе бизнесовых задач, а на техническиз

Статья не в тему анализа. Я прохожу курс Ивана Замесина, как делать продукт и прочитал его интервью Тинькову. https://secrets.tinkoff.ru/lichnyj-opyt/people/ivan-zamesin-interview/. В целом большую часть, того, что есть в интервью можно узнать из тренинга и из канала Ивана, но тут оно собрано вместе и по верхам. Для первоначального погружения самое оно. Мне Иван очень нравится и своим подходом к объяснению различных вещей с точки зрения психики и своей манерой ведения тренинга. Так что интервью рекомендую

Уоу уоу, тут у человека наболело, https://vc.ru/opinions/619737-haos-vmesto-adzhayla. Действительно, многое из того, что он пишет имеет место быть, и как абсолютно правильно замечено, вы снизу можете обложиться скрамами и канбанами, но пока наверху люди не начнут хотя бы лежать в сторону гибкости, все будет работать очень сложно, со скрипом, а то и с карго культом. И это печально

Очень давно была эта статья в закладках, большая, сложная, все не мог к ней подобраться, но наконец осилил. https://habr.com/ru/articles/680376/
Концептуально - очень интересный подход - скрестить REST с GraphQL, слегка приправив oData. Получилось очень универсально, но есть сомнения, что этой универсальности кому то столько надо. Судя по тому, что такого до сих пор нет - видимо не надо.
Но концепт очень крутой, рекомендую ознакомиться для общего развития

Чудесная статья от Юрия Куприянова про идеальный мир выявления всех требований к системе на этапе обследования. https://habr.com/ru/articles/682598/
Ну а в мире реальном половина требований к концу проекта будут неактуальны, детальные требования к интерфейсам (вот в 95% случаев) вы переделаете раз три, что, конечно, заставит пересогласовывать ТЗ (если вам хватило ума туда это запихать) или ПР, куда это все ж лучше прикладывать в качестве приложений.
А еще, если вас угораздит без разработчиков спускаться в инфомодель, то и ее придется переделывать с вероятностью 80%.

Доброго всем утра! Если вы ещё не в курсе, то началась продажа билетов на Analyst Days 27 и 28 октября в Москве. До 31 мая минимальная цена билета. Я планирую там выступить с докладом, развивающим мой весенний доклад про бережливое управление требованиями

Продолжаю читать статьи Максима Цепкова. https://vc.ru/hr/565896-chelovek-dlya-kompanii-ili-kompaniya-dlya-cheloveka На это раз про взаимоотношения сотрудника и компании и спиральную динамику. И все больше понимаю, как тот самый пресловутый Аджайл родился и как он живет в тех компаниях, в которых строят культуру развития и как страдают люди при попытках запустить такие преобразования в культуре силы и правил. Ведь по сути там нет никакого места для инициативы, самоорганизации и т.д. Радует, конечно, что многие корпорации пытаются менять подходы и двигаться в сторону бирюзы, но черт побери, как же медленно и инертно это все

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

Возлюби ближнего больше, чем самого себя. Manager's edition.

Организации достаточно крупного размера начинают быть дико неэффективными.

На это есть тысяча причин.

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

Только так ты можешь показать свое стремление и верность целям организации.

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

ну что, уже узнали свое планирование по OKR?

В итоге, наблюдается парадокс.

Любые системы управления, сильно превозносящие личную ответственность и достижения, фундаментально приводят к тому, что в компании все делают дичь и тянут одеяло на себя, 90% ресурсов тратя на подковерные игрища.

Что, как-бы сказать, немного субоптимально.

В общем, я давно думаю, а как же можно было бы поступать правильно в этой истории?

Должна существовать какая-то система правил, которая противостоит давлению конкуренции, а не поощряет его.

И, кажется, ответ лежит на поверхности. Просто он настолько противоречит управленческим инстинктам, что не рассматривается всерьез.

Нужно сделать так, чтобы помощь чужим подразделениям/людям ценилась выше, чем затаскивание собственных проектов.

Т.е. два менеджера. У одного проекты и у другого проекты. В классической системе они начинают сраться за ресурсы, в итоге оба проекта делают на пол-шишки, 90% энергии по ходу тратя на внутренние склоки.

А в системе кооперативной мотивации, один бы плюнул и помог бы второму. И не получил бы по шапке, а получил бы премию за то, что помог соседям (в противовес перетягиванию одеяла на себя). Даже, если он помог проекту как-бы другого подразделения.

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

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

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

Ребята, тут в одном аналитическом чатике мы с Таней Бунто зацепились за тему целеполагания с другими аналитиками. В итоге, мы с Таней пообщались и поняли, что надо что то вместе замутить. Итак, встречайте: Игра пойми заказчика!

🦩Аналитическая игра «Пойми заказчика. Проект «Элеонора»🦩

Вы аналитик и пишете требования по решению заказчика?
Не можете понять, зачем оно все нужно?
Не понимаете, как измеряется результат для заказчика и для себя?

📍 Что будет?
За 2,5-3 часа вы пройдете путь от выявления потребности заказчика и сбора требований до демонстрации придуманного решения (спроектируете отель). В финале обсудим, что хотел заказчик, а что получилось в результате.

📌 Зачем и для кого?
— быстро пройти весь путь аналитика — от сбора требований до демо
— узнать новые подходы к работе или переосмыслить свои действия
— абстрагироваться от мира IT, но не от аналитики
— игра для аналитиков и тех, кто хочет прикоснуться к миру коммуникаций с заказчиком

👥 Кто проводит?
Иннокентий Бодров — Analyst & Tech product at Stenn.com
Таня Бунто — аналитик и продуктовод «Единого адреса» в HFLabs

📆 Когда и где
13 июня 2023 года
19:00 по Мск
в zoom
длительность — 2,5-3 часа

❓Хочу играть
Вступай в чат игры — https://t.iss.one/+wgeYFgusyMxjN2Y6

Если вы путаетесь в терминологии, связанной с пользовательскими историями, то вот маленькая шпаргалка: https://habr.com/ru/articles/737254/

Достаточно абстрактная статься про архитектуру бизнес процессов. Самое ценное - список реферальных моделей процессов по аналогии с 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
Вроде думаешь, запускаешь, а потом или бизнес подкинул идею или сам что то забыл. Но основная мысль, кмк, что надо постоянно думать о том, куда дальше будет расти твой продукт стараться подстелить соломки