Как работа в саппорте может помочь стать CEO продуктовой компании

В этом интервью Сергей рассказал о важных моментах в развитии карьеры от простого разработчика до CEO. Поговорили и о трендах на рынке IT.

Расскажите, как начиналась ваша карьера?

В 2006 году я учился на 3 курсе вуза на программиста. На практику меня распределили в IBA-Gomel - филиал одного из крупнейших аутсорсеров в Беларуси на тот момент. Я поставил себе цель - закрепиться в компании и к новому учебному году иметь постоянную работу. Это удалось: после летней практики мне предложили остаться в IBA в разработке внутренних проектов под Enterprise-технологию Lotus Notes.

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

К моменту выпуска из университета в 2008 году я успел поработать в разных внутренних проектах, в нескольких даже в роли техлида. Главным достижением было прохождение интервью и трудоустройство на проект ИТ-гиганта IBM. Позиция разработчика Lotus Notes предусматривала широкое поле для деятельности.

Стандартный размер команды для разработки приложения 2-3 человека. На редких проектах можно было встретить команду больше. Максимум, который мне доводилось встречать - 10 человек. Для сравнения, в тот же момент времени я встречал проекты, когда над решением для Enterprise-сегмента на Java работали целые подразделения в 100 и больше человек.

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

А что вы понимаете под поиском себя?

Параллельно с разработкой для Lotus я стал пробовать себя в смежных областях. Например, среда разработки позволяла использовать для реализации некоторых задач до 4-х языков программирования: LotusScript, @-Formula, JavaScript и Java. Как-то мы с коллегой реализовали одно приложение, используя в основном Java. Клиенту было все равно, а для нас возможность попробовать что-то новое. Как выяснилось позже, проблем от такой реализации было больше, чем преимуществ, поэтому из соображений здравого смысла эксперименты мы ограничили несколькими продуктами.

Поиски продолжились, и мое внимание привлекло новое направление - Business Intelligence, больше известный как BI. Тогда только начиналось масштабное направление BI от IBM, после приобретения ими Cognos BI. Я прошел курс обучения и сертифицировался на разработчика отчетов или, как мы тогда шутили, “репортера”. Спрос на технологию был большой, каждый человек с опытом был на вес золота, но я уже работал над другим проектом. Смена проекта без достаточно веских оснований у нас не поощрялась, а вот желание помочь другим всегда получало поддержку. Так как у меня уже был опыт обучения людей Lotus на внутренних проектах, то мне предложили еще и помочь с обучением “репортеров”. Мое внимание с технологий сместилось на людей.

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

Есть такой человек-легенда, Андрей Дороничев, создатель мобильного YouTube, директор по продукту из Google. Он говорил о 4-летнем цикле карьерного развития. За это время специалист хорошо вникает в тему, разбирается, «наносит пользу» и правильно передаёт дела преемнику. Так у меня и получалось. Я знакомился с работой, получал новые навыки и бизнес-контекст, что позволяло достичь какой-то цели: переписать древнее приложение или разработать новое, обучить людей, внедрить новый процесс. Цель достигалась, и появлялось незаполненное пространство. Так я начинал новые проекты, которые в свою очередь расширяли зону ответственности.

Примерно в 2012-2013 году я понял, что как программист я уже какое-то время не развиваюсь. Появилась дилемма: сворачивать свои инициативы и нырять в море новых технологий в рамках другого подразделения или смещаться еще больше в сторону руководства. Тогда решил пробоваться в руководители проектов. Я прошел сертификацию PMI PMP, чтобы получить доступ к проектам крутых компаний. Для IBM, например, было важно, чтобы руководитель был сертифицирован. Примерно в это же время мне предложили возглавить отдел Lotus-технологии, в котором я все это время рос и развивался. После сертификации у меня появилась возможность участвовать в интервью на позицию руководителя в иностранных компаниях, и вскоре я стал отвечать за риски и разрешение нестандартных ситуациях в рамках портфеля решений IBM. Передо мной открылось новое поле возможностей. Можно сказать, что я нашел себя.

Что же вас в таком случае побудило сменить работу?

Скорее, кто. :) Один из моих коллег из минского офиса, Алексей Минкевич, хотел помочь руководителям, которые хотят стать PMI PMP сертифицированными специалистами, но не говорят по-английски. Экзамен сдать можно было и на русском, но проблема в том, что материалов для подготовки практически не было. Алексей искал сертифицированных руководителей, которые бы помогли создать симулятор экзамена с разбором вопросов. Я вызвался добровольцем, и со временем наше сотрудничество переросло в дружбу.

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

Основатели Juno - ребята, которые сделали Viber. Уже сам факт того, что будет шанс поработать с ними, был достаточным основанием для рассмотрения вакансии, не говоря уже о том, что центром разработки в Минске они пригласили Алексея. Когда поехали первые машины и появилась необходимость строить службу технической поддержки, мне предложили попробоваться, и я без раздумий поехал в Минск. Дальше все, как обычно: постановка целей, много работы и новые цели. Так я пришел в Juno первым сотрудником техподдержки с целью построить отдел, а спустя три с половиной года уходил с позиции директора минского офиса и операционного руководителя сервиса.

Зачем же в этот раз нужно было искать работу?

Я не искал. Все опять началось с сайд-проекта. Я решил получить EMBA образование и во время обучения познакомился с совладельцем Amasty, Александром Стельмахом. Мы обсуждали важность построения для компании качественной службы поддержки, и как она может стать кузницей кадров для компании. Чисто из интереса и соображений расширения личного кругозора я вызвался проконсультировать его по некоторым вопросам. Спустя какое-то время после завершения нашего обучения, Александр сделал мне предложение, от которого я не смог отказаться.

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

Да, конечно, всегда сам выступал с инициативой. Сидеть и ждать с моря погоды можно долго. Я верю в важность конструктивного конфликта. Например, когда я работал над внутренними проектами, мне поручили разработать новую функцию сбора аналитики по рабочему времени сотрудников. Решение, которое мне поручили реализовать пересчитывало большой объем данных каждый раз, когда пользователь пытался посмотреть отчет. Так как с отчетом работало высшее руководство, было крайне важно его ускорить. Я предложил разделить подготовку данных и построение отчета, но в таком случае возникали вопросы при изменении данных в уже закрытом периоде. Решение имело как минусы, так и плюсы, и вот на фоне этих минусов у меня возник конфликт с руководителем. Он не верил, что руководство одобрит подход. Я вызвался пойти и лично объяснить подход и предложить реализовать мою версию в качестве эксперимента. У меня получилось убедить руководство попробовать, и мне дали полную ответственность за внедрение нового решения. Позже человек, который отвечал за внутренние приложения, уехал в другую страну, и мне предложили взять ответственность за все направление.

Получается, конфликт – это хорошо?

Конструктивный конфликт – это хорошо. В конструктивном конфликте мы оперируем фактами, ни в коем случае не обвиняем и не переходим на личности.

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

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

Внутренние конфликты у вас тоже случались?

В 2014 году я ради интереса сходил на собеседование на позицию delivery менеджера. К тому времени я не программировал уже пару лет, занимался только управлением и организационными вопросами. Я в начале собеседования честно в этом признался и очень удивился, когда половину собеседования мне задавали вопросы из разряда: где доступ к данным быстрее – в Vector или Hashmap, как конкретно он организован в каждом случае, как выглядит запрос sql для декартова множества и что будет его результатом. Я на всякий случай уточнил, зачем руководителю знать такие тонкости. Мне объяснили, что soft skills не являются основой работы руководителя. Если руководитель не может программировать за каждого разработчика из команды, это плохо. Конечно, мы поняли, что не сработаемся.

Хотя я приверженец подхода меритократии и искренне считаю, что практикующий программист намного компетентнее меня, но я до сих пор вспоминаю то собеседование. Засел “червячок”, что знать актуальные технологии важно. Я не зарабатываю себе на хлеб программированием уже 8 лет, но всё равно продолжаю писать. Во времена Juno освоил Python и при случае решаю на нем задачи для собственных нужд.

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

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

Продолжение во второй части!