Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 10:59
Apps4all

Антон Виноградов (Protein): «Наши первые клиенты – дизайнеры и разработчики, у которых наболело»

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

559c33263ccdb4.49769572.jpg

Антон, чем ты занимался до «Протеина», какие были практики?

Когда-то давно, около 5 лет назад, я был разработчиком CRM в одной крупной компании в Москве. Это было еще в институте. Как и все, я хотел чтобы моими трудами пользовалось как можно больше людей, а не одна компания. Тогда был пик популярности iPhone, и я решил попробовать в свободное время заняться разработкой мобильных приложений. Мы запустили несколько приложений и даже немного заработали, но что-то было не то. Следующей сферой, которая могла дать мне массовость, стал веб. Я не умел ничего, и некоторое время учился на фрилансе, разрабатывая сайты на заказ. Спустя полгода, я пошел full-stack разработчиком в проект на Ruby on Rails. Так сложилось, что в команде я стал заниматься визуальной частью сервиса больше, чем всем остальным и мне это безумно нравилось. Через некоторое время я ушел в разработку интерфейсов с головой. И невероятно рад этому. Первой компанией, где я занимался исключительно фронтендом стал печально известный Мастер-Банк. Там я занимался переработкой интернет-банка и сопутствующих сервисов. После его закрытия я перешел в Альфа-Банк, где и работаю разработчиком интерфейсов по сей день в его инновационном подразделении – Альфа-Лаборатории. Здесь я занимаюсь разработкой общепортального фреймворка, внедрением новых методик и подрабатываю тех-лидом нескольких сервисов.

Что тебя напрягало при параллельной разработке интерфейсов и дизайна?

Сколько я работаю в разных командах, всегда процесс такой. Дизайнер создает макеты и интерфейсные киты, порой очень красивые, а разработчики превращают их в код и библиотеки, которые используют для разработки сервисов. Вся печаль в том, что когда сервис начинает развиваться, а это происходит уже в момент первой итерации разработки, то компоненты интерфейса начинают меняться в трех местах: в макетах новых версий дизайна, на текущем сервисе, благодаря правкам, и в библиотеках разработчиков. Со временем выходят новые и новые версии дизайна, за ними не успевают разработчики, у них самих уже черт знает какая версия в разработке, а на сервисе стоит совсем древняя. Добиваться совпадения всего этого приходится менеджеру, который ходит от одних к другим и на глазок сравнивает. Как правило, он ничего не понимает в дизайне и разработке. За что его трудно винить. Это боль всей команды номер один. Невероятное дублирование работы! Просто жуть. Боль номер два – абсолютное непонимание предметной области друг друга. Разработчики и дизайнеры говорят на разных языках и в разных терминах. Когда разработка в самом разгаре это сильно замедляет команду. Боль номер три – исключительно визуальное наследование компонентов интерфейса. Это значит, что на самом деле никакого наследования нет, компоненты просто похожи друг на друга. Никто и впрямь не думает, что компоненты можно базировать друг на друге. Как в дизайне так и в разработке. Именно поэтому возникает «та самая» лютая ненависть между дизайнерами и разработчиками. Это превращается в ежедневный кошмар! Удовольствия от такой работы мало.

Это и привело к идее создать сервис, упрощающий взаимодействие между разработчиками и дизайнерами?

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

В чем состоит задумка этого самого упрощения?

В основе хороших продуктов всегда лежит очень простая идея. С Protein всё именно так. Мы решили, что вся команда, а не только дизайнеры или разработчики, должны использовать одну библиотеку компонентов интерфейса в своей ежедневной работе. Оказалось, что все тайно только этого и хотели. Это снимает все проблемы. Но печаль в том, что все кто пытался хоть как-то идти в эту сторону, шли со стороны дизайна. Потому сегодня мы все прекрасно знаем, что экспортирование кода из дизайн-инструментов невозможно. Это игрушки на пару часов и не более того. Мы перевернули разработку продукта с ног на голову и решили, что компонент сначала должен создаваться разработчиком, а потом использоваться в дизайн-инструментах. Звучит более чем странно, я знаю, но это только на первый взгляд. Подумайте, ведь разработчики проектируют структуру компонента так, чтобы его можно было поддерживать долгие годы, выбирают технологии и инструменты, которые будут актуальны и надежны, обеспечивают наследование и многое другое. Всё то, что не лежит на поверхности. Это тот самый фундамент, который просто необходим для «правильного» визуального дизайна. Со временем идея прогрессировала и выросла в простой и понятный сервис. Protein синхронизирует изменения в компонентах интерфейса, которые приходят от дизайнеров и разработчиков. Дизайнер изменяет компонент в своем редакторе, например в Sketch. Затем сохраняет его, а изменения поступают в библиотеку уже в виде кода. То же самое и в обратную сторону. Разработчик меняет компонент в своем любимом IDE, сохраняет, а изменения поступают в библиотеку компонентов. Прямиком дизайнеру в Sketch. Это как Dropbox для компонентов интерфейса. Абсолютно естественный процесс.

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

Сколько человек сейчас в команде? Как собирался коллектив?
Сейчас в команде 5 человек. Все они имеют опыт работы в таких компаниях как Яндекс, Мегафон, Мануфактура и Альфа-Банк. Лучшие из тех, кого я знаю. Вы и без меня прекрасно знаете, что нельзя просто взять и собрать команду. Чтобы найти подходящих людей, на которых можно положиться, могут потребоваться годы. Так произошло и с нами. Мы долгое время работали в разных компаниях и даже городах. Так есть и по сей день, но теперь все мы в Москве. Нас объединял общий дух опенсорс сообщества. Это невероятно круто! Можно сказать, это изменило всю мою жизнь и отношение к программным продуктам в принципе. Мы работали над одними инструментами в опенсорс и понимали друг друга очень хорошо. Мы постоянно виделись на разных конференциях и болтали о чудесном будущем. Спустя пару лет появилась идея сервиса Protein, и я предложил ребятам поучаствовать. И знаете что? Они согласились!

Вы уже создали прототип сервиса? На какой сейчас стадии?
Да, безусловно. Мы решили, что будем продолжать заниматься опенсорсом еще больше и создаем очень много инструментов, стараясь всё это выкладывать в организацию Protein на GitHub. Очень рекомендую заглянуть всем желающим. Сейчас мы занимаемся организацией правильной работы облака и разрешением коллизий при обновлении компонентов. Первый бета запуск мы планируем на осень текущего года. Доступ к тестированию получат все подписчики и несколько крупных компаний Москвы. Стать одним из первых можно прямо со страницы проекта.

Вероятно, для удовлетворения всем требованиям пользователей, сервис должен быть глубоко интегрирован с другими инструментами. Что в этом плане уже доступно к использованию?
Мы решили, что первыми инструментами, с которыми надо интегрироваться будут Sketch и GitHub. Над этим мы и работаем. Кроме того, мы планируем интеграцию с сервисами, которые следят за качеством кода и тестирования, а также с Parse и FramerJS для тестирования компонентов на живых данных. После этого добавим различные плюшки вроде интеграции с Dropbox и онлайн просмотра компонентов, а затем возьмемся за Adobe Illustrator.

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

Кто первые клиенты, как выходили на них?
Я просто взял и рассказал о проекте на Frontend Conf в Москве и Web Standards Days в Петербурге. Также мы выходили в дайджесте опенсорс новостей и писали в группы на Facebook. Мы только начинаем. Наши первые клиенты – дизайнеры и разработчики, у которых наболело. Команды, у которых разработка интерфейсов на потоке, постоянные редизайны и жуткие дедлайны. Некоторые из них подходили после доклада или в кулуарах, чтобы рассказать свою боль и как наш сервис мог бы её решить. Это очень вдохновляет.

Трудно предлагать компаниям серьёзно изменить взгляды на процесс разработки? Или этого в принципе не требуется?
Это зависит от того, какая это компания. Если компания уже доросла до своих библиотек, то им ничего объяснять не нужно. Если компания переходит на Sketch и понимает всю несостоятельность Adobe Photoshop для создания интерфейсов, то эти ребята, как правило, в курсе того, куда движется индустрия. Они постоянно работают над своими процессами, потому что это экономит деньги и силы. Мы не предлагаем менять взгляд на разработку. Мы предлагаем оптимизацию и взгляд под другим углом. Пока мы не встречали ярых противников, что внушает надежду. Обычно хватает нескольких вопросов о том, как начать использовать сервис и с какими технологиями и инструментами он может работать. Основным требованием сейчас является наличие библиотеки компонентов интерфейса в любом виде или желание её создать. А последним – установка нашего приложения на ваш Mac и наличие на нем Sketch. Во время установки мастер вам задаст несколько вопросов для настройки окружения и можно начинать работать. Не лишним будет заранее познакомиться с современными методологиями проектирования компонентов интерфейса. Мы будем стараться как можно больше рассказывать об этом.

Какой получаете сейчас фидбек? Сильные и слабые стороны сервиса?
Сейчас об этом рано говорить. Все это мы поймем на бета-тестировании осенью. Сейчас это выглядит как чудо. И нам хочется надеяться, что так оно и есть. Самое удивительное, что мы получаем много предложений помощи проекту. Оказывается, есть много людей, готовых помогать в разработке или выступать тестировщиками совершенно бесплатно. Только лишь потому, что Protein может решить их проблемы.

Что по конкурентам и «заменителям»?
Кажется, что прямых конкурентов нет, но хватает косвенных. Например, сервисы вроде UXPin, Invision, proto.io и т.д. Сейчас на каждом шагу предлагают компоненты как панацею от всех проблем. Но вот инструментов, позволяющих с ними работать, вы не найдете. Трудно предсказать, как именно индустрия будет создавать интерфейсы. Главное, что мы единственные, кто не предлагает отказываться от инструментов проектирования и разработки, используемых у вас в команде. Бесшовная интеграция может сыграть ключевую роль. Кроме того, только мы предлагаем сервис для оптимизации процессов создания продуктов, а не конструктор или редактор прототипов из несуществующих компонентов. Вдобавок, мы предлагаем интеграцию со многими сервисами в будущем, что дает огромную свободу выбора.

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

На какие рынки, прежде всего, нацелен Protein? В каком направлении планируете развитие и фокусировку?
Сегодня мы идем на рынок разработки веб-приложений. Наши клиенты – это команды в веб и digital-студиях. Компании, которые выпускают веб-приложения и сервисы ежедневно. Ещё мы очень хотим заинтересовать свободных разработчиков и дизайнеров, которые работают из разных точек земного шара. Ребята, мы знаем, как вам помочь! Дальше мы собираемся двигаться в мобильном направлении. Мы придумали технологию, которая позволяет нам работать с любыми компонентами. Созданы они для веба или для приложения – абсолютно неважно. Мы очень хотим применить наш подход для создания мобильных приложений. Потому что у ребят, которые их создают, проблем ещё больше. Рынок мобильных приложений постоянно растет, как и компании, которые их создают.

Какие доработки и новые возможности будете реализовывать?
Первым делом мы будем развивать live-preview компонентов. Мы дадим под каждый проект веб-страницу и локальный сервер для просмотра компонентов и того, что с ними происходит. Этого очень не хватает при разработке. Следом мы будем улучшать конвертацию и стремиться получить live-preview не только компонентов, но и макетов, создаваемых в дизайн-инструментах. Это даст, наконец, возможность «трогать руками» тот интерфейс, который создаётся в редакторе. Остальное пока под покровом тайны. Но по секрету вам скажу, что мы работаем над аналитикой компонентов, используемых в живых интерфейсах. Мы хотим дать её дизайнерам и разработчикам для использования в их инструментах.

Каким ты видишь в будущем процесс создания интерфейсов?
Хочется быть как Тони Старк и собирать интерфейсы руками, ощущая все компоненты на кончиках пальцев. Шутка! Сложно ответить на такой вопрос. Чтобы это понять, надо выяснить, какие будут интерфейсы в будущем, и только тогда можно подумать над тем, как их создавать. Всё стремительно развивается. Мы сейчас где-то в стадии переосмысления многих лет разработки. Точно можно сказать, что мы, наконец, перестанем создавать всё с нуля. Когда-то это точно должно прекратиться. Мы не будем думать о том, как тот или иной компонент работает внутри. Мы будем строить связи между ними, а компоненты – сами подстраиваться друг под друга и окружающую их среду. Всё большее и большее значение будет иметь проектирование и дизайн. Уже сейчас видно, как разработчики идут в дизайн, а дизайнеры изучают программирование. Вероятно, мы с вами видим становление новой профессии. Понятие разработчик интерфейсов очень хорошо отражает весь смысл этого. Не будет дизайнеров интерфейсов и фронтенд разработчиков. Будут разработчики интерфейсов, которые создают живые продукты в дизайн-инструментах, позволяющих писать код, строить связи и использовать аналитику работы компонентов со всего мира.

Что ж, остаётся только наблюдать, как меняется этот мир! Желаем успеха!

 
интервью
проектирование
интерфейс
дизайн
front end
Protein
Anton Winogradov
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться