Документация сложных систем. Часть 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.
Треш-пост про лестницу и пустую чашку
Интересно, как в нашей компании все настолько пропитано продуктовым духом, что меня офис-менеджер начала кастдевить на кухне, когда увидела у меня паттерн, который отклоняется от заложенного сценария пользовательского поведения.
🔍 Кейс: каждое утро я пью кофе на работе. Понятный JTBD: В 8.30 утра, когда я сонная и ничего не соображаю, я хочу закинуться дозой кофеина, чтобы настроиться на эффективный рабочий лад.
И компания отлично решает эту джобу: на каждом этаже у нас есть 2 кухни, где стоят кофемашины, чашки и куча сиропов на выбор.
🐞 Что сломалось: офис-менеджер увидела, что я каждое утро с 13 этажа прихожу с чашкой на 14 этаж, наливаю себе там кофе и ухожу.
И вот вопрос, почему пользователь в моем лице ломает такое классное решение боли как «дойти 10 шагов до кухни и налить себе кофе», и идет с чашкой по лестнице на другой этаж?
🕵🏻♂ Гипотезы:
1. У меня есть другая продуктовая боль, что я мало хожу и занимаюсь спортом, поэтому я намеренно игнорирую ближайшую кухню. Но зачем мне тогда чашка? Взяла бы её сразу на 14-м.
2. Мне не нравится сорт кофе на моем этаже. Но это нелогично, он же итальянский. И опять же, зачем мне тогда чашка?
3. Кофе-машины на обеих кухнях сломались. Но…ЧАШКА ЗАЧЕМ?
🙉 Что узнала наш продакт/офис-менеджер, когда задала мне вопросы?
На самом деле я несколько раз сталкивалась с тем, что на 13 этаже в обеих машинках сбоили настройки: либо они наливали не 300мл латте, а где-то 200, либо наливали без молока, либо было очень мало пенки. Плюс они не варят капучино, что немаловажно, я люблю, когда много пенки.
И я устала каждое утро думать, а нальет ли мне машинка вкусный кофе, я хочу один раз нажимать на кнопку и получать нужный результат, а не метаться между двумя кухнями. Поэтому я зачастила на 14 этаж, где машинка меня не подводила + умеет варить капучино с крутой пенкой.
☕️ Настя, ЧАШКА ЗАЧЕМ?
JTBD: Когда я заряжаюсь кофеином, я хочу, чтобы мне нравился вкус напитка, для того, чтобы мои вкусовые рецепторы тоже получали удовольствие.
Разгадка: я люблю кофе с мятным сиропом. А на 14 этаже стоят все сиропы кроме мятного. Поэтому я каждое утро иду на кухню на 13 этаже, беру розовую чашку, наливаю в нее мятный сироп, а потом иду на 14 этаж и наливаю там капучино.
😅 А теперь блестящий вопрос от офис-менеджера: почему я не пошла в чатик поддержки и не попросила пофиксить машинки (у нас это делают в момент) или принести сироп?
Ну, я же пользователь. Кто сказал, что мое поведение в продукте должно быть логичным 😂
Интересно, как в нашей компании все настолько пропитано продуктовым духом, что меня офис-менеджер начала кастдевить на кухне, когда увидела у меня паттерн, который отклоняется от заложенного сценария пользовательского поведения.
🔍 Кейс: каждое утро я пью кофе на работе. Понятный JTBD: В 8.30 утра, когда я сонная и ничего не соображаю, я хочу закинуться дозой кофеина, чтобы настроиться на эффективный рабочий лад.
И компания отлично решает эту джобу: на каждом этаже у нас есть 2 кухни, где стоят кофемашины, чашки и куча сиропов на выбор.
🐞 Что сломалось: офис-менеджер увидела, что я каждое утро с 13 этажа прихожу с чашкой на 14 этаж, наливаю себе там кофе и ухожу.
И вот вопрос, почему пользователь в моем лице ломает такое классное решение боли как «дойти 10 шагов до кухни и налить себе кофе», и идет с чашкой по лестнице на другой этаж?
🕵🏻♂ Гипотезы:
1. У меня есть другая продуктовая боль, что я мало хожу и занимаюсь спортом, поэтому я намеренно игнорирую ближайшую кухню. Но зачем мне тогда чашка? Взяла бы её сразу на 14-м.
2. Мне не нравится сорт кофе на моем этаже. Но это нелогично, он же итальянский. И опять же, зачем мне тогда чашка?
3. Кофе-машины на обеих кухнях сломались. Но…ЧАШКА ЗАЧЕМ?
🙉 Что узнала наш продакт/офис-менеджер, когда задала мне вопросы?
На самом деле я несколько раз сталкивалась с тем, что на 13 этаже в обеих машинках сбоили настройки: либо они наливали не 300мл латте, а где-то 200, либо наливали без молока, либо было очень мало пенки. Плюс они не варят капучино, что немаловажно, я люблю, когда много пенки.
И я устала каждое утро думать, а нальет ли мне машинка вкусный кофе, я хочу один раз нажимать на кнопку и получать нужный результат, а не метаться между двумя кухнями. Поэтому я зачастила на 14 этаж, где машинка меня не подводила + умеет варить капучино с крутой пенкой.
☕️ Настя, ЧАШКА ЗАЧЕМ?
JTBD: Когда я заряжаюсь кофеином, я хочу, чтобы мне нравился вкус напитка, для того, чтобы мои вкусовые рецепторы тоже получали удовольствие.
Разгадка: я люблю кофе с мятным сиропом. А на 14 этаже стоят все сиропы кроме мятного. Поэтому я каждое утро иду на кухню на 13 этаже, беру розовую чашку, наливаю в нее мятный сироп, а потом иду на 14 этаж и наливаю там капучино.
😅 А теперь блестящий вопрос от офис-менеджера: почему я не пошла в чатик поддержки и не попросила пофиксить машинки (у нас это делают в момент) или принести сироп?
Ну, я же пользователь. Кто сказал, что мое поведение в продукте должно быть логичным 😂
Начинаем вебинар про бизнес-процессы, приходите к нам!
Ссылочка на трансляцию: https://zoom.us/j/6289646964
Ссылочка на трансляцию: https://zoom.us/j/6289646964
Появилась запись вебинара: https://clck.ru/XFVaU
На самом деле ожидала, что подготовка будет такой ресурсной.
🧘♀ Рефлексия:
1. Слайды.
Мы в Авито в подавляющем большинстве случаев отказались от использования слайдов и используем формат Word. Я сначала не понимала, в чем прикол, а потом поняла, насколько это круто и дёшево в производстве.
Прямо вспоминаю свой прошлый опыт: "Да, Настя, аналитика в экселе у тебя отличная, а теперь переложи это на слайд". Ну нет😭.
2. В первую очередь я делаю слайды для себя, чтобы понять, о чем буду говорить. Трачу на это кучу времени, а потом не успею отредактировать из формата "для чтения" в формат "для выступления". Не говоря уже о том, что для такого формата надо наизусть знать текст, а свой даже прогнать 1 раз полностью не успела.
3. Не думала, что у меня так много контента, которым хочется поделиться. За ночь 32 слайда превратились в 41, из которых я со щемящим сердцем пыталась хоть что-то выпилить, чтобы уложиться в 90 минут. Спойлер: не уложилась.
4. Очень классные вопросы и тёплый фидбек в конце 💜
Мотивирует продолжать выступать дальше.
На самом деле ожидала, что подготовка будет такой ресурсной.
🧘♀ Рефлексия:
1. Слайды.
Мы в Авито в подавляющем большинстве случаев отказались от использования слайдов и используем формат Word. Я сначала не понимала, в чем прикол, а потом поняла, насколько это круто и дёшево в производстве.
Прямо вспоминаю свой прошлый опыт: "Да, Настя, аналитика в экселе у тебя отличная, а теперь переложи это на слайд". Ну нет😭.
2. В первую очередь я делаю слайды для себя, чтобы понять, о чем буду говорить. Трачу на это кучу времени, а потом не успею отредактировать из формата "для чтения" в формат "для выступления". Не говоря уже о том, что для такого формата надо наизусть знать текст, а свой даже прогнать 1 раз полностью не успела.
3. Не думала, что у меня так много контента, которым хочется поделиться. За ночь 32 слайда превратились в 41, из которых я со щемящим сердцем пыталась хоть что-то выпилить, чтобы уложиться в 90 минут. Спойлер: не уложилась.
4. Очень классные вопросы и тёплый фидбек в конце 💜
Мотивирует продолжать выступать дальше.
Пинок ногой из зоны комфорта: вход в менторинг
Для меня всегда одной из основных ценностей было помогать людям и улучшать мир вокруг меня. Многие мои важнейшие жизненные выборы были связаны с этой мотивацией, в том числе выбор первого образования и профессии. В том числе поэтому в последнее время я много времени инвестирую в менторство ребят из коммьюнити. Последние две недели провожу встречи буквально каждое утро.
Формальный вход в сущность ментора дался мне непросто. Я как человек, которому вообще не свойственен синдром самозванца, все равно задавалась вопросами «у меня очень специфичный опыт и бэкграунд, зачем им делиться?» и «если кому-то и интересен мой опыт на стыке, то это тоже люди на стыке, а таких людей максимально мало». При этом ко мне много лет стучались в личку и на карьерных ивентах люди с однотипными запросами, а я как будто игнорировала, что такой паттерн есть.
Не так давно мы в Авито стали работать нам тем, чтобы активнее делиться опытом и экспертизой с окружающим миром, и зашли на платформу Getmentor. Причем зашли очень крутым составом: там и дизайн директор, и глава UX лабы, и один из tech директоров, и несколько мощнейших продактов. Я тоже создала себе профиль и описала, чем могу помочь, ни на что особо не рассчитывая (ибо см. выше).
И я была очень удивлена, что мне почти сразу падать заявки. В основном они касаются запросов:
1. Как войти в продакт менеджмент без релевантного опыта.
2. Как составить резюме/ адаптировать опыт для резюме/ лучше описать проекты и достижения.
3. Как понять зоны развития как продакта и прокачать их.
То есть, что самое крутое, это все карьерные запросы к моему опыту на стыке, который, как я думала, никому не интересен.
Причем запросы оставляют совершенно разные люди. Для меня шок, когда ко мне на менторство приходит человек уровня топ-менеджера, который ВУЗ закончил раньше, чем я родилась. Да, он не из ИТ, и хочет войти в ИТ, но чем я могу ему помочь? А оказывается, что могу или частично могу, и я от этого очень сильно кайфую.
🆓 И кстати это все абсолютно бесплатно, потому что для меня ценно не денег поднять, а реально помочь.
В ближайшее время тут будет несколько постов про рефлексию менторства, а если у вас есть запрос, можете перейти на GetMentor и оставить заявку мне или кому-нибудь еще из экспертов Авито (там для нас даже специальный тэг создали😉).
Для меня всегда одной из основных ценностей было помогать людям и улучшать мир вокруг меня. Многие мои важнейшие жизненные выборы были связаны с этой мотивацией, в том числе выбор первого образования и профессии. В том числе поэтому в последнее время я много времени инвестирую в менторство ребят из коммьюнити. Последние две недели провожу встречи буквально каждое утро.
Формальный вход в сущность ментора дался мне непросто. Я как человек, которому вообще не свойственен синдром самозванца, все равно задавалась вопросами «у меня очень специфичный опыт и бэкграунд, зачем им делиться?» и «если кому-то и интересен мой опыт на стыке, то это тоже люди на стыке, а таких людей максимально мало». При этом ко мне много лет стучались в личку и на карьерных ивентах люди с однотипными запросами, а я как будто игнорировала, что такой паттерн есть.
Не так давно мы в Авито стали работать нам тем, чтобы активнее делиться опытом и экспертизой с окружающим миром, и зашли на платформу Getmentor. Причем зашли очень крутым составом: там и дизайн директор, и глава UX лабы, и один из tech директоров, и несколько мощнейших продактов. Я тоже создала себе профиль и описала, чем могу помочь, ни на что особо не рассчитывая (ибо см. выше).
И я была очень удивлена, что мне почти сразу падать заявки. В основном они касаются запросов:
1. Как войти в продакт менеджмент без релевантного опыта.
2. Как составить резюме/ адаптировать опыт для резюме/ лучше описать проекты и достижения.
3. Как понять зоны развития как продакта и прокачать их.
То есть, что самое крутое, это все карьерные запросы к моему опыту на стыке, который, как я думала, никому не интересен.
Причем запросы оставляют совершенно разные люди. Для меня шок, когда ко мне на менторство приходит человек уровня топ-менеджера, который ВУЗ закончил раньше, чем я родилась. Да, он не из ИТ, и хочет войти в ИТ, но чем я могу ему помочь? А оказывается, что могу или частично могу, и я от этого очень сильно кайфую.
🆓 И кстати это все абсолютно бесплатно, потому что для меня ценно не денег поднять, а реально помочь.
В ближайшее время тут будет несколько постов про рефлексию менторства, а если у вас есть запрос, можете перейти на GetMentor и оставить заявку мне или кому-нибудь еще из экспертов Авито (там для нас даже специальный тэг создали😉).
https://getmentor.dev
Анастасия Кондрашова | GetMentor – открытое сообщество IT-наставников
Senior Product Manager / Head of HR Automation @ Avito | GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе…
Из кого получается удобный для ментора менти (или Почему важно Знание себя)?
Я сейчас тестирую фреймворки менторинга, которые создаю сама. И сегодня подтвердила одну гипотезу про свой фреймворк карьерного консультирования.
🥅 В первую очередь ментор должен понять или помочь идентифицировать позитивную цель, которую менти себе поставил или может поставить. При этом важно, что цель не должна быть негативная. То есть нельзя говорить "самое главное - уйти из техподдержки/ моей текущей компании". Надо говорить "я хочу прийти к...". И вот за этим многоточием скрывается самое главное.
🙋🏼♀ Я могу помочь заполнить это многоточие, но сделать это быстро (читай за 1 час) я смогу только если у менти развита компетенция Self-awareness.
Что это значит? Базово, что человек способен рефлексировать относительно себя и отвечать на вопросы про то, что у него круто получается, что не особо, какие он вещи и проекты считает ценными, а от чего его воротит. И это довольно сложно сделать, если выгорел, и бесит буквально ВСЕ. А ещё сложнее, если скилл рефлексии просто не прокачан, и человек на меня смотрит абсолютно пустым взглядом. Тут я сразу понимаю, что за один раз мы не управимся.
Без скилла self-awareness человек просто плывет по течению, рандомно обучается всему подряд, распыляется, не использует свои сильные стороны. Точно не может самостоятельно осознанно поставить себе цель.
А ещё это супер важный нывык именно для продакта, которому постоянно нужно понимать, какие конкретно ему сейчас скиллы нужны для развития продукта, и чего не хватает в эту секунду.
😓 Прокачивать знание себя, как мне кажется, можно, но это долгий процесс. У многих из нас какие-то ответные реакции на внешние раздражители записываются в мозгу и анализируются интуитивно, а кому-то надо попробовать ряд техник, чтобы начать замечать такие вещи.
У меня есть ряд гипотез, как можно быстро и слегка искусственно добрать self-awareness, продолжу их проверять и делиться тут результатами.
Я сейчас тестирую фреймворки менторинга, которые создаю сама. И сегодня подтвердила одну гипотезу про свой фреймворк карьерного консультирования.
🥅 В первую очередь ментор должен понять или помочь идентифицировать позитивную цель, которую менти себе поставил или может поставить. При этом важно, что цель не должна быть негативная. То есть нельзя говорить "самое главное - уйти из техподдержки/ моей текущей компании". Надо говорить "я хочу прийти к...". И вот за этим многоточием скрывается самое главное.
🙋🏼♀ Я могу помочь заполнить это многоточие, но сделать это быстро (читай за 1 час) я смогу только если у менти развита компетенция Self-awareness.
Что это значит? Базово, что человек способен рефлексировать относительно себя и отвечать на вопросы про то, что у него круто получается, что не особо, какие он вещи и проекты считает ценными, а от чего его воротит. И это довольно сложно сделать, если выгорел, и бесит буквально ВСЕ. А ещё сложнее, если скилл рефлексии просто не прокачан, и человек на меня смотрит абсолютно пустым взглядом. Тут я сразу понимаю, что за один раз мы не управимся.
Без скилла self-awareness человек просто плывет по течению, рандомно обучается всему подряд, распыляется, не использует свои сильные стороны. Точно не может самостоятельно осознанно поставить себе цель.
А ещё это супер важный нывык именно для продакта, которому постоянно нужно понимать, какие конкретно ему сейчас скиллы нужны для развития продукта, и чего не хватает в эту секунду.
😓 Прокачивать знание себя, как мне кажется, можно, но это долгий процесс. У многих из нас какие-то ответные реакции на внешние раздражители записываются в мозгу и анализируются интуитивно, а кому-то надо попробовать ряд техник, чтобы начать замечать такие вещи.
У меня есть ряд гипотез, как можно быстро и слегка искусственно добрать self-awareness, продолжу их проверять и делиться тут результатами.
#вебинар
Сегодня в 19:00 веду вебинар про составление резюме продактов в рамках карьерного марафона от ProductStar🚀.
Поговорим про:
- Как подходить к резюме как к продукту
- Смешные косяки и best practices составления резюме продакта
- Как составить резюме стажера/джуна, миддла и синиора.
Прикольно было структурировать в слайдах и советах тот контент, который был у меня в голове.
Ссылка на трансляцию будет вечером.
Сегодня в 19:00 веду вебинар про составление резюме продактов в рамках карьерного марафона от ProductStar🚀.
Поговорим про:
- Как подходить к резюме как к продукту
- Смешные косяки и best practices составления резюме продакта
- Как составить резюме стажера/джуна, миддла и синиора.
Прикольно было структурировать в слайдах и советах тот контент, который был у меня в голове.
Ссылка на трансляцию будет вечером.
Стартуем вебинар про резюме, приходите, кому тема актуальна💜
Ссылочка на трансляцию:
https://www.youtube.com/watch?v=O7xhtttgdIc
Ссылочка на трансляцию:
https://www.youtube.com/watch?v=O7xhtttgdIc
YouTube
Ужасные и прекрасные резюме продакт-менеджеров: разбираем примеры, учимся делать продающее резюме
Зарегистрироваться на Карьерную консультацию 👉 https://is.gd/Rd8dtC
Оставить заявку на курс по продакт-менеджменту👉 https://is.gd/tIdKj4
Оставить заявку на курс по продакт-менеджменту👉 https://is.gd/tIdKj4