Из менеджера проектов в менеджера продукта: бывший сотрудник Lapka об особенностях и отличиях профессий Статьи редакции

Интервью с Вадимом Булгаковым о том, чему его научили работа с дизайнером Вадиком Мармеладовым и неудачный запуск собственного устройства для музыкантов.

Вадим Булгаков в креативной индустрии с 2005 года. За это время он успел поработать дизайнером, креативным и арт-директором.

В 2013 году он присоединился к стартапу Вадика Мармеладова Lapka, который разрабатывал датчики окружающей среды. Там Булгаков был менеджером проектов и работал над подготовкой про-версии приложения к релизу.

Сегодня он работает менеджером продукта в российском стартапе Baselance, который развивает сервис по работе с контактами фрилансеров.

Вадим Булгаков рассказал vc.ru:

• В чём особенность дизайна Вадика Мармеладова.
• Почему упрощение обесценивает не только дизайн, но и нашу жизнь.
• Как строилась работа в Lapka.
• Об особенностях работы менеджером продукта и менеджером проектов.
• Почему решил создать своё устройство для гитаристов Gature.
• После чего проект Gature потерял смысл.

Расскажи, как ты попал в Lapka?

В 2013 году у Вадика Мармеладова была собственная студия — Bowyer. Вместе с техническим директором Сергеем Филипповым в рамках этой студии они сделали приложение Road Inc (энциклопедия классических автомобилей — vc.ru) и ещё много разного.

Я увидел на hantim.ru (сейчас moikrug.ru — vc.ru), что Bowyer открывает офис в Санкт-Петербурге и в команду требуется проджект-менеджер. Я в то время как раз искал работу, поэтому сразу написал на почту и рассказал о себе.

Сергей Филиппов ответил, что готов пообщаться. Сначала мы встретились с ним в кофейне на Невском проспекте, поговорили о работе и дизайне в целом. А через пару дней он написал, что «всё ок», и принял в команду.

Как позже оказалось, в рамках студии Bowyer Вадик Мармеладов и Сергей Филиппов запускали новый проект Lapka, и проджект-менеджер им требовался именно туда.

Напомни, в чём суть Lapka?

Проект делился на:

• Lapka BAM (Breath Alcohol Monitor — vc.ru) — алкотестер.
• Lapka PEM — четыре устройства: счётчик Гейгера, датчик электромагнитного излучения, нитратомер, датчик влажности и температуры.
  

Чтобы просматривать результаты измерений, Lapka использовала два приложения: одно с облегчённым интерфейсом для обычных пользователей, а другое — с подробным результатом измерений для людей, разбирающихся в цифрах.

В чём отличие Lapka от других датчиков измерений на рынке?

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

Устройства выполняли основную функцию — дарили чувство заботы и удовлетворённость. Этого не мог предложить, например, обычный счётчик Гейгера размером с утюг.

Сделать красивое устройство — сложно, но не очень. А устройство, которое будет гармонично вписываться в жизнь человека и дарить положительные ощущения, — гораздо сложнее. Такой подход учитывает контекст. И дизайн Вадика Мармеладова — это сильно про контекст. Всегда.

Сейчас Вадик развивает LOT2046 (сервис доставки вещей по подписке — vc.ru). Как и Lapka, это не про объекты, а про «экспириенс». Это проект про то, как с помощью вещей выстроить ощущения и подарить заботу.

Например, обычно производитель зубных щёток замыкается на самом себе и делает дизайн для дизайна. А у Вадика всё сделано с мыслью: «А что человек почувствует, глядя на себя в зеркало?».

Зубная щётка в дизайне контекста LOT — не про вещь, а про момент, когда в ванной смотришь на себя в зеркало, находясь при этом в полном одиночестве (подробнее об этом Вадик Мармеладов рассказывал на своей лекции в «Яндексе» — vc.ru). В это время ничто не должно отвлекать или влиять на твоё настроение.

Хороший дизайн — это когда при его проектировании понимаешь и продумываешь весь путь человека до продукта: почему человек что-то захотел, как и когда пошёл «гуглить», в каком состоянии и настроении мог попасть на сайт, купить вещь и так далее.

В Lapka ты работал над приложением для профессионалов?

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

Приложение основывалось на «пресетах» для разного контекста: в самолёте высокая радиация — это нормально, а вот в комнате ребёнка — нет.

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

Например, про-версией приложения пользовался один мой знакомый реставратор — он замерял влажность воздуха.

Упрощение — это инструмент, но это не всегда полезно. Иногда нужно сделать что-то сложнее. Когда пользуешься устройством, от тебя требуется определённое действие. Про-версия давала ту сложность «экспириенса», которую человек ожидал увидеть после взаимодействия с Lapka.

Сама по себе парадигма упрощения — логичная, даже интуитивная. Но некоторые правильные решения бывают контринтуитивными. Более простые вещи убивают сложные, и все живут в парадигме, что упрощение — путь к успеху. Но чем сильнее упрощаешь, тем больше теряешь эмоциональную вовлечённость.

Например, в начале 2000-х годов был медленный интернет. И я ездил на другой конец города к товарищу, чтобы он записал мне на CD-болванку музыку, которую он доставал через своих знакомых. И такая музыка запоминается на всю жизнь. Сейчас на стриминговых сервисах выходит море новой музыки, и она может быть лучше старой, но ты её меньше ценишь.

Раньше, чтобы что-то получить, ты затрачивал усилия. Это было неудобно, но ты получал большее эмоциональное удовлетворение. На тему, как упрощение влияет на жизнь, есть хорошая статья в The New York Times.

Как строилась работа в команде?

У меня была позиция проджект-менеджера. Помимо работы над про-версией приложения, я помогал с запуском карты, которая была как на сайте, так и в обычной версии приложения. На ней транслировались все измерения в мире, которые производились с помощью датчиков Lapka.

В команде нас было всего трое — Вадик Мармеладов, Сергей Филиппов и я. В офисе мы сидели с Сергеем вдвоём, а Вадик в этот момент находился в Штатах, решал там вопросы компании. И у нас всё общение с ним происходило на созвонах.

Остальные люди работали тоже удалённо. Например, разработчик, который отвечал за внедрение карты в основное приложение, жил в Таиланде. Версию приложения для профессионалов делали разработчики из России.

А сайт делала команда из Санкт-Петербурга. Я держал со всеми связь и контролировал процесс работы. Дизайнеров, считай, не было — за всю красоту в Lapka отвечал Вадик Мармеладов. То, как всё выглядело и работало, — его заслуга.

С чего ты начал работу в Lapka, когда пришёл в команду?

В первую очередь мы занялись доработкой ТЗ и внедрением в проекте системы канбан (помогает улучшить производительность команды — vc.ru). В разработке софта это одна из самых важных штук. Первые две недели я изучал техническую документацию, а потом мы с Сергеем Филипповым покупали мебель в офис и решали бытовые вопросы.

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

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

Конечный вид интерфейса появился уже после создания прототипов приложения. Первая версия приложения, условно, состояла из чёрных, синих и красных квадратов на сером фоне. Она работала с одним из четырёх устройств — вроде с электромагнитным излучателем.

Мы проверяли, как выполняются функции датчика Lapka, и исходя из этого, представляли, как ими можно воспользоваться через приложение. Так мы работали над UХ-дизайном.

Как долго ты работал в Lapka?

Три месяца. Но это были интенсивные три месяца, которые дали мне опыт на пару лет вперёд — всё это время работал над подготовкой про-версии приложения к релизу. В Lapka были нерешённые задачи по администрированию, они искали проджект-менеджера и меня взяли в команду.

Но позже выяснилось, что в Lapka нужен человек с уклоном больше в биздев (Business Development — создание долгосрочной ценности для компании со стороны клиентов, рынков и отношений — vc.ru), чем в продакшн. Биздев — не моя сфера, и посовещавшись с командой, мы решили, что мне лучше уйти из проекта.

С какими сложностями ты успел столкнуться за время работы в проекте?

В основном вся сложность заключалась в разных часовых поясах. Вадик Мармеладов в США, производитель датчиков в Китае, разработчик приложения в Таиланде. Чаще всего было так, что встаёшь в шесть часов утра, созваниваешься с одним, потом со вторым, с третьим — и так до глубокой ночи.

Чем ты занимаешься в Baselance?

В Baselance (интервью с его создателем Антоном Теном — vc.ru) я менеджер продукта и занимаюсь его развитием: маркетингом, контролем всех этапов разработки, дизайном и другими вопросами в плане организации проекта.

В Lapka ты был менеджером проектов, а сейчас менеджер продукта — в чём разница?

Это вопрос зоны ответственности. Проджект-менеджер отвечает только за то, чтобы выполнялась работа над проектом — это человек, который организовывает рабочий процесс.

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

Ошибки команды — это факап проджект-менеджера. Именно он принимает решения в команде по организации рабочего процесса, поэтому всю ответственность берёт на себя.

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

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

Как стать продакт- или проджект-менеджером?

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

В профессию менеджера продукта можно уйти из менеджеров, программистов — в техлиды и СТО (технический директор — vc.ru) — и дизайнеров — в арт-директоры или дизайн-директоры. Это всегда разные пути, и всё зависит от того, знаешь ли ты, как развивать продукт в будущем, или нет.

С раннего детства я любил рисовать, и лет в десять стал этому учиться — читал специализированные книжки, занимался в художественной школе. Лет в 12 начал осваивать Photoshop, иногда удавалось достать книжки из других городов — чаще всего Москвы или Самары (там были филиалы московских магазинов).

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

Я считаю, что это лучший способ научиться программировать — так острее работает голова. Сейчас я знаю HTML, CSS, JavaScript, PHP, Python и немного Swift.

После школы поступил в РАНХиГС на специальность «Государственное и муниципальное управление». Там дали хорошую теорию по менеджменту. Нас обучали гибким методикам управления проектами — Agile и Kanban.

Или ТРИЗ — теория решения изобретательских задач (набор алгоритмов и методов для совершенствования творческого процесса в команде — vc.ru). Эти знания всегда помогали мне в работе.

Как ты находишь подход к людям в команде?

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

Ещё нужно хорошо знать, у кого какая мотивация, и ясно объяснять задачи. Например, программисты могут слишком «закапываться» в технологию, а дизайнеры, напротив — выполнять работу поверхностно, если недостаточно мотивированы.

Или задача «добавить кнопку» — для программиста простая работа, а дизайнер может корпеть над ней долгое время. И в этом случае важно изначально ставить чёткую задачу и сразу объяснять, для чего делается та или иная функция или часть приложения, сайта. Тогда люди для себя понимают, как им распределять нагрузку.

Как организовываешь работу в команде?

Для этого есть бэклог (журнал оставшейся работы — vc.ru), куда я выписываю все утверждённые задачи по проекту. Из этого списка выбираются сверхсрочные задачи на спринт, и начинается работа.

Количество задач соответствует ёмкости спринта — если у нас спринт на 160 рабочих часов, то там не может быть задач на 200 часов. В целом принято, что спринт составляет одну или две недели.

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

На рынке существуют устройства для музыкантов, которые позволяют подключить к телефону, например, гитару. А просто так это сделать нельзя из-за особенностей конструкций разъёмов Apple. Если у тебя на одном конце джек (на 6,3 мм — vc.ru), а на другом мини-джек (на 3,5 мм — vc.ru), то гитара работать не будет.

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

В моём устройстве, оно называлось Gature, я избавился от блока коннектора. Я удалил дублирующие элементы вроде регулировки громкости и распределил остальное железо по корпусам штекеров. Поэтому Gature было удобнее пользоваться

Что произошло с этим проектом?

Это был маленький личный проект, которым я занимался как хобби в свободное от работы время. Мне с ним помогали знакомые инженеры, и уже были напечатаны прототипы корпуса, ещё были железные прототипы. Шли переговоры с одной фабрикой из Китая по поводу тестовой партии — первых 500 штук.

И тут я узнаю, что Apple убирает трёхмиллиметровый мини-джек из iPhone, и я такой: «Здорово!». Это было неприятно, уже были какие-то договорённости по поводу производства и так далее.

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

А вообще, насколько сложно тебе было создать продукт? Расскажи, как это происходило.

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

У меня не было цели сделать массовый продукт. Мне хотелось в первую очередь сделать устройство для себя, потому что iRig был неудобным. Всё началось с того, что я сел и спаял устройство, чтобы подключить его к iPhone.

Денег в проект было вложено около нуля. К счастью, я не успел оплатить партию из Китая и потерял только время. А прототипы стоили копейки. Распечатать корпус на 3D-принтере и собрать железо обходилось в районе 100 рублей.

Меня мучает вопрос — как ты мог не предугадать, что Apple уберёт разъём для наушников? Об этом же все говорили.

Разговор о том, уберут или не уберут, ходил давно — информация была у Apple в патентах, но официальной реакции от компании не было. К счастью, об отсутствии разъёма для наушников я узнал ещё до официального анонса, когда от проверенных источников появилась информация, что мини-джек уберут 100%.

А старые телефоны? Они же с мини-джеком, почему не захотел делать устройство под них? А ещё есть Android.

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

А у Android всё плохо. У Apple есть понимание, какие характеристики нужны для каждой модели устройства, а у Android софт с железом не всегда «дружит». Когда ты делаешь устройство под мобильное приложение, нужно учитывать много всего.

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

Что посоветуешь тем, кто хочет создать свой стартап?

Та вещь, которой ты занимаешься, всё время должна тебя драйвить. Нельзя заниматься тем, что не откликается в тебе самом, и очень важно самому чувствовать ту боль, которую ты пытаешься устранить своим проектом.

#стартапы #lapka