«Мы живем в период IT-ренессанса, когда новое решение — совершеннее предыдущего»: Анзор Кардан про внутренние продукты

Публикуем большой разговор с руководителем продукта Teamplanner, сервиса по управлению внутренними ресурсами, который мы делали вместе с X5 Tech. Поговорили о том, как появляются внутренние продукты, зачем они нужны и почему дизайн-партнер должен быть действительно партнером, а не функцией.

Понятие «внутренний продукт» часто воспринимают неверно и даже путают с внутренней разработкой. Важно на старте определиться с толкованием этого термина. В классическом виде внутренние продукты создаются в двух случаях: когда нужно сократить операционные затраты на типовые операции; когда нужно минимизировать риски, которые могут возникнуть без их использования.

Говоря про внутренние продукты, можно привести такую аналогию. Представьте советское время, колхоз, пасутся коровы, и нужно увеличить выработку молока или оптимизировать процесс уборки. Уже тогда эти ребята придумывали всякие уникальные штуки, которые помогали. Какие-то специальные чесалки для коров — ей приятно и она дает больше молока, или особенные лопаты — с ними хлев убирать быстрее.

По сути все это тоже внутренние продукты, которые используются в рамках какой-то заданной среды, оптимизируют внутренние процессы, экономят ресурсы и время и — как следствие — снижают затраты.

Цифровые внутренние продукты в современном мире так же работают с типовыми рутинными операциями. Люди привыкли перекладывать из одной Excel-таблицы в другую данные внутри одного отдела, а таких отделов еще десять. То есть сформировался какой-то процесс обмена данными, но он закрывается «старинными» методами: почта, Excel, файлы.

И тут внутри появляется человек и говорит, что нужно сделать маленький сервис, нарисовать портал — вы будете там одновременно вносить данные, и вам не нужно будет кидать друг в друга файлами и ждать, пока коллеги их заполнят. Это такой маленький пример возможного внутреннего продукта. Безусловно, оттенки таких решений будут зависеть от процессов, типа компании, ее размера, отрасли и прочее.

Доподлинно неизвестно, как рождаются идеи внутренних продуктов, универсального рецепта нет. Но я бы для себя выделил два момента. Первое — наличие грамотного руководства или сотрудников, которые умеют из операционки поднять голову и посмотреть по сторонам. Задуматься, а не фигню ли мы делаем, можно же по-другому.

Второй момент — когда создается напряжение, под которым отдел или подразделение начинают работать продолжительное время. Терпение лопается, мы получаем внутренний социальный взрыв, и это доносится до руководителя. Он, в свою очередь, понимает, что жить так дальше нельзя и приходит к мысли об инструменте, который это напряжение снимет.

Бывает и такая ситуация — в компании просто много денег. Хочется вложить их в RnD, в исследования. Люди имеют возможность поковыряться в процессах, найти узкие места и постараться их нивелировать автоматизацией, новым решением. То есть руководство осознанно выделяет средства на улучшение собственного инструментария, исследование какой-то области. Видят там экономический эффект и начинают инвестировать в создание внутренних продуктов.

Мне ещё нравится историческая аналогия с периодом ренессанса. Почему в одно время появилось столько гениальных и просто выдающихся творцов — художников, архитекторов, скульпторов. Они друг друга как бы улучшали, и с каждым годом произведения искусства становились все более совершенными.

Когда они рождались, вокруг них уже была какая-то красота, которую хотелось превзойти. Они смотрели на то, что делают другие, и делали лучше. Так и мы живем в период IT-ренессанса, когда хочется сделать что-то более производительное, более функциональное, а новое решение — совершеннее предыдущего.

Когда мы начинали работу над Teamplanner, в X5 в целом шел процесс цифровой трансформации. Мы крупная компания, у нас есть технологический блок, и на фоне этой волны все наши бренды («Пятерочка», «Перекресток» и «Чижик», а тогда еще «Карусель») хотели переупаковать продукты, найти основные драйверы роста. На чем еще можно заработать деньги, как повлиять на основные финансовые метрики: РТО, EBITDA и нефинансовые NPS,CSI итд. В тот период родилось много продуктов на базе Big Data и локальных мини-продуктов, потому что появилась возможность исследовать процессы, поискать точки роста.

Мой продукт родился из того, что предыдущая информационная система управления проектами морально устарела (древний стек технологий, плохо поддерживалась, не развивалась). Это был зарубежный софт — решение на базе Microsoft Sharepoint, оно уже не могло покрыть все запросы, которые у нас были. Тяжело было кастомизировать, гибко настраивать процессы, прикручивать дизайн-макеты и работать с UI/UX.

Я предложил идею — вот есть у нас процесс инициации новых проектов, он существовал в формах в Excel. Ты заполняешь шаблон для расчета проекта, дальше файл отправляется на согласование, в этом участвует много сотрудников. Чем больше проект и чем больше центров компетенций, тем кратно растет время на согласование и утверждение. Кроме того, в этом процессе было множество узких мест, а всего в него было вовлечено до 200 различных руководителей. И здесь как раз я нащупал тот самый экономический эффект. Это можно было ускорить, автоматизировать.

На старте у меня не было ресурсов и денег, только идея — так что я сам отрисовал макеты и пошел ее «продавать» внутри. Руководство заинтересовалось, я получил бюджет на проверку концепции — получилось сначала что-то, что я даже не могу назвать MVP, скорее недо-MVP. Но уже на этом примере было понятно, что решение работает и нужно продолжать. Отсюда началась история развития нашего продукта.

Говоря про истории успеха, важно помнить о том, что не все продукты взлетают. То есть далеко не все одновременно запущенные с Teamplanner проекты дошли до финала и получили развитие. Внутренний продукт иногда может и умереть, либо часть функционала забирает в бэклог на автоматизацию другой продукт — это нормально.

Конечно, сначала мы походили по рынку и посмотрели похожие решения, но ни одно из них не подходило на 100%. Даже если бы на 70% сервис покрывал потребности, оставшиеся 30% как правило становятся очень дорогостоящими. Нужно погрузить интегратора в компанию, он должен проанализировать все процессы, поговорить с большим количеством людей.

То есть закупка стороннего софта становится еще более затратной историей, а времени на адаптацию уйдет не меньше, чем на разработку уже готового внутреннего продукта, буквально созданного под наши требования. То есть мы хотели действительно найти решение на рынке — чтобы включил и заработало — но так не бывает в жизни.

Другая проблематика — процессы не стандартизированы. К примеру, продукт, которым я занимаюсь, про ресурсное и финансовое планирование. И все компании на рынке делают это по-своему. Я часто привожу в пример телеком, где есть неправительственная организация TM Forum, которая устанавливает и развивает единые отраслевые стандарты, которыми пользуются все, подгоняя под них свои решения.

А у нас стандартов и типовых решений нет. Поэтому мы вырабатывали собственную методологию путем наблюдения, общения, обсуждения с внутренними бизнес-единицами. И так формировали свой продукт.

Нам, конечно, еще повезло, что мы начали процесс — по сути — импортозамещения еще до массового ухода вендоров. А теперь у нас на 100% российское ПО на открытых стеках и технологиях. Мы защищены как от санкций, так и от необходимости выплачивать какие-либо лицензионные отчисления.

Мне удалось начать свой проект без долгого формирования бизнес-требований и написания технических заданий. Это длинный и мучительный путь, который, конечно, хорош в некоторых случаях, но мне он не подходил. У меня не было стандартов, процессов и референсов.

Для меня самым действенным способом было визуализировать будущий продукт в виде набросков дизайн-макетов. Нужно было показать, как эта идея выглядит на уровне дизайна, кликабельного прототипа. А в случае с ТЗ и БТ людям сложно увидеть эту красоту процессов, легкость и изящность решения.

Дизайнер — это союзник инициатора продукта, его стратегический партнер. Мой опыт говорит о том, что это партнерство ускоряет в три раза процесс принятия решений, чем когда ты бы пошел по пути составления бесконечных документаций. Так что да, первую идею я отрисовал сам, но как только получил стартовый бюджет — уже обратился в pinkman. Все внутренние дизайнеры, как обычно, были заняты на больших важных зарабатывающих продуктах, а мне нужно было полное погружение.

Есть несколько подходов к работе с дизайнерами, зависят они от того, кто управляет процессом. Первый — я сам такой умный, я знаю, как это должно быть. Нарисуй, как я тебе говорю, и принеси мне. Это путь может быть эффективен для некоторых проектов, он даже может снижать косты, но.

Есть и другой подход. Когда ты говоришь команде дизайна — смотрите, есть идея, есть проблематика — и вместе с ними ты проходишь все продуктовые этапы. Идешь с ними в аналитику, к внутренним пользователям, проводите custdev и вместе вытаскиваете и анализируете их боли. И при этом у дизайн-партнера есть экспертиза, которой нет у тебя. Получается, что на стыке ваших мнений и знаний в итоге начинает выкристаллизовываться более грамотное и правильное решение.

Поэтому дизайн-команду нужно подключать как можно раньше. Творческие люди с нужной экспертизой в отрасли могут решить эту задачу под другим углом, такой Design Thinking. Как правило, они предлагают классные идеи и решения, и это все дальше трансформируется в классный дизайн с классным флоу, удобным для пользователя.

Ребята из студий общаются с большим количеством заказчиков, чувствуют тренды. У них внутри развитая культура обмена мнениями, знаниями и компетенциями, и ты, получается, покупаешь не дизайнера, ты покупаешь сервис, насмотренность. Я получаю доступ к референсам, доступ к трендам, доступ синергетической экспертизе, которая там сосредоточена.

Директивный способ — «Делай, как я скажу!» — тоже работает, но ребята, камон, вы так далеко не уедете. Дизайн продукта давно больше чем дизайн, так дайте им заниматься дизайнерам.