Привет, Хабр! Меня зовут Екатерина Смирнова, я отвечаю за развитие внутренних продуктов в 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