Тема дня: Дерево развития Тим лида
Давно держал в голове вопрос о том, какие навыки Тим лида наиболее важны и как их развивать.
И тут на просторах github'a наткнулся на целый репозиторий, посвящённый дереву навыков Тим лида.
Ребята проделали замечательную работу, результатами которой мы можем насладиться.
У них даже есть телеграмм канал.
Если что-то хотите дополнить в дереве - ПРы приветствуются.
Навыки делятся на 5 основных типов:
- Администрирование (управление процессами, управление проектами и т д)
- Управление ресурсами (управление людьми, командой, развитие технического бренда)
- Продуктовая компетенция (навыки Product owner'a)
- Навыки интеграции в компанию (развитие культуры и ценностей, понимание бизнес модели компании и умение встроить в неё отдел разработки)
- И наконец технические навыки: качество, техническое качество, знание технологий, архитектура
Навыки по написанию кода никто не отменял, но на фоне остального становится ясно, что это всего лишь один из навыков и стать Тим лидом без прокачки других невозможно.
Я практически полностью согласен с этим деревом, радует, что кто-то структурировал информацию в один Mind map. Интересно теперь было бы посмотреть на дерево CTO, потому как, мне кажется, разница будет не очень велика.
Прикрепляю само дерево в .png формате
Давно держал в голове вопрос о том, какие навыки Тим лида наиболее важны и как их развивать.
И тут на просторах github'a наткнулся на целый репозиторий, посвящённый дереву навыков Тим лида.
Ребята проделали замечательную работу, результатами которой мы можем насладиться.
У них даже есть телеграмм канал.
Если что-то хотите дополнить в дереве - ПРы приветствуются.
Навыки делятся на 5 основных типов:
- Администрирование (управление процессами, управление проектами и т д)
- Управление ресурсами (управление людьми, командой, развитие технического бренда)
- Продуктовая компетенция (навыки Product owner'a)
- Навыки интеграции в компанию (развитие культуры и ценностей, понимание бизнес модели компании и умение встроить в неё отдел разработки)
- И наконец технические навыки: качество, техническое качество, знание технологий, архитектура
Навыки по написанию кода никто не отменял, но на фоне остального становится ясно, что это всего лишь один из навыков и стать Тим лидом без прокачки других невозможно.
Я практически полностью согласен с этим деревом, радует, что кто-то структурировал информацию в один Mind map. Интересно теперь было бы посмотреть на дерево CTO, потому как, мне кажется, разница будет не очень велика.
Прикрепляю само дерево в .png формате
Тема дня: Люди-индикаторы
Часто мы с вами не обладаем достаточной компетентностью для принятия решения. Например, стоит ли использовать эту технологию или нет. Является ли новая технология всего лишь трендом и сиюминутным влечением, находящемся на пике пиара или она действительно заслуживает внимания и дальнейшего изучения?
Понять это помогают люди-индикаторы. Кто это? Это своего рода эксперты той или иной области, которым вы достаточно доверяете, к чьему мнению прислушиваетесь. Когда этот человек начинает вам рассказывать об этой технологии, у вас зажигается индикатор. Второй человек-индикатор высказался о технологии в позитивном ключе - у вас уже горит два индикатора. В негативном - будем считать, что на табло лампочка не горит. Просто мигнула, контакт шалит.
Важное умение - окружать себя такими людьми-индикаторами, классными специалистами, способными ненадолго заглянуть вперёд в будущее. Лично я за это ценю конференции и митапы, где можно встретить таких людей и обменяться мнениями.
Часто мы с вами не обладаем достаточной компетентностью для принятия решения. Например, стоит ли использовать эту технологию или нет. Является ли новая технология всего лишь трендом и сиюминутным влечением, находящемся на пике пиара или она действительно заслуживает внимания и дальнейшего изучения?
Понять это помогают люди-индикаторы. Кто это? Это своего рода эксперты той или иной области, которым вы достаточно доверяете, к чьему мнению прислушиваетесь. Когда этот человек начинает вам рассказывать об этой технологии, у вас зажигается индикатор. Второй человек-индикатор высказался о технологии в позитивном ключе - у вас уже горит два индикатора. В негативном - будем считать, что на табло лампочка не горит. Просто мигнула, контакт шалит.
Важное умение - окружать себя такими людьми-индикаторами, классными специалистами, способными ненадолго заглянуть вперёд в будущее. Лично я за это ценю конференции и митапы, где можно встретить таких людей и обменяться мнениями.
А тем временем в Казани организаторы конференции для разработчиков DUMP проводят небольшой митап для Тимлидов. Организаторов давно знаю и уважаю, сам там буду, поэтому welcome!
⏰2 октября 9:00 -11:00 пройдет тимлид-завтрак "Удаленная команда. Начало"
Встреча для тимлидов, менеджеров разработки, СТО — всех тех, кто по полгода не может найти разработчика, кто на грани факапа, и кто созрел взять первого сотрудника на удаленке или отдать часть работ на аутсорс.
Тимлид-завтрак пройдет в кафе-баре IQ на Баумана 60 в формате "кофе-кейсы". Первый час опытом поделятся те, кто уже работает с распределенной командой или аутсорсерами. Будет как об отличном опыте, так и о провальном. А еще будет о граблях, которые можно обойти, и о тех, которые встречаются раз за разом.
Обсудим интервью Никиты Соболева из wemake.services, сделанное специально к тимлид-завтраку, в котором он рассказывает почему не пожалел, что несколько лет назад распустил всю команду из офиса и полностью перешел на работу с удаленными разработчиками.
Второй час: общение со спикерами, и друг другом. На встречу приглашаем и разработчиков, которые работали удаленно, и готовы рассказать об впечатлениях "с той стороны".
Мероприятие бесплатное. Свежесваренный кофе с оргов. Позавтракать можно прямо там: каши добавками, омлет с курицей, сэндвичи и сырники - от 160 руб.
Подробности и регистрация по ссылке 👉https://goo-gl.ru/5IzL
⏰2 октября 9:00 -11:00 пройдет тимлид-завтрак "Удаленная команда. Начало"
Встреча для тимлидов, менеджеров разработки, СТО — всех тех, кто по полгода не может найти разработчика, кто на грани факапа, и кто созрел взять первого сотрудника на удаленке или отдать часть работ на аутсорс.
Тимлид-завтрак пройдет в кафе-баре IQ на Баумана 60 в формате "кофе-кейсы". Первый час опытом поделятся те, кто уже работает с распределенной командой или аутсорсерами. Будет как об отличном опыте, так и о провальном. А еще будет о граблях, которые можно обойти, и о тех, которые встречаются раз за разом.
Обсудим интервью Никиты Соболева из wemake.services, сделанное специально к тимлид-завтраку, в котором он рассказывает почему не пожалел, что несколько лет назад распустил всю команду из офиса и полностью перешел на работу с удаленными разработчиками.
Второй час: общение со спикерами, и друг другом. На встречу приглашаем и разработчиков, которые работали удаленно, и готовы рассказать об впечатлениях "с той стороны".
Мероприятие бесплатное. Свежесваренный кофе с оргов. Позавтракать можно прямо там: каши добавками, омлет с курицей, сэндвичи и сырники - от 160 руб.
Подробности и регистрация по ссылке 👉https://goo-gl.ru/5IzL
Тема дня: Code of conduct для дизайнеров
Недавно с коллегами решили причесать работу дизайнеров. Дизайнеры работают в Figma, и далеко не полностью используют её. Figma позволяет делать более-менее адаптивные макеты, а наши дизайнеры этого не делают. В Figma можно группировать компоненты наподобие того, как группируют фронтенд разарботчики, а дизайнеры этого не делают. Посмотрели на названия каждого элемента, а там сплошные text1, text2, Btn1 и так далее. В общем ад для перфекциониста. Разработчики точно бы так компоненты не называли.
И поэтому написали свод из правил по организации макетов в Figma.
1) При использовании элементов из Material-ui (а мы их активно используем) следует использовать соответствующие названия для элементов:
- AppBar
- SnackBar
- ListItem
- Typography
2) При создании адаптивных компонентов, иконок, мы также должны задавать соответствующие self-descriptive имена, такие как:
- ProductCard
- DeleteIcon
3) Инкапсуляция. Если мы используем иконку в качестве кнопки, значит необходимо не просто разместить иконку в нужном месте, но и обернуть её в элемент Button
4) Библиотека компонентов. Переиспользуемые компоненты нужно размещать отдельно и уже на их основе собирать макеты, а не копировать элементы из предыдущего макета. Ведь, к примеру, если потребуется изменить толщину линии у кнопки, потребуется перерисовывать все макеты. Не говоря уже о создании тем для приложений.
Написали, зачем это нужно. Оказалось, что пока незачем. При этом интересно, что для разработчиков эти правила кажутся очевидными.
- Когда в команде менее трёх дизайнеров (у нас так), проблем с коммуникацией между друг другом нету.
- Разработчики же могут работать с текущими макетами и им в принципе всё равно, как сгруппированы и названы элементы в макете. Всё равно 1 к 1 сгруппировать элементы не получится.
- Обсуждения того, как называть элементы в Figma будет только накалять отношения между разработчиками и дизайнерами. При этом всё сведётся к тому, что разработчики будут говорить что как назвать.
- Различные темы в продукте мы пока вводить не планируем, а нормальных инструментов для экспорта компонентов из Figma в React приложение не появится ещё минимум полгода (сугубо личное мнение).
Введение новых правил сейчас снизит производительность дизайнеров процентов на 25, а нам сейчас наоборот, прирост нужен. Выносить же компоненты в отдельную библиотеку компонентов сейчас очень дорого. У разработчиков всё вынесено, дизайнеры пока могут обойтись без этого.
В общем отложили в ящик на 2 месяца, потом вернёмся, оценим ещё раз целесообразность. Всему своё время.
Недавно с коллегами решили причесать работу дизайнеров. Дизайнеры работают в Figma, и далеко не полностью используют её. Figma позволяет делать более-менее адаптивные макеты, а наши дизайнеры этого не делают. В Figma можно группировать компоненты наподобие того, как группируют фронтенд разарботчики, а дизайнеры этого не делают. Посмотрели на названия каждого элемента, а там сплошные text1, text2, Btn1 и так далее. В общем ад для перфекциониста. Разработчики точно бы так компоненты не называли.
И поэтому написали свод из правил по организации макетов в Figma.
1) При использовании элементов из Material-ui (а мы их активно используем) следует использовать соответствующие названия для элементов:
- AppBar
- SnackBar
- ListItem
- Typography
2) При создании адаптивных компонентов, иконок, мы также должны задавать соответствующие self-descriptive имена, такие как:
- ProductCard
- DeleteIcon
3) Инкапсуляция. Если мы используем иконку в качестве кнопки, значит необходимо не просто разместить иконку в нужном месте, но и обернуть её в элемент Button
4) Библиотека компонентов. Переиспользуемые компоненты нужно размещать отдельно и уже на их основе собирать макеты, а не копировать элементы из предыдущего макета. Ведь, к примеру, если потребуется изменить толщину линии у кнопки, потребуется перерисовывать все макеты. Не говоря уже о создании тем для приложений.
Написали, зачем это нужно. Оказалось, что пока незачем. При этом интересно, что для разработчиков эти правила кажутся очевидными.
- Когда в команде менее трёх дизайнеров (у нас так), проблем с коммуникацией между друг другом нету.
- Разработчики же могут работать с текущими макетами и им в принципе всё равно, как сгруппированы и названы элементы в макете. Всё равно 1 к 1 сгруппировать элементы не получится.
- Обсуждения того, как называть элементы в Figma будет только накалять отношения между разработчиками и дизайнерами. При этом всё сведётся к тому, что разработчики будут говорить что как назвать.
- Различные темы в продукте мы пока вводить не планируем, а нормальных инструментов для экспорта компонентов из Figma в React приложение не появится ещё минимум полгода (сугубо личное мнение).
Введение новых правил сейчас снизит производительность дизайнеров процентов на 25, а нам сейчас наоборот, прирост нужен. Выносить же компоненты в отдельную библиотеку компонентов сейчас очень дорого. У разработчиков всё вынесено, дизайнеры пока могут обойтись без этого.
В общем отложили в ящик на 2 месяца, потом вернёмся, оценим ещё раз целесообразность. Всему своё время.
Тема дня Каким должно быть тестовое задание для junior'ов
Во многих компаниях тестовое задание для junior'ов призвано оценить, обладает ли кандидат конкретными техническими навыками или нет.
А по факту, тестовое задание должно показывать, сможет ли junior овладеть новыми техническими навыками или нет. То есть измерять не константу, а дельту. Общий уровень проще на интервью выяснить.
Также тестовое задание может помочь понять, может ли кандидат отвечать за свои слова и мыслить абстрактно.
Раньше давал следующее задание: просил написать на node js + React чатик на сокетах. В требованиях было около 10 пунктов, начиная с базовых, типа "отправленное сообщение должно отображать имя автора" до "чат должен поддерживать как публичные, так и приватные сообщения". Указывал предпочтительный стэк технологий, но не навязывал его.
Просил указать объём работ, которые кандидат сможет выполнить, а также срок, за который он сможет это сделать. Таким образом кандидат сам из этих требований составлял MVP, который брался сделать за определённое время. Обычно это было 6-7 дней.
По факту кандидат должен был сделать мини проект, при этом изучив новую технологию. При этом кандидат получал удовлетворение от того, что справился с задачей, а не просто сверстал веб страничку.
Также в таком мини проекте было проще посмотреть, как кандидат организует код, нежели при задании "сверстай вот такую страничку".
Вывод: старайтесь смотреть на прогресс, а не на текущее состояние.
Во многих компаниях тестовое задание для junior'ов призвано оценить, обладает ли кандидат конкретными техническими навыками или нет.
А по факту, тестовое задание должно показывать, сможет ли junior овладеть новыми техническими навыками или нет. То есть измерять не константу, а дельту. Общий уровень проще на интервью выяснить.
Также тестовое задание может помочь понять, может ли кандидат отвечать за свои слова и мыслить абстрактно.
Раньше давал следующее задание: просил написать на node js + React чатик на сокетах. В требованиях было около 10 пунктов, начиная с базовых, типа "отправленное сообщение должно отображать имя автора" до "чат должен поддерживать как публичные, так и приватные сообщения". Указывал предпочтительный стэк технологий, но не навязывал его.
Просил указать объём работ, которые кандидат сможет выполнить, а также срок, за который он сможет это сделать. Таким образом кандидат сам из этих требований составлял MVP, который брался сделать за определённое время. Обычно это было 6-7 дней.
По факту кандидат должен был сделать мини проект, при этом изучив новую технологию. При этом кандидат получал удовлетворение от того, что справился с задачей, а не просто сверстал веб страничку.
Также в таком мини проекте было проще посмотреть, как кандидат организует код, нежели при задании "сверстай вот такую страничку".
Вывод: старайтесь смотреть на прогресс, а не на текущее состояние.
Тема дня: Галопом по Европам или 3 конференции за 4 дня
За последние 4 дня посчастливилось выступить на трёх конференциях с темой "BDD тестирование веб приложений". В четверг был митап PiterJs в Спб, в субботу была GDG конференция в Ростове, в воскресенье - Стачка в Иннополисе.
Абсолютно разные слушатели, организаторы, программные комитеты. На одной конференции твой доклад заставляют прогнать несколько раз и помогают улучшить выступление, на другой - берут в программу без прогона, не предоставляя обратной связи в принципе. И отсюда сразу же меняется отношение к мероприятию. За место в одной надо бороться, а в другую берут всех подряд. И поверьте, это никак не коррелирует со стоимостью входного билета и количеством участников.
И нетворкинг получается совершенно разный. А нетворкинг - это чуть ли не главное, зачем люди ездят на конференции и выступают на них. В любом случае за эти 4 дня познакомился с очень классными людьми, но где-то их было больше, где-то меньше.
Если честно - такой график выматывает. Потому что конференция для спикера - это не только 45 минут выступления. Это ещё preParty и afterParty, если они есть. Это обязательные мероприятия, которые надо посещать. Плюс перелёты, общение в кулуарах.
Посетившим доклад обещал выложить презентацию в канал - держу обещание, выкладываю.
За последние 4 дня посчастливилось выступить на трёх конференциях с темой "BDD тестирование веб приложений". В четверг был митап PiterJs в Спб, в субботу была GDG конференция в Ростове, в воскресенье - Стачка в Иннополисе.
Абсолютно разные слушатели, организаторы, программные комитеты. На одной конференции твой доклад заставляют прогнать несколько раз и помогают улучшить выступление, на другой - берут в программу без прогона, не предоставляя обратной связи в принципе. И отсюда сразу же меняется отношение к мероприятию. За место в одной надо бороться, а в другую берут всех подряд. И поверьте, это никак не коррелирует со стоимостью входного билета и количеством участников.
И нетворкинг получается совершенно разный. А нетворкинг - это чуть ли не главное, зачем люди ездят на конференции и выступают на них. В любом случае за эти 4 дня познакомился с очень классными людьми, но где-то их было больше, где-то меньше.
Если честно - такой график выматывает. Потому что конференция для спикера - это не только 45 минут выступления. Это ещё preParty и afterParty, если они есть. Это обязательные мероприятия, которые надо посещать. Плюс перелёты, общение в кулуарах.
Посетившим доклад обещал выложить презентацию в канал - держу обещание, выкладываю.
AI_BDD_v2.pptx
24.3 MB
29 слайд - видео. Там надо нажать кнопочку play)
Долго думал, что делать с этим каналом.
Последний пост был опубликован 5 лет назад, и за это время многое изменилось.
Последние 5 лет я активно занимался и продолжаю заниматься Product Management'ом. За это время успел поработать как в стартапах, так и в крупнейших финтех-компаниях.
Также мне удалось впрыгнуть на волну онлайн-образования и обучить около двух тысяч молодых IT-специалистов.
Многое из того, что я делал и продолжаю делать, основывается на принципах Software Engineering. Иногда это даже мешает. О своих мыслях на этот счёт и о моих текущих проектах я буду писать в этом канале.
До свидания, Software Engineering. Да здравствует Product Engineering. Да здравствует код Продакта.
Хорошей пятницы и до встречи!
Последний пост был опубликован 5 лет назад, и за это время многое изменилось.
Последние 5 лет я активно занимался и продолжаю заниматься Product Management'ом. За это время успел поработать как в стартапах, так и в крупнейших финтех-компаниях.
Также мне удалось впрыгнуть на волну онлайн-образования и обучить около двух тысяч молодых IT-специалистов.
Многое из того, что я делал и продолжаю делать, основывается на принципах Software Engineering. Иногда это даже мешает. О своих мыслях на этот счёт и о моих текущих проектах я буду писать в этом канале.
До свидания, Software Engineering. Да здравствует Product Engineering. Да здравствует код Продакта.
Хорошей пятницы и до встречи!
👍6
Почему в Продакты?
Почему я 5 лет решил стать продактом и стал развиваться в этом направлении?
Ответ — Зачем? 🤷♂️. Если слишком часто и много задаёшь этот вопрос — то рано или поздно начинаешь двигаться в строну бпроизнеса.
Зачем я пишу этот код? Зачем я делаю эту фичу? Зачем я пол года делал функционал, который потом вылетел в трубу?❓
Есть люди, и это нормально, для которых не задавать эти вопросы — нормально. Деньга капает, опыт растёт, зарплата повышается. На работе классные интересные задачки. Можно развиваться сколько душе угодно. И рынок труда сотрудника, а не работодателя! Кайф!😎
А есть те, кто по-тихоньку переходят в менеджмент, становятся тимлидами и встают на тропинку CTO. Тоже очень сложный выбор в текущих реалиях. И когда я общаюсь с такими ребятами, я довольно часто тоже слышу от них вопрос "Зачем?". Ну просто бизнес им не очень интересен. Но чаще есть другие ограничения 👨👩👧👦, и это осознанный выбор.
Мой мозг работает иначе. Слишком сильно раздражает понимание потраченного времени на никому не нужную фичу. Просто раздражает. Жизнь то одна.
В силу воспитания или ещё чего мне хочется быть вовлечённым. Ну не хочу я заниматься тем, что не увлекает. Тратить своё время. Сложно. Не увлекает меня — сложно продать другим. Сложно продать другим — сложно собрать команду. И так далее.😑
Зато преимуществ перед продактами, пришедшими в профессию не из разработки, много. Вы бы слышали восклицания типа "в первый раз вижу продакта, проводящего тех собес!". Приятно. Но и дотошность мешает. И приземлённость тоже. Но об этом в следующем посте.🔜 🔜 🔜
А вы часто задаётесь вопросом Зачем?
Почему я 5 лет решил стать продактом и стал развиваться в этом направлении?
Ответ — Зачем? 🤷♂️. Если слишком часто и много задаёшь этот вопрос — то рано или поздно начинаешь двигаться в строну бпроизнеса.
Зачем я пишу этот код? Зачем я делаю эту фичу? Зачем я пол года делал функционал, который потом вылетел в трубу?
Есть люди, и это нормально, для которых не задавать эти вопросы — нормально. Деньга капает, опыт растёт, зарплата повышается. На работе классные интересные задачки. Можно развиваться сколько душе угодно. И рынок труда сотрудника, а не работодателя! Кайф!
А есть те, кто по-тихоньку переходят в менеджмент, становятся тимлидами и встают на тропинку CTO. Тоже очень сложный выбор в текущих реалиях. И когда я общаюсь с такими ребятами, я довольно часто тоже слышу от них вопрос "Зачем?". Ну просто бизнес им не очень интересен. Но чаще есть другие ограничения 👨👩👧👦, и это осознанный выбор.
Мой мозг работает иначе. Слишком сильно раздражает понимание потраченного времени на никому не нужную фичу. Просто раздражает. Жизнь то одна.
В силу воспитания или ещё чего мне хочется быть вовлечённым. Ну не хочу я заниматься тем, что не увлекает. Тратить своё время. Сложно. Не увлекает меня — сложно продать другим. Сложно продать другим — сложно собрать команду. И так далее.
Зато преимуществ перед продактами, пришедшими в профессию не из разработки, много. Вы бы слышали восклицания типа "в первый раз вижу продакта, проводящего тех собес!". Приятно. Но и дотошность мешает. И приземлённость тоже. Но об этом в следующем посте.
А вы часто задаётесь вопросом Зачем?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Продакты — не продакты
Не открою Америку, сказав, что в России продакты — в большинстве своём проджекты, а не продакты. И это хреново.🤔
У нас есть классные инженеры, которые могут разложить задачку по полочкам и сказать, как её сделать. Есть менеджеры, которые охрененно распланируют ресурсы и всё заоркестрируют.
Не хватает только тех, кто может эту задачу поставить. Ответить на вопрос ЧТО мы делаем и ЗАЧЕМ❓ . А вот КАК это сделать — это уже проще.
И ценятся на собеседованиях Продактов очень часто именно их технические скиллы 💪 и сложность задач🗓 , которые они решали, а не метрики, которых они достигали.
Недостаточно уметь грести. Надо знать, куда грести. 🚣🚣🚣
Если менеджеру перед тобой важны метрики — Лайк 👍. Если KPI — 🤷♂️.
Не открою Америку, сказав, что в России продакты — в большинстве своём проджекты, а не продакты. И это хреново.
У нас есть классные инженеры, которые могут разложить задачку по полочкам и сказать, как её сделать. Есть менеджеры, которые охрененно распланируют ресурсы и всё заоркестрируют.
Не хватает только тех, кто может эту задачу поставить. Ответить на вопрос ЧТО мы делаем и ЗАЧЕМ
И ценятся на собеседованиях Продактов очень часто именно их технические скиллы 💪 и сложность задач
Недостаточно уметь грести. Надо знать, куда грести. 🚣🚣🚣
Если менеджеру перед тобой важны метрики — Лайк 👍. Если KPI — 🤷♂️.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Хватит искать под фонарём
Старый анекдот:
Баян? В современном продакт-менеджменте — ЖИЗА.
Сейчас в продакт-менеджменте буквально каждый говорит о важности данных. Их собирают отовсюду всеми возможными методами. Наши данные — это наш фонарь. По сути, добавление новых данных и их разметка — это увеличение яркости фонаря.💡
Однако есть нюанс. Часто лучшие решения, которые помогают вырасти бизнесу и кратно увеличить метрики 📊, находятся не под фонарём.
Логика проста. Когда данные есть, принять решение проще. Находишь места, где проседает конверсия, проводишь A/B тест, улучшаешь. Правда, обычно проводишь десяток A/B тестов. 🧪
А вот когда данных недостаточно — начинается другая игра. Она называется принятие решений в условиях неопределённости и недостаточности данных. И вот тогда начинается настоящий менеджмент: принятие рисков и ответственности.😎
Конечно, есть задачи, которые без наличия данных невозможно решить в принципе, и это нормально. Но крупная рыба обычно не под фонарём. 🐠🐟🎣
Ставь 👍 — если ищешь под фонарём, 👏 — у меня очки ночного видения.
Старый анекдот:
Ночь, темно. Горит фонарь. Под фонарем на четвереньках ползает подвыпивший мужчина и что-то ищет. Прохожий спрашивает у него:
— Что потеряли?
— Ключи.
— Здесь?
— Нет, там, в стороне.
— А чего же здесь ищете?
— Так здесь светло…
Баян? В современном продакт-менеджменте — ЖИЗА.
Сейчас в продакт-менеджменте буквально каждый говорит о важности данных. Их собирают отовсюду всеми возможными методами. Наши данные — это наш фонарь. По сути, добавление новых данных и их разметка — это увеличение яркости фонаря.💡
Однако есть нюанс. Часто лучшие решения, которые помогают вырасти бизнесу и кратно увеличить метрики 📊, находятся не под фонарём.
Логика проста. Когда данные есть, принять решение проще. Находишь места, где проседает конверсия, проводишь A/B тест, улучшаешь. Правда, обычно проводишь десяток A/B тестов. 🧪
А вот когда данных недостаточно — начинается другая игра. Она называется принятие решений в условиях неопределённости и недостаточности данных. И вот тогда начинается настоящий менеджмент: принятие рисков и ответственности.
Конечно, есть задачи, которые без наличия данных невозможно решить в принципе, и это нормально. Но крупная рыба обычно не под фонарём. 🐠🐟🎣
Ставь 👍 — если ищешь под фонарём, 👏 — у меня очки ночного видения.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Круто не иметь таланта
Мы с детства слышим “Какой талантливый ребёнок”, “Да у него талант”! Мы слышим это про себя и гордимся. Слышим это про сына маминой подруги — и завидуем.😮
Но ни мы, ни сын маминой подруги не заслужили этого. В смысле мы ничего не сделали для того, чтобы быть талантливым. Никто же не восклицает “Да он здоровый!” 💪 или “Да у него есть две руки и две ноги, вот молодец!” 🏃♂️.
Намного реже мы слышим “он заслужил это!”, “он упорно работал ради этого”! 👨💻
Многие высмеивают качков, которые ходят в спортзал и считают их тупыми. “Он спортсмен, ему мозг не нужен🧠 ” — говорят другие.
Да вот, ребята, мир устроен по-другому. И мозгов не хватает тому, кто в зеркале🪞 .
В какой-то момент в карьере и в жизни возникает момент, когда нужна воля и упорство, для того, чтобы продвигаться дальше, достигать новых результатов. Более того, с определённого момента именно эти качества, а не ум или талант определяют твоё место под солнцем. А скорее спортивная воля и упорство, характер. 🧗♂️
Ум тоже имеет свои пределы. Можешь иметь 7 пядей во лбу, но в какой-то момент без команды ты не продвинешься дальше.
Причём тут Продакт менеджмент и разработка. Я долгое время любил ИТ за то, что там виден чистый ум человека, и за него платят. Нет блата. Было приятно, что я не гуманитарий, что расту благодаря своему уму.
Но ум не помогает подниматься после провалов. Ум помогает понять, что ум не всегда и не так важен. А вот упорство и воля — да.
Если ты знаешь, зачем тебе спорт — 👍. Если веришь в талант — 👏
Мы с детства слышим “Какой талантливый ребёнок”, “Да у него талант”! Мы слышим это про себя и гордимся. Слышим это про сына маминой подруги — и завидуем.
Но ни мы, ни сын маминой подруги не заслужили этого. В смысле мы ничего не сделали для того, чтобы быть талантливым. Никто же не восклицает “Да он здоровый!” 💪 или “Да у него есть две руки и две ноги, вот молодец!” 🏃♂️.
Намного реже мы слышим “он заслужил это!”, “он упорно работал ради этого”! 👨💻
Многие высмеивают качков, которые ходят в спортзал и считают их тупыми. “Он спортсмен, ему мозг не нужен
Да вот, ребята, мир устроен по-другому. И мозгов не хватает тому, кто в зеркале
В какой-то момент в карьере и в жизни возникает момент, когда нужна воля и упорство, для того, чтобы продвигаться дальше, достигать новых результатов. Более того, с определённого момента именно эти качества, а не ум или талант определяют твоё место под солнцем. А скорее спортивная воля и упорство, характер. 🧗♂️
Ум тоже имеет свои пределы. Можешь иметь 7 пядей во лбу, но в какой-то момент без команды ты не продвинешься дальше.
Причём тут Продакт менеджмент и разработка. Я долгое время любил ИТ за то, что там виден чистый ум человека, и за него платят. Нет блата. Было приятно, что я не гуманитарий, что расту благодаря своему уму.
Но ум не помогает подниматься после провалов. Ум помогает понять, что ум не всегда и не так важен. А вот упорство и воля — да.
Если ты знаешь, зачем тебе спорт — 👍. Если веришь в талант — 👏
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🤩2
Ну что, пора прощаться с Notion.
Пару дней назад, у меня, как и у многих других пользователей Notion из России появилось это жёлтое предупреждение, напоминающее, какими сервисами я могу пользоваться, а какими нет.
И вот, прощай Notion, привет Obsidian✌️.
На миграцию ушёл один вечер. И этот пост я уже написал в Obsidian, который выглядит и ощущается почти как Notion. Вот что надо сделать:
1. Экспортируем данные из Notion и импортируем их в Obsidian. Вот простая инструкция
1. Экспортируем информацию из Notion
2. Ставим внешний плагин Importer
3. Импортируем данные в Obsidian
4. Ждём несколько минут
2. Возвращаем себе привычный интерфейс Notion, устанавливая плагины:
1. Make.md (даёт часть привычного UX' от Notion) 📖
2. Kanban (как в 21 веке жить без досок?) ✅
4. Calendar (если хотите быстрый доступ к небольшому календарю) 📆
5. Ставим кастомную тему Obdisidanotion 🌤
3. У наших главных тем, что импортировали из Notion проставляем иконки
4. Тратим время на просмотр коротких уроков по Obsidian, чтоб не тратить своё время на беганье по настройкам. Например, без этих мини-уроков я бы долго гадал, как делать так, чтоб новые страницы добавлялись в текущую папку, а не в корень пространства.
Первые впечатления.
Вполне сносно, но нюансы есть:
* Блоки нельзя двигать вверх-вниз перетаскиванием
* Сложнее работать с таблицами. Плагин Make.md хоть и возвращает часть UX Notion, но периодчески ломается. Например, на таблицах при попытке работы с тэгами 🏷. Приходится отключать и включать плагин заново
С чем ещё не разобрался, но знаю, что можно сделать малой кровью
* 🔃 Бесплатная синхронизация с мобильным приложением. Мобильным приложением Notion раньше пользовался раз в пол года, поэтому не горит
* 👯 Совместная работа надо доками. Вроде сделать не сложно можно через гугл док
* 📑 Публикация страниц
Итого
Прощай Notion, да здравствует Obsidian
А чем вы займётесь сегодня вечером?
👍 пойду ставить Obsidian
👏 Notion? Не, не слышал
Пару дней назад, у меня, как и у многих других пользователей Notion из России появилось это жёлтое предупреждение, напоминающее, какими сервисами я могу пользоваться, а какими нет.
И вот, прощай Notion, привет Obsidian✌️.
На миграцию ушёл один вечер. И этот пост я уже написал в Obsidian, который выглядит и ощущается почти как Notion. Вот что надо сделать:
1. Экспортируем данные из Notion и импортируем их в Obsidian. Вот простая инструкция
1. Экспортируем информацию из Notion
2. Ставим внешний плагин Importer
3. Импортируем данные в Obsidian
4. Ждём несколько минут
2. Возвращаем себе привычный интерфейс Notion, устанавливая плагины:
1. Make.md (даёт часть привычного UX' от Notion) 📖
2. Kanban (как в 21 веке жить без досок?) ✅
4. Calendar (если хотите быстрый доступ к небольшому календарю) 📆
5. Ставим кастомную тему Obdisidanotion 🌤
3. У наших главных тем, что импортировали из Notion проставляем иконки
4. Тратим время на просмотр коротких уроков по Obsidian, чтоб не тратить своё время на беганье по настройкам. Например, без этих мини-уроков я бы долго гадал, как делать так, чтоб новые страницы добавлялись в текущую папку, а не в корень пространства.
Первые впечатления.
Вполне сносно, но нюансы есть:
* Блоки нельзя двигать вверх-вниз перетаскиванием
* Сложнее работать с таблицами. Плагин Make.md хоть и возвращает часть UX Notion, но периодчески ломается. Например, на таблицах при попытке работы с тэгами 🏷. Приходится отключать и включать плагин заново
С чем ещё не разобрался, но знаю, что можно сделать малой кровью
* 🔃 Бесплатная синхронизация с мобильным приложением. Мобильным приложением Notion раньше пользовался раз в пол года, поэтому не горит
* 👯 Совместная работа надо доками. Вроде сделать не сложно можно через гугл док
* 📑 Публикация страниц
Итого
Прощай Notion, да здравствует Obsidian
А чем вы займётесь сегодня вечером?
👍 пойду ставить Obsidian
👏 Notion? Не, не слышал
Obsidian Help
Import from Notion - Obsidian Help
Obsidian lets you easily migrate your data from Notion using the Importer plugin. This converts your Notion workspace to durable Markdown files that you can use offline with Obsidian and many other a…
👍3❤2🔥2
Балласт или полезный груз?
Ракете, для того, чтобы продолжить полёт в космосе требуется сбросить балласт. 🚀
А путнику, чтобы отправиться в путешествие, требуется собрать рюкзак и тащить за собой. 🏕
А ещё балласт ракеты на старте был не балластом, а ценным топливом.
Для достижения наших целей 🎯 требуется необходимая подготовка, команда, инструменты. Вот только в какой-то момент всё это меняется. И удобные инструменты, и текущая команда, и собственный опыт превращаются из полезной нагрузки.. в балласт 🪨🪨🪨.
И если с инструментами всё довольно просто, их не относительно не сложно менять. То вот менять команду и бороться с собственными привычками может быть очень сложно. У нас есть эмоциональная привязанность. Меняться в принципе сложно.
В добавок ко всему ещё наш мозг 🧠 устроен таким образом, что может объяснить причину практически всему чему угодно, если мы действительно хотим найти причину. Особенно, если у нас хорошее воспитание! 👼
Из раза в раз подводят коллеги-партнёры? Да это временно! Мы добрались сюда вместе, вместе и пойдём дальше. А как идти без них? Одному стрёмно.😨
Пора расходиться. Ну реально не видишь выхлопа от работы партнёров. А вдруг это дело во мне? :🤔
Нафиг. Имей яйца отделять мух от котлет. В какой-то момент полезный груз превращается в балласт. Да, определить этот момент сложно. Но лучше расставляться точки над i и принимать решение, нежели бесконечно тянуть резину. К цели нас приближает именно череда решений, а не их откладывание.
Если сложно отличать балласт от полезной нагрузки — 👍. Если ты резкий и дерзкий — 👏
Ракете, для того, чтобы продолжить полёт в космосе требуется сбросить балласт. 🚀
А путнику, чтобы отправиться в путешествие, требуется собрать рюкзак и тащить за собой. 🏕
А ещё балласт ракеты на старте был не балластом, а ценным топливом.
Для достижения наших целей 🎯 требуется необходимая подготовка, команда, инструменты. Вот только в какой-то момент всё это меняется. И удобные инструменты, и текущая команда, и собственный опыт превращаются из полезной нагрузки.. в балласт 🪨🪨🪨.
И если с инструментами всё довольно просто, их не относительно не сложно менять. То вот менять команду и бороться с собственными привычками может быть очень сложно. У нас есть эмоциональная привязанность. Меняться в принципе сложно.
В добавок ко всему ещё наш мозг 🧠 устроен таким образом, что может объяснить причину практически всему чему угодно, если мы действительно хотим найти причину. Особенно, если у нас хорошее воспитание! 👼
Из раза в раз подводят коллеги-партнёры? Да это временно! Мы добрались сюда вместе, вместе и пойдём дальше. А как идти без них? Одному стрёмно.😨
Пора расходиться. Ну реально не видишь выхлопа от работы партнёров. А вдруг это дело во мне? :
Нафиг. Имей яйца отделять мух от котлет. В какой-то момент полезный груз превращается в балласт. Да, определить этот момент сложно. Но лучше расставляться точки над i и принимать решение, нежели бесконечно тянуть резину. К цели нас приближает именно череда решений, а не их откладывание.
Если сложно отличать балласт от полезной нагрузки — 👍. Если ты резкий и дерзкий — 👏
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2❤1
Друзья, давайте поможем одному из крупнейших продуктовых коммьюнити ProductSense провести исследование, определить чем сегодня продакты живут, с какими сложностями сталкиваются, какие у них зарплаты, какие цели.
А я потом напиши обзор на это исследование со своими личными выводами.
По ссылке ниже можно не только пройти опрос, но и получить нахаляву записи 10 докладов с ProductSense'24 Moscow, которым участники конференции дали самую высокую оценку,
А я потом напиши обзор на это исследование со своими личными выводами.
По ссылке ниже можно не только пройти опрос, но и получить нахаляву записи 10 докладов с ProductSense'24 Moscow, которым участники конференции дали самую высокую оценку,
a11753.webask.io
State of Product Management (Ru) 2024
❤2🔥2🥰1
Расти сам
Недавно я наткнулся на исследование, показывающее, какими спобосами развиваются Продакты. 📊
📑 Статьи или telegram каналы читают 75%.
🤝 Благодаря общению с коллегами общаются 53%.
📈 Проходят курсы 53%
📖 Читают книги 52%
📱 Смотрят ютуб 49%
🎶 Слушают подкасты 38%
👥 Митапы и конференции — 30%
📧 e-mail рассылки — 13%
📱 twitter — 8%
Исследование проводила Podlodka🔭 , так что данным, в целом, можно доверять.
Меня одного удивило то, что среди способов развития нет своих пет-проектов?❓
Как развиваться вообще без пет-проектов? Как люди, которые отвечают за то, что должен делать продукт, как развиваться, как приносить деньги, не пытаются запустить бизнес сами? Я уж не говорю о том, что пет-проекты могут и должны в перспективе приносить деньги.🐶
Неудобная правда в том, что менеджер продукта, который отвечает за то, ЧТО должен делать продукт, как развиваться, как зарабатывать деньги, обычно неспособен сам сделать успешный бизнес.🧐
Что с этим делать? Пилить пет-проекты, чтобы не было стыдно за кофе со смузи признаться, что никогда не закупал траф и не ничего не пытался продать.
👍 если пытаешь сделать что-то своё и сам, 👏 если продакт и продажи — абсолютно не совместимые вещи
Недавно я наткнулся на исследование, показывающее, какими спобосами развиваются Продакты. 📊
📑 Статьи или telegram каналы читают 75%.
📖 Читают книги 52%
📧 e-mail рассылки — 13%
Исследование проводила Podlodka
Меня одного удивило то, что среди способов развития нет своих пет-проектов?
Как развиваться вообще без пет-проектов? Как люди, которые отвечают за то, что должен делать продукт, как развиваться, как приносить деньги, не пытаются запустить бизнес сами? Я уж не говорю о том, что пет-проекты могут и должны в перспективе приносить деньги.
Неудобная правда в том, что менеджер продукта, который отвечает за то, ЧТО должен делать продукт, как развиваться, как зарабатывать деньги, обычно неспособен сам сделать успешный бизнес.
Что с этим делать? Пилить пет-проекты, чтобы не было стыдно за кофе со смузи признаться, что никогда не закупал траф и не ничего не пытался продать.
👍 если пытаешь сделать что-то своё и сам, 👏 если продакт и продажи — абсолютно не совместимые вещи
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Ребят, спасибо огромное за внимание и ваши вопросы! Как обещал, делюсь презентацией с выступления!
❤7👍3👏2
Учись писать пресс-релизы
Как лучше донести ценность фичи, идеи💡 до руководства?
Напиши пресс-релиз. Как маркетолог.📕
Так сразу же будет ясно, какой именно выхлоп будет от фичи. Hot or not🔥 ? А заодно сам потренируешься писать маркетинговые материалы. Ведь настоящий пресс-релиз тебе вряд ли позволят написать самому (не зря же в компании есть штат маркетологов). Так хоть тут оторвёшься.
Почему не стоит это называть One Pager 📄?
Не все любят читать тексты. Особенно скучные. Это в условно продвинутом Amazon📱 якобы запрещены презентации в powerPoint , а в обычных реалиях руководство любит глянцевые журналы. И они имеют на это право! И тебе будет проще продать свою идею, и им в дальнейшем будет проще её защитить. 🛡
Так что упаковка продукта, идеи, фичи должна начинать ДО её разработки. А то если не понимаешь, как она будет упакована в дальнейшем, то может и не стоит начинать пилить?🪚
Кстати, будь аккуратен, особенно когда в команде есть маркетолог. Если он услышит, что ты собираешься написать пресс-релиз, он может тебя не понять и покрутить у виска🤪 . Поэтому лучше замени в общении "пресс-релиз" на тот же самый "One pager".
👍 если думаешь об упаковке заранее, 👏 если маркетологи сами всё упакуют, тебе это ни к чему
Как лучше донести ценность фичи, идеи
Напиши пресс-релиз. Как маркетолог.
Так сразу же будет ясно, какой именно выхлоп будет от фичи. Hot or not
Почему не стоит это называть One Pager 📄?
Не все любят читать тексты. Особенно скучные. Это в условно продвинутом Amazon
Так что упаковка продукта, идеи, фичи должна начинать ДО её разработки. А то если не понимаешь, как она будет упакована в дальнейшем, то может и не стоит начинать пилить?🪚
Кстати, будь аккуратен, особенно когда в команде есть маркетолог. Если он услышит, что ты собираешься написать пресс-релиз, он может тебя не понять и покрутить у виска
👍 если думаешь об упаковке заранее, 👏 если маркетологи сами всё упакуют, тебе это ни к чему
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🤯1