Ниже мой опыт и грубые ошибки. Посыпаю голову пеплом.
Во многих компаниях, где я работал в штате, на подряде или делал аудиты, встречаются сложные бесхозные IT продукты и инструменты. Которые, тем не менее, требуют значительных ресурсов на свое содержание и поддержку.
Похоже на парадокс? Да нех! Быть такого не может! — скажет неискушенный читатель.
Однако, встречается такое очень часто. И рецепт очень простой:
- 1 шт — инициативный сотрудник НЕ заказчик;
- 1 шт — заказчик, который не понимает, зачем ему это, или не хочет вникать
- 1 шт — руководство, которому инициатива и продукт в целом понравилась
- 0 шт — документация на инструмент или продукт
- 0 шт — ответственное лицо за эксплуатацию
Как следствие, отсутствует выстроенный бизнес процесс, а продукт “ни жив ни мертв”. Только разработчик, и/или его создатель понимает его “ценность”. При этом продукт может быть реально и пустышкой, но может быть и очень толковым инструментом, если им пользоваться.
Однако, реальность такова, что когда в компании нет культуры ввода продукта в эксплуатацию, то реальная ценность продукта или отсутствует вовсе или же его ценность минимальная.
В ITIL 4 мне очень нравится определение сервиса
Сервис – Средство, способствующее совместному созданию ценности за счет содействия достижению результатов, которых хотят достичь клиенты, без необходимости управлять конкретными затратами и рисками
Слово “совместный” я выделил не просто так. Дело в том, что если со стороны Продаж у вас не будет заинтересованного Заказчика, который будет активно участвовать в создании продукта с командой разработки, то дело швах.
Последние несколько дней я провожу аудит IT систем, которые я внедрил за последние годы. И обнаружил несколько таких систем, которые были разработаны давно, но по некоторым причинам, не используются совсем, либо же используются совсем не так, как предполагалось.
Давайте внесу немного конкретики, и дам пример, чтобы на нем разобрать свои ошибки.
Пример продукта
ИИ система автоматического определения свойств светильников по фото.
Назначение продукта
Определение свойств светильников, которые можно определить по фотографии. например:
- какой формы плафон?
- в какую сторону направлены рожки?
- какой стиль светильника?
- длинный или короткий?
- есть ли хрусталь?
- предполагается использование лампочки типа “свечка”?
- один большой плафон или много разных?
- подвесной или нет?
- и т.п.
Зачем нужен продукт по задумке?
Поскольку я в прошлом занимался профессионально продвижением сайтов в Яндекс/Гугл, то знаю, насколько важно иметь такие свойства, т.к. люди в поиске задают запросы из серии “люстры с квадратным плафоном” или же “бра с плафоном вверх”.
Вот примеры из Wordstat Яндекс
Речь идет об интернет магазине с сотней тысяч товаров и SEO продвижение является очень важным источником трафика. Если такие свойства обработаны, то есть возможность создать специальную страницу для людей, которые искали такие вещи в поиске. Тогда можно вести их сразу на релевантную страницу с нужными товарами.
Это приводит к росту трафика, и продаж, как следствие.
Затраты на создание продукта
- 60 часов на подготовку датасетов;
- 25 часов на разработку моделей (около 100-150 еще на изучение в “свободное время”);
- 90 часов на разработку информационной системы с панелью управления;
Первоначальные затраты для компании не стоили ничего, т.к. меня просто заинтересовала тема и я в свободное время изучил построение таких ИИ моделей на базе библиотек Tensor flow, Keras.
Затем уже в рабочее время потратил 10 рабочих дней (полные две недели) на то, чтобы создать и обучить модели для определения свойств. Львиная доля времени ушла на то, чтобы подготовить чистые датасеты. Да, это самая утомительная часть при разработке систем с обучением.
Далее я показал результаты потенциальному заказчику, руководителю продаж Интернет-магазина и он оказался в полном восторге от результата и перспектив, и “благословил” на дальнейшие работы.
Забегая немного вперед, в этом кейсе я избежал ошибки “отсутствие заказчика”. Однако, совершил другую, не менее серьезную, которая привела к тому, что спустя полтора года оказалось, что продукт не используется. Я не ввел продукт должным образом в эксплуатацию.
Затем еще около полутора недель работа PHP разработчика и около 5 часов 1С разработчика по моим ТЗ. Нужно было создать панель управления, которой по задумке должны бы пользоваться контент менеджеры.
Система работает следующим образом:
1С по регламентному заданию проверяла, у каких товаров НЕТ обработанных свойств по тем моделям, которые мы обучили и добавили в систему (всего 8 моделей). Далее 1С отправляла эти данных в наш WEB сервис.
WEB сервис, в свою очередь, прогонял по моделям эти товары и проставлял свойства. Затем помечал, что они обработаны и подготавливал данные для модерации в удобном виде.
Модерация была обязательной, т.к. точность моделей колебалась для разных свойств от 87 до 98%.
За час можно отмодерировать около 10 тысяч товаров, что делает простановку свойств быстрой и удобной.
В месяц у нас каталог увеличивается примерно на 4000 товаров. И их инструмент позволял обработать эти 8 свойств всего за 4-5 часов одним контент менеджерером в год.
Без такой системы, проставлять эти свойства было бы просто нерентабельно, т.к. это куча времени.
Когда мы с программистом сделали и проверили, что он работает, мы показали продукт руководителю контент отдела и сказали, что если будут вопросы, то пусть обращается к нам.
Далее просто сообщил Заказчику, чем безусловно, его порадовал.
Что было дальше?
В первые несколько дней у того, кто по идее должен был использовать систему, не нашлось времени. Потом его загрузили срочными и емкими задачами. А потом он и полностью забыл о ней. И мы забыли.
А потом, спустя полтора года я выяснил, что система висит себе, крутится в докер контейнере и даже мониторится на предмет падений… там копятся обработанные товары на модерацию. Но никто их с тех пор не модерировал.
Получается, все было зря. Я бросил проект на полпути, не убедившись, что он полетит дальше без меня.
Что нужно было сделать?
- Привлечь Заказчика на приемку;
- Добиться от Заказчика официального Назначения ответственного лица за Эксплуатацию;
- Помочь внедрить БП с участием контент отдела для запуска работ по обработке этих свойств;
- Написать полноценную инструкцию по эксплуатации сервиса и разместить в базе знаний;
- Поставить поддержку сервиса в каталог услуг;
- Передать контроль на отслеживание использования заинтересованным лицам (кто отвечает за результаты SEO в компании);
Проблема была в том, что эти свойства не являются обязательными к обработке. А установщик приоритетов контент группе, просто забыли о возможности получить с помощью сервиса халявный трафик. Да и не его это KPI.
Также тут присутствует мои личные “дефекты”. Я могу загореться идеей, не спать ночами и сделать MVP, а дальше рутину по внедрению делать уже не хочется… А там уже какие-то новые проекты и идеи маячат.
Из-за этого дефекта я не один потенциально полезный проект слил на этапе передачи в эксплуатацию. Я сделал, я красавчеГ, я молодец…берите и юзайте, а я пошел дальше творить. В моем случае, хороший выход, это иметь кого-то с сильной административной функцией, который может подхватить проект и переместить его на следующую стадию жизненного цикла.
Какие еще варианты факапов могут быть из-за того, что нет культуры полноценной сдачи продукта в эксплуатацию?
Передача все одному ответственному лицу, который был заказчиком, пользователем
Тоже, без документации. Заказчик участвовал в создании продукта. Реализовывались все его хотелки, совместно принимались решения и даже использовались костыли.
Тоже без документации… тоже без процедуры ввода.
А потом он уходит из компании. А новый приходит очень нескоро. И даже не понимает, как использовать этот продукт. И даже не знает о нет. И разработчики, которые изначально разрабатывали, не в курсе, что тот уже давно ушел…
У нас многие любят Аджайл, говоря, что по нему документация не нужна.
Согласно одному из пунктов манифеста.
Работающий продукт важнее исчерпывающей документации.
Это, безусловно, верно. Только почему люди читают это как “Есть продукт, а документация не нужна”?
Последние два года я нахожусь в компании, которая очень быстро выросла в штате и в направлениях работы. IT подразделение развернуло и разработало кучу сервисов, многие из которых уникальны.
И если поначалу нормально было помнить обо всем и гнать «быстрее-быстрее», при этом хорошо помнить об особенностях разных инструментов, то с увеличением количества сайтов и вспомогательных сервисов, нужно вводить бюрократию.
Ведь это единственный способ обеспечить безопасность бизнеса и снизить зависимость от конкретных разработчиков.
В последующих статьях расскажу, как именно мы осуществляем ввод в эксплуатацию.