Всем привет. Ко мне онлайн на собеседование пришел Александр Афенов, руководитель отдела развития Lamoda. Мы говорили об онбординге, управлении командой в Lamoda, devrel и многом другом.
Интервью транслировалось онлайн на YouTube – запись доступна по адресу связь .
Вы также можете прослушать в формате аудио подкаст .
Ну а ниже — стенограмма интервью.
Вопросы задавал не только я - зрители эфира писали свои вопросы, а я их озвучивал - такие вопросы отмечаются как (YouTube) .
О Саше Меня зовут Александр, я отвечаю за одно из направлений, которое специализируется на генерировании новых денег в Lamoda — подключение бизнес-партнеров и их поддержку.
Как и когда ты оказался в Lamoda?
Я пришел в Lamoda в декабре 2015 года.До этого около 6 лет работал в телекоме, в том числе занимался разработкой услуг технической поддержки у провайдера NetByNet. После того как туда пришел «Мегафон», ему стало «больно» из-за процессов интеграции, поглощения и всего остального, и, в конце концов, я ушел.
Следующие 4 года я занимался, стыдно сказать, «с музыкой вместо гудков».
Я там писал на PHP и немного на Java. В какой-то момент я понял, что бизнес-модель меня напрягает. Очень часто приходилось продавать через тендеры несуществующий товар, а затем в короткие сроки распиливать его.
Первая попытка уйти была через 1,5 года после того, как я начал работать, в 2013 году.
Я пошел на собеседование в Lamoda, там все прошло нормально, но я отказался - мое нынешнее место выкупили, в основном из-за автобусного фактора (это потом стало причина моей постоянной борьбы с фактором автобуса в моих командах).
Я проработал там еще некоторое время, пока не понял, что разработка там мне не интересна — из чисто разработчика я стал полноценным сотрудником, причем не в лучшем смысле (аналитик, QA, технический менеджер и т. д.).
На этот раз деньги уже не могли меня сдерживать и я снова приехал в Ламоду, где работаю до сих пор.
Как вы выросли внутри Lamoda?
Есть гипотеза, что находиться на среднем уровне полезно, чтобы понимать, куда ты хочешь расти дальше — копаться в технической части или больше работать с людьми.За 9 месяцев я поднялся до старшего статуса и пробыл там довольно недолго.
В какой-то момент мой тимлид понял, что ему интереснее позиция технического лида и перешёл туда, а позиция тимлида стала вакантной.
К тому времени я уже улучшил свои soft навыки, участвовал в различных мероприятиях, начал выступать с презентациями и понял, что это можно хорошо использовать в качестве тимлида.
О Ламоде
Руководство командой в Lamoda
Не каждый желающий может стать тимлидом? Как устроена ваша система роста?
Чтобы стать тимлидом, как минимум, нужна команда :) В общем, подход такой, что действующий тимлид старается подготовить хотя бы одного преемника.У меня есть случай, когда я долгое время пытался привлечь к определенной деятельности одного из разработчиков и начал понимать, что в случае чего он будет тимлидом.
Я не стеснялся говорить об этом внутри компании и в результате его сделали тимлидом в другой команде, а я был вынужден снова готовить себе замену.
Мне предложили самому стать тимлидом.
Сначала мне дали должность младшего руководителя команды, испытательный срок 3-6 месяцев.
По итогам испытательного срока ожидалось, что как минимум не должны нарушиться процессы в коллективе и люди не должны уходить.
Младший руководитель команды должен уметь поддерживать все аспекты функционирования команды и не допускать ее ухудшения.
Что касается обзора производительности.
Как вы оцениваете человека, если он сказал, что хочет стать руководителем команды? Нечасто наши разработчики высказывают подобные пожелания.
Были ситуации, когда мы нанимали тимлида со стороны и в процессе понимали, что он не подходит — приходилось либо уйти после испытательного срока, либо перевести его на должность разработчика.
Вообще, наем тимлидов со стороны у нас довольно редкое явление.
У команды свой проект, опыт и приход человека со стороны неэффективен — нужно много сил и времени на наращивание экспертизы, выстраивание отношений и т. д. Что касается метрик, то у нас есть система, но не строго формализованная.
Человек время от времени получает разные возможности проявить себя.
Есть институт виртуальных ролей — инженер службы поддержки, дежурный и технический руководитель.
Это возможность любому разработчику в команде взяться за проект и взять на себя ответственность за его архитектуру, технические решения, процесс запуска, код-ревью и т. д. Он не управляет ресурсами — он остается на той же должности, но отвечает за этот конкретный проект. Для него это прекрасная возможность проявить свой командный потенциал и занять это место в команде в будущем.
(YouTube) Есть ли у вас KPI для разработчиков?
У нас нет явных KPI. Есть внутренние ожидания результатов.Руководитель группы каждого разработчика четко понимает, что нужно, чтобы с высокой вероятностью получить высокую оценку производительности.
Конечно, здесь нет KPI в виде строк кода.
Мы отслеживаем вопрос оверлогов, чтобы понять, насколько хорошо мы описываем и планируем задачи.
Если происходит крупномасштабное превышение, то возникает ретроспективный вопрос: что пошло не так.
Я иногда обращаю внимание на то, как часто менялось описание задачи.
Если он менялся десятки раз, то оверлог, скорее всего, не главная проблема разработчика.
Мы также иногда смотрим на количество коммитов, комментариев и действий в нерабочее время.
Это чаще всего свидетельствует о том, что человек не успевает что-то сделать в рабочее время и это часто приводит к выгоранию, на это стоит обратить внимание.
Как вы стали «тимлидом для руководителей команд»? У тебя тоже был наставник, чье место ты занял?
Надо мной было «безвоздушное пространство».У нас есть два больших блока:
- интернет-магазин: все, что доходит до конечного клиента и связано с веб-сайтами, мобильными приложениями и сервисами, так или иначе их обслуживающими;
- бэкэнд, который автоматизирует бизнес-процессы.
Пользователь непосредственно этого не видит (склад, b2b и т. д.).
Раньше тимлиды подчинялись непосредственно менеджеру, но их становилось все больше, коммуникации стали усложняться и мы изменили структуру.
Мы выделили команды, которые работают над одним направлением бизнеса, и объединили их в дирекции.
Так появилась коммерческая дирекция, которая занимается B2B, и я занимаю место ее руководителя.
(YouTube) Как вы развиваете команду внутри компании? Проходят ли они какое-то централизованное обучение или все происходит спонтанно?
На текущем этапе существует два слоя обучения - внутрикомандный, когда действующий тимлид воспитывает себе замену, и целевое обучение тимлида, уже занявшего эту должность.Раньше у нас были курсы по менеджменту (без особого акцента на лидерство в команде), на которые ходили сотрудники.
Обучение было достаточно полезным, но оторванным от специфики IT-разработки.
Сейчас система другая — у нас есть внутренний курс для тимлидов, который охватывает все проблемы, начиная с: «Я тимлид и что мне делать дальше» и заканчивая спецификой проведения аттестаций в нашей компании.
Там говорится о проведении собеседований, увольнении, правильной даче отзывов и так далее.
Продолжительность одного модуля около 8 часов, есть теоретическая часть и практическая часть – тематические исследования.
Кроме того, есть поддерживающий чат с участниками курса, где люди делятся полезными материалами по теме курса.
Курс проходит волнами, и сейчас будет запущена следующая волна для текущего набора тимлидов.
(YouTube) Вы нанимаете руководителей команд только с техническими навыками?
Это довольно глубокий вопрос, и обычно он начинается с вопроса «Какова у вас связь между программированием и управлением людьмиЭ» Нам нужны технические навыки от тимлида, но если они у него только есть, то он уже архитектор, который скоро перегорит от общения с людьми и перейдет к техническому руководству.Есть команды, в которых технический руководитель и тимлид — один человек.
Это достаточно опытный разработчик, знающий, как работает система, и он продолжает поддерживать свою экспертизу, но движется в сторону управления людьми — занимается ростом, развитием, проверкой производительности и решает вопросы вокруг проекта.
(YouTube) Может ли команда уволить руководителя команды?
У нас не было такого случая.Я общаюсь с разными командами, чтобы понять, какая там атмосфера.
Создать прозрачную обратную связь очень сложно.
Команда может выделить проблемы, сообщить о них руководителю группы или поговорить с HR BP. Они приходят в HR BP с какими-то внутренними проблемами, которые не могут решить самостоятельно.
Например, вас обижает тимлид, вы с ним воюете и хотите как-то решить проблему.
Вы обращаетесь в HR BP, а он в свою очередь делает все, чтобы максимально аккуратно все оформить.
Если тимлид делает что-то безумное, а его менеджер этого не видит, то, конечно, есть каналы передачи этой информации.
(YouTube) Что делать команде, когда замечают, что лидерство начинает выгорать, а он шутит, что «все хорошо»?
Речь идет о случае коллективной ответственности, когда руководителем команды должен быть весь коллектив.Все зависит от того, как лидер позиционирует себя для команды.
Иногда в команде есть достаточно сильные люди, которые видят, что могут отобрать у тимлида какую-то деятельность.
Если ни прямым разговором, ни намеками команда не может дать понять тимлиду, что у него что-то не получается, то можно подключить HR BP, который с ним поговорит. В отчете об онбординге я сказал, что грустно, если тимлид сильно отстает от команды и к нему относятся как к какому-то мега-менеджеру.
Если он станет частью команды, то получит такую же поддержку, как и все остальные.
Чем ближе он к народу, тем больше шансов, что его поддержат.
У вас есть доклад «Трудно быть Колей», где вы рассказали о том, как делитесь знаниями.
Удовлетворены ли вы тем, как построен процесс адаптации новичков? С каждым разом становится все лучше.
Была очень хорошая история с приятелем — человеку помогает не кто-то отвлеченный, а человек непосредственно из коллектива, который поддерживает тимлида и является другом для нового сотрудника.
Бадди помогает с повседневными вопросами и помогает ознакомиться с системой.
Это укрепило наш процесс адаптации.
В своем докладе на «Страйке» я говорил, что у нас есть чек-листы и именно с ними очень хорошо работает онбординг в ИТ, потому что они позволяют увидеть план того, что мы ожидаем от новичка, и регулярно отслеживать прогресс.
Часто адаптация происходит бессистемно и возлагается на руководителя команды, а руководители команд разные.
Сейчас мы стараемся этого избежать, используя формальные чек-листы, регулярные встречи с новичками и вообще следуя более-менее формализованному и описанному процессу адаптации.
Есть ли у вас какой-либо процесс увольнения и передачи знаний на данном этапе?
Сохранять знания на этом этапе – плохая идея.Человек, даже будучи лояльным к своему тимлиду, не говорит ему заранее о возможном предложении, опасаясь подорвать доверие, если по каким-то причинам он решит остаться в команде.
Из-за этого часто возникает ситуация, что человек приходит с предложением уйти в отставку, поскольку ранее ему было неудобно сообщать о своих намерениях.
После этого убедить сотрудника оставить после себя какую-то документацию проблематично – нет мотивации.
О процессе трансфера знаний лучше поговорить под другим углом – техническое лидерство, кранчи и так далее.
Если говорить конкретно о процессе отключения, то первое, что активируется – это режим удержания.
Если мы можем как-то повлиять на его решение, то мы это делаем – составляем конкретный план.
Такие ситуации случаются и работают регулярно.
Я слышал мнение, что делать людям встречное предложение бессмысленно.
Подходит ли вам эта практика? А после возвращения была ли работа проведена эффективно? Такие случаи случаются и случаются довольно часто.
Мы всегда стараемся.
Я сам прошел через нечто подобное — пару лет назад у меня появилось желание просто заняться программированием.
Я поговорил с руководством и в обычном диалоге мы выяснили, что именно не так, и нам удалось это исправить.
Я все еще работаю здесь.
Удерживать на местах, даже деньгами, неэффективно.
Если «держать», то человек, скорее всего, все равно уйдет через пару месяцев-полгода.
И если удастся установить, в чем именно причина, и устранить ее, то можно продолжать эффективную работу, как это было со мной.
Это вопрос распределения ресурсов для облегчения боли этого человека.
(YouTube) Что делать с тем, что разработчики по умолчанию не всегда делятся знаниями?
Я бы солгал, если бы сказал, что наш процесс выстроен идеально.Есть несколько направлений, в которых мы пытаемся это охватить.
У нас есть институт аналитики, который работает не только над проектными историями, но и занимается тем, что было сделано раньше, но по каким-то причинам не было задокументировано.
Это касается крупных элементов.
В прошлом году мы нарисовали диаграммы последовательности всех ключевых бизнес-процессов и связей между ними; каждая диаграмма включала в себя десятки систем, которые взаимодействуют друг с другом, например, для размещения или подтверждения заказа клиента.
Это документация, сделанная постфактум, но она актуальна и удобна.
Сервис Lamoda имеет достаточно высокую нагрузку и архитектурно разделен на микросервисы.
Оправданы ли затраты на поддержку такой архитектуры? По большей части я поймал этот разрез.
Всегда есть светлые и темные стороны.
Я думаю, что мой опыт мало репрезентативен, потому что.
я работал в основном с гигантским монолитом.
Не скажу, что мы полностью следуем принципам DDD, но во многом стремимся.
Например, у нас есть сервис «Обработка заказов» и он по неизвестным причинам решает проблему синхронизации остатков между складами на сайте, но ему это знать не обязательно — достаточно знать о наличии только на этапе заказа.
подтверждение или отмена.
При этом он решает чужие проблемы.
Имеет интерфейс для управления шаблонами SMS, отправляемыми пользователям.
Если мы по каким-то причинам захотим изменить то, что рассылается пользователям по СМС, нам нужно будет передать в производство двухтысячный монолит, который обрабатывает все заказы.
Сейчас в кубе с проверками здоровья и т.п.
всё работает хорошо, а раньше было очень страшно.
Хотелось бы, чтобы появились сервисы, решающие свою, пусть и не самую узкую, задачу.
Это не обязательно должен быть обычный микро-микросервис.
Важно, чтобы было разделение на уровне домена.
Такой подход разделения позволяет командам сосредоточиться на одном домене.
Стоит ли оно того? Строго да.
Помимо бонусов могу добавить, что при вырезании какого-то старого сервиса решается проблема технического обновления старого сервиса.
За счет этого мы уже решили кучу проблем.
Теперь вы являетесь руководителем группы.
Но кодируете ли вы себя? Да, но в основном это истории поддержки и любимые проекты вне основной работы.
Как бороться с блокировкой задач, которые нависают над вами?
История проста – попадать в такие ситуации крайне нежелательно.Задачи, которые можно взять на себя, не являются срочными.
Например, я знаю, что у нас есть интерфейс управления отправкой СМС и знаю, что он работает плохо и срочной задачи по улучшению этого блока нет. Я заканчиваю тихо и никого не блокирую.
Если я не могу гарантировать, что сяду и выполню задание в срок, то я не имею права за него браться.
Основная задача тимлида — не ввязываться в подобные ситуации.
Недавно был случай, когда мне пришлось подключиться к инфраструктурным задачам.
Большая часть была сделана до меня, и мне это было интересно с точки зрения «самосовершенствования» и одновременно решения задачи, на которую у команды точно не будет ресурсов в ближайшие пару недель.
Без этого задача просто стояла бы на месте, если бы я не подключился.
Я также подключаюсь, когда идут минуты.
Например, когда что-то попало в дежурство и нужно внести какие-то коррективы, чтобы это заработало, странно отказываться, если можно.
Поддержка Ламода
Как структурирована поддержка производительности в Lamoda? Я как пользователь понимаю, но мне интересно, что происходит на вашей стороне.
Звонки клиентов обрабатываются контакт-центром, а затем эта информация передается в нашу службу поддержки.
Для большинства случаев существует набор инструкций, где и какую проблему можно решить.
Также по каждому направлению есть информация о текущем дежурном.
Если задача не срочная, то она попадает на доску в Jira, где потом в рабочее время разбирается инженер поддержки.
Если что-то срочное, то задание поручается дежурному и он садится решать проблему независимо от времени суток.
Сколько человек дежурит?
Одновременно дежурит один человек.Например, сегодня последний день моего дежурства — я дежурю периодически, чтобы быть в курсе того, что происходит с системой.
Должен ли дежурный офицер знать обо всей системе? Получается, что им может стать только опытный разработчик, давно работающий с системой?
Бывает по разному.На дежурство они обычно выходят не ранее, чем через полгода после трудоустройства и только по желанию.
Дежурство может стать инструментом обучения – дежурный будет «доверенным лицом» более опытного сотрудника и разъяснит, что нужно для решения проблемы.
Совместным решением дежурный узнает. В идеале последствия решения проблемы и информация о решении фиксируются в Confluence. Постепенно из «доверенного лица» он превращается в полноценного дежурного офицера.
Каждая последующая проблема новая, и не каждый раз существует универсальное решение.
Если ошибка прямо в продакшене, могут ли дежурные развернуть ее напрямую?
Мы всячески пытаемся исключить такую возможность.Если такое все-таки произойдет, мы придерживаемся стандартного процесса — помимо дежурного, внесшего изменения в код, при необходимости будут задействованы QA и другие.
Релиз обычно делает не тот, кто писал код — это наше внутреннее требование, выработанное после множества проб, ошибок, проверок и так далее…
(YouTube) Руководители команд тоже дежурят? Мы для себя поняли, что обязанность тимлида негативно влияет на процессы
Я за то, чтобы руководитель команды не слишком дистанцировался от команды.Если он на дежурстве, то хорошо понимает, что происходит в системе в рамках ее работы.
Я считаю, что руководителю бригады даже важно и нужно иногда быть на дежурстве, если он хочет быть в курсе происходящего.
Возможно, он дежурит меньше других, но у меня никогда не было желания полностью игнорировать этот процесс.
У нас довольно сложный проект, и дежурство, код-ревью и прочие вещи позволяют тимлиду оставаться в курсе темы.
(YouTube) Что касается инфраструктуры, есть ли у вас дежурные люди? Когда проблема не в бизнес-логике, а в производстве.
Или когда есть проблема с границей.
У нас есть оперативная группа с собственным мониторингом.
Есть инструкции, кому и по какому поводу звонить, а в оперативной команде всегда дежурят свои люди.
Если, например, у нас реплика разваливается, то вызываем дежурного — он подключает и решает проблему.
Дежурные разработчики имеют прямой доступ к базе данных, но строго для чтения.
Если регулярно возникают проблемы, требующие прямого вмешательства в базу, то разбираем задним числом, делаем кнопку, реализующую тот же функционал и больше не заходим напрямую в базу.
О карантине
Это непростые времена.
Как вы выживаете на карантине? Мы работаем удаленно.
Люди тоже время от времени посещают офис, но по мере развития эпидемии людей в офисе становилось все меньше и меньше.
Например, сейчас в офисе никого из моей команды нет.
Есть ли у вас какие-либо показатели, которые могут сказать, насколько сильно удаленная работа ударила по вам или, наоборот, помогла?
На этот вопрос нельзя ответить однозначно.Многие люди почувствовали себя более комфортно.
Например, мой случай: мне добираться до офиса 1 час 20 минут, что в сумме составляет почти три часа на дорогу туда и обратно.
Теперь я могу потратить это время либо на работу, либо на свои личные дела, что в конечном итоге делает меня более продуктивным.
Настоящий минус в том, что приходится отвлекаться на бытовые вопросы – у тех, кто живет один, этой проблемы нет, но у них все равно возникают трудности с планированием своего времени.
Если говорить об общей ситуации, то в разных командах она разная, у кого-то показатели не изменились, а у кого-то улучшились.
Проблема заключалась лишь в отдельных точечных проблемах с графиком.
Людям стало сложнее решать, во сколько начинается рабочий день и когда им что нужно делать.
Чем дольше мы работаем в таком режиме, тем лучше у нас все проходит. Стендапы делают стендапы, также проводятся все деловые встречи.
Проблемы с задержками из-за перехода от встречи к встрече просто исчезли — переключение между конференциями Zoom происходит быстро.
Конечно, есть и минусы – в моем случае, когда работа сильно завязана на личное общение, возможность забрать человека на кофе и поговорить сильно деградировала.
Учусь компенсировать это регулярными звонками - даже неформальное общение стараемся перевести в онлайн - сидим с чашечками кофе в Zoom :) Вроде заметного падения качества работы не произошло.
Когда эпидемия пройдет, как вы думаете, что-то изменится в ваших процессах или вы забудете об этих временах, как о страшном сне?
Я надеюсь, что мы станем гораздо более гибкими в плане удаленной работы.У нас есть случаи с полной удаленной работой.
Но это всегда те люди, которые какое-то время проработали в офисе и изъявили желание работать удаленно – их можно пересчитать по пальцам.
Сейчас руководство разных уровней видит, что ничего страшного и фатального не произошло, а на некоторых позициях даже стало лучше.
Поэтому мы продолжим развивать историю про 1 день домашнего офиса, когда можно оставаться дома раз в неделю — главное предупредить заранее и синхронизироваться с остальной командой.
Я думаю, что это направление будет развиваться и мы будем более лояльны друг к другу в этом плане.
Конечно, мы не останемся полностью удаленными — возможность собрать всех вместе в переговорной комнате очень ценна.
Или просто развернитесь в кресле и задайте вопрос коллеге.
Логично было бы с большим интересом отнестись к найму удаленных сотрудников, потому что.
за несколько месяцев изоляции мы коснемся всех ключевых моментов и наберемся опыта.
Ну, технически мы готовы — завершили кучу переговоров по онлайн-встречам.
Есть ли у вас закрытые ресурсы, доступные только из офиса? Произошли ли какие-то изменения в условиях доступа с момента введения карантина?
Мы уже наладили процесс полного удаленного доступа к нашей сети, чтобы дежурные могли работать удаленно.Так что с этим проблем не было.
О девреле
Я слышал, что у вас есть школа ораторского искусства? Можете ли вы рассказать нам больше о ней?
Да, Клуб спикеров.В 2016 году на devconf я услышал об IT-бренде — для меня это было совершенно новое направление, потому что.
В компаниях, где я работал, такого не было.
В докладе объясняется, что такое ИТ-бренд, каковы способы его продвижения и как это сделать.
Вернувшись с доклада, я поднял вопрос о начале модернизации IT-бренда в Lamoda. Именно в этот момент к нам пришла Женя Голева, наша нынешняя девля.
Летом 2016 года она запустила курс по публичным выступлениям, куда были приглашены тимлиды и технические лидеры — я тоже туда попал, так как меня интересовала тема.
По итогам года работы Спикер-клуба мы готовились и выступали на HighLoad и других конференциях.
Спикер-клуб существует уже 4 года и мы встречаемся каждые 2 недели.
Туда приходят на обучение – тема не имеет значения.
Можно даже прийти и поговорить о морской рыбе :) Главное прийти без презентации и просто начать говорить.
Потом уже идет работа над подачей, работа с аудиторией, структурой повествования и так далее.
Основная идея клуба – возможность получить обратную связь о своих навыках, причем в максимально безопасной атмосфере.
(YouTube) Случалось ли когда-нибудь, чтобы деятельность деврела начинала мешать основной работе тимлида или разработчика? Если да, то как решить эту проблему?
Вмешиваться невозможно, потому что.Приоритет каждого – выполнение текущих задач.
Такие проблемы решаются путем создания процессов — в Jira создан отдельный проект. Договорились, что мы можем тратить время на отчеты и благодаря этому не возникает проблем, что кто-то кого-то беспокоит, кого-то отвлекает и т. д.
(YouTube) Есть ли проблема с поиском динамиков для devrel? Есть ли задача, которую выполняют одни и те же люди?
Наш деврел работает с руководителями отделов, которые затем доносят до сотрудников мысль, что они могут высказаться и потратить время на подготовку отчетов.В Спикер-клуб за поддержкой приходят люди, которые хотели бы выступить, но не думают, что смогут это сделать.
Мы стараемся делиться опытом публичных выступлений и рассказывать о пользе выступлений на конференциях.
Например, на следующей неделе у нас будет мероприятие IT Gathering. На нем ИТ-менеджмент рассказывает об итогах квартала: что мы сделали хорошо, что мы сделали плохо и какие у нас планы на следующий квартал.
Там же выступает Деврел и рассказывает о состоянии бренда, его стратегии и планах.
Мы регулярно напоминаем сотрудникам, что выступать публично — это нормально и почему это полезно.
Эта практика также помогает. Каждые несколько месяцев мы собираем из компании разных людей, технически сильных в своих областях и которые, надо полагать, косноязычны, но не выполняют свою работу.
Мы предлагаем каждому записать список проектов, над которыми он работает. Мы рассадим их друг вокруг друга в случайном порядке и предложим им задать друг другу вопросы об этих проектах.
Все вопросы и мысли фиксируются и в результате получается ряд отчетов.
Это упражнение позволяет пробить стену синдрома самозванца и ощущения, что «все, что я делаю, скучно и неинтересно».
Когда вы слушаете вопросы коллег и понимаете, что если внутри компании есть люди, готовые задать интересный вопрос, то есть и люди снаружи, скорее всего, этот опыт можно интересно подать.
Далее при работе над докладом вы можете рассчитывать на поддержку Деврела или других опытных спикеров.
То есть у вас нет проблем с трафиком желающих выступить?
Это постоянный фокус, над которым мы работаем.Создать кучу отчетов по щелчку пальцев не получится, но работы достаточно, чтобы регулярно что-то писать на Хабре и выпускать стабильно 20-30 отчетов в год вот уже несколько лет. То есть проблемы нет, но над ней постоянно приходится работать — люди в основном думают о своих задачах, а не о выполнении.
Еще раз о Саше
Спектакли
Как вы начали выступать? Зачем тебе это?
Впервые я выступил в 2017 году на CodeFest. Я начал выступать по простой причине – я хотел справиться со своим страхом перед публичными выступлениями.Если вдруг мне пришлось что-то рассказать перед двумя и более людьми, то я мог замкнуться и не мог говорить.
Меня это раздражало и я решил с этим разобраться.
Для начала я присоединился к чтению книг по скайпу – интересное занятие.
Вечером люди собирались и читали друг другу все, что хотели.
Этот опыт позволил мне частично справиться со своим страхом перед публикой, и я начал двигаться дальше.
В 2016 году я прошел тренинг спикеров и начал готовить доклад о Docker на Codefest. Я месяцами общался с разработчиками и другими, чтобы получить максимально полезный контент. В результате первый блин вышел комом – я нервничала, голос дрожал.
Но после полуторачасовой серии вопросов и ответов я понял, что нахожусь на правильном пути.
Спустя пару лет на Saint TeamLeadConf я заметил, что спокоен и меня не волнует количество слушателей.
Плюс на конференциях я могу познакомиться с огромным количеством интересных мне людей.
В конце концов я на это подсела :)
Есть ли у вас планы на ближайшие выступления?
У меня постоянно есть несколько отчетов каждый год. В этом году у меня новые рефераты Теги: #Интервью #Управление развитием #выступления #тимлид #lamoda-
Почему Apple Отказалась От Метеослужбы Yahoo
19 Oct, 24 -
Слушайте Всех! Или Прощай Карма.
19 Oct, 24 -
Мечты Роберта Бойля Сбываются. Часть 2
19 Oct, 24 -
Что Общего Между Коронавирусом И Шахматами?
19 Oct, 24 -
Ocr От Google
19 Oct, 24 -
Простая Проверка/Очистка Html
19 Oct, 24
