О бизнес-анализе и не только

Никогда не исходите из предположения, что вы работаете со взрослыми осознанными людьми, ставящими во главу угла успех продукта и решение болей пользователей. Просто потому, что это контр-продуктивно. Люди тщеславны, ленивы, обидчивы и любят, когда их слушают не перебивая. В пылу спора всем до фиолетовой звезды, что мы вообще-то работаем на одну общую цель - успех продукта. Намного важнее выяснить, кто прав, кто виноват, и у кого больше. И если исходить из предпосылок выше, то парадоксальным образом вопросы будут решаться намного быстрее. Ну и потому что вы сами не “взрослые и профессиональные” в 100% случаях, даже если вам кажется, что вы-то исключение. Сколько раз мне, остывая, было мучительно стыдно за свои слова и поступки, вам не передать. Но честно признавшись себе в том, что я тоже тщеславная, ленивая и обидчивая, мне стало гораздо проще решать конфликты. Потому что внезапно становится кристально ясно, что кому и как надо сказать, чтобы получить нужный результат, а не врага.

Требования в git: моя практика Сразу дисклеймер: моя философия с AI -- “делай и экспериментируй, а там разберешься”. Поэтому сетап может быть далек от оптимального, но пока работает. Начало моего AI adoption описывала пару постов выше. Коллега-инженер помог поднять локальное dev-окружение и настроить Claude Code с GitHub через стандартный gh CLI. И между делом обронил фразу, которая для меня стала ключевой: «агенты работают эффективнее, когда контекст лежит в репозитории рядом с кодом. И уже есть скиллы, которые пишут требования, тебе руками писать не нужно». Open-source скилл, который он мне показал, выдавал ерунду. Я его переписала под себя и сохранила где? Правильно, в git. Скилл покрывает весь процесс написания требований: 1. Записывает бизнес-контекст, формулирует гипотезу 2. Ходит в кодовую базу и исследует, как новая идея ложится на текущее состояние кода, подсвечивает лимитейшены и потенциальные проблемы ещё до того, как я пойду к разработчикам. 3. Генерирует prd по заданной структуре 4. Проверяет, какие метрики для AB-тестов уже существуют, чтобы не плодить дубли (с этим у нас исторически была проблема). Теперь я не пишу и не редактирую требования руками. Вообще. Я вызываю скилл, описываю контекст идеи, получаю драфт, дальше промчу AI до состояния ready -- и пушу в git. Сетап такой: 1. Общение с AI: Claude Code в терминале. Сейчас через cmux, думаю перейти на Warp. 2. Просмотр markdown: Nimbalyst (это AI-нативный редактор markdown-файлов; удобно читать рядом с тем, что пишет агент). 3. Хранение и согласование: pull request в GitHub. Пока требование в папке draft, аппрув разработчиков не нужен. Как только перевожу в ready for dev - нужен. 4. Если в процессе написания требований я поняла, что нужно улучшить скилл, то доставляю исправления в скилле в одном PR с требованиями. 5. Если в процессе разработки мы поняли, что требования нужно изменить, то это чаще всего делают сами разработчики. Ребята просто просят свой AI обновить требования согласно коду, и я аппрувлю это изменение. Никаких тебе “не так понял”, “не так услышал”, “я этого не говорила”. Иногда я свои оптимизационные идеи реализую сразу в коде, и только если идея нравится -- пишу PRD. Тогда коллеги получают draft PR сразу с требованиями и реализацией, и решают сами: переиспользовать код или выкинуть и написать нормально. Ещё у меня есть агент, который оценивает результаты AB-тестов. Контекст по каждому тесту он забирает из git, а не из Confluence. Теоретически мог бы и оттуда, но интуитивно кажется, что токенов горело бы больше (но замеров я не делала). Я уже писала, что время на написание требований с таким сетапом сократилось в разы. Падения в качестве не замечены, даже наоборот -- за счет того, что скилл исследует кодовую базу, он часто поднимает вопросы, которые я бы 100 про пропустила при проработке идеи. При этом я вижу потенциальные проблемы с внедрением такого подхода: 1. Не-инженерные стейкхолдеры. В Git комфортно тем, кто там уже живёт. Если вам нужно получать формальное согласование от бизнес-стейкхолдеров, вряд ли они легко адаптируются. 2. Сетап работает круто, потому что я не пишу требования руками и все процессы по веткам и PR делает claude code. Если вы не хотите или не можете делегировать эту работу AI, то писать требования в markdown файлах и руками открывать PR скорей всего вас замедлит. Резюме В эпоху AI самым важным становится правильная организация контекста для агентов. Организовать контекст в GitHub проще, потому что: 1. Там уже лежит код, то есть львиная доля контекста. 2. Есть наработанные практики контроля контрибьюшена в этот контекст: PR, ревью, diff'ы, история. Раз мы превращаемся в менеджеров контекста, логично перемещаться туда, где этот контекст живёт. Если у вас похожий опыт или, наоборот, вы попробовали и не зашло -- расскажите в комментариях! Страшно интересен опыт простых смертных, а не AI гуру с линкедина и телеги)

Снова про AI😂 Время несется, прошло почти 2 месяца с моего предыдущего восторженного поста про AI. Наверное, кому-то из вас интересно, как продвигаются дела. Если коротко: медовый месяц продолжается. Несмотря на ограничения технологии, ничто в моей профессиональной истории так качественно не меняло мою работу. Новые возможности 1. 3 похожие метрики выдают разные результаты. Сходили сама в код разобралась, как технически каждая работает; поняла, почему разные результаты и какую нужно использовать для моей задачи. 2. Есть большой датасет в десятки тысяч строк в формате csv. Придумать таксономию —> прогнать на куске датасете —> изменить таксономию —> так несколько кругов —> получить достаточно хорошую таксономию и кластеризировать весь датасет. Напомню, у меня ноль знаний python (или любого другого языка). Зато только у меня есть продуктовое понимание, что пользователи имеют в виду, и только я могу оценить качество получаемого результата и осознанного его менять. 3. Смотрю сессии пользователей. Есть повторяющая проблема, у меня появляется идея, как её решить. Иду и прототипирую сразу в коде. Если нравится - создаю на основе сразу prd, и отдаю инженерам draft PR с прототипом. Иногда они его выкидывают и делают всё сами (ибо на уровне продакшена там нужно поменять кучу всего еще и на BE, а я прототипировала только фронт), а иногда берут мой PR за основу. Главное здесь то, что 1) четко понятно, что именно нужно сделать, 2) я как продакт уверена, что финальный UX стоит того, чтобы его тестировать. 4. Вообще, любой свой вопрос к тому “а как сейчас работает” я могу решить сама, исходя из кода, а не мытарства по приложению с пропуском кучи нюансов. Улучшение\ускорение старых 1. Сделать расчет ROI новой большой инициативы на основании актуальных данных: от придумки модели до финального excel 1 час вместо 6-8ч до этого 2. Написание требований со скиллом: вау-эффект даже не ускорение. Главное, что автоматизирована самая нелюбимая часть: складывать мысли в понятные предложения; редактировать структуру; не писать повторяющихся требований или пропускать очевидные по коду edge cases. Мой скилл не пишет такие требования, которые не нужно править, есть косяки. Но в самой задаче написаний требований от меня требуется только думать (что я люблю), но не требуется всё это писать и переписывать (что я не люблю). 1-2 ч вместо 4-6ч до этого. Кстати, требования я пишу теперь только в git. 3. Оценка AB тестов: опять-таки, скилл может проинтерпретировать неверно, его часто нужно вдумчиво промтить. Но при этом он записывает результаты сам, челленджит мои допущения и пару раз спасал меня от преждевременных выводов. Если что-то из вышеперечисленного особенно интересно, дайте знать в комментариях, напишу более подробный пост. И обязательно делитесь, что вы можете делать сейчас, что раньше представлялось невозможным. Хочу вдохновляться! #ai

Наконец-то кто-то сказал вслух то, что я думаю уже несколько месяцев. Если вы думаете, что кто-то умный знает, куда нас приведет текущая тех революция, то не обольщайтесь. Если вы думаете, что все вокруг действительно понимают, как эффективно внедрить AI в свою работу, то вы зря так думаете. Много умных постов и снобских комментариев, а на проверку - пустой звук. Нигде вы не найдете готовой инструкции, нужно садиться и делать самому. Разбираться, экспериментировать, охреневать от того, что на самом деле стало возможным и одновременно беситься, когда супер простую задачу по-прежнему легче сделать самому, чем запромтить AI. А это бешенное FOMO? Реально, нужна еще одна full-time job, чтобы хоть немного не отставать. А еще жесткое выгорание от того, что теперь ты пытаешься делать 5 разных по сути задач одновременно. Да, вроде ж просто промтишь AI, но твои ментальные токены выгорают в два раза быстрее, чем токены электрические. Неприятная правда в том, что легче не будет. Можно сколько угодно закрывать глаза и отшучиваться, но всё несется. И если не придумать свою пользу в этой новой реальности, она тебя прожует и не подавится. Веселой всем среды) https://www.elenaverna.com/p/confessions-of-a-millennial-in-tech?utm_campaign=post-expanded-share&utm_medium=web&triedRedirect=true&hide_intro_popup=true

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

AI У меня в компании очень поощряется использование AI. Главный фокус, как водится, на разработчиков: разные тулы на выбор, воркшопы по использованию, универсальные скиллы и т.д. И какое-то время я не видела особых изменений в скорости или в подходе к работе. А потом один из моих инженеров просто стал делать гипотезы за 1 час агентом. Не пишет ни строчки кода руками, не привлекает тестировщиков, просто репортит, что тест на проде. Да, это были небольшие оптимизационные идеи, которые и без AI не делали бы долго. Да, он на порядок дальше всех остальных в адопшене AI. Но это было отрезвляюще. Я поняла, что если что-то не поменяю в своей работе, я не смогу обеспечивать команду качественными задачами. А нахрена я тогда нужна вообще? Первая мысль, которая у меня появилась - если он может делать небольшие оптимизационные идеи без самостоятельного написания кода, то может и я могу? Амбициозно, учитывая отсутствие инженерного образования и опыта =) А еще очень сложного продукта с 15 летней историей. Поэтому я зашла так: “хочу проверять свои идеи и гипотезы, делая сырые прототипы сразу в коде, чтобы к вам на разработку доходили только хорошо проработанные”. Он помог мне настроить claude code с доступом к репозиторию и сказал “вообще хорошо бы, чтобы ты писала требования сразу в git, ибо так у агентов будет больше контекста по изменению кода, и они будут работать лучше”. В итоге сначала я сделала скилл по написанию требований. И дело даже не в ускорении работы. Это качественно другой подход - агент сразу идет в код, анализирует текущее состояние и подсвечивает текущие лимитейшены; агент челленджит мои гипотезы и помогает их лучше сформулировать, потому что я написала ему подробный контекст своей части продукта, метрики, историю АБ тестов и т.д.; агент может описывать и думать о нескольких гипотезах сразу. На моей первой же идее агент нашел легаси поведение, которое руинит всю идею, и исправлять сначала нужно его. Ни я, ни UX дизайнер, ни сами инженеры, когда мы обсуждали прототипы в фигме, вообще не вспомнили про это легаси. На этой неделе я написала скилл по оценке АБ тестов. И на первом же АБ тесте агент увидел движение в тех метриках, на которые я сама не подумала посмотреть. И он объективен, никакой эмоциональной привязки, только числа и факты. А представьте, как он поумнеет, когда мы с ним после каждого АБ теста будем и контекст продукта делать всё точнее. Короче, у меня медовый месяц и уже небольшая зависимость =) Хочу покрыть скиллами всю свою работу, и оставить за собой только то, что я действительно люблю - много думать и искать новые идеи. #ai

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

AI лезет из всех щелей. Весь Линкедин пестрит историями успешного успеха в духе: “Я собрал продукт на Lovable за 3 дня - уже получаю кучу тысяч долларов в месяц” или “Я сделал прототип, протестировал на пользователях и провёл сто тысяч итераций за неделю, а не за полгода”, и т.д. Сказать, что у меня жёсткий FOMO - ничего не сказать. Постоянно кажется, что я недостаточно использую AI в работе, а значит, меня скоро заменят. Но сегодня я праздную маленькую победу продакта с AI над бюрократией. Мне нужно было собрать выборку пользователей для интервью. Условий было достаточно много — простым select * from не обойдёшься. В прошлой жизни мне пришлось бы писать задачу аналитикам, ждать, пока её возьмут “в спринт”, тратить время на коммуникацию и объяснение всех условий, потом получить выборку, выпросить сам запрос, не понять в нём половину функций и операторов -- и не суметь повторить такую выборку самостоятельно в следующий раз. А сегодня -- за час сфокусированной работы в паре с Gemini -- я написала запрос сама, отправила аналитикам на ревью и получила аппрув. Чтобы вы понимали: это пятиэтажный монтстр с WITH, функциями вроде num_session, CASE WHEN ... THEN ... ELSE ..., и формулой, которая считает процент сессий на определённой платформе от общего количества. Не оптимизированный монстр, но МОЙ! До своего модного SaaS-приложения на Lovable, конечно, как до Луны. Тем не менее, сегодня я горда собою, о чем вам и хвастаюсь =) И призываю не прокрастинировать и пугаться, а начинать с маленьких понятных шагов. #горопека_о_развитии

Продукт менеджер — очень одинокая профессия. Нет, конечно, ты проводишь 7 часов из 8 на митингах: алайнишь стейкхолдеров, алайнишь команду, брейнштормишь с дизайнером — нужное подчеркнуть. И каждый полон идей о том, что именно не так в продукте, над чем нужно работать в первую очередь и почему эта кнопка должна быть именно в этом месте. Но как только приходит время отвечать за результат - а точнее, за его отсутствие - вокруг никого не остаётся. И это по-человечески нормально, странно ожидать другого. Я это всё пишу не для того, чтобы пожаловаться. Просто после очередного разговора "Ну я же включил в роадмап то, что просили стейкхолдеры, хотя был против. А теперь результата нет, и я виноват" хочется спросить: A чего ты ожидал? Откуда берётся эта избирательная наивность? Не давайте вешать на вас ответственность без права решения. Не давайте решать тому, кто сольётся при первой же сложности. И сами принимайте те решения, за которые вам не будет стыдно. В первую очередь перед самим собою. #горопека_о_карьере #горопека_о_развитии

Баланс - иллюзия. Невозможно успевать всё. Вот и мой маленький блог - очередная иллюстрация. Имея непростой период на работе и большое личное дело, на блог времени и внимания не хватает. Но еще я теряю вдохновение. Я давно уже не бизнес-аналитик, а название канала как-будто обязывает писать про это. Мне кажется, я приучила вас к полезным постам о техниках, приемах, фреймворках, но мне далеко не всегда интересно писать полезность. И вообще, кому она нужна в эпоху chatGTP? Поэтому, дорогие подписчики, если вам не лень, напишите мне в комментариях, как вы пришли в мой блог и о чем вам интересно (было бы) читать от меня. Особенно, если я об этом не пишу или пишу редко. Сверим часы.

Когда “решалка” отказывает Один из побочных эффектов работы менеджером - “решалка” часто отказывает. Ты решаешь 100500 вопросов по работе целый день, и к вечеру физически не можешь решить, что поесть на ужин. Просто проще не есть, чем решать. И наоборот: если в личной жизни приходится много с чем справляться, на работе ты открываешь результаты спорного теста — и не можешь ничего решить. Когда “решалка” уже отказала, нужно отдохнуть, ничего больше не поможет. А вот предотвратить поломку могут помощь следующие принципы. Отделять важные и неважные решения. Критерии “важности” у каждого будут разные. Важно знать свои, чтобы в голове срабатывал алерт “это важное решение, его нельзя принимать впроброс”. Классические критерии: 1. сложно или невозможно провернуть назад (рождение ребенка; согласование бюджета на год) 2. ошибка стоит много денег, времени или энергии (выбор стратегии развития продукта; переезд в другую страну) 3. определяет стратегию на ближайшие N-месяцев \ лет (поменять работу; выйти замуж\жениться) Неважные решение принимать быстро, важные - обдуманно и в отдохнувшем состоянии. Сколько раз я благодарила себя за то, что оставляла важные рабочие решения помариноваться до понедельника. Потому что уставший мозг выстроит вам любую стройную аргументацию для простого решения. И только отдохнув и выспавшись, вы найдете силы на правильные решения. А неважные решения нужно принимать и реализовывать сразу же, иначе они будут сжирать мыслетопливо. Делегировать решения команде и близким. По моим наблюдениям, много кто жалуется на то, как загружен и занят, но на практике не принимает никаких шагов к тому, чтобы разгрузить себя. Ведь ощущение “без меня тут ничего не могут решить” - очень лестное. Но если вы действительно хотите расти и принимать хорошие стратегические решения, не вешайте всё на себя. Дизайнер может решить цвет или расположение кнопки без вас. Инженеры с тестировщиком могут порешать очень много вопросов самостоятельно, было бы желание. Муж\жена могут сами решить, что купить на ужин и в какой ресторан сходить на выходных. Тренировать “решалку”. Как и тело, ментальная энергия тоже тренируется через практику и постепенное повышение нагрузки. Беря на себя больше, вы и справляетесь всё с большим. Так что вместо того, чтобы откладывать на завтра, решите и сделайте сейчас. Планировать жизнь так, чтобы завалы на работе и в личной жизни не совпадали. Понятно, все не предугадаешь, но часто подстелить соломку можно. Когда в офис приезжает топ-менеджмент на неделю, я не планирую никаких важных личных дел, потому что работа съест весь ресурс. Что уж там, я даже вещи глажу на неделю вперед, чтобы утром не думать, что надеть😂 Отпуск я стараюсь не планировать на конец квартала, потому что там подведение итогов и определение OKR на следующий квартал, и я всё равно про это буду думать, так смысл? Если я знаю, что меня ждут челенджи в личной жизни (запланированные вопросы по здоровью, например), то я побольше поработаю до, чтобы ничего важного и срочного по работе не было. Уверена, ничего нового вы не услышали. Но действительно ли вы применяете принципы выше на практике? Помогает? Или может быть у вас есть свои - поделитесь, мне правда интересно. #горопекалайфхаки

Уроки 2024 Кажется, только недавно я выкладывала пост новогодних напутствий, а вот уже и следующий нужно писать. Более вдохновляющий набор букв, чем в прошлый раз, я вряд ли выдам еще раз. Так что если вам нужно вдохновение - перейдите по ссылке, и не читайте дальше) Ибо на вдохновение у меня нет сил. Этот год был полон уроков и преград, а не достижений и поводов похвастаться. Так что всё, чем я могу поделиться - выводами из местами горького опыта. 1. Уверенность в себе и умение “продавать” заведут вас гораздо дальше, чем отличные навыки и скромность. Неправильно нас родители учили быть удобными девочками и мальчиками, во взрослой жизни это только мешает. Пока одни молча хорошо делают свою работу вечерами и ночами, другие уверенно творят всякую херню на коленке, продавая это как конфетку. Угадайте, у кого выше грейды и больше счастья в жизни?) 2. Для успешного продукта нужно трио: продакт, дизайнер и инженер. Если хотя бы одно звено выпадает - вы будете буксовать. Не бывает из этого правила исключений. Один человек может закрывать несколько функций сразу (хотя это редкость), но суть в том, что все три функции 1) должны быть закрыты профессионалами своего дела 2) эти профессионалы должны эффективно работать друг с другом. Возможно, расскажу вам как-нибудь, что бывает, когда пытаешься не замечать пробуксовку одного из звена. 3. Проактивность, самостоятельность, умение держать данное слово - встречаются все реже и реже, и поэтому сильно ценятся. Вся моя карьера построена не на исключительных hard skills, а на этих трех качествах. Я меняю компании, начальников и коллег - но фидбек “что хорошо” остается один и тот же. Харды нужны разные в разных ситуациях, а возможность положиться на человека нужна всегда. 4. На проявление одних и тех же эмоций женщина и мужчина получат очень разный фидбек. Если женщина сдержана, не улыбается и не шутит - “нужно быть проще”, “стоит улыбаться почаще”, “а чего мы такие грустные”? Мужчина в аналогичной ситуации либо вообще не получит фидбек, либо “серьезный и надежный, молодец”. Если женщина спрашивает за результат, указывает на невыполнение дедлайнов, делает замечания по качеству работу - “не нужно быть такой пессимисткой”, “нужно спокойней ко всему относится, не стрессовать так”. Мужчина в аналогичной ситуации будет сильным лидером и менеджером, который держит команду в рабочем темпе. Работает это и в другую сторону. Почему-то женщинам можно шутить про внешность, или там шутки с откровенным сексуальным подтекстом, и это не харрасмент. А мужчинам лучше даже комплименты не делать) 5. Когда очень сложно — вспомни, зачем всё это. Возможно, чтобы прокормить семью и не потерять ВНЖ. Возможно, чтобы сделать крутую штуку в продукте, за которую будешь гордиться и благодаря которой научишься многому. Возможно, выдержав этот сложный период, впереди ждет повышение и бонусы. А возможно, весь этот стресс и сложность не ведут вообще ни к чему хорошему — и тогда самое время осознать это и выбрать себя. #горопека_о_развитии

Разберем кейс из предыдущего поста Качество “фидбека” - объективно плохое. Это очень эмоциональное сообщение, с сомнительной лексикой, без конкретных пример, без запроса на изменение \ вариантов решение, без принципа бутерброда (хорошее-плохое-хорошее) и т.д. От такого сообщения легко отмахнуться по принципу “женщина просто истерит” или “она на меня наезжает не понятно за что”. Зайдите в комментарии к предыдущему посту, там дорогие подписчики всё разложили. Чего же я такой некачественный фидбек отправила? Во-первых, в тот момент многое наложилось, и я просто не сдержала эмоции. Не повторяйте такое в домашних условиях😁 Но во-вторых, у нас были в целом неплохие отношения. Магии не было, но мы решали вопросы, деливерили результаты, и я знала по предыдущим фидбекам, что коллега в целом моей работой доволен. Если бы у нас был открытый конфликт или скрытая ненависть, я бы конечно свои эмоции проглотила и действовала бы более обдумано. Что же было дальше? 1. Коллега ПОБЛАГОДАРИЛ меня со словами “мне никто никогда не дает негативный фидбек”. И это проблема любого менеджера: получить честный фидбек сложно, и чем выше по иерархии менеджер - тем сложнее. 2. Поругался, что не пришла раньше =) 3. Мы довольно подробно разобрали, что именно меня триггерит. Я подчеркивала, что мне очень нужна обратная связь по моим гипотезам и идеям, потому что в здоровой коллаборации всегда рождается что-то лучшее. Что дело не в самом факте наличия вопросов, а в их формулировках, издевках и т.д. И что я знаю, что он может по-другому общаться, потому что я видела его общение с инженерами, когда они допускают баги на проде или делают что-то не так после подробных объяснений. Коллега же говорил о том, что не ставил себе целью демотивировать или задеть меня, но в целом понимает, почему так могло показаться, и постарается это контролировать. После наши отношения стали лучше и честнее. Я поняла, что могу приходить с негативной обратной связью (даже такой эмоциональной), и от меня не отмахнутся. Коллега понял, что если у меня будет недовольство - то я сначала приду к нему, а не буду сразу увольняться или эскалировать. А для данного локального кейса у меня появилось стоп-слово “переставай жестить”, после которого коллега ухмылялся и, собственно, переставал жестить. Выводы: 1. Фидбек - основной инструмент построения хороших отношений. Нужно регулярно просить и давать фидбек: и положительный, и негативный. 2. Негативный фидбек нужно особенно хорошо формулировать: подбирать лексику, давать примеры, писать я-сообщениями, обозначивать запрос и т.д. 3. Положительный фидбек нужно не забывать давать. Почему-то критиковать мы все горазды, а сказать “вот тут классно сделала, молодец” - часто не считаем нужным. 4. Я понимаю, что страшно давать негативный фидбек, но это лучшая лакмусовая бумажка. Если на качественный негативный фидбек реакция адекватная — вы скорей всего с каждым обоюдным фидбеком будете подстраиваться друг под друга и в результате классно сработаетесь. #реальныйкейс

#реальныйкейс Во многих продуктовых компаниях Product Manager работает в тесной связке с Engineering Manager. Когда у этих двух ролей есть мэтч — понимают друг друга и свою часть ответственности; эффективно челленджат друг друга при обсуждении гипотез и приоритетов; есть согласие по стратегии и направлению движения — происходит настоящая магия: показатели растут, команда перформит, все вокруг довольны. Но бывает, что магии нет. Однажды, сразу после встречи по обсуждению гипотез я отправила своему коллеге следующее сообщение. По грамматике и некоторой лексике вы можете понять, что у меня накипело =) Непрошенная обратная связь: я очень часто чувствую от тебя наезд или снисхождение типа "нахера вы это придумали" при обсуждении продуктовых инициатив. Я всегда приветствую обратную связь и вообще считаю, что лучшие идеи рождаются в коллаборации и челлендже друг друга. Но чтобы это работало, атмосфера должна быть здоровой и дружелюбной. Иначе не будет никакой коллаборации, а просто наезды друг на друга. На этом примере предлагаю вам потренироваться: 1. Адекватно ли я сформулировала свой фидбек? 2. Вы поступили бы также (дали фидбек) или как-то по-другому? 3. Как развивалась ситуация дальше? А поскольку это реальный кейс из моей практики, на неделе расскажу, что было потом.

#пятничныезаметки На этой неделе размышляла о том, как много у нас в голове всяких установок, которые мешают в работе. Например, такие: Критикуешь - предлагай. Всегда будут ценится сотрудники, которые умеют решать проблемы, а не только “подсвечивать” и “накидывать на вентилятор”. Каждый раз, когда вы хотите поднять проблему, нужно думать, как бы вы её решали. Это полезно для вас самих же: именно так и решалка тренируется, и зп повышается. Но есть проблемы, которые вы не можете решить. Потому что не та позиция. Или потому что не хватает знаний и скиллов. Но это не значит, что о проблемах нужно молчать и притворяться, что всё хорошо. Ибо это работа ваших менеджеров и хэдов: решать те проблемы, которые вы на своем уровне решить не можете. Поэтому, дорогие сотрудники, не стесняемся поднимать сложные проблемы, которые объективно мешают вам работать. Просто делаем это уместно и не скатываемся в вечных нытиков. Инициатива наказуема Опять-таки, инициативные сотрудники ценятся намного больше. И есть определенная логика в том, чтобы реализацию идеи класть на плечи автора, потому что это здорово отрезвляет пустых накидывателей на вентилятор. Но слепое следование такому принципу приводит к тому, что вся команда едет на плечах 2х инициативных сотрудников. В результате они выгорают от нагрузки и несправедливости, и либо перестают быть инициативными, либо уходят. Поэтому, дорогие менеджеры, помним: ваша работа заключается в адекватном распределении нагрузки и ответственности. Задачи должны реализовываться тем, кто имеет на это скиллы и время, и это вообще не обязательно инициатор изменений. Конечно, намного проще поручать сложные задачи старательным и ответственным, а остальных не трогать. И вы так можете долго продолжать, но только будьте честны хотя бы с собою - вы не учитесь ставить цели, определять ответственность, спрашивать результат, нанимать \ увольнять людей, а просто получаете менеджерскую зп за счет сверх-усилий других.

Первое правило при работе с требованиями: начни документировать как можно раньше. Даже если кажется, что там работы на 15 минут. Точно всплывут неучтенные проблемы и несостыковки с текущей логикой. Второе правило: начни документировать как можно раньше. Потому что спустя час, день, неделю тебя внезапно догонит понимание, что вот это и вот это еще не учтено. Хорошие требования должны “настояться”. Третье правило: начни документировать как можно раньше. Даже если задачу отдавать тебе через месяц. Любые появляющиеся идеи, или потенциальные проблемные моменты, или полезные ссылки — сохраняй всё сразу, даже если “на чистовик” будешь писать через месяц. Четвертое правило: забей, всё равно никто читать не будет #пятничныезаметки

АБ тест проиграл. Делать итерацию? Вы запустили АБ тест. Он проиграл \ не выиграл. Какой вывод из этого делать - не верна гипотеза или решение к ней? ИМХО, это один из самых злободневных вопросов, который продукт-менеджер должен решать каждый день. В моей практике есть примеры, когда на вторую-третью итерацию решения мы получали супер-выигрышный тест. Но также есть и примеры, когда команда всё делает и делает, пробует разное - и ничего не срабатывает. А могли бы давно перейти к другой гипотезе и получить результат. Где та грань, когда нужно остановиться? Думаю, однозначного ответа на этот вопрос нет, но с опытом я пришла к подходу, который позволяет мне обдуманней принимать такие решения: 1. Я документирую все допущения\риски ДО ЗАПУСКА ТЕСТА 2. По каждому продумываю, как мы померяем результат. В идеале это конкретная метрика либо просмотр записей пользовательских сессий 3. Если на этапе обсуждения решения были разные хорошие варианты, я записываю, почему мы выбрали этот вариант, и при каких условиях стоит попробовать другие. И когда приходят результаты теста, я могу конкретно проверить, какие допущения сработали и риски реализовались. И тогда вырисовывается картина: 1. все допущения оправдались, риски не реализовались, но улучшение ключевой метрики нет — значит сама по себе гипотеза проигрышная, нет смысла продолжать 2. есть допущения, которые не сработали, или реализовались риски, и у команды есть хорошие недорогие идеи, как это изменить — можно делать итерацию. 3. ключевые допущения не сработали, но и нет хороших идей, как это изменить — вероятно, пока смысла продолжать нет. С таким подходом и решения принимать проще, и аргументы для команды и стейкхолдеров всегда есть, и после каждого теста остаются lessons learned. Применяйте — только не в голове, а на бумаге — и вы мне скажете спасибо =) #горопека_о_продукте #горопека_техники #горопека_лайфхаки

Как вы понимаете, что у вас крутой руководитель? Ничто так не влияет на вашу карьеру и удовольствие от работы, как ваш непосредственный менеджер. Компания в целом может быть перспективной, и коллеги - адекватные люди. Но если у вас не случилось коннекта с руководителем, вы вряд ли будете расти в навыках и должности. Я уже писала, что на заре перехода в продукт-менеджемент мне повезло с руководителем. Никого лучше до или после я не встречала. И когда я рефлексировала, что именно сделало его таким крутым для меня, у меня родился своего рода чек-лист: 1. Понимание целей своих сотрудников. Если вам кажется, что всем “просто нужно больше денег”, то вы ой как ошибаетесь. Кому-то важен статус и power. Кому-то - миссия и делать добро. Кому-то коллектив и хорошая атмосфера. Кому-то challenge и интересные задачи. Поняв цель сотрудника, намного проще подобрать ему задачи и проекты, где сотрудник раскроется и принесет максимальную пользу как себе, так и компании. 2. Управление целями и ожиданиями сотрудников. То, чем не занимаются 99% менеджеров. Мало понять цели сотрудника, важно сформировать реалистичные ожидания. Особенно, когда ожидания не совпадают с реальностью. Думаю, многие из вас были в позиции сотрудника, которому что-то обещали и кивали головой, заранее понимания, что в этой компании\команде вы не получите желаемое. И вместо того, чтобы честно разговаривать и находить компромисс, менеджер просто откладывает проблему на потом и теряет сотрудника. 3. Адекватная частая обратная связь. Всем очевидно, что фидбек важен. Тысячи статей и постов про то, “как правильно давать фидбек”. Только по факту большинство менеджеров дают обратную связь раз в год, абы-как, и только потому, что “снова HR со своими review process пришли”. А сотрудники не запрашивают фидбек сами и вообще никак не выстраивают отношения со своим менеджером. 4. Выстраивание эффективной рабочей атмосферы. Я терпеть не могу булшита “мы тут все как семья”. Потому что за этим всегда скрывается самодурство начальников, фамильярность, шуточки за 300, непрофессионализм и манипуляции на чувстве вины. Но и другая крайность ничем не лучше. Поэтому мне лучше всего работается с менеджерами, которые требуют от команды результата, но при этом выстраивают атмосферу поддержки и дружелюбия. 5. Умение держать сотрудника в зоне между посредственностью и выгоранием.Не знаю, как вы, а я с особой благодарностью помню тех менеджеров, рядом с которыми я значимо выросла. Но выросла не вопреки, а благодаря. Т.е. когда мне давали задачи на вырост и не давали расслабиться, но при этом поддерживали и помогали разруливать блокеры. Которые заставляли меня расти, но при этом не давали скатиться в выгорание. А как вы понимаете, что у вас крутой руководитель? Что для вас важно? Как вы проверяете это на этапах собеседования? #горопека_о_карьере

Как руководить, когда ты метр с кепкой 😂 Я - дружелюбный человек. Улыбаюсь, шучу шутки, искренне хвалю, поддерживаю в сложных ситуациях. И это не хитро-продуманная маска. Я такая в жизни, с друзьями и близкими, такая же и на работе с коллегами. Еще я женщина 158 см роста с высоким голосом, работающая преимущественно в мужских командах, где проявление даже уместных эмоций воспринимается с "умилением". При этом я работаю на senior позиции, где, не являясь формально начальником никому, нужно лидить команду и добиваться бизнес-результатов. Что сопряжено со спорами, конфликтными ситуациями и необходимостью завоевывать авторитет. Как с этим справляться, не изменяя себе? 1. Цифры и факты. Я не могу позволить себе “стукнуть по столу” и просто сказать, что будем делать так, и все так будут делать из условного страха или нежелания связываться. Но зато у меня всегда есть цифры и факты. Любое свое решение я могу обосновать и объяснить. При это я всегда внимательно, не для галочки, выслушиваю обратную связь, и обрабатываю её. Команда чувствует себя вовлеченной, а я использую силу коллективного мозга. 2. Умение держать границы. Я не терплю того, что не должна терпеть. Если мне не нравятся какие-то шутки или комментарии в мой адрес - я не смеюсь и прошу так больше не шутить. Если мне кажется, что со мною разговаривают снисходительным тоном - то я спрошу напрямую, откуда вдруг снисхождение. Если меня перебивают - я не даю себя перебить. Быть дружелюбным человеком не означает терпеть то, что терпеть не стоит. Здесь важно не скатываться в эмоции, а давать отпор вежливо, но твердо. 3. Контраст. Ничто не отрезвляет больше, чем когда обычно "няшный" человек вдруг задает острые вопросы - вежливо, по делу и без шуток. И это работает именно потому, что я не играю что-то специально. Как я искренне радуюсь и хвалю, когда всё хорошо, точно так же искренне я разбираюсь в проблеме, когда она есть. Так что если шуток нет, значит сейчас не до шуток - сигнал считывается моментально. 4. Признание своих ошибок. Никто этого не любит, я не исключение. Но если я причина проблемы, то я это признаю и исправляю. Без излишнего самобичевания, а по фактам: “да, тут я недосмотрела, такие выводы сделала, так изменю работу в дальнейшем”. Когда ты сам себя так ведешь, команда понимает, что главное не никогда не лажать (все мы лажаем), а вовремя исправлять и учиться на своих ошибках. 5. Искренняя забота о команде. В хорошие отношения нужно много инвестировать, чтобы в кризисной ситуации накопленный баланс доверия помогал справляться. Хвалить по делу; проактивно давать положительную связь “ресурсным” менеджерам, чтобы коллега рос в грейде; отмечать успехи; благодарить за помощь и помогать самой; отправить болеть, когда норовят с 38 всё равно работать, ведь послезавтра релиз. Тогда любые конфликтные или сложные моменты переживаются легче, потому что на балансе доверия не зеро. Ну и будем честны друг с другом - принципы выше работают в изначально адекватной рабочей культуре. Если ваш начальник самодур, команда подобрана по принципу друг-брат-сват и т.п., то всё написанное конечно не сработает. #горопека_о_карьере #горопека_о_развитии

#пятничныезаметки От компании к компании, от продакта к продакту одна из основных жалоб - мало времени, много задач, постоянная смена контекста. Отсюда вывод: способность не стрессовать от того, что тебе нужно решать стопятьсот задач одновременно — важный “навык” продакта. Пример моей текущей загрузки: 1. 2 большие задачи в дисковери и проработке бизнес-кейса 2. Подготовка к OKR в Q3 3. 7 эпиков в деливери \ АБ тест процессе, с постоянными уточнениями по требованиям, анализом тестов, просмотров пользовательских сессий в fullstory 4. Участие в agile ритуалах двух команд разработки 5. Онбординг нового продакта При таком разнообразии задач на разных стадиях я вынуждена часто менять контекст, быстро въезжать в вопросы в 10+ тредах, ходить на кучу митов и при этом находить время на сфокусированную работу. Да, есть практики, которые делают работу проще и легче (а многих писала выше в канале). Да, наверное есть компании, где процессы налажены по-другому, и продакт более сфокусирован и имеет пустой календарь. Но если вы думаете о работе продакта, я бы советовала принять как базовую реальность формат работы, в котором нужно решать стопятьсот задач одновременно. И если настоящий кайф от работы вы ловите тогда, когда глубоко и полноценно закапываетесь в одну задачу, у вас мало митов и много времени на подумать — возможно, в роли продакта вы будете несчастны. И наоборот - если вы боги мультизадачности и ловите кайф от разнообразия задач и вопросов, то переход в продакты может быть неплохой идеей.