Всем привет. Ко мне в онлайн-гости на интервью зашел Александр Афенов — руководитель направления разработки в Lamoda. Пообщались про онбординг, тимлдиство в Lamoda, devrel и другое.
Интервью было в формате онлайн-трансляции на YouTube — запись доступна по ссылке. Также можно послушать в формате аудио-подкаста. Ну а под катом расшифровка интервью.
Вопросы задавал не только я — зрители трансляции писали свои вопросы и я их озвучивал — такие вопросы помечены как (Youtube).
Про Сашу
Зовут меня Александр, я отвечаю за одно из направлений, которое специализируется на добывании новых денег в Lamoda — подключении бизнес-партнеров и их поддержке.
Как и когда ты оказался в Lamoda?
В Lamoda я пришел в декабре 2015. До этого я порядка 6 лет работал в телекоме: в том числе занимался разработкой сервисов техподдержки в провайдере NetByNet. После того, как туда зашел Мегафон, стало “больно” из-за процессов интеграции, поглощения и всего остального и, в итоге, я ушёл.
Следующие 4 года занимался, стыдно сказать, “музыкой вместо гудков”. Писал там на PHP и немного на Java. В какой-то момент понял, что меня напрягает модель бизнеса. Очень часто приходилось продавать несуществующий продукт в рамках тендеров и потом пилить его в сжатые сроки.
Первая попытка уйти была спустя 1,5 года после начала работы, в 2013 г. Я сходил на собеседование в Lamoda, там всё прошло отлично, но я отказался — на текущем месте перекупили, в основном, из-за bus factor (это впоследствии стало причиной моей постоянной борьбы с bus factor в своих командах).
Ещё какое-то время я там проработал пока не понял, что развитие там мне не интересно — из чисто разработчика я стал фуллстеком не в самом лучшем его понимании (аналитик, QA, техменеджер и т.д). В этот раз деньги меня уже не удержали и я снова пришёл в Lamoda, где работаю до сих пор.
Как проходил твой рост внутри Lamoda?
Есть гипотеза, что находясь на уровне мидла полезно понять, куда ты хочешь дальше расти — копать в техническую часть или же больше работать с людьми. Я за 9 месяцев дорос до senior и пробыл им довольно недолго. В один момент мой тимлид понял, что позиция техлида ему интереснее и перешел туда и позиция тимлида освободилась. К тому времени я уже прокачал свои софт-скиллы, участвовал в разных активностях, начал выступать с докладами и понял, что это можно хорошо использовать на позиции тимлида.
Про Lamoda
Тимлидство в Lamoda
Стать тимлидом может же не каждый, кто захотел? Как выстроена система роста у вас?
Чтобы стать тимлидом, как минимум, нужна команда:) В целом подход такой, что текущий тимлид старается готовить себе минимум одного преемника. У меня есть кейс, когда я на протяжении долгого времени одного из разработчиков старался привлекать к тем или иным активностям и начал понимать, что он, в случае чего, будет тимлидом команды. Я об этом не стеснялся рассказывать внутри компании и, в результате, его сделали тимлидом в другой команде, а я был вынужден снова готовить себе замену.
Мне самому предложили стать тимлидом. Сначала дали должность младшего тимлида, испытательный срок был 3-6 месяцев. По результатам испытательного срока ожидалось, что в команде, как минимум, не должны сломаться процессы, не должны уйти люди. Младший тимлид должен суметь сохранить все аспекты жизнедеятельности команды и не допустить ухудшений.
По поводу Performance Review. Как вы оцениваете человека, если он заявил, что хочет стать тимлидом?
У нас не очень часто разработчики заявляют о таких желаниях. Бывали ситуации, что мы нанимали тимлида снаружи и в процессе работы понимали, он не подходит — приходилось либо расставаться после испытательного срока, либо переводить его на позицию разработчика. В целом найм тимлидов снаружи у нас практикуется довольно редко. В команде есть свой проект, опыт и приход человека извне неэффективен — уходит много сил и времени, чтобы нарастить экспертизу, выстроить отношения и т.д.
Насчет метрик — у нас есть система, но не жестко формализованная. Человек время от времени получает разные возможности проявить себя. Есть институт виртуальных ролей — саппорт инженер, дежурный и техлид. Это возможность для любого разработчика в команде взять себе в работу проект и взять на себя ответственность за его архитектуру, технические решения, процесс запуска, code review и т.д. Он не управляет ресурсами — он остается на той же позиции, но отвечает за этот конкретный проект. Для него это отличная возможность проявить тимлидский потенциал и в будущем занять это место в команде.
(YouTube) Есть ли у вас KPI по разработчикам?
Какого-то явного KPI у нас нет. Есть внутренние ожидания по результатам. Тимлид по каждому разработчику четко понимает, что нужно, чтобы с высокой вероятностью получить высокую оценку по performance review. KPI с точки зрения строк кода, разумеется, нет.
Мы мониторим вопрос оверлогов чтобы понимать, как хорошо мы описываем и планируем задачи. Если случился масштабный оверлог, то на ретро поднимается вопрос, что пошло не так. Я иногда обращаю внимание на то, как часто менялось описание задачи. Если оно менялось десятки раз то оверлог, скорее всего, это не главная проблема разработчика.
Также иногда смотрим количество коммитов, комментариев и активностей во внерабочее время. Это чаще всего говорит о том, что человек не успевает что-то в рабочее время и такое часто приводит к выгоранию, стоит обращать на это внимание.
Каким образом ты стал “тимлидом для тимлидов”? У тебя также был наставник, на чье место ты пришёл?
Надо мной было “безвоздушное пространство”. У нас есть два больших блока:
- online shop: все, что выходит на конечного клиента и связано с сайтами, мобильными приложениями и так или иначе обслуживающими их сервисами;
- бекенд, который занимается автоматизацией бизнес-процессов. Этого пользователь напрямую не видит (склад, b2b и так далее).
У каждого блока свой руководитель, они подчиняются напрямую СТО.
Раньше тимлиды были в прямом подчинении у руководителя, но их становилось всё больше и больше, коммуникации стали усложняться и мы изменили структуру.
Выделили команды, которые работают над одним направлением бизнеса и объединили их в дирекции. Так появилась коммерческая дирекция, которая занимается направлением B2B и я занимаю место её руководителя.
(YouTube) Как вы растите тимлидов внутри компании? Они проходят какое-то централизованное обучение или все происходит стихийно?
На текущем этапе есть два слоя обучения — внутри команды, когда текущий тимлид растит себе замену и целенаправленное обучение тимлида, который уже занял эту позицию.
Раньше у нас были курсы по управлению (без упора конкретно на тимлидство), на которые сотрудники выезжали учиться. Тренинг был довольно полезен, но оторван от специфики разработки в IT.
Сейчас система другая — у нас есть внутренний курс для тимлидов, который охватывает все проблемы, начиная с: “Я тимлид и что мне делать дальше” и заканчивая особенностями проведения performance review у нас в компании. Рассказывается о проведении собеседований, увольнении, правильной подаче обратной связи и так далее. Длительность одного модуля около 8 часов, есть теоретическая часть и практическая — разборы кейсов. Кроме этого есть поддерживающий чатик с участниками курса, где люди делятся полезными материалами по теме курса. Курс проходит волнами, сейчас как раз будет запускаться очередная волна для текущего набора тимлидов.
(YouTube) Тимлидов берете только с техническими скиллами?
Это довольно глубокий вопрос, и его обычно начинают с вопроса “Какое у вас соотношение программирования и people management?”. Нам нужны технические скиллы у тимлида, но если у него будут только они, то это уже архитектор, который скоро перегорит от коммуникаций с людьми и сдвинется в техлидство.
Есть команды, в которых техлид и тимлид — один человек. Это достаточно опытный разработчик, который знает как устроена система и он продолжает поддерживать свою экспертизу, но двигается сторону people management — занимается ростом, развитием, performance review и решает вопросы около проекта.
(YouTube) Может ли команда уволить тимлида?
Такого кейса у нас не было. Я общаюсь с разными командами, чтобы понимать какая там атмосфера. Выстраивание прозрачной обратной связи дело очень непростое. Команда может подсветить проблемы, сообщить о них руководителю тимлида или поговорить с HR BP.
К HR BP как раз приходят с какими-то внутренними проблемами которые не могут решить сами. Например, ты в обиде на тимлида, находишься в состоянии войны с ним и хочешь как-то решить проблему. Ты обращаешься к HR BP, а он, в свою очередь, делает все, чтобы максимально аккуратно все потушить.
Если тимлид делает какую-то дичь, а его руководитель этого не видит, то, конечно же, каналы для донесения этой информации есть.
(YouTube) Что делать команде, когда она замечает, что их лид начинает выгорать, а сам отшучивается, что “все норм”?
Мы говорим о кейсе коллективной ответственности, когда вся команда должна быть тимлидом. Все зависит от того, как тимлид поставил себя для команды. Бывает в команде есть достаточно сильные люди, которые видят, что они могут забрать какие-то активности у тимлида.
Если у команды не получается ни прямым разговором, ни намёками дать понять тимлиду, что у него что-то не получается, то можно подключить HR BP, который с ним поговорит.
В докладе про онбординг я говорил, что печально, если тимлид сильно отстает от команды и к нему отношение как к какому-то мегаруководителю. Если он часть команды, то будет получать ту же поддержку, что и остальные. Чем он “ближе к народу”, тем больше шансов, что ему будет оказана поддержка.
У тебя есть доклад “Трудно быть Колей”, где ты рассказывал как у вас происходит шаринг знаний. Ты сам доволен как выстроен процесс онбординга новичков?
С каждым разом все лучше. Появилась очень хорошая история с бадди — человеку помогает не кто-то отвлеченный, а человек прямо из команды, который поддерживает тимлида и является товарищем для нового сотрудника. Бадди помогает с бытовыми аспектами и помогает познакомиться с системой.
Это усилило наш процесс онбординга. В докладе на Стачке я говорил, что у нас есть чек-листы и именно с ними в IT онбординг заходит очень хорошо, т.к. они позволяют увидеть план того, что мы ждем от новичка и регулярно трекать прогресс.
Часто онбординг является несистемным и отдается на откуп тимлида, а тимлиды все разные. Сейчас мы стараемся этого избегать с помощью формальных чек-листов, регулярных встреч с новичками и вообще следования более-менее формализованному и описанному процессу онбординга.
Выстроен ли у вас как-нибудь процесс оффбординга и передачи знаний на этом этапе?
Сохранять знания на этом этапе провальная идея. Человек, даже будучи лояльным к своему тимлиду, не рассказывает ему о возможном оффере заранее из-за страха подрыва доверия в том случае, если по каким-то причинам он решит остаться в команде. Из-за этого часто складывается ситуация, что увольняться человек приходит с оффером, потому что ранее ему было неудобно сообщать о своих намерениях. После этого убедить сотрудника оставить после себя какую-то документацию проблематично — нет мотивации.
О процессе передачи знаний лучше говорить с другого угла — техлидство, кранчи и так далее. Если говорить именно о процессе оффбординга, то первое, что активируется — режим удержания. Если мы можем как-то повлиять на его решение, то мы это делаем — составляем конкретный план. Такие ситуации бывают и работают регулярно.
Я слышал мнение, что давать людям контроффер бессмысленно. У вас эта практика работает? И после возвращения работа была построена эффективно?
Такие кейсы бывают и бывают достаточно часто. Мы пытаемся всегда. Я сам проходил через подобное — у меня пару лет назад было желание уйти просто в программирование. Я пообщался с руководством и в нормальном диалоге мы выяснили, что именно не так, и это удалось исправить. Я работаю тут до сих пор.
Удержать локально, даже деньгами, не эффективно. Если мы “удержим”, то человек, скорее всего, через пару месяцев или полгода всё равно уйдет. А если удается установить в чем именно причина и устранить её, то можно продолжить эффективную работу, как это было со мной. Это вопрос выделения ресурсов на решение боли этого человека.
(YouTube) Как быть с тем, что не всегда разработчики делятся знаниями по умолчанию?
Я бы соврал, если бы сказал, что у нас этот процесс выстроен идеально. Тут есть несколько направлений, которыми мы пытаемся это закрывать. У нас есть институт аналитиков, который работает не только над проектными историями, но и занимается тем, что было сделано раньше, но почему-то не было задокументировано. Это касается крупных элементов.
В прошлом году мы нарисовали схемы (sequence diagram) по всем ключевым бизнес-процессам и взаимосвязям между ними, в каждую схему вошли десятки систем, которые взаимодействуют друг с другом например для того, чтобы оформить или подтвердить заказ клиента. Это документация, которая была сделана постфактум, но зато она актуальная и удобная.
У сервиса Lamoda довольно высокая нагрузка и архитектурно он распилен на микросервисы. Оверхед поддержки такой архитектуры стоит того?
По большей части я застал этот распил. Всегда есть светлые и темные стороны. Думаю, что мой опыт слабо репрезентативен, т.к. я работал, в основном, с гигантским монолитом. Я не буду утверждать, что мы всю дорогу едем по принципам DDD, но во многом стремимся. Например у нас есть сервис Order Processing и он, по непонятным причинам, решает задачи синхронизации стока между складами сайта, а ему это знать не нужно — достаточно знать о стоке только на этапе подтверждения заказа или его отмены.
При этом он решает чужие задачи. В нем есть интерфейс для управления шаблонами отправляемых пользователям смс. Если мы, по какой-то причине, захотим изменить то, что отправляется пользователям в СМС, нам нужно будет перелить в прод двухтысячный монолит, который процессит все заказы. Сейчас, в кубе с health-чеками и т.д., все работает хорошо, но раньше это было очень страшно.
Хотелось бы, чтобы появлялись сервисы, который решают свою, пусть не самую узкую, задачу. Необязательно, чтобы это было прям микро-микросервис. Важно, чтобы было разделение на уровне домена. Подход такого разделения позволяет фокусировать команды на каком-то одном домене.
Стоит ли этого того? Строго да. Вдобавок к бонусам могу добавить, что во время распила какого-то старого сервиса решается проблема технического обновления старого сервиса. Мы решили уже кучу проблем за счёт этого.
Ты сейчас тимлидов у тимлидов. Но ты сам кодишь?
Да, но в основном это саппортные истории и пет-проджекты вне основной работы.
Как поступать с блокирующими задачами, которые висят на тебе?
История простая — попадать в такие ситуации крайне нежелательно. Задачи, которые можно взять, имеют не срочный характер. Например, я знаю, что у нас есть интерфейс управления отправкой СМС и я знаю, что он работает плохо и нет срочной задачи по улучшению этого блока. Я в спокойном режиме дорабатываю ее и никого не блокирую.
Если я не могу гарантировать, что я сяду и сделаю задачу в срок, то не имею права ее брать. Основная задача тимлида — не влезать в такие ситуации.
Недавно был кейс, когда мне пришлось подключиться к инфраструктурным задачам. Большая часть была сделана до меня, и мне было это интересно с позиции “прокачать себя” и заодно решить проблему, на которую в ближайшие пару недель у команды точно не будет ресурсов. Без этого задача просто стояла бы на месте, если бы я не подключился.
Также подключаюсь, когда счет идет на минуты. Например, когда на дежурстве что-то упало и нужно сделать некоторые правки, чтобы все заработало — тут странно отказываться, если ты можешь.
Поддержка в Lamoda
Как выстроена поддержка работоспособности в Lamoda? Как юзер я понимаю, но мне интересно что происходит на вашей стороне.
Звонки клиентов обслуживает контакт-центр и эта информация дальше переходит в нашу службу поддержки. Под большинство случаев есть набор инструкций куда и с какой проблемой можно обращаться. Также по каждому направлению есть информация о текущем дежурном.
Если задача не срочная, то она попадает в доску в Jira, которая потом разбирается саппорт-инженером в рабочее время. Если что-то срочное, то ставится задача дежурному и он садится решать проблему вне зависимости от времени суток.
Сколько у вас дежурных?
В один момент времени один дежурный. Например, сегодня последний день моего дежурства — я периодически дежурю, чтобы оставаться в курсе происходящего с системой.
Дежурный должен быть в курсе всей системы? Получается им может стать только опытный разработчик, давно работающий с системой?
Бывает по-разному. Дежурными обычно становятся не ранее чем через полгода после трудоустройства и только по желанию. Дежурство может стать инструментом обучения — дежурный будет “прокси” к более опытному сотруднику и уточнять то, что нужно для решения проблемы.
Через совместное решение дежурный обучается. В идеале, последствия решения проблемы и информация об устранении фиксируется в Confluence.
Постепенно из “прокси” он превращается в полноценного дежурного. Каждая последующая проблема — новая, и далеко не каждый раз есть универсальное решение.
Если находится баг прямо на проде — дежурные могут деплоить напрямую?
Мы всеми возможными способами стараемся такую возможность исключить. Если такое всё же произошло, придерживаемся стандартного процесса — кроме дежурного, который внес изменения в код, будет привлечен, при необходимости, QA и другие. Релизит обычно не тот, кто писал код — это наше внутреннее требование, выработавшееся после многих проб, ошибок, аудитов и так далее…
(YouTube) Тимлиды тоже дежурят? Мы для себя поняли, что дежурство тимлида негативно сказывается на процессах
Я за то, что тимлид не дистанцируется сильно от команды. Если он участвует в дежурствах, то он хорошо понимает, что происходит в системе в рамках ее эксплуатации. Я считаю, что тимлиду даже важно и необходимо иногда дежурить, если он хочет оставаться в курсе происходящего. Он может дежурить меньше, чем остальные, но совсем игнорировать этот процесс у меня желания не возникало никогда.
У нас достаточно сложный проект и как раз таки дежурство, code review и другое позволяет тимлиду оставаться в теме.
(YouTube) Со стороны инфраструктуры у вас есть дежурные? Когда проблема не в бизнес-логике, а на продакшене. Или когда граничная проблема.
У нас ops команда со своими мониторинги. Есть инструкции кому по какому поводу звонить и у команды ops всегда есть свои дежурные. Если, например, у нас разваливается реплика, то мы звоним дежурному — он подключается и решает проблему.
У дежурных от разработки есть прямой доступ к базе данных, но строго на чтение. Если регулярно возникают проблемы, требующие прямого вмешательства в базу, то мы на ретро разбираемся, делаем кнопку, которая реализует тот же функционал и больше напрямую в базу не ходим.
Про карантин
Сейчас времена не простые. Как выживаете в карантин?
Работаем удаленно. В офисе люди тоже периодически бывают, но, по мере развития эпидемии, людей в офисе становилось все меньше и меньше. Например из моих команд сейчас в офисе никого нет.
У вас есть какие-то метрики, которые могут сказать как сильно удаленка ударила по вам или, наоборот, помогла вам?
На этот вопрос однозначно ответить нельзя. Многим людям стало комфортнее. Например, мой случай: на дорогу до офиса у меня уходит 1 час 20 минут, что в сумме почти три часа на дорогу туда-обратно. Сейчас я могу это время потратить либо на работу, либо на свои личные дела, что в итоге делает меня более продуктивным.
Из реальных минусов остается то, что приходится отвлекаться на домашние вопросы — у тех, кто живет один, этой проблемы нет, но всё равно бывают трудности с планированием своего времени..
Если говорить про общую ситуацию, то в разных командах по-разному, чья-то производительность не изменилась, а у кого-то стала лучше. Проблемой стали только отдельно точечные проблемы с графиком. Людям стало сложнее определиться в какое время начало рабочего дня и когда им чего нужно делать.
Чем дольше мы работаем в таком режиме, тем лучше у нас все проходит. Стендапы стендапятся, все бизнесовые встречи тоже проводятся. Проблемы с опозданиями из-за перехода из переговорки в переговорку просто исчезли — переключение между Zoom конференциями происходит быстро.
Конечно, есть и минусы — в моем случае, когда работа сильно завязана на личном общении, возможность взять и выцепить человека попить кофе и поговорить сильно деградировала. Я учусь ее компенсировать через обычные созвоны — мы стараемся даже неформальное общение переносить в онлайн — сидим с чашками кофе в zoom:) Кажется, что заметного падения качества работы не произошло.
Когда эпидемия пройдет, как ты думаешь, у вас что-то изменится в процессах или вы забудете про эти времена, как про страшный сон?
Я надеюсь, что мы станем гораздо более гибкими в плане удаленной работы. У нас есть кейсы с удаленной работой фуллтайм. Но это всегда те люди, которые отработали какое-то время в офисе и заявили о желании работать удаленно — таких можно пересчитать по пальцам.
Сейчас разные уровни руководства видят, что ничего страшного и фатального не произошло, а на некоторых позициях даже стало лучше. Поэтому мы будем продолжать развивать историю 1 day home office, когда можно раз в неделю остаться дома — главное заранее предупредить и синхронизироваться с остальной командой.
Думаю, что это направление будет расти и мы будем более лояльнеев этом плане друг к другу. Полностью оставаться на удаленке, конечно, не будем — возможность собраться всем в переговорке очень ценна. Или просто развернуться в кресле и задать вопрос коллеге.
Логично было бы бОльшим интересом смотреть на найм удаленных сотрудников, т.к. за несколько месяцев изоляции набьем все основные шишки и получим опыт. Ну а технически мы готовы — доработали кучу переговорок для встреч онлайн.
У вас есть какие-то закрытые ресурсы, доступные только из офиса? Были ли какие-то изменения в плане доступа с введением карантина?
У нас уже отлажен процесс полного удаленного доступа в нашу сеть, чтобы дежурные могли работать удаленно. Так что никаких проблем с этим не возникло.
Про devrel
Я слышал, что у вас есть школа спикеров? Можешь рассказать про нее подробнее?
Да, Speakers Club. В 2016 году на devconf я слушал про IT-бренд — для меня это была совершенно новая область, т.к. в компаниях, где я работал, этого не было. На докладе рассказывалось что такое IT-бренд, какие есть способы его прокачки и как это делать.
Я вернулся с доклада и поднял вопрос о том, чтобы начать прокачивать IT-бренд в Lamoda. Именно в этот момент к нам пришла Женя Голева, наш действующий devrel.
Она с лета 2016 начала курс по публичным выступлениям, куда позвали тимлидов и техлидов — туда попал и я, так как интересовался темой.
По результатам года работы Speakers Club мы подготовились и выступили на HighLoad и на других конференциях.
Speakers Club существует 4 года и мы собираемся каждые 2 недели. Люди приходят туда за тренировкой — тема не имеет никакого значения. Можно прийти рассказывать хоть про морских рыбок:) Главное — нужноприходить без презентации и просто начинать выступать. Дальше уже ведется работа над подачей, работой с аудиторией, структурой повествования и так далее. Главная идея клуба — возможность получить обратную связь о своих навыках, и получить её в максимально безопасной атмосфере.
(YouTube) Бывало ли такое, что devrel своей активностью начинал мешать основной работе тимлида или разработчика? Если да, то как эту проблему решать?
Мешать не получается, т.к. у всех в приоритетах выполнение текущих задач. Подобные проблемы решаются через заведение процессов — был создан отдельный проект в Jira. Было согласовано, что мы можем тратить время на доклады и благодаря этому нет проблем, что кто-то кому-то мешает, отвлекает и т.д.
(YouTube) Есть ли проблема с поиском спикеров для devrel? Есть ли проблема, что выступают одни и те же люди?
Наш devrel работает с руководителями отделов, которые потом доносят до сотрудников мысль о том, что они могут выступать и тратить время на подготовку докладов. Людям, которым было бы интересно выступить, но они считают, что это не умеют, приходят за поддержкой в Speakers Club. Мы стараемся шарить опыт публичных выступлений и рассказываем про полезность выступлений на конференциях.
Например, на следующей неделе у нас будет мероприятие IT Gathering. На нем IT-руководство рассказывает о результатах работы за квартал: что мы сделали хорошо, что плохо, и какие у нас планы на следующий квартал. Также там выступает и devrel, рассказывает про состояние бренда, его стратегию и планы. Мы регулярно напоминаем сотрудникам о том, что можно выступать публично и почему это хорошо.
Ещё помогает такая практика. Раз в несколько месяцев собираем разных людей из компании, которые сильны в своих направлениях технически и у них, предположительно, подвешен язык, но они не выступают.
Предлагаем всем выписать список проектов над которыми они работают. В случайном порядке рассаживаем их между собой и предлагаем позадавать друг другу вопросы об этих проектах. Все вопросы и мысли фиксируются и, в результате, получается некоторое количество докладов.
Это упражнение позволяет пробить стену с синдромом самозванца и ощущение, что “все, что я делаю скучно и неинтересно”. Когда ты слушаешь вопросы своих коллег и понимаешь, что если внутри компании есть люди, готовые задать интересный вопрос, то значит и снаружи, скорее всего, этот опыт можно интересно изложить. Дальше, при работе над докладом, можно рассчитывать на поддержку devrel либо других опытных спикеров.
То есть у вас нет проблем с трафиком людей желающих выступить?
Это постоянный фокус, над которым мы работаем. По щелчку пальцев кучу докладов создать не получается, но есть объем наработок, чтобы регулярно что-то писать на Хабр и делать стабильно по 20-30 докладов в год уже несколько лет. То есть проблемы нет, но работать над этим постоянно приходится — люди в основном думают о своих задачах, а не о том, чтобы выступать.
Еще раз про Сашу
Выступления
Как ты сам начал выступать? Зачем тебе это?
Первый раз я выступил в 2017 на CodeFest.
Начал выступать по простой причине — хотел разобраться со страхом публичных выступлений. Если вдруг мне приходилось что-то рассказывать перед двумя и более людьми, то я мог замкнуться и говорить не получалось.
Меня это раздражало и я решил с этим разобраться. Для начала вписался в чтение книг через Skype — занятие интересное. Люди собирались и по ночам друг другу читали все, что захотят. Этот опыт позволил мне частично разобраться со страхом перед аудиторией и я стал двигаться дальше.
В 2016 году я попал на тренинг для спикеров и начал готовить свой доклад про Docker на Codefest. На протяжении нескольких месяцев я общался с devops и другими, чтобы получить максимально полезный контент. В итоге первый блин вышел комом — я нервничал, у меня дрожал голос. Но после полуторачасовой серии вопросов и ответов понял, что я на верном пути. Пару лет спустя на Saint TeamLeadConf я заметил, что спокоен и мне не важно количество слушателей. Плюс, на конференциях можно познакомиться с огромным количеством интересных мне людей. В итоге я на это подсел:)
Есть какие-то планы на ближайшие выступления?
У меня стабильно пара докладов каждый год. На этот год у меня есть тезисы нового доклада и мы обсуждаем с devrel куда его можно было бы подать. Возможно, подам на РИТ. Также есть материал для TeamLeadConf.
Хобби
Какие у тебя хобби? Я видел в твоем инстаграме пост про то, что ты снимал на Highload. Ты увлекаешься фотографией?
Я увлекаюсь фотографией примерно с 2008 года. Редко проходит неделя, чтобы я не сделал какого-нибудь кадра. Больше всего люблю портретную репортажную фотографию, когда люди не знают, что их снимают.
Начинал со съемок в ночных клубах. С тех пор как мы начали выступать на хайлоад и стоять со стендом, я начал снимать все эти процессы. Также записывал видео наших митапов.
Есть какие-нибудь pet-проекты по разработке?
Большую часть времени в плане pet-проектов я трачу на музыку — пишу электронную музыку, хотя музыкального образования у меня нет. Для меня время, проведенное с музыкой — это лучший способ расслабиться и переключиться.
Заключение
На этом закончилось наше интервью с руководителем направления разработки в Lamoda Александром Афеновым.
Про проект MoreView и другие интервью можно посмотреть здесь. Интервью выходят в прямо эфире на канале YouTube
