Про продуктовые команды 🤝
(Пролог)

Большинство существующих курсов для продактов уделяют несправедливо мало внимания вопросам взаимодействия продакта с командой разработки. Обычно это глава, в которой скомкано всё вперемежку:
✦ краткое описание Scrum и Agile
✦ состав команды
✦ функции продакта во взаимодействии с командой

Думаю, это попытка не раздуть ещё сильнее и без того объёмные курсы и не перегрузить мозг студента. К тому же, soft skills сложнее научить - там не особо помогает знание теории.

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

Не отрицая важности hard skills продакт менеджера, я всё-таки больше ценю продактов, умеющих эффективно руководить командой.

Я пришёл в product management, имея за плечами 6 лет опыта на руководящих позициях, и с Agile прошивкой в мозгу, поэтому мне некоторые вещи давались легче. Попробую поделиться своими наблюдениями про продуктовые команды по мотивам работы Сбере, Яндексе и стартапах. Авось, пригодится. 😉

Наблюдений много - разобью на 6-7 частей.

⚠️ Disclaimer! Всё написанное ниже - мой субъективный взгляд и опыт. Сбер и Яндекс - огромные компании, и в разных их частях всё сильно по-разному.

Оглавление:
- Scrum Guide
- Кросс-функциональные команды
- Ключевые метрики
- Teach-Lead и Project Manager
- Soft Skills
- Тесное взаимодействие vs Документация
- Кто разрабатывает, тот и поддерживает

#product_team #product_management #longread

Про продуктовые команды 🤝
(Часть 1 - Scrum Guide)

Scrum Guide (далее SG) читали полностью слишком мало продактов. А ещё меньше понимают его суть. Очень рекомендую познакомиться с ним поближе. Джеф и Кен продумали стройный и целостный фреймворк для команд разработки (и не только).

Несмотря на то, что в реальной жизни эталонный Scrum я не встречал ни разу, SG содержит несколько мощных идей, которые вместе резко повышают шансы команды на успех.

✦ Эмпирический подход (сердце Scrum) - цикл: ставить эксперимент, получать обратную связь, делать выводы. Комада постоянно инспектирует продукт (sprint review), саму себя (sprint retrospective) прогресс в работе (daily scrum). Это создаёт систему в которой (если она по-настоящему работает) невозможно не перформить. Представьте гоночный болид, который с каждым спринтом едет быстрее за счёт постоянного анализа, что мешает, и небольших, но постоянных, улучшений. Если гипотеза улучшения не сработала, она просто откатывается в конце спринта и тестируется следующая.

✦ Команда сама определяет принципы, по которым работает. Любые попытки выработать общие правила (кроме вернеуровневых) приводят к тому, что неудобно вообще всем. Давая командам больше автономности и спрашивая за результат, а не за следование процессам, повышается их продуктивность. В случае унификации delivery, например, достаточно gateway’ев - контрольных точек в процессе типа “успешно пройдено 100% регрессионных авто-тестов”. А как именно этого добились, и чьими руками - не так важно.

✦ Цели спринта не подлежат изменению в ходе спринта (кроме особо описанных исключений). Это позволяет сконцентрироваться на достижении конкретного результата, не тратя ресурсы на постоянное переключение контекста. Я встречал команды, которые не имели end2end работающего продукта, спустя год работы. Потому что приоритеты менялись буквально по 2 раза в неделю.

✦ Длительность спринта - не более 1-го месяца. Такой подход снижает риски, позволяет меньше сомневаться и не впадать в параличь в попытках выработать идеальное решение. Потому что быстрее проверить гепотезу на практике и получить реальную обратную связь клиентов. Даже, если ты принял неверное продуктовое решение, команда потеряет (в худшем случае) месяц работы. Но и это позволит сделать вывод из допущенной ошибки.

Когда я в полной мере осознал логику с циклами обратной связи я стал видеть области её применения повсюду, начиная с семейной жизни и заканчивая построение карьеры. Не удивительно, что и область применения Scrum давно распространилась далеко за пределы IT.

При этом стоит учитывать, что для достижения настоящего Scrum (и вытеснения Waterfall) потребовался ряд пререквизитов:
✦ высокая пропускная способность каналов связи, позволившая доставлять обновления софтверный продукты онлайн (а не 💿)
✦ распространение DevOps и CI/CD практик и авто-тестов, позволившие снизить накладные расходы и ускорить циклы (а не ручной регресс длинной в неделю)
✦ превалирование in-house разработки или “time and material” (на смену fix price - в условиях фиксированный платы за заведомо оговорённый скоуп не бывает гибкости)

Рекомендую посетить тренинг по Scrum, если ещё не. Откроет глаза на много интересного. 🤔

#product_team #product_management #Scrum

Про продуктовые команды 🤝
(Часть 2 - Кросс-функциональные команды)

SG декларирует, что команда должна быть способна производить на свет инкремент, независимо от внешних ресурсов. То есть, должна обладать всеми компетенциями, необходимыми для разработки всех компонентов необходимых для реализации фичи.

Agile coach'и любят рассказывать сказки про то, как "нужно на Ruby - открываем учебник и садимся писать на Ruby". На деле это дорого и неэффективно, а кросс-функциональность чаще достигается унификацией технологического стека.

Мои наблюдения говорят, что этим Sbergile проигрывает Яндексовой вариации Scrum.

✦ В Яндекс Маркете повсюду Java и React. Поэтому для ддоработки соседнего сервиса для реализации конкретной фичи разработчику просто нужна консультация или нормальная дока. К тому же, в случае смены приоритетов бизнеса это даёт возможность быстрее перераспределить ресурсы.

✦ В Сбере (не смотря на унифицированный стек) команды привязаны к системам. И даже в случае потребности редко лезут дорабатывать системы соседей, чтобы избежать ответственности за факапы. Это приводит к чудовищным затратам ресурсов и времени на синхронизацию планов и частому "переводу стрелок" в случае факапов.

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

Поэтому я не верю в SAFe и LESS. Это всё попытки выдать желаемое за действительное, без реальной автономности. Только микросервисность, только независимые команды, только хардкор. 🤘

#product_team #product_management #Scrum

Всё пошло не по плану. Запостил недописанную версию. 🤦‍♂

Завтра будет законченный вариант.

Про продуктовые команды 🤝
(Часть 3 - Ключевые метрики)

Независимая (насколько это возможно) работа команд над инкрементами никак не противоречит тому, что все они работают на благо глобальных целей компании. В крупных компаниях большинство продуктовых команд не занимаются поиском product-market fit (хотя, большинство курсов пытаются учить именно этому), а отвечают за прокачку конкретного набора метрик. (Если бы product-market fit не был достигнут, компания не стала бы крупной.)

Глобальные цели компании, обычно выраженны в росте выручки, аудитории, капитализации и т.п. Их составляющие можно представить в виде модели с множеством взаимосвязанных факторов или формулы с множеством переменных. (Про взаимосвязи послушайте шикарные мысли Байрама или Красинского.) Чтобы их достичь не нужно всем работать на выручку, а нужно, чтобы каждая шестерёнка в этом сложном механизме показывала достойный результат. (Эту логику отлично раскрывают Google OKR или иерархия метрик Миши Карпова.)

Например, в Яндекс.Маркете цели продуктовым командами ставятся разным командам в таких терминах:
✦ повышение конверсии из посетителя в покупателя на Х%
✦ рост NPS по процессу возврата товаров на Y%
✦ увеличения покрытия товаров отзывами на Z%

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

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

Product Lead’ы и CPO связывают эти разрозненные uplift’ы метрик в общую картину, формируя ту самую модель, и отвечая на вопрос “Как всё это приведёт нас к успеху? И что такое успех?” (Почему управление по метрикам лучше согласованного roadmap, и почему настоящий Scrum без этого не работает, круто рассказывает Марина Арефьева - гуглите её выступления.)

Сбер тоже пытается в историю с целями по метрикам, но этому сильно мешает привязка команд к системам и общий уровень бюрократии. Чтобы делать большие проекты, нужно заранее договариваться с соседними трайбами, поэтому свободы в принятии решений "по ходу" сильно меньше, а "коммитменты перед руководством" в плане реализации конкретных проектов сильно жёстче.

Интересным следствием управления по метрикам является то, что иерархия метрик (как бы) приходит на смену привычной корпоративной иерархии:
✦ продакт знает, как прокачать метрику, в его огород никто не лезет, потому что он точно знает больше деталей
✦ продакт отвечает перед CPO/Product Lead’ом за результат и фактически несёт роль руководителя команды
✦ выше по цепочке у Product Lead’ов цели в терминах более верхнеуровневых метрик
✦ CPO и Product Lead’ы лучше понимают общую картину
✦ распределение ресурсов между командами отражает приоритет достижения метрики для организации и определяется CPO

То есть, CPO выступает product owner’ом на один уровень абстракции выше, который определяет число story point'ов на разные направления задач в бэклоге в количестве выделяемых человеческих ресурсов. (Спасибо за эту мысль Славе Москаленко.)

Страдаю, что не могу найти классную статью, чем плоха любая иерархия.

Если управление по метрикам работает, как задумано, то это крутейший механизм, совмещающий движение всей организации в одном направлении с высоким уровнем свободы в принятии ежедневных решений. А если оно декларируется, но не работает, то “лебедь, рак и щука”. 🤷‍♂️

#product_teams #product_management #metrics

Интенсив «Level Up 2.0: старт в продакт-менеджменте» 🤩

Product Star проводят очередной интенсив для начинающих продактов. Как тот, на котором выступал я сам.

В этот раз тоже будет куча полезного:
✦ про продуктовые метрики - уже сегодня
✦ про когортный анализ
✦ про CustDev
✦ про дешёвую проверку гипотез

Короче, сплошной поток must have скиллов. Всего 8 выступлений от тех, кто практикует эти скиллы в ежедневной работе.

Как обычно, у PS это сопровождается:
✦ возможностью задавать вопросы в чате спикерам
✦ розыгрышем сертификатов на курсы PS на общую сумму 560 000 рублей
✦ бесплатными карьерными консультациями
✦ и не только…

С 5-го по 19-е октября в 19:00. Да, он уже стартовал. И выступление Миши вы уже пропустили (можно посмотреть в записи). Не пропустите вторую серию сегодня. ☝️

Полная программа интенсива и регистрация здесь.

#промо

Про продуктовые команды 🤝
(Часть 4 - Teach-Lead и Project Manager)

Scrum Guide декларирует равноправие членов команды. Нет руководителей, ответственность только коллективная. На практике "самоорганизующиеся команды” - скорее миф. Как я уже описал выше, роль руководителя возлагается на продакта, как ответственного за результат в терминах достижения целевых метрик.

Кстати, восприятие продакта в качестве руководитель команды типично не только в России. Зарубежные компании намного больше внимания на собеседованиях уделяют именно скиллам взаимодействия с командой: как делишься информацией, как разрешаешь конфликты, как выявляешь слабые места, как следить за соблюдением сроков и т.д. Анализ метрик или дизайн экспериментов их волнуют сильно меньше. То есть, тот же перекос продакта в роль руководителя.

Но за пределами бизнесовых вопросов есть ещё огромный пласт технической реализации и предсказуемого delivery.

Чтобы мозг продакта не взорвался окончательно от необходимости вникать и в эти аспекты, и Сбер, и Яндекс вводят в командах роль teach lead. Получается довольно гармоничное разделение: продакт решает “что делать”, а Tech-Lead - “как делать” и "кому делать”. (Sporify Tribes, прообраз Сберовских трайбов, существуют по схожей логике. И да, это очень похоже на обычную матричную структуру.)

Предполагается, что Tech-Lead обычно отвечает за:
✦ классический people management: мотивация, 1-1, найм…
✦ delivery: предсказуемость и скорость, оптимизация процессов…
✦ унификацию технических аспектов в рамках компании: технологический стек, правила работы с репозиторием…

Но я чаще встречал ситуации, когда это работает не полностью. Tech-Lead чаще обладает глубокой экспертизой, чем скиллами типичного менеджера (или стоит очень много). Поэтому продакту, наверняка, придётся разбираться в том, как выстраивать эффективный процесс разработки. Потому что, если delivery хромает, количеством кастдева/аналитики эту проблему не решить.

Приходя в новую команду, я склонен врываться в оптимизацию процессов, пока не "обучу нейронки" команды действовать с понятной мне логикой. Когда статусы задач в таск-трекере начинают отражать реальную картину, и становятся достаточно прозрачными, чтобы не выяснять каждый раз “а это мы зачем делаем?", я постепенно перестаю участвовать в Daily. Planning и Retrospective остаются в календаре продакта насовсем - без них потеряешь связь с реальностью. (Если опыта в построении эффективных процессов пока немного, рекомендую “Цель” Голдратта - ставит мозги на место, послужит неплохим базисом.)


В вопросам требующих сложной координации появляются и Project Manager’ы. Они могут быть быть как частью конкретной команды, если у неё много завязок с окружающими, так и координировать большие проекты, вовлекающие множество команд и подразумевающие жёсткие deadline. (В Яндекс.Браузере, судя по рассказу Галины Митричевой, всё ещё интереснее.)

Обычно роль проджекта, заключается в следующем:
✦ осознать все составляющие проекта и взаимные зависимости - собрать их в общий план, ничего не забыть
✦ убедиться, что составляющие отражены в планах команд в нужное время - в бэклоге с нужным приоритетом
✦ отслеживать, что всё будет доставлено во время - про задачи не забыли, все справляются
✦ если что-то идёт не по плану, предпринять корректирующие мероприятия (например, перераспределить ресурсы) или экскалировать
✦ координировать всех участников проекта, не являющихся членами продуктовых команды (закупки, инфраструктура, маркетологи, логисты и т.д.)


Продакту не обязательно знать все детали технической реализации фичей или быть гением в оптимизации процессов разработки. Но наличие этих скиллов позволит двигаться быстрее и доставлять фичи эффективнее. ☝️

#product_teams #product_management #tech_lead #project_management

Про продуктовые команды 🤝
(Часть 5 - Soft Skills)

Не смотря на наличие Tech-Lead’а, работать с командой только через него не получится. (Это будет жалким подобием работы реальной продуктовой команды.) Взаимодействие продакта с командой составляет от 20 до 70% рабочего времени. Поэтому быть хорошим продактом без прокачанных soft skills почти нереально.

Если конкретнее, то из essential для продакта soft skills я бы выделил:

✦ Умение делиться информацией. Очень рекомендую погружать команду в контекст исследований и логику приоритизации задач, держать в курсе долгосрочной стратегии и результатов работы - обратной связи от руководителей/заказчиков/рынка. Больше информации - сильнее чувство "причастности" и возможность принимать лучшие решения. Например, проектировать новую фичу с учётом перспектив её развития.

✦ Совместное принятие решений. Если информацией делились достаточно, то команда, с минимумом подталикиваний, поможет генерить идеи и качественные решения. Генерация идей в коллаборации мозгов, почти всегда лучше, чем в одиночку - позволяет компенсировать собственные слепые пятна. Особенно, поиск оптимальных в плане трудоёмкости и ценности вариантов. Даже просто возможность отрефлексировать логику в процессе рассказа про неё крайне полезна - легче заметить шероховатости, донося идею до кого-то. Не вваливайтесь в “я руководитель, поэтому слушайте меня” - это тупиковая ветвь, когда команда просто "смотрит в рот" продакту, даже не пытаясь самостоятельно думать.

✦ Делегирование. Нужно учиться доверять команде - что запланированная задача будет выполнена. Типичная ошибка: “если не проконтролировать, всё сломается” приводит к микроменеджменту. За стремлением контролировать всё часто прячется потребность доказать самому себе свою нужность, постоянно работать на разрыв, чтобы удовлетворить внутреннего критика. На самом деле, если постоянно контролировать, то это никогда не закончится - члены команды будут ждать пинка, без которого ничего не работает. Нужно иногда "отпускать" и просто наблюдать результат, позволять команде учиться на своих ошибках. Сколько свободы давать - очень тонкая грань, экспериментируй.

✦ Мотивация. Я долго жил в иллюзии, что сдержанная похвала лучше, иначе “перехвалишь”. А потом на тантре прочувствовал на себе, что позитивная мотивация решает. (Вот и Харитон рекомендует праздновать микро-победы.) Негативные же эмоции, которых не избежать, нужно доносить по принципам ненасильственного общения. Если вы выстроили эмпатическую связь с командой, то “я чувствую бессилие от того что..." будет работать лучше, чем прямая критика. А доверительные отношения будут стимулировать реже факапить, “не подводить” своего продакта.

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

Вовлекайте членов команды в принятие решений, давайте им проявлять инициативу, прислушивайтесь к их мнению - и будет вам счастье. 🙌

#product_teams #product_management #soft_skills

Про продуктовые команды 🤝
(Часть 6 - Тесное взаимодействие vs Документация)

Бонусом от тесного взаимодействия продакта с командой является отсутствие необходимости в излишней детализации требований. Как детализация является излишней - ситуативно.

Я не верю в идеально проработанные требования. Достаточно детальная и избегающая двусмысленных формулировок документация требует неоправданно много ресурсов на написание и согласование. И чаще она требовалась, чтобы прикрыть зад во времена работы с аутсорсингом по fix price.

При этом (имея опыт работы с 7+ подрядчиками по fix price) я ни разу не встречал такого документа с требованиями, к которому бы не возникало вопросов в процессе разработки. А возникающие вопросы в старой модели взаимотношений "заказчика” и "исполнителя” это приводит к одному из двух сценариев:
✦ "ну тогда сделаю на своё усмотрение" - и будет плохо, потому что, кроме чтения этого документа, я вообще хз что мы делаем
✦ "ваши документы плохие, не могу работать" - постоянные простои в работе и пинг-понг по статусам

А в ситуации, когда команда разработки погружена в контекст, “на своё усмотрение" внезапно оказывается отличной стратегией. Чем больше нейронки команды обучаются принимать правильные решения самостоятельно по обратной связи от продакта, тем меньше потребность в детализации документов. И тем больше продакт мозг продакта освобождается для принятия судьбоносных для продукта решений, вместо расписывания логики работы каждой кнопки.

Казалось бы, проблему можно решить введением роли бизнес-аналитика - продакт описывает требований верхнеуровнево, а аналитик детализирует. Но на практике этот механизм ломается об:
✦ разработчики спихивают принятие даже мелких решений на БА - он становится bottleneck’ом
✦ даже сильно вовлечённый в контекст БА будет отчасти сломанным телефоном - продакту приходится вычитывать все подробности и убеждаться, что его поняли верно
✦ если решать прошлую проблему обсуждениями "всем вместе”, то БА превращается в "писаря" - всё обсудили, все поняли, а Коля зафиксирует

В Сбере и Яндексе требования к подробности документации сильно варьиюруются от команды к команде. Но даже самая подробные из встреченных мной там документов не идут ни в какое сравнение с BRD от бизнес-аналитиков в Ренессанс Кредите, где один только процесс их согласования мог занимать месяцы. (Угадаете, какой в РК был T2M?)

Ещё один бонус от не_слишком детальных требований - их не так обидно отбрасывать, когда выяснится, что задуманное слишком трудоёмко в реализации. А на стадии формирования MVP фичи/продукта стадия потрошения неизбежна.

У недостаточно детальной и не поддерживаемой в актуальном состоянии документации тоже есть минусы:
✦ выше требования к разработчикам при найме - нужно не просто кодер, а человек способный вникать в смысл того, что он делает, немного понимать бизнес
✦ сложность передачи экспертизы - как принималось решение, и почему некоторые вещи сделаны именно так, зачастую можно узнать только из кода, и то не всегда
✦ будут случаться ошибки - как нейронку не тренируй, иногда принятые разработчиком решения будут несовпадать с видением продакта

На мой субъективный взгляд, тесное взаимодействие при, всех его недостатках, бьёт детальную документацию, если для бизнеса критична скорость доставки функционала. (А это почти все компании в текущих реалиях.) Естественно, сильно зарегулированные (банки, здравоохранение…) или высоко-рисковые индустрияи (авиация, энергетика…) накладывают свои ограничения - там всё немного иначе.

Делитесь информацией с разработкой, не считайте их просто "руками" - это окупится ростом самостоятельности. 🤓

#product_teams #product_management #documentation

Про продуктовые команды 🤝
(Часть 7 - Кто разрабатывает, тот и поддерживает)

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

Устаревающие подходы с жёстким разделением развития и поддержки* обычно приводили в обоснование "разгрузить развитие от решения инцидентов и запросов, чтобы сконцентрироваться на новых фичах". Но на практике обилие инцидентов является верным признаком хреново реализованного функционала, затыкание этой проблему бесконечным ростом численности поддержки - вовсе не решение, а подорожник.

*Здесь и далее речь про 2-ю линию с теническим уклоном. 1-ая линия, общаюящаясь с клиентом, конечно, никуда не денется.

"If a human operator needs to touch your system during normal operations, you have a bug." - Carla Geisser, Google SRE.

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

Когда команда сама поддерживает функционал, выработка более качественных решений неизбежна, иначе растущей технический долг и количество порождаемых им инцидентов однажды приведут к тому, что весь ресурс команды станет уходить на "выплату процентов”

Поэтому и в Яндексе, и в Сбере большинство команд поддерживают сами тот функционал, который разрабатывают. Соотношение ресурсов на решение инцидентов и разработку новых фичей определяется в диалоге продакта и Tech-Lead’а Сверху за этим приглядывают ребята из поддержки. Но их роль не в решении инцидентов, а в
✦ координации решения особенно крупных факапов
✦ разбор их причин и предотвращении их повторения
✦ развитии систем мониторинга

Баланс между развитие и поддержкой хорошо раскрывает концепция "error budget" из Google SRE. (Хотя, во всей книге речь скорее про отдельные развитие и поддержку.) Если коротко, то суть сводится к тому, что инцидент неизбежны, если продукт развивается. Отсутствие инцидентов = отсутствие изменений = проигрыш рынка конкуренту. Баланс между развитием (внесением возмущения в прод) и стабильностью сводится к бюджету даунтаймов. Например, 10 часов в квартал сервис может быть недоступен, и это нормально. Но, как только бюджет израсходован, новые фичи не выносятся в прод, а все ресурсы разработки до конца квартала переключаются на повышение стабильности. Размер бюджета отражает понимание бизнес владельцев систем об относительных приоритетах непрерывности сервиса и развития нового функционала.

Ещё одним преимуществом поддержки функционала самой командой является то, что инциденты попадают на глаза продакту. (По крайней мере, критичные.) Будучи погружённым в контент, он может понять реальный приоритет проблемы, чтобы бы ни было по этому поводу написано в тикете. Например, можно не чинить функционал, если мы уже запланировали его замену целиком. Или можно найти компромиссное решение, закрывающее конкретный проблемный кейс костыльно, но быстро. Такие "пируэты" невозможны, когда решением инцидентов занимается поддержка в силу несравнимо худшего понимания контекста.

Будьте в курсе инцидентов - помогает не терять связь с реальностью и не забывать о corner-кейсах, фантазируя невероятные новые фичи. 🙄


Кажется, я могу говорить про построение эффективных процессов в командах бесконечно. Но многое уже сказано до меня и лучше меня. Поэтому на этом закончим. Надеюсь, написанное выше было вам полезно. 😉

#product_teams #product_management #support

Цитаты: Тупые вопросы 🤨

Прочтите короткий пост в источнике. Егор шикарно сформулировал.

Невозможно сосчитать, сколько раз ещё до прочтения это цитаты я задавал вопросы:
✦ А почему нельзя сделать так: … ?
✦ А зачем мы это делаем?
✦ А что такое ...?
✦ А почему процесс такой?
✦ А как это работает?

Вообще всем вокруг. Начальству. Коллегам. Подчинённым. Архитекторам, когда ничего не знал про архитектуру. Аналитикам, первый раз видя их дэшборды.

И эта способность неизбежно приводит к дичайшей скорости моей адаптации. На вопрос, в чём я хорош, я обычно отвечаю именно так: “Я быстро адаптируюсь/учусь.” Обратная связь подтверждает: руководители охреневают именно от моей скорости включения.

Кажется, способность базируется на фундаментальной уверенности “я не тупой” - тогда не страшно казаться тупым. И с каждый разом всё менее страшно, потому что через Х итераций ты становишься прокачаннее тех, кто считал тебя тупым. Это явно следствие воспитания. Не знаю, можно ли развить во взрослом возрасте, но пробовать точно стоит.

И ещё пара напутствий:
✦ Если на твой вопрос не могут ответить доходчиво, то одно из двух: либо человек сам не разобрался достаточно глубоко, либо ты пока, и правда, не в силах осознать ответ. Распознавать буллшит - отдельный скилл.
✦ Да, можно погуглить или почитать доку, но это дольше. Нужно учиться интуитивно чувствовать баланс, когда быстрее спросить, а когда не отвлекать и поискать ответ самому.
✦ “Тупые” вопросы работаю ещё круче при переходе из одной индустрии в другую. Начинаешь привносить подходы, о которых здесь и не задумывались.
✦ Если в компании не принято задавать “тупые” вопросы, беги из такой компании. Там нечего ловиться - вот там ты реально станешь тупым.

Больше тупых вопросов! 😜

#quotes #about_me #stupid

Отзыв на книгу “Dune” by Frank Herbert
(aka “Дюна”)

Ozon | Amazon

“Дюна” великолена - лучшая научная фантастика, что я читал. Входит в топ-3 моих любимых художественных книг. (Остальные две: “Стрелок” и “Убить пересмешника”.) Здесь плотно замешаны политика, религия, генетика, судьба и предвидение.

Вселенная, которую придумал Герберт, поражает своей многогранностью и продуманной предысторией:
✦ Бене Гессерит, десятки поколений закулисно занимающиеся селекцией ради получения своего Квизац Хадерача.
✦ Ментаты - люди, способные проворачивать в уме вычисления на уровне компьютера, пришедшие на смену умным машинам после Бутлерианского джихада.
✦ Гильдия, имеющая монополию на межпланетные перевозки, с навигаторами, обладающими даром предвидения для прокладывания курса между звёздами.

И много чего ещё… Просто отрыв башки! 🤯

А ещё после тантры совсем иначе ощущаются упоминания “предназначения” и “сознания рассы”… От этого ещё сильнее кроет.

Перечитал перед походом в кино. На удивление, фильм не разочаровал. Историю пришлось сильно упростить, чтобы уместить в экранное время. Но атмосфера хороша.

В общем, очень рекомендую. 😉

#books #novel

Всё по-взрослому 😄

В августе блог перерос 500 подписчиков. Я порадовался и чуть успокоился с активным продвижением.

Но в сентябре произошло ещё одно важное изменение, которое для большинства из вас прошло незаметно. Взрослому блогу положен взрослый логин. Поэтому блог прееехал с @vaduz_pro_product на @side_effect. (Это было не очень просто, но об это позже.)

А в эти выходные я актуализировал все использовавшиеся ссылки на предыдущие посты и попутно привёл в порядок хэштеги. Поэтому встречайте актуальный набор тематик.

Надеюсь, он поможет новым подписчикам находить ценное среди старых постов - в них было вложено немало души. 😄

#blog

Тематики канала

#longread - выжимка знаний по темам, в которых я (кажется) разобрался, заслуживают отдельного внимания:
✦ Инсайты за год работы в сфере целевого маркетинга - по результам года работы в Яндекс.Маркете
✦ Как стать продактом? - прикладное руководство по мотивам 2-х лет прокачки, 4-х работ и 50+ собеседований
✦ Про продуктовые команды - главное за 6+ лет в менеджменте разработки ПО
✦ Рефклексия 2021 - результаты года на фоне психотерапии и тантры

#mindfulness - всё про осознанность, включая #tantra и #psychotherapy
#books - отзывы на книги и всё, что связана с книжной тематикой
#about_me - про меня, путь развития, странности
#product_management - всё про управление продуктами
#marketing - всё связанное с маркетингом, включая мой личный опыт
#support - про поддержку пользователей
#tools - инструменты, которые я использую и люблю, полезные хинты
#quotes - цитаты, которые повлияли на мой образ мышления
#thoughts - мои рассуждения на разные темы
#UX_heaven и #UX_hell - примеры крутого и отстойного клиенского опыта
#eatandtalk - мои встречи с интересными ребятами
#blog - всё про развитие этого блога

Я в других соцсетях 👋
✦ Facebook
✦ Instagram
✦ LinkedIn
✦ VK

А ещё есть “свой” стикер-пак! 😉