Продуктовая бомбежка
596 subscribers
26 photos
29 links
Старший продакт менеджер @Авито, ментор. Пишу о менеджменте в сфере управления продуктом, об оптимизации процессов и рабочих эмоциях.

По вопросам @Kondrashova_Anastasia
Download Telegram
"Тебе никогда не достичь успеха в карьере в HR".
Это 5 лет назад на полугодовом ревью сказал мне топ-менеджер Марса.

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

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

Что я могу сказать спустя все это время? Выгорев в 0 в HR, поняв, что это не моё, и уйдя в ИТ? Что, возможно, если человек уровня топ-менеджера даёт тебе фидбек, он может быть прав😄.

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

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

Как? Сфокусировавшись на моих ценностях и сильных сторонах.

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

(📚 Для классного самоанализа рекомендую книгу М.Бакингема "Заставь свои сильные стороны работать". Сейчас читаю и кайфую.)

P.S. Чем дело кончилось? Естественно, я закусила удила и поставила себе целью доказать ему, что он не прав. Следующие полгода я развивала коммуникабельность, открытость, умение общаться с коллегами, чтобы на следующем ревью показать ему, как я изменилась и смогла развить то, что он считал невозможным развить.
У меня были готовы новые фидбеки, модель поведения, презентация, все-все.
А за день за ревью получила оффер на тимлида и уволилась😅.
🐼 Pet project: пилить нельзя забыть.

Руководствуясь правилом "хочешь сделать - пиши об этом", хочу рассказать о том, что меня уже полгода свербит мысль начать делать pet project.

Причём свербило меня изначально с неправильной мотивацией. Почему мне хотелось что-то свое (причины в порядке приоритета):

📊 1. Покрыть те пробелы, которые у меня появились из-за специфики работы над внутренним продуктом: монетизация и работа с продуктовыми, а не процессными метриками.

🤴 2. Желание сделать что-то значимое и крутое, что-то, чем будут пользоваться и любить.

💸 3. Дополнительный источник дохода.

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

Второй стоппер: у меня не было идей, в которые я бы реально верила.
Какие идеи я прокручивала:

1. Сервис по приоритизации гипотез.
Почему мне нравилась идея: она решала мою личную боль ведения тонны экселек с экономикой и RICE, сведения всех данных по impact и effort в один файл, выстраивания и редактирования роудмапа.
🚫 Почему я отказалась от идеи: продакт менеджмент в России новый процесс, если такое решение делать, оно должно быть максимально настраиваемое, потому что все приоритизируют и считают экономику по-разному.
Вторая причина: B2B рынок.

2. Сайт для проектирования дизайна интерьера.
Почему мне нравилась идея: она решала мою личную боль планирования ремонта. Я начала проектировать квартиру и столкнулась с кучей вопросов, ответы на которые пришлось искать в разных источниках. С чего начать? Как продолжить? Что должно входить в дизайн-проект? Когда передавать проект бригаде? Где искать классных исполнителей?
🚫 Почему я отказалась от идеи: очень узкая целевая аудитория, много сервисов, которые дублируют части функционала, не подтвердились гипотезы, не сошлась экономика.

Но third time is a charm, right?

Я замахнулась сделать продукт на перенасыщенном рынке Edtech😅.

Почему сейчас я хочу начать инвестировать в это время?

🤗 1. Я верю в то, что контент может принести людям ценность (и базово гипотезу подтвердила).

💲 2. Изначальные финансовые инвестиции минимальные.

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

🏃‍♀ Буду пробовать этот новый для себя опыт и, конечно, рассказать обо всем здесь.
Ненавижу поддержку (нет)

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

Обо всем по порядку.

На прошлой неделе у нас был релиз. Выкатили в прод процесс, который дискаверили и разрабатывали 3 месяца. С понедельника начали сыпаться вопросы в чатик. Сначала немного, пользователи репортили минорные баги, нашёлся один плавающий критичный баг (и все ещё не отловлен, зараза), комментировали юзабилити, что было очень полезно.
Я искренне радовалась, что пользователи знают, где нас найти, куда написать про свои проблемы. Завела страничку в Confluence, куда записывала все комментарии и идеи.

В четверг случился hard launch, раскатились на 100% аудитории, и всех просто бомбануло.
Команда в 10 человек (заказчики, разработчики, тимлид и я) нон-стоп в авральном режиме отвечали на вопросы, объясняли по методологии и тушили пожары.

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

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

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

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

🤔 Что за зверь такой этот ключевой пользователь (AKA ки юзер)?

Представьте, что у вас есть внутренний продукт, который разрабатывается командой из продакта, аналитика, разработчиков, дизайнера. И тут вам прилетает вопрос: а почему такая методология кривая? Почему я должен заходить в систему и заполнять заявку на подбор? Мне вполне удобно было написать в Skype "Настя, набери как будет минутка", и рассказать про вакансию.
Вопрос чисто методогический, и на него не может правильно ответить (и не должен!) дежурный разработчик или администратор поддержки.

А кто должен? Продакт? Может. Он 100% знает, почему были приняты те или иные методологические решения, но все равно это будет не очень весомо. Правильно в этот момент будет включиться представителю заказчика и сказать "Серёжа, у тебя же болит аналитика и чистота данных? Вот теперь у нас такая автоматизация, которая позволяет в моменте из заполненных тобой данных построить дэшборды и понять, как ты давно передал вакансию в работу. А ты будешь отслеживать прогресс работы по ней, ты же страдал из-за непрозрачности рекрутмента".

(Любые совпадения случайны😂)

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

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

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

Я видела все цвета радуги тимлидов.
🙆🏼‍♂️ Видела невероятно классного в технину, но считавшего, что если на проекте есть проджект, то пусть он управляет разработкой.

👨🏻‍🦰 Видела молодого и жадного до власти, который не понимал масштабов продукта, на который попал, и не умел прикинуть сроки (все его сроки надо было как минимум х6).

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

🧔🏻 Видела (= сейчас работаю с) прекрасного, который и в команду, и в продукт готов (даже интервью проводить), и руками кодить как фуллстек, и все скрам ивенты фасилитирует, и вообще все.

🤷‍♀️ И вот вопрос: а что вообще я жду от тимлида?
Наш тимлид:
1. Отслеживает мотивацию команды и управляет ей.

2. Строит сильную команду и не боится принимать сложные решения.

3. Рассчитывает и планирует необходимые ресурсы для выполнения стратегии.

4. Оценивает большие куски разработки и помогает ставить цели на квартал.

5. Экспертно оценивает фичи и челленджит команду, если они недо/перезакладываются.

6. Помогает доносить до команды стратегию и понимание продукта.

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

8. Помогает (по доброте душевной) с роудмапом, особенно с тем, который детализирован до спринтов и внутри спринта.

9. Техдооооолг!))

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

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

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

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

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

🤭 2. Развитие продукта бьет по самолюбию. Как бы это ужасно не звучало. Мы выкатываем штуку, в которую верим. Мы облизали ее тестами и уверены в результате. И эта штука даже какое-то время работает. А потом внезапно перестает, меняется процесс, меняется рынок, меняется стейкхолдер, меняется все на свете. И надо уметь проявлять достаточную скорость и гибкость, чтобы это отловить до сильной просадки метрик и что-то выпилить или перепилить. А всегда больно отказываться от того, во что вложил много работы, даже если понимаешь, что пора.

😵‍💫 3. Постоянное переключение между задачами рождает много стресса. Мы повсюду. Мы бегаем к стейкхолдерам, описываем задачи, проектируем, общаемся с пользователями, смотрим аналитику, сводим P&L, чертим роудмап, мотивируем команду, продолжать можно бесконечно. И в большинстве случаев в течение дня стоит много встреч и много задач, и у каждой своя направленность. В этом одновременно и кайф нашей работы, и огромная сложность. Я после максимально активных дне чувствую себя лимончиком, которому даже на тренировку идти не хочется.

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

💔 5. Попа в (личной) жизни. Проблемы в личной жизни и просто в жизни очень сильно влияют на мою продуктивность. У меня есть режим «счастье», когда у меня только начинаются классные вещи в жизни, которые меня мотивируют делать экстра и инвестировать в свои проекты. Есть режим «полное одиночество», когда я закапываюсь в сублимацию и занимаюсь только работой, а есть еще третий режим «попа». Это когда проблемы выходят на первый план и съедают все ресурсы, в том числе рабочие.

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

И небольшой фотоотчет:
Синдром самозванца в ИТ

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

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

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

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

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

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

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

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

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

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

В первый день моего отпуска я летела на самолёте в Грецию. По прилёту мой 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 опубликовали мини-интервью со мной в рамках развития программы менторства💚💜