Культура ввода продукта в эксплуатацию, пустая трата времени? Или все же нет?

Ниже мой опыт и грубые ошибки. Посыпаю голову пеплом.

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

Похоже на парадокс? Да нех! Быть такого не может! - скажет неискушенный читатель.

Однако, встречается такое очень часто. И рецепт очень простой:

Как следствие, отсутствует выстроенный бизнес процесс, а продукт “ни жив ни мертв”. Только разработчик, и/или его создатель понимает его “ценность”. При этом продукт может быть реально и пустышкой, но может быть и очень толковым инструментом, если им пользоваться.

Однако, реальность такова, что когда в компании нет культуры ввода продукта в эксплуатацию, то реальная ценность продукта или отсутствует вовсе или же его ценность минимальная.

В ITIL 4 мне очень нравится определение сервиса

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

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

Давайте внесу немного конкретики, и дам пример, чтобы на нем разобрать свои ошибки.

Пример продукта

ИИ система автоматического определения свойств светильников по фото.

Назначение продукта

Определение свойств светильников, которые можно определить по фотографии. например:

Зачем нужен продукт по задумке?

Поскольку я в прошлом занимался профессионально продвижением сайтов в Яндекс/Гугл, то знаю, насколько важно иметь такие свойства, т.к. люди в поиске задают запросы из серии “люстры с квадратным плафоном” или же “бра с плафоном вверх”.

Вот примеры из Wordstat Яндекс

http://joxi.ru/Q2K7OgzULKpQD2

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

Это приводит к росту трафика, и продаж, как следствие.

Затраты на создание продукта

Первоначальные затраты для компании не стоили ничего, т.к. меня просто заинтересовала тема и я в свободное время изучил построение таких ИИ моделей на базе библиотек Tensor flow, Keras.

Затем уже в рабочее время потратил 10 рабочих дней (полные две недели) на то, чтобы создать и обучить модели для определения свойств. Львиная доля времени ушла на то, чтобы подготовить чистые датасеты. Да, это самая утомительная часть при разработке систем с обучением.

Далее я показал результаты потенциальному заказчику, руководителю продаж Интернет-магазина и он оказался в полном восторге от результата и перспектив, и “благословил” на дальнейшие работы.

Забегая немного вперед, в этом кейсе я избежал ошибки “отсутствие заказчика”. Однако, совершил другую, не менее серьезную, которая привела к тому, что спустя полтора года оказалось, что продукт не используется. Я не ввел продукт должным образом в эксплуатацию.

Затем еще около полутора недель работа PHP разработчика и около 5 часов 1С разработчика по моим ТЗ. Нужно было создать панель управления, которой по задумке должны бы пользоваться контент менеджеры.

Система работает следующим образом:

1С по регламентному заданию проверяла, у каких товаров НЕТ обработанных свойств по тем моделям, которые мы обучили и добавили в систему (всего 8 моделей). Далее 1С отправляла эти данных в наш WEB сервис.

WEB сервис, в свою очередь, прогонял по моделям эти товары и проставлял свойства. Затем помечал, что они обработаны и подготавливал данные для модерации в удобном виде.

Модерация была обязательной, т.к. точность моделей колебалась для разных свойств от 87 до 98%.

За час можно отмодерировать около 10 тысяч товаров, что делает простановку свойств быстрой и удобной.

В месяц у нас каталог увеличивается примерно на 4000 товаров. И инструмент позволял обработать эти 8 свойств всего за 4-5 часов одним контент менеджером в год.

Без такой системы, проставлять эти свойства было бы просто нерентабельно, т.к. это куча времени.

Когда мы с программистом сделали и проверили, что он работает, мы показали продукт руководителю контент отдела и сказали, что если будут вопросы, то пусть обращается к нам.

Далее просто сообщил Заказчику, чем безусловно, его порадовал.

Что было дальше?

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

А потом, спустя полтора года я выяснил, что система висит себе, крутится в докер контейнере и даже мониторится на предмет падений… там копятся обработанные товары на модерацию. Но никто их с тех пор не модерировал.

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

Что нужно было сделать?

Проблема была в том, что эти свойства не являются обязательными к обработке. А установщик приоритетов контент группе, просто забыли о возможности получить с помощью сервиса халявный трафик. Да и не его это KPI.

Также тут присутствует мои личные “дефекты”. Я могу загореться идеей, не спать ночами и сделать MVP, а дальше рутину по внедрению делать уже не хочется… А там уже какие-то новые проекты и идеи маячат.

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

Какие еще варианты факапов могут быть из-за того, что нет культуры полноценной сдачи продукта в эксплуатацию?

Передача все одному ответственному лицу, который был заказчиком, пользователем

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

Тоже без документации… тоже без процедуры ввода.

А потом он уходит из компании. А новый приходит очень нескоро. И даже не понимает, как использовать этот продукт. И даже не знает о нет. И разработчики, которые изначально разрабатывали, не в курсе, что тот уже давно ушел…

У нас многие любят Аджайл, говоря, что по нему документация не нужна.

Согласно одному из пунктов манифеста.

Это, безусловно, верно. Только почему люди читают это как “Есть продукт, а документация не нужна”?

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

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

Ведь это единственный способ обеспечить безопасность бизнеса и снизить зависимость от конкретных разработчиков.

В последующих статьях расскажу, как именно мы осуществляем ввод в эксплуатацию.