«Общался с будущим единорогом: они уволили полкоманды „старичков“ — строят бизнес без привязанности». Александр Стельмах о пути из программистов в бизнесмены

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

Dev.by обсудил с экс-разработчиком «сдвиг» парадигмы от программистского мышления (что делать?) к бизнесовому — зачем?  

Amasty разрабатывает продукты для е-коммерс платформы Magento (сейчас часть Adobe). Они улучшают работу интернет-магазинов на этой платформе в разных аспектах. Например, делают более релевантный поиск, развернутую навигацию, подробные отчеты по продажам, одностраничный чекаут. Есть технически довольно сложные (поддержка логистики на многих складах), есть простые (возможность применить много купонов одновременно). Всего таких приложений более 200. 

Александр, как вы начинали карьеру?

На третьем курсе ФКСиС БГУИР я подрабатывал в компании, которая делала военные заказы. Мне, студенту, доверили разрабатывать визуализацию для радара. С тех пор я не особо доверяю таким разработкам.

Потом была Aitoc — это одна из первых продуктовых компаний, сначала делала свою CMS, потом продукты для соцсетей, а затем продукты для е-комерса. За 5 лет я многое у команды перенял, от технических навыков до стиля руководства — там был яркий фаундер. Хотя далеко не все уроки усвоил. В 2006 году я сдал экзамен на Zend Certified Engineer, одним из первых в нашей стране, и попал на их yellow pages. И там меня стали находить клиенты и предлагать компании проекты. Для меня это было немного необычно. Я не осознавал ценность публичного профиля, репутации, нетворкинга. И вот сейчас понимаю, что этот урок так и не «выучил». У меня номинальные «учетки» в соцсетях и слабый нетворк, несмотря на стаж в отрасли и участие в конференциях и ивентах. Это мешает ряду текущих задач.

Потом ушёл в Oxagile, потому что хотел и карьерного роста, и больших проектов, а главное — более тесного общения с конечными клиентами. Работал руководителем отдела, часто бывал в Германии — ездил в командировки в Кельн, общался с клиентами — всё как и хотел. Но со временем понял, что аутсорсинг не моё. А вот е-коммерс — как раз то, в чём я уже неплохо разбираюсь, хотелось ещё больше понять эту область. 

Кто-то думает, что люди из е-коммерса — спекулянты, «продаваны».

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

В итоге в 2012 году вместе с партнёрами мы открыли компанию Amasty с офисами в Минске, Братиславе, Лондоне. Сейчас в компании работает более 100 сотрудников, тысячи клиентов по всему миру. Мы делаем приложения, которые улучшают и оптимизируют работу интернет-магазинов на платформе Magento. Нашими продуктами пользуются как небольшие SMB компании (их большинство), так и крупные enterprise клиенты. Например, Blizzard использует систему для учета продуктов (физических сувениров, связанных с их играми) в разных локациях, а Nestle формирует скидки и акции в том числе с помощью нашего приложения. 

Вообще корпорации — очень сложные клиенты. В том же Nestle огромное число подразделений. Часть из них используют Magento, часть Shopify. Одни представительства работают с нами, другие выбирают наших конкурентов, третьи разрабатывают сами. Большой вызов для нас — научиться работать с такими структурами. Причём это некоторая общая проблематика отрасли. Тот же Slack, если вы посмотрите его проспекты и описание бизнес-модели перед выходом на биржу, как раз видит потенциал роста в энтерпрайз сегменте, где их позиции довольно слабые. Да, есть мнение что «корпораты» — это что-то бездушное и неповоротливое. Но в то же время это серьёзная «точка опоры», которую просил Архимед, чтобы повлиять на мир.

Однажды нам написал благотворительный фонд из Африки (не вспомню сейчас какой), они использовали Magento не как магазин, а как систему для сбора пожертвований. Мы просто подарили ему несколько модулей. Интересно было общаться и с представителем знаменитого лондонского музея естественной истории, тем, что со скелетом динозавра. Мы им тоже бесплатно выслали приложение (по расчёту доставки, в Англии запутанная система почтовых индексов), хоть там благотворительностью и не пахло — продавали сувениры.

Получается, после вуза вы поработали в компании Aitoc, которая разрабатывает расширения для Magento, — а затем основали свою компанию Amasty, которая делает аналогичные решения. То есть вы набрались опыта и основали конкурента?

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

Сейчас Amasty работает только с Magento, разрабатывая приложения именно для этой платформы. Я не вижу сейчас ни одного значимого конкурента в этой области. Но существуют же специализированные сервисы под конкретные задачи, скажем Abandoned Cart Recovery или Rewards. Каждый из таких сервисов работает со всеми платформами: и с Magento, и с Shopify и с BigCommerce, и с WordPress и с Wix и прочими. У них больше фидбека от клиентов, больше охват аудитории и в то же время больше глубины и ценности. «Бодаться» с такими решениями гораздо сложнее, но в то же время полезнее и для нас и конечных клиентов. Существует мнение, что специфический продукт, технология, фреймворк имеют шанс. Тот же uber и яндекс.такси, twitch и недавно закрывшийся youtube gaming. Дальше зависит от нас, воспользуемся ли мы этим шансом.

Название компании — это же не отсылка к Amnesty international?

Мы хотели, чтобы название было на букву «А», достаточно популярная стратегия — А100, Amazon. Подбирали благозвучный набор букв, но не аббревиатуру. Придумали Amasty, и всё было классно.

Для меня как программиста название вообще не имело значения — просто чтобы знать, как классы в коде называть. Но потом оказалось, что есть такая организация Amnesty, которая занимается правами заключённых.

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

Почему ушли из аутсорсингового бизнеса, который стартовали в 2010 году?

Для меня это был, наверное, самый сложный проект в моей жизни.

По сути, это первый опыт создания и развития компании с нуля. Раньше были просто проекты (более или менее сложные) в готовой инфраструктуре: офис, стабильная зарплата, куча помощников-смежников (hr ищут специалистов, qa тестируют, дизайнеры рисуют, маркетологи продвигают, аккаунт менеджеры закрывают счета и т. д.). Ну и, наверное, ценность этой поддержки я тогда в полной мере и осознал. Собственно кодирование занимало немного времени, а вот координация оказалась не такой тривиальной, когда пришлось ей заняться самому. Хотя все проекты я начинал с партнёрами, и это немного облегчало дело. Я и до сих по ценю командную работу. В нашей текущей компании Amasty много самостоятельных команд и рабочих групп, а структура довольно плоская.

Я как СТО и эйчар по совместительству написал фреймворк, на основе которого мы делали аутсорсинговые проекты, и построил распределённую команду — сейчас это уже норма, а раньше было ноу-хау. Это была совсем маленькая команда, 7 или 8 человек из разных городов Беларуси, большинство ребят из Минска. У нас не было офиса, но был общий чатик (почивший уже icq) и борд с проектами/задачами (вроде живой еще redmine). Слёты у нас были в кафе, разрабатывали проекты итерациями, но не называли это словом Agile.

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

Я просто сказал: «Ребята, я всё вам оставляю, мне ничего не нужно».

Компания продолжила существовать, а я пошёл дальше.

Если честно, звучит не очень правдоподобно: оставить свою компанию со словами «Ребята, мне ничего не нужно». Что на самом деле случилось?  

Да так все и было, просто без подробностей действительно выглядит странно. Ну вот сделали пару проектов, в оценки где-то попали, где-то нет.

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

Итак, вы фаундер с техническим прошлым. Как оно даёт о себе знать?

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

Опишите этапы жизни компании, когда вам как экс-программисту приходилось особенно непросто.

Настоящая тряска была, когда переходили с версии Magento 1 на Magento 2. Дело в том, что они сильно отличались, и мы переписывали всё, что сделали за несколько последних лет, в авральном режиме. В этот момент мне приходилось говорить: «Ребята, я понимаю, что мы сейчас делаем ерунду, но нам нужно, чтобы этот продукт был первым в маркетплейсе». И стратегия сработала, мы вышли одними из первых, это дало нам ресурсы для развития.

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

А в какой момент вы «доверились команде», с чем связана эта перемена?

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

Осознать это — первый шаг. Потом я постоянно хожу, смотрю как у других, что в других компаниях, как решают похожие проблемы роста и масштабирования. А когда есть запрос, то находятся и ответы. В том числе через обучение. Я постоянно учусь — управление проектами (хотел одно время сдать экзамен pmi), создание продуктов (разные курсы), скрам (Кривицкий), коучинг (Дернаковский). Кстати, очень рекомендую Stratoplan — школу Славы Панкратова (ex Яндекс) и Александра Орлова (ex Intel) в плане коммуникаций. У нас ее прошли все руководители отделов, а потом и многие тимлиды, и это сформировало определенный общий язык решения проблем.

Сейчас для меня лучший фидбек — это «Саша, мы тут без тебя, лучше не вмешивайся».

Это значит: а) человек уверен в своих силах и результате; б) знает, что делать; в) отношения в команде доверительные, а значит, проблемы не будут замалчиваться. Таким образом, у меня лично появляется время на другие, более общие проекты как внутри (кросс-командное взаимодействие, процессы), так и на рынке (тут ничего не буду рассказывать, пока рано), так и связанные с технологиями. Например, сейчас у нас ни в одном продукте не используется машинное обучение, это явный минус, который нужно исправлять.

А вообще я не помню и дня, когда было легко. Компания растёт, и всё меняется. Когда в команде до 10 человек — это одни процессы, до 40 — другие. Когда становится больше 50 — вообще непонятно, что делать. Я пошёл на MBA, думал, может, там знают, но и там готовых рецептов не дают.

А что там дают, на MBA?

Кругозор сильно расширило, помогло понять бизнес клиентов глубже. Познакомился со многими замечательными людьми, например, Сергеем Дерцапом из Juno, Юлей Мурашко из Altoros и Андреем Цыганом из ИзиШтандарт. Не говоря про большое число людей вне ИТ. В целом я разделяю мнение, что до определённого момента MBA не сильно полезен. Поэтому доволен, что не пошёл туда раньше, пока компания была меньше. Еще один вывод, которые я сделал (точнее прочувствовал, обсуждая рабочие ситуации с одногруппниками: в) сложность работы и сложность бизнеса мало связаны с финансовым потоком. В моей группе были люди, решающие намного более сложные задачи, чем я, с гораздо меньшей финансовой отдачей, и наоборот.

В итоге пришлось думать самим, вместе с управленческой командой, и, похоже, придумали хорошо. Мы достигли отметки в 100 человек, и это совсем не та компания, что была в начале пути. Она, с одной стороны, становится мощнее, а с другой, неповоротливее. И вроде бы все всё делают хорошо, но вкупе хотелось бы лучшего результата. Это как броуновское движение — когда нет упорядоченности, получается замедление. Поэтому, если у нас появляются какие-то новые направления, мы не смешиваем их с существующими, а выделяем в отдельные компании.  

Вы создаёте внутренний топ-менеджмент, «выращивая» текущих сотрудников компании, или хайрите со стороны?

Мы стараемся не брать менеджеров со стороны и предпочитаем, когда сотрудник растёт внутри компании. Если компании приходится привлекать кого-то со стороны, это значит, что у неё не было кадрового резерва. Или рост очень быстрый. Другое дело — когда вы выходите на новые направления и привлекаете специалиста, потому что у вас нет необходимой экспертизы. Мы можем сами постигать новую область, но на это уйдёт много времени, а можем позвать эксперта, который поможет. Так, например, у нас было с sales направлением. Кстати, забавный случай. Наша HR познакомилась с девушкой в очереди в поликлинику, ну и пошло-поехало. А очень опытного руководителя bizdev отдела мне как-то по-знакомству посоветовал приятель из EnCata (вот и нетворкинг аукнулся). Там как раз чудом был перерыв между проектами (какой-то стартап закрывался, а новый не открылся).

С текущим руководителем front-end команды столкнулся в электричке — ехал из Гомеля, с дачи, небритый. Вижу, человек книжку читает по JavaScript.

Обсудили (я послушал больше) про оптимизацию памяти, ну и как-то сложилось. Знаете, за каждым человеком история стоит. Я же в большинстве собеседований, пока нас было меньше, сам участвовал.

Сталкивались с проблемой сложности поиска технического топа в Минске? 

Давайте прямо назовем поиск «хантингом». И в чем тогда проблема? В Минске достаточно технологических компаний. В каждой из них хватает крутых специалистов, разных стеков технологий. Будет ли ваша команда, атмосфера, ваш проект, ваши задачи и условия в совокупности интересны этим людям, зависит же от вас. Нет интереса к вашей технологии? Можно жаловаться. А скажем, Валерия Коваленко из Qlean прямо сказала (по памяти цитирую): мы выбрали переход на react native как нашу — внимание! — HR стратегию.

Вы никогда не привлекали инвестиции для своей компании. Почему?

Это скорее было моей ошибкой. У нас долгое время была компания семейного типа. Но нужно ведь понимать, мы вообще про что: про семью или про бизнес? Люди ведь хотят повышения зарплаты, карьерного роста, а для этого должен расти бизнес. Мало пить чай и есть тортик со всеми. Сейчас я, конечно, привлекал бы деньги, потому что появился венчурный рынок, стало больше акселераторов, фондов. Но в том, что мы этого не делали, тоже есть плюсы: ты сразу думаешь о том, чтобы построить прибыльную компанию.

Михаил Дубаков говорил, что если бы рассмотрел вопрос привлечения инвестиций в 2010-2011, а не 2018 году, компания была бы в три раза больше. В какой период, по-вашему, стоило привлечь инвестиции, какие суммы? Думаете ли сейчас об этом?

Да, однозначно нужно было быстрее растить техническую команду с самого начала, в 2012 или даже раньше. Рынок сильно рос, были т. н. «ранние последователи», им был важен продукт. Мы сильно тормозили с ассортиментом. Не хочу загадывать, во сколько бы раз выросли, история не терпит сослагательного наклонения. Инвестиции минимальные требовались — сотни тысяч. Второй этап прозевали не так давно, в 2015, там уже маркетингового бюджета не хватало. Там речь о суммах до миллиона. Та самая пропасть между «ранними последователями» и «большинством» в модели Мура. Тогда «smart money» особенно бы пригодились. Ну и кроме финансовых инвестиций, есть же еще инвестиции времени. Я вот женился. А в это время Shopify начал бурно расти. Но мне было не до того.

Если привлекать инвестиции сейчас, то скорее от стратегического партнера, который сможет использовать текущую базу клиентов намного более эффективно, чем это делаем мы.

Расскажите о текущем положении дел в компании.

Компания постоянно рaстёт: как по продуктам, так и по выручке. Но я вижу замедление темпов из-за сложности координации.

Что это такое?

Классическая проблема, ее еще Сенге в «Пятой дисциплине» описывал. Рост численный без усиления процессов (будь то формализация или в другую сторону децентрализация) замедляет развитие. Про это же классический закон Брукса — добавление новых разработчиков в проект на финальной стадии только отодвигает сроки. Зная все это, над процессами как раз и работаем, возникают все чаще упоминания ITIL, SIPOC, и прочих сокращений. Причем я придерживаюсь взгляда, что нужна минимально необходимая (но не меньше) формализация. В программировании есть похожий принцип «преждевременной оптимизации», но вот у нас уже пора.

Сейчас пробуем новую модель — перевод части продуктов на SaaS модель. Первая ласточка — calcurates.com. Для нас это возможность использовать и другой стек технологий, и другие подходы к работе с клиентами. Ведь сейчас большинство продуктов мы устанавливаем прямо на сервера клиентов, что с одной стороны позволяет их сильно кастомизировать, с другой — усложняет поддержку. Это выход за рамки старых технологий и способов привлечения клиентов. Как компания мы постоянно пробуем что-то новое, отправляем своих лидов на конференции, проводим стажировки и внутреннее обучение, привозим специалистов по Growth Hacking и пр. Например ребятам очень понравился Юрий Дроган из московской GrowthAcademy. Мы не cделали из этого PR-акции, как Apalon, но мы учимся. Многие ездили в Киев к Алексею Кривицкому (Scrum Ukraine), приходил к нам и Юрий Шиляев из WorkFusion, рассказывал про свой конек — эффективность. Я бы позвал кого-то из EPAM’a с курсом Intro to Management (хорошие отзывы), но вроде это их внутренний продукт, если в онлайн не выложат, то придётся самим делать.

Ищем оптимальный путь развития, возможностей сейчас много, но гнаться за 10 зайцами нет смысла, нужна глубина.

Вы упоминали, что было всякое: «и с партнёрами ссорился, и сотрудники воровали». Давай остановимся на последнем. Это как — технику, код, интеллектуальную собственность?

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

Однажды я решил ввести систему поощрений за быструю обработку запроса из техподдержки. Намерение прекрасное. Во что это вылилось? Разработчик понял, что его KPI зависит от количества запросов, и, делая фикс проблемы, перестал заливать его в обновление. Просто давал юзеру патч, а потом следующему. И получалось, что девелопер наращивал свой бонус, а продукт лучше не становился. Вот вам управленческая ошибка: я как менеджер придумал архитектуру, которая стимулирует худшее качество продукта. Если в организации есть что-то нездоровое, нужно смотреть на менеджмент. Про это хорошо рассказано в книге «Nudge. Архитектура выбора» Касса Санстейна и Ричарда Талера: она про то, что построение неправильной архитектуры в компании провоцирует не совсем адекватные действия людей.

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

В каждой компании «правильная» архитектура своя. Я сейчас в Киеве общался с фаундером компании, которая метит в единороги. Там на определенном этапе уволили половину команды «старичков». Чтобы бизнес был бизнесом и не было эмоциональной привязанности. В то же время помню свои ощущения от московского ФРИИ акселератора. Там потрясающая энергетика. CEO образовательного проекта, который мне сделал мини-экскурсию, рассказывал, как люди спят в офисе, потому что «движ и все в огне, некогда ездить по пробкам». У всех по разному.

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

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

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

Есть ли в планах сделать из хорошей компании великую?

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

Я рассматриваю компанию как продукт: в эйчар-отделе не хватает каких-то фичей, UI в соцсетях не дружественный, в матрице компетенций нужно что-то допилить, а рефакторинг на людях — это вообще очень тонкое дело. Такой подход открывает новые перспективы, и уже хочется делать не великий продукт, а эффективный.

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

А какие принципы корпоративной культуры могут быть позаимствованы для семейной жизни?

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

В отношения минус. Как вариант, можно было дать обратную связь «как на работе»: безоценочно, с фактами, выводами, проговариванием своих эмоций, поиском путей решения. «Дорогой, мы договаривались, что ты будешь дома к 6. Сейчас 7:15 и ужин остыл. Я волновалась и переживала и от этого злилась, потому что телефон не отвечал. Что случилось? Что мы можем сделать, чтобы избежать такой ситуации в следующий раз?» Да, может быть звучит слегка искусственно, потому что письменная речь не передает эмоции. Да, это требует самообладания и искреннего желания исправить ситуацию. Но ведь так отношения и строятся — что в семье, что на работе. Через совместный труд, уступки, разрешения конфликтов. У меня, может быть, тут масса примеров. И с системным мышлением (виноват процесс, а не человек «мудак»), и с решением проблем — сначала решаем, потом узнаем, как так произошло, потом думаем в спокойном режиме, что подправить (а можно же начать с поиска виноватых), и с agile культурой, и прочее, и прочее.

Стремитесь ли к 1 проценту текучки, как некогда у PandaDoc (но уже нет)?

Нет. Урок, который я извлёк: текучка, это — естественный процесс, и не нужно гнаться за её минимизацией. Команда всегда будет динамической, просто нужно строить архитектуру так, чтобы всё работало даже после ухода одного-двух ключевых сотрудников. К слову, у нас есть другой показатель, на который мы равняемся — время ввода (обучения) нового сотрудника. У каждого руководителя отдела есть KPI по обучению новых специалистов, который подразумевает наличие понятных материалов, план обучения и пр.

Важно понять, как считать текучку. Мы даем возможность многим людям попробовать себя в новой профессии, «войти в IT» — это позиции в техподдержке, QA, jun dev (через стажировку), копирайтинге, продажах. Далеко не все проходят испытательный срок. Но это ожидаемо. И это не текучка. Хотя люди вроде бы приходят и уходят.

Если же человек завершил испытательный период (3 месяца) и на 5-8 месяце увольняется или мы его увольняем — вот тут проблема, и это проблема компании. Мы с этим сталкивались в некоторых отделах. В качестве решения стали больше обращать внимание на личные качества человека и меньше значения придавать начальным скилам — все равно научится. Сейчас такой текучки практически нет. А у каждого из руководителей отделов есть свой срок на обучение новичка. Самый короткий — в техподдержке. За две недели человек осваивает платформу, знакомится с продуктами компании, учится работать с ssh и т. д.

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

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

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

Чувствовали, что выгораете?

Было и такое. Мне нравится бежать, правда, нужно делать паузы, иначе легко себя загнать. Стартап — это работа по 12 часов в сутки. Я три года не был в отпуске и на выходные тоже не ходил. Днём занимался управленческими делами, с 8 до 9 вечера был в техподдержке, потом наступало время, когда можно было подправить что-то в архитектуре кода, на выходных делал большие фичи. Наркоманский какой-то кайф. Но в таком режиме долго не протянешь. Наступил момент безразличия, когда уже ничего не хотелось. Я всех предостерегаю не попадать в эту ловушку. Компания — это марафон, а не спринт.

Что я сделал? У меня была мечта побывать на всех континентах, и я почти её реализовал, только в Южной Америке не был. А в тот момент, чтобы перезагрузиться, поехал с друзьями в путешествие по Африке. Кульминацией поездки было восхождение на Килиманджаро. Я абсолютно не спортивный человек, и для меня это был вызов себе, вдобавок я тогда заболел. И несмотря на то, что подъём был лёгким, для меня он оказался ужасно сложным. Буквально за несколько метров до вершины я понимаю, что сил совсем нет. Но товарищ говорит: «Ну, ещё немного». Я собрался с силами, и второе — точнее, уже сто второе — дыхание открылось. В тот момент я понял, что воля сильнее, чем тело. Я дошёл, отметился, спустился. Но то ощущение на горе пошло со мной по жизни — не сдаваться, когда тяжело, ведь цель всегда очень близко.