Делаем план развития на год (реальный пример)
Вчера мы выбрали себе долгосрочную карьерную цель, построили карьерную карту, как до нижней дойти, определили следующий карьерный шаг и собрали фидбек.
Теперь наша задача сделать себе классный план развития, который поможет двигаться вверх и преодолевать слабые стороны.
Всегда лучше смотреть на примере, поэтому давайте рассмотрим часть моего плана развития. Я только недавно официально стала старшим менеджером продукта, и некоторые навыки синиора мне ещё нужно прокачать.
🔢 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, поэтому описывать компетенцию будем по этой модели.
Но завтра😁
Продолжение следует...
Вчера мы выбрали себе долгосрочную карьерную цель, построили карьерную карту, как до нижней дойти, определили следующий карьерный шаг и собрали фидбек.
Теперь наша задача сделать себе классный план развития, который поможет двигаться вверх и преодолевать слабые стороны.
Всегда лучше смотреть на примере, поэтому давайте рассмотрим часть моего плана развития. Я только недавно официально стала старшим менеджером продукта, и некоторые навыки синиора мне ещё нужно прокачать.
🔢 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).
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. М. Бакингем, К. Коффман "Сначала нарушьте все правила". Большой талмут от института Гэллапа о компетентностном подходе к развитию. В книге компетенции называются "талантами", а еще сказано, что если у вас нет таланта в чем-то, то не стоит даже пытаться его развить. Я с этим мнением не согласна, все очень сильно зависит от того, какой конкретно навык развивать, и личной мотивации. Но в целом книга будет полезна всем молодым менеджерам, а также тем, кто пытается понять, что за зверь такой эта "компетенция".
🦮 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.
Продолжение следует...
(Применимо для внутренних продуктов и систем автоматизации).
Итак, ты - новый (а ещё страшнее - новый и неопытный) продакт в компании, которая разрабатывает систему автоматизации для себя или для внешних клиентов. Тебе выдали большой кусок функционала или даже всю систему и сказали "Пили!". Знакомо?😅 Мне - да, причём даже не один раз. Поэтому, продолжая традицию писать о том, о чем знаю лучше всего, расскажу, как быть в такой ситуации (спойлер: круто и развивающе).
⚙ 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". Что можно резать?
- Сложную логику;
- Оптимизации, которые облегчат жизнь малой части пользователей;
- Дублирующиеся элементы (например, у вас есть табличный вид, а хочется ещё и плиточный);
- Сложные фильтры и внутреннюю логику полей и выпадающих списков;
- Красивые экраны, если есть возможность на первый раз упростить;
- Графики, отчёты, если будет возможность извлечь данные из базы;
- Прости господи интеграции.
Все, бэклог готов.
Отличной вам разработки!
💡 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! Как внедрять исследования в процесс, где их никогда не было, и как дизайнить тестирования прототипов, я расскажу в другой раз.
Продолжение следует😉
Что-то в прошлых двух постах было довольно много теории о том, как надо, и не было рассказа о том, как же это происходит на самом деле. Исправлюсь - ловите историю о моем жизненном опыте с бэклогом😅
Когда я пришла на прошлое место работы разрабатывать систему автоматизации 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.
А если разработчикам надо объяснить, что такое вообще "постановка целей", то рассказом на пальцах и тасками в джире не отделаться.
Я до недавнего времени не писала документацию. Как-то так повезло, что у меня была команда аналитиков, которая этим занималась. Периодически конечные потребители этой документации были недовольны, но у команды никогда не доходили руки зафиналить критерии приёмки бизнес требований (так, чтобы было понятно системным аналитикам и дизайнерам).
Сейчас у нас нет бизнес документации, так как вести её было некому. Есть несколько инструкций по работе с системой, но, конечно, они покрывают не все. Когда я только вышла, мне было не очень просто въехать в процесс без какого-либо описания, я просила ссылки на архитектуру, тыкала в прод и спрашивала у людей.
И сегодня пришёл тот день, когда я работаю без аналитиков и должна сама понять, какой структурой бизнес требований я буду довольна.
После продолжительной рефлексии я поняла, что мне нужны:
🔗 Флоу процесса разного уровня детализации.
👨👦👦 Роли, кто в них попадает и описание ролевой модель.
📺 Описание экранов, правил и сценариев на них.
📏 Описание шкал и справочников.
💌 Все, что связано с уведомлениями из системы.
Детальнее про каждый раздел документации я расскажу завтра, я сегодня пора заканчивать прокрастинацию и начинать писать требования😉
Рефлексия и желание поделиться помогает не прокрастинировать. Так что поехали.
Написание документации или ТЗ - такая вещь, которую ненавидит практически любой продакт. Неудивительно - мы просто по своему типу личности больше склонны к другим задачам (про это можно почитать у Адизеса в "Стилях лидерства"). И ладно завести задачку на одну фичу в джиру на добавление кнопочки или внутренней логики. Вроде тут все понятно, пишешь решение в задачку, описываешь критерии приёмки, которых не очень много обычно, прикрепляешь макет, разработчики сами создают подзадачи. Но с большими системами такое не прокатит.
Почему нет? Во-первых, если мы автоматизируем с нуля, то отдаём в работу совершенно новый процесс. Мы не говорим "нам нужен лендинг с картинками и одним call to action", мы говорим "мы делаем новый процесс постановки и согласования целей для сотрудников". И повезло ещё, если разработчики как мои сейчас, которые полгода жили без продакта и ходили сами к бизнесу выяснять требования. Тогда они понимают, о чем речь, как работает HR.
А если разработчикам надо объяснить, что такое вообще "постановка целей", то рассказом на пальцах и тасками в джире не отделаться.
Я до недавнего времени не писала документацию. Как-то так повезло, что у меня была команда аналитиков, которая этим занималась. Периодически конечные потребители этой документации были недовольны, но у команды никогда не доходили руки зафиналить критерии приёмки бизнес требований (так, чтобы было понятно системным аналитикам и дизайнерам).
Сейчас у нас нет бизнес документации, так как вести её было некому. Есть несколько инструкций по работе с системой, но, конечно, они покрывают не все. Когда я только вышла, мне было не очень просто въехать в процесс без какого-либо описания, я просила ссылки на архитектуру, тыкала в прод и спрашивала у людей.
И сегодня пришёл тот день, когда я работаю без аналитиков и должна сама понять, какой структурой бизнес требований я буду довольна.
После продолжительной рефлексии я поняла, что мне нужны:
🔗 Флоу процесса разного уровня детализации.
👨👦👦 Роли, кто в них попадает и описание ролевой модель.
📺 Описание экранов, правил и сценариев на них.
📏 Описание шкал и справочников.
💌 Все, что связано с уведомлениями из системы.
Детальнее про каждый раздел документации я расскажу завтра, я сегодня пора заканчивать прокрастинацию и начинать писать требования😉
Документация сложных систем. Часть 2.
1. Верхнеуровневый флоу процесса. Нужен мне для того, чтобы определить статусную модель форм и документов, которые участвуют в процессе.
2. Детализированный флоу. Возможно, избыточная схема для разработки, но точно понадобится мне для понимания того, какие вопросы мне ещё надо проработать, и точно будет полезна дизайнеру. Чем детальнее я представляю процесс на каждом его шаге, тем лучше я смогу прописать сам пользовательский сценарий.
3. Роли, которые участвуют в процессе. Кто получает доступ к процессу, какими атрибутами эти люди обладают. По каким правилам люди получают те или иные роли. Зачем эти роли участвуют в процессе, какая их цель. Это будут верхнеуровневые User Stories, которые мы потом будем декомпозировать.
4. Количество экранных форм, которые я ожидаю от дизайнера. Такое я пишу всегда для декомпозиции задач на дизайн и для упрощения принятия работ. Очень больно, когда вдруг в середине разработки понимаешь, что не хватает макета из середины процесса (проверено на себе).
5. Описание сценариев работы каждой экранной формы. Здесь я описываю необходимые поля на каждой форме, обязательны они к заполнению или нет, по каким правилам предзаполняются и из каких справочников заполняются их значения. А также необходимые условия каждого поля для определения ошибок валидации.
В use case, описывая логику работы системы, я стараюсь не цепляться к описанию конкретных элементов дизайна и кнопок, а говорю, что, например, мне нужна "возможность" создать форму, чтобы дать простор фантазии дизайнеру.
6. Собственно шкалы и справочники, которые используются в формах.
7. Модель задач и уведомлений. Таблица всех этапов процессов и всех ролей, в которой указаны события, которые запускают отправку системного уведомления в нужный момент.
8. Шаблоны уведомлений, которые будут приходить пользователям (тексты).
9. Ролевая модель. Огромная таблица, где показано, какие роли имеют доступы к форме на каждом этапе, а если имеют, то к каким полям и кнопкам (и с каким уровнем власти: просмотр, редактирование, удаление).
Это чисто моё видение необходимой документакции, которое родилось из опыта работы с аналитиками и передачи в поддержку частей функционала SAP (для этого надо было отгрузить кучу документации).
Я думаю, что формат бизнес требований я буду улучшать итеративно, когда лучше пойму, что точно нужно команде.
Ну а пока пришло время идти писать юз кейсы😏
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 раза интереснее.
Давайте разбираться, так ли это. Тут будет 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 версия. Но для этого нужны и большие бюджеты, и вовлеченные стейкхолдеры, и зрелые процессы. Сочетание этих трех факторов у нас не очень часто встречается на внутренних продуктах.
Звучит все это больно и сложно, но многие проблемы можно решить грамотной работой со стейкхолдерами и выстраиванием процессов аналитики. И не перечеркивает тех удовольствий, которые может дать работа над внутренним продуктом.
О них – в следующий раз.
🆙 6. Стратегия всегда будет через один уровень. У любого внутреннего продукта должна быть стратегия развития, из которой следует роудмап. Иначе это не продукт, а проект, который был сделан как скриншот состояния бизнеса на тот момент и не будет соответствовать потребностям пользователей и функции через N лет. Но оторвана от реальности стратегия тоже не может быть, мы же в бизнесе работаем и хотим заработать компании деньги. Итого мы получаем, что у нас есть стратегия бизнеса. Она каскадируется на определенную функцию – в моем случае на HR. И только от HR стратегии мы уже можем отстраивать стратегию нашего продукта. Иначе у нас получится шикарный шаттл на автопилоте, который стоит в далеком селе и взлететь не может, потому что жители и старейшина села готовы только на быстрых лошадях ездить. Усложняется эта история если стратегии функции нет в принципе или если она никак не соотносится со стратегией бизнеса.
🔪 7. Пользователи всегда знают, где нас искать. Если мы выкатим какую-то фичу, которая разозлит часть пользователей, они не постесняются выразить свое негодование. У меня был кейс, когда мы делали продукт для подбора персонала и реализовали решение, которое требовало от всех рекрутеров вносить кандидатов в систему и заполнять обязательные поля. В тот момент внесение руками одного кандидата в систему занимало от 2 до 6 минут. И двое рекрутеров не гнушались в довольно жестком формате высказывать мне все свои фи по этому поводу. При этом откатить решение мы никак не могли, т.к оно было обусловлено требованиями топ-менеджмента и несло долгосрочную ценность, и упросить быстро жизнь рекрутеров тоже не могли, т.к у функции не было бюджета на робота или внешнюю интеграцию. Приходилось терпеть.
🎤 8. У нас нет маркетинга, у нас есть change management. Если он есть. Представьте, мы реализовали новую фичу во внутренней системе, которая часто или автоматизирует их текущий процесс, или запускает новый, о котором они пока не знают. Как нам обеспечить использование этой функции во всех филиалах? Рассылки сотрудники не читают, инструкции не читают, в Yammer не заходят, на zoom-тренинги не доходят, в офисе больше не появляются и плакаты в коридоре не видят. Обычно какие-то из этих инструментов частично работают, но все равно довольно сложно поменять поведение и привычные сценарии людей и заставить работать по-новому. Часто нужно привлекать большое количество людей-амбассадоров изменений, использовать много каналов в разное время на разные внутренние аудитории.
🙊 9. Часто у пользователей нет выбора. Если мы автоматизируем внутренний процесс, то по большей части сотрудники будут обязаны его использовать. Поэтому стейкхолдеры задаются вопросом: а зачем тратить время и деньги на то, чтобы эта обязанность была еще и удобной? Я много раз слышала фразы вроде «мы скажем, они будут использовать». Если стейкхолдеры будут придерживаться такого подхода, то шанс достигнуть product/market fit будет нулевой, наши решения будут будут бесить всех своей неудобностью, ненужностью и сложностью. Мы никогда не услышим «спасибо» за реализованный функционал и будем демотивироваться тем, что наши разработки не делают людей счастливыми, а заставляют страдать.
💡 10. Мало возможностей для инноваций. Они есть, правда. Как-то я работала с компанией, которая каждый мелкий подпроцесс была готова обвязать искусственным интеллектом, потому что это стильно-модно-молодежно, запускала по 10 новых внутренних продуктов в год и давала добро на разработку мобилки до того, как была выкачена web версия. Но для этого нужны и большие бюджеты, и вовлеченные стейкхолдеры, и зрелые процессы. Сочетание этих трех факторов у нас не очень часто встречается на внутренних продуктах.
Звучит все это больно и сложно, но многие проблемы можно решить грамотной работой со стейкхолдерами и выстраиванием процессов аналитики. И не перечеркивает тех удовольствий, которые может дать работа над внутренним продуктом.
О них – в следующий раз.
Удовольствие работать над внутренним продуктом.
Наблюдение: писать в формате «бомбежка» гораздо проще, чем писать о том, что нравится. Но за всеми прошлыми эмоциями о болях можно было упустить самое главное: мне дико нравится моя работа. Даже когда я страдала на прошлом месте работы из-за внешних факторов, меня никогда так не штырило от того, что я делаю.
И я искренне верю, что для некоторых людей работа над внутренним продуктом может быть интереснее, чем над внешним, и вот почему.
🎨 1. Можно создавать несколько продуктов одновременно. Как часто бывает на внешнем продукте: в компании много продактов, и нам выделили маленькую его часть, над которой нужно работать. И все решения будут касаться этого маленького кусочка. Прикольно, есть влияние на деньги, но может надоесть, так как охват ограничен. На внутренних продуктах нет ресурсов на много продактов, поэтому один человек может отвечать за все. На прошлом месте работы я одновременно делала 4 больших модуля системы, каждый из которых станет на рынке отдельным продуктом, сейчас у меня в охвате управления внутренний корпоративный портал, продукт для обучения, продукт для рекрутмента и продукт для performance management. И никогда не будет скучно, потому что просто бесконечность того, что можно поделать, и бэклог длиною с жизнь.
🔨 2. Мы создаем довольно сложные продукты. Что еще крутого – внутренние продукты автоматизируют какой-то бизнес-процесс. Поэтому мы делаем не лэндинги и не понятные решения вроде интернет-магазинов, мы делаем большие Системы, в которых куча всего сложного и интересного. Цепочки согласований, пересекающиеся сущности, задачи и уведомления, логирование событий, ролевые модели, какие-то шины, которые нам будут позволять стучаться в систему из внешних систем, интеграции. А во многих внутренних продуктах даже есть ML элементы. Во всем этом надо разобраться, что нереально прокачивает.
👩❤️👨 3. Пользователи всегда знают, где нас найти. Про это писала в болях, но в этом и много плюсов, это же постоянная прямая линия с нашими конечными потребителями. Сейчас у меня есть чат, в который все пользовали пишут свои баги, вопросы и предложения. А еще есть отдельная страница в Confluence, куда они могут заводить фича реквесты и голосовать за понравившиеся. Нам очень просто найти людей на custdev или UX, достаточно просто кинуть клич в Slack. Нам не нужно через несколько слоев иерархии рваться к пользователям, они уже среди нас. И из-за того, что они так близко и так похожи на нас, мы можем сделать для них еще более крутое решение.
⚙ 4. В процессе мы делаем кучу оптимизаций. Кейс: мы хотим запилить интеграцию системы рекрутера с платформой тестирования для кандидатов. Мы уже задали себе вопросы: а зачем нам вообще тестирования? Может, отказаться от них? Мы начинаем анализировать ситуацию. В нашем случае наличие тестов на позиции массового поиска экономит рекрутеру час времени на общение с одним кандидатом, что при наличии условного потока в 200 кандидатов в месяц высвободит 200 часов. Дальше считаем бизнес кейс интеграции. Сейчас рекрутер тратит 7 минут на то, чтобы завести одного кандидата в тестовую систему, отправить ему нужную методику, проверить, прошел ли кандидат тест, а потом выгрузить результаты и занести в свой трекер. При таком же условном потоке кандидатов это почти три рабочих дня в месяц на оперативку. Интеграция позволит нам отправлять тесты и извлекать результаты мгновенно. Сравниваем стоимость потерянного времени и стоимость интеграции и решаем пилить.
И такие задачи нам нужно решать каждый день.
⚡️ 5. Мы невероятно быстро покачиваем навыки. Одному продакту приходится погружаться во все, даже еще сильнее, чем на внешнем продукте. Мы сразу отвечаем и за стратегию, и за все метрики, и за все требования, и за все исследования, а когда начинаем зарубаться со стейкхолдерами, то с космической скоростью начинают развиваться наши лидерские качества и прочие гибкие навыки.
Бонус: Пользователь точно будет использовать наш продукт😂. Ведь у него просто нет выбора.
Наблюдение: писать в формате «бомбежка» гораздо проще, чем писать о том, что нравится. Но за всеми прошлыми эмоциями о болях можно было упустить самое главное: мне дико нравится моя работа. Даже когда я страдала на прошлом месте работы из-за внешних факторов, меня никогда так не штырило от того, что я делаю.
И я искренне верю, что для некоторых людей работа над внутренним продуктом может быть интереснее, чем над внешним, и вот почему.
🎨 1. Можно создавать несколько продуктов одновременно. Как часто бывает на внешнем продукте: в компании много продактов, и нам выделили маленькую его часть, над которой нужно работать. И все решения будут касаться этого маленького кусочка. Прикольно, есть влияние на деньги, но может надоесть, так как охват ограничен. На внутренних продуктах нет ресурсов на много продактов, поэтому один человек может отвечать за все. На прошлом месте работы я одновременно делала 4 больших модуля системы, каждый из которых станет на рынке отдельным продуктом, сейчас у меня в охвате управления внутренний корпоративный портал, продукт для обучения, продукт для рекрутмента и продукт для performance management. И никогда не будет скучно, потому что просто бесконечность того, что можно поделать, и бэклог длиною с жизнь.
🔨 2. Мы создаем довольно сложные продукты. Что еще крутого – внутренние продукты автоматизируют какой-то бизнес-процесс. Поэтому мы делаем не лэндинги и не понятные решения вроде интернет-магазинов, мы делаем большие Системы, в которых куча всего сложного и интересного. Цепочки согласований, пересекающиеся сущности, задачи и уведомления, логирование событий, ролевые модели, какие-то шины, которые нам будут позволять стучаться в систему из внешних систем, интеграции. А во многих внутренних продуктах даже есть ML элементы. Во всем этом надо разобраться, что нереально прокачивает.
👩❤️👨 3. Пользователи всегда знают, где нас найти. Про это писала в болях, но в этом и много плюсов, это же постоянная прямая линия с нашими конечными потребителями. Сейчас у меня есть чат, в который все пользовали пишут свои баги, вопросы и предложения. А еще есть отдельная страница в Confluence, куда они могут заводить фича реквесты и голосовать за понравившиеся. Нам очень просто найти людей на custdev или UX, достаточно просто кинуть клич в Slack. Нам не нужно через несколько слоев иерархии рваться к пользователям, они уже среди нас. И из-за того, что они так близко и так похожи на нас, мы можем сделать для них еще более крутое решение.
⚙ 4. В процессе мы делаем кучу оптимизаций. Кейс: мы хотим запилить интеграцию системы рекрутера с платформой тестирования для кандидатов. Мы уже задали себе вопросы: а зачем нам вообще тестирования? Может, отказаться от них? Мы начинаем анализировать ситуацию. В нашем случае наличие тестов на позиции массового поиска экономит рекрутеру час времени на общение с одним кандидатом, что при наличии условного потока в 200 кандидатов в месяц высвободит 200 часов. Дальше считаем бизнес кейс интеграции. Сейчас рекрутер тратит 7 минут на то, чтобы завести одного кандидата в тестовую систему, отправить ему нужную методику, проверить, прошел ли кандидат тест, а потом выгрузить результаты и занести в свой трекер. При таком же условном потоке кандидатов это почти три рабочих дня в месяц на оперативку. Интеграция позволит нам отправлять тесты и извлекать результаты мгновенно. Сравниваем стоимость потерянного времени и стоимость интеграции и решаем пилить.
И такие задачи нам нужно решать каждый день.
⚡️ 5. Мы невероятно быстро покачиваем навыки. Одному продакту приходится погружаться во все, даже еще сильнее, чем на внешнем продукте. Мы сразу отвечаем и за стратегию, и за все метрики, и за все требования, и за все исследования, а когда начинаем зарубаться со стейкхолдерами, то с космической скоростью начинают развиваться наши лидерские качества и прочие гибкие навыки.
Бонус: Пользователь точно будет использовать наш продукт😂. Ведь у него просто нет выбора.
Все косячат. Давайте начнём с этого. Но одни ошибки стоят дороже других, особенно если их допускают люди на роли продакта, когда принимают неправильные продуктовые решения, которые влияют на ключевую метрику.
Я вчера была в шаге от совершения такой ошибки. Чтобы вы поняли потенциальный масштаб бедствия, я сейчас занимаюсь разработкой продукта которым пока будут пользоваться 2 раза в год. Поэтому шанса тестировать и постоянно проверять гипотезы на реальных данных у нас нет. У нас есть дата начала процесса, к которой мы должны успеть выкатить релиз, и у нас есть цель, к которой мы хотим прийти.
🥅 Про цель: у нас 2 верхнеуровневые метрики: скорость и качество. И сейчас нам поставили фокус оптимизировать скорость, не уронив при этом качество.
🏟 Какой контекст? Я где-то полтора месяца работала над оптимизацией бизнес-процесса оценки для каждой роли. Выписывала смыслы, крутила разные решения, тестировала прототипы и так далее.
Был текущий процесс, были верхнеуровневые ожидания, которые во многих местах расходились (как всегда HR видит процесс одним образом, топы – другим, простые пользователи – третьим).
И было несколько вариантов решений, каждое из которых принесло бы свой вэлью.
🎢 Где случился косяк? Если вкратце, мы со стейкхолдерами выбрали решение, которое увеличивает качество и при этом увеличивает время процессе. Я загорелась идеей о том, какую крутую ценность мы принесем, решение подкреплялось пользовательскими интервью и историческими данными.
🚦 Что могло меня остановить? На многих демо прототипа я слышала фидбеки о том, что как-то все сложно, а ли точно надо делать именно так. Но было и много позитивных фидбеков. Cразу было понятно, что решение неоднозначное. Я запустила опрос в двумя вариантами решений, с небольшим перевесом победило то, которое эмоционально поддерживала я. Я утвердила решение со стейкхолдерами и отдала требования в дизайн.
💜 Что меня на самом деле остановило? Моя команда. Я принесла требования и первый вариант макетов на PBR (еще расскажу о том, какая это мощная штука), и ребята-разработчики просто ничего не поняли в интерфейсе. Не поняли смысла блоков в форме, порядка заполнения, но основный их комментарий был в том, что мы отклонились от цели, которую поставили им в KPI: не просто разработать форму, а сократить в 2 раза время, которое мы затрачиваем на процесс. С одной стороны, может, проблема в дизайне, неужели можно так сразу отказаться от потенциального увеличения ценности процесса? Наверно, нельзя.
🌋 Что дальше? Так как у нас появился готовый макет, который визуально сильно отличался от прототипа в Экселе, побежали его проверять. И прямо… фэйл. Я себе напоминала главного героя сериала «Кремниевая долина», который во время UX’ов выходил из-за зеркала, чтобы втолковать пользователям ценность своего решения. Но мы же проверяли гипотезу, чтобы ценность была очевидна! А вот что произошло: в процессе участвуют 2 роли, увеличение ценности для двух ролей очень сильно усложняет жизнь третьей. При этом ценность для одной из ролей завязана на итоговом процессе, который вытекает из оценки персонала, который потенциально будет пересматриваться. То есть мы бы удлинили процесс для одной роли, чтобы принести (возможно) краткосрочную ценность для двух других. В целом, решение имеет место быть, если бы наши цели были по-другому сформулированы. Но это не так.
Надо было принять сложное решение, что делать дальше. Я подготовила питч для HR директора, представила новый вариант решения, представила, защитила. Переписала требования и вернула на дизайн.
🌠 Какие выводы?
1. Надо всегда держать в голове основную метрику или цель.
2. Не надо эмоционально привязываться к одному из решений, как бы нам его не продавали.
3. Надо быть открытой командой, которая не боится давать друг другу сложные фидбеки.
Как круто, что у меня такая команда💙
Я вчера была в шаге от совершения такой ошибки. Чтобы вы поняли потенциальный масштаб бедствия, я сейчас занимаюсь разработкой продукта которым пока будут пользоваться 2 раза в год. Поэтому шанса тестировать и постоянно проверять гипотезы на реальных данных у нас нет. У нас есть дата начала процесса, к которой мы должны успеть выкатить релиз, и у нас есть цель, к которой мы хотим прийти.
🥅 Про цель: у нас 2 верхнеуровневые метрики: скорость и качество. И сейчас нам поставили фокус оптимизировать скорость, не уронив при этом качество.
🏟 Какой контекст? Я где-то полтора месяца работала над оптимизацией бизнес-процесса оценки для каждой роли. Выписывала смыслы, крутила разные решения, тестировала прототипы и так далее.
Был текущий процесс, были верхнеуровневые ожидания, которые во многих местах расходились (как всегда HR видит процесс одним образом, топы – другим, простые пользователи – третьим).
И было несколько вариантов решений, каждое из которых принесло бы свой вэлью.
🎢 Где случился косяк? Если вкратце, мы со стейкхолдерами выбрали решение, которое увеличивает качество и при этом увеличивает время процессе. Я загорелась идеей о том, какую крутую ценность мы принесем, решение подкреплялось пользовательскими интервью и историческими данными.
🚦 Что могло меня остановить? На многих демо прототипа я слышала фидбеки о том, что как-то все сложно, а ли точно надо делать именно так. Но было и много позитивных фидбеков. Cразу было понятно, что решение неоднозначное. Я запустила опрос в двумя вариантами решений, с небольшим перевесом победило то, которое эмоционально поддерживала я. Я утвердила решение со стейкхолдерами и отдала требования в дизайн.
💜 Что меня на самом деле остановило? Моя команда. Я принесла требования и первый вариант макетов на PBR (еще расскажу о том, какая это мощная штука), и ребята-разработчики просто ничего не поняли в интерфейсе. Не поняли смысла блоков в форме, порядка заполнения, но основный их комментарий был в том, что мы отклонились от цели, которую поставили им в KPI: не просто разработать форму, а сократить в 2 раза время, которое мы затрачиваем на процесс. С одной стороны, может, проблема в дизайне, неужели можно так сразу отказаться от потенциального увеличения ценности процесса? Наверно, нельзя.
🌋 Что дальше? Так как у нас появился готовый макет, который визуально сильно отличался от прототипа в Экселе, побежали его проверять. И прямо… фэйл. Я себе напоминала главного героя сериала «Кремниевая долина», который во время UX’ов выходил из-за зеркала, чтобы втолковать пользователям ценность своего решения. Но мы же проверяли гипотезу, чтобы ценность была очевидна! А вот что произошло: в процессе участвуют 2 роли, увеличение ценности для двух ролей очень сильно усложняет жизнь третьей. При этом ценность для одной из ролей завязана на итоговом процессе, который вытекает из оценки персонала, который потенциально будет пересматриваться. То есть мы бы удлинили процесс для одной роли, чтобы принести (возможно) краткосрочную ценность для двух других. В целом, решение имеет место быть, если бы наши цели были по-другому сформулированы. Но это не так.
Надо было принять сложное решение, что делать дальше. Я подготовила питч для HR директора, представила новый вариант решения, представила, защитила. Переписала требования и вернула на дизайн.
🌠 Какие выводы?
1. Надо всегда держать в голове основную метрику или цель.
2. Не надо эмоционально привязываться к одному из решений, как бы нам его не продавали.
3. Надо быть открытой командой, которая не боится давать друг другу сложные фидбеки.
Как круто, что у меня такая команда💙
Еще о продуктовых косяках и о стейкхолдер-менеджменте.
Когда я пытаюсь улучшить UX на внутренних продуктах и обсуждаю решения со стейкхолдерами, то почти всегда сталкиваюсь с создателями и держателями бизнес-процессов или методологии, которые уверены в том, что она идеальна.
🙏 Я искренне верю в то, что такие методологи тоже должны работать по продуктовому подходу или давать нам как продуктовым командам им помочь.
🛠 Реальный кейс: разрабатывали модуль системы для постановки годовых целей и их последующей оценки руководителем. Методология, в целом, очень хорошая. Оценить результат по целям, оценить софт-скиллы, после этого вывести рекомендованный итоговый балл.
👹 В чем подвох? Оценка софт-скиллов была неоправданно сложной. Во-первых, сам набор софт-скиллов не обновлялся десять лет и изжил свою актуальность. Во-вторых, он не адаптировался под конкретную роль. В-третьих, надо было оценивать не один скилл, а его индикатор, то есть поставить не 5 оценок, а 30. В итоге после подведения факта по выполнению целей процесс сводился к прокликиванию баллов по тридцати индикаторам, смысла которых сотрудники не понимали. Сделать это должны были и сами сотрудники на себя, и их руководители. И если оценка руководителя потом попадала в формулу для расчета итогового рейтинга, то оценка сотрудника не попадала никуда.
🤳 Что мы выяснили на UX-тестировании?
1. Люди не видят смысла в самооценке и ставят себе 30 одинаковых оценок «нормально» или «выше среднего».
2. Люди не понимают компетенций и тем более их индикаторов – хотят пример того, что значит тот или иной софт-скилл.
3. Руководители больших команд страдают нестерпимо, когда ставят каждому члену команды 30 оценок, поэтому тоже прикликивают 30 одинаковых оценок.
👷 Что предложили Заказчику?
1. Убрать самооценку.
2. Убрать оценку каждого индикатора, оставить только пять софт-скиллов.
3. Следующей итерацией пересмотреть софт-скиллы и адаптировать их под изменившийся бизнес-мир.
💡 Что захотел Заказчик?
1. Согласился убрать оценку каждого индикатора.
2. При этом захотел вытащить к оценке софт-скиллов оценку хард-скиллов, если эти хард-скиллы ведутся.
3. В свободном формате писать сильные стороны и зоны развития (хотя были внедрены Оценка 360 и План развития).
4. Оценивать «плюсики» – своеобразный вклад в развитие HR инициатив: активное участие в различных мероприятиях, менторинг, написание тренингов и так далее.
😿 Почему это было спорно?
1. Принятые решения почти никак не отвечали известным нам болям пользователей и были придуманы держателями методологии.
2. Новые поля решали боль держателей методологии – HRов: увеличить пенетрацию HR-процессов вроде создания тренингов сотрудниками или системы наставничества. При этом они противоречили целям руководителя получать от сотрудника максимальный выхлоп на бизнес-задачах.
3. Они не отвечали никакой задаче с точки зрения процесса и автоматизации: не помогали руководителю поставить итоговую оценку, не помогали составить план развития, не вытекали из опроса обратной связи.
НО
Они были прикольными гипотезами по увеличению ценности процесса.
🧗 Что надо было сделать дальше?
Проверить гипотезы. Поговорить с руководителями, понять, чего им не хватает для выставления оценки, как они относятся к дополнительным HR активностям, видят ли в них ценность. Понять, как руководители и сотрудники работают с обратной связью, в какой момент и как агрегируют ее в план развития. По итогам подтвердить инсайты и решения на количественном опросе (масштабы компании позволяли) и сгенерить решения. Решения переложить на прототипы и проверить с пользователями.
🙈 Что попросил сделать Заказчик?
Нарисовать макеты и показать топ-менеджеру Заказчика. Если макеты утвердят, то разработать функционал.
(минутка продуктового крика боли)
❓ Как с таким работать?
Выхода два: смириться или бороться.
Я не из тех, кто готов смириться, поэтому в последний год активно ботала работу со стейкхолдерами. Некоторыми инсайтами поделюсь в следующий раз.
Когда я пытаюсь улучшить UX на внутренних продуктах и обсуждаю решения со стейкхолдерами, то почти всегда сталкиваюсь с создателями и держателями бизнес-процессов или методологии, которые уверены в том, что она идеальна.
🙏 Я искренне верю в то, что такие методологи тоже должны работать по продуктовому подходу или давать нам как продуктовым командам им помочь.
🛠 Реальный кейс: разрабатывали модуль системы для постановки годовых целей и их последующей оценки руководителем. Методология, в целом, очень хорошая. Оценить результат по целям, оценить софт-скиллы, после этого вывести рекомендованный итоговый балл.
👹 В чем подвох? Оценка софт-скиллов была неоправданно сложной. Во-первых, сам набор софт-скиллов не обновлялся десять лет и изжил свою актуальность. Во-вторых, он не адаптировался под конкретную роль. В-третьих, надо было оценивать не один скилл, а его индикатор, то есть поставить не 5 оценок, а 30. В итоге после подведения факта по выполнению целей процесс сводился к прокликиванию баллов по тридцати индикаторам, смысла которых сотрудники не понимали. Сделать это должны были и сами сотрудники на себя, и их руководители. И если оценка руководителя потом попадала в формулу для расчета итогового рейтинга, то оценка сотрудника не попадала никуда.
🤳 Что мы выяснили на UX-тестировании?
1. Люди не видят смысла в самооценке и ставят себе 30 одинаковых оценок «нормально» или «выше среднего».
2. Люди не понимают компетенций и тем более их индикаторов – хотят пример того, что значит тот или иной софт-скилл.
3. Руководители больших команд страдают нестерпимо, когда ставят каждому члену команды 30 оценок, поэтому тоже прикликивают 30 одинаковых оценок.
👷 Что предложили Заказчику?
1. Убрать самооценку.
2. Убрать оценку каждого индикатора, оставить только пять софт-скиллов.
3. Следующей итерацией пересмотреть софт-скиллы и адаптировать их под изменившийся бизнес-мир.
💡 Что захотел Заказчик?
1. Согласился убрать оценку каждого индикатора.
2. При этом захотел вытащить к оценке софт-скиллов оценку хард-скиллов, если эти хард-скиллы ведутся.
3. В свободном формате писать сильные стороны и зоны развития (хотя были внедрены Оценка 360 и План развития).
4. Оценивать «плюсики» – своеобразный вклад в развитие HR инициатив: активное участие в различных мероприятиях, менторинг, написание тренингов и так далее.
😿 Почему это было спорно?
1. Принятые решения почти никак не отвечали известным нам болям пользователей и были придуманы держателями методологии.
2. Новые поля решали боль держателей методологии – HRов: увеличить пенетрацию HR-процессов вроде создания тренингов сотрудниками или системы наставничества. При этом они противоречили целям руководителя получать от сотрудника максимальный выхлоп на бизнес-задачах.
3. Они не отвечали никакой задаче с точки зрения процесса и автоматизации: не помогали руководителю поставить итоговую оценку, не помогали составить план развития, не вытекали из опроса обратной связи.
НО
Они были прикольными гипотезами по увеличению ценности процесса.
🧗 Что надо было сделать дальше?
Проверить гипотезы. Поговорить с руководителями, понять, чего им не хватает для выставления оценки, как они относятся к дополнительным HR активностям, видят ли в них ценность. Понять, как руководители и сотрудники работают с обратной связью, в какой момент и как агрегируют ее в план развития. По итогам подтвердить инсайты и решения на количественном опросе (масштабы компании позволяли) и сгенерить решения. Решения переложить на прототипы и проверить с пользователями.
🙈 Что попросил сделать Заказчик?
Нарисовать макеты и показать топ-менеджеру Заказчика. Если макеты утвердят, то разработать функционал.
(минутка продуктового крика боли)
❓ Как с таким работать?
Выхода два: смириться или бороться.
Я не из тех, кто готов смириться, поэтому в последний год активно ботала работу со стейкхолдерами. Некоторыми инсайтами поделюсь в следующий раз.
Кросс-функциональная команда - это миф.
Нытье про скрам, часть 1 из миллиона.
На прошлом месте работы у меня было шесть скрам команд, сейчас, слава богу, всего одна. Я никогда серьёзно не думала уходить от скрама, но это мне не мешает его не любить и видеть в нем кучу недостатков.
Первый поинт:
❌ Кросс-функциональность не работает. Или работает ну очень плохо и очень редко. И по большей части зависит от желания конкретных исполнителей.
Вот в чем проблема. Нельзя просто так взять и закинуть группе исполнителей цель спринта на 2 недели. Вспомню реальный случай: я как продакт отдаю команде задачу сделать функционал генерации отчётов всех данных из системы. Команда из двух бэков и двух фронтов говорит: 8 спринтов. Я говорю, ок. Тем временем прошла первая неделя спринта. Приходят на дэйли фронты и говорят: а мы все сверстали. Слышь, Насть, задач нет. Бэки говорят: а мы опаздываем, нам ещё 8 спринтов.
И в этот момент, в идеальном мире скрам мастеров фронты должны были сказать: мы поможем вам, мы станем фуллстеками и будем писать бэк.
😂 Ах, если бы так всегда работало.
Нет, иногда работает. Иногда я работала с фронтами, которые были готовы переучиться в бэков (просить бэков стать фронтами повода не было, HR системы всегда простые интерфейсно, но со сложной логикой).
Но чаще всего фронты говорили "мы не хотим". Или иногда соглашались, а потом на ретро писали карточку "не заставляйте нас". И это нормально, почему они должны переучиваться?
Более того. Даже если человек соглашается, мы получаем бэка-стажера, который взял в работу маленький метод или простенький баг, но закрыть задачу может только если отвлечет синиор или миддл бэка из команды. Конечно, так люди и учатся и спустя несколько спринтов он перестанет отвлекать коллег, но нам надо принять, что сроки разработки эпика вырастут на 30%.
😫 И решить эту проблему очень сложно. Частично помогают PBRы, но все равно нужно каждый спринт доставать из шляпы несуществующие новые задачи на фронт. Это стресс, потому что часто их просто нет.
Ротировать постоянно исполнителей под каждый эпик тоже не хочется: мы же хотим работать одной командой, а не гореть в условиях неопределённости.
Какого-то одного решения тут нет. Оно зависит от продукта, от задач, от компании. Но говорить, что скрам команда (в которой ещё, например, тестировщики работают так-то) кросс-функциональная и каждый из членов команды может покрыть 2 стрима - значит врать самим себе.
Нытье про скрам, часть 1 из миллиона.
На прошлом месте работы у меня было шесть скрам команд, сейчас, слава богу, всего одна. Я никогда серьёзно не думала уходить от скрама, но это мне не мешает его не любить и видеть в нем кучу недостатков.
Первый поинт:
❌ Кросс-функциональность не работает. Или работает ну очень плохо и очень редко. И по большей части зависит от желания конкретных исполнителей.
Вот в чем проблема. Нельзя просто так взять и закинуть группе исполнителей цель спринта на 2 недели. Вспомню реальный случай: я как продакт отдаю команде задачу сделать функционал генерации отчётов всех данных из системы. Команда из двух бэков и двух фронтов говорит: 8 спринтов. Я говорю, ок. Тем временем прошла первая неделя спринта. Приходят на дэйли фронты и говорят: а мы все сверстали. Слышь, Насть, задач нет. Бэки говорят: а мы опаздываем, нам ещё 8 спринтов.
И в этот момент, в идеальном мире скрам мастеров фронты должны были сказать: мы поможем вам, мы станем фуллстеками и будем писать бэк.
😂 Ах, если бы так всегда работало.
Нет, иногда работает. Иногда я работала с фронтами, которые были готовы переучиться в бэков (просить бэков стать фронтами повода не было, HR системы всегда простые интерфейсно, но со сложной логикой).
Но чаще всего фронты говорили "мы не хотим". Или иногда соглашались, а потом на ретро писали карточку "не заставляйте нас". И это нормально, почему они должны переучиваться?
Более того. Даже если человек соглашается, мы получаем бэка-стажера, который взял в работу маленький метод или простенький баг, но закрыть задачу может только если отвлечет синиор или миддл бэка из команды. Конечно, так люди и учатся и спустя несколько спринтов он перестанет отвлекать коллег, но нам надо принять, что сроки разработки эпика вырастут на 30%.
😫 И решить эту проблему очень сложно. Частично помогают PBRы, но все равно нужно каждый спринт доставать из шляпы несуществующие новые задачи на фронт. Это стресс, потому что часто их просто нет.
Ротировать постоянно исполнителей под каждый эпик тоже не хочется: мы же хотим работать одной командой, а не гореть в условиях неопределённости.
Какого-то одного решения тут нет. Оно зависит от продукта, от задач, от компании. Но говорить, что скрам команда (в которой ещё, например, тестировщики работают так-то) кросс-функциональная и каждый из членов команды может покрыть 2 стрима - значит врать самим себе.
В первый четверг сентября рассказываю про продуктовый подход к проектированию и оптимизации процессов с фэйспалмными примерами из практики.
Приходите!😉
Приходите!😉
Forwarded from Changellenge Alumni Channel
#MasterClass
✌️Alumni, привет!
Ну что, вы готовы к следующему Мастер-классу?
Мы с вами выбрали тему🔥
Мы видим высокий интерес и к другим, обещаем, обязательно к ним вернемся.
А теперь немного информации, что будет нас ждать 2 сентября (чт) в 20:00 по Мск, а главное, с кем?
Мы встретимся с Настей Кондрашовой - Senior Product Manager Авито, Руководителем HR автоматизации и выпускником Школы Changellenge >>.
На мастер-классе мы обсудим на конкретных примерах из практики:
- Что такое неэффективный бизнес-процесс;
- Инструменты оптимизации бизнес-процессов;
- Продуктовый подход к автоматизации процессов: как сделать процесс для людей;
- Как на оптимизации и автоматизации сэкономить средства компании.
🖇Регистрация: https://changellenge.typeform.com/to/vlfQMuLJ
🗓Добавить в календарь
✌️Alumni, привет!
Ну что, вы готовы к следующему Мастер-классу?
Мы с вами выбрали тему🔥
Мы видим высокий интерес и к другим, обещаем, обязательно к ним вернемся.
А теперь немного информации, что будет нас ждать 2 сентября (чт) в 20:00 по Мск, а главное, с кем?
Мы встретимся с Настей Кондрашовой - Senior Product Manager Авито, Руководителем HR автоматизации и выпускником Школы Changellenge >>.
На мастер-классе мы обсудим на конкретных примерах из практики:
- Что такое неэффективный бизнес-процесс;
- Инструменты оптимизации бизнес-процессов;
- Продуктовый подход к автоматизации процессов: как сделать процесс для людей;
- Как на оптимизации и автоматизации сэкономить средства компании.
🖇Регистрация: https://changellenge.typeform.com/to/vlfQMuLJ
🗓Добавить в календарь
Public speaking: преодолеваем страх.
Больше десяти лет я безумно боялась выступать на публике. Очень этого хотела, но просто не могла физически.
С подросткового возраста у меня были страхи, связанные с моей речью: я довольно быстро говорила, часто съедала окончания. Людям приходилось переспрашивать, они не понимали, что я сказала. Это вызывало во мне невероятный стресс, потому что разрывало мое преставление о себе и давило на моего внутреннего перфекциониста. Я даже ходила с этим запросом на терапию, правда, без особого успеха: быстрая речь у меня возникала в ситуации стресса, а в кресле у психолога я этот стресс не чувствовала.
На третьем курсе университета мне наскучило учиться по специальности, и я пошла на годовую переподготовку на спортивного тележурналиста (ага, и такое было). Там приходилось много говорить на камеру, записывать озвучки, читать скороговорки на технике речи. Я до сих пор помню, как плакала на некоторых парах, потому что не получалось практически ничего. Преподаватели там были разные: один очень жестко проходился по моей речи, второй говорил, что ничего в ней такого нет, гораздо важнее, что я рассказываю интересный контент.
Я не стала искать работу журналистом, хотя школа предлагала крутую стажировку на федеральном канале, и вернулась к своему образованию, закончила бакалавриат и (зачем-то) магистратуру. Начала работать, и хоть моя работа была связана с общением с людьми, публичных выступлений у меня не было, что не могло меня не радовать.
Все изменилось 5 лет назад, когда я доросла до менеджерской позиции. Внезапно я должна была выходить к толпе студентов и рассказывать им, как начинать у нас карьеру, проводить тренинги для слабослышащих ребят о том, как составить резюме и пройти интервью, вести дневное обучение для нанимающих менеджеров.
И я бы провалилась, если бы не мой прекрасный менеджер (спасибо, Катя!). Она просто выталкивала меня из зоны комфорта и постоянно отправляла на публику. Ей было все равно, что я стрессую, что быстро говорю, что не умею этого делать, она пинала меня и говорила «иди и учись». И все время записывала меня спикером на все публичные ивенты, на которые было только можно.
Что помогло справиться со страхом?
1. Проработка проблемы и принятие, что не каждая деталь должна быть идеальной.
2. Понимание, что качественная подготовка снижает уровень стресса => меньше стресса – ниже скорость.
3. Отсутствие выбора и наличие постоянной практики.
4. Осознание, что мой контент несет ценность аудитории.
5. Отношение к выступлению не как к лекции, а как к разговору с людьми (крутая штука с тренинга, расскажу про нее завтра).
Больше десяти лет я безумно боялась выступать на публике. Очень этого хотела, но просто не могла физически.
С подросткового возраста у меня были страхи, связанные с моей речью: я довольно быстро говорила, часто съедала окончания. Людям приходилось переспрашивать, они не понимали, что я сказала. Это вызывало во мне невероятный стресс, потому что разрывало мое преставление о себе и давило на моего внутреннего перфекциониста. Я даже ходила с этим запросом на терапию, правда, без особого успеха: быстрая речь у меня возникала в ситуации стресса, а в кресле у психолога я этот стресс не чувствовала.
На третьем курсе университета мне наскучило учиться по специальности, и я пошла на годовую переподготовку на спортивного тележурналиста (ага, и такое было). Там приходилось много говорить на камеру, записывать озвучки, читать скороговорки на технике речи. Я до сих пор помню, как плакала на некоторых парах, потому что не получалось практически ничего. Преподаватели там были разные: один очень жестко проходился по моей речи, второй говорил, что ничего в ней такого нет, гораздо важнее, что я рассказываю интересный контент.
Я не стала искать работу журналистом, хотя школа предлагала крутую стажировку на федеральном канале, и вернулась к своему образованию, закончила бакалавриат и (зачем-то) магистратуру. Начала работать, и хоть моя работа была связана с общением с людьми, публичных выступлений у меня не было, что не могло меня не радовать.
Все изменилось 5 лет назад, когда я доросла до менеджерской позиции. Внезапно я должна была выходить к толпе студентов и рассказывать им, как начинать у нас карьеру, проводить тренинги для слабослышащих ребят о том, как составить резюме и пройти интервью, вести дневное обучение для нанимающих менеджеров.
И я бы провалилась, если бы не мой прекрасный менеджер (спасибо, Катя!). Она просто выталкивала меня из зоны комфорта и постоянно отправляла на публику. Ей было все равно, что я стрессую, что быстро говорю, что не умею этого делать, она пинала меня и говорила «иди и учись». И все время записывала меня спикером на все публичные ивенты, на которые было только можно.
Что помогло справиться со страхом?
1. Проработка проблемы и принятие, что не каждая деталь должна быть идеальной.
2. Понимание, что качественная подготовка снижает уровень стресса => меньше стресса – ниже скорость.
3. Отсутствие выбора и наличие постоянной практики.
4. Осознание, что мой контент несет ценность аудитории.
5. Отношение к выступлению не как к лекции, а как к разговору с людьми (крутая штука с тренинга, расскажу про нее завтра).
Public speaking: выступление как разговор, а не как лекция. Метод хуков.
Я стрессую выступать с трибуны или читать доклад. И я знаю, что у многих есть такая же проблема. Чтобы меньше стрессовать, надо понять причины страха.
😰 Вот мои:
1. Никто меня не поймет (быстрая речь, сложные слова).
2. Никто не будет меня слушать (а мы сами внимательно слушаем лекторов, даже если они несут офигенный контент?).
С первой причиной бороться просто: рассказываем так, чтобы понял и ребенок. Если называем термин, который будем часто использовать, то разжевываем его. Решить вторую мне помог шикарный тренинг Presentation Skills. Там я узнала про метод хуков.
🪝 Hook – крючок. Так называется прием, с помощью которого можно мгновенно вернуть внимание аудитории на себя.
Тренер из консалтинга привел такой пример: конференция, люди вернулись с обеда, все сидят болтают, а ему выступать. Он говорит: «Проект Пума». Ноль внимания. Он включает колонки и по всему залу разносится на полной громкости львиный рык, после чего он говорит: «Внимание. Проект Пума». Зал обалдел и готов ему внимать.
Это, конечно, экстремальный способ использовать хук, но очень показательный.
С уходом на удаленку и переносом тренингов в зум использование хуков стало просто жизненной необходимостью, потому что мы не видим, что люди делают по ту часть экрана, а они могут кодить, сидеть в телефоне, играть. Конечно, они не будут нас слушать, контекст вокруг создает им массу отвлечений.
Хук работает на переключении внимания с одного источника на другой. Хуком может быть любой интерактив, который мы используем в презентации.
🔱 Например:
1. Видео, музыкальный отрывок.
2. Картинки, фотографии.
3. Голосовалка или квиз.
4. Вопрос в зал, на который мы ждем ответа.
5. Любая быстрая игра.
6. Если два спикера, передача слова другому.
7. Рассказ про пример из практики.
8. Практическое упражнение.
И так до бесконечности. Причем нет запрета использовать слишком много хуков в одной презентации, наоборот: их нужно использовать сразу как мы чувствуем, что внимание аудитории рассеивается (чаще всего это происходит каждые 5 минут).
Я сама чаще всего разбавляю свои выступления вопросами в зал, диалогами и упражнениями, результаты которых потом можно обсудить. Так я превращаю лекцию в разговор с залом, то есть в то, что мне удается делать хорошо.
Я стрессую выступать с трибуны или читать доклад. И я знаю, что у многих есть такая же проблема. Чтобы меньше стрессовать, надо понять причины страха.
😰 Вот мои:
1. Никто меня не поймет (быстрая речь, сложные слова).
2. Никто не будет меня слушать (а мы сами внимательно слушаем лекторов, даже если они несут офигенный контент?).
С первой причиной бороться просто: рассказываем так, чтобы понял и ребенок. Если называем термин, который будем часто использовать, то разжевываем его. Решить вторую мне помог шикарный тренинг Presentation Skills. Там я узнала про метод хуков.
🪝 Hook – крючок. Так называется прием, с помощью которого можно мгновенно вернуть внимание аудитории на себя.
Тренер из консалтинга привел такой пример: конференция, люди вернулись с обеда, все сидят болтают, а ему выступать. Он говорит: «Проект Пума». Ноль внимания. Он включает колонки и по всему залу разносится на полной громкости львиный рык, после чего он говорит: «Внимание. Проект Пума». Зал обалдел и готов ему внимать.
Это, конечно, экстремальный способ использовать хук, но очень показательный.
С уходом на удаленку и переносом тренингов в зум использование хуков стало просто жизненной необходимостью, потому что мы не видим, что люди делают по ту часть экрана, а они могут кодить, сидеть в телефоне, играть. Конечно, они не будут нас слушать, контекст вокруг создает им массу отвлечений.
Хук работает на переключении внимания с одного источника на другой. Хуком может быть любой интерактив, который мы используем в презентации.
🔱 Например:
1. Видео, музыкальный отрывок.
2. Картинки, фотографии.
3. Голосовалка или квиз.
4. Вопрос в зал, на который мы ждем ответа.
5. Любая быстрая игра.
6. Если два спикера, передача слова другому.
7. Рассказ про пример из практики.
8. Практическое упражнение.
И так до бесконечности. Причем нет запрета использовать слишком много хуков в одной презентации, наоборот: их нужно использовать сразу как мы чувствуем, что внимание аудитории рассеивается (чаще всего это происходит каждые 5 минут).
Я сама чаще всего разбавляю свои выступления вопросами в зал, диалогами и упражнениями, результаты которых потом можно обсудить. Так я превращаю лекцию в разговор с залом, то есть в то, что мне удается делать хорошо.
Перерождение в большого босса или «отвали от людей».
У меня год назад случился интересный транзишн: я из простого руководителя команды (которая еще и брала год отдыха от управления людьми, потому что выгорела и больше не могла) стала менеджером менеджеров. И я прямо почувствовала, как изменилось все. И как меняются правила игры, по которым я играла, когда была просто тимлидом.
Но одно правило для менеджера менеджеров стоит для меня особняком. Я его формулирую как НЕ ЛЕЗЬ!
Отстань от людей, если они не твои директ репорты. Не трогай процессы нижнего уровня, если только ты не понимаешь, что тимлид в твоей команде не справляется совсем.
Мой священный свод правил НЕ ЛЕЗЬ:
⛵️ 1. У тебя команда руководителей. Это больше не стажеры/джуны, за которыми надо перепроверять. Надели их полномочиями и отпусти в свободное плавание.
🎓 2. Есть большая вероятность, что тимлиды из твоей команды сильно функционально экспертнее, чем ты. Это прекрасно, не нужно этого бояться и страдать синдромом самозванца.
🏯 3. Делегируй своим менеджерам большой кусок полномочий: не только людей, но задачи и процессы.
👵🏼 4. Да, ты точно лучше некоторых из них знаешь, как оптимизировать те или иные процессы, но дай им самим попробовать. Коучи, если надо, но не ментори. Поверь, у многих из них оптимизация получится еще лучше, чем у тебя.
🛂 5. Регулярно отслеживай результаты работы. Если тимлид не справялется и начинает факапить, это надо узнавать немедленно.
Я один раз не отследила вовремя и получила заваленный проект, необученных стажеров и выгоревшего крутого миддла, которая ушла из компании.
🙅🏽♂ 6. Не лезь к подчиненным своих менеджеров. Не давай им негативный фидбек, не сообщай им новости о повышении грейда или зарплаты, НИ В КОЕМ СЛУЧАЕ не проводи с ними регулярные 121ы. Ты просто всем этим дискредитируешь их непосредственного менеджера.
У меня один раз была менеджер, которая сама звонила моим директ репортам и их репортам, чтобы и обсудить проблемные кейсы, и сообщить хорошие новости. Ну и это просто ужасно, это демотивирует абсолютно всех, кто в это вовлечен. Люди не понимают, кто их руководитель, какая иерархия, не понимают, кому доверять. Это просто собственноручный расстрел своей команды. При этом мы как руководители людей не развиваемся, а управлять процессами мы могли и без команд в подчинении. Не доверяешь людям – ходи с ними на эти встречи, слушай и давай фидбек по итогам.
👄 7. Если тебе важно донести обратную связь подчиненному подчиненного лично от себя, сделай это на общей встрече с его менеджером.
🤙🏻 8. Регулярные 121 запрещены, но вот ежемесячные или ежедвухмесячные полезны – иначе как ты узнаешь, что твой директ репорт начал косячить как менеджер.
😉 9. Позитивную обратную связь на -2 уровня давать можно, но хвалить надо не кого-то одного, а всю команду, которая участвовала в достижении результата. Есть шанс, что ты не видел реального положения дел и очень сильно обидишь какого-нибудь пахаря.
👨👧👧 10. Ну и одного своего тимлида тоже не хвали, он не один результата достигал, а с помощью команды.
У меня год назад случился интересный транзишн: я из простого руководителя команды (которая еще и брала год отдыха от управления людьми, потому что выгорела и больше не могла) стала менеджером менеджеров. И я прямо почувствовала, как изменилось все. И как меняются правила игры, по которым я играла, когда была просто тимлидом.
Но одно правило для менеджера менеджеров стоит для меня особняком. Я его формулирую как НЕ ЛЕЗЬ!
Отстань от людей, если они не твои директ репорты. Не трогай процессы нижнего уровня, если только ты не понимаешь, что тимлид в твоей команде не справляется совсем.
Мой священный свод правил НЕ ЛЕЗЬ:
⛵️ 1. У тебя команда руководителей. Это больше не стажеры/джуны, за которыми надо перепроверять. Надели их полномочиями и отпусти в свободное плавание.
🎓 2. Есть большая вероятность, что тимлиды из твоей команды сильно функционально экспертнее, чем ты. Это прекрасно, не нужно этого бояться и страдать синдромом самозванца.
🏯 3. Делегируй своим менеджерам большой кусок полномочий: не только людей, но задачи и процессы.
👵🏼 4. Да, ты точно лучше некоторых из них знаешь, как оптимизировать те или иные процессы, но дай им самим попробовать. Коучи, если надо, но не ментори. Поверь, у многих из них оптимизация получится еще лучше, чем у тебя.
🛂 5. Регулярно отслеживай результаты работы. Если тимлид не справялется и начинает факапить, это надо узнавать немедленно.
Я один раз не отследила вовремя и получила заваленный проект, необученных стажеров и выгоревшего крутого миддла, которая ушла из компании.
🙅🏽♂ 6. Не лезь к подчиненным своих менеджеров. Не давай им негативный фидбек, не сообщай им новости о повышении грейда или зарплаты, НИ В КОЕМ СЛУЧАЕ не проводи с ними регулярные 121ы. Ты просто всем этим дискредитируешь их непосредственного менеджера.
У меня один раз была менеджер, которая сама звонила моим директ репортам и их репортам, чтобы и обсудить проблемные кейсы, и сообщить хорошие новости. Ну и это просто ужасно, это демотивирует абсолютно всех, кто в это вовлечен. Люди не понимают, кто их руководитель, какая иерархия, не понимают, кому доверять. Это просто собственноручный расстрел своей команды. При этом мы как руководители людей не развиваемся, а управлять процессами мы могли и без команд в подчинении. Не доверяешь людям – ходи с ними на эти встречи, слушай и давай фидбек по итогам.
👄 7. Если тебе важно донести обратную связь подчиненному подчиненного лично от себя, сделай это на общей встрече с его менеджером.
🤙🏻 8. Регулярные 121 запрещены, но вот ежемесячные или ежедвухмесячные полезны – иначе как ты узнаешь, что твой директ репорт начал косячить как менеджер.
😉 9. Позитивную обратную связь на -2 уровня давать можно, но хвалить надо не кого-то одного, а всю команду, которая участвовала в достижении результата. Есть шанс, что ты не видел реального положения дел и очень сильно обидишь какого-нибудь пахаря.
👨👧👧 10. Ну и одного своего тимлида тоже не хвали, он не один результата достигал, а с помощью команды.
С автоматизацией бизнес-процессов всегда непросто. Сколько бы я с ними не работала, всегда возникают какие-то вопросы, на которые сложно дать ответ.
❓ 1. Как быть с кастомизацией? Правила автоматизации говорят нам, что нужно переносить в систему типовой процесс, иначе мы задолбаемся его поддерживать. При этом какой-то представитель заказчика мог потратить годы на то, чтобы привести процессы к идеалу именно в своей функции. Нужно нам ломать процесс и делать так, чтобы, например, айтишники жили по тем же правилам, что и сейлзы?
❓ 2. Нужно ли в какой-то момент сказать "нет" автоматизации? Все мы знаем, что не каждый бизнес-кейс сойдётся, сегодня мне вот саркастично сказали, что вообще "не надо HR автоматизировать, не верю, что это выгодно" (не в моей компании, разумеется). Но и правда, какая-то автоматизация будет окупать себя десятки лет. Нужно ли отказаться от такой автоматизации, даже если она сэкономит часы работы узкой целевой аудитории (например, админам поддержки или специалистам по кадрам)?
❓ 3. Как быть с политикой во время автоматизации? Как управлять ожиданиями заказчика, доносить до него, что не 100% будет готово к сроку, и что вообще-то пользователи не очень согласны с тем процессом, который видит он? А может, пользователи просто не готовы к Форду и ссылаются только на свою медленную лошадь? А топ-менеджер прав, и надо делать, как он говорит?
К чему это я. Приходите завтра на мой вебинар по неэффективным бизнес-процессам, который я провожу вместе с Changellenge>>. Контента у меня на двое суток, но у нас будет полтора часа. Посмотрим на те 39 слайдов, которые я сделала, подробно разберём 4 процессные схемы в Miro и Visio и разгромим 2 ужасных бизнес-процесса, по которым я когда-то работала.
🕸 Регистрация по ссылке, и всех жду: https://changellenge.typeform.com/to/vlfQMuLJ
❓ 1. Как быть с кастомизацией? Правила автоматизации говорят нам, что нужно переносить в систему типовой процесс, иначе мы задолбаемся его поддерживать. При этом какой-то представитель заказчика мог потратить годы на то, чтобы привести процессы к идеалу именно в своей функции. Нужно нам ломать процесс и делать так, чтобы, например, айтишники жили по тем же правилам, что и сейлзы?
❓ 2. Нужно ли в какой-то момент сказать "нет" автоматизации? Все мы знаем, что не каждый бизнес-кейс сойдётся, сегодня мне вот саркастично сказали, что вообще "не надо HR автоматизировать, не верю, что это выгодно" (не в моей компании, разумеется). Но и правда, какая-то автоматизация будет окупать себя десятки лет. Нужно ли отказаться от такой автоматизации, даже если она сэкономит часы работы узкой целевой аудитории (например, админам поддержки или специалистам по кадрам)?
❓ 3. Как быть с политикой во время автоматизации? Как управлять ожиданиями заказчика, доносить до него, что не 100% будет готово к сроку, и что вообще-то пользователи не очень согласны с тем процессом, который видит он? А может, пользователи просто не готовы к Форду и ссылаются только на свою медленную лошадь? А топ-менеджер прав, и надо делать, как он говорит?
К чему это я. Приходите завтра на мой вебинар по неэффективным бизнес-процессам, который я провожу вместе с Changellenge>>. Контента у меня на двое суток, но у нас будет полтора часа. Посмотрим на те 39 слайдов, которые я сделала, подробно разберём 4 процессные схемы в Miro и Visio и разгромим 2 ужасных бизнес-процесса, по которым я когда-то работала.
🕸 Регистрация по ссылке, и всех жду: https://changellenge.typeform.com/to/vlfQMuLJ
Typeform
Мастер-класс 02.09.21
Turn data collection into an experience with Typeform. Create beautiful online forms, surveys, quizzes, and so much more. Try it for FREE.