Тут еще подняли тему анализа, как хобби и саморазвития. Есть разные подходы, опишу свой:
1. Я трачу на саморазвитие +\- 10 часов в неделю. Читаю различные статьи на хабре, vc, medium, осмысляю их, часть прочитанного рефликсирую в канал.
2. На спорте, в самолете, когда один в машине слушаю/смотрю видео или подкасты. Если иногда вы видите, как меня прорывает на несколько видео, значит я куда то летал)
3. А еще я учу студентов на курсе по СА, что меня тоже мотивирует развиваться не только как СА, но и как спикера. И учиться качественно готовить материалы, и грамотно систематизировать информацию и много чему еще.
4. Пока в отпуске сумел пойти на тренинги\курсы, в основном про создание продуктов и гибкие методологии, мне реально интересно копать в ту сторону.
5. НО! Я не считаю, что анализ это мое хобби. Иногда это даже мое проклятье. Профдеформация не дает расслабиться, мозг постоянно что то крутит, анализирует, там самая картинка про мозг с идей в 2 часа ночи - иногда это про меня.
6. Я кайфую от своей работы, я кайфую, когда я приношу пользу и пользователи меня искренне благодарят. Но, как правильно писали в комментариях - я работаю для того чтобы жить и мои хобби они за пределами системного анализа, и это прекрасно!

Если кто-то хочет больше разобраться в CharGPT, то тут Владимир Меркушев рекомендует бесплатный онлайн курс

10000001 пост про нейросети

Кажется, в каждом первом канале уже была подборка полезных нейросетей. И мы сохраняем такие посты на будущее, но всё никак не возвращаемся, чтобы использовать наконец AI в своей работе.

Я, как уже говорил, попробовал внедрить использование Chat GPT на ежедневной основе, и ничуть не жалею 🙂

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

Если вам надоело просто читать про нейросети, пройдите 1 бесплатный онлайн-курс по Chat GPT:
— Узнаете, с чем может помочь AI
— Научитесь составлять запросы
— Разберётесь, как обходить галлюцинации и уточнять ответы

Всё бесплатно, надо просто записаться на сайте: https://aiacademy.me/free-course

PS: у курса уже довольно активный чат, где можно посоветоваться и найти ответ на свои вопросы по AI. Соавтор курса Александр Горный, тот самый, что пишет про Стартап дня, активно отвечает и участвует в дискуссиях. Я уже узнал много полезного и точно посмотрю курс.

Ссылка на чат будет доступна после регистрации☝🏻

#дружескийпиар

Достаточно подробная статья про GraphQL. Подробно разбираются плюсы и минусы на основании нескольких лет использования технологии. Исходя из материалов статьи - GraphQL решение по прежнему весьма нишевое, я например, в своих проектах его пока не вижу. А кто то из вас запускал GraphQL в проде? https://habr.com/ru/articles/728476/

Тут коллеги из Отус запилили статью про 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