Пинок ногой из зоны комфорта: вход в менторинг
Для меня всегда одной из основных ценностей было помогать людям и улучшать мир вокруг меня. Многие мои важнейшие жизненные выборы были связаны с этой мотивацией, в том числе выбор первого образования и профессии. В том числе поэтому в последнее время я много времени инвестирую в менторство ребят из коммьюнити. Последние две недели провожу встречи буквально каждое утро.
Формальный вход в сущность ментора дался мне непросто. Я как человек, которому вообще не свойственен синдром самозванца, все равно задавалась вопросами «у меня очень специфичный опыт и бэкграунд, зачем им делиться?» и «если кому-то и интересен мой опыт на стыке, то это тоже люди на стыке, а таких людей максимально мало». При этом ко мне много лет стучались в личку и на карьерных ивентах люди с однотипными запросами, а я как будто игнорировала, что такой паттерн есть.
Не так давно мы в Авито стали работать нам тем, чтобы активнее делиться опытом и экспертизой с окружающим миром, и зашли на платформу Getmentor. Причем зашли очень крутым составом: там и дизайн директор, и глава UX лабы, и один из tech директоров, и несколько мощнейших продактов. Я тоже создала себе профиль и описала, чем могу помочь, ни на что особо не рассчитывая (ибо см. выше).
И я была очень удивлена, что мне почти сразу падать заявки. В основном они касаются запросов:
1. Как войти в продакт менеджмент без релевантного опыта.
2. Как составить резюме/ адаптировать опыт для резюме/ лучше описать проекты и достижения.
3. Как понять зоны развития как продакта и прокачать их.
То есть, что самое крутое, это все карьерные запросы к моему опыту на стыке, который, как я думала, никому не интересен.
Причем запросы оставляют совершенно разные люди. Для меня шок, когда ко мне на менторство приходит человек уровня топ-менеджера, который ВУЗ закончил раньше, чем я родилась. Да, он не из ИТ, и хочет войти в ИТ, но чем я могу ему помочь? А оказывается, что могу или частично могу, и я от этого очень сильно кайфую.
🆓 И кстати это все абсолютно бесплатно, потому что для меня ценно не денег поднять, а реально помочь.
В ближайшее время тут будет несколько постов про рефлексию менторства, а если у вас есть запрос, можете перейти на GetMentor и оставить заявку мне или кому-нибудь еще из экспертов Авито (там для нас даже специальный тэг создали😉).
Для меня всегда одной из основных ценностей было помогать людям и улучшать мир вокруг меня. Многие мои важнейшие жизненные выборы были связаны с этой мотивацией, в том числе выбор первого образования и профессии. В том числе поэтому в последнее время я много времени инвестирую в менторство ребят из коммьюнити. Последние две недели провожу встречи буквально каждое утро.
Формальный вход в сущность ментора дался мне непросто. Я как человек, которому вообще не свойственен синдром самозванца, все равно задавалась вопросами «у меня очень специфичный опыт и бэкграунд, зачем им делиться?» и «если кому-то и интересен мой опыт на стыке, то это тоже люди на стыке, а таких людей максимально мало». При этом ко мне много лет стучались в личку и на карьерных ивентах люди с однотипными запросами, а я как будто игнорировала, что такой паттерн есть.
Не так давно мы в Авито стали работать нам тем, чтобы активнее делиться опытом и экспертизой с окружающим миром, и зашли на платформу Getmentor. Причем зашли очень крутым составом: там и дизайн директор, и глава UX лабы, и один из tech директоров, и несколько мощнейших продактов. Я тоже создала себе профиль и описала, чем могу помочь, ни на что особо не рассчитывая (ибо см. выше).
И я была очень удивлена, что мне почти сразу падать заявки. В основном они касаются запросов:
1. Как войти в продакт менеджмент без релевантного опыта.
2. Как составить резюме/ адаптировать опыт для резюме/ лучше описать проекты и достижения.
3. Как понять зоны развития как продакта и прокачать их.
То есть, что самое крутое, это все карьерные запросы к моему опыту на стыке, который, как я думала, никому не интересен.
Причем запросы оставляют совершенно разные люди. Для меня шок, когда ко мне на менторство приходит человек уровня топ-менеджера, который ВУЗ закончил раньше, чем я родилась. Да, он не из ИТ, и хочет войти в ИТ, но чем я могу ему помочь? А оказывается, что могу или частично могу, и я от этого очень сильно кайфую.
🆓 И кстати это все абсолютно бесплатно, потому что для меня ценно не денег поднять, а реально помочь.
В ближайшее время тут будет несколько постов про рефлексию менторства, а если у вас есть запрос, можете перейти на GetMentor и оставить заявку мне или кому-нибудь еще из экспертов Авито (там для нас даже специальный тэг создали😉).
https://getmentor.dev
Анастасия Кондрашова | GetMentor – открытое сообщество IT-наставников
Senior Product Manager / Head of HR Automation @ Avito | GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе…
Из кого получается удобный для ментора менти (или Почему важно Знание себя)?
Я сейчас тестирую фреймворки менторинга, которые создаю сама. И сегодня подтвердила одну гипотезу про свой фреймворк карьерного консультирования.
🥅 В первую очередь ментор должен понять или помочь идентифицировать позитивную цель, которую менти себе поставил или может поставить. При этом важно, что цель не должна быть негативная. То есть нельзя говорить "самое главное - уйти из техподдержки/ моей текущей компании". Надо говорить "я хочу прийти к...". И вот за этим многоточием скрывается самое главное.
🙋🏼♀ Я могу помочь заполнить это многоточие, но сделать это быстро (читай за 1 час) я смогу только если у менти развита компетенция Self-awareness.
Что это значит? Базово, что человек способен рефлексировать относительно себя и отвечать на вопросы про то, что у него круто получается, что не особо, какие он вещи и проекты считает ценными, а от чего его воротит. И это довольно сложно сделать, если выгорел, и бесит буквально ВСЕ. А ещё сложнее, если скилл рефлексии просто не прокачан, и человек на меня смотрит абсолютно пустым взглядом. Тут я сразу понимаю, что за один раз мы не управимся.
Без скилла self-awareness человек просто плывет по течению, рандомно обучается всему подряд, распыляется, не использует свои сильные стороны. Точно не может самостоятельно осознанно поставить себе цель.
А ещё это супер важный нывык именно для продакта, которому постоянно нужно понимать, какие конкретно ему сейчас скиллы нужны для развития продукта, и чего не хватает в эту секунду.
😓 Прокачивать знание себя, как мне кажется, можно, но это долгий процесс. У многих из нас какие-то ответные реакции на внешние раздражители записываются в мозгу и анализируются интуитивно, а кому-то надо попробовать ряд техник, чтобы начать замечать такие вещи.
У меня есть ряд гипотез, как можно быстро и слегка искусственно добрать self-awareness, продолжу их проверять и делиться тут результатами.
Я сейчас тестирую фреймворки менторинга, которые создаю сама. И сегодня подтвердила одну гипотезу про свой фреймворк карьерного консультирования.
🥅 В первую очередь ментор должен понять или помочь идентифицировать позитивную цель, которую менти себе поставил или может поставить. При этом важно, что цель не должна быть негативная. То есть нельзя говорить "самое главное - уйти из техподдержки/ моей текущей компании". Надо говорить "я хочу прийти к...". И вот за этим многоточием скрывается самое главное.
🙋🏼♀ Я могу помочь заполнить это многоточие, но сделать это быстро (читай за 1 час) я смогу только если у менти развита компетенция Self-awareness.
Что это значит? Базово, что человек способен рефлексировать относительно себя и отвечать на вопросы про то, что у него круто получается, что не особо, какие он вещи и проекты считает ценными, а от чего его воротит. И это довольно сложно сделать, если выгорел, и бесит буквально ВСЕ. А ещё сложнее, если скилл рефлексии просто не прокачан, и человек на меня смотрит абсолютно пустым взглядом. Тут я сразу понимаю, что за один раз мы не управимся.
Без скилла self-awareness человек просто плывет по течению, рандомно обучается всему подряд, распыляется, не использует свои сильные стороны. Точно не может самостоятельно осознанно поставить себе цель.
А ещё это супер важный нывык именно для продакта, которому постоянно нужно понимать, какие конкретно ему сейчас скиллы нужны для развития продукта, и чего не хватает в эту секунду.
😓 Прокачивать знание себя, как мне кажется, можно, но это долгий процесс. У многих из нас какие-то ответные реакции на внешние раздражители записываются в мозгу и анализируются интуитивно, а кому-то надо попробовать ряд техник, чтобы начать замечать такие вещи.
У меня есть ряд гипотез, как можно быстро и слегка искусственно добрать self-awareness, продолжу их проверять и делиться тут результатами.
#вебинар
Сегодня в 19:00 веду вебинар про составление резюме продактов в рамках карьерного марафона от ProductStar🚀.
Поговорим про:
- Как подходить к резюме как к продукту
- Смешные косяки и best practices составления резюме продакта
- Как составить резюме стажера/джуна, миддла и синиора.
Прикольно было структурировать в слайдах и советах тот контент, который был у меня в голове.
Ссылка на трансляцию будет вечером.
Сегодня в 19:00 веду вебинар про составление резюме продактов в рамках карьерного марафона от ProductStar🚀.
Поговорим про:
- Как подходить к резюме как к продукту
- Смешные косяки и best practices составления резюме продакта
- Как составить резюме стажера/джуна, миддла и синиора.
Прикольно было структурировать в слайдах и советах тот контент, который был у меня в голове.
Ссылка на трансляцию будет вечером.
Стартуем вебинар про резюме, приходите, кому тема актуальна💜
Ссылочка на трансляцию:
https://www.youtube.com/watch?v=O7xhtttgdIc
Ссылочка на трансляцию:
https://www.youtube.com/watch?v=O7xhtttgdIc
YouTube
Ужасные и прекрасные резюме продакт-менеджеров: разбираем примеры, учимся делать продающее резюме
Зарегистрироваться на Карьерную консультацию 👉 https://is.gd/Rd8dtC
Оставить заявку на курс по продакт-менеджменту👉 https://is.gd/tIdKj4
Оставить заявку на курс по продакт-менеджменту👉 https://is.gd/tIdKj4
Растим эмпатию команды к продукту❤️
Сегодня ко мне пришел продакт из B2B с шикарным запросом: как развить эмпатию к продукту у распределенной команды и побудить их мыслить не историями в джире, а пользователем.
Наши идеи:
👄 1. Вовлекать в интервью с пользователями.
Если у команды есть время (не стоит какого-то жесткого дедлайна, который не позволяет разработчикам ни на секунду оторваться от кода), то совместные кастдевы – отличная возможность лучше почувствовать, что болит у аудитории. Моя команда до моего прихода жила без продакта 8 месяцев, и все это время сама ходила к стейкхолдерам. И они настолько круто узнали заказчика, что могут челленджить многие мои решения, причем не просто словами «мы тоже пользователи, нам так будет неудобно».
👂🏻 2. Рассказывать им про результаты UX-ов.
Если разработчики походили на выборочные интервью с продактом, у них может возникнуть эффект искажения: они могут привязаться к тому, что услышали, и подумать, что то, что болит у одного пользователя – это общий паттерн. Поэтому важно звать их на обсуждение результатов исследования или на презентацию проблем и решений UX-а.
Мы сделали такое на моем прошлом продукте, но тимлид воспротивился тому, чтобы мы оторвали на целый час разрабов от кода, поэтому сказали всем «приходите по желанию». В итоге те фронты, который пришли на презентацию UX, все время могли качественно челленджить решения дизайнеров и говорить, что «на юзабилити пользователи такое не замечали, давайте переделаем».
🎞 3. Звать на демо клиентов.
Самую быструю обратную связь мы получаем на демо, это давно известно. Но как ее получить, если ты работаешь в B2B? Звать сейлзов и стейкхолдеров – не то, получится испорченный телефон. Можно попросить сейлзов выделить группу самых лояльных и вовлеченных клиентов и звать их на спринтовые демо. Причем нужно на первое время забрифовать всех гостей не жестить и не говорить ничего неприятного, чтобы не демотивировать команду.
На моем прошлом продукте мы сначала стали звать на демо самого главного заказчика, потом держателей каждого бизнес-процесса, а потом людей из рабочей группы и из поддержки. Чем больше комментариев мы получали, тем лучше вся команда понимала, в какую мы сторону движемся.
💻 4. Разработчик сам проводит демо.
Максимально мощный инструмент, который мы используем у себя на продукте. У нас есть практика дежурств: каждый спринт определенный разработчик отвечает на вопросы по поддержке и готовит демо.
Чтобы провести демо, ему нужно понять общий скоуп задач, что было сделано в спринте коллегами, самому протестировать весь функционал и в итоге про него рассказать.
📲 5. Сделать чатик поддержки/фича реквестов самых лояльных клиентов.
У нас на продукте (так как он внутренний) очень близкий контакт с пользователями: у нас есть чатик в слаке, где нам в живом режиме задают вопросов по функционалу или api, говорят про баги и накидывают фича-реквесты. И дежурный лично отвечает на эти вопросы и общается с пользователями. Это съедает около 30% его времени в спринте, но дает понимание самых неудобных моментов в продукте (потому что паттерны видно в момент).
Если продукт внешний, то можно опять же выделить группу активных пользователей или клиентов и создать с ними чатик. Так разработчики увидят частые вопросы и даже смогут сами на них ответить (правда, вряд ли они это будут делать без процесса дежурств).
👸🏼 6. Внедрить персоны.
Я пару лет думала, что метод персон – ерунда какая-то. Ну придумываем мы типового пользователя, наделяем его фоткой и именем, что за глупость. Но один раз в рамках разработки стратегии продукта решила попробовать, сделала слайды с персонами и показала новичкам из команды на индакшне. И это был взрыв.
Никогда еще мне на индакшне не задавали столько вопросов и не давали столько комментариев. Внезапно дизайнеры поняли, что их типовому пользователю за 40, аналитики поняли, что HRы не поймут сложные тексты в интерфейсе, вся остальная команда поняла, ради кого мы все это делаем.
Люблю такие классные запросы, которые заставляют подумать и структурировать опыт и мысли💜.
Сегодня ко мне пришел продакт из B2B с шикарным запросом: как развить эмпатию к продукту у распределенной команды и побудить их мыслить не историями в джире, а пользователем.
Наши идеи:
👄 1. Вовлекать в интервью с пользователями.
Если у команды есть время (не стоит какого-то жесткого дедлайна, который не позволяет разработчикам ни на секунду оторваться от кода), то совместные кастдевы – отличная возможность лучше почувствовать, что болит у аудитории. Моя команда до моего прихода жила без продакта 8 месяцев, и все это время сама ходила к стейкхолдерам. И они настолько круто узнали заказчика, что могут челленджить многие мои решения, причем не просто словами «мы тоже пользователи, нам так будет неудобно».
👂🏻 2. Рассказывать им про результаты UX-ов.
Если разработчики походили на выборочные интервью с продактом, у них может возникнуть эффект искажения: они могут привязаться к тому, что услышали, и подумать, что то, что болит у одного пользователя – это общий паттерн. Поэтому важно звать их на обсуждение результатов исследования или на презентацию проблем и решений UX-а.
Мы сделали такое на моем прошлом продукте, но тимлид воспротивился тому, чтобы мы оторвали на целый час разрабов от кода, поэтому сказали всем «приходите по желанию». В итоге те фронты, который пришли на презентацию UX, все время могли качественно челленджить решения дизайнеров и говорить, что «на юзабилити пользователи такое не замечали, давайте переделаем».
🎞 3. Звать на демо клиентов.
Самую быструю обратную связь мы получаем на демо, это давно известно. Но как ее получить, если ты работаешь в B2B? Звать сейлзов и стейкхолдеров – не то, получится испорченный телефон. Можно попросить сейлзов выделить группу самых лояльных и вовлеченных клиентов и звать их на спринтовые демо. Причем нужно на первое время забрифовать всех гостей не жестить и не говорить ничего неприятного, чтобы не демотивировать команду.
На моем прошлом продукте мы сначала стали звать на демо самого главного заказчика, потом держателей каждого бизнес-процесса, а потом людей из рабочей группы и из поддержки. Чем больше комментариев мы получали, тем лучше вся команда понимала, в какую мы сторону движемся.
💻 4. Разработчик сам проводит демо.
Максимально мощный инструмент, который мы используем у себя на продукте. У нас есть практика дежурств: каждый спринт определенный разработчик отвечает на вопросы по поддержке и готовит демо.
Чтобы провести демо, ему нужно понять общий скоуп задач, что было сделано в спринте коллегами, самому протестировать весь функционал и в итоге про него рассказать.
📲 5. Сделать чатик поддержки/фича реквестов самых лояльных клиентов.
У нас на продукте (так как он внутренний) очень близкий контакт с пользователями: у нас есть чатик в слаке, где нам в живом режиме задают вопросов по функционалу или api, говорят про баги и накидывают фича-реквесты. И дежурный лично отвечает на эти вопросы и общается с пользователями. Это съедает около 30% его времени в спринте, но дает понимание самых неудобных моментов в продукте (потому что паттерны видно в момент).
Если продукт внешний, то можно опять же выделить группу активных пользователей или клиентов и создать с ними чатик. Так разработчики увидят частые вопросы и даже смогут сами на них ответить (правда, вряд ли они это будут делать без процесса дежурств).
👸🏼 6. Внедрить персоны.
Я пару лет думала, что метод персон – ерунда какая-то. Ну придумываем мы типового пользователя, наделяем его фоткой и именем, что за глупость. Но один раз в рамках разработки стратегии продукта решила попробовать, сделала слайды с персонами и показала новичкам из команды на индакшне. И это был взрыв.
Никогда еще мне на индакшне не задавали столько вопросов и не давали столько комментариев. Внезапно дизайнеры поняли, что их типовому пользователю за 40, аналитики поняли, что HRы не поймут сложные тексты в интерфейсе, вся остальная команда поняла, ради кого мы все это делаем.
Люблю такие классные запросы, которые заставляют подумать и структурировать опыт и мысли💜.
"Тебе никогда не достичь успеха в карьере в HR".
Это 5 лет назад на полугодовом ревью сказал мне топ-менеджер Марса.
Как он тогда это обосновал? Настя, ты быстро говоришь, слишком безэмоциональная, не размахиваешь руками во время речи, вся такая cool & composed, и тебе сложно создать хорошее первое впечатление. Слабые стороны слишком сильны, да ещё и не развиваемы. Не хочешь попробовать в другой функции поработать? Ну вот в аналитике, например.
Я помню, как я тогда разозлилась и расстроилась. В смысле не достичь? Я за эти полгода работы добилась бОльших результатов, чем все мои коллеги, которые просто были приятными девочками, умеющими создать хорошее первое впечатление.
Что я могу сказать спустя все это время? Выгорев в 0 в HR, поняв, что это не моё, и уйдя в ИТ? Что, возможно, если человек уровня топ-менеджера даёт тебе фидбек, он может быть прав😄.
Я действительно вообще по набору своих сильных сторон не походила на классического HR. Я очень люблю конкуренцию, наслаждаюсь значимостью своей работы и образом будущих результатов.
Другой вопрос, а плохо ли это? Сейчас я все больше встречаю HR-ов, которые круты именно тем, что делают кардинально другие вещи новыми способами за счёт того, что они другие.
Но, возможно, страдают так же, как страдала тогда я.
🤔 Но в чем этот топ-менеджер был не прав? (Не считая того, что свои выводы он базировал на часовом общении).
Он ужасно донес свой фидбек. Зачем фокусироваться на слабых сторонах и травмировать человека, если ты можешь донести смысл совершенно иначе?
Как? Сфокусировавшись на моих ценностях и сильных сторонах.
Настя, что для тебя ценно? Какие у тебя сильные стороны? Сколько по времени ты их применяешь в повседневной работе? От чего ты кайфуешь? А что доставляет тебе стресс? Сколько в твоей работе вещей, которые доставляют тебе стресс?
Это только часть вопросов, которые могут помочь адресовать проблему и помочь понять, что человек занимается не тем, что ему в радость.
(📚 Для классного самоанализа рекомендую книгу М.Бакингема "Заставь свои сильные стороны работать". Сейчас читаю и кайфую.)
P.S. Чем дело кончилось? Естественно, я закусила удила и поставила себе целью доказать ему, что он не прав. Следующие полгода я развивала коммуникабельность, открытость, умение общаться с коллегами, чтобы на следующем ревью показать ему, как я изменилась и смогла развить то, что он считал невозможным развить.
У меня были готовы новые фидбеки, модель поведения, презентация, все-все.
А за день за ревью получила оффер на тимлида и уволилась😅.
Это 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, который просто разорвал мне сознание. Столько полезных советов за полчаса я, возможно, не слышала никогда в жизни.
(Теперь поняла, почему мои менти так меня благодарят после нашего общения).
🏃♀ Буду пробовать этот новый для себя опыт и, конечно, рассказать обо всем здесь.
Руководствуясь правилом "хочешь сделать - пиши об этом", хочу рассказать о том, что меня уже полгода свербит мысль начать делать 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 человек (заказчики, разработчики, тимлид и я) нон-стоп в авральном режиме отвечали на вопросы, объясняли по методологии и тушили пожары.
🔥 А пожар был ещё какой. И это ещё один пункт про боль работы над внутренним продуктом: всегда нужно сохранять баланс между необходимой методологией и тем, что хотят пользователи. Если баланс будет разрушен, то они будут искать любые обходные пути, лишь бы не пользоваться решением.
Такое активное вовлечение в поддержку выжимает все соки, а ещё сбивает фокус. Ты видишь хорошие фидеки, видишь крики, видишь смешанные, и очень хочется пойти и что-то срочно сделать. Типа все откатить. Или срочно запилить ещё одну фичу, которая не продумана с точки зрения требований и процесса и не описана в документации. И тут самое главное - связать себе руки и дождаться метрик.
Шёл понедельник следующей недели. Все еще жду😅.
А ведь специалисты поддержки в таком урагане эмоций живут каждый день. А им никто не пишет хорошие отзывы. Хочется их обнять и пожалеть.
Уже неделю хочется написать пост про поддержку пользователей. Причём хочется написать с совершенно разными эмоциями: от "нужно делать поддержку своими руками хоть изредка" до "как же я ненавижу поддержку, это худшее, что есть в жизни".
Обо всем по порядку.
На прошлой неделе у нас был релиз. Выкатили в прод процесс, который дискаверили и разрабатывали 3 месяца. С понедельника начали сыпаться вопросы в чатик. Сначала немного, пользователи репортили минорные баги, нашёлся один плавающий критичный баг (и все ещё не отловлен, зараза), комментировали юзабилити, что было очень полезно.
Я искренне радовалась, что пользователи знают, где нас найти, куда написать про свои проблемы. Завела страничку в Confluence, куда записывала все комментарии и идеи.
В четверг случился hard launch, раскатились на 100% аудитории, и всех просто бомбануло.
Команда в 10 человек (заказчики, разработчики, тимлид и я) нон-стоп в авральном режиме отвечали на вопросы, объясняли по методологии и тушили пожары.
🔥 А пожар был ещё какой. И это ещё один пункт про боль работы над внутренним продуктом: всегда нужно сохранять баланс между необходимой методологией и тем, что хотят пользователи. Если баланс будет разрушен, то они будут искать любые обходные пути, лишь бы не пользоваться решением.
Такое активное вовлечение в поддержку выжимает все соки, а ещё сбивает фокус. Ты видишь хорошие фидеки, видишь крики, видишь смешанные, и очень хочется пойти и что-то срочно сделать. Типа все откатить. Или срочно запилить ещё одну фичу, которая не продумана с точки зрения требований и процесса и не описана в документации. И тут самое главное - связать себе руки и дождаться метрик.
Шёл понедельник следующей недели. Все еще жду😅.
А ведь специалисты поддержки в таком урагане эмоций живут каждый день. А им никто не пишет хорошие отзывы. Хочется их обнять и пожалеть.
Как выжить на поддержке, когда у тебя внутренний продукт?
Практически с поддержки начался мой вход в ИТ. Я работала на стороне заказчика, и мы внедряли коробочную систему, которую долго и упорно настраивали, готовили к ней требования и тестировали (как бизнес-заказчики могли тестировать, т.е с попеременным успехом). И когда внедрение первой волны завершилось, мне предложили дополнительную нагрузку в виде роли с устрашающим названием "ключевой пользователь". Взамен мне дали стажера, который снял часть нагрузки с моей команды.
🤔 Что за зверь такой этот ключевой пользователь (AKA ки юзер)?
Представьте, что у вас есть внутренний продукт, который разрабатывается командой из продакта, аналитика, разработчиков, дизайнера. И тут вам прилетает вопрос: а почему такая методология кривая? Почему я должен заходить в систему и заполнять заявку на подбор? Мне вполне удобно было написать в Skype "Настя, набери как будет минутка", и рассказать про вакансию.
Вопрос чисто методогический, и на него не может правильно ответить (и не должен!) дежурный разработчик или администратор поддержки.
А кто должен? Продакт? Может. Он 100% знает, почему были приняты те или иные методологические решения, но все равно это будет не очень весомо. Правильно в этот момент будет включиться представителю заказчика и сказать "Серёжа, у тебя же болит аналитика и чистота данных? Вот теперь у нас такая автоматизация, которая позволяет в моменте из заполненных тобой данных построить дэшборды и понять, как ты давно передал вакансию в работу. А ты будешь отслеживать прогресс работы по ней, ты же страдал из-за непрозрачности рекрутмента".
(Любые совпадения случайны😂)
Я по опыту выстраивания и оптимизации модели поддержки искренне убеждена, что в случае сложных систем роль ки юзера необходима, и включаться ему нужно в тот момент, когда возникает методологический вопрос или в любом случае, когда пользователь приходит к ним напрямую.
❤️ А теперь минутка любви: как хорошо, что наши заказчики вовлекаются в поддержку без каких-то формальных ролей, а просто потому, что они клевые.
Практически с поддержки начался мой вход в ИТ. Я работала на стороне заказчика, и мы внедряли коробочную систему, которую долго и упорно настраивали, готовили к ней требования и тестировали (как бизнес-заказчики могли тестировать, т.е с попеременным успехом). И когда внедрение первой волны завершилось, мне предложили дополнительную нагрузку в виде роли с устрашающим названием "ключевой пользователь". Взамен мне дали стажера, который снял часть нагрузки с моей команды.
🤔 Что за зверь такой этот ключевой пользователь (AKA ки юзер)?
Представьте, что у вас есть внутренний продукт, который разрабатывается командой из продакта, аналитика, разработчиков, дизайнера. И тут вам прилетает вопрос: а почему такая методология кривая? Почему я должен заходить в систему и заполнять заявку на подбор? Мне вполне удобно было написать в Skype "Настя, набери как будет минутка", и рассказать про вакансию.
Вопрос чисто методогический, и на него не может правильно ответить (и не должен!) дежурный разработчик или администратор поддержки.
А кто должен? Продакт? Может. Он 100% знает, почему были приняты те или иные методологические решения, но все равно это будет не очень весомо. Правильно в этот момент будет включиться представителю заказчика и сказать "Серёжа, у тебя же болит аналитика и чистота данных? Вот теперь у нас такая автоматизация, которая позволяет в моменте из заполненных тобой данных построить дэшборды и понять, как ты давно передал вакансию в работу. А ты будешь отслеживать прогресс работы по ней, ты же страдал из-за непрозрачности рекрутмента".
(Любые совпадения случайны😂)
Я по опыту выстраивания и оптимизации модели поддержки искренне убеждена, что в случае сложных систем роль ки юзера необходима, и включаться ему нужно в тот момент, когда возникает методологический вопрос или в любом случае, когда пользователь приходит к ним напрямую.
❤️ А теперь минутка любви: как хорошо, что наши заказчики вовлекаются в поддержку без каких-то формальных ролей, а просто потому, что они клевые.
Лучший друг продакта
Мне кажется, что для того, чтобы не сойти с ума, продакту нужно несколько напарников, и самый главный - тимлид команды разработки. И лучшее, что может случиться с продактом, - гармония в работе с тимлидом.
Я видела все цвета радуги тимлидов.
🙆🏼♂️ Видела невероятно классного в технину, но считавшего, что если на проекте есть проджект, то пусть он управляет разработкой.
👨🏻🦰 Видела молодого и жадного до власти, который не понимал масштабов продукта, на который попал, и не умел прикинуть сроки (все его сроки надо было как минимум х6).
🧔🏽 Видела забившего и выгоревшего, который демотивировал моих аналитиков, разработкой рулить не хотел, зато при любом удобном случае рассказывал, что мы неправильно декомпозируем, а как правильно - не говорил.
🧔🏻 Видела (= сейчас работаю с) прекрасного, который и в команду, и в продукт готов (даже интервью проводить), и руками кодить как фуллстек, и все скрам ивенты фасилитирует, и вообще все.
🤷♀️ И вот вопрос: а что вообще я жду от тимлида?
Наш тимлид:
1. Отслеживает мотивацию команды и управляет ей.
2. Строит сильную команду и не боится принимать сложные решения.
3. Рассчитывает и планирует необходимые ресурсы для выполнения стратегии.
4. Оценивает большие куски разработки и помогает ставить цели на квартал.
5. Экспертно оценивает фичи и челленджит команду, если они недо/перезакладываются.
6. Помогает доносить до команды стратегию и понимание продукта.
7. Лидирует проектирование и планирование разработки сложных технических штук (типа интеграции или сервис для защиты информации) - если нет синьоров, которые это задрайвят сами.
8. Помогает (по доброте душевной) с роудмапом, особенно с тем, который детализирован до спринтов и внутри спринта.
9. Техдооооолг!))
10. Просто клевый и за любой движ типа внутреннего предпринимательства, пет проектов или хакатонов.
Мне кажется, что для того, чтобы не сойти с ума, продакту нужно несколько напарников, и самый главный - тимлид команды разработки. И лучшее, что может случиться с продактом, - гармония в работе с тимлидом.
Я видела все цвета радуги тимлидов.
🙆🏼♂️ Видела невероятно классного в технину, но считавшего, что если на проекте есть проджект, то пусть он управляет разработкой.
👨🏻🦰 Видела молодого и жадного до власти, который не понимал масштабов продукта, на который попал, и не умел прикинуть сроки (все его сроки надо было как минимум х6).
🧔🏽 Видела забившего и выгоревшего, который демотивировал моих аналитиков, разработкой рулить не хотел, зато при любом удобном случае рассказывал, что мы неправильно декомпозируем, а как правильно - не говорил.
🧔🏻 Видела (= сейчас работаю с) прекрасного, который и в команду, и в продукт готов (даже интервью проводить), и руками кодить как фуллстек, и все скрам ивенты фасилитирует, и вообще все.
🤷♀️ И вот вопрос: а что вообще я жду от тимлида?
Наш тимлид:
1. Отслеживает мотивацию команды и управляет ей.
2. Строит сильную команду и не боится принимать сложные решения.
3. Рассчитывает и планирует необходимые ресурсы для выполнения стратегии.
4. Оценивает большие куски разработки и помогает ставить цели на квартал.
5. Экспертно оценивает фичи и челленджит команду, если они недо/перезакладываются.
6. Помогает доносить до команды стратегию и понимание продукта.
7. Лидирует проектирование и планирование разработки сложных технических штук (типа интеграции или сервис для защиты информации) - если нет синьоров, которые это задрайвят сами.
8. Помогает (по доброте душевной) с роудмапом, особенно с тем, который детализирован до спринтов и внутри спринта.
9. Техдооооолг!))
10. Просто клевый и за любой движ типа внутреннего предпринимательства, пет проектов или хакатонов.
Почему мы постоянно выгораем?
Пора брать за практику ходить в отпуск каждые три месяца и разряжаться от того стресса, который мы получаем на работе. У меня стресса в последнее время было уж очень много, причем подкрался он нежданно-негаданно.
Продакты и вообще люди из ИТ мира постоянно выгорают. Я обожаю свою работу, но я вот даже не замечаю сама, как внезапно из состояния «класс, фигачу» оказываюсь в «у меня лапки, я не в ресурсе». И это при том, что я год назад осознанно свела переработки к абсолютному минимуму и не испытываю трудностей с тем, что команда у меня не в прямом подчинении.
Решила под конец своего перезагрузочного отпуска на дизайн регате слегка порефлексировать на тему «а почему я как продакт выгораю», чтобы в следующий раз заранее ловить сигналы.
😩 1. Сложно с результатом. Большинство наших гипотез, к сожалению, не подтверждается. Если подтверждается половина, то это с ума сойти какой результат. И получается, что мы кучу времени и ресурсов тратим на то, что точно не увидит свет. При этом тратит не только продакт, но и дизайнер, и даже разработчики. И мало того, что продакту нужно самому признавать, что ничего не получилось, так еще и не расстроиться и вдохновлять себя и команду на следующие вершины.
🤭 2. Развитие продукта бьет по самолюбию. Как бы это ужасно не звучало. Мы выкатываем штуку, в которую верим. Мы облизали ее тестами и уверены в результате. И эта штука даже какое-то время работает. А потом внезапно перестает, меняется процесс, меняется рынок, меняется стейкхолдер, меняется все на свете. И надо уметь проявлять достаточную скорость и гибкость, чтобы это отловить до сильной просадки метрик и что-то выпилить или перепилить. А всегда больно отказываться от того, во что вложил много работы, даже если понимаешь, что пора.
😵💫 3. Постоянное переключение между задачами рождает много стресса. Мы повсюду. Мы бегаем к стейкхолдерам, описываем задачи, проектируем, общаемся с пользователями, смотрим аналитику, сводим P&L, чертим роудмап, мотивируем команду, продолжать можно бесконечно. И в большинстве случаев в течение дня стоит много встреч и много задач, и у каждой своя направленность. В этом одновременно и кайф нашей работы, и огромная сложность. Я после максимально активных дне чувствую себя лимончиком, которому даже на тренировку идти не хочется.
🥴 4. Теряем видение цели. У меня в управленческом скоупе огромная экосистема. Если выписать все, что мы хотим сделать, то 10 команд разработки будут пилить фичи 3 года. И бессознательно очень хочется упростить себе жизнь и сделать детальный роудмап на все это время (и, конечно, мы его делаем). Только вот роудмап на 3 года нежизнеспособен, сроки факапятся, приоритеты меняются, и мы снова сталкиваемся с тем, что сделали неработающий инструмент.
💔 5. Попа в (личной) жизни. Проблемы в личной жизни и просто в жизни очень сильно влияют на мою продуктивность. У меня есть режим «счастье», когда у меня только начинаются классные вещи в жизни, которые меня мотивируют делать экстра и инвестировать в свои проекты. Есть режим «полное одиночество», когда я закапываюсь в сублимацию и занимаюсь только работой, а есть еще третий режим «попа». Это когда проблемы выходят на первый план и съедают все ресурсы, в том числе рабочие.
Мне, чтобы все это пережить, нужны терапевт и перезарядка. Но после такого отпуска и такого максимального всплеска эмоций, кажется, еще недельку нужно просто лежать и чиллить😅.
Но было здорово, обязательно поеду в мае на Ибицу.
И небольшой фотоотчет:
Пора брать за практику ходить в отпуск каждые три месяца и разряжаться от того стресса, который мы получаем на работе. У меня стресса в последнее время было уж очень много, причем подкрался он нежданно-негаданно.
Продакты и вообще люди из ИТ мира постоянно выгорают. Я обожаю свою работу, но я вот даже не замечаю сама, как внезапно из состояния «класс, фигачу» оказываюсь в «у меня лапки, я не в ресурсе». И это при том, что я год назад осознанно свела переработки к абсолютному минимуму и не испытываю трудностей с тем, что команда у меня не в прямом подчинении.
Решила под конец своего перезагрузочного отпуска на дизайн регате слегка порефлексировать на тему «а почему я как продакт выгораю», чтобы в следующий раз заранее ловить сигналы.
😩 1. Сложно с результатом. Большинство наших гипотез, к сожалению, не подтверждается. Если подтверждается половина, то это с ума сойти какой результат. И получается, что мы кучу времени и ресурсов тратим на то, что точно не увидит свет. При этом тратит не только продакт, но и дизайнер, и даже разработчики. И мало того, что продакту нужно самому признавать, что ничего не получилось, так еще и не расстроиться и вдохновлять себя и команду на следующие вершины.
🤭 2. Развитие продукта бьет по самолюбию. Как бы это ужасно не звучало. Мы выкатываем штуку, в которую верим. Мы облизали ее тестами и уверены в результате. И эта штука даже какое-то время работает. А потом внезапно перестает, меняется процесс, меняется рынок, меняется стейкхолдер, меняется все на свете. И надо уметь проявлять достаточную скорость и гибкость, чтобы это отловить до сильной просадки метрик и что-то выпилить или перепилить. А всегда больно отказываться от того, во что вложил много работы, даже если понимаешь, что пора.
😵💫 3. Постоянное переключение между задачами рождает много стресса. Мы повсюду. Мы бегаем к стейкхолдерам, описываем задачи, проектируем, общаемся с пользователями, смотрим аналитику, сводим P&L, чертим роудмап, мотивируем команду, продолжать можно бесконечно. И в большинстве случаев в течение дня стоит много встреч и много задач, и у каждой своя направленность. В этом одновременно и кайф нашей работы, и огромная сложность. Я после максимально активных дне чувствую себя лимончиком, которому даже на тренировку идти не хочется.
🥴 4. Теряем видение цели. У меня в управленческом скоупе огромная экосистема. Если выписать все, что мы хотим сделать, то 10 команд разработки будут пилить фичи 3 года. И бессознательно очень хочется упростить себе жизнь и сделать детальный роудмап на все это время (и, конечно, мы его делаем). Только вот роудмап на 3 года нежизнеспособен, сроки факапятся, приоритеты меняются, и мы снова сталкиваемся с тем, что сделали неработающий инструмент.
💔 5. Попа в (личной) жизни. Проблемы в личной жизни и просто в жизни очень сильно влияют на мою продуктивность. У меня есть режим «счастье», когда у меня только начинаются классные вещи в жизни, которые меня мотивируют делать экстра и инвестировать в свои проекты. Есть режим «полное одиночество», когда я закапываюсь в сублимацию и занимаюсь только работой, а есть еще третий режим «попа». Это когда проблемы выходят на первый план и съедают все ресурсы, в том числе рабочие.
Мне, чтобы все это пережить, нужны терапевт и перезарядка. Но после такого отпуска и такого максимального всплеска эмоций, кажется, еще недельку нужно просто лежать и чиллить😅.
Но было здорово, обязательно поеду в мае на Ибицу.
И небольшой фотоотчет:
Синдром самозванца в ИТ
Мне часто кажется, что я неправильный синиор. В моей голове синиор отвечает за стратегию, за большую команду и за деньги. А, раз у меня внутренний продукт, который денег не приносит, то я и продакт неправильный, и синиор ненастоящий.
🤔 Знакомо? Вспомните, сколько раз вы не шли на конференцию, потому что казалось, что вы недостаточно хороши, чтобы общаться со всеми этими людьми. Или шли, но боялись задать вопрос тому, с кем хотели пообщаться, потому что прозвучали бы глупо. Или отказывались выступать со своим кейсом, потому что вас начинало трясти от тревоги или потому, что считали его маленьким и поверхностным.
Мы чувствуем, что не заслуживаем где-то быть, но тем не менее мы там. И нам постоянно страшно, что нас раскроют, увидят, что мы не на своём месте.
Ко мне часто приходят менти с синдромом самозванца. Очень крутые ребята, которым сложно прочувствовать свою крутость.
Я тоже, как и очень многие другие, временами чувствую себя самозванцем, который незаслуженно занимает свое место, ничего крутого сама не добилась и вообще гораздо менее значимая, чем остальные люди на рынке.
Почему так происходит?
Глобально проблемы две: детские травмы и идеальный образ, который нам навязывает комьюнити.
💅 Идеальный образ продакта
Мы все самозванцы, потому что опираемся на ролевые модели, которые нам создает рынок и создают чужие соцсети. Ведь что мы публикуем в инстаграме и на фэйсбуке? Наши должности в крутых компаниях, наши достижения, наши самые яркие моменты жизни. При этом про свои сложности и проблемы мы не пишем: это слишком личное. Этим мы делимся с друзьями. И получается куча красивых соцсетей невероятно успешных во всем людей. Мы читаем их, вдохновляется и бессознательно целимся в чью-то чужую идею успеха.
👨👨👧 Детские травмы
Родители нам хотят добра. Поэтому всегда ждут от нас максимальных результатов и чтобы мы были лучшей версией себя. Поэтому, любя, дают нам только негативный фидбек, за который мы цепляемся. И каждый раз чувствуем, что все, что мы делаем - это недостаточно круто для них.
Есть еще второй кейс: когда родители, например, страдали алкоголизмом, поэтому совсем не могли принять ребенка со всеми его достижениями и крутизной. Такие травмы лечатся сложнее всех.
Я вернулась с регаты и записалась к новому психотерапевту. И я буду писать про психологическое здоровье в ИТ, потому что вижу, как это важно. И чтобы мы знали, что мы не одни ❤️
Мне часто кажется, что я неправильный синиор. В моей голове синиор отвечает за стратегию, за большую команду и за деньги. А, раз у меня внутренний продукт, который денег не приносит, то я и продакт неправильный, и синиор ненастоящий.
🤔 Знакомо? Вспомните, сколько раз вы не шли на конференцию, потому что казалось, что вы недостаточно хороши, чтобы общаться со всеми этими людьми. Или шли, но боялись задать вопрос тому, с кем хотели пообщаться, потому что прозвучали бы глупо. Или отказывались выступать со своим кейсом, потому что вас начинало трясти от тревоги или потому, что считали его маленьким и поверхностным.
Мы чувствуем, что не заслуживаем где-то быть, но тем не менее мы там. И нам постоянно страшно, что нас раскроют, увидят, что мы не на своём месте.
Ко мне часто приходят менти с синдромом самозванца. Очень крутые ребята, которым сложно прочувствовать свою крутость.
Я тоже, как и очень многие другие, временами чувствую себя самозванцем, который незаслуженно занимает свое место, ничего крутого сама не добилась и вообще гораздо менее значимая, чем остальные люди на рынке.
Почему так происходит?
Глобально проблемы две: детские травмы и идеальный образ, который нам навязывает комьюнити.
💅 Идеальный образ продакта
Мы все самозванцы, потому что опираемся на ролевые модели, которые нам создает рынок и создают чужие соцсети. Ведь что мы публикуем в инстаграме и на фэйсбуке? Наши должности в крутых компаниях, наши достижения, наши самые яркие моменты жизни. При этом про свои сложности и проблемы мы не пишем: это слишком личное. Этим мы делимся с друзьями. И получается куча красивых соцсетей невероятно успешных во всем людей. Мы читаем их, вдохновляется и бессознательно целимся в чью-то чужую идею успеха.
👨👨👧 Детские травмы
Родители нам хотят добра. Поэтому всегда ждут от нас максимальных результатов и чтобы мы были лучшей версией себя. Поэтому, любя, дают нам только негативный фидбек, за который мы цепляемся. И каждый раз чувствуем, что все, что мы делаем - это недостаточно круто для них.
Есть еще второй кейс: когда родители, например, страдали алкоголизмом, поэтому совсем не могли принять ребенка со всеми его достижениями и крутизной. Такие травмы лечатся сложнее всех.
Я вернулась с регаты и записалась к новому психотерапевту. И я буду писать про психологическое здоровье в ИТ, потому что вижу, как это важно. И чтобы мы знали, что мы не одни ❤️
Почему всегда болит тестирование?!
В первый день моего отпуска я летела на самолёте в Грецию. По прилёту мой Slack просто взорвался. Оказалось, что за эти 4 часа наш продуктивный стенд не выдержал нагрузки и упал. Упал в самый жаркий период использования нашего продукта.
☠ Это была катастрофа, которую ребята быстро исправили. Но на этом сложности не закончились. Люди повсюду видели надпись "проверь VPN", хотя по факту просто неправильно отрабатывали валидации на фронте. Периодически у нас возникали те условия, которых в требованиях не было.
Я могу продолжать до бесконечности, но к чему я веду? Баги есть у всех. Они есть у нашего большого продукта, есть на Фэйсбуке, есть на Нетфликсе. Вопрос лишь в критичности этих багов.
🙈 Значит ли это, что мы все плохо работаем? По большей части нет. Только что, что мы недостаточно хорошо выстраиваем процесс тестирования.
Тут часто включается эффект когнитивного искажения. Мы не любим думать о том, что можем совершать ошибки, поэтому ненавидим оценивать риски. Наш мозг думает в режиме "нормально все будет" и триггерит нас принимать неправильные решения быстро. Тестирование - как хорошая привычка. Его культуру нужно прививать.
На моем прошлом продукте тестирование (даже функциональное) болело так сильно, что нас физически трясло. Оно было как кот Шредингера: вроде тестировщики и есть, а баги не находятся и не закрываются😂.
И поняли мы это только когда у нас завершился рефакторинг, и в системе оказалось 300+ багов, которые никто не находил, а если и находил, то не логировал или логировал неправильно.
Пример: Блокирующий баг в джире: "В карте KPI у HRа не хватает кнопки Согласовать". 🤯
В смысле?! Это все? На каком стенде ты это проверял? Под каким пользователем нашел ошибку? На каком этапе была карта? У какого пользователя? В каком браузере? Какие были твои шаги перед тем, как ты нашел ошибку? Где скрин? Панель разработчика открывал?
И самое главное: а ты вообще уверен, что это ошибка, а не ожидаемое поведение системы? (Спойлер: нет).
Разработчик не понимал, что за баг, воспроизвести по такому описанию не мог, поэтому ставил статус "не воспроизводится" и закрывал задачу. А тестировщик потом заводил ее заново 😜.
В целом это история с хэппи эндом. Правда, выстраивать процесс тестирования пришлось техническому писателю, системному аналитику и мне (звучит как начало плохого анекдота. За тем исключением, что мы в бар не заходили, а пошли ботать в выходные на Яндекс.Практикум).
Почему мы? Я искренне считаю, что за процесс тестирования отвечает в том числе продакт. Да, с помощью тимлида, но кому аутнется, когда в продукте будет 300 багов? У кого из-за этого упадут метрики?
Через боль и страдания мы пришли к конкретному описанию багов в джире.
Логировали:
- где возникла ошибка (стенд, браузер)
- под каким пользователем ее обнаружили
- шаги воспроизведения
- ожидаемое поведение
- фактическое поведение системы
- скрин с открытой панелью разработчика
- воспроизводимость ошибки.
Но это были только первые шаги к выстраиванию тестирования. И сейчас во многом мне придется пройти через этот процесс еще раз (у нас в команде нет QA, поэтому пока возникают трудности).
В первый день моего отпуска я летела на самолёте в Грецию. По прилёту мой 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 года, и при этом мы осчастливили команду рекрутеров и освободили им время для более качественной работы с кандидатами.
Каждый кейс уникален. Если мы создаем продукты для всех сотрудников или всех руководителей компании, то наше решение скорее всего окупится даже при условии собственной разработки. А вот если мы автоматизируем процессы узкой целевой аудитории, то лучше очень внимательно считать цифры и принимать осознанное решение по методу реализации.
😭 К сожалению, на большинстве внутренних HR продуктов очень плохая экономика.
У меня в практике был такой кейс: компания ежегодно нанимала в районе 600 стажеров и молодых специалистов. На часть таких вакансий (возьмём 60%) обычно очень большая воронка на входе, поэтому для её сужения рекрутеры использовали отсев с помощью тестирования (числовые тесты).
Допустим, мы знаем, что для вывода на работу одного нового сотрудника, нам надо отправить кандидатам 10 тестов.
Как происходит отправка теста? Рекрутер связывается с кандидатом и подтверждает с ним, что тот согласен на условия компании: дата выхода, ЗП, функционал и так далее. И что он сам базово подходит компании по своим знаниям. Потом рекрутер идёт на платформу тестирования и создаёт там учётную запись кандидата. Вводит имя/фамилию, почту. Далее выбирает нужный тест и назначает. После этого рекрутер идёт в почту и пишет кандидату: Вася, тест назначен, как пройдёшь, отпишись (потому что отбивки из системы тестирования не приходили). Вася может отписаться, а может не отписаться. В этом случае наш рекрутер заходит сам в систему тестирования и проверяет, пройдены ли тесты. Если нет, то, спустя Х дней, удаляет данные Васи и отправляет ему отказ.
На такой процесс рекрутер тратит в среднем 7 минут на кандидата. Считаем. 360 ставок, 10 кандидатов на каждую, 7 минут на каждого кандидата. Получаем 420 часов в год.
Ужасная цифра для такого процесса.
Автоматизируем? Давайте. Можем написать шину, которая сынтегрирует платформу рекрутера с системой тестирования. Рекрутеру достаточно будет просто одним кликом переместить кандидата в нужную ячейку в системе, а дальше наша шина сама подхватит кандидата, назначит ему нужные тесты, отправит ссылку на прохождение, а после прохождения уведомит об этом рекрутера и запишет баллы в систему. Если кандидат с тестами не справился или не прошёл их через Х дней, то шина сама это поймёт, передаст данные платформе рекрутера, которая отправит отказ. И в итоге мы простой интеграцией экономим 420 часов в год, которые рекрутер может посвятить более важным задачам.
👏 Ну классно же? Надо делать?!
А теперь давайте посчитаем цифры ещё раз.
В этом процессе мы упрощаем жизнь только рекрутеру. Возьмём среднюю ЗП рекрутера на то время: 65к гросс. Прибавим ещё 30 процентов, так как он в штате (косты за офис, прочие налоги). А потом посчитаем стоимость часа работы рекрутера... и получим примерно 500 рублей.
Соответственно, нашей автоматизацией мы сэкономим компании 210 тысяч рублей в год.
Ну, не миллионы, но тоже неплохо...так?
Не так. Спринт работы собственной команды разработки стоит от 1 до 3 млн рублей. А такой функционал делать 4 спринта минимум (двусторонняя интеграция, формы кандидатов, маски для обезличивания данных, тестирование и исправление багов + настройки на стороне системы рекрутера).
И что же делать? Смириться с тем, что разработка не окупится никогда в жизни? Или сказать на старте, что этот внутренний продукт экономически неэффективный и отказаться от разработки? И пусть бедные рекрутеры страдают?
На самом деле есть несколько вариантов:
1. Купить коробочное решение, если такое есть.
2. Заказать разработку у провайдера.
3. Смириться с тем, что решение не окупится.
4. Отказаться от процесса, который нужно автоматизировать.
5. Отказаться от автоматизации.
🥳 В нашем случае все закончилось отлично: мы запартнерились с провайдером тестов, который увидел бизнес возможность в том, чтобы зарабатывать на интеграциях, и очень задешево написал нам шину. Наша автоматизация окупилась за 2 года, и при этом мы осчастливили команду рекрутеров и освободили им время для более качественной работы с кандидатами.
Каждый кейс уникален. Если мы создаем продукты для всех сотрудников или всех руководителей компании, то наше решение скорее всего окупится даже при условии собственной разработки. А вот если мы автоматизируем процессы узкой целевой аудитории, то лучше очень внимательно считать цифры и принимать осознанное решение по методу реализации.