Как тимлиду развивать себя и команду: принципы SOLID
Привет, меня зовут Влад, и я ... (нет, не то, что ты подумал) я — тимлид. «Войти в АйТи» случилось со мной в 2010 году на позиции системного администратора (или как сейчас стильно-модно-молодежно — SRE) маленькой сервисной компании, название которой нельзя произносить вслух :)
Дальше, когда я сменил профориентацию на разработчика, был Junior, Middle, Senior, ну и вот это вот все. Каждый из нас там был, там будет, и это единственный правильный путь.
Если ты, как и я когда-то, мучал или продолжаешь мучить себя вопросом: «Есть ли жизнь после Senior?», то спешу с ответом — есть. Это либо все тот же Senior, когда ты любишь писать код с закрытыми глазами, при этом помешивая ложкой свой кофе, и это на самом деле ок! Либо архитектор, либо тимлид. Давай на последнем мы и остановимся.
Последние два года я работаю на позиции Team Lead в компании Provectus. Моя команда насчитывает 11 человек. И за этот период я собрал опыт, которым и хочу с тобой поделиться.
Так, мы уже определились, что с технической стороны ты определенно крут, но какими софт скиллами ты должен обладать на позиции Senior+ / Team Lead? Однозначный ответ дать достаточно сложно. Слишком много переменных и обстоятельств. Проект, команда, стиль управления, бизнес-боли, которые ты лечишь, — все это катализаторы различных навыков человека.
SOLID. Что в себе несет аббревиатура, понимает даже Middle Developer. Но не каждый осознает, какую цель преследуют эти принципы. На первый взгляд, все они направлены на стандартизацию и улучшение качества кода. Но если это так, то зачем размножать и без того описанные best practices? Будь то PSR, если говорить о PHP, или Coding Guidelines в случае с Java.
SOLID направлен на самодисциплину и культуру разработки. В наших же практиках мы пошли дальше и применяем SOLID для персонального развития всех и каждого в команде. Итак, что такое SOLID с точки зрения разработчика, который стремится в Senior+ level?
S — Smart
Если ты читаешь этот текст, то уже заинтересован бежать вперед и не стоять на месте. Ты можешь с легкостью оперировать методологиями разработки, технологиями, языками программирования и т. д. и т. п. Но готов ли ты делиться своими навыками с товарищами по команде? Можно занять позицию «я прошел школу жизни, потратил овер-дофига времени и каждый должен так же». Вот только позиция эта не эффективна и эгоистична. При таком подходе я бы все еще добывал огонь из камня и ночевал в скале.
Окей. Мы с тобой пришли к факту knowledge sharing. Но к чему тут Smart? Делиться опытом или навыками — та еще головная боль. При неправильном подходе, например, выдаче готовых решений, которые ты генерируешь на сверхзвуке, велика вероятность получить команду кодеров. Кодер — существо ленивое, но результативное. Результативное в тех случаях, когда нужно решить задачу в лоб по описанию тикета. Но стоит ему выйти из зоны комфорта и столкнуться с проблемами — впадает в состояние стазиса. Отключаются все органы и функционирует только один — «пойди к гуру, он точно знает решение».
Smart заключается в предоставлении человеку возможности набить шишки, но при этом тебе, как опытному и повидавшему, нельзя допустить ситуацию, в которой он себе башку отобьет к чертям. Smart — это способность дать совет и убедиться в его правильном преподнесении. Задай своему напарнику верный вектор движения и не забудь, спустя некоторое время, поинтересоваться успехами.
O — Obvious
Учитывая факт, что ты заинтересован быть лидером (даже если ты Senior — это в любом случае необходимо), постарайся осознать фундаментальный принцип — «очевидно и прозрачно». Твои решения, советы, разговоры за чашкой кофе на кухне должны быть очевидны для всех, с кем ты взаимодействуешь. Каждый раз, оставляя подтекст в своих поступках, мы даем людям шанс на нерелевантные выводы. А если рассуждать в проекции на команду, то каждое непрозрачное решение, принятое тобой, будет триггером закулисных игр. Однако не стоит уделять большое внимание объяснению своих решений — ты на той позиции, где люди не должны сомневаться в твердости и правильности твоего поведения.
Каждая рабочая или жизненная ситуация — это сюжет, который имеет пролог, кульминацию и эпилог. Выдерживай очевидность и прозрачность на всех этапах. Посвяти людей в суть проблемы, предложи решение, покажи, как принятое решение продвигается, и не забудь про фидбэк.
Команда должна доверять своим лидерам или менторам. Начав с прозрачности, ты добьешься очевидности в сознании людей.
Из личного опыта, я не выдерживал достаточной прозрачности и очевидности своих действий в одной из команд. В итоге такой подход породил сомнения и недоверие команды к своему лидеру. А восстановить авторитет стоило больших усилий.
L — Loyalty
Лояльность — композитное понятие. Оно проявляется во многом, начиная от пропаганды культуры и до общения 1-2-1.
В нашем же случае, лояльность — двухстороннее понятие. Лояльность, проявляемая лидером, порождает лояльность команды.
Одно из важнейших качеств любого лидера — формирование культуры в команде. Очевидно, что культура может разделяться на внутрикомандную и корпоративную. Скажу из личного опыта — редко эти два типа живут, не пересекаясь. В исключительных случаях возможны тотальные различия, которые ни к чему хорошему в свою очередь не приводят. На практике же каждая уважающая себя компания или коллектив не позиционирует культуру, как догму. Руководители стараются достичь синергии между командами или отделами и извлечь общую пользу.
Лидер — основной транспорт корпоративной культуры. Мост между ценностями и сознанием. Нет более подходящей роли, чем лидер, чтобы достучаться до разработчиков. Для тебя у них уже открыты двери.
Занимайся внедрением культуры, но будь уверен, что ты сам её понимаешь правильно.
Учись идентифицировать конфликты, это важно. Не стоит тушить дом, когда горят все этажи. Эффективнее предотвращать пожары. Если же конфликт произошел — займи нейтральную позицию (даже если ты понимаешь кто прав, а кто нет). Прояви дипломатию и лояльность в отношении обеих сторон. И, оперируя принципом Smart, подтолкни ситуацию в правильном направлении. Переключи людей с конфронтации на поиск решения.
Наряду с решением конфликтов, хороший наставник уделяет время команде не только, когда требуется его помощь. Прислушивайся к коллегам, прокачивайте навыки. Давай промежуточные честные и конструктивные отзывы об эффективности команды. Не стоит дожидаться Performance Review — людям важно осознавать свою значимость и пользу в коллективе.
Забудь про микроменеджмент. Удерживай баланс свободы и инициативности в команде.
А как насчет геймификации? Это работает! Преобразуй рутину в соревнование, где соперником для каждого является его «Я», а целью — командные достижения. Пример из нашего опыта: каждый успешный pull request засчитывается в общий счетчик достижений команды. Достигая определенных значений, приложение выдает achievement и усложняет достижение новой цели. Если кто-то допускает критическую ошибку (например, в разрез прописанным стандартам разработки) — команда голосует, счетчик обнуляется и виновник торжества ставит всем пиво. Назвали мы это Beer Mistake. Чем дальше прогресс, тем пристальнее и ответственнее ребята подходят к решению своих задач.
С применением подобной геймификации мы получили метрики производительности. Да-да, всякие Jira считают Burn Down, но это не про клиентские или менеджерские графики. Это про внутреннюю производительность, которую оценивает команда.
Забудь про «Я». Его больше нет, а на смену приходит «Мы». Любой успех или факап — результат поведения команды. Поверь, если поначалу может показаться, что это удобный способ переложить вину на своего соседа, то спустя время каждый в команде осознает, что ошибка общая: один оступился, второй — не помог встать, третий — видел яму, но не сказал.
I — Initiative
Тут все просто. Развивай в себе навыки определения узких мест. Это может быть дырка в технологии или методологии. Внутренние процессы и стандарты. Или даже «мониторы должны смотреть на восход». Фундамент — это аргументация предлагаемых решений. Инициатива не проявляется в указании пальцем в сторону проблемы, а выражается в способах её решения.
Проявляй инициативу на всех уровнях. Да, она наказуема, но тебя это не должно пугать.
D — Driver
Любой ментор или лидер обязан быть драйвером своих падаванов. Они каждый раз будут смотреть на тебя в сложных ситуациях. Достигнув уровня Senior+, ты попадешь в ситуацию, когда каждое твое действие имеет последствия. И иногда поспешные решения приносят много вреда. Все хотят быть частью продуктивной и успешной команды, но это трудно, если лидер не задает рабочий ритм. Не навязывай свой подход к работе и тайм-менеджменту. Но и не скрывай своей позиции. Просто делай (тут пробежал Шайа Лабаф).
Показывай на своем примере сильные стороны своих взглядов. Но не акцентируй ни на чем. Поверь, люди сами начнут замечать необходимые им моменты.
Следи за трендами и инновациями. При первой возможности (а их у тебя больше, ты же авторитет перед менеджерами) внедряй свежие технологии. Основной целью для тебя должен стать профессиональный рост коллектива. Ты достиг определенного уровня — помоги остальным сделать это в два... нет! В три раза быстрее!
Ты не начальник. Ты — лидер. Никто не любит боссов, кроме человека-кодера, которому нужны четкие задачи и оплата. Мы в своей практике упразднили вертикальный стиль управления. Строгая горизонтальность! Junior ты или Architect, не имеет никакого значения. Твое мнение — это Грааль. Мы работаем ради общей цели, а различает нас только круг обязанностей. Лидер всегда находится в лодке, а не у штурвала. Управлять лодкой можно и без руля, общими усилиями ;)
Из личной практики, подобные навыки стали для команды триггером брать на себя дополнительные обязательства и проявлять интерес к управлению. Некоторые определили для себя рубеж, который необходимо преодолеть. А еще несколько месяцев назад на вопросы о своем развитии они отвечали: «Хочу улучшить свой код еще в 100500 раз». Человеку нужна не только цель, но и методы достижения. Ты как драйвер имеешь уникальный шанс помочь с этим на своем примере.
В заключение
Я находился в ситуации, в которой были многие из нас: «Я си-сеньор, почему я должен выполнять менеджерские обязанности?» Да, мы можем развиваться и без вот этого всего, вопрос только — куда? А еще важнее — для каких целей?
Команда — это больше, чем коллектив разработчиков, команда — это живой механизм для достижения общей цели. И в первую очередь — вашей цели.
Находите общий язык и вершите великие дела. Спасибо за внимание, у меня все :)
Полезное чтиво
Том ДеМарко «Deadline. Роман об управлении проектами»
Том ДеМарко «Человеческий фактор: успешные проекты и команды»
Ричард Брэнсон «Теряя невинность»
