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

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

Меня зовут Алексей Чернышов, я генеральный директор 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. Соблюдать ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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