Архив недели
Понедельник
План на неделю:
ПН Про себя, HR автоматизацию и внутренние продукты
ВТ Что делает продакт на внутренних продуктах
СР Сбор бэклога с нуля
ЧТ О плюсах и минусах скрама в разных командах
ПТ Сбор идеальной команды
СБ Делаем план развития
ВС О выгорании на жизненном опыте и балансе
В каждой крупной компании HR процессы как-то автоматизированы. Есть системы для ведения КДП (SAP, 1C, Босс-кадровик), есть системы для прочих процессов (SAP SF, TalentTech, ETWeb...). Сейчас вот волна тренда на собственные разработки для прочих процессов, и я ее ловлю🌊
Замесин (t.me/zamesin_pro_pr…) сегодня написал, что все делают свою LMS. Я думаю, тренд шире: все автоматизируют те части EJM, под которые не нашли подходящие для себя решения на рынке.
Но да, это правда. Я делала LMS для Росатома, я буду делать систему обучения сейчас😊
При этом LMS - вымирающий мамонт, у которого очень печальные перспективы в ближайшие несколько лет. Пилить такую систему лет 5, поддерживать и администрировать - ад, а тут еще и тренды меняются. На смену LMS придет LXP. vc.ru/education/1855…
Чем плоха LMS? У неё маленькая целевая аудитория. Основной пользователь LMS - администратор, который хочет собрать сотрудников в группы и назначить им обучение. Для этого ему надо руками создать курс, занятия к нему, собрать список учащихся, листы ожидания, все согласовать...
А основной пользователь процесса обучения - сотрудник, а не HR администратор. Избалованный сотрудник, которого мир приучил к Нетфликсу, умным лентам и прочим прелестям персонализации. Он не хочет массово назначенное обучение, он хочет зайти в каталог и видеть личные рекомендации.
В системе обучения сотрудник хочет видеть не просто рекомендации, а релевантные для него тренинги, видео и конференции в данный момент времени. О, а еще проекты и менторов.
Все это будет завязано на важные для его развития скиллы, предпочитаемый тип контента, день недели и время.
Как к этому прийти? Планомерно автоматизировать все части EJM, на основе которых будем учить MLку формировать рекомендации. Поэтому я делаю продукты из процессов постановки целей, ежегодной оценки карьерного планирования, матриц компетенций и т.д.
Тренды меняют обучение😎
Серьёзно, у Coursera даже модель компетенций/скиллов MLка собирает!😱
Тред #1
Отложим ненамного разговоры про автоматизацию, поговорим о личном
Как я переключаюсь, чтобы не сойти с ума?
🏋️♀️ Тренировки в зале 3 раза в неделю
🎨 Учусь рисовать акварелью
✒ Веду телеграм канал, т.к у меня слишком много контента, чтобы держать в себе😁 t.me/productbombing
Вторник
Всем доброе утро с нашей веранды😊
Я из тех странных людей, кто любит приходить на работу к 8.30, чтобы выпить кофе (на кухне столько сиропов!) поделать оперативку до встреч, разобрать почту и бэклог.
В офис ходить у нас не обязательно, но мне нравится. Хотя я тут почти одна).
Начинаем день про оптимизацию бизнес-процессов и продуктовый подход к ним.
Для начала короткий опрос.
Сталкивались на работе с неэффективными бизнес-процессами?
🤔
86.3% Да🤔
1.5% Нет🤔
12.2% Что значит неэффективный?Когда я 5 лет назад была тимлидом команды рекрутмента, к нам в Deloitte пришел SAP внедрять свой Successfactors для автоматизации всего HR. И сказал: Настя, дай нам типовой процесс подбора, чтобы мы его зашили в систему.
На что я им сказала: ребята, у меня 72 разных процесса.
Я сейчас не шучу, у меня правда была своя воронка подбора для каждой бизнес функции, с которой работала моя команда. Каждый стрим делал свои тестирования, проводил сколько хотел этапов собеседований, устраивал ассессмент центры и финальные интервью с партнером.
Персонализация🤦🏼♀️
SAP – коробочное решение, которое такую персонализацию не поддерживает. И не зря.
Если попытаться автоматизировать хаос, то получится автоматизированный хаос. Который будет немыслимо дорогой в поддержке: передача знаний о каждой воронке, внесение изменения в них отдельно руками.
✂️ Как оптимизировать бизнес-процесс перед автоматизацией?
Сократить этапы.
Сократить роли.
Изменить роли.
Уменьшить длительность каждого этапа.
Унифицировать похожие процессы.
Отказаться от процесса (да, иногда это тоже решение).
Шаг 1. Рисуем процесс "как есть".
Для того, чтобы оптимизировать, надо понять, что именно. Для этого нужно выписать в столбик все роли, которые участвуют в процессе, и нарисовать, как происходит движение.
Подойдёт любая нотация, я использую BPMN, но адаптирую её под себя.
Шаг 2. На основе схемы процесса готовим скрипт интервью и идём кастдевить участников. На каждую роль нужно 5-8 респондентов, а еще нужно обязательно поговорить со стейкхолдерами процесса, чтобы понять верхнеуровневый вижн. На основании результатов интервью выделяем боли и цели.
Шаг 3. Выделяем гипотезы оптимизации:
А. Креативим решения тех болей, которые услышали.
B. Лечим области неэффективности процессов.
C. Строим RACI матрицу: убираем из процесса всех, кто ни за что не отвечает.
D. Выделяем метрики процесса и учимся их тречить.
Что характерищует неэффективный процесс?
- дублирование операций;
- множество итераций;
- излишнее количество согласующих;
- размытость ответственности за этап;
- нерегулярный характер процесса;
- недостаточный уровень автоматизации =)
А про RACI-матрицу хорошая статья есть на Хабре: habr.com/ru/company/inf…
Как она может помочь? Часто в процессе есть куча людей "в копии" или 100500 согласующих, потому что ну надо же. Этих людей надо из процесса убирать. Они сначала пострессуют, но потом скажут спасибо.
Шаг 4. Генерим решения, создаём прототип и тестируем.
Прототип в Фигме нам не подойдёт: нам не прокликать процесс надо, а заполнить форму.
Я делаю прототипы в Excel. Вставляю пару картинок, чтобы было похоже на интерфейс, делаю кнопки, выпадающие списки и прочие зависимости.
Тред #2
Как раз моя первая задача в Авито - сократить время, затрачиваемое на Performance Review, в 2 раза.
И тут продуктово нужно подходить не только к системе, но и к процессам.
На этой неделе активно тестирую прототип на сотрудниках. И они все такие клевые и позитивные💜
И последнее: во имя всех святых, обвязывайте сразу процесс метриками. Наши метрики есть двух типов:
- процессные;
- продуктовые.
Часто в карьере я слышала запросы "оптимизируйте то, не знаю что".
Самое больное, это когда система уже год как запущена в прод, а метрик не отдаёт🤦🏼♀️
Например, процесс найма можно обвязать метриками пяти кластеров:
Стоимость (cost per hire)
Скорость (time to hire)
Эффективность (final interview conversion)
Качество (candidate's satisfaction)
Загрузка (openings per recruiter)
Это примеры, метрик в районе сорока.
Ниже пример процессных метрик, которые я выделяла для одного клиента.
Синие мы могли тречить, но очень уж сложно (vlookup данных двух систем), а красные не знали, как считать.
И нельзя пилить новые фичи, пока непонятно, на какие метрики они влияют, и как мы измерим эффект.
впервые за то время, что читаю @produnderhood там такой годный контент как сейчас. не знаю, то ли девочка крутая, то ли HR-контент для меня в принципе гораздо интереснее любого другого у нее там в коментах спросили "не скучно ли заниматься внутренним продуктом", и я такая пффф
Среда
Всем доброе утро с home office! Сегодня говорим о сборе бэклога на внутренние продукты или большие системы.
Для начала быстрый опрос.
Как вы получили свой бэклог: при передаче дел от прошлого продакта или создавали с нуля?
🤔
40.4% Достался по наследству🤔
34.0% Собирал/а с нуля🤔
25.5% Я не отвечаю за бэклогВ интеграторе было весело: за день до выхода меня позвали в офис, рассказали про все проблемы этого мира и сказали, что прямо сейчас архитектор, скрам и аналитики пытаются родить с нуля бэклог продукта, который разрабатывался к этому моменту уже год.
Честно?) Получалась какая-то ересь в свободном формате. Зато в Miro. Как пример: в качестве эпиков они выбрали роли пользователей.
Руководство мне предложило их креатив свернуть, что я и сделала.
Только теперь задача собрать бэклог с нуля легла уже на меня😅
История с хэппи эндом: после недели штурма получилась вот такая простыня с гипотезами. Это был первый черновик, который мы сделали.
В следующем треде расскажу, как подойти к задаче создания бэклога структурно.
Создаем бэклог с нуля.
Шаг 1.
Определяем границы функционала. Понимаем верхнеуровнево, что входит в процесс, который надо автоматизировать. Собираем все и записываем как эпики. Тут важно ничего не упустить, чтобы не оказалось, что надо было сделать слона, а мы его не учли.
Я однажды не учла слона, связанного с информационной безопасностью. В тот момент нам это не помешало, но выпило много крови в дальнейшем.
И, если бы стояла задача выйти в прод, а не в тестирование, то безопасники нас бы жестко заблокировали.
Научило на всю жизнь.
Шаг 2.
Понимаем, что уже сделано. Наверняка что-то уже готово. Но что именно, и как это выделить в бэклоге? Просим тимлида или тестировщика провести нам демо того, что готово, рассказать про систему. Прочим доступ к тесту. Так мы сможем прояснить задачу и углубимся в контекст.
В интеграторе я просила членов команды комментировать фичи и говорить, где готово, где нет, где заглушка на фронте. Без чего нельзя прожить. Мы вместе декомпозировали каждый эпик до user stories, которые я пометила тремя цветами: красный=MVP, жёлтый = не MVP, фиолетовый = готово.
Шаг 3.
Подключаемся к разуму основного стейкхолдера. А в идеальной картине сажаем его рядом, пока вместе смотрим демо в шаге 2.
Никто не даёт вижн лучше, чем основной заказчик. Так мы еще получим множество ценных замечаний по тому, что ещё должно быть сделано или сделано не так.
Шаг 4.
Custdev'им.
Третий шаг важен, но мы же делаем систему для людей, а не для заказчика. HRы генерят кучу гениальных идей и методологий, которые потом сложно приземлить.
После интервью проводим переговоры со стейкхолдерами, чтобы убедить их в том, что процесс надо менять.
В Госкорпорации я наблюдала жуткую ситуацию, когда процесс работал более 10 лет, но люди просто не понимали его и не видели в нем смысла. Если бы мы его автоматизировали в таком виде, то не принесли компании никакой ценности, кроме того, что удовлетворили бы высокоуровневую даму.
Шаг Final.
Проверяем прототипы, делаем User Story Map на весь функционал. Выделяем MVP. У
нас точно стоит какой-то дедлайн, в который нужно успеть. И мы уже понимаем, что не успеем сделать 100%. Тут тоже надо делить на релизы. Отличное решение - резать фичи и выделять главное.
Тред #3
🔪 Что вырезаем из MVP сложного внутреннего продукта?
- Сложную логику
- Решения болей вторичных ЦА
- Дублирующиеся элементы
- Сложные фильтры и внутреннюю логику полей
- Секси интерфейс
- Графики и отчёты
- Прости господи интеграции, если только без них НИКАК не жить.
Вообще MVP внутреннего продукта больше похож на MLP, иначе выкатишь решение, все сотрудники его возненавидят, и создадут ему плохой бренд (не будет фич, которые бы их спасли, или будет убогий интерфейс).
MLP = Минимальный продукт, который возможно любить💜
productschool.com/blog/product-m…
О чем поговорим вечером?
🤔
23.9% Процессы в разработке🤔
29.7% Вход в ИТ с нуля🤔
32.6% Must have знания технины🤔
13.8% Тренды HR techТааак, мнения разделились, давайте попробуем совместить разговор про вход в ИТ из вообще другой функции с разговором о том, какие технические знания помогут быстрее въехать и адаптироваться в команде.
🤢 Мне ужасно не нравилось внедрять SAP SF. Система ничего не могла из того, что нам было нужно, менеджер проекта откровенно заваливал его, а консультант по внедрению не мог настроить нужные мне отчёты для выгрузки процессных метрик.
Все изменилось с полным обновлением команды.
Пришли новый проджект и консультант на мой модуль, я тоже перешла на роль владельца продукта и оказалась внутри команды внедрения.
И мир заиграл новыми красками.
SF все ещё не мог многое из того, что хотелось бы, но меня подпустили к настройкам системы, и мне понравилось.
Я стала собирать боли пользователей со всего СНГ, я сама разбиралась в том, какие сущности есть в каждом модуле, и как они взаимосвязаны (или нет, это ж SF😅), как писать бизнес-правила.
Все это в дальнейшем помогло мне быстрее понять логику работы бэка, что такое "ручки" и т.д.
В то же время меня демотивировало то, что я не могу решить все потребности пользователей, потому что SF так не умеет.
А дальше совпали звезды. Меня позвала на интервью на ректурера ИТ компания, и в разговоре возникло слово "продакт". Я пошла гуглить, кто это вообще...и пропала.
Ботала я где-то полгода.
Использовала:
- Лекции школы менеджеров Яндекса
- Лекции Дины Сидоровой из Mail на YouTube
- GoPractice
- Skillfactory
Работу искала около месяца, выбирала из двух офферов по HR автоматизации. Интегратор победил, т.к это была собственная разработка.
В первое время в роли продакта я была абсолютно офигевшей.
Да, я когда-то очень давно учила Бэйсик и Паскаль, но это никак не помогало мне понимать, о чем вообще говорят люди вокруг. Прошлый продакт была системным аналитиком и понимала технину. Я же понимала только HR процессы.
Спасло меня время, ботанство и мои системные аналитики - мои солнце и звезды 💜.
Они настойчиво ходили за мной по офису и объясняли, что такое методы бэкенда, "прикручивание методов", микросервисы, json'ы, ERD диаграммы, sequence диаграммы и так далее.
Тред #4
🧠 Что важно знать продактам по технине (на мой взгляд)?
- Микросервисы VS монолит
- Понимать задачи фронта и бэка (методы, верстка, запросы...)
- Ориентироваться в ERD и БД
- Тестирование
Кодить и писать SQL запросы не must. Если компания это требует, то экономит на аналитике.
Тема про бэклог не очень зашла, так что выровняемся по завтрашнему дню)
О чем писать?
Плюсы и минусы скрама в разных командах.
Процессы в продуктовой команде.
Постить фоточки из офиса Авито.
Другое (о чем - в комментарии).
🤔
33.3% Скрам🤔
41.0% Процессы🤔
24.4% Фоточки😍🤔
1.3% ДругоеЧетверг
В равной борьбе у нас побеждают процессы в продуктовой команде. Значит, сегодня буду занудствовать про бизнес и системную аналитику, про тестирование (БОЛЬ), про выстраивание флоу разработки.
А про ненависть к скраму тогда расскажу уже у себя в канале (ссылка в шапке).
Почему я могу про это говорить?
В интеграторе мы делали продукт командой из 20+ разработчиков, 14 аналитиков, 4 дизайнеров и 6 тестировщиков.
Вместе с начальником разработки и тимлидом системной аналитики мы ускорили путь фичи на стенд на 30%. И при том, что внедрили дискавери.
Ребята работали как стартап и были первой командой, которая делала продукт для Госкорпорации.
Процессы тоже были как в стартапе, а вот бюрократия на уровне гос. компании.
На скрине изначальный процесс discovery/delivery. Когда я его поняла, я захотела уволиться в первый день😬
Какие были проблемы?
Процессный подход, не продуктовый.
Не проводились исследования.
Автоматизировались неоптимальные бизнес-процессы.
Позднее вовлечение заказчика, перерисовывали чистовые макеты.
Тестирование не работало.
Все присутствовали на всех встречах.
Как подошли к решению?
Внедрили дискавери и оптимизацию процессов.
Изменили процесс работы с Заказчиком.
Перестроили с начальником разработки команды разработки.
Переоткрыли тестирование.
Выделили тимлидов каждого стрима.
Изменили роли в команде. Как стало:
В дискавери команду вошли:
- Все бизнес аналитики, которые были закреплены каждый за одним процессом и одним заказчиком.
- По умолчанию заказчики (владельцы бизнес-процессов), хотя задач в Джире у них не было
- Дизайнеры.
- Я как продакт.
Работали спринтами по 2 недели.
В дискавери работали стандартно:
- рисовали as is
- выдвигали гипотезы
- верифицировали их с Заказчиками и проверяли (повторить Х раз)
- рисовали to be
- рисовали макеты на доске в офисе
- рисовали wireflow и апрувили с заказчиком
- апрувили с топом
- рисовали чистовые макеты.
Дальше круче. Выделили роль системного аналитика на стыке Дискавери и Деливери.
Он принимал требования у дизайнера и бизнес аналитика и вместе с техлидом проектировал бэк: разбивал на методы и описывал алгоритмы.
СА был закреплён за одной командой разработки как её мини тимлид.
В чем смысл выделения системных аналитиков?
У кого-то появлялась ответственность за команду и функционал (разработке привить её не смогли).
Увеличение скорости разработки (когда на PBR приносят не бизнес требования, а системные, команда успевает разобрать и сделать больше).
С ручным тестированием было сложно, и пришлось поботать для того, чтобы выстроить процесс.
Как ботали: Яндекс.Практикум.
Ввели стандарт написания сценариев тестирования.
И стандарт логирования багов.
Приземлили тестировщиков в скрам команды.
Научили тестировать бэк.
Тред #5
По итогу процесс Discovery с учетом того, что дискаверили бизнес-процессы и учитывали желания Заказчика, выглядел так.
было много согласований макетов, это из-за того, что все дизайнеры были джуны.
В среднем такой процесс занимал 3-4 спринта в условиях Госкорпорации.
С топом сделали встречу раз в 2 недели, куда приносили наработки по одному большому процессу (только самые ключевые): результаты дискавери, предложение по оптимизации, черновики макетов. Приучили её к тому, что её гениальные предложения - гипотезы, которые будем проверять.
Перечитываю сегодняшний день, вроде такие очевидные вещи и процессы (для зрелой компании), но сколько же нервов и трудов стоило к ним прийти🤷🏼♀️
Ну и как обычно дьявол в деталях, рассказать которые в формате твиттера нет места)
Пятница
Говорят, что 80% успеха команды - эффективный наем.
Чтобы его выстроить, надо:
Понять, кто нам нужен.
Понять, как мы проверим, что человек подходит под наши критерии.
Найти адекватного человека, который поможет с наймом.
Научиться качественно оценивать людей.
Первый вопрос: какие нужны опыты, hard и soft skills для того, чтобы успешно справляться с работой на том уровне, который я ожиданию?
Это значит, что нужно сесть и написать, что мы ожидаем от человека на этой роли. Гипер важно учитывать ту ситуацию, которая сейчас в компании.
Например, ищу я дизайнера.
Вводные:
- Надо внедрить исследования;
- Сделать с нуля дизайн-систему;
- У меня суровые фронты, которые критикуют все макеты;
- Есть куча джунов, которых надо коучить;
- Интерфейсное неединообразие.
Делаем такое описание:
drive.google.com/file/d/1fEs2bd…
А теперь вопрос: какой прошлый опыт и какие компетенции мне нужны у человека, чтобы он смог затащить те вызовы, которые есть на этой роли?
Для начала определяю, какой мне нужен бэкграунд:
drive.google.com/file/d/1smwChW…
Определяем список компетенций:
⚙️Мне нужны софт скиллы:
Нацеленность на результат
Проактивность
Развитие других
Мотивация других
Планирование
Отношения с коллегами
Нацеленность на развитие
Основной вопрос, зачем. И что покажет, что софт скилл развит.
Вот ответы на эти вопросы:
Общий список soft скиллов этого мира можно взять вот в этом прекрасном файле: pdfslide.net/documents/mlcg…
Основан на модели компетенций Ломингера, я им пользуюсь уже лет 5.
Тред #6
Прекрасно, мы поняли ожидания от будущего сотрудника, отдали их рекрутеру.
Рекрутер провел свои этапы и назначил нам интервью. Готовимся!
Хард скиллы дизайнера мы сами оценить не сможем - зовем в помощь тимлида дизайна, который нам поможет.
Софт скиллы оцениваем мы. Но...КАК?
Делюсь бесценным скриптом интервью по софт скиллам, которые мы выделили.
drive.google.com/file/d/1m7MgLa…
Просим привести пример конкретной ситуации, и это уменьшает риск, что человек будет нам врать generic фразами.
Начинаем копать вглубь каждого примера по STAR.
Не забываем, что валидность только софтового интервью 0.2, нам нужно провести структрное интервью (Soft/hard).
Я никогда не увольняла людей за то, что у них недостаточно hard скиллов: это все развиваемо, нужно время.
Но я неоднократно увольняла за отсутствие софтов: нацеленности на результат (ленивый) или умения работать в команде (токсичный).
Последнее про подбор людей. Он может быть дорогим и болезненным, а может быть быстрым и эффективным.
К процессу найма и воронке рекрутмента надо относиться как к продукту, метрики которого нужно улучшать.
Немного примеров из жизни:
Кажется, к софт скиллам многие относятся скептически (а вот для меня не верить в них как не верить в... воду). Продолжаем завтра про софты в контексте плана развития или меняем тему?
🤔
70.0% План развития🤔
7.8% HR продукты🤔
22.2% Ещё про бизнес-процессыНу ладно, говорим про развитие) Бедные HR продукты тихо плачут в углу
Ну ничего, кое-кто с плохим life/work balance сегодня ими тоже займётся.
Самое обидное, что нас никто никогда не учил развиваться (и развивать людей). Система обучения у нас чаще всего построена так, что считается, что вызубрить книжку = прокачаться до уровня бога.
Чуть дальше ушли бизнес-школы, в которых есть обучение через решение кейсов в командах.
Перед тем, как начнём говорить про развитие, сразу дисклеймер.
Говорить я буду на основании тех методологий, которым меня научили в разных корпорациях.
Универсального вселенского знания у меня слава богу нет, только знание того, что сработало или нет в моем прошлом опыте.
Планируем развитие структурно:
1. Определяем желаемую долгосрочную карьерную цель.
2. Строим реалистичный карьерный путь.
3. Определяем следующий шаг.
4. Собираем фидбек.
5. Проводим gap-анализ.
6. Составляем план развития на год.
1. Определяем, чего хотим достигнуть в течение хотя бы 5 лет. Без этого не очень понятно, какой следующий шаг. Важно общее ощущение в жизни. Может быть, корп. карьера не приносит удовлетворения. Тогда надо почувствовать, что приносит. Но если совсем не знаем, переходим к шагу 3.
2. Строим желаемый карьерный путь. Анализируем, какие нужны опыты, hard&soft, чтобы прийти из точки А в Б. Какие роли и проекты помогут этого достичь? Какие смежные функции?
Стараемся строить не один путь, чтобы не зацикливаться на нем.
Завершаю неделю немного раньше, всем хороших выходных, и давайте будем позитивными 👋
