Как задавать тупые вопросы

Тупые вопросы нужно задавать, потому что они экономят деньги заказчика и время команды. Вы, как бизнес-аналитики, должны понимать, что цена ошибки в требованиях НАМНОГО выше, чем бага в работе системы. Особенно дорого обходится неправильное понимание бизнес-целей и потребности заказчика. Ибо тогда неправильно понятые бизнес-цели трассируются дальше на пользовательские и функциональные требования, и привет - никому не нужная система.

Но у любой стороны есть 2 медали. Системное мышление - это hard skill аналитика. Поэтому заказчик правильно ожидает, что платя за бизнес-аналитика, основная масса вопросов будет очень даже умными и "экспертными".

Поэтому давайте разберемся в ключевых правилах задавания тупых вопросов.

1. Не надо решать проблему вашей неподготовленности шквалом тупых вопросов.

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

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

Заказчики бывают разными. Не все понимают, что аналитик не проработал те же 30 лет в сфере. Соответственно, у такого заказчика толерантность к любому "тупому" вопросу нулевая.
Что же делать? Я в таких ситуациях перестаю задавать вопросы, а воодушевляю заказчика больше говорить, чтобы как можно лучше погрузиться в его контекст. И тогда вы или услышите ответы на ваши вопросы, не задавая их; или осознаете, что вопросы ваши действительно "не в кассу"; или поймете, как их можно перефразировать и задать по-другому.

3. Используйте разные формы задать тупой вопрос

В комментариях коллега написала, что всегда добавляет "извините, возможно тупой вопрос, но..". Согласна, это любимый прием всех аналитиков. Главное, не перебарщиваете, берегите козырь для ДЕЙСТВИТЕЛЬНО тупых вопросов 😁
Еще хорошо работает прием пересказа. Вы слушаете, записываете, а потом говорите "правильно ли я понимаю, что…" - и выдаете вашу логическую цепочку. Тогда у заказчика есть возможность поправить конкретные звенья в вашей цепочке. И вы как бы не тупой вопрос задали, вы вон логическую цепь выстроили!

Итого: хороший аналитик не стесняется задавать тупые вопросы. Потому что он 1) хорошо понимает цену не заданного вопроса 2) умеет спросить, не тратя время и нервы заказчиков.

#горопека_лайфхаки

Как проверять свои требования

Я писала выше, что вопрос "Как вы проверяете, что ваши требования действительно полные/проработанные и готовы идти в разработку? " многих аналитиков ставит в тупик.

После варианта "я просто знаю" следующий по популярности - вспомнить про тестировщиков. "Я скидываю нашим тестировщиком, и они вычитывают". Я за любые peer review: коллегами БА, тестировщиками, разработчиками, whoever. Но я надеюсь, вы же не скидываете полуготовые требования на вычитку, снимая с себя ответственность? Вы же просите проверить требования, в качестве которых сами уверены?

Далее некоторые вспоминают про прототипирование и моделирование. Действительно, визуализация требований - действенный метод проверки на пропуски и противоречивость. Если у меня есть сущность с жизненным циклом - обязательно рисую State Machine Diagram. Если сложный БП - диаграмму процессов. И в довесок еще набор прототипов с обозначением основных функций и user journeys. А вообще - хотя бы таблицы и нумерованные списки используйте )))

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

Когда применять: на проектах, где много взаимозависимых функций и сущностей.

Что делать:
1. Составить чек-лист проверки новых требований
2. КАЖДУЮ СТОРЮ проверять согласно чеклисту. КАЖДУЮ.

Секрет: действительно применять. Не просто составить чек-лист, и забыть про него. Не думать "я и так его помню, не буду открывать". А прям открываете чек-лист на одном экране, сторю на другом - и по каждому пункту в чек-листе думаете, сторя затрагивает данную функциональность? у меня продуманы edge cases?
После каждого найденного пропуска в требованиях - дополнять чек-лист соответствующим пунктом.

Попробуйте применить эту очевидную технику и поделитесь фидбеком - помогло уменьшить пропуски?
#горопека_лайфхаки #горопека_техники

Навык фасилитации. Подготовка

Важный навык для БА, правда? А как он проявляется на практике? Не понимая, что подразумевает под собою навык, невозможно его и прокачать.

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

Поскольку кирпичей оказалось на приличный самосвал, разделим тему на части Подготовка и Проведение.

Итак, подготовка.

Это ваш фундамент и защита от провала. Если поведение людей при обсуждении контролировать сложно (но можно), то подготовиться - точно полностью в вашей власти.
Подготовка включает в себя:

1. Определить цель.
Довольно очевидный пункт, но давайте кратенько по самому важному.

Во-первых, цель нужно объяснить в начале встрече. И записать большими буквами на видном месте.
Во-вторых, часто цель нужно не только объяснить, но и продать. Дайте коллегам контекст, откуда цель взялась? Почему это для нас важно? Это значимо влияет на качество обсуждения.

Примеры целей:
○ Есть идея провести А/B тест, валидирующий такую-то гипотезу. Мы должны определить технический подход к реализации теста.
○ Скоро релиз большой фичи. Мы должны определить rollout plan.
○ По итогам последнего user research мы знаем, что 4 из 5 пользователей сталкиваются с такой-то проблемой. Цель встречи - брейншторм, как мы можем улучшить пользовательский опыт и убрать данную проблему.

2. Продумать план/агенду совещания.

Если вы проводите backlog refinement, то агенда проста: набор сторей, которые нужно зарефайнить.
Но если вы проводите брейншторм, или сессию по выработке того же rollout plan - вам нужно подумать над планом проведения. Каким именно путем за условный 1 час встречи вы придете к цели?

Например, если это брейншторм по решению проблем пользователей, то план может быть следующим:
1) объяснение проблемы с цитатами пользователей и видео момента, где пользователи сталкиваются с проблемой
2) примеры, как похожая проблема решается в других приложениях
3) важные технические ограничения
4) брейшторм идей
5) голосование участников за лучшие идеи.
6) next steps по итогам брейншторма

Качество ваших митов КРАТНО улучшиться, если вы будете продумывать ход встречи заранее.

3. Определить состав участников

Определив цель и план совещания, довольно легко понять, сколько и какого народа нужно приглашать. Основные моменты:
1) Чем больше народу, тем сложнее проводить встречу. Не приглашайте коллегу, если не уверены, что он необходим для принятия решения. Это будет и уважением к коллеге - адекватные люди терпеть не могу присутствовать на митах, где они не нужны

2) Если сомневаетесь, будет ли коллеге интересно\важно поучаствовать - спросите!

3) Если у вас есть стейкхолдер control freak, и его аппрув вам необходим - приглашайте на совещание. Банальная психология - принимал участие в выработке решения, странно его не аппрувить потом.

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

Зависит от цели и агенды. Если это backlog refinement - может быть достаточно открыть сторю в jira/wiki, и походу встречи уточнять требования, создавать таски и т.д.

Если брейншторм из примера выше - то явно нужно подготовить miro доску: добавить исходные данные, создать фреймы, стикеры и объекты для визуализации идей, продумать способ голосования за лучшие идеи (dot-voting? встроенная фича Miro)?

Встреча в оффлайне? Убедитесь, что есть доска, фломастеры, стикеры, бумага (виски, закуска 😅).

Ну вот и подготовились. В следующей части пойдем проводить!
#горопека_лайфхаки #горопека_техники

Навык фасилитации. Проведение.

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

Теперь про приемы\навыки, которые помогут вам модерировать обсуждение.

1. Установите базовые правила проведения.

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

2. Визуализация в процессе

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

Вот разработчики обсуждают, какая должна быть архитектура для нового модуля системы. Один говорит: "давайте одна lambda function будет забирать данные из базы, преобразовывать их и отдавать на фронт". Пока он говорит, вы рисуете базу данных, lambda function и фронт. Второй возражает "слишком жирно будет одной lambda function и преобразовывать, и отдавать на фронт. Давайте сделаем 2 lambda functions". Вы берете маркер другого цвета и дорисовываете вторую lamda function со знаком вопроса. И спрашиваете третьего разработчика "Вася, а ты что думаешь"? Даже если Вася отвлекся, или недослушал, он посмотрел на доску - и понял, в чем вопрос.

А если вы нарисовали не то, что хотел донести участник, у него есть возможность моментально это увидеть и поправить. До того, как начнется обсуждения идеи, которую он сам не считает верной.

А в конце встречи вы можете сфотографировать доску - и вот митинг ноутс практически и написаны.

И это, с вами говорит человек, который рисовать умеет только картинки по номерам😅 Не важно, насколько ровные прямоугольники и круги вы можете рисовать. Важно, чтобы ваш визуальный язык был консистентным и понятным, а не красивым.

3. Слышать ВСЕ аргументы

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

Когда я модерирую обсуждения, я ВСЕГДА заставляю участников подумать, почему наше решение может не сработать. Какие риски мы видим? Есть ли потенциал для улучшения? Критические вопросы помогают из хорошего решения вытесать идеальное.

4. Уметь вовлечь каждого члена команды.

Пересекается с предыдущем пунктом, но немного о другом. Если вы хорошо готовились ко встрече, то в комнате нет людей, мнение которых по вопросу не важно. Ваша задача убедиться, что все участники "купили" решение группы и не будут его потом тихой сапой саботировать. Так что важно всех тихонь периодически встряхивать и проверять - они молчат, потому что со всем согласны?

Также не забывайте, что многие люди стесняются выражать свое мнение. Иногда им надо "разрешить" или подтолкнуть, например: "Вася, а что ты думаешь"? "Вася, мне кажется, или я вижу сомнения в твоих глазах?" "Вася, в прошлый раз ты высказал очень дельные мысли, что думаешь теперь?"

#горопека_лайфхаки #горопека_техники

5. Постоянно фокусировать на теме

Думаю, очевидно, почему это нужно делать. Не очевидно только, как )) Потому что перебивать людей сложно, а некоторые еще и обижаться могут.
Но такова нелегкая судьба модератора.

Если я вижу, что коллега ушел от темы, я даю ему договорить до точки, и потом вмешиваюсь с фразой "Это очень интересный пойнт, но давайте его пока запаркуем, потому что мы еще не разобрались с основным вопросом".

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

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

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

Пожалуй, это основные пойнты. Делитесь в комментариях, какие приемы\навыки помогают вам в фасилитации?

#горопека_лайфхаки #горопека_техники

Как быть успешным джуном

Джуном (без опыта работы) быть не просто. Конкурс на место зашкаливает, жесткое сито в виде курсы - неоплачиваемая стажировка - плохо оплачиваемый испытательный срок (ИС). Поэтому вдвойне обидно, когда по итогам ИС контракт не продлевают.

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

1. Узнайте критерии прохождения ИС

Да, вам не привиделось, я и тут про бизнес-требования 😄 Очевидно же, что вы не можете осознанно работать на достижение цели, если не знаете, а как её достижение будут измерять. А измерять могут по-разному, потому что план прохождения ИС может быть очень разным.

Где-то джуна поставят сразу на проект под присмотр лид-БА. И критерии будут (например) 1) хорошо разобрался в функциональности такого-то модуля 2) ревью требований не выявляет критичных пропусков и несоответствий 3) ходит на миты с Заказчиком под присмотром лид-БА, но вопросы задает сам.

Где-то джун весь ИС будет выполнять тестовые задания. И тогда критерии будут (например) 1) прогресс по выполнению тестовых заданий. 2) Последние 2 задания выполнены не ниже чем на 8 баллов.

Оффтоп: когда я проходила стажировку на тестировщика, я выполнила первое тестовое задание на 3 из 10. Думала, что меня тут же выгонят, но нет. Оценка по следующему заданию была 5. Потом - 7, и в конце - 8. И когда мне предлагали переходить на ИС, формулировка была ты показала хороший прогресс за 2 недели, а это главное, на что мы смотрим. И они не врали. У нас в группе был парень, который сделал ВСЕ задания на 6 (т.е. средняя оценка по курсу у него даже лучше), но он не прошел на ИС.

2. Не повторяйте ошибок, которые вы уже сделали.

Адекватный ментор не ждет от вас, что вы не будете делать ошибок, вы же джун.

Но от вас точно ожидают следующего: вы обучаемы и не наступите на те же грабли дважды. Потому что если вы не делаете выводы, не обучаетесь - смысл в вас дальше инвестировать время? Вы не можете дать гарантию, что затащите новую и сложную задачу (потому что вы джун), но вы также не доказываете гипотезу, что сможете качественно выполнить задачи, с которыми уже сталкивались. В чем профит тогда в вас для компании?

Я понимаю, что проще сказать, чем сделать. Но сфокусируйтесь на этом. Впитывайте каждую обратную связь. Осознанно проверяйте себя: в прошлый раз мне сделали такие замечания, я их учел в этом задании?

3. Не стесняйтесь задавать вопросы. Просто делайте это по-умному.

Вашему ментору платят за то, чтобы он отвечал на все ваши вопросы (а если не платят - его проблема). Кроме того – никого не интересует, что вы «думали об этом, но постеснялись спросить». Всегда лучше спросить, даже если вопрос кажется очень глупым, чем не спросить.

Другое дело, что в ваших же интересах освоить навык “задавать вопросы по-умному”:

а) Сначала задавайте вопрос гуглу. Всё, что гуглится за 15 мин - не достойно быть заданным

б) Группируйте вопросы. Лучше отвлечь человека 2 раза по 15 мин, чем 10 раз по 3 минуты. Исключения - вопросы блокеры: когда без ответа на вопрос вы никак не можете продвигаться в выполнении задачи

в) Приходите с вариантами ответов. Хороший ментор на многие вопросы будет задавать вам встречный вопрос - а ты как думаешь? Потому что ментор хочет научить вас решать вопросы самостоятельно. Поэтому если вы придете с вопросом в формате "Как поступить в ситуации Х? Я думаю, можно вот так, но сомневаюсь потому что... Еще я думал, что можно сделать так, но как же тогда ....", получите +100 в карму.

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

Время на подумать.
#пятничныезаметки #горопека_лайфхаки

Среди всех этих “а что мне брать следующей задачей?”, “ой, у нас там что-то на проде отвалилось”, “у меня есть идея супер-полезной фичи” легко забыть, зачем мы вообще работаем.

Я уверена, что наша работа - максимизировать value, причиняемое пользователям.

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

Вот то-то же.

И если вы думаете, что это проблема только в аутсорсе, то нет. В продукте основная боль продукт-менеджера - это найти время на качественное “подумать”. И если вы сами не организуете себе это время - оно у вас никогда не появится.

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

Надеюсь, услышу от вас “спасибо” через пару недель =)

Метод приоритизации RICE

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

На мой взгляд, главное условие для успешного применения RICE следующее:

Убедитесь, что все члены команды понимают каждую букву одинаково.

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

Какие определения использую я:

Reach - на какой процент пользователей решение повлияет значимо?

Часто можно увидеть что reach оценивается как процент пользователей, которые “увидят” решение. Т.е. если у нас есть воронка из 5ти шагов, тогда решения на первом шаге воронки имеют reach 100%, а на последнем - условно 20%.

Мне такой подход кажется неправильным по нескольким причинам:

1. Не всем пользователям нужно решение. Например, вы работаете над сервисом доставки продуктов с рецептами (типо rebox.by). Вы знаете, что только 30% вашей аудитории являются вегетарианцами. Соответственно, даже если вы на первой странице воронки регистрации добавите информацию про доступность вегетарианского меню, reach не может быть 100%, потому что большинству пользователей не нужно вегетарианское меню.
2. Каждая потребность в разной степени удовлетворена. Например, вы знаете, что для ваших пользователей очень важно разнообразие и большой выбор рецептов. Но вы уже говорите и подчеркиваете это 5ю разными способами в разных местах воронки регистрации. Думаю, добавление 6го способа подчеркнуть разнообразие вашего меню повлияет на небольшой процент пользователей (потому вы уже громко и ясно об этом говорите).

Impact - какой положительный эффект мы получим, если внедрим решение?

Очень часто команды не чувствуют разницу между reach и impact. А она важна. Возьмем пример с вегетарианским меню - oxват только 30%, но зато потребность может настолько болеть, что impact будет 9 из 10. При этом у вас есть потребность, бОльшая по охвату (скажем - 70%), но вы понимаете, что она не настолько “болит”, соответветственно оцениваете impact на 2 из 10. Получается, вегетарианское меню выигрывает (если судить по этим двум критериям)

Confidence - насколько мы уверены в своих оценках reach и impact.

Как “объективно” оценивать уверенность? Я использую только три оценки (50, 80 и 100) по следующей схеме:

1. 100 - есть много данных (и количественных, и качественных), подтверждающих оценку; успешные эксперименты в прошлом; common sense или стандартные лайфаки(условно если мы снизим цену, или предложим большую скидку, то точно положительно повлияем на процент регистраций)
2. 80 - данных не так много; данные только косвенные; только качественные или только количественные
3. 50 - по сути нет никаких данных, все оценки основаны исключительно на допущениях

Efforts - насколько сложно \ долго реализовать решение.

У меня есть еще парочку практических советов по применению этого метода приоритизации, вам будет интересно?
#горопека_техники #горопека_лайфхаки

Метод приоритизации RICE. Продолжение.

Итак, еще пару советов по применению RICE фреймворка. Начало было положено здесь

1. Обязательно записывайте данные и допущения, которые вы делали при оценке.

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

Поэтому при приоритизации я всегда записываю данные и допущения, сделанные при оценке. Тогда команде проще обсуждать приоритеты, потому что легче объективно челленджить друг друга: “а помнишь, мы проводили такой-то тест, и он был негативный - поэтому я снизил impact этой фичи”, “последние исследования показывают, что пользователи намного чаще стали жаловаться на Х, поэтому мы должны увеличить оценку Reach для такой фичи”.

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

2. Помните о ловушке “предвзятость подтверждения”

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

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

Я борюсь с этим следующим образом:

1. Когда делаю первый раунд оценки, концентрируюсь последовательно на каждой фиче. Ищу данные для объективной оценки reach, impact, confidence, efforts, записываю все сделанные допущения. Я даже не считаю итоговую оценку, чтобы не было соблазна сравнивать с другими фичами и подгонять цифры.
2. Только после этого я считаю итоговую оценку и сравниваю результаты. И если мне кажется, что какая-то фича выбивается - я еще раз проверяю данные и допущения. Либо я что-то не учла (тогда что?), либо я должна принять объективные цифры. Иначе зачем тогда всё это было затевать?
3. Привлекаю еще кого-то к приоритизации. Каждый делает оценку отдельно, и дальше сравниваем и обсуждаем результаты.

3. Как интерпретировать данные

Понятно, что фичи с высоким reach / impact и confidence и низким effort - главные претенденты на попадание в ближайшие планы.

Но не забывайте о идеях с высоким reach / impact, но низким confidence. Эти идеи - главные претенденты на дальнейшее исследование. Каких данных не хватает, чтобы повысить confidence? Как дешево можно протестировать идеи? Т.е. ваша задача либо убедиться, что у этих идей большой потенциал - и тогда включать в планы по разработке; либо убедиться в обратном - и тогда откорректировать оценку (снизить reach/impact)

Также бывает, что reach/impact/confidence высокие, но effort тоже высокий. Здесь нужно работать с командой разработки. Как можно реализовать эти фичи проще и быстрее? Точно нет никакого элегантного решения, которое займет недели, а не месяцы?

P.S.Кажется, советы получились довольно универсальными, и могут применяться с любыми техниками приоритизации. Да, там могут быть другие параметры для оценки, но советы (особенно 1 и 2) - точно применимы. Главное - применяйте.
#горопека_техники #горопека_лайфхаки

Как справляться со страхом ответственности

Без навыка брать на себя ответственность за результат хорошую карьеру не построишь. Но многие объективно сильные профессионалы бояться ответственности.

Я не психолог, не коуч, даже не нахожусь в терапии. Но именно поэтому я хочу поднять эту тему с вами, такими же простыми смертными. Поделиться своими мыслями и советами, а главное - послушать ваши.

Объективный взгляд на свои навыки.
Любую роль мечты можно разложить на набор твердых и мягких навыков. И если у меня есть большинство навыков на хорошем уровне - значит я должна справиться. Поэтому дело за малым (ха-ха) - объективно оценить уровень своих навыков.

Мои лайфхаки тут такие:

1. спрашивать фидбек у людей, которых я сама считаю крутыми в каком-то навыке. Если я хочу приоритизировать как Вася - я попрошу оценить именно Васю именно навык приоритизации. При этом мне может не нравится, как Вася общается с разработчиками - соответственно об этом я и спрашивать не буду
2. спрашивать фидбек по горячим следам. Провела сессию фасилитации - сразу после спросила участников о фидбеке. Провела мит со сложным заказчиком - сразу после спросила коллегу, как я справилась и что можно было сделать лучше.
3. задавать конкретные вопросы. Т.е. не “дай фидбек на мою работу”, а “как я справилась с выявлением и описанием Х? можно ли было сделать это быстрее \ лучше \ понятнее”.
4. активно спрашивать самой, что можно было бы улучшить, и не обижаться на сказанное. Коллеги часто бояться обидеть негативной обратной связью. Но если вы сами напроситесь, а потом действительно не обидитесь - то обратная связь будет становится всё честнее и полезней.

Брать ответственность понемногу.
Сила малых шагов, чтобы не пугать свою психику. Вы начинающий БА, работающий в паре с лидом. Вызоветесь провести один рефайнемент самостоятельно (но с поддержкой лида). Попросите фидбек - учтите его - проведите следующий. Repeat. Через пару месяцев вдруг понимаешь, что проведение рефайнемента - уже плевое дело.

Тщательно готовиться
Хорошо помню, как я впервые перешла проект с англоговорящим заказчиком. Мне было дико страшно не справиться. Перед каждым созвоном я за полчаса уходила в переговорку, тренировала вопросы, продумывала возможные ответы, выписывала английские слова, которых мне не хватало в моих виртуальных разговорах. Это давало мне ощущение “я сделала всё что могла, чтобы не облажаться”. Через полгода мой английский улучшился, стресс ушел, а рост в зарплате и больший выбор интересных проектов остался со мной.

Превратите свой страх ответственности в силу
Я впервые готовлю стратегию развития продукта на ближайшие полгода. Я подхожу ответственно, по каждому элементу могу объяснить, на основании чего я сделала такой вывод. Но конечно же у меня есть и много сомнений в своих решениях - я ведь делаю это в первый раз!

И вот здесь, как мне кажется, есть 2 стратегии: 1) несмотря на сомнения, излучать глубочайшую уверенность, ведь я же продакт, это моя работа - определять стратегию 2) открыто и честно обсудить свои стратегию с лидом - на чем она основана; в чем я более-менее уверена, а где сомневаюсь; в чем вижу наибольшие риски и как планирую их митигировать.

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

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

Теперь ваша очередь - что помогает вам?
#горопека_лайфхаки #горопека_о_карьере

Сила говорить “Я подумаю”

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

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

На меня такой фидбек был, дословно: As X pointed out, sometimes you might have an “immediate negative reaction to hearing that there are new potential priorities on the horizon e.g. the idea 1, the idea 2”.

Конечно у меня немедленная негативная реакция, когда стейкхолдеры сначала согласуют цели на квартал, а потом они же приходят в середине квартала с идеями, напрямую влияющими на роудмап!

Но после фидбека выше, я осознанно стала менять свое поведение на следующее:

1. Выяснить как можно больше деталей. Почему стейкхолдер считает, что это хорошая идея? Какую ценность она несет (желательно в метриках \ деньгах)? Возможно, уже даже есть конкретные идеи по имплементации?
2. Понять, как новая идея встраивается в текущий роудмап. Сравнить ценность новой идеи с текущими инициативами в роудмапе (только на свежую голову, после первоначальной реакции “как они меня задолбали со своими изменениями” 😅). Идея требует проработки и исследования перед реализацией, или нет? Прикинуть затраты инженеров. После этого у вас получится один из следующих сценариев:
а) [Ценность новой идеи высокая] Можем взять в этот квартал, с низким риском для других инициатив (при этом прописать допущения, с которыми вы делали оценку)
b) [Ценность новой идеи высокая] Мы не можем взять в этот квартал без исключения какой-то другой инициативы. Исходя из первых допущений, понадобиться столько-то времени на реализацию. Исходя из ценности и других факторов - предлагаю заменить такую-то инициативу на новую идею
c) [Ценность новой идеи низкая] Крутая идея, но не такая ценная, как другие, потому что… . Предлагаю положить в бэклог и обсудить при планировании следующего квартала.
3. Объяснить и согласовать решение. Написать вежливое, короткое и основанное на данных письмо. Подумать хорошо, каких стейкхолдеров включить, чтобы не решать потом проблему “а почему вот это было сделано без моего согласия”.

Таким подходом вы

1) убираете субъективность из оценки идей, потому что оперируете фактами и цифрами, делая процесс принятия решения прозрачным и понятным

2) обеспечиваете работу команды над самыми ценными возможностями вместо того, чтобы держаться за продуманный вначале квартала роудмап просто потому что “ну вы же сами согласовали”.

3) обеспечиваете себе хороший фидбек 😄

А вы пользуетесь чит-кодом “I will think about it and get back to you shortly?” =)
#горопека_лайфхаки #горопека_техники

Управляйте вашим временем

Один из важных навыков, которые помогают мне в работе - это осознанное управление своим рабочим календарем.

Давайте возьмем усредненный пример для бизнес-аналитика - ваш проект работает по Scrum методологии, т.е. у вас есть набор обязательных митов и понятные дедлайны по подготовке требований. Также вы вписались во внутреннюю инициативу компании по оптимизации каких-нибудь процессов, которая забирает 4 часа в неделю. А еще вы хотите жить эту жизнь - ходить на спорт утром\вечером, забирать детей с садика, встречаться с друзьями.

Что в таком случае будет “осознанное управление своим рабочим календарем”?

1. Обозначить рабочее и нерабочее время. Особенно, если оно отличается в зависимости от дня недели.

По вторникам вам нужно освобождаться раньше, чтобы доехать вовремя до бассейна (и поэтому вы начинаете раньше)? В среду и пятницу с утра спортзал? В четверг вы ответственны за отвод ребенка на кружок, и никак не можете задержаться? Вам удобней в понедельник поработать 10 часов, чтобы в пятницу работать только 6? А еще время на обед нужно. Всё это влияет на ваш рабочий график.

2. Обозначить в календаре слоты времени на выполнение набора задач.

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

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

1) Вы будете видеть, сколько у вас “свободного” времени НА САМОМ ДЕЛЕ. Ибо то, что у вас нет мита - не значит, что вы не работаете, правильно?

2) Вам не будут ставить миты на время, которое у вас забукано на работу. Потому что календарь - занят

3) Вы не будете забывать о важных задачах. Если сегодня вмешался форс-мажор, и вам пришлось срочно делать что-то другое, вам будет легко перераспределить время, чтобы успеть всё важное. Потому что из календаря понятно, что нужно успеть, а что можно пододвинуть.

Конечно, главное условие успеха - следовать вашему календарю. А не просто календарь раскрасить - и пойти зависать в ютюбе \ возле кофе машины.

3. Управлять своей нагрузкой проактивно

Если вы максимально продуктивны по утрам - ставьте важные задачи на утро. Если вы чувствуете себя выжатым после общения с заказчиками - явно не лучшая идея ставить после общения задачи, требующие фокуса и сил. Если вам нужно вместить еще один мит в календарь - где лучшее время для него, чтобы и время на подготовку было, но и не разрушать текущую рутину? Ну и конечно всегда встраивайте в свое расписание буферы на внеплановую работу.

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

#горопека_лайфхаки

Нещадно визуализируйте

Внезапно родилась рубрика #непрошенныесоветы

Речь и письмо - инструменты прекрасные, но почему-то плохо работающие в делах донесения требований, проработки логики взаимодействия, описания user flow.

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

Поэтому никакие мои обсуждения не обходятся без визуализации на miro-борде. Но только визуализировать нужно правильно. Не написать сказанную мысль на стикере, а визуализировать её через разбиение на элементы и связи между ними.

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

Если мы решили, что отображаем какое-то сообщение 5 раз, при этом 1 раз в сессию, то я нарисую 6 квадратов сессии, пронумерую их, а на шестом поставлю ЖИРНЫЙ КРЕСТ. Потому что иначе сделают 5 отображений сообщений, но в рамках одной сессии (вот только сегодня разгребала такую ошибку, сделанную до моего прихода. И пока я не нарисовала - сути ошибки команда не понимала).

В общем, не переоценивайте свою способность объяснить и описать что-то только через plain текст. И даже не предполагайте, что ваш текст воспримут так, как вы его написали) Рисунки, схемы, диаграммы, мокапы - наше всё.
#горопека_лайфхаки

Думать об бумагу

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

Делала я так не всегда. Но после внедрения практики “думать об бумагу” качество моих решений заметно выросло. Ниже гипотезы, почему это очень круто работает.

Мой мозг способен активно думать ОГРАНИЧЕННОЕ количество мыслей. А анализ комплексной ситуации всегда требует посмотреть на проблему с разных сторон, что значит - подумать много мыслей. Поэтому процесс выглядит как-то так: выгрузила на бумагу то, что думаю на текущий момент → появилось место и энергия на новые мысли → выгружаю следующую партию → повтор. И так до тех пор, пока мысли (или время 😂) не закончатся.

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

Проще переключаться между режимами собираю данные / анализирую данные. Часто “подумать” предполагает последовательное прохождение цикла сбор данных → анализ и синтез → выводы → сбор данных… Например, после интервью пользователей (сбор данных) я группирую обратную связь в повторяющие паттерны (анализ и синтез), потом генерирую и приоритизирую гипотезы (делаю выводы), а потом иду проверять жизнеспособность гипотез на данных (снова сбор). Сложно представить, как такой процесс возможно проделать без выгрузки мыслей на бумагу.

Проще переключаться между ролями генератор / критик идей. Слышали же, наверное, про метод 6 шляп. Я ВСЕГДА одеваю шляпу жесткого критика, т.е. думаю о том “что может пойти не так? почему это может не сработать? какие есть риски?”. Но делаю это только после фазы генерации, потому что качество финальной идеи почти всегда есть функция от количества исходных опций. Поэтому сначала я пишу свои мысли, прихожу к какому-то выводу, а потом перехожу в режим критики. Не представляю, как это всё сделать в голове.

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

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

Для разных типов проблем у меня сложились разные шаблоны, которые помогают “думать об бумагу”. Могу поделиться с вами несколькими, если тема будет интересной
#горопека_лайфхаки #думать_об_бумагу

Практика journaling для рабочих задач

С нового года я внедрила практику довольно подробного описания своего рабочего дня. Уже заметила положительное влияние на свою работу, поэтому решила поделиться с вами.

Зачем я это начала

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

Но поскольку я недавно сменила работу, мой фокус внимания сильно сместился в эту область. В результате, как-то не заметно для меня, подробный journaling перекинулся и на работу

Как выглядит процесс

Начиналось всё просто с описания всех задач, сделанных за день. Но со временем практика трансформировалась в следующий процесс:

1. Инструмент: личный notion
2. Вечер пятницы - утро понедельника: составить список задач на неделю. Примерно раскидать их по дням с учетом загрузки и специфики задачи. Забронировать в календаре слоты для deep work
3. Утро рабочего дня: составить список задач на день из приоритетов недели и результатов прошлого дня.
4. В течение дня: ставить галочки напротив сделанных дел (самое любимое!!) и вносить незапланированные дела. Проставлять затраченное время.

Какие бенефиты я уже заметила

1. Всегда есть, что сказать на дейлике: чем занималась и что планирую делать. Наверное, это возраст😅, но я реально часто забываю, что делала. А не хочется производить впечатление ничего не делающей, тем более когда это правда не так.

2. Выделяется дофаминчик от осознания сделанного дела. Да, я такая: люблю ставить галки, вычеркивать, переводить в done.

3. Есть объективное понимание своего прогресса. Думаю, меня поймут все менеджеры - бывают дни, когда ты весь день работала, а вроде бы ничего и не сделала. А если записывать всё проделанное, то внезапно получается, что ты разруливала блокеры по важным задачам. Или наоборот - действительно занималась неважной ерундой, и нужно улучшить фокус на важном.

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

5. Накапливается объективное понимание своей пропускной способности. Сколько задач в день в тебя “влазит”? Какие типы задач хорошо объединяются, а какие - нет? Сколько времени уходит на написание важных документов, анализ, продумывание, а сколько - на мелкие задачи.

6. Намного легче формулировать достижения для performance review и резюме. Поверьте, вам будет намного проще готовиться к разговорам о зарплате, когда у вас есть конкретные измеримые достижения. И достижения проще формулировать, когда есть лог сделанных задач.

7. Можно проводить личные ретроспективы, внедрять изменения и отслеживать результат. Особенно, если вы умеете быть честными с самим собой.

И последнее. Я долгое время не верила в восторженные отзывы о практике journaling. Пока не призналась себе, что я просто боюсь того, что могу туда написать. Ведь если осознаешь проблему - придется её решать. Так что если у вас тоже сильный скепсис к прочитанному - возможно, вам правда не нужен journaling. А возможно - вы просто не хотите встретиться с реальностью.
#горопека_лайфхаки

Давайте сегодня разберем #вопросподписчика. Публикую с сокращениями.

Часто в рабочей практике сталкиваюсь с проблемой «ухода в детали», чем сильно торможу процесс. Я вроде понимаю, что если не выходит быстро решить вопрос или найти подход, то стоит остановиться и оценить важность этого этапа, спросить себя на что он повлияет и могу ли я идти дальше. Но как правило в моменте это сложно, особенно если проект большой и таких белых пятен очень много (при этом всегда кажется что эти белые пятна и незнание как подступить к вопросу только в моей голове из-за недостатка опыта).
Подскажите, можно ли как-то научиться видеть картину в целом? Не уходить в нюансы и держать в голове суть?

Первое, что хочется сказать - это нормально, что начинающий специалист скатывается в детали, и теряет картину в целом. И очень круто, что вы осознаете это как точку росту.

Второе - такого рода “навыки” развиваются долго, больно, через откаты и наступления на те же самые грабли. Успеха добиваются те, кто упорно не сдается и экспериментирует с разными методами. Так что не ожидайте быстрых результатов, но и не сдавайтесь.

Третье - не думаю, что для таких запросов есть единственно верная метода. Поэтому я расскажу, что помогает мне, но вы должны экспериментировать и рефлексировать сами.

Определите acceptance criteria для задачи, и каждый день сверяйтесь с ними

Введите в привычку для каждой крупной задачи документировать цель и acceptance criteria. Не проговаривать, а документировать. Это поможет ясно сформулировать, лучше запомнить, а главное - убедиться, что вы правильно поняли суть задачи.

Дальше самое главное: каждый день сверяться - вы делаете то, что продвигает вас к цели, или нет? Прям с самого утра, после утренней проверки почты. Нет, “я и так помню” не канает.

Документируйте все возникающие вопросы.

При работе над любой задачей всплывают новые вводные и подзадачи, которые и приводят к “уходу в детали”. Вы не бросаетесь их делать, а создаете раздел “Бэклог”, и документируете всё туда. Так вы решите сразу несколько проблем:

1) боязнь забыть важные нюансы.

2) прозрачность вашей работы - лид будет видеть, какого объема информации вы проработали, пока делали задачу.

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

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

Техника timeboxing

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

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

Я бы в этой ситуации отвела себе 2-4 часа на изучение Google API в целом: структура API; наборы параметров; примеры интеграций (case studies); отзывы, вопросы на Stake Overflow; поговорить с chatGPT😁. Таким образом вы погрузитесь немного в контекст, разберете основные определения и сокращения, увидите примеры использования API, что поможет вам в поиске ответа на конкретный вопрос.

Ключевое здесь - жестко следовать лимиту времени. Дали себе 2 часа - после 2х часов вы прекращаете общее изучение и переходите к конкретному вопросу.

Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_лайфхаки

Думать об бумагу. Шаблоны

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

Когда мне нужно составить роудмап на ближайшие месяцы, я прибегаю к шаблону Факты - Ограничения - Допущения - Выводы. Он помогает мне структурировать большое количество data points по категориям, что наводит порядок в мыслях и облегчает аргументацию своих решений команде и стейкхолдерам.

Факты.
Самое главное здесь - это не приписывать свои или чужие домыслы, как факты. Самый большой drop off в воронке на таком-то шаге - это факт. 75% пользователей в опросе указали причину ухода как плохое соотношение цена\качество - это факт. Пользователи отваливаются на таком-то шаге воронки, потому что считают соотношение цена\качество недостаточным - это не факт, а допущение (как минимум, пока АБ тест, основанный на этой гипотезе, не выиграл).

Обычно фактов очень мало. Общепринято делить факты на количественные и качественные. И важная задача продакта - 1) факты добывать 2) не давать себе и другим записывать допущения как факты. Потому что план, основанный на рандомных данных ведет к рандомным результатам.

Ограничения.
В команде нет бэкенд инженеров. Мы не можем экспериментировать с ценой подписки. Инженеры не хотят работать с этой частью кода, пока не будет сделан рефакторинг. Всё это примеры ограничений.

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

Допущения \ Гипотезы
При работе с допущениями я стараюсь рассматривать продукт с разных сторон:

1) анализ и интерпретация фактов

2) анализ конкурентов

3) анализ трендов рынка и индустрии

4) behaviour science, UX basics, classic marketing / CRO tactics, other learnings.

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

Выводы
1) Какие “слепые” зоны о продукте у нас есть, какие факты нам нужно добыть? Как это можно сделать?

2) Какие допущения нужно тестировать в первую очередь, и почему?

3) Какие ограничения мешают больше всего и как их решать?

Довольно простой и очевидный шаблон. Попробуйте, но обязательно на бумаге, а не в уме. Думаю, у вас появится больше ясности и уверенности в своем роудмапе.
#горопека_лайфхаки #думать_об_бумагу

Структурность в работе

Я писала вам пост про системное мышление, но он не написался. Поэтому я оставлю здесь всего один совет, но зато тот, которым пользуюсь сама на 100%.

Любую проблему или задачу начинайте с составления структуры решения. А лучшие структуры для повторяющихся проблем сохраняйте как чек-листы и шаблоны, чтобы переиспользовать при каждом удобном случае.

Поясню на нескольких примерах.

АБ тест выдает результаты, которые я никак не ожидала. Прежде чем что-либо делать, я составляю структуру возможных проблем. Получаю следующее: 1) баг в бизнес-логике, 2) баг в метриках, которые отправляем, 3) баг в отчете (подвязаны не те метрики) 4) баг в рандомизации \ в эксперимент попадают не те пользователи 5) нет багов, такой результат теста. В результате я могу действовать спокойно и структурно: самое вероятное приоритизировать в первую очередь, часть делегировать (например, баг в бизнес-логике может проверить тестировщик), ключевые моменты проверить сама. А главное, я не решаю вопрос перебором “на удачу”.

Скоро предстоит регулярный health check со стейкхолдерами, к которому нужно подготовить презентацию. Первое, что я делаю - определяю свою цель на эту встречу. Я хочу похвалиться результатами? Получить +2 инженера, ибо мы можем делать больше? Донести, что важный майлстоун Х не будет выполнен так, чтобы не пострадала репутация моей команды? Определив свою цель, я сначала составляю структуру так, чтобы встреча прошла с нужным мне результатом. Только после этого я занимаюсь добавлением контента и оформлением.

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

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

#горопека_лайфхаки

Как не терять рабочие задачи

Я человек, которые ничего не забывает. Если я пообещала, что сделаю - то я:

1) либо сделаю,

2) либо ЗАРАНЕЕ сообщу о срыве дэдлайна, причинах и как собираюсь из этого выбираться

3) либо договорюсь не делать, если вводные поменялись, и задача стала неактуальной.

Моя надежность не раз двигала меня по карьере - менеджеры готовы вкладываться в сотрудника, на которого можно положиться.

Что же мне помогает ничего не забывать?

Я проактивно планирую свое время. Без фанатизма, но дисциплинированно. У меня есть план на квартал → план на месяц → план на неделю → план на день. План на квартал - это максимум 3 цели, которые нужно достичь. План на месяц - это задачи, ведущие к цели. План на неделю вытекает из плана на месяц и разных операционных задачек. Ну и сами догадайтесь, откуда берется план на день.

Я всё записываю. Для мелких задач и вопросов - функция напоминания в slack. Для больших задач, на которые нужно выделить сфокусированное время - букаю слот в календаре, и следую своему календарю. Для идей, что можно сделать - есть список идей, которые потом переходят в планы на неделю\месяц. Ничего не держу в голове, потому что моя голова - не помойка.

Я удаляю задачи, до которых никогда не доберусь. Знаете это гаденькое чувство, когда у тебя есть задачка, которую и хорошо бы сделать, но из недели в неделю на нее не находится время? Я поняла, что такие задачи меня бесят. Ты вроде работаешь, и чего-то добиваешься, но постоянно ощущение, что недостаточно. Поэтому со временем я установила лимит: если задача повторяется 3 недели подряд, я либо сажусь и делаю её, либо удаляю из списка.

Я прям слышу ваши возражения:

1) это слишком задротский подход, а я не задрот

2) столько времени на это уходит - я лучше поработаю.

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

На счет времени - это миф и оправдание, чтобы ничего не делать. Потому что если цели и планы записать, то потом придется их выполнять🙂. А это нужно напрягаться. На практике квартальные цели так или иначе в продуктовых компаниях существуют. Соответственно спланировать их достижение крупными мазками по месяцам - суммарно ну день максимум. Сделать ревью недели и спланировать следующую - 30-60 минут. План на день - минут 10.

Зато в итоге у меня спокойный мозг, ощущение контроля и доверие стейкхолдеров.

#горопека_лайфхаки

АБ тест проиграл. Делать итерацию?

Вы запустили АБ тест. Он проиграл \ не выиграл. Какой вывод из этого делать - не верна гипотеза или решение к ней?

ИМХО, это один из самых злободневных вопросов, который продукт-менеджер должен решать каждый день.

В моей практике есть примеры, когда на вторую-третью итерацию решения мы получали супер-выигрышный тест. Но также есть и примеры, когда команда всё делает и делает, пробует разное - и ничего не срабатывает. А могли бы давно перейти к другой гипотезе и получить результат. Где та грань, когда нужно остановиться?

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

1. Я документирую все допущения\риски ДО ЗАПУСКА ТЕСТА
2. По каждому продумываю, как мы померяем результат. В идеале это конкретная метрика либо просмотр записей пользовательских сессий
3. Если на этапе обсуждения решения были разные хорошие варианты, я записываю, почему мы выбрали этот вариант, и при каких условиях стоит попробовать другие.

И когда приходят результаты теста, я могу конкретно проверить, какие допущения сработали и риски реализовались. И тогда вырисовывается картина:

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

С таким подходом и решения принимать проще, и аргументы для команды и стейкхолдеров всегда есть, и после каждого теста остаются lessons learned.

Применяйте — только не в голове, а на бумаге — и вы мне скажете спасибо =)

#горопека_о_продукте #горопека_техники #горопека_лайфхаки