Три распространённые ошибки цифровой трансформации

📍 Технология - самое главное

Помогают ли технологии решать сложные задачи? Конечно! Все мы знаем массу успешных примеров, о таких ещё часто рассказывают на конференциях. Например, о том, как технологии искусственного интеллекта сэкономили десятки миллионов рублей на обслуживании оборудования. Но сколько неудачных примеров вам известно? Их много. И часто они случаются из-за неправильной оценки применимости технологии или конкретного продукта для решения поставленной задачи. Может существовать отличное технологическое решение, которое работает на многих предприятиях, но оно не интегрируется с вашими системами, или, что ещё хуже, не разрабатывалось с учетом требований вашей отрасли или бизнес-процессов. В этом случае начинается процесс забивания гвоздей микроскопом. Конечно, в некоторых случаях это работает. Можно решить отдельные задачи, цифровизовать некоторые функции, но построить цифровое решение, способное к масштабированию и адаптации к новым потребностям компании уже не получится.

📍 Быстрые проекты - быстрые результаты

Наверное, все любят “быстрые победы”. Кажется, что это магическое словосочетание звучит в каждом втором проекте. Давайте по-быстрому внедрим виртуальную реальность в процесс обучения и улучшим нашу работу в 10 раз! Это понятное и правильное стремление - краткосрочные выгоды придают дополнительные импульсы развитию цифровой трансформации в организации. Но строить всю дорожную карту трансформации короткими планами - ошибочный путь. Изначально нужно строить планы хотя бы на 3-5 лет. Долгосрочное планирование и возможность внесения корректировок в первоначальные планы - один из самых важных пунктов в успехе цифровой трансформации.

📍 Всё делаем сами

Часто в начале проекта кажется, что самостоятельная реализация проекта отличная идея. Вы создаёте уникальное, адаптированное к вашему бизнесу решение, наращиваете разносторонние компетенции о проекте, контролируете весь процесс. Но опыт (и некоторые исследования) показал, что преимущества такого подхода проигрывают недостаткам. Обычно это более длительные сроки, высокие затраты и меньшие результаты. Для успешной цифровой трансформации сконцентрируйтесь на своих ключевых бизнес-компетенциях и поиске партнёров. Далеко не всем компаниям нужна внутренняя компетенция по постановке задач дизайнерам пользовательских интерфейсов. Отдайте это профессионалам, которые знают как работать с дизайнерами, а сами двигайте бизнес вперёд.

Часто IT-компаниям кажется, что заказчик должен базово разбираться в процессах разработки. Неприятный факт – не должен. Здорово, если заказчики обладают экспертизой. Но если нет, задача – IT-компании помочь всем участникам не наделать ошибок в проекте.

Сегодня поговорим про две из них – менеджмент и попытки обхитрить время.
Объясню на примере нашего проекта.

В Rubius мы сделали систему, которая отслеживает местоположение персонала и техники под землёй. Заказчик впервые покупал разработку, а не готовое ПО. Проект был комплексным: мы писали код, партнёры монтировали железо, а заказчик контролировал и ставил задачи.

🙅При правильном менджменте все понимают, кто за что отвечает и качество чего контролирует. И есть главный менеджер проекта, у которого в голове есть вся картинка с ролями, дедлайнами и артефактами. Но в этом проекте зоны ответственности были максимально размыты, и все надеялись друг на друга. В результате на этапе тестирования системы мы обнаружили, что датчики установили неправильно. Заказчик предположил, что пока ПО неготово – их нет смысла проверять. А мы не проговорили требования к проверке датчиков. В итоге все потеряли время на переустановке и отладке.


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

📌 Совет заказчикам – если вы только задумываетесь об автоматизации ваших бизнес-процессов – ищите компанию, которая будет вам помогать учиться и готова объяснять, что и как.

📌Совет разработчикам – убедитесь, что за каждую часть проекта есть ответственный и критерии качества работы понятны. Если ответственных больше одного, поздравляем – риски выйти из бюджета только что выросли.

Как увеличить прибыль за счёт цифровой трансформации клиентского опыта? – Кажется, что у рынка уже есть примеры и ответы.

Цифровизация бизнеса – это тренд, который нельзя игнорировать. По прогнозам агентства "Research and Markets", инвестиции в этот сектор к 2025 году достигнут 1009,8 миллиардов долларов.

Что в тренде? Фокус на клиентском опыте. Так что, если хотите держать руку на пульсе, уделяйте внимание не только качеству продукта, но и удобству процесса покупки.

Идеальный пример – Квартиротека IKEA

Поток посетителей офлайн-магазинов IKEA за последние годы снизился. Всё больше молодых людей переезжают в городские районы, меньше водят автомобили и больше покупают товары онлайн. Поэтому компания решила развивать интернет-продажи.

В России 60% людей живут в стандартных советских квартирах с однотипными дизайнами и планировками. IKEA воспроизвела эти планировки в 3D-конструкторе “Квартиротека”. Сервис помогает клиентам подобрать мебель от IKEA и увидеть, как она будет смотреться у них дома, просто кликая мышкой.

Решение привлекло 2,8 миллиона посетителей на сайт IKEA, большинство из которых стали новыми клиентами. Это способствовало росту продаж в России на 17% в 2020 году.

По нашему опыту, для большего выхлопа, нужно искать место, где продажи встали. Анализировать CJM и своих клиентов. А потом внедрять инструменты, которые помогут увеличить число клиентов на входе и их конверсию в сделку.

Привет! Сегодня у меня был разговор с заказчиком, после которого захотелось поделиться мыслями.

“Илья, мы хотим начать с себя, а потом вывести продукт на рынок”

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

🔎 Попробуем разобраться.

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

Поэтому первый этап не подробное ТЗ, а исследования. Рынка, аудитории, проблем, трендов. Всегда. Даже если вам кажется, что вы на 100% знаете, в чём проблема таких компаний, как ваша. Ваша экспертиза сыграет с вами злую шутку, мы тоже в такой ситуации бывали – дорого и больно.

Исследование можно делать самим, нанять продакт-менеджера или аутсорсить компаниям-экспертам. Все варианты хороши в разных случаях.

Что нужно анализировать:

📍Проблему, требующую решения, и целевую аудиторию. Здесь вы предполагаете, кто и в каких условиях сталкивается с какой-то трудностью в работе и насколько сильно она его беспокоит. Это называется гипотеза о проблеме.

Например, вы предполагаете, что бизнесу сложно контролировать удалённых сотрудников, он несёт убытки, а проблему можно починить внедрением HRM системы. Разобраться поможет глубинное интервью. Надо определиться, с кем вы будете говорить, чтобы понять, действительно ли удалёнщики – это головная боль. Это менеджеры, HR, руководители подразделений. А затем узнать ответ на главный вопрос, готовы ли они чинить эту проблему.

📍Объём рынка. Можно обойтись исследованием статистики в интернете. Например, использовать данные Росстата, Tadviser, Вышки, на английском можно почитать PwC, Gartner, Deloitte. В своих проектах мы миксуем все эти источники.

📍Конкурентов и аналоги. На кого позиционируются, сколько стоят, какие задачи уже решают? Растут или не растут? Здесь нужно смотреть отдельно русский рынок и зарубежный. Первую группу на Rusprofile, СБИС, Rusbase. Для анализа зарубежных проектов подойдут Techcrunch и Crunchbase. Сайты, статьи о продуктах, интервью основателей тоже ок.

Собираем полученные данные в одном месте и делаем выводы. Реальна ли проблема, которую мы планируем решать, достаточен ли объём рынка, чтобы на нём много и долго зарабатывать, и получиться ли нам зайти в него. Ведь на рынке могут быть государственные ограничения, большая инертность покупателей или попросту такая стоимость привлечения клиента, которая никогда не окупится.

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

Что можно читать и смотреть:
1. Про анализ конкурентов https://www.youtube.com/watch?v=6nPRgTfYqJA
2. Про глубинные интервью “Роберт Фицпатрик “Спроси маму”
3. Про оценку объёма рынка https://scrumtrek.ru/blog/product-management/product-glossary/6005/tam-sam-som-model/

Исследования в продуктовой разработке

Тренд на производство собственных цифровых продуктов у крупных промышленных компаний только набирает обороты. Например, Family Manager от строительной компаний ПИК. Сервис помогает спроектировать строительство дома до мельчайших деталей: окна, дверные ручки и др. Поэтому делимся некоторыми особенностями продуктовой разработки.

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

Что нужно сделать, чтобы от идеи перейти к продукту, не закопав миллионы в разработку
📌Сформулировать и проверить гипотезу потребности. На этом этапе нужно ответить на вопросы: Какую проблему/задачу пользователя сервис будет решать? Как много таких людей/компаний на рынке?
📌Сформулировать и проверить гипотезу ценности для пользователя
📌Сформулировать гипотезу решения. Определить, как должен выглядеть будущий продукт, какие функции для него важнее всего, а какие можно отбросить

Что делать, когда продукт уже есть, но кажется, что нужны доработки
Здесь цикл исследований похожий, но в сжатом формате. Исследователь тестирует на рынке каждую доработку отдельно: какая аудитория у продукта с доработками, какие потребности пользователя закрываются в этом случае, какая ценность и чего ещё может не хватать, чтобы полностью доработать продукт

На сайте Rubius написали подробную статью по теме с примерами из нашей практики.
→ Приходите почитать

Коллеги, меня хорошо слышно… А теперь?

В этом году мы с головой ушли в машинное обучение и нейросети. Балансировали между восторгом и лёгким страхом перед искусственным интеллектом. А потом, всем миром гадали, как же наши технологии будут сочетаться с новой волной импортозамещения.

Но мы не просто выдержали этот год, мы его прокачали!

Так что давайте на миг отложим все эти "BIMы” и “CADы” в сторону. Пусть наступающий год будет годом не только новых идей, но и годом заслуженного отдыха. Пора зарядиться новой энергией, чтобы в следующем году мы смогли создать что-то ещё более дерзкое и впечатляющее.

От всей души желаю вам в новом году прорывных проектов и творческого вдохновения. Счастливого Нового Года, друзья!

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

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

Систему хорошо приняли и сотрудники, и контрагенты, поэтому бэклог новых требований только увеличивался. В общей сложности систему допиливали почти 1,5 года. Ровно до того момента, когда программист попросил у компании премию: он усердно трудился 1,5 года, больших нареканий к работе не было, а системой успешно каждый день пользуются десятки сотрудников.

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

Оказалось, что за все 1,5 года работы компания не получала исходные коды системы и администрированием рабочих серверов так же занимался фрилансер. Собственно доступ к серверам он и закрыл в надежде получить от компании премию. Работа компании, конечно, не была парализована, к хорошему быстро привыкаешь и на второй день простоя начался хаос. Люди привыкли делать свою работу удобно и быстро.

Быстро решить проблему не получилось – человек был настроен серьёзно. Своим преимуществом в этом конфликте он посчитал то, что уже полгода жил на берегу Андаманского моря и последствий своих действий не боялся.

Не вдаваясь в детали, скажу, что в целом история закончилась хорошо, насколько это возможно. И обращу ваше внимание, что необходимо контролировать риски работы с фрилансерами. В некоторых ситуациях даже наличие очень качественно составленного договора не защищает вас от возможных проблем. Да и вообще с физическими лицами и маленькими компаниями споры вести сложновато.

Так не бывает: инновации разработали, а производство внедрило 🙂

Самый болезненный/сложный этап в разработке инновационного проекта – это внедрение. Многие инновационные проекты в крупных компаниях терпят неудачу после перехода от отдела инноваций или исследований и разработок (R&D) к бизнес-юнитам.

Пример. Хорошая, большая, цифровизованная компания – просто пять звёзд. Отдел инноваций разрабатывает крутейшее передовое ПО для контроля качества монтажа коммуникаций на промышленных объектах. А потом наступает момент, когда надо это ПО передать в ответственный отдел условному ГИПу. И вот этот хороший в общем-то человек сидит и смотрит на новый приказ. И нет у него ни денег, ни ресурсов, ни понимания зачем, как, что. И начинается мелкий тихий саботаж. А у инноваторов и разработчиков начинается сыпаться KPI и картинка светлого будущего.

“Почему” тут несколько:
– недостаток коммуникации
– недостаточное вовлечение бизнес-юнитов
– недостаток ресурсов и недостаточная ответственность за успех проектов.

Что делать инноваторам, чтобы бизнес-юниты внедряли:
– ходить в партнерства и взаимодействия между отделами инноваций и бизнес-юнитами
– приглашать тех, кто вежливо не против на промежуточные демо проектов
– больше разговаривать с бизнес-юнитами, искать, где у них болит и за решение чего они бы сами поборолись
– создавать совместные карты внедрения
– искать в бизнес-юнитах тех, кому интересно

Что делать айтишникам, чтобы их ПО внедряли заказчики:
– участвовать во всём, что написал выше
– формулировать ценность и для платящего заказчика, и для конечного пользователя
– хорошо проверять, а ценность настоящая или мнимая
– обучать тех, кому интересно
– быть терпеливыми

Если знаете другие инструменты, рад обсудить!

В отличном подкасте наших партнёров PRO-ТИМ рассказал всё самое интересное из истории Rubius и нашего пути в разработке инженерного ПО. Кто мы и почему до сих пор не закрылись, знаковые продукты и проекты, что мы умеем в BIM и облаках точек, какие сегодня тренды видим и почему не боимся работать со стартапами в столь нестабильные времена. Ребята сделали очень удобную навигацию по видео – приятного просмотра. И большой респект команде за качественный продакшн
https://www.youtube.com/watch?v=Nwm95Jm8pJM