Синдром самозванца в ИТ

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

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

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

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

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

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

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

👨‍👨‍👧 Детские травмы
Родители нам хотят добра. Поэтому всегда ждут от нас максимальных результатов и чтобы мы были лучшей версией себя. Поэтому, любя, дают нам только негативный фидбек, за который мы цепляемся. И каждый раз чувствуем, что все, что мы делаем - это недостаточно круто для них.

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

Я вернулась с регаты и записалась к новому психотерапевту. И я буду писать про психологическое здоровье в ИТ, потому что вижу, как это важно. И чтобы мы знали, что мы не одни ❤️

Почему всегда болит тестирование?!

В первый день моего отпуска я летела на самолёте в Грецию. По прилёту мой Slack просто взорвался. Оказалось, что за эти 4 часа наш продуктивный стенд не выдержал нагрузки и упал. Упал в самый жаркий период использования нашего продукта.

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

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

🙈 Значит ли это, что мы все плохо работаем? По большей части нет. Только что, что мы недостаточно хорошо выстраиваем процесс тестирования.

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

На моем прошлом продукте тестирование (даже функциональное) болело так сильно, что нас физически трясло. Оно было как кот Шредингера: вроде тестировщики и есть, а баги не находятся и не закрываются😂.
И поняли мы это только когда у нас завершился рефакторинг, и в системе оказалось 300+ багов, которые никто не находил, а если и находил, то не логировал или логировал неправильно.

Пример: Блокирующий баг в джире: "В карте KPI у HRа не хватает кнопки Согласовать". 🤯
В смысле?! Это все? На каком стенде ты это проверял? Под каким пользователем нашел ошибку? На каком этапе была карта? У какого пользователя? В каком браузере? Какие были твои шаги перед тем, как ты нашел ошибку? Где скрин? Панель разработчика открывал?
И самое главное: а ты вообще уверен, что это ошибка, а не ожидаемое поведение системы? (Спойлер: нет).

Разработчик не понимал, что за баг, воспроизвести по такому описанию не мог, поэтому ставил статус "не воспроизводится" и закрывал задачу. А тестировщик потом заводил ее заново 😜.

В целом это история с хэппи эндом. Правда, выстраивать процесс тестирования пришлось техническому писателю, системному аналитику и мне (звучит как начало плохого анекдота. За тем исключением, что мы в бар не заходили, а пошли ботать в выходные на Яндекс.Практикум).

Почему мы? Я искренне считаю, что за процесс тестирования отвечает в том числе продакт. Да, с помощью тимлида, но кому аутнется, когда в продукте будет 300 багов? У кого из-за этого упадут метрики?

Через боль и страдания мы пришли к конкретному описанию багов в джире.

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

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

Экономика, которая не сойдется никогда

😭 К сожалению, на большинстве внутренних HR продуктов очень плохая экономика.

У меня в практике был такой кейс: компания ежегодно нанимала в районе 600 стажеров и молодых специалистов. На часть таких вакансий (возьмём 60%) обычно очень большая воронка на входе, поэтому для её сужения рекрутеры использовали отсев с помощью тестирования (числовые тесты).
Допустим, мы знаем, что для вывода на работу одного нового сотрудника, нам надо отправить кандидатам 10 тестов.

Как происходит отправка теста? Рекрутер связывается с кандидатом и подтверждает с ним, что тот согласен на условия компании: дата выхода, ЗП, функционал и так далее. И что он сам базово подходит компании по своим знаниям. Потом рекрутер идёт на платформу тестирования и создаёт там учётную запись кандидата. Вводит имя/фамилию, почту. Далее выбирает нужный тест и назначает. После этого рекрутер идёт в почту и пишет кандидату: Вася, тест назначен, как пройдёшь, отпишись (потому что отбивки из системы тестирования не приходили). Вася может отписаться, а может не отписаться. В этом случае наш рекрутер заходит сам в систему тестирования и проверяет, пройдены ли тесты. Если нет, то, спустя Х дней, удаляет данные Васи и отправляет ему отказ.

На такой процесс рекрутер тратит в среднем 7 минут на кандидата. Считаем. 360 ставок, 10 кандидатов на каждую, 7 минут на каждого кандидата. Получаем 420 часов в год.
Ужасная цифра для такого процесса.

Автоматизируем? Давайте. Можем написать шину, которая сынтегрирует платформу рекрутера с системой тестирования. Рекрутеру достаточно будет просто одним кликом переместить кандидата в нужную ячейку в системе, а дальше наша шина сама подхватит кандидата, назначит ему нужные тесты, отправит ссылку на прохождение, а после прохождения уведомит об этом рекрутера и запишет баллы в систему. Если кандидат с тестами не справился или не прошёл их через Х дней, то шина сама это поймёт, передаст данные платформе рекрутера, которая отправит отказ. И в итоге мы простой интеграцией экономим 420 часов в год, которые рекрутер может посвятить более важным задачам.

👏 Ну классно же? Надо делать?!
А теперь давайте посчитаем цифры ещё раз.
В этом процессе мы упрощаем жизнь только рекрутеру. Возьмём среднюю ЗП рекрутера на то время: 65к гросс. Прибавим ещё 30 процентов, так как он в штате (косты за офис, прочие налоги). А потом посчитаем стоимость часа работы рекрутера... и получим примерно 500 рублей.
Соответственно, нашей автоматизацией мы сэкономим компании 210 тысяч рублей в год.
Ну, не миллионы, но тоже неплохо...так?

Не так. Спринт работы собственной команды разработки стоит от 1 до 3 млн рублей. А такой функционал делать 4 спринта минимум (двусторонняя интеграция, формы кандидатов, маски для обезличивания данных, тестирование и исправление багов + настройки на стороне системы рекрутера).

И что же делать? Смириться с тем, что разработка не окупится никогда в жизни? Или сказать на старте, что этот внутренний продукт экономически неэффективный и отказаться от разработки? И пусть бедные рекрутеры страдают?

На самом деле есть несколько вариантов:
1. Купить коробочное решение, если такое есть.
2. Заказать разработку у провайдера.
3. Смириться с тем, что решение не окупится.
4. Отказаться от процесса, который нужно автоматизировать.
5. Отказаться от автоматизации.

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

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

Ужасная экономика внутренних продуктов, часть 2.

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

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

Таким типовым "дорогим" для автоматизации процессом в последние годы стал Position management. А в переводе на русский: штатное расписание и забюджетированные ставки.
Нормального удобного решения на российском рынке действительно нет.

💼 Кейс.
Все компании нанимают людей. Представим, что я нанимающий менеджер (тимлид) с командой в 5 человек. И мне срочно нужен ещё один. Ну вот горят у меня сроки в квартале, я понимаю, что не закрою цели двумя фронтами.

🏃‍♀️ Как я поступаю в таком случае?
Чаще всего я иду в почту к рекрутеру и говорю "Вася, мне нужен ещё один разработчик". Вася стонет от того, что ему прилетела ещё одна вакансия в работу, но спрашивает меня, кто же мне нужен, и берет заявку в работу. Потом он публикует вакансию на job порталах и стандартно по ней работает. Через два месяца я готова сделать оффер фронту.
Вася начинает согласовывать оффер и идёт к тому, кто может согласовать финальные цифры. И - внезапно! - держатель бюджета говорит мне и Васе: ребята, а с чего вы вообще взяли, что можете нанимать фронта? У нас нет такого в бюджете, бизнес необходимость я не вижу. Не подтверждаю.

🤦‍♀️ Как такое вообще могло произойти?
Это реальный кейс и вовсе не единичный случай. Когда нет автоматизации, которая бы митигировала риски, это нужно делать в ручном режиме. Ручным режимом для Васи было бы в момент получения от меня вакансии пойти к держателю бюджета и подтвердить ставку. Но он этого не сделал. Почему? Разные процессы в разных департаментах, доверился, что я сама согласую свой бюджет, забыл, да что угодно.

🚨 Какой процесс надо автоматизировать, чтобы этого избежать?
Управление ставками и бюджетирование. В крупных компаниях бюджет на штатных сотрудников чаще всего составляется один или несколько раз в год, но может пересматриваться. Но я, как пользователь процесса, который вытекает из бюджетирования, не хочу знать нюансов. Я хочу просто подать заявку на нового человека. Система под капотом должна проанализировать, что бюджета нет, и, вместо отправки заявки рекрутеру, она направит мой запрос тем, кто отвечает за выделение незапланированных расходов на персонал.

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

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

🎡 Какие эффекты стоит принимать во внимание?
1. Экономия денег, времени сотрудников, уменьшение time to market основного продукта.
2. Снижение дорогостоящих рисков.
3. Масштабирование процесса и его консистентность. Единый процесс проще поддерживать (- косты на поддержку), проще адаптировать людей (- косты на онбординг).
4. Повышение качества работы.
5. Появление доступной аналитики по процессным метрикам.
6. База для автоматизации массово используемых процессов.

Как материнская травма мешает в менеджменте. Часть 1.

📕 Последнюю неделю в перерывах между "болею и умираю" и "фигачу страткейс" провела с книгой Бетани Уэбстер "Обретение внутренней матери". Звучит как какой-то бред, если не прочтёшь надпись внизу книжки: Как проработать материнскую травму и обрести личную силу.

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

💡 Мысль, которую Уэбстер доносит: мы живем в патриархальном обществе, которое исторически говорило женщинам подавлять свои эмоции. Поэтому это то, что передается детям любого пола через матерей из поколение в поколение. Мысль "Не высовывайся, не добивайся успеха". При этом мы, когда вырастаем, передаем эти установки нашим детям, т.к не успели сами проработать свои материнские травмы. И надо не винить во всем родителей, надо принять на себя ответственность за свою жизнь и бежать на терапию.
А дальше идут мои мысли, в которых много интерпретаций. На страх и риск😉

Как материнская травма мешает в карьере?

🗣 1. Нас учили быть "хорошими" и наказывали, когда мы ими не были. В нас отложилась эта установка, поэтому мы работаем на убой и скрываем свои истинные эмоции от этого (часто даже от себя самих).

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

👥 3. Мы бессознательно ожидали, что родители инициируют процесс сепарации сами. Из-за этого мы часто впадаем в порочный паттерн, когда ожидаем, что за нашу сепарацию от руководителя (т.е за наше развитие!) будет нести ответственность кто-то другой. Спойлер: не будет.
При этом процесс сепарации пугал нас до чёртиков, и из-за этого мы просто тормозим в развитии и сидим на одном теплом месте.

🦄 4. И самое жесткое - от этой идеи "не высовывайся" пришли блокеры быть классными лидерами, мыслить по-прорывному и формировать крутые гипотезы. В том числе поэтому, мне кажется, продакты в терапии успешнее тех, которые не в терапии. Они (мы!) слой за слоем снимают свои блокеры и освобождают "истинное я".

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

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

Как материнская травма мешает быть классным менеджером. Часть 2.

Больше всего меня разорвало на том моменте книги, когда Уэбстер описывала, как женщины с непроработанной материнской травмой сами становятся плохими матерями. И я поняла, что частично реализовывалась как мать со своей командой. И мой бог, сколько же я наделала «материнских» ошибок со своим самым первым сотрудником до того, как проработала травму.

🤵‍♀️ Я официально стала менеджером и получила в подчинение команду в 25 лет, став руководителем отдела в «крупной международной компании». К отделу прилагалась команда в три человека, двух из которых нужно было найти.
Первой ко мне вышла очень классная девочка, с которой мы подружились в ту же секунду. Наконец-то мне было, с кем ходить на обеды, обсуждать работу и сидеть вечерами в офисе. Она вела одновременно два жестких проекта с очень строгими дедлайнами и прямо сгорала. Я же думала, что она так много работает потому, что ей по кайфу, мне же по кайфу (а я к тому времени уже три года подряд работала в среднем с 8 до 22 и задавала максимально плохой пример команде). Она работала ночами и выходными, и я ее хватила за это, ведь она была «хорошей».

🚩 Спустя полгода работы она начала подавать мне сигналы, что делает не то, что позволяет ей реализовать ее сильные стороны, что не кайфует. Спустя еще три месяца я вернулась из отпуска, а она была с оффером на руках. Ее схантил фэшн ритейл делать совершенно не такие вещи, какие она делала у нас. Какая нелепица, думала я.
Мы договорились оставаться друзьями даже после ее ухода из компании. Но оказалось, что для меня это невозможно. Во мне настолько была сильна иррациональная обида и чувство «брошенности», что я намеренно 2 месяца не инициировала с ней никаких контактов.

Потом внезапно она появилась на пороге офиса и позвала попить кофе. Она рассказывала о том, как счастлива на новой работе, какие делает классные вещи, как оптимизирует процессы. Что же в ответ сделала я? Я просто обесценила все ее достижения, сказав, что ничего особенно в этом нет. А потом добавила, что вообще-то это мы здесь без нее делаем еще более крутые вещи. (АААААААА 🤦‍♀️)

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

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

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

Ищу продакта к себе в команду🥳

Друзья, в последнее время я недаром так много писала про кейсы автоматизации рекрутмента. Это направление сейчас просто шагами Гулливера развивается у нас в Авито: темпы роста у нас как у компании огромные, а текущий уровень диджитализации процессов не всегда может их поддержать с нужной скоростью и качеством.

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

Итааак. Кого смотрим. В идеале мне нужен миддл с опытом в HR tech или на внутренних продуктах, но при этом готова смотреть из проджектов, только переходящих в продакты, или из аналитиков.

Описание вакансии можно посмотреть на нашем джоб портале, который будет входить в список продуктов в зоне ответственности😏
А вопросы и все резюме кидать мне в личку @Kondrashova_Anastasia.

Продуктовая стратегия на внутреннем продукте

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

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

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

Хорошая продуктовая стратегия опирается на потребности пользователя, рынок и бизнес-цели самого продукта или компании, которая создает этот продукт.
И в этом зарыт краеугольный камень: бизнес-цели самой компании. У меня могут спросить: Настя, как же HR продукт может помочь целям компании? Легко, если есть прозрачная цепь каскадирования стратегии.

Смотрите, у компании есть видение, миссия, стратегия, которая поможет ей добиться целей и в долгосрочной перспективе выиграть у конкурента на каком-то рынке или сегменте пользователей. Но у компании не всегда сразу могут быть на руках все энейблеры реализации этой стратегии. В 99% случаев для реализации стратегии нужно трансформироваться изнутри. И это именно то, с чем помогает HR организация.

Итак, в идеальном мире наш HR директор (будучи С-левелом) принимает участие в разработке стратегии компании и понимает, как ему нужно преобразовать процессы, чтобы эту стратегию реализовать. Например, в 2 раза сократить количество встреч на всех уровнях, вырастить у менеджеров умение принимать самостоятельные решения, внедрить процесс преемственности, чтобы снизить текучку, и быть готовым нанимать в год не N человек, а 3N. Все это должно лечь в основу HR стратегии, а потом каскадироваться в стратегию каждой подфункции HR-a (рекрутмент, обучение и развитие, институт HR бизнес-партнерства и так далее).

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

AvitoTech опубликовали мини-интервью со мной в рамках развития программы менторства💚💜

Как определить стратегические фокусы, чтобы не делать никому не нужную фигню
В прошлый раз мы поговорили о том, что внутреннему продукту тоже нужна стратегия: чтобы быть лучше непрямых конкурентов, и чтобы правильно фокусироваться. Сегодня я расскажу о том, как мы у себя в одном из продуктов Avito People перешли от большого и красивого вижна внутренней функции и внутреннего продукта к конкретным фокусам и действиям (когда продукта практически нет).

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

🦄 Стратегия складывается из больших кусков Where to play и How to win. Первое – это про наш рынок, контекст и пользователей, а второе – про те действия, которые нам нужно предпринять, чтобы быть круче конкурентов. Даже несмотря на то, что мы внутренний продукт, у нас есть непрямые конкуренты. Например, если говорить о конкурентах нашей LMS: люди могут пойти обучаться вовне, могут уйти в другую компанию, где они видят больше возможностей развиваться и расти карьерно, могут вести планы развития не у нас, а в гуглдоках.

Помните пирамиду Product/Market fit? Она как раз включает в себя оба эти больших куска. И, если говорить про пирамиду, то продуктовая стратегия живет в ней на уровне Value Proposition. То есть какую ценность мы должны нести клиенту, чтобы из всех решений выбрал именно нас.

🪄 Чтобы определить ту самую ценность, нам стандартно нужно провалиться на уровень проблема/решение и понять, какие же JTBD сценарии нам нужно автоматизировать. Мы провели исследование (в нашем случае 20-30 глубинок) + изучили рынок. Мы поняли наших пользователей (и чего они хотят), а также наших стейкхолдеров (как Авито нужно развивать людей и процессы для того, чтобы кратно расти) и структурировали в Miro спектр проблем и возможностей, который у нас есть.
Мы даже сделали часть работы по второму шагу: для части наших проблем и возможностей мы определили возможные решения (гипотезы), с помощью которых мы можем сделать мир пользователей лучше.

А дальше начинается самое интересное: как понять, какое Value Proposition нам нужно, чтобы достичь значимого эффекта? И – мой любимый вопрос – как измерить качественный эффект?
Дон Олсен, например, рекомендует все решения болей пользователя оценить по модели Кано и взять в первый релиз все маст-хэвы, несколько фичей базовой производительности и одну или две клевые штуки (именно за счет них идет дифференциация от конкурента). Но мы же внутренний продукт. Как нам понять, где создать вау эффект, на чем нам стоит сфокусироваться в первую очередь?

🎲 Мы со внутренними клиентами провели воркшоп, чтобы обсудить четыре модели приоритизации. Говорили про то, насколько нам походят тот же самый Кано, RICE, MoSCoW и JTBD.
В следующий раз разберу плюсы и минусы каждой методологии для нас и расскажу, почему нам не подошла ни одна.

Как определить стратегические фокусы, чтобы не делать никому не нужную фигню. Часть 2.
Итак, мы определились с тем, что для разработки нашей стратегии нам нужно выделить те решения, которые помогут нам лучше конкурентов закрывать «работы» (проблемы), на которые наши пользователи хотят их нанять. А дальше разобраться с фокусами.

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

Какие у нас были предпосылки?
🏦 Наши решения должны окупаться, поэтому мы не можем не считать эффект.
🚃 Одни бизнес-процессы должны автоматизироваться раньше, чем другие, иначе в другом процессе будет не хватать данных (например, сначала постановка целей, а потом их оценка).
🌓 У нас есть автоматизации для всех пользователей, а есть для профессиональных (HRы). И вторую группу нельзя обижать.

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

RICE
➕ Используется в большом Авито
➕ Принимает в расчет все самое важное
➕ Особенно эффект!
➖ Не подходит для выделения MVP
➖ Никак не учитывает то, что во внутренних продуктах одни эпики должны делаться после других
➖ Вечная боль: как рассчитать эффект, если он качественный
➖ Confidence для меня мусорный критерий
➖ Не подходит для сравнения неоднородных эпиков

MoSCoW
➕ Походит для выделения MVP
➖ Абсолютно непонятно, на основе чего оценивать
➖ Никак не учитывает то, что во внутренних продуктах одни эпики должны делаться после других
➖ И вообще какая-то слишком простая

JTBD (Приоритизация по последовательному выполнению работ)
У нас есть Employee Journey Map (как CJM, только для сотрудников). В нем процессы идут один за другим, то есть нельзя сначала выйти на работу, а потом подписать оффер. Приоритизация по JTBD как раз предлагает нам последовательно решать работы, которые возникают перед пользователем.
➕ Finally учитывает то, что во внутренних продуктах одни эпики должны делаться после других
➖ Не учитывает эффект и все остальное

Что мы выбрали?
Конечно, никакая методология нам не подошла на 100%. Поэтому мы сделали гибрид, и очень им довольны.

🤼‍♂️ Разные команды будут заниматься автоматизацией для пользователей и для HRов: так мы сможем избежать конфликта интересов.
🏌‍♂️ Перед обсуждением эпика (большой боли) будет задаваться дисквалифицирующий вопрос: как его реализация поможет нашей стратегии? Если никак - выкидываем.
🤹 Боли пользователей нам помогло приоритизировать количественное исследование
🧗‍♀️ Приоритизировать другие эпики (большие боли) мы будем по адаптированному RICE: будем также учитывать важность задачи для стейкхолдера.
🏊‍♀️ При этом мы всегда будем оглядываться на последовательность выполнения работ: в каком случае нам стоит изменить приоритеты и решить сначала предыдущую работу?
🤺 Наша задача - разделить эпики на примерно равнозначные, чтобы маленький балл по Effort не дал искажений.
🏄‍♀️ Приоритизировать фичи внутри эпика будем по Кано.

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

​​Воспитание чат-ботов для чайников
Мне кажется, что каждому продакту нужен свой чат-бот, который нужно будет обучать. Потому что это весело и сближает команду. У нас такой появился вчера, и это дикий кайф и смех.
Мы с командой до 10 вечера скармливали ему вопросы и ответы чисто по фану.

🧸 Зачем нам эта игрушка?
Я как-то рассказывала о том, что у нас есть чатик поддержки нашего продукта, в котором дежурят разработчики (а в пики нагрузки я и даже стейкхолдеры). В какой-то момент мы поняли, что тратим очень много драгоценного времени на ответы на типовые вопросы и задумали снизить количество вопросов в чатике.

🧩 Что сделали?
Проанализировали чат за последние несколько месяцев и выписали 23 самые часто встречающиеся вопроса.

Проанализировали и поняли, что все частые вопросы можно разделить на 3 части:
🪲 Баг, который надо поправить
⚙ Неудобный функционал, который надо доработать
❓ Часто задаваемые вопросы, на которые мы каждый раз отвечаем одно и то же (отправляем в HR, призываем ответственного и так далее).

И вот если с первыми двумя пунктами все понятно, то с третьим мы сразу понимали, что нам нужен какой-то Slack бот, который нас спасет.
Мы погуглили опенсорсные решения, хотфикса нашей проблемы не нашли и временно ее отложили.

⛑ Что изменилось?
Ребята из нашего ИТ саппорта затащили в контур бота и отдали нам на тестирование. Мы создали чатик, в котором поселили бота и начали задавать ему вопросы, а потом обучать ответам. А потом задавать повторно вопросы, чтобы проверить, что там наш ребеночек успел усвоить.

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