Всем привет!
Меня зовут Настя, и я старший продакт менеджер. Занимаюсь я, к сожалению и к счастью, в основном внутренними и внешними HR tech продуктами. Это оптимизация бизнес процессов постановки целей, подбора персонала, обучения, планирования карьеры и так далее. К сожалению потому, что это довольно узкое направление, в котором мало что пока понятно и очень мало экспертов. К счастью в принципе по тем же причинам - так как направление новое и узкое, есть большой простор для роста и улучшений. А ещё хорошие эксперты на стыке IT и HR очень редкие, что делает нас невероятно ценными😉

Этот канал станет моим третьим блогом в жизни. Первый я вела на liveinternet в 15 лет и писала о поп-панк концертах, второй в 20 - делала в Sims 3 лукбуки и публиковала на Tumblr. Third time is a charm, right?

🖊Писать я буду в основном о менеджменте в сфере управления продуктом, о софт скиллах, об оптимизации процессов (и бизнес процессов, и внутри команды разработки), о сложностях и выгорании, а также буду делиться теми яркими эмоциями, которые у меня вызывает работа, которую я так люблю.
Расскажу, как была первым продактом в Госкорпорации, где и не слышали о продуктовой методологии, о том, как выстраивала процессы бизнес аналитики, исследований и тестирования и многом другом.

По вопросам пишите в личку @Kondrashova_Anastasia, и будем на связи!

Про выгорание: реальная история. Часть 1

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

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

❓Почему?
1. Graduate Recruitment - очень динамичная и развивающая профессия. Из-за того, что все очень быстро, специалистам по подбору надо работать гораздо оперативнее, чем тем, кто занимается точечным подбором. И поэтому ребята в моей команде вырастали и переходили на другие позиции невероятно быстро. Полгода-год - среднее время их работы. И я стала чувствовать себя каким-то инкубатором. Ко мне приходит недавний студент с нулём опыта, я отдаю ему все, что знаю, только начинаю получать отдачу... как он говорит, что перерос роль и хочет перейти внутри. Или что его схантили на большие деньги куда-нибудь в Газпром. И тебе надо снова идти на рынок, снова искать недавнего студента (а на других нет бюджета), снова обучать с нуля и так по кругу.
2. Невероятная монотонность работы. Graduate Recruitment цикличен. Ты всегда знаешь, что будет завтра, какую воронку тебе нужно организовать для выполнения целей, сколько резюме разобрать и сколько сделать звонков. Первые полгода была активная оптимизация работы, а потом 100% рутина.
3. Отсутствие позитивной обратной связи. Есть одно правило, которое я поняла ещё в начале карьеры: как бы хорошо рекрутер не работал, им всегда будут недовольны. Новые сотрудники всегда нужны вчера, кандидаты всегда недостаточно хороши, а рекрутер всегда слишком медленный. Новоиспеченные менеджеры считали нормальным прийти в наш оупен спейс и начать прессовать моих джунов или написать хамское письмо. И эти конфликты эмоционально истощают.
4. Переработки. Я работала очень много. Я считала неправильным уйти с работы раньше моей команды, а они могли сидеть до 23 вечера. Просто потому, что было очень много работы, а нанять больше людей мы не могли - бюджет. В середине лета мне согласовали переход на новую роль - проектно-продуктовую, но переход на неё очень сильно затянулся. В итоге финально перейти, не совмещать 2 роли и не поддерживать свою преемницу я смогла только в конце октября.

👩🏼‍⚕ Какие были симптомы выгорания?
- Я стала отчетливо понимать, что занимаюсь не своим делом.
- Встречи с моим ментором из "давай обсудим моё карьерное развитие, вот мой план на 5 лет" превратились в "я больше не могу, я ничего не хочу".
- Я стала срываться на людей за плохую работу.
- Я стала неадекватно реагировать на свою преемницу, которая делала мою прежнюю работу не так, как ее делала бы я.
- Я расхотела делать больше, чем от меня ожидалось.
- Меня не драйвили проекты на новой роли, мне казалось, что они поверхностные и мелкие.

💉 Что помогло?
В ноябре я ушла в трехнедельный отпуск по состоянию здоровья. Сделала операцию, потом лежала, проходила тренинги по продукту и смотрела "Друзей". Но не помогло. Я вышла на работу с таким же состоянием бессилия и ненависти к проекту, который вела. И вышла на рынок. Я начала общаться с одной довольно интересной мне компанией, но не на самую интересную позицию. Хотя в тот момент мне казалось, что она станет глотком свежего воздуха. Но не случилось. В самом конце декабря мы поняли, что не сходимся в ожиданиях друг от друга, я отклонила оффер и улетела в отпуск в Португалию.
Когда я 10го января вышла в офис, выгорание как рукой сняло. Я почувствовала, что могу дышать, что мне снова интересно

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

Продолжение следует...

Про выгорание: реальная история. Часть 2

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

⁉️ Что же случилось?
У меня была очень классная работа: такая, о которой продакт на внутренние продукты может только мечтать. Огромный организационный периметр, космический бюджет, чётко выделенный заказчик на каждый процесс и большой масштаб управления (больше 50 человек в продуктовой команде).

🔨 Сложно было с самого начала. Я пришла в тот момент, когда уже через 3 месяца надо сдавать результат, а ни у кого нет понимания, что же в этот результат входит. Добавьте к этому конфронтацию между менеджментом и продуктовой командой и отношение команды ко мне как к представителю злостного менеджмента. Скрам-мастера меня травили и выживали, на дэйли разработчики говорили "делаю задачу 2674, проблем нет, передаю слово следующему", шел рефакторинг всей системы, не запускался стенд, тимлид разработки уволился, а каждое ретро превращалось в молчание (и даже не ягнят). И все это в условиях Госкорпорации.

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

1. Постоянная борьба против плохо работающих людей истощает. Подбор людей - сложно. Увольнения - сильно сложнее. Особенно если твоя компания не привыкла увольнять людей и даёт им несколько шансов в то время, как страдает продуктивность всей команды. Часто понимаешь, что лучше совсем без аналитика/скрама/дизайнера, чем с таким. И нужно было потратить много энергии, чтобы убедить в этом тех, кто может принять это решение. 
2. У нас был дедлайн "от балды", который поставили в самом начале запуска проекта. От этого дедлайна было не уйти, Заказчик не слушал, что у нас теперь продуктовая разработка, что мы проектируем, делаем исследования, оптимизируем процессы и собираем требования. Заказчик хотел всё здесь и сейчас, чем фрустрировал команду и не оставлял время на продуктовое виденье.
3. А очень весело когда ты еще и перфекционист, правда? И когда точно знаешь, что можно сделать лучше, что ты делаешь неправильно, недостаточно много исследований, извлекаешь недостаточно аналитики, доработки по итогам UX покрываются плесенью в бэклоге, так как очень мало дизайнеров, а найти новых - проблема. Я постоянно жила в состоянии неудовлетворенности собой и своим результатом, понимая, что нет предела совершенству.
4. Отсутствие позитивной обратной связи. Сложно жить с ощущением, что тебя все ненавидят или по крайней мере не считаются с твоим мнением. Обидно, что осознаешь свою ценность и важность только когда приносишь заявление на подпись. Но тогда уже слишком поздно.
5. Не получилось найти на работе друзей. Другая культура, другие люди. Чувство принадлежности может очень сильно мотивировать и гнать вперёд. Я помню, как на своей самой первой работе я не увольнялась только из-за того, что команда была нереально классная. А ходить полгода одной на обеды в ком угодно разбудит социопата.
6. Я очень устала. Это был действительно драйвовый период, который я буду вспоминать всегда. Я работала с 7 утра до полуночи. Бывало, что в полночь перед релизом я только положила голову на подушку, как получала сообщение от техлида "Ты спишь? Можешь прогнать регресс на новом стенде?". Я вставала, включала ноутбук и прямо из кровати начинала тестировать до двух ночи. Это круто, и я не призываю так не делать. Просто следите за своей батарейкой и вовремя её заряжайте.

🛡 Самая большая проблема была в том, что выгорание я в этот раз заметила слишком поздно. 20 декабря мы сдали систему, и я просто упала. Психосоматика дала о себе знать, и я слегла с ОРВИ. Очень болезненно реагировала, когда коллеги мне писали во время болезни. Даже просто спросить, как я себя чувствую. Думала, что этого времени хватит, чтобы отдохнуть.
В новогодние каникулы у меня начались новые отношения, и когда я вышла в январе в офис, перерабатывать уже совсем не хотелось. Хотелось уйти в 17.30, уехать до пробок и бежать на свидание. Только после того, как отношения закончились, я поняла, что мне просто хотелось бежать. И не обязательно на свидание.

👨🏻‍⚕ Симптомы:
- Ощущение перманентных эмоциональных качелей из-за большой кучи проблем на проекте.
- Я снова стала часто срываться на коллег, если мы спорили и были не согласны друг с другом.
- Я всегда приходила на работу в 8.00-8.30 утра. Для меня это было самое продуктивное время, когда я могла разобрать почту, причесать бэклог и джиру, собрать руками прототип. Сейчас я стала видеть, что мне ничего этого не хочется. Я час просто сидела со стаканчиком латте и смотрела в пустоту или в телефон.
- Я не была достаточно вовлеченной во время встреч. Часто я замечала, что на заднем фоне может идти PBR или показ макетов, а я мысленно нахожусь где-то совсем в другом месте.
- Довольно неожиданно для меня мне пришёл новый оффер, который был "быстрее, выше, сильнее". И только когда я написала заявление, а моя компания стала меня очень рьяно удерживать, предлагая и больше денег, и роль начальника отдела UX/UI на всю линейку продуктов, я поняла, что нет ничего, что может заставить меня остаться.

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

💊 Что делать?
1. Уходить. Очень сложно уходить, когда команда плачет и говорит тебе, что ты лучший продакт на свете, когда руководитель говорит, что ты нужна этому продукту, а большой человек из Госкорпорации лично приезжает и просит тебя остаться. Можно поддаться тщеславию, попросить хорошие условия и остаться. Но не надо. По крайней мере для меня это был не вариант. Это бы не решило тех проблем, от которых меня трясло, не помогло бы мне дать себе эмоциональную встряску.
2. Отпуск! Боже, я не была в отпуске с января 20го. Сначала не хотелось, потом не отпускали. Я не из тех, кто мог бы просто все бросить и улететь на полгода в саббатикал на Мальдивы - мне на это просто не хватит смелости. Я улетаю с оффером в почте и не на Мальдивы, но надеюсь использовать по максимуму те шесть дней, которые у меня есть.
3. Я уверена, что новая работа станет тем воздухом, который мне нужен. У меня было около 10 интервью с самыми разными людьми, каждый из которых меня вдохновил и впечатлил. Я собрала фидбеки у знакомых, и они идеальные. Мне нравится продуктовая линейка, которая мне достанется, и нравится будущий руководитель. Сейчас, дописав пост, я гораздо меньше чувствую стресс и смотрю в будущее с восторгом и позитивом.

Бонус про выгорание: как удавалось его избежать на старте карьеры

Моё первое серьёзное место работы было в маленьком стартапе, который делал крутые HR проекты для больших корпораций. Первые 2 года я работала практически как сотрудник Unilever: на их проектах, на их оборудовании, в их офисе или дома на удаленке. Но формально моим руководителем была СЕО моего агентства. Она была хоть и сложной, но очень мудрой женщиной, которые 2 года управляла моим эмоциональным состоянием так, чтобы я избежала выгорания (хотя переработки были безумные).

🤔 Что она делала?
1. После первых трех месяцев работы (когда я была истощена рутиной проекта) она перевела меня на более сложный (хоть и практически идентичный) проект и дала в помощь стажера.
2. Когда я стала чувствовать, что меня не ценят, немного прибавила мне зарплату и переименовала из "консультанта" в "менеджера проектов".
3. Когда летом был низкий сезон, и было мало задач, сказала, что я могу просто ходить гулять с сохранением ЗП, чтобы я не сидела в стрессе и не придумывала себе сама задачи.
4. Дала мне попробовать новое направление в работе - заниматься генерацией контента для соцсетей клиентов. Конечно, мои прежние функции также остались на мне, контентом я занималась в свободное время (после 18.00).
5. Понимая, что мне это важно, дала мне самой руководить общением с клиентом и SMM проектом.
6. Давала обратную связь: и плохую, и хорошую.

Алёна, спасибо.

Давайте все будем хорошими менеджерами и будем заботиться о своих командах.

Как понять, что занимаешься не своим делом?

Мне часто задают вопрос "Настя, как перейти в IT из другой сферы? Хочу изменить карьеру. Как у тебя это вышло?". Я спрашиваю, а зачем? На что люди отвечают "сейчас за это много платят".

🤦🏼‍♀️ Ох, люди. Скажу как бывший HR и как руководитель со стажем: это худшая мотивация из всех возможных. Конечно, все мы хотим ездить на такси, есть только в ресторанах и красиво одеваться. Но счастливый эффект от "зарплаты олигарха" уходит через 1-2 месяца. А ощущение, что делаешь не то, что должна, остаётся.

Я назвала пункт "я занимаюсь не своим делом" одной их основных причин своего первого выгорания.
У меня был чёткий план. Я начала как HR и росла как HR в международной корпорации. Хотела получить опыт в функции 360°, поработать на развивающемся рынке, чтобы помочь им выстроить процессы, дорасти до HR директора, а потом уехать в глобальную команду делать методологию на весь мир. В одной из моих первых корпораций мне рассказали, что так мечтать "правильно", и я перестала замечать, что это не мои мечты. Любопытно, но что-то из этого правда описывает то, что я на самом деле хочу делать.

Так как я поняла, что пора что-то менять?
(Аргументы "скучно" и "не нравится" опускаем).

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

🗽 2. Фидбек руководителей. Я долгое время не сомневалась в том, что я нахожусь в правильном месте. Даже когда во время работы в Марсе мне довольно жёстко сказали, что я совсем не похожа на классического HR, я подумала, что они ошибаются. Я работала как HRBP и мне нравилось...по большей части. Нравилось, когда я смогла вычленить в процессной работе метрики и оцифровала то, как они выросли за год моей упорной работы.

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

🔆 4. Я не чувствовала, что несу ценность и делаю важные вещи. Чувствовала, что я занимаюсь никому не нужной работой: поддержка для поддержки. И мне постоянно кому-то нужно было доказывать свою ценность. Не должно так быть. Не должна любимая работа приносить страдания и чувство нереализованности.

🏋‍♀ 5. Я не использовала все свои сильные стороны, а если использовала, то очень редко и не совсем по назначению. Самые яркие моменты моей работы тимлида по рекрутменту были, когда я исследовала рынок труда с вопросом "где еще в регионах России можно набирать молодых аудиторов?" и делала сравнительный анализ с 15 вводными. А еще когда на цифрах доказала партнёру оценки бизнеса как можно оптимизировать воронку подбора... и потом оптимизировала ее.

💫 6. У меня не было ролевой модели в HR. Не было руководителя или просто человека из функции, работой и умом которого я бы восхищалась и на которого равнялась. Выступления на конференциях в большинстве своём казались поверхностными, а отсутствие стратегии обескураживало. Я просто всегда чувствовала, что я другая.

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

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

Поздравляю, вы поняли, что занимаетесь не своим делом.

В момент осознания этого факта приходят 2 эмоции: радость от того, что наконец разобралась в себе, и фрустрация/стресс/депрессия от того, что понятия не имеешь, что твоё.
Тогда какой следующий шаг? Как понять, чем нужно заниматься дальше? Что принесёт драйв и яркие эмоции?

🕵🏻‍♀ 1. Проанализиуйте прошлый опыт. Сосредоточтесь на вещах, которые правда доставляли удовольствие. Я училась в ИТ классе в школе и в начальных классах мне нравилось писать код для черепашки Logo, а в старших я создавала сайты с помощью конструкторов и растила engagement на них. Меня штырили количественные исследования и анализ данных в университете, проведение глубинных интервью в Unilever. Меня драйвили оптимизация воронок и конверсий в моей повседневной работе. И ничего из этого не имело отношения к моей day-to-day работе тогда, но имеет сейчас.

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

🎠 3. Пробуйте разное. Когда я поняла, что хочу перейти в бизнес, я начала пробовать все на свете. У меня был отличный батут: как руководитель команды подбора я имела доступ к любой функции внутри Делойта. Сначала я заинтересовалась корпоративными финансами и оценкой бизнеса, построила две DCF модели. И мне вроде как понравилось. Особенно раскладывать бизнес на факторы потенциального роста и думать, за счёт чего он будет приносить больше денег. Я думала перейти в классический консалтинг и внедрять ИТ решения клиентам. Но я никогда не хотела замыкаться на чем-то столь узком как роль SAP консультанта. Даже на несколько решений и модулей.

🆘 4. Если совсем запутались и без помощи не справляетесь, обратитесь к карьерному консультанту. Я не буду никого рекомендовать, но знаю успешные случаи.

Честно? Мне просто повезло найти себя в тот момент, когда я себя потеряла. Меня позвали на интервью в Яндекс.Такси на тимлида по рекрутменту, и потенциальный руководитель сказал, что ем убраться мой мозг и что он отправит мне тест, который обычно отправляет продакт менеджерам. И после этого интервью я пошла погуглить, кто такие продакты, что они делают. И провалилась. Помню, как на даче (с ужасным интернетом) пыталась смотреть видео про UX/UI и переходить дальше и дальше, все глубже погружаюсь в новое для себя (но такое захватывающее) направление.

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

Скорее всего, вы не умеете развиваться.

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

Так как нужно структурировать свое развитие, чтобы это приносило пользу?

🏆 1. Определитесь с тем, чего хотите достигнуть в течение хотя бы 5 лет. Это важный пункт для выстраивания всей цепи развития. Если не знать, к чему хочешь прийти в долгосрочной перспективе, то не очень понятно, какой следующий шаг. Большие цели помогают мечтать и идти вперёд. Причем важна не только карьерная осознанность, но и общее ощущение в жизни. Может быть, корпоративная карьера не приносит вам удовлетворения. Тогда надо почувствовать, что приносит. Но если совсем не знаете, чего хотите в будущем, переходите сразу к шагу 3.

🌈 2. Постройте реалистичный карьерный путь. Играем в Яндекс.Навигатор: прокладываем маршрут из текущей роли в идеальную будущую. Какие опыты нужно получить? Какие компетенции приобрести? Какие смежные функции попробовать? Какие роли и проекты смогут помочь этого достичь? Когда появятся ответы на эти вопросы, вы будете готовы построить карьерную карту. Лучше сделать несколько вариантов, чтобы не зацикливаться на одном пути.

🏹 3. Определите, какой следующий шаг и узнайте, что на нем ожидается. Если есть карьерная карта, то становится совсем просто: берём свой следующий шаг из неё и смотрим, какие компетенции нужны для успешной работы на нем (если карьерной карты нет, то просто подумайте о том, какой для вас следующий желаемый и реалистичный переход). Узнать список требуемых компетенций можно в компании (часто HRы или руководители ведут такие списки). Если компания такого не предоставляет, то можно ориентироваться на рыночные бенчмарки (идти и гуглить "навыки senior product manager"). Помните, что важны не только hard skills, но и soft. И soft skills надо обязательно разложить на базовые компетенции.

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

📊 5. Проведите GAP анализ: сопоставьте результаты обратной связи и требования к будущей должности. Скорее всего у вас образуется список из 2-5 компетенций к прокачке.

📇 6. Составьте план развития на год. Помните, что в нем должно быть не более 4 компетенций (больше просто вызовет расфокусировку), а также должен быть баланс между hard и soft skills. Детальнее про составление качественного плана я расскажу на неделе.

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

Делаем план развития на год (реальный пример)

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

🔢 1. Определяем список компетенций к развитию. Важно, что компетенций не должно быть меньше двух и не больше четырех. Обычно на начальном уровне имеет смысл брать в план развития больше функциональных (технических) компетенций, а на более зрелом - больше лидерских.
Я взяла 2 лидерские и 1 техническую компетенции.
Вот мой список:
- Отношения с коллегами 👩‍👩‍👦‍👦 (лидерская, пришла из фидбека)
- Стратегическое мышление 🧠 (лидерская, основная компетенция роли, выявлена путем gap-самооценки)
- Работа с данными/ аналитика, advanced 📉 (техническая, пришла из фидбека с входного собеседования)
Важно, что "набирать" в план развития себе можно только те компетенции, которые я смогу прокачать на текущем месте работы на ежедневных задачах. Например, я могу сколько угодно ставить себе в развитие юнит-экономику, но хоть тресни, на внутренних продуктах я её не прокачаю.

🎯 2. Пишем, к чему мы хотим прийти в конце года по компетенции.
Давайте сконцентрируемся на компетенции Стратегическое видение.
Цель:
- Выравниваю стратегию бизнеса со стратегией продукта;
- Ориентирована на масштабируемые решения.

📝 3. Распишем, как будем развивать компетенции по 4Е или 70/20/10. Что это за непонятные термины? Это названия моделей развития: 4Е Берсина (применяется, например, в Делойте) и 70/20/10 (моя любимая модель, применяется в Марсе). Они в целом про одно и то же.
Обе говорят про то, что невозможно развить компетенцию, просто читая книги и посещая тренинги. Развитие приходит в основном из реальной работы над задачами и общения с ментором.
70% развития компетенций - работа на проектах и изо дня в день;
20% - обучение на примере других, работа с ментором и обратная связь;
10% - формальное обучение (книги и тренинги).
В модели 4Е есть четыре кита:
Experience - опыт работы;
Exposure - общение с менторами и экспертами;
Environment - нахождение в развивающией среде, доступ к необходимым материалам;
Education - формальное обучение.
Мне привычнее 70/20/10, поэтому описывать компетенцию будем по этой модели.
Но завтра😁

Продолжение следует...

Ставим цель развития: Стратегическое мышление.

70%, как вы помните, приходит из опыта выполнения реальных задач и проектов. Я не просто так взяла эту компетенцию к развитию: мне нужно будет сделать стратегию для своей линейки продуктов и своего отдела.  Не буду долго сейчас разглагольствовать про создание стратегии для внутренних продуктов, скажу только, что она всегда должна опираться на стратегию бизнеса (Как мы зарабатываем деньги?), а дальше на стратегию того подразделения, для которого создаётся продукт (Какая цель заказчика? Какие ценности?).

⚒ 70%:
1. Изучить бизнес стратегию компании.
2. Изучить стратегию департамента управления персоналом, проанализировать философию и ценности компании.
3. Проанализовать HR и HR tech рынок на предмет релевантных процессов и трендов, на которые можно ссылаться.
4. Проанализировать стратегию внутренних продуктов лидеров рынка на предмет отличных решений и опережения трендов.
5. Провести стратегическую сессию с Заказчиками.
6. Проанализировать бизнес процессы, выявить самые дорогостоящие места, места, где возможен quick win.
7. Создать стратегию для линейки продуктов (3 года) и защитить её у руководства.
8. На основе созданной стратегии сделать роудмап на ближайшие квартал, год.

20% - это среда, получение фидбека и работа с ментором. Что тут важно - найти ментора по компетенции и договориться с ним о периодических встречах. Когда я работала HRBP, я ревьюила планы развития своих сотрудников и с удивлением обнаружила, что я стою у некоторых ментором. Естественно, никаких встреч и никакого развития не происходило. Люди просто поставили меня туда для "отписки". Не надо так делать☹.
При этом, если честно, я часто опускаю 20-ку из плана развития, т.к так много задач, что довольно сложно найти время на менторские встречи. При этом у меня был позитивный опыт, когда мы с ментором просто ходили на обеды и завтраки и обсуждали вопросы, пока ели.

🤼‍♂ 20%:
1. Интеграция в продуктовое комьюнити компании.
2. Поиск ментора по компетенции (срок - середина сентября).
3. Ежемесячные встречи с ментором со структурированной адресной для обсуждения текущих задач по разработке стратегии линейки продуктов/ направления.

📚 10%:
1. Участие во внутреннем тренинге по Стратегии.
2. Книги:
- Harvard Business Review: стратегия;
- Масштабирование приложений: выстраивание сложных систем;
- Блиц-масштабирование: как создать крупный бизнес со скоростью света;
- Платформа. Практическое применение революционной бизнес-модели.

🔻 Дисклеймер: что здесь неправильно. Цели всегда-всегда надо ставить по SMART, то есть в том числе иметь срок выполнения. А ещё должно быть понятно, как я буду оценивать, что цель достигнута. Сейчас мои цели очень условны, т.к не оцифрованы. По сути это черновик, который в ближайшие 3 месяца испытательного срока будет дополняться и редактироваться.

Про SMART цели и изменение плана развития в течение года мы поговорим как-нибудь в другой раз, а в выходные я дам полезные ссылки на материалы, которые помогут составить себе план развития по компетенциям (soft и hard skills).

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

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

📓 1. М. Бакингем, К. Коффман "Сначала нарушьте все правила". Большой талмут от института Гэллапа о компетентностном подходе к развитию. В книге компетенции называются "талантами", а еще сказано, что если у вас нет таланта в чем-то, то не стоит даже пытаться его развить. Я с этим мнением не согласна, все очень сильно зависит от того, какой конкретно навык развивать, и личной мотивации. Но в целом книга будет полезна всем молодым менеджерам, а также тем, кто пытается понять, что за зверь такой эта "компетенция".

🦮 2. Гид по модели развития 70-20-10: расширенная и краткая версии. Гид помогает понять, как структурировать план развития, и какие опыты, взаимодействия и материалы в него эффективно и полезно включать.

💼 3. Гид по модели развития Джоша Берсина 4Е, в которой Берсин сначала нахально объясняет, почему модель 70-20-10 устарела, а потом рассказывает о том, какие элементы позволяют взять контроль над собственным развитием и учиться нон-стоп.

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

🧪 5. Как бонус - ссылка на Gallup StrengthFinder - приложение-тест от института Гэллапа, которое поможет вам понять свои сильные стороны и зоны развития. Тест помогает понять свои склонности (аналитика или построение отношений?) и свой талант номер один, принять его и научиться добиваться за счет него успеха.

Отличного вам развития!

Как собрать бэклог с нуля? Часть 1.
(Применимо для внутренних продуктов и систем автоматизации).

Итак, ты - новый (а ещё страшнее - новый и неопытный) продакт в компании, которая разрабатывает систему автоматизации для себя или для внешних клиентов. Тебе выдали большой кусок функционала или даже всю систему и сказали "Пили!". Знакомо?😅 Мне - да, причём даже не один раз. Поэтому, продолжая традицию писать о том, о чем знаю лучше всего, расскажу, как быть в такой ситуации (спойлер: круто и развивающе).

⚙ 1. Определи границы функционала. Пойми верхнеуровнево, что входит в процесс, который тебе надо автоматизировать. Если это процесс управления эффективностью деятельности, то входит ли в задачу только создание формы для постановки KPI/OKR сотрудникам? Или задача шире и включает в себя наличие каталога целей, формы для выставления годовой оценки? Процесса ежегодной оценки 360°? Функционала автоматизации дискуссий по принятию кадровых решений? Что насчёт отчётности? Собери все большие блоки и запиши их в виде эпиков.

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

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

⁉️ 4. Процесс/ функционал уже как-то внедрен? Если да, сходи на раунд custdev'ов.
Третий шаг важен, но мы же делаем систему для людей, а не для заказчика. Нельзя верить ему на слово, нужно обязательно проверить, что процесс привычен и удобен людям. Я однажды наблюдала абсолютно жуткую ситуацию, когда процесс работал в компании более 10 лет, но люди просто не понимали его и не видели в нем смысла. Если его автоматизировать в таком виде, то мы не принесём компании никакой ценности, кроме того, что удовлетворим какую-нибудь высокоуровневую даму.
На этом этапе важно провести раунд переговоров со стейкхолдерами разного уровня, чтобы убедить их в том, что процесс необходимо менять. Иногда это занимает сильно больше времени, чем хотелось бы.
Что может их мотивировать?
А) Слова "у вас в процессе 11 этапов согласований, вы уверены, что они все нужны?"
Б) Аргументация, что мы сэкономим компании Х денег на сокращении времени.
В) Демонстрация того, что в процессе были рудименты, от которых можно избавиться, не потеряв качества.
Г) Фидбек от пользователей.

Завтра расскажу по пункты 5-10.
Продолжение следует...

Как собрать бэклог с нуля? Часть 2.

💡 5. Выдели бэклог гипотез.
Как только с заказчиком будет принципиально согласован момент того, что процесс можно менять и адаптировать под конечного пользователя, нужно выделить боли, которые были услышаны на интервью. А после - наштормить с командой варианты решений. Я обычно формирую гипотезы в формате Jobs to be done.

✂️ 6. Раздели гипотезы на релизы проверки.
После я делю гипотезы на несколько частей в порядке приоритетности для проверки и реализации. Количество релизов зависит от ситуации, но ключевое - выделить первый пул гипотез и решений для проверки. Приоритеты можно расставлять по разному, для совсем нового функционала обычно подходит фреймворк Moscow, для дорабатывающегося - RICE/ICE.

👩🏼‍🎨 7. Слепи прототип.
Пришло время тестирования на прототипах. Если мне нужно проверить какую-то форму, а не проход по процессу, я делаю интерактивный макет в Excel. Быстрое решение, мне очень нравится его изящность. За 2 часа можно сделать довольно неплохую форму, а для того, чтобы придать ей вид интерфейса, я вставляю картинку шапки моей системы и блокирую те ячейки, в которые нельзя кликать.
Потом я делаю упражнение, которое называю "дизайн исследования": собираю в один файл данные о всех экранах, которые проверяю, гипотезах и джобах, выписываю задания для респондентов, метрики, по которым мы поймём, что гипотеза подтвердилась, а также вопросы, которые задам респонденту после прохождения сценария или после интервью.

🧑🏼‍🔬 8. Проверь прототип.
Время исследования! Найди респондентов и попроси их прощелкать прототип, комментируя свои действия и мысли. Записывай интервью, считай время там, где необходимо.
Лучше сразу подготовить чеклист по подтверждению гипотез, чтобы потом не приходилось пересматривать все записи.

🗂 9. Создай бэклог разработки функционала.
После анализа результатов исследования станет понятно, что надо делать, а что не надо. Причем часто не только по тем гипотезам, которые проверяли, но и по всем процессу. Сделай User Story Map на весь функционал, который ты понимаешь, что надо делать. Если функционал большой, раздели свой USM на эпики.

🔪 10. Выдели MVP.
Скорее всего, у тебя стоит какой-то дедлайн, в который нужно успеть разработать функционал. И скорее всего ты понимаешь, что вы не успеете сделать 100% и не на костылях. Тут тоже надо делить на релизы. Отличное решение - резать фичи и выделять главное. Я всегда использую метод "не MVP". Что можно резать?
- Сложную логику;
- Оптимизации, которые облегчат жизнь малой части пользователей;
- Дублирующиеся элементы (например, у вас есть табличный вид, а хочется ещё и плиточный);
- Сложные фильтры и внутреннюю логику полей и выпадающих списков;
- Красивые экраны, если есть возможность на первый раз упростить;
- Графики, отчёты, если будет возможность извлечь данные из базы;
- Прости господи интеграции.

Все, бэклог готов.
Отличной вам разработки!

Как я собирала бэклог с нуля (реальная история)

Что-то в прошлых двух постах было довольно много теории о том, как надо, и не было рассказа о том, как же это происходит на самом деле. Исправлюсь - ловите историю о моем жизненном опыте с бэклогом😅

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

🥽 1. Определяем границы функционала.
Я знала, что мне надо сдавать 2 больших модуля моего продукта: модуль, который отвечает за управление эффективностью деятельности сотрудников (УЭД), и базовый модуль. Звучит максимально размыто, поэтому первым делом я пошла к моему тимлиду бизнес аналитики, который в то время назывался прости господи "функциональный архитектор", чтобы он погрузил меня в контекст и помог разбить на эпики. Так как мы импортозамещали текущее решение, мы посмотрели в инструкции прошлой версии  и в требования к новому продукту (ТЗ). Верхнеуровневый набор фич был готов.

⚡️ 2. Понимаем, что уже сделано.
Так как передо мной стояла задача сдать часть продукта (MVP) до конца года. Но как понять, что надо сдать, а что не надо? И что вообще входит в понятие "надо" вплоть до user stories?
У меня была довольно большая команда, поэтому я собрала системных аналитиков, тимлида бизнес анализа и тимлида разработки в "рабочую группу" по сбору бэклога. Тимлиж разработки провел нам демо продукта, показал, что уже сделано, что нет, что сделано на костылях, а что - просто красивая картинка на фронте.
При этом тимлид бизнес аналитики комментировал фичи и говорил, где готово, где нет, что есть в предыдущем решении, без чего нельзя прожить (за общение с пользователями отвечала его команда). Мы вместе декомпозировали каждый эпик до user stories, которые мы помечали тремя цветами: красный =MVP, жёлтый = не MVP, фиолетовый = готово. У нас получилось в районе 300 карточек на доске в Miro.

🌚 3. Собираем требования у основного стейкхолдера.
Следующей интеграцией я собрала встречу с основным заказчиком, где показала ему наши наработки и цветовую легенду. Так как он был спонсором проекта и держателем методологии, никто кроме него не мог подтвердить нам, правильно ли мы выделили MVP. Спустя несколько встреч мы определились с тем, что хотелось бы сделать и добавили новый цвет - оранжевый. Он значил "если влезет, то MVP".

🌊 4. Понимаем, влезет ли.
Только как определить, что мы успеем сделать в этом году, а что нет? Мы собрали очередную рабочую группу из аналитиков (они описывали требования), тимлида дизайна, техлида и тимлида разработки. Мы шли по каждой истории и оценивали её в сторипоинтах. Так мы посчитали, что у нам надо сделать 200 сторипоинтов на фронт и 200 на бэк.
И чего?

🌪 5. Понимаем велосити команды.
Если команда зрелая, то тут все понятно. Эта цифра известна. У нас было не так. Было 2 скрам команды, в одной было 7 разработчиков, в другой 10 (ужас, знаю). Но после нескольких этапов приседаний и выгрузки аналитики из Jira я поняла, что в спринт в команду влезает где-то 40 сторипоинтов.

⚔ 6. Режем MVP.
В идеальном мире, где бегают единороги и розовые пони, мы бы успели сделать все за 10 спринтов. У нас было 3.5 месяца - 7 спринтов. Надо было с царского разрешения заказчика резать функционал большим ножом мясника.

🧑🏼‍💻 7. Разрабатываем!

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

Продолжение следует😉

Документация сложных систем. Часть 1.

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

Почему нет? Во-первых, если мы автоматизируем с нуля, то отдаём в работу совершенно новый процесс. Мы не говорим "нам нужен лендинг с картинками и одним call to action", мы говорим "мы делаем новый процесс постановки и согласования целей для сотрудников". И повезло ещё, если разработчики как мои сейчас, которые полгода жили без продакта и ходили сами к бизнесу выяснять требования. Тогда они понимают, о чем речь, как работает HR.
А если разработчикам надо объяснить, что такое вообще "постановка целей", то рассказом на пальцах и тасками в джире не отделаться.

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

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

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

После продолжительной рефлексии я поняла, что мне нужны:

🔗 Флоу процесса разного уровня детализации.

👨‍👦‍👦 Роли, кто в них попадает и описание ролевой модель.

📺 Описание экранов, правил и сценариев на них.

📏 Описание шкал и справочников.

💌 Все, что связано с уведомлениями из системы.

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

Документация сложных систем. Часть 2.

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

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

3. Роли, которые участвуют в процессе. Кто получает доступ к процессу, какими атрибутами эти люди обладают. По каким правилам люди получают те или иные роли. Зачем эти роли участвуют в процессе, какая их цель. Это будут верхнеуровневые User Stories, которые мы потом будем декомпозировать.

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

5. Описание сценариев работы каждой экранной формы. Здесь я описываю необходимые поля на каждой форме, обязательны они к заполнению или нет, по каким правилам предзаполняются и из каких справочников заполняются их значения. А также необходимые условия каждого поля для определения ошибок валидации.
В use case, описывая логику работы системы, я стараюсь не цепляться к описанию конкретных элементов дизайна и кнопок, а говорю, что, например, мне нужна "возможность" создать форму, чтобы дать простор фантазии дизайнеру.

6. Собственно шкалы и справочники, которые используются в формах.

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

8. Шаблоны уведомлений, которые будут приходить пользователям (тексты).

9. Ролевая модель. Огромная таблица, где показано, какие роли имеют доступы к форме на каждом этапе, а если имеют, то к каким полям и кнопкам (и с каким уровнем власти: просмотр, редактирование, удаление).

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

Ну а пока пришло время идти писать юз кейсы😏

Боль работать над внутренним продуктом. Часть 1.

Выражу популярное мнение: быть продактом – классно. А еще очень больно. И, есть такой шанс, что над внутренним продуктом работать в два раза больнее, чем над внешним. И в 2 раза интереснее.
Давайте разбираться, так ли это. Тут будет 2 части про боль и 1 часть про удовольствие.

🌏 1. Ресурсы. Продакт – это не проджект, не дизайнер, не специалист центра поддержки, не бизнес аналитик и не системный. Но на внутренних продуктах часто приходится быть всем одновременно, так как мало ресурсов, и наш продукт не всегда приоритетный, а чаще всего наоборот гораздо менее приоритетный, чем внешний. И мы можем ходить месяцами и просить ресурс, например, дизайнера, или дополнительного разработчика, но не получать, потому что в бутылочное горлышко влезает только один человек, и он нужен на внешнем продукте. И приходится либо страдать без роли, либо делать работу самим. Спойлер - чаще всего самим.
👨🏻 2. Ограниченное число пользователей. Кто наши пользовали? Самая большая выборка - все сотрудники компании. Потом сужаем - все руководители. Еще сужаем - все HRы. И до максимума: все специалисты поддержки системы. Тут не очень просто (и не всегда возможно) играть с данными, делать А/В, следить за метриками и вообще их иметь, если продукт супер локальный. Но при этом есть несколько лидеров мнений на компанию, чей вижн на продукт может влиять на всех остальных сотрудников (и в том числе в негативную сторону).
💸 3. Сложно понять выхлоп для компании. На внешних продуктах обычно просто понять, как тот или иной шаг повлиял на ключевые финансовые метрики. Поменял цвет кнопки, увеличил конверсию в покупку на Х, выручка возросла на Y. А если мы запилим интеграцию системы рекрутера с платформой тестирования для кандидатов? Как мы повлияем на метрики? Приходит в голову 2 ответа: "я х3" и "да никак". А потом вопрос: а зачем нам вообще тестирования? Может, отказаться от них и сэкономили бы и на лицензии, и на интеграции? Внутреннему продакту всегда нужно задаваться такими вопросами и считать метрики бизнес-процессов и то, как их оптимизация сэкономит время людей, ведь время - тоже деньги.
🦮 4. Не все понимают, зачем им продакт. Если компания продуктовая (thank god я сейчас в такой), то вопросов меньше, но если, например, индустриальная компания или консалтинговая нанимает продакта, то им нужен мессия, который потушит все пожары, подружит всех стейкхолдеров и запустит в срок проект. Поэтому в большинстве случаев они ожидают проджекта, который просто соберет с них хотелки, опишет и проконтролирует разработку. Как вы понимаете, это изначально неверный вижн, с которым надо работать, но очень уж сложно. Особенно когда заказчики - HRы, которые хотят в каждый процесс внести методологический смысл, а простые пользователи (сюрприз!) этот смысл не покупают. Из чего рождается следующая боль:
🗿 5. Стейкхолдеры VS решения для людей. HR процессы сложные, неочевидные и в России везде разные. Спросите у 5 компаний, как они делают performance review, каждая из них вам расскажет похожие истории, но совершенно разные с точки зрения экзекьюшна. И чаще всего HR процессы диктуются сверху: глобальной командой, СЕО или HR директором. HRы собираются в кружок и придумывают вместе, какими смыслами нужно наполнить методологию, чтобы принести максимальную пользу. Но они делают это, не спросив в у пользователей, а что, собственно, им надо. И получается, что одни придумывают классные процессы и people стратегию, а вторые хотят прозрачности и решения своих болей. И продакту нужно и верхнеуровневый стейкхолдеров не обидеть, и сделать так, чтобы конечные пользователи после релиза не проткнули его вилами. В идеальной картине нужно найти золотую середину или убедить стейкхолдера слушать пользователей, но, как вы понимаете, чем-то иногда приходится жертвовать.

Продолжение следует...

Насколько больно работать над внутренним продуктом? Часть 2.

🆙 6. Стратегия всегда будет через один уровень. У любого внутреннего продукта должна быть стратегия развития, из которой следует роудмап. Иначе это не продукт, а проект, который был сделан как скриншот состояния бизнеса на тот момент и не будет соответствовать потребностям пользователей и функции через N лет. Но оторвана от реальности стратегия тоже не может быть, мы же в бизнесе работаем и хотим заработать компании деньги. Итого мы получаем, что у нас есть стратегия бизнеса. Она каскадируется на определенную функцию – в моем случае на HR. И только от HR стратегии мы уже можем отстраивать стратегию нашего продукта. Иначе у нас получится шикарный шаттл на автопилоте, который стоит в далеком селе и взлететь не может, потому что жители и старейшина села готовы только на быстрых лошадях ездить. Усложняется эта история если стратегии функции нет в принципе или если она никак не соотносится со стратегией бизнеса.
🔪 7. Пользователи всегда знают, где нас искать. Если мы выкатим какую-то фичу, которая разозлит часть пользователей, они не постесняются выразить свое негодование. У меня был кейс, когда мы делали продукт для подбора персонала и реализовали решение, которое требовало от всех рекрутеров вносить кандидатов в систему и заполнять обязательные поля. В тот момент внесение руками одного кандидата в систему занимало от 2 до 6 минут. И двое рекрутеров не гнушались в довольно жестком формате высказывать мне все свои фи по этому поводу. При этом откатить решение мы никак не могли, т.к оно было обусловлено требованиями топ-менеджмента и несло долгосрочную ценность, и упросить быстро жизнь рекрутеров тоже не могли, т.к у функции не было бюджета на робота или внешнюю интеграцию. Приходилось терпеть.
🎤 8. У нас нет маркетинга, у нас есть change management. Если он есть. Представьте, мы реализовали новую фичу во внутренней системе, которая часто или автоматизирует их текущий процесс, или запускает новый, о котором они пока не знают. Как нам обеспечить использование этой функции во всех филиалах? Рассылки сотрудники не читают, инструкции не читают, в Yammer не заходят, на zoom-тренинги не доходят, в офисе больше не появляются и плакаты в коридоре не видят. Обычно какие-то из этих инструментов частично работают, но все равно довольно сложно поменять поведение и привычные сценарии людей и заставить работать по-новому. Часто нужно привлекать большое количество людей-амбассадоров изменений, использовать много каналов в разное время на разные внутренние аудитории.
🙊 9. Часто у пользователей нет выбора. Если мы автоматизируем внутренний процесс, то по большей части сотрудники будут обязаны его использовать. Поэтому стейкхолдеры задаются вопросом: а зачем тратить время и деньги на то, чтобы эта обязанность была еще и удобной? Я много раз слышала фразы вроде «мы скажем, они будут использовать». Если стейкхолдеры будут придерживаться такого подхода, то шанс достигнуть product/market fit будет нулевой, наши решения будут будут бесить всех своей неудобностью, ненужностью и сложностью. Мы никогда не услышим «спасибо» за реализованный функционал и будем демотивироваться тем, что наши разработки не делают людей счастливыми, а заставляют страдать.
💡 10. Мало возможностей для инноваций. Они есть, правда. Как-то я работала с компанией, которая каждый мелкий подпроцесс была готова обвязать искусственным интеллектом, потому что это стильно-модно-молодежно, запускала по 10 новых внутренних продуктов в год и давала добро на разработку мобилки до того, как была выкачена web версия. Но для этого нужны и большие бюджеты, и вовлеченные стейкхолдеры, и зрелые процессы. Сочетание этих трех факторов у нас не очень часто встречается на внутренних продуктах.
Звучит все это больно и сложно, но многие проблемы можно решить грамотной работой со стейкхолдерами и выстраиванием процессов аналитики. И не перечеркивает тех удовольствий, которые может дать работа над внутренним продуктом.
О них – в следующий раз.