Очень крутой совет, не буду врать, я им тоже пользовался для саморазвития)

Техника обучения Фейнмана

Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:

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

Очень крутой пост от Дмитрия Филлипова про типы сотрудников. На какой уровне вы? Я вот на третьем и пытаюсь подступиться к четвертому)

Уже все, наверное видели, но вот тут коллеги из школы системного анализа сделали оооочень крутую подборку статей по системной интеграции
https://systems.wiki/integration

В ходе конференции ЛАФ сделал наблюдение, которое, на мой взгляд, заслуживает отдельного обсуждения. У многих аналитиков неявно есть "учебный" взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка "по умолчанию" считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

И все это не лишено оснований в реальной жизни: оценки проекта основываются на следовании правилам и процедурам, а не на реальном результате внедрении системы или отдельных фич, и методика ведения проекта это предполагает. Проблема в том, что реально это плохо работает: сначала по известным методикам пишут постановки, потом их реализуют, а потом оказывается, что результат плохо применим на практике. Но в объяснении говорят "вы плохо следовали методике", не оценивая пригодность методики как таковой. То есть учебный подход, сформированный в школе и институте - поддерживается. Я вижу проявления этого не только на конференциях.

Чтобы перейти от такого подхода к реальной работе на достижение результата надо менять мышление. Такие тренинги есть для руководителей, это переходе понимания ответственности от responsibility к accountability, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

Регулярная рубрика субботние #мемы

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

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

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

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

и да, берегите себя и своих близких.

❤️ все будет хорошо, главное спокойствие

Правильный пост от Тиграна

Всем привет! Выхожу из отпускного анабиоза и возвращаюсь к вам с новыми статьями. https://habr.com/ru/articles/146647/. Для тех аналитиков, которые хотят расти в архитектуру - достаточно неплохо расписана разница между Solution и Enterprise архитекторами

За что я обожаю Александра Бындю, популяризатора гибких методологий, Impact mapping и осознанной работы с заказчиками, так это за умение простыми словами и метафорами объяснять сложные вещи. Например, в этой статье https://habr.com/ru/articles/743034/ он очень круто рассказывает про способы организации инкрементальной доставки продуктов и ценности и подходы к гибкому планированию. Настоятельно рекомендую к прочтению

Тут увидел очень крутое выступление про стили управления: классический и ситуативный или адаптивный. Спикер затрагивает и тему аджайла, но лишь мельком, обозначая ее лишь как сильного предвестника текущих изменений в мире. Рекомендую к просмотру всем менеджерам и лидам. https://youtu.be/Qj0pBJrH14A

Я тут с пачкой роликов)
Хороший и насыщенный ликбез по SSO. Спикер очень хорошо описывает и технологии и кейсы их применения. Подойдёт и тем, кто не в курсе про ССО и для тех, кто в теме. https://youtu.be/RXoSWhFk2X0

И третий ролик. Про брокеров, как писать к ним требования, если разработчики в них не умеют. И про то, какие параметры действительно важные, как с точки зрения техники, так и с точки зрения бизнеса, и их надо подсветить в постановке. https://youtu.be/64v2tP3JVRU

Немного двойственные ощущения от статьи про документирование фронта на ASIIDOC. Я с ним не работал, чтал, что он менее удобен. А вот ребята из Альфы пропилотировали и собрали отзывы, получилось, что не очень получилось, примерно половина людей сказала, что инструмент неудобен и сложнее конфлюенса (хотя, что уж может быть хуже). https://habr.com/ru/companies/alfa/articles/745776/. Даже грустно немного, потому что я верю в Doc as Code, думаю, что у просто надо время, чтобы к нему привыкнуть

Прекрасное выступление от Дениса Бескова, не потеряло ни грамма актуальности за 5 лет. И все то, что Денис обозначает как ошибки предпроекта можно спроецировать и на продуктовую разработку. Особенно про те же цели из головы топ менеджеров. https://www.youtube.com/watch?v=hErMe9DC18I

Что то я в последние дни рекламирую школу системного анализа. Но что поделать - Зоя Степчева делает очень крутые и полезные хардовые доклады для СА, которые уже скорее идут в software/solution архитектуру. На этот раз Зоя рассказала про gRPC. Хорошо, подробно, с примерами и при этом меньше чем за час. Но потом это зачем то побили на три видео)
https://www.youtube.com/watch?v=BgmDc8Ix8Ws
https://www.youtube.com/watch?v=8f3OT45qOBg
https://www.youtube.com/watch?v=aeQDmU8un6o

Тут увидел универсальную статью по проектированию системы. Что за чушь, подумал я.
А статья то оказалась очень годная, это схема и справочник того, о чем надо подумать, когда проектируешь систему и даже раньше, когда собираешь и выявляешь требования.
https://habr.com/ru/companies/kts/articles/741846/
А как вам, дорогие читатели?

Как обычно, очень крутое выступление от Саши Клименко про коммуникации и работу с эмоциями. Для тех из нас, кто хочет расти в менеджмент, прямо must look. https://youtu.be/4zQ6eJzgUuk