Привет, Хабр! Меня зовут Екатерина Смирнова, я отвечаю за развитие внутренних продуктов в MANGO OFFICE.
Давайте попробуем разобраться, что такое внутренний продукт, где его место внутри современного бизнеса, какие сложности испытывают команды, работающие над внутренними продуктами.
Я занимаюсь внутренними продуктами 13 лет и, по-моему, столкнулась уже со всеми возможными сложными ситуациями.
Каждый раз, встречаясь с вопросом, на который у меня не было ответа, я шла серфить интернет в надежде найти релевантный опыт. Увы, на просторах сети мало кто делится чем-то здравым по поводу внутренних продуктов.
Я много раз обращалась к своим коллегам по цеху из ВМК МГУ и с предыдущих мест работы, к знакомым с конференций и различным тренерам. Чаще всего ответы на вопросы опирались на теорию, но не на опыт. А хотелось посмотреть реальные кейсы, узнать, как кто-то уже разрешил аналогичные проблемы, поучиться на чьем-то опыте.
Сначала давайте засинхронимся, что такое внутренний продукт. Почему нужно отдельно говорить о продуктах внутренних и внешних.
Хочу сразу внести ясность, что все сказанное дальше — мой опыт, пропущенный через мою субъективную призму реальности.
Итак, внутренний продукт — это самописный или вендорский с собственным кастомом продукт, который внедрен в компании для закрытия собственных нужд по тем или иным бизнес-процессам и бизнес-функциям компании. Это такой «помогатор» для достижения бизнес-результата.
Основное, на что мы смотрим — какой бизнес-результат должен быть достигнут теми или иными подразделениями, и как они могут существенно выиграть, используя информационные системы. Тут могут быть совсем разные примеры: от выполнения плана продаж x10 без найма дополнительных продавцов до выполнения регуляторных норм. Суть одна — есть бизнес-цель, есть инвестиции, адекватные для ее выполнения, и есть вопрос: «Какую работу может забрать на себя внутренний продукт?». В большинстве случаев мы получаем бОльшие или меньшие бизнес-изменения, которые сильно (или чуть-чуть) меняют бизнес-процессы и стандарты работы внутри компании путем приземления их на софт. То есть задача команды внутренних продуктов — понять ценность, увидеть энд-ту-энд процессы, отреинжинить их, автоматизировать или роботизировать то, что нужно, а далее за руку с бизнесом внедрить изменения в жизнь (привет регламентам, обучению, работе с сопротивлениями, изменению мотивации).
Итого если все это обозначим в путь длиной Х, то сама разработка фичей в продукте будет в лучшем случае Х/3 от всего объема работ.
Давайте сегодня поговорим о тех трудностях, с которыми сталкивается команда внутренних продуктов на пути к своим целям. Остановимся на трех.
Первая. Восприятие заказчиками работы, которую делают внутренние продукты, как довольно легкой
Итак, представление:
Кажется, что все реально должно быть просто. Есть мощный представитель бизнеса, он же — владелец бизнес-функции, которая будет подвергаться трансформации, он же — заказчик.
И вот приходит заказчик с идеей. Первое, что видится: кто, если не он, точно знает, что делать. Это же его процессы и его зона компетенций, уж его-то идея взлетит точно. Берем, разрабатываем, выпускаем в прод и, как будто, успех неизбежен.
В таком случае задача внутреннего продукта выглядит действительно очень легкой — просто качественно и в срок сделать то, что просят. Легко же? Элементарно!
Реальность:
В голове бизнес-заказчика множество идей. У него за рабочий день десятки касаний с метриками/смежниками/подчиненными/конкурентами/клиентами! И его задача — сохранить и донести до команды продуктов те идеи, которые, возможно, выстрелят и дадут кратные результаты.
По сути, на данном этапе речь идет даже не о гипотезе, а именно об идее уровня «А что, если мы сделаем вот так…».
На этом этапе продуктовый менеджмент берет идею и начинает ее приземлять на реальность, проверять, оценивать, обсуждать с коллегами из бизнеса с целью поиска истинных задач/целей/болей, которые лежат за ней. Из идеи постепенно рождается гипотеза, с метриками, критериями ее проверки, вариантами тестирования. По части идей до реализации проводится глубокая аналитика данных, запускаются тесты, измеряются результаты.
И если после всех этих этапов сохранится ответ: «Да, эта идея принесет ценность нашей компании», то идем в разработку, сразу планируя внедрение изменения вместе с бизнесом (обучения, регламенты, изменения мотивации и прочее) и проверку «выстрелило ли» в реальности (отчетность, точки срезов, процессы супервизии).
И, конечно, все это нужно успеть сделать в адекватные сроки, чтобы идея не стухла, осталась актуальной.
Уже кажется, что все не так легко, зато увлекательно.
В чем ловушка:
Заказчик часто приносит идею с горящими глазами и верой в успех, ему нужно срочно и все сразу. В его восприятии он уже все придумал, дело за малым — быстро сделать.
Продуктовый менеджер попадает в волну обаяния заказчика, берет сырую идею и несет в разработку, не продумав все то, о чем написано выше.
Часто итоги такой реализации — функционал на продакшн, который не несет никакой пользы. А выводы о работе команды — вы делаете то, что приносят готовеньким на блюдечке, да еще и не очень эффективно.
Что сделать, чтобы было проще:
Грубый чек-лист для того, чтобы не попасть в ловушку «Это легко, сейчас запилим за пару часов». Продуктовому менеджменту и команде продукта стоит поставить галочки по всем пунктам прежде, чем стартовать работу или отгружать на прод:
Так весь рабочий путь будет более осознанным, продакшн не будет захламлен никому не нужным функционалом, а результативность команды будет в разы выше.
Второе. Желание сделать сразу все, до малейших деталей и каждого мельчайшего сценария
Представление:
Когда доходит до реализации процессов с помощью внутренних продуктов, первым делом продуктовая команда сталкивается с отторжением со стороны команды от бизнеса. В целом, здесь все понятно: работали себе люди спокойно, пришли какие-то ребята и давай вмешиваться и встраивать информационные системы, которые хоть и облегчают труд, но ведь еще и формируют дополнительный контроль и надзор над происходящим. Спустя время все страхи проходят, прелесть удобных систем становится очевидна, и наступает другая крайность: нужно автоматизировать все! Наступает эра «полета в космос».
Любой запрос превращается в «мы все хотим все сразу». Начинается гонка за тем, как покрыть все кейсы, даже те, что выстреливают раз в пять лет и делаются руками ровно три минуты. Кажется, что если продукт начинает забирать на себя работу, то он должен покрыть абсолютно все. А если нет — плохой продукт.
Бизнес-заказчику кажется, что где-то там у кого-то есть идеальные продукты: очень красивые, очень удобные, очень умные. Поэтому перейти с бумаги и экселя нужно непременно сразу в космолет, иначе — «фи».
Этим начинают грешить как заказчики, так и продуктологи, и команды продукта. Следствие — долгая проработка, долгая разработка, долгое тестирование, вываливание на людей такого количества функционала с разными нюансами, которое тяжело осознать. Итог — дорогое решение, внедрение которого запоздало, отторжение у пользователей, позор продуктовой команде.
Реальность:
На деле все упирается в поиск баланса между достижением цели, затратами и скоростью. В бой идет пресловутый MVP, минимально жизнеспособный продукт. Да-да, это отличное решение — разбивать весь замысел на минимально жизнеспособное решение и последующую доработку продукта. Если у вас вендорский продукт, вначале ставим его максимально на стандартные рельсы с последующий апгрейдом, если гипотеза MVP подтвердится. Если свой продукт — с учетом адекватности инвестиций, чтобы потом не жалко было выбросить, если гипотеза не выстрелит.
И далее в случае успеха — развитие, развитие и еще раз развитие до тех пор, пока экономика инвестиций в этот продукт и в эти кейсы будет сходиться.
И вот это самое разделение всего замысла «художников» на части нередко проходит очень болезненно, с комментариями от бизнеса: «Я в таком решении вижу мало ценности», от команды: «Это недорешение», — и так далее.
В чем ловушка:
Когда садится брейнштормить команда продактов и владельцы от бизнес-функции, начинается настоящее творчество, мозг кипит, идеи летят, «а можно еще вот так», «а вот так вообще будет пушка» и в итоге получается огромная бизнес-логика, мысль доходит до тех самых «бантиков и рюшечек», в воображении рождается идеальный великолепный процесс, базирующийся на использовании нового продукта. В этом творческой процессе нет времени, нет инвестиций, нет сроков, нет потребности делить ресурс между многими направлениями деятельности. В реальности — все это есть, и приходится резать «по живому».
Что сделать, чтобы было проще:
Я не буду рассказывать о том, что затраты должны быть адекватны полученной выгоде, что нужно декомпозировать и так далее. Это все и так понятно.
О чем точно стоит помнить: люди, которые будут работать в вашей системе, — не владельцы функции, зачастую даже не сопровождают весь энд-ту-энд процесс, у них есть четкий кусок их работы, который они должны делать максимально круто (результативно, быстро, удобно и, желательно, с удовольствием). Но если система делает автоматические действия, «переварив» при этом 33 условия в комбинаторике из 100, то человеческая голова не в состоянии это принять (либо быстро, либо совсем). И тем самым ваша фантастическая бизнес-логика превращает жизнь работников в ад. Они перестают понимать, система помогает или что-то идет с ошибкой, так должно быть или нет, все хорошо или нет.
Я видела много реакций людей в таких случаях: кто-то забивает, кто-то валит по 100 обращений в поддержку, кто-то заводит «Гуглдокс» и туда параллельно все пишет «на всякий случай».
Нет, это не значит, что не нужно делать умные решения, это значит, что нужно аккуратно и постепенно внедрять их как изменения, чтобы ваши пользователи успевали их осознать, понять, принять и научиться с наслаждением в них жить.
Итого — помним, что софт хорош только там, где подготовлено бизнес-изменение, где люди аккуратно и эволюционно улучшают и улучшаются. Всегда ищите этот баланс между выгодой бизнеса и людьми, которые эту выгоду добывают.
Третье. Забывать получать удовольствие от сделанной работы и фиксировать свои достижения
Представление:
Обычное дело — брать работу, быстро и качественно делать, постоянно улучшать свое мастерство, за счет этих улучшений от итерации к итерации брать больше и больше работы, постоянно наращивать свою производительность, держа высокий темп.
Кажется, что это позволяет показать, как много всякого важного для компании мы делаем, как мы результативны. Бесконечное улучшение и наращивание темпа приводит к росту ценности самой команды. Бизнес счастлив, что продуктовая команда такая мощная, продуктовая команда счастлива брать все новые и новые планки. Бежим быстро и красиво, закрываем много фичей, внедряем много изменений.
Реальность:
А как измерить? Да, у каждой цели и фичи есть ценность. Но во внутренних продуктах, как правило, нет прямой выручки, то есть показать те самые заветные рубли крайне сложно. У наших пользователей также нет права выбора: работать там или тут, так как компания выбирает инструмент, поэтому классические DAU, MAU важны, но не являются явной опорой в результат.
На какие радары положить бизнес-эквивалент выручки? Как показать окупаемость команд внутренних продуктов?
Как для самих команд наладить процесс прочувствовать свой результат, дать подтверждение для ума своих собственных достижений и получить энергию и запал на следующий рывок? Многие ли компании вообще думают об этой стороне вопроса?
В чем ловушка:
Если нет объективных радаров, то вопросы из разряда: «Что мы такого масштабного сделали?», «Принесли ли мы компании больше, чем компания тратит на нашу зарплату?», «Успешен ли наш продукт?», Нужно ли увеличивать инвестиции?» — остаются без ответов, управление переходит на уровень эмоций и субъективного восприятия.
И тут возможны две сопутствующие проблемы: просьбы от компании к продуктовым направлениям объяснить свои результаты и мозгомучения внутри команды на тему: «Зачем мы вообще делаем эту работу, не пойти ли нам на рынок поискать что-то поинтереснее». И то, и другое прямой путь к развалу команды.
Что сделать, чтобы было проще:
Ответ — сверстать P&L внутреннего продукта, который будет глубже в части своей P, чем привлеченная выручка, и глубже, чем отчет, а также станет ритуалом осознания ценности внутри команд.
На этой ноте я хотела бы войти с вами в диалог и порассуждать на эту тему в комментариях. Ведь тут может быть так много полезного и так много снимающего головняк ежедневной работы.
Если вы увидите пользу от этой статьи и дадите отклик, я напишу еще продолжение, где детально пройдусь по теме P&L, там есть о чем поговорить и есть чем поделиться.
Ну и да, всегда помним, что все по силам и все можно разрулить, нужна только волшебная таблетка в виде желания + готовности брать ответственность + умения перевести негативный опыт в выводы + немного самоиронии. Все очень просто и все возможно! Погнали!
Подписывайтесь на наши соцсети:
Аккаунты Mango Office
ВКонтакте: https://vk.com/mangotelecom
Телеграм: https://t.me/mango_office