Публикуем видео и текст открытого семинара Екатерины Антаковой, старшего инженера по разработке инструментов анализа производительности в компании Intel.
Доклад Екатерины “Обзор TeamLead Roadmap. Нетехнические навыки для разработчиков” посвящен ролям и обязанностям тимлида, которые актуальны для любого разработчика, а также личным качествам, которые нужны для выполнения этих обязанностей.
Как расширять зону ответственности и расти, как определять актуальный для себя фронт работ и практиковать навыки. В рамках доклада рассмотрена методика TeamLead Roadmap, которая помогает в карьере и в жизни – и не только тимлидам.
Мотивация
У Андрея Смирнова из Х5 как-то был доклад про уровни, связь с группой и карьеру, где также приводились результаты опроса про Soft skills. Наибольшее количество разработчиков из его опроса ответили, что вообще не понимают, что это за навыки (рефлексия, креативность, обратная связь), и как с ними работать.
Действительно, мы довольно часто уходим в свою техническую линейку и думаем, что если мы уже состоялись как специалисты, то этого достаточно. Но чем дальше работаешь, тем больше замечаешь, что этого мало, и приходит понимание того, что если вы хотите двигаться в карьере и что-то менять в команде, то вам все равно придется осваивать следующие навыки: организационные, нетехнические или же околотехнические.
Даже если вы будете техлидом, архитектором, product ownerом, вам придется убеждать людей делать именно это, именно в это время, именно по этой архитектуре и работать именно вместе с вами. Чтобы влиять на людей, нужно уметь это делать. Есть еще и другие причины, зачастую личные: например, работать в хорошей культуре, в удобной и приятной для совместного творчества команде.
Инструмент, о котором мы поговорим сегодня – Teamlead Roadmap. Если мы с вами на минуточку заглянем в Интернет и посмотрим на эту карту хотя бы одним глазком, то увидим огромную схему по типу mind map, где есть роли, обязанности, и отдельно, как бы в стороне, личные навыки, которые тимлид мог бы развивать. Личных навыков очень много, к ним относится и управление, и технические навыки – как писать код, и как тестировать требования; сложные навыки – как сотрудничать, как управлять конфликтами. Я думаю, что их все нужно развивать, только не обязательно браться за все сразу и прямо сейчас, поэтому давайте обратимся к чему-то конкретному, чтобы не запутаться.
Навыки менеджмента
Начнем с организационных навыков – это навыки управления людьми, навыки менеджмента. Даже разработчику имеет смысл на них обратить внимание.
Давайте посмотрим на две самые важные вещи: во-первых, знание вашего бизнеса, и понимание того, как работает ваша компания, а во-вторых, митинги один-на-один, часто с менеджерами или с коллегами. Разработчики, естественно, должны знать что-то про бизнес, на который они работают, потому что именно он дает зарплаты, задания, и по максимуму связан с нуждами людей и компании. Очень полезно знать, кто владеет вашей компанией, как она зарабатывает деньги, кто ей платит, какие отделы сколько получают, какая у компании стратегия на рынке, что она планирует делать, куда она двигается или смещается. Это очень вам поможет, потому что вы будете понимать, как ваша ежедневная работа и простейшие задания, которые вы закрываете, связаны в целом. Понимание этого поможет принимать какие-то решения, что делать, а что нет, на что именно сейчас стоит потратить ресурс; также это связывает вас с покупателем, а понимание покупательских нужд во многом снижает психологические риски и беспокойства типа «а закроют ли наш проект», «а не будет ли у нас проблем». Если вы сами понимаете, в каком ландшафте работаете, то вам будет легче вовремя принять необходимые решения – переключиться, передвинуться, и даже просто не волноваться.
Я, например, работаю в американской компании и, естественно, тоже пытаюсь разобраться в модели работы этой компании и вообще в том, какие у нас отношения с Америкой, и что может случиться дальше. Мне это полезно и как человеку, и как инженеру.
Также у вас должна быть какая-то возможность конкретной практики, не просто «надо знать бизнес и точка», ведь бизнес в каждом конкретном случае очень субъективен, у каждой компании собственные ресурсы. Иногда об этом можно спросить у вашего начальника или менеджера, иногда у технического лидера сети, или у вашей компании выложены открытые финансовые результаты, которые можно почитать, как например, у Intel есть специальная информация для инвесторов. И если подключиться к этим ресурсам и хоть немножечко о них подумать, попробовать понять их, посмотреть на них во временном ряду и обсудить со своими коллегами или менеджером в команде, то понимание того, что мы делаем и кто нам за это платит, станет гораздо лучше, а также вы будете знать, насколько по целям и ценностям сильна ваша связь с компанией. Иногда разработчики не понимают, что сдерживает их рост в компании, в то время как этим фактором как раз может быть отсутствие кругозора.
Митинги один-на-один
Далее поговорим о митингах один-на-один. Думаю, у многих разработчиков, программистов, тестировщиков есть совещания или встречи со своим менеджером. Это очень большой ресурс, ведь через эти встречи вы можете повлиять и на стратегию, и на то, куда команда дальше пойдет. Если вы создадите доверие между собой и менеджером, то вам будет значительно легче добиваться совместных целей. Помните о том, что эти цели нужно время от времени перепроверять и выравнивать: то есть не забывать обсудить, что менеджер ждет от вас на текущем карьерном уровне, или что он будет ждать на следующем. Не постесняться и спросить: если я хочу стать ведущим инженером /главным архитектором/ старшим разработчиком, что от меня ожидается? Обсудить тонкие моменты – где вы не тянете, где нужно доработать, и легче всего это сделать именно на совещании один-на-один, а не при всей команде. На страничке Roadmap для этого уже составлен чеклист, вроде такого:
- Совещание не должно проходить в молчании
- Менеджер должен больше слушать, чем говорить и т.д.
По нему вы можете проверить, насколько хорошо проходят ваши встречи, и можете ли вы сделать их лучше, добавить то, чего там еще нет – высылать план совещания, так называемую agenda; вести истории проектов – провалов и достижений, чтобы потом это могло вам помочь наполнить ваше резюме. Такие вещи – сбор обратной связи, ее обработка – будут очень полезны и для карьеры, и для вас, и для менеджера. Кроме того, если вы будете больше владеть этим процессом в качестве разработчика, то менеджер увидит вашу активность, поймет, что вы не просто сидите на своем месте и ждете, когда вас начнут развивать в карьере, а что вы уже обратили внимание на этот вопрос, знаете инструменты, внимательно их изучили и уже начинаете практиковать. Очень рекомендую вам обратить внимание на эту стандартную во многих компаниях практику, посмотреть, что и как можно сделать лучше и начать делать.
Навыки владельца продукта
Следующая цепочка навыков тимлида, которая нам, как разработчикам, может быть полезна – это навыки владельца продукта, человека, который определяет, куда и по каким рельсам движется продукт. Сегодня мы можем поговорить о двух небольших элементах, относящихся к этим навыкам – это понимание продукта и жизненный цикл фич.
Как вы видите, эта ветка тоже огромна, и сразу бросаться на нее не стоит, потому что идея работы с таким широким ресурсом – это обращение к тому, что именно сейчас и именно вам актуально, что поможет на вашей позиции. Работа над фичами и их укладывание в задания – это то, что актуально многим разработчикам. Мы все эти фичи в какой-то мере определяем, создаем, двигаем, и имеет смысл посмотреть на это с точки зрения долгого процесса. Стоит помнить, что наш продукт состоит из целой группы фич, и они не должны противоречить друг другу, появляться неожиданно, без проверки и без дополнительного анализа. И если вдруг этот анализ все-таки был, но по-прежнему не достаточен, то вы как простой разработчик можете на это повлиять.
Хороший продукт, естественно, содержит много фич, и каждая из этих фич должна быть качественной, а все вместе они должны составлять единое целое и не противоречить друг другу. То есть если в вашем продукте меню устроено по принципу хлебных крошек, то хорошо было бы, чтобы оно было так устроено везде, на каждой странице, на любой панели.
Ради всего этого стоит посмотреть, каким образом фичи приходят в продукт, как они прорабатываются, как мы создаем гипотезы о том, что фича ценна, определяем размеры, план реализации, выкатку фичи, ее поддержку, как мы можем удалить ее, и когда это сделать. Если у вас нет цикла работы по фичам, то имеет смысл его предложить, создать и предложить его своей команде и начальникам. По текущим фичам тоже сделать какую-то оценку: на каком уровне они находятся, насколько удовлетворяют запросы, куда они двигаются. То есть практика состоит в том, чтобы вы исследовали новые, текущие и старые фичи, определяли их стадии, улучшали наши знания о фичах, понимали, как их используют кастомеры сейчас, и как они хотели бы их использовать в будущем. Если вы разработчик, то вы можете в этом месте найти свою точку роста; если вы в начале влияли совсем немного, то взять на себя руководство какой-то фичей в продукте и начать определять ее больше, подхватить дело за своим техническим лидером, архитектором и вложить в продукт чуть больше своего труда.
Понимание продукта
Следующий пункт довольно абстрактный, но если погрузиться в него, то очень интересный – это понимание продукта. Многие не пытаются глубоко изучить свой продукт, понять его, например, с точки зрения теории систем, понять как этот продукт выглядит как подсистема. У ваших пользователей есть пути, по которым они проходят и решают свои задачи, а на этих путях, где-то в середине стоит ваш продукт. Если мы об этом задумаемся, то нам будет легче работать, потому что и у конкретного разработчика, и у команды будет мотивация. Лучше пилить процессы, исходя из знаний о нашем продукте и его положении, принимать лучшие архитектурные решения – на чем мы пишем, какие сейчас развиваются фреймворки, кто их поддерживает, что есть сейчас рынке и что появляется.
Во всех этих проекциях мы можем рассматривать наш продукт и, соответственно, практиковаться. Мы, как разработчики, можем ходить на интервью с нашими кастомерами или даже проводить их, если их еще не было. Смотреть на задачи, которые решает клиент с помощью нашего продукта, какие у него есть альтернативы, проводить конкурентный анализ, анализ рынка, смотреть, какова культурная среда, в которой работает наш продукт.
Такое углубленное понятие бизнеса станет в нужный момент конкурентным преимуществом: если вы знаете ландшафт, то уже проще будет подключиться к потоку, вовремя предложить фичу, когда она актуальна на рынке, а это будет большим выигрышем как для людей, так и для карьеры.
Личное развитие
И последний сложный вопрос: это наше личное развитие. Здесь хочу поговорить с вами о привычках, хороших и плохих, и об обратной связи, как мы ее получаем и как даем. Это как раз относится к ощущению культуры в команде – могу ли я открыто сказать о чем-то, попросить помощи или признаться в слабости, или же культура совершенно другая и не позволяет этого. Кроме Teamlead Roadmap по личным качествам есть огромное количество литературы – могу порекомендовать вам Бюро Артёма Горбунова, сайт Максима Ильяхова и их осьминожки навыков. Я и себя, и других людей в плане навыков представляю как осьминожек, у которых есть щупальца с большим мастерством, а есть совсем коротенькие; эти осьминожки постоянно растут, развиваются, делегируют что-то, становятся профессионалами.
Как говорил Канеман, мы действуем автоматически большую часть времени, поэтому эффект от правильной привычки просто огромен. Если бы Чайковский и Рахманинов не садились в пять утра на несколько часов писать музыку за фортепиано, то они никогда не написали бы свои гениальные симфонии. Вдохновения у них, может, и не было, а привычка трудиться была. Так что же мы можем делать со своим привычками? Как минимум, включить осознанность и начать оценивать, изучать то, что есть сейчас. Какие у вас есть рутинные дела, где вы замечаете, что вам неудобно, плохо? Надо смотреть, что со всем этим делать, выносить в рациональное поле.
Кроме того, есть один сложный момент, связанный с ментальными привычками, привычками нашего ума. То есть это то, что мы думаем о себе сейчас, и что мы думаем после каких-то провалов, неудач, в трудные времена; ведь когда все хорошо, то мы обычно о себе и не думаем, а вот если все плохо, то сразу начинаем сравнивать, оценивать. И у этих привычек также есть тенденция ухудшаться, скатываться в неблагоприятные повторения, так называемые руминации, которые совершенно неэффективны, только лишают вас сил нормально работать, расти и развиваться. Вы привыкли о себе думать в каком-то ключе, например: «Я девелопер, никаких фичей вообще в жизни не видел», но можно попытаться думать по-другому и пользоваться инструментами для изменения наших привычек. Человек и его мозг пластичен, он адаптируется под что угодно, и многие сложные ситуации можно переломить всего лишь с помощью изменений привычек. Исследовать, чего вы избегали в своей работе – например, почему вы редко делаете презентации или не ходите продавать свои идеи архитекторам. Все это можно продумать, сделать и использовать для этого совершенно разные инструменты. Просто подумайте, как ваша привычка на вас влияет – как вы себя ведете, как вы себя показываете перед семьей, коллегами; к чему это все приведет в долгосрочной перспективе?
Получение и ответ на обратную связь
И последний конкретный навык, который всем нам может помочь, это получение и ответ на обратную связь. Почему-то мы не всегда хотим это делать, чего-то стесняемся или боимся, но на самом деле, это очень помогает и развиться лично, и развиться вашей компании или команде в целом. Неясные пожелания по поводу вашей работы могут стать четкими и высказанными после получения обратной связи. Если же ее не давать и не получать, то неизбежно появятся конфликты – мы думали, что вы сделаете, а вы не сделали; а мы думали, что этим займутся тестировщики; и лучше побеспокоиться заранее, чем узнавать обо всем этом слишком поздно.
Но если обратная связь дается неправильно или как-нибудь слишком сурово, то это приводит к неудачным коллективным отношениям или к токсичности. Людям становится неприятно работать вместе, они закрываются, трудно в коллективе что-то двигать вперед. Поэтому тут нам, как разработчикам, полезнее всего будет проверить себя – а давно ли мы спрашивали об обратной связи своего архитектора, лидера или просто коллег? Может быть, как раз настало время спросить. Не было ли у нас такого, что мы сперва рубили сплеча и только потом начинали думать, что же я такого сказал, и каким людям, и почему теперь коллеги не рвутся со мной работать? Проясняли ли мы ожидания от нас, и сообщали ли мы о своих ожиданиях начальнику? С одной стороны, вы можете думать, что не в ваших полномочиях говорить об ожиданиях начальнику, но почему бы и не поговорить об этом, почему не спросить, какие у меня ожидания от менеджера, в чем мне бы хотелось получить его помощь, где мне бы хотелось получить больше свободы, какие предложения от него я готов и буду рад выслушать? Как менеджер вам, так и вы менеджеру можете высказать свои ожидания, только, разумеется, внимательно и аккуратно. Если вы все-таки получили обратную связь, то постараться с ней что-то делать.
Говорить больше о фактах, чем о своих впечатлениях, конкретизировать. Не заявлять сходу: «Ты неряшливый», а пояснять: «В этом отчете не хватило детализации, ожидался более четкий подход». Смысл примерно тот же самый, но уже намного мягче воспринимается собеседником. Хорошо, если бы в компании были варианты выдачи фидбека, чтобы можно было сообщить свое мнение по-разному: через открытые /анонимные опросы, фокус-группы, обсуждения, ретроспективы. Разные виды дают разные взгляды, помогают вернуть какую-то объективность, главным образом, по отношению к себе.
Практика
А как же практиковать все эти навыки, о которых мы говорили? Мы сейчас изучили с вами теорию, чуть позже у вас наступит понимание этой теории, а потом вам предстоит огромный пласт работы – практика. Можно с начальником обсудить, как и в каких условиях практиковаться; можете ли вы брать фичи на проработку, каким образом вы можете изучать бизнес вашей компании, как вы можете налаживать автоматическое тестирование, которого еще не было в вашем проекте. Если у вас будет возможность иметь регулярную практику, тогда вы увидите результат.
Помните, что не надо сильно распыляться, только действовать в соответствии с тем, что вам сейчас актуально, что интересно, потому что вариантов очень много и нужно определить личные предпочтения. Очень важно, чтобы вы развивали и двигали свои навыки в подходящем окружении: это может быть какой-то личный помощник, карьерный коуч, ментор или бадди, то есть человек, который вам помогает или параллельно с вами учится чему-то. Наличие таких людей поможет вам не сбежать и чувствовать необходимость этого развития, не забить на все после первой трудности. Кроме того, если мы иногда смотрим на себя необъективно или обманываем себя, то внешний наблюдатель поможет нам с этим разобраться.
Помните о том, что стоит погрузиться в контекст нетехнических или околотехнических навыков. Например, послушать один раз в неделю полезный подкаст, сходить на конференцию, записаться в онлайн-школу. Имеет смысл зайти в какое-то сообщество заботливых и растущих вместе с вами людей. Я знаю несколько вариантов таких сообществ и готова с вами ими поделиться:
- группы Mastermind, например, создаются по возрасту или по интересам, там вы можете вместе с другими отмечать свой рост в тех или иных сферах;
- для дата-аналитиков рекомендую ODS AI, в особенности его подчасть – Nizhny Novgorod Data Science Breakfast, где всегда отличная атмосфера, можно собраться, обсудить разные рабочие вопросы, получить совет и поддержку;
- сообщество Woman in Big Data принимает не только женщин, как вы могли бы подумать, там тоже можно найти что-то для себя интересное;
- девелоперам рекомендую FAANG-interview preparation group, где можно найти замечательные вебинары, в которых люди из Google или Facebook делятся способами подготовки к интервью и так далее;
- языковые клубы, которые тоже открывают нам новые дороги. Они совершенно разные, их много, да и просто прокачать английский в хорошей компании всегда мега-круто.
Последний на сегодня короткий совет – не забывать про своего внутреннего ребенка, и то, что вы любите в своей работе, и с помощью этого понимания двигаться в сторону того, что вам интересно. Не надо себя перебарывать, мучить, скатываться в выгорание и депрессию. Сохраняйте легкий элемент игры и веселья, будьте приятным коллегой – этого всего реально достичь, главное, делать все бережно по отношению к себе. Если вы хотите еще поговорить на эту тему или у вас есть какие-то крутые карьерные устремления, которые вам нужно с кем-нибудь обсудить, то пишите на kate@antakova.ru.
Q&A
Q: У меня недавно был кейс: я какое-то время уже работаю тимлидом, веду свою команду, и тут к нам пришел человек, которому все не нравилось; процессы, код – всё ему казалось очень плохо, «давайте мы всё и сразу поменяем». Что вы думаете о таком подходе к делу, и как тимлиду правильно в таком случае себя вести?
А: Вопрос интересный, и не очень простой. С одной стороны, пришла обратная связь, с другой стороны, не в самой приятной форме, и вам, как тимлиду, да и всей команде довольно неприятно такие вещи слышать. Тут, конечно, нужна совместная работа, в зависимости от того, насколько ценен этот новый человек и какой степени мягкость нужно к нему проявлять. Вполне возможно, что какие-то вещи в вашей команде кажутся недопустимыми.
Обязательно нужно это с человеком один-на-один обсудить или повторить правила на открытом собрании, упомянуть вещи, которые ни в коем случае нельзя делать. Определенно нужна какая-то личная работа с таким человеком, чтобы он тоже что-то прорабатывал, как в старой советской пословице «Критикуешь – предлагай».
Если этот человек готов проявить свою лидерскую позицию, то можно предложить ему пилотировать проекты. Не нравится, как устроен процесс выкатки фич – давай создадим новый, но, естественно, этот процесс также нужно согласовать с вовлечением команды, лидеров, архитекторов и всех ключевых людей проекта, чтобы они не удивились неожиданно, что мы вдруг все поменяли. Если человек справится, покажет свое мастерство, то, наверное, можно расширять его полномочия.
Нужно установить правила, чтобы не было неприятных пинков друг от друга, и в то же время дать возможность в определенной песочнице случиться какой-то инициативе, которая для вас сейчас не критична, потому что вдруг есть какое-то объективное зерно в его суждениях, и действительно пришла пора поменять какие-то вещи. Если не получится, то думаю, это всем будет очевидно – и данному человеку и команде, что мы пытались, пилотировали, но не получилось, не подошло в наших обстоятельствах и сейчас для нас неактуально.
Q: Еще по поводу один-на-один митингов вопрос: если эти митинги рассматривать со стороны лида, то что хорошо было бы на них обсуждать?
А: Тут, если вы мне позволите, я обращусь к крутому инструменту, который нам предоставляет наше community, Егор Толстой и компания. Например, на них мы можем обсуждать мотивацию, что сотрудник от работы хочет, спокойствия и безопасности или риска и возможности заработать много денег, или он вообще в дальнейшей перспективе хочет стать менеджером. Прояснять конкретные настроения, ощущения подчиненного, карьерный рост и развитие и, конечно же, конкретные вопросы текущей работы.
Думаю, это все покрывается веткой, которая называется «ожидания» – что ожидается от данного сотрудника на неделе, в месяце, за полгода, год и так далее, чтобы были прозрачность, ясность, доверие; что мы хотели, что планируем, где находимся сейчас, к чему стремимся. Для молодых сотрудников часть этих встреч зачастую посвящается обучению – как культуре компании, так и тому, как решать рабочие проблемы.
Напоминаем, что больше видео семинаров вы можете найти на нашем youtube-канале.
