Сегодня мы с Оппонентом обсудим актуальную тему. Импортозамещение объявлено всеобщей целью, многие фирмы провозгласили продуктовый подход.
Но реально продуктовых решений мало. Почему же ставят цель, но не идут к ней? Какие преимущества даёт продукт? Что мешает просто подойти и сорвать яблочко? И что делать, чтобы препятствия исчезли?
Как всегда, наша тема – 1С, других направлений касаться не будем.
Но сначала представлю Оппонента. Приходят вопросы к статьям - кто ты такой? ИИ? Специалист?
Оппонент:
Я - персонаж полностью вымышленный. Не ИИ, не реальный твой коллега, не знакомый. Все совпадения случайны.
Я - персонаж собирательный. Появился из возражений твоих коллег, интересных мысли от ИИ, контркейсов, сомнений, подслушанных где-то мнений – вот мои источники знаний.
А теперь давай сразу определим, что такое продукт. Платформа? 1С:Аналитика? Мобильные приложения?
Автор:
Да, всё это продукты. Но сегодня разговор не о них. Будем говорить о конфигурациях 1С - от известных (Управление строительной организацией) до небольших решений (Пример:Электронная очередь). Но будет условие: продукт должен быть коммерческим, продаваться. И полноценно функционировать. Такие разработки (Пример:Салон красоты (на 1С 8.2 управляемые формы)) продуктом не считаем – это шаблон, незавершёнка.
Чем хорош продукт для Исполнителя?
Для отраслевого решения - конкурентные преимущества при продаже в отрасли. Системы с требуемым готовым функционалом клиенты всегда будут закупать охотнее. Готовые решения дешевле разработки, а наличие таких решений подтверждает отраслевой опыт их вендора.
Вендора отраслевого решения охотно будут приглашать на субподряд по внедрению этого решения, а также в смежных областях.
Зарегистрированное решение будут продавать интеграторы, что также увеличит объём продаж.
Сам факт наличия решений повышает известность и привлекательность вендора как исполнителя проектов внедрения, даже не связанных с продуктом.
На разработку продукта можно привлекать разработчиков в моменты простоев. Также вполне допустимо использовать труд начинающих специалистов.
Не тратятся деньги на повторную разработку того же функционала у других клиентов.
Повышается компетенция сотрудников в предметной области.
Улучшаются технологии и подготовка к созданию следующих продуктов.
Чем хорош продукт для заказчика?
Владение продуктом – прибыль. Передача продукта Исполнителю – деньги.
Стандартизирует процессы – уходим от «как я захотел», к «как все делают».
Тоже повышает узнаваемость – как законодателя отрасли или предметной области.
И добавлю от себя: программисты 1С выполняют повторные разработки сотни и тысячи раз. Эти трудозатраты не компенсирует никакой искусственный интеллект (в первую очередь – в силу «секретности» всех этих практически одинаковых изделий). Решение проблем этих повторов приведёт к огромной экономии, и создание продуктов – один из шагов в этом направлении.
Оппонент:
Какой список хороший! Но если для заказчика его плюсы не всегда очевидны, то многие интеграторы свои плюсы называют и понимают, но вот продуктов почти не видно.
Автор:
Года до 2024 был огромный спрос на проекты. Все ресурсы туда уходили: и трудовые, и денежные. А когда спрос упал – денег не находится.
Оппонент:
Это если поверхностно смотреть. Давай поглубже глянем. Даже в период полной загрузки у интеграторов бывают простои. И когда спрос упал – у интеграторов деньги не кончились, а свободные сотрудники есть. Почему в это время не заняться продуктом?
Автор:
В каждой ситуации свои причины. Но навскидку такие мысли приходят:
Продукт требует вложений. Интеграторы привыкли получать за проект сразу. А за продукт так не получится. Если же продукт небольшой – то и доход от него меньше.
Нет уверенности, что продукт будет продаваться. Рисковать не хотят.
Прибыль от продажи экземпляра продукта не так уж и велика. Проект коммерчески интереснее.
Чтобы создать продукт на базе проекта – нужны усилия, специфическая разработка, затраты на регистрацию продукта, потом на продажи. И подготовка нужна – анализ востребованности, конкуренции. Это всё сложно. Хотят как проще.
Есть ещё одна причина. Заказчик требует права на все результаты проекта. Исполнитель смотрит на определение проекта: проект всегда уникален. Поэтому его результаты никому, кроме этого конкретного заказчика, не нужны. И условие идёт в договор. А в результате – перехитрили себя. Заказчик не получает права – поскольку права на 1С и типовую конфигурацию всё равно у 1С, а в доработках часто используется стандартный код, который есть и в типовых, и у других клиентов. А менеджеры исполнителя получают заветную причину не заморачиваться созданием продукта.
Оппонент:
Как же правильно поступить? Догадываюсь, заказчику права эти нужны только чтобы кто-то другой не предъявил прав на результаты проекта. Если исполнитель оформит эти результаты как продукт и будет продавать – заказчика это никак не волнует. Если, конечно, его данные не зашиты в программу (а такое случается). И если сам заказчик не захочет владеть продуктом (а такого я ни разу не встречал).
Автор:
И я тоже. Поэтому да – указать, что исполнитель гарантирует легитимность программы у заказчика. Никаких там авторских прав – всё равно их не будет, да и возможности их как-то отследить реально нет.
Оппонент:
Это ты так считаешь. А у меня клиент как раз судится. Нашёл одну из установленных ему обработок на Инфостарте, и претензию подрядчику, почему права на мою обработку, оказывается, у кого-то другого.
Автор:
Тогда это ещё один минус такого пункта в договоре.
Так как же подойти к созданию продукта, и где можно сэкономить?
На проекте внедрения стоит сразу запланировать создание продукта. Конечно же, предварительно оценить востребованность и конкуренцию. Затем можно сразу договориться, какой стороне договора (или обеим) будет принадлежать продукт, и как за него расплачиваться.
Исполнитель может и сам делать продукт, не привлекая заказчика. Если сразу применять нужную технологию, повышать уровень абстракции, то дополнительных затрат будет немного, а прибыль от продукта - ощутимой. Или заказчик может оплатить эти допрасходы и забрать продукт себе.
Оппонент:
Поподробнее про абстракцию!
Автор:
На каждом проекте видишь кнопки вроде "Отправить документ в ООО Ромашка". В продукте такого быть не должно. Либо "Отправить комиссионеру из топ-списка", либо выделить в отдельную подсистему и не включать в продукт. И это пусть небольшие, но расходы.
Если продукт создаётся не на базе проекта – тут, конечно, расходов больше.
Оппонент:
А я вот совсем таких продуктов не видел. Даже небольшой продукт изначально делается под покупателя.
Автор:
Спорить не буду.
Подведу итоги:
Продукт выгоден.
Лучше всего делать на основе проекта.
Продукт требует вложений и квалификации, особых подходов к разработке, маркетинговых и технических исследований и развития продаж. Перечень изменений для перехода к работе на продукт - тема для отдельной статьи.
Именно квалификация, а за ней - необходимость затрат - причины отказа от продуктового подхода.
Продукт потребует регистрации в 1С и/или создания дистрибутивов - дополнительные квалификация и затраты.
Лично я считаю продуктовый подход хорошей стратегией и призываю к разработке продукта. Если у вас есть идеи продукта – пишите, обсудим, поучаствую с удовольствием. Если есть желание поучаствовать - знакомимся, как появится идея и/или финансирование - сообщу, будем думать, как организовать разработку.
