×

Как тимлиду развивать себя и команду: принципы 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. Роман об управлении проектами»

Том ДеМарко «Человеческий фактор: успешные проекты и команды»

Ричард Брэнсон «Теряя невинность»

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




25 коментарів

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

100% согласен. Хочу добавить, что болезнь мертвых пней очень быстро распространяется по команде. Если в команде есть хоть один немотивированный, который делает абы как, то это быстро распространяется на остальных

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

По поводу факапов не совсем согласен. Как тимлид, я придерживаюсь философии: «Ошибки всегда мои, а победы — чьи-то». Так получается строить хорошую команду. В телеграм канале Заметки тимлида оцифровал свои размышления на эту тему Кто несёт ответственность за ошибки? Тимлид или команда?

Класна стаття, дякую! Автору успіхів!

«Троллей бояться на доу не ходи.»

Спасибо автору за статью. Считаю что статей по софт скилам должно быть больше, и главная причина почему они нужны, так это для того чтобы в Украинском айти перестало быть модно оскорблять друг друга или пытаться показать себя миру через язвительный коммент. Понятное дело это из разряда фантастики, но статьи подобные этой двигают молодые умы в направлении строительства команд, а не в сторону «я его слепила из того что было». Любой софт скил будь то SOLID или нет опирается на обычном взаимном уважении, если оно есть, то работать будет комфортно, если нет, то не будет. Кэп))

Владислав, отличный опыт и разработанный подход в управлении людьми. Вы молодец, что об этом написали!
Есть множество книг и литературы по менеджменту с общеизвестными подходами, привычными терминами.
Чаще всего подобную литературу и тренинги проходят в продажах и топ-менеджмент. Поэтому в этой статье наглядно видна гибкость мысли и желание развиваться дальше, а также стремиться к совершенству во всем (это называется японская система Кайдзен)
Конечно, эти знания и навыки нужно передавать в айти. Ведь ранее таких больших команд не существовало.
Уверен, все отзывы под статьей вас лишь вдохновят ещё больше развиваться и трансформировать известные методики в айти командах! Успехов!)

Как тимлиду развивать себя и команду

 На практике тимлид чаще всего сам тасков с борды не делает, в офисе и на рабочем месте бывает реже своего тима, чем подрывает их дисциплину, являясь по сути говорящей головой в скайпе или 1/2 погонщика. Или мне «везло» на таких тимлидов.

На мой взгляд лид от слова «lead» ведет за собой, подает пример, решает сложные и неприятные задачи. Ограждает свою команду от различных потоков гавна и идиотизма, принимая удар на себя, и оставляя своих людей спокойно работать. Пора переименовать лид в «1/2 чайка-менеджера».

А так можно было? Я вот как дурак задачи делаю, стараюсь чтоб команда видела мой вклад, а не только чесание языком на митингах, комментарии в мердж-реквестах и тикеты в джире. А можно даже на работу не ходить? Что-то мне кажется, что это контора виновата, что не приструнила такого «лида».

В двох різних компаніях навіть кавова машина рідко буває одинакова, а Ви порівнюєте таку складну річ, як і без того ефимерне поняття «team lead», яке залежить від сфери і типу бізнесу, бізнес процесів, технологій, розміру команди і тд і робите якісь недоречні, іронічні коментарі, недостойні професійного інженера.

> Любой ментор или лидер обязан быть драйвером своих падаванов

Гарна стаття, але оце останнє слово я б забрав. Воно відгонить «зірочкою» і зневагою до членів команди.

Согласен. Падаваны кофе подают, а в команде работают специалисты, которым такое именование будет оскорбительным.

Но готов ли ты делиться своими навыками с товарищами по команде?

Какие такие «навыками» сирёзно чувак? В почти 146% случаев в тимлид будет тот самый

перелік softskills для нормальної людини в будь-якому середовищі (к) (тм)

— и никакого больше «навыка» от слова вообще.

ЗЫ: хотя нет был не прав будет таки ещё гипертрофированый навык «делиться своими навыками с товарищами по команде» (к) (тм) что при условии почти 146% отсутствия таки чисто технических навыков особенно доставляет. Я проверял.

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

Санитары санитары!!!

... а ведь ещё только среда... ))

В принципі, перелік softskills для нормальної людини в будь-якому середовищі. А тут чи тімлід, чи ПМ — все рівно ти до цього дойдеш. Хтось набиваючи шишки, а хтось набиваючи половину шишок за рахунок читання різних книг та статей, на кшталт цієї.

Незважаючи на трохи невдалу, на мою думку, спробу перевизначити всім зрозумілий акронім, основний меседж — дуже правильний. Впевнений, що команді автора доволі комфортно з ним працювати.

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

Після багатьох років роботи як «code monkey», вирішуючи таск за таском і розраховуючи лише на себе, перехід в цей тип мислення дався мені не одразу і не легко, але відколи я відчув як це — працювати в подібній команді, я більше не хочу назад.
Більше того, такий підхід став для мене одним з вирішальних показників при пошуку роботи тепер.

Від себе додам, що також дуже важливим є створення культури психологічної безпеки в команді. Про це є доволі цікава стаття в New York Times Magazine — на жаль одного коментаря буде недостатньо для пояснення «чому» окрім «як».

Для повної картини опису статі автору вартувало б додати «7 навиків високоефективних людей» в список літератури. А загалом таке враження, що автор досяг професійного апогею, ставши лідом.
Не всі тім ліди були раніше сеньйорами, це радше про тех лідів.

Это ж надо было пальцем выковыривать сколько терминов, совпадающих с солидом. Можно на ваш проект? Вижу там делать нечего.

Какой-то неправильный SOLID. Это надо было назвать SOLID2

Забудь про «Я». Его больше нет, а на смену приходит «Мы».

Ага, вот прям щас.

Почему же ж? В плане ответственностей и конкретности задач самый торт! Я проверял. ))

Aleksey Rayev
Freelancer в Self-Employed

¯\_(ツ)_/¯

«Тема не раскрыта» — двойка! ©

S — Single responsibility principle
O — Open closed principle
L — Liskov substitution principle
I — Interface segregation principle
D — Dependency Inversion principle

зачем девов конфузить? :)

Ну переопределили аббривеатурку, бывает.

Тут год или два назад один персонаж жаловался что его, тимлида (или архитекта?) на собеседовании в Софт спросили что такое SOLID, что вызвало некоторое затруднение. Наверное коллега автора.

Кэп, перелогинтесь.

Но вообще да, если шутку надо объяснять, то лучше не объяснять.

со мной случился когнитивный диссонанс в случае с этой статьей (прочитал этот момент несколько раз, вдруг «я сам дурак») — потому очередной раз убедился, если слишком долго не озвучивать очевидное, то у некоторых оно мутирует в что-то не совсем очевидное для других...

SOLID уже не модно, сейчас модно писать код в стиле STUPID (Singleton, Tight coupling, Untestability, Premature optimization, Indescriptive naming, Duplication)

Підписатись на коментарі