За последние 10 лет мне удалось чередовать работу тимлида команды разработки из 3-5 человек (или как сейчас принято называть - техлида, хотя грань между этими понятиями часто размыта) с должностью сениор‑разработчика: после первого 3-летнего опыта тимлидинга я так устал и «выгорел», что на следующие 5 лет вернулся в кодинг, после чего уже более осознанно сделал вторую итерацию и опять стал лидом. Сегодня, оглядываясь на себя 10 лет назад, понимаю, что это совершенно два разных человека. Буду рад, если мой опыт станет полезен новичку, только ступившему на путь тимлида, а также услышать фидбэк от коллег по цеху, обменяться мнениями, мыслями, идеями.

Итак, первый инсайт, разбивший мои начальные представления, я прочёл в книге Т.Демарко и Т.Листера «Человеческий фактор: Успешные проекты и команды»:

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

Ведь правда, практически не бывает технологических проблем - перед нами не ставят задачи управлять самолётом через сайт или лечить больных с помощью тач-скрина планшета, хотя мы, наверное, уже близки. Все мы решаем повторяющиеся и в целом понятные задачи. Механизмы и инструменты давно переполнены методиками и best-practice. Однако постоянно появляются проблемы: в сроки не попали, пропустили баги, не учли важное и в итоге пришлось костылить и т.п, Конечно всё это легко объясняется нехваткой ресурсов, отсутствием чётких постановок, некомпетентностью исполнителей. Но если копнуть глубже, а затем наоборот - отдалиться и посмотреть шире, - открывается картина гораздо интереснее, которой и хочу поделиться в этой статье.

На самом деле эти основы интуитивно стали приходить ещё в первые месяцы моего тимлидства, когда еще абсолютно не понимал, какой стиль работы выбрать, с кого брать пример, ведь каждый руководит по-своему, работа является продолжением его личности. И когда нашёл им подтверждение в книге, претендующей на звание классики IT-управления, (а впоследствии и других, уже не IT-шных, например автобиографии Ричарда Брэнсона "Теряя Невинность"), они прочто забетонировались сознании, чему я благодарен и по сей день.

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

Итак, что же за аббревиатура ДДД?
Доверие - Делегирование - Драйв.
И хотя на этой схеме делегирование визуально стоит во главе угла, начать хочется с самого простого, понятного и базового - доверия.

Доверие

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

Действительно бывает так, но лишь с теми, кто изначально слаб и не замотивирован, кто плохо совместим с командой или компанией. Кто, по сути — и так не на своем месте.

Существует альтернативный подход — Жёсткий менеджмент. Желание самому всё контролировать неизбежно приводит к bottle neck на самом себе, потере инициативности в команде, интереса и драйва. Обычно такой стиль присущ начинающим руководителям: они чувствуют ответственность за результат всецело на себе, часто пытаются не упустить из виду любую мелочь, не пропустить ни одно решение без своего одобрения, хотя вовлечённость в детали и низкоуровневые компетенции со временем неизбежно будут падать. Более того, постоянно демонстрируя свой авторитет и доказывая превосходство одной библиотеки/компоненты/подхода над другими, они лишают подчиненных ощущения своей полноценности, самостоятельности и разумной свободы выбирать, пробовать и ошибаться. Вместо развития ответственности у них растет страх ошибки, проявления инициативы. В итоге работа сводится к тому, чтобы лишь бы закрыть задачу в джире и не быть наказанным. Работа в такой атмосфере превращается быстро в каторгу.
Но если приглядеться к стилю управления вышестоящих руководителей, можно заметить, что они лишь указывают направление, и практически никогда на конкретную реализацию типа «делай вот так и это, а затем то». Они ставят задачи, предусматривающую обязательную свободу выбора для достижения цели. Из этого плавно вытекает следущая неотъемлемая часть руководства — делегирование.

Делегирование

В учебниках говорится, что это передача полномочий от руководителя подчинённому. Но как это работает в реальной жизни? Не всё так просто.

Можно ли, например, делегировать поиск нового кандидата в команду, проведение интервью? По определению — да, это как раз передача полномочий. Но согласитесь ли вы полностью доверить выбор своему коллеге и не мешать ему принимать решение? А что если идеально подошедший ему кандидат окажется плохо совместим с вами по каким‑то личностным качествам? Скорее всего, вы тоже захотите участвовать в отборе или хотя бы принимать финальное решение. Но это же тогда не делегирование! А лишь постановка задачи первичного отсева кандидатов. Конечно, если у вас уже большая команда со сформированной иерархией, вы можете практически и не пересекаться с джуниором, и тогда вся ответственность за его онбординг и дальнейшую работу будет на сениоре, а вы лишь формальный руководитель. Таких случаев меньше, хотя бы потому, что большинство команд плоские, а при появлении выраженной иерархии их разделяют на более мелкие. И это, пожалуй, единственный путь роста тимлида до уровня выше.

Но обо всём по порядку.

Другой пример. Можно ли поставить задачу проанализировать требования и выбрать библиотеку для нового приложения? Я видел десятки таких задач, или даже «спроектировать архитектуру». Допустим, у команды стек PHP + Symfony, и задача сделать легко настраиваемую crud‑админку. Опытный разработчик выбирает, скажем, EasyAdmin. И с этого момента вы фактически делегировали ответственность за будущее этого проекта ему. Уже не получится через месяц сказать: «знаешь, EasyAdmin нам не очень подходит, т.к. нужна кастомизация каждого раздела и формы, здесь лучше бы подошла SonataAdmin или вообще самописные контроллеры. Но на этом каркасе уже построено много чего, поезд ушёл! Отказаться от этого и начать переписывать будет слишком дорого. Теперь это предстоит разруливать тому, кто решал задачу выбора фреймворка. Если вы будете продолжать как есть, потому что нет времени переделывать, код вскоре рискует превратиться в кровавое месево, и самое главное — ваши отношения с сениором начнут натягиваться. Если изначально вы ставили эту задачу именно как задачу, а не делегировали ответственность, с большой долей вероятности начнутся проблемы: человек ведь выполнил задачу исходя из имеющейся на тот момент информации, его опыта и предпочтений. Так что теперь это ваша проблема, нужно было точнее формулировать требования.

Но если вы делегировали всю ответственность со словами вроде „я хочу доверить тебе вести этот проект, принимать важные решения в нём, и фактически отвечать за него, а я буду оставаться ответственным формально перед руководством“, это уже совсем другая история: это ему показывает доверие с вашей стороны, открывает перспективы (что в будущем неминуемо вызовет желание финансового и карьерного роста, и к этому надо быть готовым), мотивирует к ответственности и инициативности — в общем всё, что поможет развивать и растить свою команду, и одновременно с этим вам позволит фокусироваться на более стратегических вопросах. Однако не стоит забывать, что люди, чувствуя свой успешный рост, спустя какое‑то время могут начать составлять вам конкуренцию. Зачастую страх этого и останавливает руководителей от полноценного делегирования. Однако скажу честно, за последние 12 лет в разработке я ни разу не видел ситуаций, когда руководитель взрастил сильную команду, и его в итоге вытеснили как ненужного. Для более высокого руководства такой тимлид — очень ценный ресурс, который способен не просто строить работу, а приумножать её и масштабировать. Таких сразу стремятся поднять на уровень выше и дать новые ключевые роли.

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

Драйв

Третья «Д» — это драйв, ощущение, кайф от процесса. Без него работа становится скучна, рутина съедает, перспективы отдаляются. О драйве можно говорить как о синониме счастья: у него нет однозначного рецепта и не может быть. Всё слишком относительно — в каждый период времени в каждой конкретной ситуации только сам человек может ответить, что сейчас его «драйвит». У кого‑то сейчас это — саморазвитие, изучение новой технологии или языка. У кого‑то — вовлеченность в важный проект, которым пользуется множество людей. А, к примеру, через год они могут поменяться местами. Но некоторые общие истины можно выделить: Если разработчики сохраняют свою причастность к общему результату, если их не изолируют друг от друга и от руководства, такая команда может свернуть горы. Тут мощно работает эффект синергии, когда 1+1 магическим образом равняется не 2, а 3. Очень важно не допустить перегрева этого движка, чувствовать настроения и грамотно реагировать. И поддержание драйва тоже заслуживает отдельной большой статьи из выжимки концентрата из лучших книг. Если же эта тема зайдёт, буду очень рад поделиться в следующей статье.

Заключение

И самое главное — Драйв усиливается Доверием и Делегированием, часто даже порождается ими. Как впрочем, и любые две Д в этом кругу усиливают третью Д.

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