Итак, конфа прошла, и у меня появилось свободное время. А шило сами знаете где говорит, что его быть не должно)
Поэтому я готов взять на половинку декабря и январь трех человек на несколь менторских сессий.
Условия:
1. Все бесплатно
2. Общаемся по договоренности, сессия не больше часа и не чаще раза в неделю
3. Запросы присылайте вот сюда: https://forms.gle/ingi1o3Jqcm3ybLW9
4. Выберу три интересных мне запроса до 13 декабря
5. Если вы не приходите на назначенную сессию с вас штраф, небольшой, но обидный.
6. Почему и кого выбрал объясню после того, как закончим сессии. Или не объясню)

Давно в списке to read лежала статья СберМаркета про проджектов в продуктовом подходе. https://habr.com/ru/companies/sbermarket/articles/772390/
Что я могу сказать, в той системе, в которой работает СберМаркет оно, кажется, действительно, надо. Является ли это продуктовым подходом? Большой вопрос. Есть ли гибкость? Тоже не понятно. Если у вас выстроена вся разработка так, что даже небольшие доработку требуют учёта и проработки большего количества зависимостей, а это следует из упоминания про удвоение количества проджектов меньше чем за год, то проблема похожа на неэффективность всего процесса доставки ценности.
Я с таким сталкивался в МТС, когда у меня был весь день забит митами с различными проджектами различных проектов, а про интересантов, бизнес заказчиков проекта особо ничего не было известно и их было даже не видно. У вас есть куча документов, ТЗ и тому подобного.
Проблема появления проджектов в том, что они не решают системные процессные проблемы, а лишь закрывают дыры в этих процессах собой. таких проджектов на моем пути встречалось 99%. Зачастую они кроме всего прочего не мыслят категориями ценности для бизнеса, а только категориями закрытия проекта в срок любой ценой, т.к. их КПИ на это намертво завязан.
Наличие в статье упоминания Деливери менеджера меня очень порадовало, т.к. именно деливери это основная функция проджектов, а подпускать их к целеполаганию мне кажется излишним. Правда ребята деливери менеджером называют скорее человека, выстраивающего процессы в целом, но и это очень хорошо, хотя если мы говорим про процесс гибкой разработки ПО (а судя по двухнедельным спринтам это он), то логичнее все же использовать Agile coach, правда хорошие стоят очень дорого.
Главное преимущество тут будет в том, что, как я говорил проджект закрывает собой функцию, а Коуч учит команду и компанию обходиться без проджектов за счёт коллаборации и ответственности.
В целом, я ничего не имею против хорошего проджекта, но проблема, что для многих строгое управления проектом в железном треугольнике становится гораздо важнее доставки реальной ценности. Как только это поменяется, я сам буду топить за проджектов. Кстати, у нас на конфе Надер Рад, один из создателей методологии p3express рассказывал об особенностях ее применения, когда получится, выложу презу и ссылку на запись вступления, проджектам точно пригодится

Я снова делаю рецензию на видео, а значит, я снова в полете. На этот раз моя цель - Кипр. У нас продуктовая стратегическая сессия, три дня плотной работы в отрыве от внешнего мира. Предвкушаю много интересного и полезного, ведь это первая моя стратегическая сессия, можно сказать, дорос 😄
Плюс мы с ребятами готовим для всей компанды небольшой воркшоп по Карте гипотез (это развитие техники Impact mapping от Александра Бындю, если не знаете - гугл легко находит, очень интересно и надеюсь, что будет полезно). После сессии расскажу подробно про свой опыт использования техники и в целом про впечатления от стратегической сессии и, конечно, Кипра. Так же рассчитываю встретиться со старыми и новыми знакомыми, так что ждите фоток в инсте (запрещена в РФ, экстретистская Мета и вот это вот все) innokentybo.

И, собственно, сама рецензия. Потрясающий рассказ от Анны Обуховой (если идеальный Agile Coach сушествует, то это Анна) про обесценивание соственного результата. https://www.youtube.com/watch?v=FNeY-sU2vMM&list=PPSV.
Пересказывать смысла нет - лучше смотрите.
Почему это ценно для меня и так зашло?
Потому что я в это пока не умею. Усиленно этому учусь, последние несколько сессий разбираю причины и блоки с психологом.
Последнее время поймал сеья на том, что получаю кратно меньше долгосрочного удовольствия от того что делаю и как раз докопался до причин в лице сложностей с авторищацией результата именно как своего, часто встречаю у себя блоки Мы и ЛОСИ из доклада Анны, есть уже даже понимание, что внутри это связано с установкой, что хвастаться нехорошо и неправильно, что тебя за это будут бить, нелюбить, завидовать и т.д.
И могу сказать, что будут, обязательно будут, пожтому крайне важно оставлять за спиной такие отношения, друзей, работу, которые это завистью тянут тебя вниз.
Раньше я тоже сильно завидовал более "успешным люлям" с мотивацией - вот они козлы, а меня никто не замечает. А теперь я им тоже завидую, но меньше и с мотивацией: так, у них получилось, а чем я хуже, надо пробовать. И вы знаете что? Получается, я писал свои результаты за год и мог сказать, что сам немного не поверил, что я все это сделал.
Как говорит моя жена, раньше я смотрел на успешных сорокалетних дядек на БМВ и завидовал. А надо понять и самое главное принять, что теперь я сам сорокалетний дадька на БМВ, надо соответствовать. И многое из того чего я достиг - достигнуто благодаря рефлекии, терапии и упрямству.
Но надо еще дальше и больше работать над собой, в первую очередь, в авторизации результатов и получении от них удовольствия, а то так недолго и выгореть или чего похуже.
Собственно, пока сам себя не похвалишь, другие тоже не похвалят😅

И добивочка. Очень техническое и очень вводное видео про облачные вычисления и построение приложений в вебе. Если хотите немного боли и понять в общих чертах, как оно там в облаках, узнать что значат сложные слова Kubernetes, Docker и тд, то велком. https://www.youtube.com/watch?v=JC_OyWpqNSA&list=PPSV

А нет, вот добивка. https://habr.com/ru/articles/777244/. На вид статья не сильно сложная, просто технические детали проектирования системы.
Но вчера на итоговом занятии группы, закончившей обучение на моем курсе мне ребята сказали, что им не хватило особенностей и тонкостей архитектурной проработки. А теперь, почитав эту статью, давайте попробуем подумать, где же должна пролегать граница работы системного аналитика и системного архитектора, который по сути схему из статьи и делает? Может СА писать про Cron? Наверное, может, но вот насколько это нужно насколько он может обосновать свой выбор?
Продумывать работу с кешом? Заниматься выбором оптимальной БД под задачу (вот я бы тут вообще отказался от реляционки в пользу условного редиса и сбрасывал его на диск раз в какой то период времени). Но могу ли я обосновать этот выбор? Пожалуй, что да, но мне тут в помощь 15 лет опыта, широкий кругозор и природная харизма😁.
Давайте подискутируем в комментариях!

Кстати, а вдруг есть кто то на Кипре, я утром в субботу буду в Пафосе, а потом в Лимасоле, есть время примерно до 12-13 часов. Если есть кто то, можем встретиться

Еще один камень кину в сторону классических проджектов. Сегодня смотрел запись интенсива по прдуктовому менеджменту и там был вопрос, а где границы работы продакта. Один из вариантов был "от идеи до продакшена", звучит вроде здраво, но ведущая возмутилась: "Это как то по проджектовому звучит, довести до продакшена и бросить".
И вот тут у меня действительно сложилась картинка, почему деятельность менеджеров проектов мне так претит:
1. Раньше я уже упоминал про ориентацию на сроки и бюджет, а не на ценность. Сколько раз у меня такое было, что нужно приложить немного больше усилий и сделать конфетку. Но проджет либо сразу отметал идею, либо фейлил переговоры по ней с заказчиком, а один раз даже просто сказал, что заказчик отказал, хотя даже не выходил с этим предложением. Очень часто для таких специалистов лень или страх становились блокерами в донесении реальной ценности.
2. Фанатичное следование плану и желание всех на этот план натянуть. Никогда не забуду, как чудесные проджекты из одной из компаний большой четверки перед сдачей устраивали ежечасные статусы накануне сдачи проекта, задолбав всю команду. В два часа ночи (дада, статусы продолжались) я просто сказал, что иду спать невзирая на их возмущения, моему примеру последовала вся команда.
3. Умение и желание спихивать с себя ответственность. Однажды был проект,в рамках которого требовалось загрузить в систему клиентскую базу в несколько сотен тысяч клиентов с договорами, актами и прочим атрибутивным составом. Система была оборудована встроенным 1с подобным интерпретатором (но это не 1С), были варианты грузить через него, делать все проверки бизнес логики, дедупликацию, сверку и тд, все в интерпретаторе в несколько потоков. Или грузить нативно из табличек в SQL и там скриптами проверять и все делать. Первый вариант выглядел дешевле - все проверки уже есть в бизнес логике системы, почему бы не переиспользовать. Я написал четко, почему это будет работать долго, плохо и больно, однако это же было дешевле в разработке и сдедали по первому варианту. В результате загрузка из 3 недель превратилась в 4-месячное полуручное адище с ручной разбивкой файлов и подбором оптимального размера файла. Надо ли говорить, что проджект пытался обвинить меня в недостатках проектирования и изучения данных, спасло меня только то, что все было зафиксировано в письме.
4. И это тот самый поинт из начала поста, им реально все равно, что будет после завершения проекта, продакшен - уже не их зона ответственности, сколько раз я это слышал - нам главное сдать, а там посмотрим, найдут - доделаем, или на проекте развития. Что это не решает проблем пользователей и заказчика в целом было все равно.
Я прекрасно понимаю, что далеко не все проджект менеджеры такие, но большая часть людей, работают на отвали и это печально.

Я таки добрался до @eslysenko )

Очередной шедевр мысли от Дмитрия. В нем собраны основные мысли касательно изменения парадигмы управления компанией и ее элементами. Авторитарная модель становится менее эффективной и в посте приведено очень импонирующее мне обоснование. Задумайтесь и ответьте себя какое решение вы будете реализовать с большим желанием? Которое вам просто спустили? Или то, в выработке которого вы приняли самое деятельное участие? В целом это и есть принцип коллективной ответственности, когда вся команда договорилась, наша решение, которое устроит всех. Именно решение, которое устроит всех, а не компромисс. И вот тогда получается синергия, которая позволяет решить самые важные и сложные задачи относительно легко.

Достаточно интересная статья про шаблонизацию ТЗ. https://habr.com/ru/companies/magnus-tech/articles/776732/
В ней очень грамотно отражен опыт заказной разработки, можно прямо брать и переиспользовать.
Я могу как обычно начать рассказывать, как это неэффективно и т.д. Но реальность такова, что все ещё много систем разрабатывается по модели аутсорса, когда ни заказчик ни исполнитель думают, не про пользу, а про соответствие единой точке правды в виде ТЗ. Для такой ситуации статья очень полезна, я в свое время работы в аутсорсе делал подобный шаблон, но не настолько подробно.

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

Увидел сегодня гениальную игру от Юрия Куприянова (канал Системный сдвиг):
Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.

Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), либо потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.

Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).

Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).

Пока на практике играть не пробовал, но должно быть весело!

Пока готовился к открытому уроку нашел очень дельную статью про gRPC от ребят из Тинькоф, если хотете начать погружение в gRPC, то сначала смотрите мой открытый урок https://www.youtube.com/watch?v=8s4QFKO4RmY, а потом читайте статью https://habr.com/ru/companies/tinkoff/articles/780024/

https://www.youtube.com/watch?v=RkaRSFsVGrw заскакивайте на эфир к Кате Лысенко

Всем привет! Всех с наступающим новым годом!
Хочется пожелать, чтобы всякого неконструктивного треша в вашей жизни было как можно меньше!
А рабочее время заполнялось исключительно задачами, от которых вы кайфуете и приносите пользу!

Всем привет! Новый года я начал просто потрясающе - свалился с лютующим в Португалии гриппом А, кашлем и температурой под 39. Зато появилось время немного притормозить, подумать, переосмыслить.
И первое решение - это все таки начать делать более авторский контент. Да, вначале я буду опираться на чужие материалы, но не как на основу для обзора, а как на подводку к какой то своей мысли, которая мне так или иначе отозвалась. Поэтому я буду очень благодарен вам за любую обратную связь, особенно если она будет конструктивной. Если вам не понравился пост - не стесняйтесь ставить какашку, а если при этом вы еще и напишите, что вам не понравилось - форма или содержание, будет вообще круто.

И начну с небольшого рассуждения про книги. Думаю, многие видели, что я искренне считаю того же Вигерса сильно устаревшим и вообще не очень полезным современному аналитику, особенно начинающему. Кто то говорит, что он помогает систематизировать знания. Возможно, лично мне не помог, знания лучше не стали, но, может быть - дело во мне.
Я потратил на Вигерса чертову тучу времени и нервов, делал несколько подходов, чтобы его прочитать, наконец осилил целиком, через насилие над собой и тут меня постигло разочарование, описанное выше, знаний не прибавилось, система не построилась. Сложно, долго, нудно.
И есть обратный пример - я точно так же заставлял читать себя Коберна про Use Case,но там мне реально открылась новая вселенная и понимание, что все то, что в банках называют Use Case это дико извращенное понимание методологии и от такого ее использования Коберн открещивался. Я про до жути детализированные Use Case до вызовов API, которые еще иногда и бизнесу носят на утверждение. Там мне истина открылась где то через 50 страниц.
И вот сейчас я смог это отрефлексировать и перестать себя заставлять читать книгу, если не получается ее читать хоть по немного и если за первые 50 страниц ты не понял, зачем оно тебе.
Вот буквально вчера принял решение прекратить мучить "Как пасти котов", которую многие считают очень полезной для организации работы команды разработки, а я же все таки теперь продакт менеджер 😁, с разработкой надо общаться немного по-другому. Но она тоже выглядит устаревшей и насквозь пронизана тем - что вы больше не программист, не надо писать код. За 60 страниц я не увлекся. Скажу сразу, что тот же Скрам, что от Сазерленда, что от Швабера проглотил за несколько дней,хотя написаны они примерно в те же года, так что я не то чтобы не уважаю старшых..
И принял очень правильное на мой взгляд решение - перечитать "45 татуировок менеджера", с которой началось мое увлечение профессиональной литературой. И за два дня, больной и с температурой прочитал 200 страниц. Попутно рефлексируя каждую татуировку. Но это уже в следующих постах.
https://www.labirint.ru/books/872445/ (никакой рекламы, просто первая ссылка)

Буквально за несколько дней проглотил книжку про 45 татуировок. Как писали в комментариях к предыдущему посту, книга не даёт никакой системы или фреймворка для построения эффективной системы управления, но лично я ее не за тем и читаю.
Для меня невозможно взять чужую систему и переиспользовать, невозможно натянуть на себя чужой фреймворк, идёт огромное внутреннее сопротивление, хочется сбросить это ярмо 😁. Звучит смешно и по детски, но так оно есть.
Поэтому книги в формате коротких историй, вредных советов или вот таких принципов мне заходят на ура. Я могу сам выбрать, что принять и отрефлексировать, а что выбросить и пройти мимо и никто тебе не скажет, что ты не прав или без этого вся система не взлетит. Мне, кстати, поэтому и скрам не сильно зашёл, наверное)
Но вернусь к книге. Собственно, она стала для меня первой профессиональной книгой, которую я прочитал, именно она подтолкнула меня к тому, что не только художка может быть интересной и не вся проф литература такая скучная, как методички в универе. И мне очень понравилось то, что я смог сопоставить свои впечатления тогда и сейчас.
Конечно, восторга такого уже нет, но есть такое приятное удовольствие от того, что ты как профессионал можешь согласиться с автором или даже внутренне поспорить, причем обоснованно. И это даёт очень крутую мотивацию.
И одна татуировка у меня с тех самых пор появилась. В книге она идёт под номером два. "Читайте, осмысливайте. Тренируйте главную мышцу".
За прошедшие 5 лет я свою очень неплохо натренировал.

Всем привет! Тут нашел гайд, как праввильно делать программное обеспечение с помощью ChatGPT. Гайд короткий и поместрился в один твит, но вот взять из него кусочки и приложить к нашим реалиям проектирования систем вполне можно. https://twitter.com/paraschopra/status/1746942751839797670?utm_source=tldrnewsletter