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

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

Если вы хотите объяснить своей бабушке, как работают нейросети в принципе и генеративные сети, в частности, то рекомендую эти два видео. Сильно нового ничего нет, но если вы не сильно в теме, то материал очень хорошо структурирован.
https://youtu.be/VVfFf_XW8zw
https://youtu.be/Aaaf6CzG_3Y

Короткое выступление про парную архитектуру. Командное выполнение задачи (в первую очередь, кончено, парное программирование), один из основных инструментов Экстремального программирования Кент Бэка. Но ведь эти коллаборативные практики хорошо работают и в архитектуре им в анализе. Ведь каждый сталкивался с тем. что сидишь над задачей и пришел человек со свежим взглядом, дал два совета и все, ты пошел дальше. В этом и прелесть настоящей командной работы.
А самое главное - такие практики позволяют шарить знания на всю команду, таким образом, чтобы уход, например, аналитика не стал бас-фактором даже без подробнейшей документации ( в чем меня убеждают многие коллеги по цеху, которые топят за подробную документацию в постановках и везде).
https://youtu.be/qlqYKguUV-4

Очень крутая статья от Максима Цепкова про разницу в бизнес процессах и процессах согласования документов. Я почти 10 лет так или иначе работал с внутренними бизнес процессами и процессами согласования документов и могу с уверенностью сказать, что Максим абсолютно прав. Да, есть организации и госструктуры, в которых согласование документов это основной процесс, но самое главное,что это внешние для организации документы. А вот если говорить про внутренние процесс от заявок на оборудование до заявлений на отпуск, то тут реально заменить согласование даже не цифровизацией, а автоматизацией. Проверили уровень сотрудника, наличие оборудования и все, не надо согласовывать - сразу в работу. Заявка на конференцию? Проверили бюджет и уровень сотрудника, ну максимум за аппрувом к его начальнику сходили. https://vc.ru/hr/716180-processy-soglasovaniy-vmesto-realnyh-processov-dlya-biznesa

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

#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 как набор рекомендаций, а не обязательных правил.