Представляем седьмой выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Сергей Борисюк, сооснователь и технический директор компании PandaDoc.
Слушать подкаст
О нашем собеседнике:
Сергей Борисюк карьеру разработчика начал в Минске в компании EPAM Systems (2006). В 2007−2010 годах работал в SaM Solutions; параллельно с работой в компании стал сооснователем собственного проекта—Coding Staff, где занимал должность технического директора. В январе 2011 года совместно с Микитой Микадо запустил свою вторую компанию Quote Roller, сегодня известную как PandaDoc (приложение для автоматизации документооборота).
Александр Астапенко: Сергей, расскажи, как появился Coding Staff и каким образом ты превратился из программиста в основателя собственной компании?
Сергей Борисюк: Я с Микитой знаком очень давно, и началось все с того, что мы играли в одной рок-группе. Он был басистом, а я—барабанщиком. И так получилось, что Микита поехал в Америку студентом по обмену. На тот момент компании, которые занимались разработкой веб-сайтов, росли как грибы. Микита сделал свою маленькую веб-дизайн студию на Гавайях, где он тогда жил, и ему была нужна какая-то помощь с программированием, по чистой случайности мы сконтактировались. Через какое-то время он вернулся в Беларусь, и мы решили открыть свою компанию, начать заниматься тем же самым аутсорсингом, но только уже самостоятельно. Так, собственно, родился Coding Staff. Почему это было параллельно с моей работой в других компаниях? Причина банальная—распределение. Хотелось сделать что-то самому, но я еще был связан контрактом. Я тогда работал Java-тренером в компании SaM Solutions, и мы как-то договорились полюбовно, распределили время и обязанности.
Александр Астапенко: И что на тот момент представлял собой Coding Staff?
Сергей Борисюк: На тот момент Coding Staff—однокомнатная квартира, в которой жил Микита. Еще пять−шесть человек приходили утром и уходили вечером. Мы варили макароны и шутили, что вот так обедает American-based software development company—макароны по-флотски и пельмени. Делали разную мусорную работу, в общем-то, мелкие веб-сайты, еще что-то. Мы сфокусировались на системе управления сайтами DotNetNuke и начали делать проекты на ее основе, а потом стали разрабатывать и модули для нее. Хоть спустя пять лет такое и звучит странно, но тем не менее продукты—небольшие расширения для этой системы управления сайтами—продавались и постоянно приносили нам доход.
Александр Астапенко: А как появился проект Quote Roller? Как определились с конкретным продуктом?
Сергей Борисюк: По-моему, в 2010 году мы поехали на Google Developer Day в Москву, где выступал евангелист Google Дон Додж (Don Dodge). После разговора с ним—самое интересное, что он не сказал ничего невероятного—мы вдохновились и решили, что надо переставать заниматься ерундой и делать свой продукт. Тогда мы, правда, еще не знали какой это будет продукт.
В один прекрасный день, когда все уже ушли с работы, к нам пришли два запроса на разработку. Наши product- и sales-менеджеры, если можно так сказать, были в отпуске. В офисе никого нет, а ответить и найти цены нужно. Я начал искать документы, которые мы посылаем нашим клиентам, и, конечно, ничего не нашел. Психовал, не понимал, что мы оцениваем: какие цены на это, какие—на то. В общем, я решил, что так быть не должно, и нужна какая-то более стройная система, которая позволяла бы отправлять подобные документы (предложения, ответы на запросы клиентов), с уже указанными там ценами, с тем, что мы делаем, кто мы такие и как наш процесс работает, с квотой. Так мы и придумали идею для Quote Roller.
Павел Павлов: Что происходило с Coding Staff по мере развития Quote Roller, а позже—PandaDoc?
Сергей Борисюк: Мы управляли двумя компаниями параллельно, и на тот момент Quote Roller был скорее проектом внутри Coding Staff. Мы экспериментировали еще с несколькими проектами, которые потом отпочковались и умерли. Компания Coding Staff финансировала Quote Roller, и мы фактически не зарабатывали, а вкладывали деньги в развитие другого продукта. Было тяжело, потому что самое главное в стартапах—фокус. Если долбить в одно и тоже место, то можно стать успешным, а если распыляться и пытаться заработать и там, и там, то ты, конечно, заработаешь, но это будут совершенно другие деньги. Поэтому спустя какое-то время мы нашли менеджера, который стал управлять Coding Staff, а наш фокус полностью сместился на собственный продукт. Мы стали отдельной компанией. Спустя какое-то время компания Coding Staff тоже преобразовалась в другую компанию.
Павел Павлов: Кто помогал вам создавать Quote Roller, позже PandaDoc, в самом начале? Те же ребята, которые сидели в однокомнатной квартире в Минске? Или как-то изменилась ситуация?
Сергей Борисюк: Так как мы решили изменить технологический стек, то это была уже другая команда. Я был Java-программистом, поэтому мне все-таки ближе open source мир, а не закрытый проприетарный типа .NET. Для Quote Roller мы с самого начала выбрали Python и нашли двух программистов, которые до сих пор работают с нами. Собственно, это и была команда: я, два разработчика, иногда дизайнер, а Микита больше занимался маркетингом и продажами на тот момент.
Павел Павлов: Как сейчас выглядит ваша команда?
Сергей Борисюк: Раньше в компании было четыре, иногда пять человек, которые к тому же работали не full time. Теперь нас около 30 и мы работаем в трех офисах. Офис разработки находится в Минске, в Южной Каролине—поддержка клиентов и частично продажи, в Сан-Франциско—головной офис с нашими маркетинговыми и sales-ресурсами. Я с Микитой тоже в Сан-Франциско. Все работают на full time, чему я очень рад.
Александр Астапенко: Ты недавно переехал в ваш головной офис в Калифорнии, а команда разработки осталась в Минске. Расскажи, как выглядит управление процессом разработки, когда ты находишься, скажем, в 11 часах от Минска.
Сергей Борисюк: Прелесть в том, что если команда хорошая, ты можешь находиться в 11 часах временной разницы от Минска. У нас есть director of engineering, и он теперь выполняет ту работу, которой я занимался в Беларуси.
Почему возникла необходимость в моем переезде? Компания росла, поэтому изменялись мои роли и обязанности: в самом начале занимаешься всем, потом фокусируешься на релиз-менеджменте, фичах, планировании, а уже затем переходишь на работу в стратегическом направлении—технологии и партнерство. И когда доходишь до этого стратегического этапа, имеет смысл находиться там, где твои партнеры и большинство клиентов, в одной с ними временной зоне и желательно в том же месте: ты можешь прийти к ним в офис и объяснить, как все работает, что мы можем сделать вместе.
Я созваниваюсь с командой часто, и мы держим тесный контакт. Работать в одном офисе с инженерами было очень приятно и круто, ведь проще делать продукт, когда вы все сидите вместе, а когда команда распределенная—уже сложнее, потому что временная разница в 11 часов огромна.
Павел Павлов: Как ты сам сказал, важным условием было наличие эффективной и ответственной команды, а также человека, который бы помогал тебе в Минске. А как удалось построить такую команду?
Сергей Борисюк: Сложности, наверное, всегда есть. С точки зрения инженерной, нам повезло быть в Беларуси. У нас есть огромное количество прекрасных и талантливых разработчиков, которых мы можем нанять и это круто. С другой стороны, не повезло, потому что делать продукт на глобальный рынок из Беларуси—очень тяжело. Ты банально не имеешь возможности поехать в США пока не получишь визу.
Как мы растили команду? Я привык сравнивать команду инженерную с командой футбольной. Знаете, когда там 12 звезд, которые не могут играть вместе, то это намного хуже, чем команда крепких и слаженно играющих футболистов. И сейчас ребята выросли в суперзвезд. Мы, в принципе, руководствовались этим принципом и, помимо технических навыков, обращали внимание на возможность учиться. В стартапе крайне важна культура, особенно в самом начале, когда вы проводите очень много времени вместе. Я нанимал несколько действительно неплохих инженеров, которые просто не прижились из-за того, что культура (culture fit) сильно отличалась от того, что было у нас. Сulture fit на ранней стадии стартапа, возможно, даже важнее технических навыков.
Павел Павлов: Можно ли в процессе интервью понять подходит ли человек с точки зрения culture fit?
Сергей Борисюк: Однозначно, можно понять. Как мы это делали? Сначала я интервьюировал человека, потом—ребята из команды, и так выводили какое-то среднее мнение о нем. Я иногда ловлю себя на мысли, что шел на компромисс и думал: «Ладно, может быть что-то изменится». Не изменялось. Если сразу чувствуется, что человек по культуре не очень хорошо подходит, есть какое-то трение, лучше пропускать.
Павел Павлов: Не до конца понятно, что все-таки представляет собой культура PandaDoc? Как бы ты охарактеризовал?
Сергей Борисюк: Это когда у тебя есть какие-то персональные качества, которые подходят персональным качествам команды. Это то, как ты общаешься и что делаешь после работы, насколько ты легок на подъем, разделяешь ли ценности компании, насколько ты командный игрок. Все вместе и складывается в образ человека, который может работать у нас. Культуру сложно описать и разложить на элементы, но когда ты проработал с командой год, то сразу понимаешь, кого туда можно добавить, а кого лучше не добавлять.
Павел Павлов: А чем нужно заниматься после работы, чтобы попасть в PandaDoc?
Сергей Борисюк: Самое главное—любить панд.
Александр Астапенко: Почему людям будет интересно работать в PandaDoc?
Сергей Борисюк: Если человек занимался продуктовой разработкой, он понимает ее отличия от работы в аутсорсинговой компании. Иногда к нам приходят разработчики из аутсорсинга и говорят: «Ребята, вы занимаетесь одним проектом, так неинтересно». И все мы смотрим большими глазами: «Как это может быть неинтересно, если мы занимаемся своим продуктом?» Во-первых, ты можешь влиять на продукт. Во-вторых, мы очень гибки в технологиях и можем пробовать самые-самые последние разработки, фреймворки и так далее. Мы много экспериментируем и с технологиями, и с фичами. Мы открыты, и каждый из наших работников знает о том, что было сделано за месяц, сколько компания заработала, как мы развиваемся и какие у нас планы. Это сильно отличается от аутсорсинговых компаний. Плюс возможность того, что бизнес вырастет и станет многомиллионным. Как правило, этого достаточно, чтобы понять загорелся человек или нет.
Павел Павлов: Можешь подробнее рассказать про ваши технологические новшества?
Сергей Борисюк: Мы начали с Quote Roller и использовали там Python и Django в классическом варианте, без каких-либо особых инноваций, хотя мы, наверное, стали одними из самых первых пользователей Backbone. Помню даже, что мы были указаны на сайте проекта. Конечно, когда Backbone начали пользоваться все, нас оттуда выкинули, потому что лучше иметь огромные компании в портфолио.
Спустя какое-то время мы решили сделать архитектуру PandaDoc более гибкой—это REST API с несколькими клиентами, один из которых AngularJS, плюс мобильные iOS и Android клиенты. В целом у нас сервис-ориентированная архитектура с небольшими, в принципе, независимыми блоками внутри. Мы до сих пор используем Python и Django. Почему именно такой стек? Перед тем, как начинать PandaDoc, мы попробовали кучу фреймворков, экспериментировали с не реляционными базами данных, и все разработчики пришли к выводу, что для нас это абсолютно бессмысленно в приложении и еще больше усложняет процесс.
С чем мы экспериментируем? Например, собираем аналитику по документам—нечто похожее на Google Analytics для сайтов. Ты можешь смотреть сколько времени клиент проводит на определенных страницах документов, откуда он их смотрит. Для этого сервиса используем Python, Tornado и MongoDB, для основной части—Python, Django и Postgre.
Александр Астапенко: Мы уже ушли в технологии, но можешь про сам продукт PandaDoc пару слов сказать?
Сергей Борисюк: PandaDoc—это веб и мобильное приложение, которое помогает автоматизировать документооборот. Может звучать скучно, но на самом деле все не так. Первое, что мы сделали—редактор документов, похожий на современные визуальные редакторы сайтов. У тебя есть блоки (картинка слева, справа тексты, заголовки, таблицы, видео), из которых ты можешь собирать документы. Этот редактор—краеугольный камень, он выглядит очень красиво, мы поддерживаем разные темы для документов. Время на разработку самих документов тоже сокращается.
Правда, этого было бы недостаточно для того, чтобы продавать продукт, и сейчас мы больше фокусируемся на людях, которые занимаются продажами в компаниях. И для них главной причиной использования PandaDoc стала автоматизация. Как это происходит? Человек продает какой-то продукт, и он должен прислать клиенту документ с описанием продукта, с ценами, с информацией о компании—это то, что наши пользователи делают через PandaDoc. PandaDoc помогает достать данные из одной системы, очень быстро сформировать из них документ, подставить эти данные, внести какие-то поля, которые должен заполнить клиент (электронная подпись, имя, фамилия и так далее), а потом отправить документ как ссылку. Клиент может открыть ссылку, просмотреть документ, заполнить поля и подписать документ в электронном виде, что будет легально в большинстве развитых стран. Наш пользователь получает подписанный документ прямо в свой аккаунт PandaDoc, то есть время завершения сделки сокращается колоссально. Мы по своей статистике за несколько лет работы в Quote Roller и PandaDoc наблюдаем увеличение производительности с продуктом до 35%.
Александр Астапенко: Сколько сейчас пользователей у PandaDoc? О какой нагрузке идет речь?
Сергей Борисюк: Так как PandaDoc—это бизнес-приложение, то каких-то сумасшедших нагрузок нет. У нас около 100 000 пользователей на данный момент. Компании, которые реально пользуются, составляют где-то до 10 000.
Павел Павлов: Какую выбрали платформу для поддержки пользователей? Где разворачиваете свое приложение?
Сергей Борисюк: Я думаю, что это не будет сюрпризом—на Amazon. Почему там? Это довольно гибко. Мы оптимизировали всю нашу инфраструктуру и то, как мы ее разворачиваем. С помощью Chef мы можем добавлять сервера вообще за минуты, разворачивать какие-то зеркальные инфраструктуры и так далее. Это очень быстро и хорошо поддерживается. Если что-то изменяется, ты просто поменял рецепты, и у тебя вся обновленная инфраструктура.
Александр Астапенко: Я могу ошибаться, но, по-моему, вы раньше пользовались Rackspace. Было такое?
Сергей Борисюк: Так как у нас два продукта, то для одного—Rackspace, а для другого—Amazon.
Александр Астапенко: Я так понимаю, что для PandaDoc используете Amazon, а для Quote Roller—Rackspace?
Сергей Борисюк: Да, да.
Александр Астапенко: Почему PandaDoc решили на Amazon? Rackspace все же чем-то не устраивает? Кроме цены есть что-то?
Сергей Борисюк: Там, скорее, даже не цена. Нам почему-то показалось, что инициализация всего на Amazon значительно быстрее происходит, чем на Rackspace. Возможно, что-то уже изменилось, но мы решили пойти путем Amazon. Плюс у них очень много дополнительных сервисов, один из которых мы сейчас начинаем использовать—KMS, управление ключами для шифрования. И это очень круто, потому что для стартапа иметь свою железную инфраструктуру для управления ключами—супер дорого, несколько тысяч в месяц. Так ты можешь отложить траты на какой-то промежуток времени, и это относительно недорого в месяц. Плюс, оба провайдера поддерживают стартапы, и у фондов, которые в нас инвестировали, есть с ними договоренности. Они дают очень большие кредиты: 20 000−25 000 на сервисы Amazon, поэтому год бесплатно практически пользовались. И тоже самое Rackspace.
Александр Астапенко: Раз уж мы в теме серверов и облаков, расскажи, как у вас организован процесс непрерывной интеграции.
Сергей Борисюк: Для непрерывной интеграции мы используем Jenkins. Мы уделяем внимание юнит-тестам, но не очень много внимания к непрерывной интеграции как таковой, что меня, несомненно, не радует. Но что есть, то есть. Так как приложение у нас довольно сложное, то есть такие функциональные части, которые юнит-тестами не покроешь, особенно интеграционные—у нас очень много интеграций. Мы используем Selenium для автоматизированного тестирования. В общем-то, у нас все автоматизировано, и мы можем выкатить продукт за минуту, есть несколько стейджинг инфраструктур, на которых мы работаем. Два человека в команде иногда делают много мануального тестирования, чтобы убедиться, что все окей, так как Selenium-тесты иногда не все могут схватить с точки зрения логики.
Что касается релиз-менеджмента, у нас нет непрерывного релиз-менеджмент. Мы готовую фичу не отпускаем сразу в продакшн, а делаем это где-то раз в неделю, но нет проблемы и в том, чтобы какие-то фичи выпускать между релизами.
Александр Астапенко: У меня сейчас открыт документ в Google Docs, где я какие-то свои пометки для подкаста делаю, и там есть только один add-on. Угадай, какой?
Сергей Борисюк: PandaDoc.
Александр Астапенко: PandaDoc, да. Вы, насколько я помню, попали в число первых, кто эти add-ons сделали. Расскажи, может быть, кому-то поможет, у кого потенциально есть возможность интегрироваться с такими большими компаниями и сервисами.
Сергей Борисюк: Да, все верно. Мы участвовали в Early Access Program для add-ons, которые Google запустил весной прошлого года. Первый наш add-on—для PandaDoc. Как он работает? Ты можешь подписывать и отправлять на подпись Google-документы через PandaDoc. Второй add-on—для переноса информации из электронной таблицы (spreadsheet) в документ. Предположим, у тебя есть 100 записей, и ты хочешь создать 100 документов, только с разными данными из таблицы—это то, что делает Document Merge.
Как это произошло? Одна из причин—нахождение в Сан-Франциско, потому что такие вещи случаются. В этот раз нам помог один из наших бизнес-ангелов, который работает в Google. Он свел нас с командой, занимающейся add-ons, и мы начали участвовать в программе. Как Early Access Program работает внутри: это закрытая группа, есть какие-то обновления, доступ к девелоперам Google. Ты разрабатываешь add-on, готовится релиз, заранее скоординированный пиар-запуск. Опыт работы с Google в Early Access Program потрясающий: вы не представляете насколько быстро отвечают люди из такой огромной компании. У нас и до этого были приложения в Google App Store, Chrome, мы с ними очень плотно так интегрируемся и дружим.
Павел Павлов: Получается, что твой бизнес-день сейчас в основном состоит из встреч с партнерами, инвесторами?
Сергей Борисюк: Нет. И слава Богу, что это не так. Я больше занимаюсь продуктом, разговариваю с пользователями, пытаюсь найти какие-то вещи, которые мы должны добавить. Мой день теперь немного более разнообразный, а в Беларуси я фокусировался только на продукте и разработке. Сложно даже сказать, что мне нравится больше. Наверное, все-таки продукт.
Павел Павлов: Раз ты находишься в Сан-Франциско, то у тебя есть возможность участвовать в различных сообществах, митапах. Занимаешься ли ты такими вещами?
Сергей Борисюк: Пока не занимаюсь, я совсем недавно переехал, но в целом нам очень нравится поддерживать сообщество. В Беларуси мы это делаем: я сам выступал на митапах, какие-то вещи мы пытаемся спонсировать, выделять призы. Из последнего—конференция сообщества The Rolling Scopes. У больших компаний есть интерес к подобным мероприятиям с точки зрения найма людей. У нас же в найме особо интереса нет, потому что компания относительно небольшая и нет потребности в огромном количестве ресурсов. Скорее, мы занимаемся этими мероприятиями для удовольствия, чтобы быть внутри сообщества. В Сан-Франциско пока не участвую и, честно говоря, иногда не хватает времени уже.
Александр Астапенко: Ты сегодня упоминал, что в свое время вы начинали Coding Staff на .NET, и потом ты был очень рад переходу на более открытый технологический стек в Quote Roller и PandaDoc. Какую роль open source играет в культуре компании?
Сергей Борисюк: У нас есть планы, идеи, но как всегда не хватает времени. Мне кажется, что open source—основной двигатель всех инноваций. И когда-то в свое время, работая в EPAM, я как раз-таки и занимался open source. Мне нравилось: расширяет кругозор, связи, делает мир лучше.
Если посмотреть на количество open source кода, который мы используем в своих проектах, то практически все там—open source. У нас есть пара вещей, которые мы купили просто из-за лицензии, но это весь open source код.
Александр Астапенко: Я так понимаю, что пока в PandaDoc вы не очень активно open source продукты делаете?
Сергей Борисюк: Мы пока не вносим своего вклада, к сожалению, но у нас есть такие планы. Дай Бог, что это случится в 2015 году.
Александр Астапенко: Что-нибудь скажешь в завершение подкаста?
Сергей Борисюк: Я хочу сказать, что не надо бояться что-то пробовать и начинать как в open source, так и в направлении стартапов. Мне очень нравится то, что сейчас происходит в Беларуси с точки зрения всего этого движения, когда люди начинают думать не только о коде, а о каких-то вещах в целом, вроде продуктов, ценности, которую они приносят сообществу, людям. Мы с Микитой называем наши компании самым лучшим университетом, за который мы заплатили очень дорого, но это самое лучшее образование.
Слушать подкаст
О нашем собеседнике:
Сергей Борисюк карьеру разработчика начал в Минске в компании EPAM Systems (2006). В 2007−2010 годах работал в SaM Solutions; параллельно с работой в компании стал сооснователем собственного проекта—Coding Staff, где занимал должность технического директора. В январе 2011 года совместно с Микитой Микадо запустил свою вторую компанию Quote Roller, сегодня известную как PandaDoc (приложение для автоматизации документооборота).
Текстовая версия подкаста
На пути к PandaDoc
Александр Астапенко: Сергей, расскажи, как появился Coding Staff и каким образом ты превратился из программиста в основателя собственной компании?
Сергей Борисюк: Я с Микитой знаком очень давно, и началось все с того, что мы играли в одной рок-группе. Он был басистом, а я—барабанщиком. И так получилось, что Микита поехал в Америку студентом по обмену. На тот момент компании, которые занимались разработкой веб-сайтов, росли как грибы. Микита сделал свою маленькую веб-дизайн студию на Гавайях, где он тогда жил, и ему была нужна какая-то помощь с программированием, по чистой случайности мы сконтактировались. Через какое-то время он вернулся в Беларусь, и мы решили открыть свою компанию, начать заниматься тем же самым аутсорсингом, но только уже самостоятельно. Так, собственно, родился Coding Staff. Почему это было параллельно с моей работой в других компаниях? Причина банальная—распределение. Хотелось сделать что-то самому, но я еще был связан контрактом. Я тогда работал Java-тренером в компании SaM Solutions, и мы как-то договорились полюбовно, распределили время и обязанности.
Александр Астапенко: И что на тот момент представлял собой Coding Staff?
Сергей Борисюк: На тот момент Coding Staff—однокомнатная квартира, в которой жил Микита. Еще пять−шесть человек приходили утром и уходили вечером. Мы варили макароны и шутили, что вот так обедает American-based software development company—макароны по-флотски и пельмени. Делали разную мусорную работу, в общем-то, мелкие веб-сайты, еще что-то. Мы сфокусировались на системе управления сайтами DotNetNuke и начали делать проекты на ее основе, а потом стали разрабатывать и модули для нее. Хоть спустя пять лет такое и звучит странно, но тем не менее продукты—небольшие расширения для этой системы управления сайтами—продавались и постоянно приносили нам доход.
Александр Астапенко: А как появился проект Quote Roller? Как определились с конкретным продуктом?
Сергей Борисюк: По-моему, в 2010 году мы поехали на Google Developer Day в Москву, где выступал евангелист Google Дон Додж (Don Dodge). После разговора с ним—самое интересное, что он не сказал ничего невероятного—мы вдохновились и решили, что надо переставать заниматься ерундой и делать свой продукт. Тогда мы, правда, еще не знали какой это будет продукт.
В один прекрасный день, когда все уже ушли с работы, к нам пришли два запроса на разработку. Наши product- и sales-менеджеры, если можно так сказать, были в отпуске. В офисе никого нет, а ответить и найти цены нужно. Я начал искать документы, которые мы посылаем нашим клиентам, и, конечно, ничего не нашел. Психовал, не понимал, что мы оцениваем: какие цены на это, какие—на то. В общем, я решил, что так быть не должно, и нужна какая-то более стройная система, которая позволяла бы отправлять подобные документы (предложения, ответы на запросы клиентов), с уже указанными там ценами, с тем, что мы делаем, кто мы такие и как наш процесс работает, с квотой. Так мы и придумали идею для Quote Roller.
Павел Павлов: Что происходило с Coding Staff по мере развития Quote Roller, а позже—PandaDoc?
Сергей Борисюк: Мы управляли двумя компаниями параллельно, и на тот момент Quote Roller был скорее проектом внутри Coding Staff. Мы экспериментировали еще с несколькими проектами, которые потом отпочковались и умерли. Компания Coding Staff финансировала Quote Roller, и мы фактически не зарабатывали, а вкладывали деньги в развитие другого продукта. Было тяжело, потому что самое главное в стартапах—фокус. Если долбить в одно и тоже место, то можно стать успешным, а если распыляться и пытаться заработать и там, и там, то ты, конечно, заработаешь, но это будут совершенно другие деньги. Поэтому спустя какое-то время мы нашли менеджера, который стал управлять Coding Staff, а наш фокус полностью сместился на собственный продукт. Мы стали отдельной компанией. Спустя какое-то время компания Coding Staff тоже преобразовалась в другую компанию.
О команде
Павел Павлов: Кто помогал вам создавать Quote Roller, позже PandaDoc, в самом начале? Те же ребята, которые сидели в однокомнатной квартире в Минске? Или как-то изменилась ситуация?
Сергей Борисюк: Так как мы решили изменить технологический стек, то это была уже другая команда. Я был Java-программистом, поэтому мне все-таки ближе open source мир, а не закрытый проприетарный типа .NET. Для Quote Roller мы с самого начала выбрали Python и нашли двух программистов, которые до сих пор работают с нами. Собственно, это и была команда: я, два разработчика, иногда дизайнер, а Микита больше занимался маркетингом и продажами на тот момент.
Павел Павлов: Как сейчас выглядит ваша команда?
Сергей Борисюк: Раньше в компании было четыре, иногда пять человек, которые к тому же работали не full time. Теперь нас около 30 и мы работаем в трех офисах. Офис разработки находится в Минске, в Южной Каролине—поддержка клиентов и частично продажи, в Сан-Франциско—головной офис с нашими маркетинговыми и sales-ресурсами. Я с Микитой тоже в Сан-Франциско. Все работают на full time, чему я очень рад.
Александр Астапенко: Ты недавно переехал в ваш головной офис в Калифорнии, а команда разработки осталась в Минске. Расскажи, как выглядит управление процессом разработки, когда ты находишься, скажем, в 11 часах от Минска.
Сергей Борисюк: Прелесть в том, что если команда хорошая, ты можешь находиться в 11 часах временной разницы от Минска. У нас есть director of engineering, и он теперь выполняет ту работу, которой я занимался в Беларуси.
Почему возникла необходимость в моем переезде? Компания росла, поэтому изменялись мои роли и обязанности: в самом начале занимаешься всем, потом фокусируешься на релиз-менеджменте, фичах, планировании, а уже затем переходишь на работу в стратегическом направлении—технологии и партнерство. И когда доходишь до этого стратегического этапа, имеет смысл находиться там, где твои партнеры и большинство клиентов, в одной с ними временной зоне и желательно в том же месте: ты можешь прийти к ним в офис и объяснить, как все работает, что мы можем сделать вместе.
Я созваниваюсь с командой часто, и мы держим тесный контакт. Работать в одном офисе с инженерами было очень приятно и круто, ведь проще делать продукт, когда вы все сидите вместе, а когда команда распределенная—уже сложнее, потому что временная разница в 11 часов огромна.
Павел Павлов: Как ты сам сказал, важным условием было наличие эффективной и ответственной команды, а также человека, который бы помогал тебе в Минске. А как удалось построить такую команду?
Сергей Борисюк: Сложности, наверное, всегда есть. С точки зрения инженерной, нам повезло быть в Беларуси. У нас есть огромное количество прекрасных и талантливых разработчиков, которых мы можем нанять и это круто. С другой стороны, не повезло, потому что делать продукт на глобальный рынок из Беларуси—очень тяжело. Ты банально не имеешь возможности поехать в США пока не получишь визу.
Как мы растили команду? Я привык сравнивать команду инженерную с командой футбольной. Знаете, когда там 12 звезд, которые не могут играть вместе, то это намного хуже, чем команда крепких и слаженно играющих футболистов. И сейчас ребята выросли в суперзвезд. Мы, в принципе, руководствовались этим принципом и, помимо технических навыков, обращали внимание на возможность учиться. В стартапе крайне важна культура, особенно в самом начале, когда вы проводите очень много времени вместе. Я нанимал несколько действительно неплохих инженеров, которые просто не прижились из-за того, что культура (culture fit) сильно отличалась от того, что было у нас. Сulture fit на ранней стадии стартапа, возможно, даже важнее технических навыков.
Павел Павлов: Можно ли в процессе интервью понять подходит ли человек с точки зрения culture fit?
Сергей Борисюк: Однозначно, можно понять. Как мы это делали? Сначала я интервьюировал человека, потом—ребята из команды, и так выводили какое-то среднее мнение о нем. Я иногда ловлю себя на мысли, что шел на компромисс и думал: «Ладно, может быть что-то изменится». Не изменялось. Если сразу чувствуется, что человек по культуре не очень хорошо подходит, есть какое-то трение, лучше пропускать.
Павел Павлов: Не до конца понятно, что все-таки представляет собой культура PandaDoc? Как бы ты охарактеризовал?
Сергей Борисюк: Это когда у тебя есть какие-то персональные качества, которые подходят персональным качествам команды. Это то, как ты общаешься и что делаешь после работы, насколько ты легок на подъем, разделяешь ли ценности компании, насколько ты командный игрок. Все вместе и складывается в образ человека, который может работать у нас. Культуру сложно описать и разложить на элементы, но когда ты проработал с командой год, то сразу понимаешь, кого туда можно добавить, а кого лучше не добавлять.
Павел Павлов: А чем нужно заниматься после работы, чтобы попасть в PandaDoc?
Сергей Борисюк: Самое главное—любить панд.
Александр Астапенко: Почему людям будет интересно работать в PandaDoc?
Сергей Борисюк: Если человек занимался продуктовой разработкой, он понимает ее отличия от работы в аутсорсинговой компании. Иногда к нам приходят разработчики из аутсорсинга и говорят: «Ребята, вы занимаетесь одним проектом, так неинтересно». И все мы смотрим большими глазами: «Как это может быть неинтересно, если мы занимаемся своим продуктом?» Во-первых, ты можешь влиять на продукт. Во-вторых, мы очень гибки в технологиях и можем пробовать самые-самые последние разработки, фреймворки и так далее. Мы много экспериментируем и с технологиями, и с фичами. Мы открыты, и каждый из наших работников знает о том, что было сделано за месяц, сколько компания заработала, как мы развиваемся и какие у нас планы. Это сильно отличается от аутсорсинговых компаний. Плюс возможность того, что бизнес вырастет и станет многомиллионным. Как правило, этого достаточно, чтобы понять загорелся человек или нет.
О продукте PandaDoc и технологиях
Павел Павлов: Можешь подробнее рассказать про ваши технологические новшества?
Сергей Борисюк: Мы начали с Quote Roller и использовали там Python и Django в классическом варианте, без каких-либо особых инноваций, хотя мы, наверное, стали одними из самых первых пользователей Backbone. Помню даже, что мы были указаны на сайте проекта. Конечно, когда Backbone начали пользоваться все, нас оттуда выкинули, потому что лучше иметь огромные компании в портфолио.
Спустя какое-то время мы решили сделать архитектуру PandaDoc более гибкой—это REST API с несколькими клиентами, один из которых AngularJS, плюс мобильные iOS и Android клиенты. В целом у нас сервис-ориентированная архитектура с небольшими, в принципе, независимыми блоками внутри. Мы до сих пор используем Python и Django. Почему именно такой стек? Перед тем, как начинать PandaDoc, мы попробовали кучу фреймворков, экспериментировали с не реляционными базами данных, и все разработчики пришли к выводу, что для нас это абсолютно бессмысленно в приложении и еще больше усложняет процесс.
С чем мы экспериментируем? Например, собираем аналитику по документам—нечто похожее на Google Analytics для сайтов. Ты можешь смотреть сколько времени клиент проводит на определенных страницах документов, откуда он их смотрит. Для этого сервиса используем Python, Tornado и MongoDB, для основной части—Python, Django и Postgre.
Александр Астапенко: Мы уже ушли в технологии, но можешь про сам продукт PandaDoc пару слов сказать?
Сергей Борисюк: PandaDoc—это веб и мобильное приложение, которое помогает автоматизировать документооборот. Может звучать скучно, но на самом деле все не так. Первое, что мы сделали—редактор документов, похожий на современные визуальные редакторы сайтов. У тебя есть блоки (картинка слева, справа тексты, заголовки, таблицы, видео), из которых ты можешь собирать документы. Этот редактор—краеугольный камень, он выглядит очень красиво, мы поддерживаем разные темы для документов. Время на разработку самих документов тоже сокращается.
Правда, этого было бы недостаточно для того, чтобы продавать продукт, и сейчас мы больше фокусируемся на людях, которые занимаются продажами в компаниях. И для них главной причиной использования PandaDoc стала автоматизация. Как это происходит? Человек продает какой-то продукт, и он должен прислать клиенту документ с описанием продукта, с ценами, с информацией о компании—это то, что наши пользователи делают через PandaDoc. PandaDoc помогает достать данные из одной системы, очень быстро сформировать из них документ, подставить эти данные, внести какие-то поля, которые должен заполнить клиент (электронная подпись, имя, фамилия и так далее), а потом отправить документ как ссылку. Клиент может открыть ссылку, просмотреть документ, заполнить поля и подписать документ в электронном виде, что будет легально в большинстве развитых стран. Наш пользователь получает подписанный документ прямо в свой аккаунт PandaDoc, то есть время завершения сделки сокращается колоссально. Мы по своей статистике за несколько лет работы в Quote Roller и PandaDoc наблюдаем увеличение производительности с продуктом до 35%.
Александр Астапенко: Сколько сейчас пользователей у PandaDoc? О какой нагрузке идет речь?
Сергей Борисюк: Так как PandaDoc—это бизнес-приложение, то каких-то сумасшедших нагрузок нет. У нас около 100 000 пользователей на данный момент. Компании, которые реально пользуются, составляют где-то до 10 000.
Павел Павлов: Какую выбрали платформу для поддержки пользователей? Где разворачиваете свое приложение?
Сергей Борисюк: Я думаю, что это не будет сюрпризом—на Amazon. Почему там? Это довольно гибко. Мы оптимизировали всю нашу инфраструктуру и то, как мы ее разворачиваем. С помощью Chef мы можем добавлять сервера вообще за минуты, разворачивать какие-то зеркальные инфраструктуры и так далее. Это очень быстро и хорошо поддерживается. Если что-то изменяется, ты просто поменял рецепты, и у тебя вся обновленная инфраструктура.
Александр Астапенко: Я могу ошибаться, но, по-моему, вы раньше пользовались Rackspace. Было такое?
Сергей Борисюк: Так как у нас два продукта, то для одного—Rackspace, а для другого—Amazon.
Александр Астапенко: Я так понимаю, что для PandaDoc используете Amazon, а для Quote Roller—Rackspace?
Сергей Борисюк: Да, да.
Александр Астапенко: Почему PandaDoc решили на Amazon? Rackspace все же чем-то не устраивает? Кроме цены есть что-то?
Сергей Борисюк: Там, скорее, даже не цена. Нам почему-то показалось, что инициализация всего на Amazon значительно быстрее происходит, чем на Rackspace. Возможно, что-то уже изменилось, но мы решили пойти путем Amazon. Плюс у них очень много дополнительных сервисов, один из которых мы сейчас начинаем использовать—KMS, управление ключами для шифрования. И это очень круто, потому что для стартапа иметь свою железную инфраструктуру для управления ключами—супер дорого, несколько тысяч в месяц. Так ты можешь отложить траты на какой-то промежуток времени, и это относительно недорого в месяц. Плюс, оба провайдера поддерживают стартапы, и у фондов, которые в нас инвестировали, есть с ними договоренности. Они дают очень большие кредиты: 20 000−25 000 на сервисы Amazon, поэтому год бесплатно практически пользовались. И тоже самое Rackspace.
Александр Астапенко: Раз уж мы в теме серверов и облаков, расскажи, как у вас организован процесс непрерывной интеграции.
Сергей Борисюк: Для непрерывной интеграции мы используем Jenkins. Мы уделяем внимание юнит-тестам, но не очень много внимания к непрерывной интеграции как таковой, что меня, несомненно, не радует. Но что есть, то есть. Так как приложение у нас довольно сложное, то есть такие функциональные части, которые юнит-тестами не покроешь, особенно интеграционные—у нас очень много интеграций. Мы используем Selenium для автоматизированного тестирования. В общем-то, у нас все автоматизировано, и мы можем выкатить продукт за минуту, есть несколько стейджинг инфраструктур, на которых мы работаем. Два человека в команде иногда делают много мануального тестирования, чтобы убедиться, что все окей, так как Selenium-тесты иногда не все могут схватить с точки зрения логики.
Что касается релиз-менеджмента, у нас нет непрерывного релиз-менеджмент. Мы готовую фичу не отпускаем сразу в продакшн, а делаем это где-то раз в неделю, но нет проблемы и в том, чтобы какие-то фичи выпускать между релизами.
Александр Астапенко: У меня сейчас открыт документ в Google Docs, где я какие-то свои пометки для подкаста делаю, и там есть только один add-on. Угадай, какой?
Сергей Борисюк: PandaDoc.
Александр Астапенко: PandaDoc, да. Вы, насколько я помню, попали в число первых, кто эти add-ons сделали. Расскажи, может быть, кому-то поможет, у кого потенциально есть возможность интегрироваться с такими большими компаниями и сервисами.
Сергей Борисюк: Да, все верно. Мы участвовали в Early Access Program для add-ons, которые Google запустил весной прошлого года. Первый наш add-on—для PandaDoc. Как он работает? Ты можешь подписывать и отправлять на подпись Google-документы через PandaDoc. Второй add-on—для переноса информации из электронной таблицы (spreadsheet) в документ. Предположим, у тебя есть 100 записей, и ты хочешь создать 100 документов, только с разными данными из таблицы—это то, что делает Document Merge.
Как это произошло? Одна из причин—нахождение в Сан-Франциско, потому что такие вещи случаются. В этот раз нам помог один из наших бизнес-ангелов, который работает в Google. Он свел нас с командой, занимающейся add-ons, и мы начали участвовать в программе. Как Early Access Program работает внутри: это закрытая группа, есть какие-то обновления, доступ к девелоперам Google. Ты разрабатываешь add-on, готовится релиз, заранее скоординированный пиар-запуск. Опыт работы с Google в Early Access Program потрясающий: вы не представляете насколько быстро отвечают люди из такой огромной компании. У нас и до этого были приложения в Google App Store, Chrome, мы с ними очень плотно так интегрируемся и дружим.
Павел Павлов: Получается, что твой бизнес-день сейчас в основном состоит из встреч с партнерами, инвесторами?
Сергей Борисюк: Нет. И слава Богу, что это не так. Я больше занимаюсь продуктом, разговариваю с пользователями, пытаюсь найти какие-то вещи, которые мы должны добавить. Мой день теперь немного более разнообразный, а в Беларуси я фокусировался только на продукте и разработке. Сложно даже сказать, что мне нравится больше. Наверное, все-таки продукт.
Павел Павлов: Раз ты находишься в Сан-Франциско, то у тебя есть возможность участвовать в различных сообществах, митапах. Занимаешься ли ты такими вещами?
Сергей Борисюк: Пока не занимаюсь, я совсем недавно переехал, но в целом нам очень нравится поддерживать сообщество. В Беларуси мы это делаем: я сам выступал на митапах, какие-то вещи мы пытаемся спонсировать, выделять призы. Из последнего—конференция сообщества The Rolling Scopes. У больших компаний есть интерес к подобным мероприятиям с точки зрения найма людей. У нас же в найме особо интереса нет, потому что компания относительно небольшая и нет потребности в огромном количестве ресурсов. Скорее, мы занимаемся этими мероприятиями для удовольствия, чтобы быть внутри сообщества. В Сан-Франциско пока не участвую и, честно говоря, иногда не хватает времени уже.
Александр Астапенко: Ты сегодня упоминал, что в свое время вы начинали Coding Staff на .NET, и потом ты был очень рад переходу на более открытый технологический стек в Quote Roller и PandaDoc. Какую роль open source играет в культуре компании?
Сергей Борисюк: У нас есть планы, идеи, но как всегда не хватает времени. Мне кажется, что open source—основной двигатель всех инноваций. И когда-то в свое время, работая в EPAM, я как раз-таки и занимался open source. Мне нравилось: расширяет кругозор, связи, делает мир лучше.
Если посмотреть на количество open source кода, который мы используем в своих проектах, то практически все там—open source. У нас есть пара вещей, которые мы купили просто из-за лицензии, но это весь open source код.
Александр Астапенко: Я так понимаю, что пока в PandaDoc вы не очень активно open source продукты делаете?
Сергей Борисюк: Мы пока не вносим своего вклада, к сожалению, но у нас есть такие планы. Дай Бог, что это случится в 2015 году.
Александр Астапенко: Что-нибудь скажешь в завершение подкаста?
Сергей Борисюк: Я хочу сказать, что не надо бояться что-то пробовать и начинать как в open source, так и в направлении стартапов. Мне очень нравится то, что сейчас происходит в Беларуси с точки зрения всего этого движения, когда люди начинают думать не только о коде, а о каких-то вещах в целом, вроде продуктов, ценности, которую они приносят сообществу, людям. Мы с Микитой называем наши компании самым лучшим университетом, за который мы заплатили очень дорого, но это самое лучшее образование.