О смертных грехах в развитии продукта. Взгляд со стороны бизнеса

22.01.24

Управление продуктом - Продуктовый подход

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

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

Меня зовут Алексей Чернышов, я генеральный директор 1С-Коннект. Мой доклад будет полезен владельцам продуктов, продуктологам, продукт-менеджерам, бизнес-аналитикам и другим сотрудникам, которые занимаются продуктовой частью проектов внутри компании.

Я надеюсь, что, прослушав наш опыт (я здесь буду говорить только про опыт нашей команды) в вашей «нейросети» отложится 1-2 нейрона, которые помогут в развитии ваших бизнесов.

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

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

 

 

Небольшая справка про меня. В нашей команде я отвечаю за все, что делает компания, и одна из моих ролей – это владение продуктами, я – владелец продукта.

С 2011 года мы занимаемся развитием и распространением «1С-Коннект», у него было ещё прежнее название «Бухфон». Продукт достаточно зрелый – ему больше 10 лет. До этого я занимался продажами и сервисным обслуживанием других программных решений.

 

1С-Коннект

 

 

Короткая справка по «1С-Коннект».

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

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

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

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

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

Спустя много лет эта история превратилась в целую инфраструктуру, в которой:

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

  • А на стороне клиента – это по-прежнему простое «единое окно» для входа и решения самых разных вопросов.

В докладе попробую коротко рассказать, как мы к этому пришли, и какие ошибки совершали на этом пути.

 

 

На текущий момент ландшафт продукта представлен рядом интерфейсов:

  • Есть кроссплатформенное приложение для персонального компьютера, поддерживающее Linux, Mac OS, Windows и основные отечественные операционные системы. Аудитория, которая ежедневно пользуется этим решением – больше 200 000 пользователей.

  • Есть мобильное приложение, которое поддерживает почти тот же периметр функций, но им уже пользуется 10 000 пользователей ежедневно.

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

  • И специальное средство для онлайн-мониторинга всего происходящего – этим пользуются 500 человек ежедневно.

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

 

 

Если посмотреть на продукт глазами разработчика, глазами технического архитектора, то облачная инфраструктура продукта 1С-Коннект включает в себя большое количество слоев и имеет широкий технологических стек.

 

 

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

 

 

Основные инструменты, которые мы используем, я привел на слайде:

  • Всю информацию по процессу разработки мы отражаем в Jira/Confluence: в Confluence – документирование, в Jira – бэклог. К этой системе подключены все наши технические службы – служба техподдержки, разработчики, продуктологи. Все знания, связанные с развитием продукта, аккумулируются там.

  • Макеты мы делаем в Figma. Figma тоже хорошо интегрирована с Jira;

  • Все коммуникации мы проводим внутри 1С-Коннект;

  • Для удобства визуализации наших производственных планов мы используем GantPRO.

 

Роль продукт-менеджера в 1С-Коннект

 

 

Что делают наши продуктовые менеджеры каждый день? В чем их основные фокусы внимания и работы?

  • Вокруг продукта в компании возникает так называемое «поле сил». Менеджеры по продвижению, разработчики, руководство, служба эксплуатации – все что-то хотят от продукта, всем в нём что-то не нравится, каждый «тянет одеяло на себя», образуя вокруг продукта некое «поле сил». Задача продукт-менеджера – собрать со всех информацию и сбалансировать это «поле сил». У каждого из агентов влияния есть свои белые пятна, своя зашоренность, и задача продуктолога эту зашоренность нейтрализовывать, а белые пятна устранять.

    • Верхнеуровнево руководящий состав и топ-менеджмент вырабатывают решение о развитии продукта методом «водопада» – мы собираем большое количество информации по рынку, выбираем рыночное направление и идём дальше «водопадом».

    • А на уровне команд практически везде применяются методики Agile – везде идут двухнедельные спринты. Продуктологи погружены в эту активность и занимаются этим каждый день – по продукту собирается большое количество данных, а старый-добрый Excel эти данные агрегирует. Мы анализируем много данных и, опираясь на эти данные, вырабатываем решения по производству и развитию продукта.

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

  • Для проработки пожеланий продукт-менеджеры каждую неделю проводят с каждой командой встречи по синхронизации – мы их называем синки. Эти синки идут постоянно, их задача – выработать единообразное представление о том, что мы делаем. Практика показывает, что у разных людей абсолютно разные представления о том, что написано. Написали «Хотим это», все прочитали и каждый понял по-разному. Задача синков – это проговорить и найти единое понимание того, что нужно сделать, какой результат мы хотим ожидать на следующем шаге.

  • Также продуктологи занимаются приемкой работ и организацией выпуска – бета-тестированием, документированием и передачей продукта в эксплуатацию.

 

Принцип №1. Соблюдать ограничения

 

Первый принцип, который мы выработали для себя, дался нам с большой болью.

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

 

 

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

Скорость роста сложности системы квадратична от количества внесённых в неё вводных. Если у вас 3 точки – это 3 связи, если у вас 4 точки – это уже 6 связей между собой и так далее по квадрату.

Чем это опасно, и какие последствия, если за этим не следить?

Если у вас внутри системы появляется очень много параметров (очень много фич), изменение любого из параметров будет затрагивать все связанные с ним возможности. А это осложняет, утяжеляет и удорожает эксплуатацию, развитие и изменение системы в будущем.

N2 есть везде, практически во всех сложных системах. Не только в разработке. Если вы делаете продукт с большим количеством фичей, эти фичи нужно документировать, их нужно раскатывать по sales kit-ам, там их нужно транслировать аудитории, аудиторию надо онбордить, вводить в ваш продукт, они будут его осваивать – это тоже затраты энергии. Везде есть этот N2.

 

 

Если вы занимаетесь фичеводством, N2 найдёт вас всегда. Неподконтрольное набрасывание фич на продукт – это болезнь, которая оборачивается серьезными последствиями.

Но если мы рассматриваем количество фичей как ограничивающий фактор, это вызывает холивары (противоречия):

  • Первый холивар – фундаментальный: а давайте заниматься только одной фичей и оттачивать ее всю жизнь. Это у нас будет киллер-фича – она будет убивать. Она будет лучшая в истории – с помощью неё наш продукт захватит рынок. Выглядит фундаментально, сам Брюс Ли это пропагандировал, и мы знаем много людей, которые в это верят – это очень классный подход.

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

  • В связи с этим возникает другой холивар: а давайте добавим в продукт максимальное количество фичей и победим весь рынок. Тоже опасный ход. Потому что придет N2 и завалит наш проект расходами, которые мы можем не вывезти. Задача продуктолога – постоянно это балансировать, переваривать, что-то с этим делать.

  • Мы для себя в команде выработали такой подход. Нам надо максимум три какие-то штуки. Если мы вводим фичу, у нее должно быть не больше трёх параметров, трёх уровней гибкости. Это оптимально, чтобы начать этим заниматься и тащить это дальше. Если в процессе анализа и обсуждений-синков оказывается, что трех недостаточно – хорошо, мы согласны на четыре. Но если больше четырёх – начинается реальная боль по введению, обслуживанию, эксплуатации, трансляции каждой новой фичи.

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

Я сейчас фокусируюсь на нашем практическом опыте – в чем мы нашли для себя оптимальный баланс.

 

 

Следующий ограничивающий фактор – это время. Дело в том, что производство продукта, его документирование, отладка – всё это требует времени, и это время откуда-то надо брать.

  • Наш бизнес – сезонный: у нас есть весенний и осенний бизнес-сезоны, когда люди активны, и есть летний сезон, когда спящий режим. И еще в партнёрской сети 1С есть партнёрский семинар, к которому полезно выдать большое количество парадных новостей. Как в советское время: выпуск чего-то к празднику – у нас тоже это присутствует.

  • Мы планируем нашу производственную деятельность на 3, 6, 12 месяцев вперед и стараемся утрамбовывать выход релизов горизонтами – в зависимости от того, есть ли какое-то важное событие или бизнес-сезон, к которому нужно подготовить фичу.

  • Мы стараемся рассчитать количество времени, которое нужно будет потратить на все этапы производственного цикла. Это время нужно откуда-то брать, нужно обязательно позаботиться о том, чтобы его хватило и было достаточно. Если на какие-то важные процессы времени вдруг не хватит, это может привести к тому, что будет грустно – мы что-то не успеем и промахнёмся в ожиданиях.

 

 

Третий ограничивающий фактор – это количество информации, которая ходит внутри компании.

Дело в том, что продукт-менеджер занимается, в том числе, подготовкой технических описаний, документированием, и ему важно понимать, для кого он пишет материал.

Мы в своей практике сталкивались с такой проблемой, что продукт-менеджеры старались описать ту или иную фичу как можно подробнее. Получались огромные лонгриды, талмуды с описанием, которые приходилось читать каждому сотруднику в команде.

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

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

  • сейлз-менеджерам нужно отдавать шортриды,

  • а разработчики любят, когда обо всём написано со всеми подробностями.

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

 

 

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

  • Размер рынка. Если вы работаете на маленьком рынке, даже если у вас супер-классный продукт, он может просто по физическим причинам себя не окупить – может не найтись столько пользователей. И наоборот, если вы выходите на большой рынок, даже если у вас продукт слабенький или слабенькая команда, на нём может случиться эффект взрыва. Я начал с того, что мы свою плохо работающую программу вывели на большой рынок, и это получилось. Если бы рынок был маленький, мы бы, скорее всего, загнулись.

  • Наличие конкурентов. Если рынок конкурентный, и поляна истоптана, привлечение нового клиента, как правило, обойдется в три раза дороже, чем удержание рынка. Это тоже влияет на экономику процессов – за этим нужно следить, в том числе продуктологу.

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

 

Принцип №2. Верить цифрам, а не словам

 

Второй принцип, наверное, банальный: верить цифрам, а не словам.

 

 

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

Люди склонны преувеличивать, фантазировать, заблуждаться – это приводит к искажениям.

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

 

 

По этому поводу я хочу порекомендовать вам книгу «Спроси маму» Роба Фитцпатрика. Там хорошо объясняется, почему люди склонны к такому поведению, и что с этим делать – как продуктологу правильно снимать с рынка истинные запросы, выявлять истинные сценарии.

При проведении CustDev важно соблюдать правило – маленький рот, большие уши и правильные вопросы.

Методика CustDev позволит собрать с рынка истинные сценарии применения – куда люди тратят свои ресурсы, за которые продукт будет биться.

 

Принцип №3. Сначала продать

 

Как я уже сказал, N2 нас всех победит, вы, наверное, запомните не больше трёх, поэтому третий принцип – последний: сначала продать, а делать можно потом.

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

 

 

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

Основная задача MVP – не только увидеть этот продукт вживую, но и спроектировать воронку дальнейших продаж (воронку привлечения нового клиента и стоимость этого привлечения).

Редко удается сразу попасть в покупателя. Когда мы делаем MVP, то допускаем какие-то ограничения и послабления – сразу не ждём эффекта. Потому что бывает такое, что сделали, силы потратили, принесли – не понравилось. И все начинают грустить: ничего никому не надо, руки опускаются и т.д.

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

И после выпуска MVP мы стараемся собрать как можно больше статистики, чтобы понять, в какую сторону вносить изменения.

 

Другие опасности на пути продукт-менеджера

 

 

Другие опасности, которые могут быть в работе продукт-менеджера.

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

  • Вторая опасность, которая здесь тоже может присутствовать – это эйфория от успеха. Если в процессе реализации вы получили проверку вашей гипотезы, MVP сработал, пользователи довольны и счастливы – это вообще не повод, чтобы расслабляться или радоваться. Обычно в таких случаях мы открываем бутылку шампанского, нюхаем её, закрываем и ставим обратно, потому что предстоит огромное количество работы для того, чтобы дожать MVP до настоящего, уже коммерческого состояния, чтобы вернуть инвестиции.
    Если у вас много фич и все получается, то скорее всего тоже есть еще белое пятно – технический долг. Скорее всего, пока ваши разработчики делали продукт, реализовывали ваши замыслы, ограничивали себя во времени и что-то не досматривали, то, скорее всего, накопился технический долг. Есть большая рекомендация: за ним тоже следить и стараться, чтобы он был в ограниченном виде.
    Есть полезная книга, называется «Как гибнут великие компании» Джима Коллинза, её тоже рекомендую почитать. Это большой обзор о том, как компании с топовых мест проваливались в небытие и умирали.

  • И вот совсем недавно узнал, что фраза memento mori из фильма «Кавказская пленница», оказывается, переводится не как «моментально в море». Эта фраза переводится как «помни о смерти». Не бывает вечных бизнесов, не бывает вечных продуктов. Я исхожу из этого. И работой продуктолога, неправильными действиями, ошибками, можно очень быстро убить свой продукт. А если стараться не совершать ошибок или как-то их минимизировать, можно обеспечить для своего продукта более длинную жизнь и, возможно, вечную весну на каждом очередном этапе.

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Продуктовый подход Программист Россия Бесплатно (free)

Статья является попыткой доступно объяснить принцип открытости/закрытости (Open-Closed) из SOLID в контексте разработки ПП на платформе 1С:Предприятие.

14.05.2024    858    0    EvgeniyOlxovskiy    7    

3

Продуктовый подход Бесплатно (free)

При запуске нового продукта нужно проверить идею на прочность, оценить ваши возможности и определить позиционирование среди целевой аудитории. Расскажем о том, какие инструменты могут в этом помочь.

09.02.2024    1240    0    comol    0    

10

Продуктовый подход Бесплатно (free)

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

17.11.2023    1028    0    user1949771    0    

7

Продуктовый подход Бесплатно (free)

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

20.09.2023    1570    0    user1949771    0    

4

Продуктовый подход Бесплатно (free)

В одиннадцатом выпуске подкаста Радио “Аналитик” обсудили, как найти актуальную проблему для создания продукта, как проверить идею продукта на востребованность и как сделать продукт привлекательным для потенциальной аудитории.

06.02.2023    627    0    Radio_Analyst    0    

3

Продуктовый подход Бизнес-аналитик Руководитель проекта Бесплатно (free)

Один из подходов, который помогает найти с бизнес-заказчиком общий язык и организовать сотрудничество – это использование принципа бережливой разработки (Lean Development). На митапе «Сбор требований и составление ТЗ» директор по проектам Инфостарта Мария Темчина рассказала, как с помощью этого принципа наладить взаимодействие с заказчиком, и показала практические инструменты, которые удобно применять при сборе требований.

26.05.2022    3863    0    MariaTemchina    0    

11

Продуктовый подход Программист Бесплатно (free)

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

05.10.2020    5335    0    primat    2    

26

Продуктовый подход Руководитель проекта Бесплатно (free)

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

24.07.2020    8280    0    iseleverstov    0    

17
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Tarlich 116 22.01.24 21:00 Сейчас в теме
эйфория от успеха, технический долг - здесь бы развернуть тему ... -)
3. t278 57 23.01.24 04:55 Сейчас в теме
(1) доклады на эти темы набирают мало голосов и не попадают на конференцию
2. muskul 23.01.24 02:46 Сейчас в теме
Вместо подобных статей лучше бы коннект в порядок привели. почему просто открытие диспетчера задач даже случайно, все стопорит и ничего нельзя закрыть или отменить
4. partizand 134 23.01.24 08:57 Сейчас в теме
Делаете ради зарплаты и реализовываете фичи к праздникам. И все вокруг врут с обратной связью. Я например навру, что интерфейс ужасен.
Не удивительно, что вы не любите свою работу. И результат соответствующий получается.
Статьи только про это не нужно писать, это вас не красит.
Думаю Коннект уже бы исчез в своем текущем виде, если бы не был связан с 1С.
7. user1075439 8 17.02.24 15:40 Сейчас в теме
Вам к сведению: потери партнерской сети 1С по направлению регулярного сопровождения за последние 6-7 лет снизились с 25% до 9% в год (в деньгах это 200-300 млн. в год) благодаря выстраиванию сервисных процессов и применению правильных технических инструментов, в т.ч. 1С-Коннект, который мы развиваем с большой заботой и любовью. В остальном - вы меня с кем-то путаете :)
5. support 4451 23.01.24 09:43 Сейчас в теме
Отличный доклад! Как владелец продукта владельца продукта понимаю, все боли знакомы.
6. user-z99999 70 24.01.24 16:37 Сейчас в теме
1С Коннект умирает или нет?
Система взаимодействия его убивает или есть своя ниша?
8. user1075439 8 17.02.24 15:44 Сейчас в теме
В 2023г. прирос на 50 тыс. пользователей, до 833 тыс. Не нужно никого убивать, "пусть расцветают сто цветов!" (с)
Оставьте свое сообщение