Как тимлиду развивать себя и команду: принципы SOLID

team_lead

Сейчас я работаю менеджером проектов, но еще совсем недавно я был тимлидом, но понял, что мой путь лежит в другую сторону. Начинал я как и все программисты Junior, Middle, Senior, ну и вот это вот все. Каждый из нас там был, там будет и для того кто хочет стать тимлидом разработчиков — это правильный путь.

Если вы, мучались или продолжаете мучить себя вопросом: «Есть ли жизнь после Senior?», то отвечу сразу — есть. Это либо все тот же Senior, когда вы любишь писать код с закрытыми глазами, при этом помешивая ложкой свой кофе, и это на самом деле ок! Либо архитектор, либо тимлид. На последнем мы и остановимся.

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

Определимся, что с технической стороны тимлид определенно крут, но какими софт скиллами вы должны обладать на позиции Senior+ / Team Lead? Однозначный ответ дать достаточно сложно. Я собрал все необходимые на мой взгляд софт-скиллы для уровня Senior и выше в своей статье.

Проект, команда, стиль управления — это катализаторы различных навыков человека.

Разобраться с тем как тимлиду развиваться самостоятельно и помогать в развитии команде мне поможет принцип SOLID.

На первый взгляд, он направлен на стандартизацию и улучшение качества кода. Но если это так, то зачем размножать и без того описанные best practices? Будь то PSR, если говорить о PHP, или Coding Guidelines в случае с Java.

SOLID направлен на самодисциплину и культуру разработки. В своей практике я решил пойти дальше и применить SOLID для персонального развития всех и каждого в команде. Итак.

Что такое SOLID с точки зрения разработчика, который стремится в Senior+ level?

S — Smart

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

Это приводит к факту knowledge sharing. Делиться опытом или навыками — та еще головная боль. При неправильном подходе, например, выдаче готовых решений, которые генерируются на сверхзвуке, велика вероятность получить команду кодеров. Кодер — существо ленивое, но результативное. Результативное в тех случаях, когда нужно решить задачу в лоб по описанию тикета. Но стоит ему выйти из зоны комфорта и столкнуться с проблемами — впадает в состояние стазиса. Отключаются все органы и функционирует только один — «пойди к гуру, он точно знает решение».

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

O — Obvious

Учитывая факт, что тимлид заинтересован быть лидером (даже если вы Senior — это в любом случае необходимо), постарайтесь осознать фундаментальный принцип — «очевидно и прозрачно». Ваши решения, советы, разговоры за чашкой кофе на кухне должны быть очевидны для всех, с кем вы взаимодействуете. Каждый раз, оставляя подтекст в своих поступках, мы даем людям шанс на нерелевантные выводы. А если рассуждать в проекции на команду, то каждое непрозрачное решение, принятое вами, будет триггером закулисных игр. Однако не стоит уделять большое внимание объяснению своих решений — вы на той позиции, где люди не должны сомневаться в твердости и правильности вашего поведения.

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

Команда должна доверять своим лидерам или менторам. Начав с прозрачности, вы добьетесь очевидности в сознании людей.

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

L — Loyalty

Лояльность — композитное понятие. Она проявляется во многом.

В нашем случае, лояльность — двухстороннее понятие. Лояльность, проявляемая лидером, порождает лояльность команды.

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

Лидер — основной транспорт корпоративной культуры. Мост между ценностями и сознанием. Нет более подходящей роли, чем лидер, чтобы достучаться до разработчиков. Для вас у них уже открыты двери.

Занимайтесь внедрением культуры, но будьте уверены, что вы сами её понимаете правильно.

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

Наряду с решением конфликтов, хороший наставник уделяет время команде не только, когда требуется его помощь. Прислушивайтесь к коллегам, прокачивайте навыки. Давайте промежуточные честные и конструктивные отзывы об эффективности команды. Не стоит дожидаться Performance Review — людям важно осознавать свою значимость и пользу в коллективе.

Забудьте про микроменеджмент. Удерживайте баланс свободы и инициативности в команде.

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

I — Initiative

Тут все просто. Развивайте в себе навыки определения узких мест. Это может быть дырка в технологии или методологии. Внутренние процессы и стандарты. Или даже «мониторы должны смотреть на восход». Фундамент — это аргументация предлагаемых решений. Инициатива не проявляется в указании пальцем в сторону проблемы, а выражается в способах её решения.

Проявляйте инициативу на всех уровнях. Да, она наказуема, но вас это не должно пугать.

D — Driver

Любой ментор или лидер обязан быть драйвером своих падаванов. Они каждый раз будут смотреть на вас в сложных ситуациях. Достигнув уровня Senior+, вы попадете в ситуацию, когда каждое ваше действие имеет последствия. И иногда поспешные решения приносят много вреда. Все хотят быть частью продуктивной и успешной команды, но это трудно, если лидер не задает рабочий ритм. Не навязывайте свой подход к работе и тайм-менеджменту. Но и не скрывайте своей позиции. Просто делайте.

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

Следите за трендами и инновациями. При первой возможности пробуйте внедрять свежие технологии. Основной целью для вас должен стать профессиональный рост коллектива. вы достигли определенного уровня — помогите остальным сделать это быстрее!

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

Из личной практики, подобные навыки стали для команды триггером брать на себя дополнительные обязательства и проявлять интерес к управлению. Некоторые определили для себя рубеж, который необходимо преодолеть. А еще несколько месяцев назад на вопросы о своем развитии они отвечали: «Хочу улучшить свой код еще в N раз». Человеку нужна не только цель, но и методы достижения. вы как драйвер имеете уникальный шанс помочь с этим на своем примере.

В заключение

Я к сожалению не находился в ситуации, в которой были многие из нас: «Я сеньор, почему я должен выполнять менеджерские обязанности?». С момента как я проработал 1 год программистом я уже знал, что хочу развиваться в сторону менеджера проекта и шел к этой цели набивая шишки и ломая грабли. Да, мы можем развиваться и без вот этого всего, вопрос только — куда? А еще важнее — для каких целей?

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

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

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

%d такие блоггеры, как: