Денис Кравченко

Денис Кравченко создал платформу Adcel для агрегации рекламных ресурсов силами распределенной команды: ее сотрудники живут и работают в разных странах – от Украины до Таиланда. В колонке для MC Today он рассказывает, как сделать, чтобы такая удаленная команда работала эффективно. В 2014-ом я переехал в США и первое время занимался консалтингом, а потом решил помогать разработчикам мобильных приложений монетизироваться быстрее и проще. Так в 2016-м мы начали работать над своим собственным продуктом и появилась Adcel – платформа, которая позволяет агрегировать рекламные ресурсы, предоставляя издателям наиболее доходную рекламу для их аудитории. Денис Кравченко, Adcel Трудности и новые возможности Я решил создать команду единомышленников, чтобы реализовать продукт, но оказалось, что собрать офис талантливых программистов молодой компании сложно. Нам бы попросту не хватило финансов для найма профессионалов, так как старший программист в США может зарабатывать больше $10 тыс. в месяц плюс бонусы (они могут составлять до 40 % от базовой зарплаты). Я же ориентировался на $5 тыс. Выход из ситуации Оптимальным вариантом стала распределенная команда – мы хотели строить продукт сразу, не дожидаясь, пока найдутся дополнительные средства. И начали собирать людей через сервисы HeadHunter и LinkedIn. Первых пять человек мы нашли и наняли в течение месяца, а основную кадровую часть – за первые четыре месяца проекта. Сегодня у нас 15 профессионалов. Ребята находятся в разных странах и часовых поясах: есть люди из Украины, Беларуси, России и Таиланда. Основа основ – созвоны С самого начала было достаточно тяжело, потому что работа людей «где-то там далеко» сама собой не наладится. Сотрудники в офисах любят поболтать возле кофемашины, и это не должно измениться только потому, что у вас удаленная команда, работающая в разных странах. Мы пришли к тому, что главный способ коммуникации – это звонки. Чаще всего, если задача является продолжением предыдущей или поправкой к уже реализованной, звонок не нужен. Однако он обязателен для масштабных задач вроде нового функционала, смены архитектуры и так далее. Также каждое утро по киевскому времени у нас общий созвон, в котором мы обсуждаем такие вопросы: «Что я сделал?», «Что я буду делать?» и «Что в процессе?». Так сотрудники могут делиться проблемами и получать советы. Однако вначале без курьезов не обходилось. Мы работаем по американскому календарю, и бывают ситуации, когда ребята забывают про выходные на День труда или День независимости. Несколько раз были забавные случаи, когда на звонке присутствовали ребята, недоумевающие, где же остальная часть команды. Нормой также стали голоса собирающихся в школу детей на фоне. Мы уже привыкли и их непосредственным вопросам, которые так часто веселят команду. К примеру, сын одного сотрудника спросил: «Папа, почему вы говорите про архитектуру, вы что, строители?» Как мы координируем работу Весь процесс работы в компании структурирован, для всего есть свой инструмент. В Jira контролируем процесс разработки, в Wiki храним всю информацию о проекте, а в Telegram у нас есть общий чат и подгруппы чатов, где мы общаемся. Раз в несколько недель проводим встречи, используя Skype. На этих встречах мы не говорим о работе, но общаемся на бытовые темы для поддержания дружеской атмосферы в коллективе. Получается та же пятничная встреча за бокалом, только удаленная. Несмотря на разные часовые пояса и местонахождение, видеозвонок нивелирует расстояние и дает ощущение присутствия в режиме реального времени. Мы не верим и не используем систему контроля рабочего времени. Это дает людям возможность выполнять работу в периоды, когда они наиболее продуктивны, без обязательного графика. Есть только одно правило: если тебе нужно отойти от компьютера больше чем на полчаса, отправляешь в общий чат сообщение afk (Away From Keyboard, то есть «не у клавиатуры») 1/2/3 часа. Это индикатор для других членов команды, что ты недоступен. Правило свободного графика было с самого начала, но люди, работающие в мини-командах, приняли решение о более-менее едином графике для себя. Это не приказ начальства, а самостоятельное решение сотрудников. Если говорить о дедлайнах, то разработчик сам оценивает задачу, но при этом я контролирую, чтобы сроки были реалистичными. В обратном случае пытаюсь определить, в чем могут быть проблемы – в карьерной мотивации или в личном. Как пример, я никогда не забуду случай, когда один из наших сотрудников жил в Украине в зоне боевых действий и мы во время созвона слышали звуки стрельбы. В таких трудных условиях он все равно справлялся с задачами в срок. Но решили предложить ему переезд в более безопасное место, в столицу. Переезд обошелся нам в три месячных зарплаты, что покрыло аренду жилья, транспорт и привычный быт сотрудника. Думаю, что мы сравнительно быстро и эффективно решили две проблемы: помогли сотруднику в сложной жизненной ситуации и сохранили ценного кадра в команде. Поглощение компании Подтверждением того, что мы сделали хороший продукт, стало предложение о покупке и поглощении нашей компании. И в 2018 году мы подписали договор о продаже нашего продукта компании EngageBdr Ltd за $4,5 миллионов. И мы по сей день работаем в команде почти тем же составом, что был вначале. В итоге я вычленил для себя 5 правил, которые помогли мне собрать команду и успешно реализовать идею: Определить приоритеты и задачи. Я составил четкий план и определил бизнес-модель. Как продукт будет зарабатывать, кто будет клиентом и как бизнес будет реагировать на рост пользователей. Затем составил дорожную карту для минимально жизнеспособного продукта. Так появилось четкое понимание, каких инженеров и когда нанимать. А грамотный документ с бизнес-моделью дал представление о этапах роста, когда нужно будет нанимать маркетинг, поддержку, продажников и пиар. Думаю, важно нанимать людей по мере формирования продукта, потому что нанимать много сотрудников за раз сложно и неразумно. Расширять кругозор. Культурное разнообразие распределенной команды побуждает каждого мыслить нестандартно, понимать и принимать идеи, которые являются новыми и нетрадиционными. У нас был инженер, который вырос в материковом Китае, благодаря ему мы получили реальное представление о специфике Android-приложений там. Без этой экспертизы мы могли потерять несколько месяцев разработки, делая продукт, который невозможно будет использовать на этом рынке. Полагаться на реальные знания сотрудника. Даже проработав в крупной организации, человек может не иметь достаточного багажа знаний и опыта. Поэтому я проверяю знания тестовым заданием и многоэтапным рекрутинг-процессом. У нас в интервью участвовали сотрудники, в команду которых нанимали новенького: команда не могла пропустить человека, который будет обузой. Однако была одна серьезная ошибка с наймом Android-разработчика. Он хорошо зарекомендовал себя на интервью, но после найма не смог справиться с задачами, потому что у него не было практического опыта реализации своих знаний. В связи с этим Android-релиз нашего набора средств разработки пришлось сдвинуть на полтора месяца, пока мы искали замену. Организовать структуру работы. Учитывая особенности распределенной команды, нужно понимать, что коммуникация – это ключ. А первичная структура работы, которую вы себе представляете, скорее всего, будет видоизменяться с ростом команды. У нас, например, не прижился Slack как основное место коммуникации. В один момент мы решили попробовать заменить им Telegram, TeamSpeak и Skype. Через несколько недель команда единогласно решила вернуться к привычной схеме. Формировать правильные ожидания. Чтобы работать было комфортно, я научился ожидать от человека меньшего, чем он может дать. Поначалу у меня были очень завышенные ожидания к инженерам. Мой график выглядел примерно так: с 7:00 до 23:00 я работал, в остальное время пытался заснуть в мыслях о следующих задачах для проекта. Но я не просил сотрудников работать так же, а придерживаться восьмичасового графика. Но когда задача не выполнялась в срок, который я ожидал и за который сам мог ее сделать, это вызывало разочарование и конфликт. Я хотел видеть подобную отдачу от сотрудников и рассчитывал, что их интерес хотя бы чуточку будет сопоставим с моим. Благодаря советам друзей я изменил подход, что помогло мне получать больше, чем я ожидаю, и дало возможность сотрудникам проявить свои таланты на полную. В заключение скажу, что создание и управление распределенными командами может потребовать больше усилий в начале, но оно того стоит в перспективе. В конце концов эффективность вашей команды зависит не от того, где живут ваши сотрудники, а от того, что они могут сделать вместе.

Денис Кравченко

Как мы построили продукт стоимостью $4,5 млн силами удаленной команды. Колонка Дениса Кравченко