Тут полезняшки с Analyst Days. Кто не в чатике, забирайте

Очередной привет от Кати Лысенко. Очень жесткая статья, аккуратно, может сломаться картина мира https://www.linkedin.com/pulse/%D0%BB%D1%8E%D0%B1%D0%B8%D0%BC%D1%8B%D0%B9-%D1%85%D0%BE%D0%BB%D0%B8%D0%B2%D0%B0%D1%80-%D0%BD%D1%83%D0%B6%D0%B5%D0%BD-%D0%BB%D0%B8-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5-ekaterina-lysenko-ozxfe/

Немного интересного с Вебсаммита. Всякой крипты и VR навалом, а вот тут интересная штука, с помощью AI позволяет оцифровать и оптимизировать сетевую инфраструктуру)

ARIS уже не тот

Сегодня мне стукнуло 38 (у меня еще 26 ноября в Лиссабоне, так что все ок)
Обычно итоги подводят по календарному году, а я решил подвести итоги году жизни. А он был что надо, насыщеным и интересным:
- Я сменил страну. Опять. Теперь я обитаю в Португалии и мне тут нравится.
- Я отдохнул 3 месяца в саббатикале.
- Я сменил машину. Всегда мечтал о BMW и наконец то смог себе купить.
- Я сменил работу. Да, опять. И не просто работу, я окончательно сместился из чистого ИТ в продуктовый менеджмент, чем несказанно доволен.
- И я (естестенно не один) сделал в Лиссабоне крутую конференцию EpicHey, которая будет уже в эту среду.
И то ли еще будет!
С днем рождения меня!

Мы это сделали! Сегодня первый день нашей конференции EpicHey!, которую мы собрали в Лиссабоне за предыдущие полгода.
200 человек, больше 40 спикеров. Ваш покорный слуга открывал конференцию в качестве программного директора. новый, волнующий опыт, но у нас получилось!)

Наша конфа начинает собирать отзывы, народу понравилось. В течение перы дней наберусь сил и напишу подробнее о своих впечатлениях!

Новая реальность IT конференций

Заглянул вчера на англоязычную конференцию EpicHey, которую организовала русскоязычная команда в Лиссабоне. Для первого раза получилось очень бодро! Ребята хорошо подошли к выбору спикеров — получилась отличная смесь из докладов про разработку, управление продуктами и тестирование. Все выступления были на английском, хотя для большинства спикеров и участников это не основной язык. Так что в кулуарах часто переходили на русский 🙂

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

#portugal

Решил тут почитать статей аналитических, а то пока к конференции готовились совсем времени не было. И сразу наткнулся на вот этот опус https://habr.com/ru/companies/X5Tech/articles/777196/. В целом, чтобы понять про что статья можно обратиться к первой фразе заключения: Что же делать, если артефакт нужен, а задача под него не подходит? Не отчаиваться!
В целом, наверное, отчаиваться и правда не стоит, но и карго культ делать не надо, если артефакт не подходит - надо взять другой.
Возьмем первый пример по CJM (Customer Journey Map). Зачем он нужен, когда мы описываем внутренний бизнес процесс? Посмотреть на эмоциональную реакцию логиста, когда привезли топливо не на ту заправку? Я и так ее знаю 😂. CJM нужен только в продуктовой разработке, когда делается продукт для широкого рынка, для внутрянки или заказной разработки проще делать описанные БП.
USM вообще то логической продолдение CJM, на котором вы раскладываете те самые эмоции и мотивацию по историям, чтобы понять, как вам разложить реальный путь пользователя на систему, продукт или ручные задачи. В этом, кстати, самое главное отличие US от UC. Стори можно закрыть ручным трудом и ничего не разрабатывать.
Очень важно, кстати, перед CJM и USM определиться с категориями пользователей, сегментировать, выделить персоны, без этого работать будет плохо. А еще между ними можно сделать ServiceBlueprint, как логичное развитие CJM, которое описывает, как тот самый путь пользователя ложится на наш сервис в общем виде, то есть без учета того, что автоматизировано, а что нет и где есть точки контакта. Это помогает дальше строить карту пользовательских историй. И, соответственно под конкретный шаг пути пользователя добавить не только его истории, но и истории и задачи развития сервиса.
Ну и финальный аккорд это Impact Map. Суть ее вообще потеряна и удалена от книжки Аджича. То есть в целом ок использовать такую ментальную карту, но называть ее Impact Map не стоит. Кстати, Александр Бындю усовершенствовал Impact Map, назвав свой метод Карта гипотез, очень рекомендую к изучению. https://xn--80aajikek0bigwf.xn--p1ai/
Вывод простой - дорабатывать инструменты надо под свои нужды, но как минимум соблюдая принцип Сю Ха Ри, и не выдавать свои идеи на их базе за сами методы.

Итак, конфа прошла, и у меня появилось свободное время. А шило сами знаете где говорит, что его быть не должно)
Поэтому я готов взять на половинку декабря и январь трех человек на несколь менторских сессий.
Условия:
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 )

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