«О чем это я?» или вместо предисловия.

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

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

Чего в статье нет: «золотых правил идеального тим-лида», детально-пошаговых инструкций по разрешению конфликтов и прочей нравоучительной нудятины.

Как “рождаются” тим-лиды?

.. известно как - назначают.

У вас бывало такое: «Сижу, никому не мешаю, починяю примус..»,  то есть делаю свою работу и не отсвечиваю, не задаю лишних вопросов, как вдруг возникает задача – «Надо б тут кой-чего сделать для команды, ты как»?

Разумный ответ в наше специфическое время звучит так: «Конечно!», «Не вопрос!» и т.д. — и это несмотря на многие внутренние «но» и прочие оговорки. В целом, мы «за любой положительный движ», главное, чтобы понятно было, что от нас требуется. Ну а дальше следует логичный вопрос: «А что, собственно, сделать-то надо?».

И вот тут выясняется, что в команду нужен тим-лид, и как-то вот так получается, что эту роль предлагают именно вам. И не потому, что больше некому, а вот «Потому что ...». Ну, вы поняли. Конечно, если ранее опыта подобной работы у вас не было, резонно может возникнуть вопрос: «А достоин ли я? Справлюсь ли?». Тут просто — если «выдали погоны», значит достоин. Иначе не бывает. Такие привилегии и обязанности (отож!) просто так не доверят и не доверяют.

Что делать-то теперь?

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

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

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

Причем условные проблемы могут быть самые разные.

Из банального: зоопарк веток в общем хранилище кода. Более того, названия у веток такие, что сходу не поймешь, кто автор, в рамках какой задачи и зачем он это сделал. Раздражает? Меня — весьма. В общем проектном репозитории веток должно быть минимум, с понятными, самообъясняющимися именами. А если их много, то обязательно должен быть документ с описанием структуры репозитория. Еще более банальное — отсутствие централизованного места структурированного хранения проектной информации. При этом оно, скорее всего, есть, но почему-то не наполняется так, как надо. Или, еще пример, отсутствует CI,  и хорошо б его уже настроить и подключить автоматические тесты для всего проекта с  рассылкой писем счастья всем участникам и т.д. Из более глобального — это согласование с клиентами требований на разработку, технических деталей реализации той или иной части проекта (да, есть и такое). Кроме того, распределение и контроль выполнения задач командой, помощь в адаптации новых сотрудников в команде и т.д., и т.п.

«Пфф, ничего особенного», – заметит читатель. — "Все же понятно, зачем ради такого было сей опус городить?». И даже будет в чем-то прав. А в чем-то — нет. В нашем деле [1] есть набор нюансов, которые, будучи помноженными на специфику конкретной компании и её клиентов, порождают тот самый «некоторый набор проблем», требующих, чтобы кто-то с ними работал на регулярной основе. Одним из таких «кто-то» и становится тим-лид.

Про процессы в команде

«Торопиться не надо, не надо торопиться» (с)

И вот преисполненные собственного величия… ан нет, это из другой оперы. В общем, мысленно засучив рукава, приходим на старую работу уже в новом амплуа, готовые свернуть горы и сделать все «как надо». Но, заняв рабочее место, сначала просто стоит вдохнуть поглубже и подумать.

С чего именно начать? А надо ли что-то менять в уже устоявшемся процессе? Это скорее всего первые вопросы, которые нужно себе задать, когда в руки попадает «метла управления». Вещь эта — обоюдоострая, ею можно как реально «навести порядок», так и легко и непринужденно поломать все, что было уже выстроено до нас, ввергая команду в хаос (“Во славу Императора!”). За последнее, впрочем, по голове не погладят, но это и так очевидно, так что останавливаться на этом не будем. А для вдумчивого процесса выстраивания потребуется и время, и помощь, и даже консультации непосредственно с командой на тему «Как стоит или не стоит делать».

Таким образом, если очень грубо, ситуации возможны две:

1. Есть уже существующая, сформированная команда, которая лишилась предыдущего тим-лида.

2. Команды или еще нет совсем, и вы в ней первый участник, либо команда находится на стадии формирования, когда и людей в ней почти нет, и процессов тоже.

Что же нам необходимо? О каких таких пресловутых процессах вообще речь? Да все банально: задачи, их выполнение командой, контроль, отчетность и приемка работ внутри команды.

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

Что от вас здесь потребуется?

Умение формулировать задачи для коллег с четким понимаем того, что надо сделать (requirements) и, желательно, в какие сроки. Очень пригодится привычка записывать все оговоренное по задачам, где бы то ни было. Кроме того, нельзя забывать про т.н. «критерии приемки» (definition of done), которые также необходимо формулировать и доводить до разработчика. В сухом остатке, — это постановка задач разработчикам [2] и контроль их выполнения.

Кроме того, для согласования задач с клиентом также потребуются некоторые навыки системного аналитика. Это если вам не повезло, и нет готового специалиста «под руками».

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

Вы спросите: «А как же “product owner”?». Ведь задачи, "бэклог" и его наполнение, приемка работы — это его прямые обязанности. Я вам-таки отвечу — да, все так, вы абсолютно правы, и замечание справедливо. Но в идеальном мире. В реальном мире оно устроено далеко не всегда так, как хочется «по процессу».

Также на плечи тим-лида ложится и обработка результатов работы: сначала внутренняя (читай «code-review», «acceptance testing», и вот это вот все), а затем внешняя, где результаты работы уже демонстрируются и передаются клиенту. Если не хочется потом краснеть за качество работы коллег перед клиентом, то имеет смысл проводить пред-приемку локально. И в целом требовать от коллег определенного уровня качества в работе.

А еще не будем забывать про CM (Configuration Management) и контроль того, что происходит в общем репозитории системы контроля версий проекта (git, svn, etc). Если в команде нет отдельного человека на эту роль, то придется и эту область тоже взять под свой контроль. Noblesse oblige (sic!), что поделать.

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

Резюмируем этот не самый короткий блок текста (обещал не «нудеть», но не получается, увы). Что же надо уметь делать (и непосредственно применять эти умения) в новой/молодой команде:

1. Проводить с клиентом обсуждение им же сформулированных требований (обязательное мероприятие!).

2. Формализовывать требования при непосредственном участии клиента (в идеале).

3. Оценивать трудозатраты на выполнение каждой из формализованных задач.

4. На основании согласованных требований (работа с задачами):

   1. формализовать, назначать, отслеживать выполнение задач и контролировать результат;

   2. помогать новым сотрудникам с деталями проекта;

   3. помогать команде с выполнением задач.

Выглядит не особо сложно, не правда ли? В целом, да.

Оценка сложности выполнения, (i.e.) трудозатрат

Из формального описания рождаются требования.
Из требований рождаются задачи.
Задачи требуют оценки.
Оценки рождают план.
План порождает сроки.
Сроки порождают боль.

Отдельно хотел бы заострить внимание на этом важном моменте. Помимо всего увлекательного, описанного выше, есть еще оценки трудозатрат, которые также надо и готовить, и «ревьювить». Но здесь уже неудивительно. Оценить трудозатраты мы (в идеале — все) должны и обязаны уметь. Хотя бы приблизительно, даже если какой-то проект видим впервые. Сложнее все же договориться с клиентом об однозначном понимании результата работ. Хорошо бы иметь некоторую форму, шаблон, возможно, даже согласованную с клиентом, и понимание, как оценивать трудозатраты. Если у вас не было опыта в этом плане,  то имеет смысл ознакомится с методологией — например, модели COCOMO I/II, PERT-оценка и т.д.

Ну и дальше уже проще – оценки обязательно (!) должны проходить «ревью» (а  то мало ли, что там нафантазировали) и согласовываться. С кем? С менеджером проекта и клиентом в том числе. Дальше из оценок строим план, набираем/распределяем задачи и ..? А больше нет никаких «и» – далее работаем работу по подготовленному нами же плану.

Прививаем коллегам привычку следовать процессам

Привести осла к воде может каждый,
но не каждый сможет заставить его пить.

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

В процессе уже выяснилось — все можно разжевать, продумать, прописать и проговорить. В плане, как и что делать, чтоб и клиент был счастлив, и исполнители на своей стороне не «упоролись» в процесс ради процесса. Но по факту далеко не всегда люди сразу и с удовольствием следуют предложенным правилам.

Здесь я для себя вынес одно: надо разъяснять. Всем сразу, а если надо, то и каждому в отдельности. Приводить примеры, как бывает, и к чему приводят те или иные упущения в процессе работы. И неудивительно, что люди при таком отношении вполне адекватно реагируют. Работа с коллективом — вещь весьма нетривиальная, на мой взгляд, и требует аккуратности и деликатности.

Работа с несознательными

Если споры там возникнут – сразу снять!
Бить не нужно, а не вникнут – разъяснять!

А еще может оказаться, что после доведения деталей и требований процесса, кто-то из коллег скажет: «А я не считаю нужным делать вот то и это...» или «Мы на прошлой работе так не делали, и все было хорошо». Или даже: «Я тут поспрашивал у своих коллег по прошлой работе – так никто не делает». И «привет» всем “наполеоновским” планам, да и не только. Как быть? На каком основании строить свою руководческую «политику»?

Да, такое тоже бывает. Более того, когда таковой прецедент возникает, его нужно сразу купировать, иначе дальше это может оказать большое влияние на команду. Как правило, негативное. Легко сказать — «купировать», а как? По сути, может статься, что требования процесса порождены требованиями клиента/заказчика. Например, необходимость оформления истории коммитов в системе контроля версий.

Как мы все знаем, помним и понимаем: «Авторитет — не есть довод», как сказал кто-то из великих [3]. И продавливать свою точку зрения с позиции авторитета и положения не стоит. В подобном случае, повторюсь еще раз, необходимо снова и снова разъяснять для такого коллеги суть требований, причины и, возможно, их первоисточник. Но на этом полномочия тим-лида, скорее всего, и заканчиваются, т.к. если оппонент продолжает упорствовать, то эту проблему имеет смысл  (а это уже проблема) переводить в плоскость непосредственно менеджмента и HR.

Или вот, например, еще вчера мы вместе пили кофе, шутили и, в целом, прокрастинировали в рабочее время. А сегодня вы приходите в ту же условную «курилку», к тем же коллегам, с вопросом: «Вася, а где обещанный тобой вчера PR/MR (прим. переводчика: запрос на внесение изменений в общую кодовую базу)?». И вся «курилка» хором: «Фи, мы-то думали ты нормальный, а ты вон — какой! Вот что власть с людями-то делает!». С одной стороны, это может быть просто троллинг вас как нового, «молодого» тим-лида, а с другой, некоторая точка зрения, что вы все еще «свой рубаха-парень», и ваши требования-решения и даже указания/распоряжения всерьез не воспринимаются. Опять же, ничего нового, если это была шутка – отшучиваемся в ответ, с отсылкой на то, что работу надо работать и т.д., а если не шутка, то гнем свою линию, потому что требования есть требования, и работа есть работа, но уже в более формальном, прохладном тоне. Если ничего не помогает, ну что ж, мы сделали, что могли — вызываем Рэмбо обращаемся за помощью к менеджменту и/или в HR.

И когда все получилось

И главное — а как понять, получилось ли или нужно еще и еще что-то доработать, исправить и т.д.? Как мне видится, каждое решение должно получить некоторое время на работу. По сути, здесь ничего нового: «практика — критерий истины». Только посмотрев, как работают те или иные решения, можно оценить их правильность или неправильность (бывает и такое, шоужтам).

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

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

И вот наконец, проект/задача завершен/сдан — ура, овации и цветы, девушки бросают вверх чепчики... ну дальше сами фантазируйте, взрослые люди же, а мы тут серьезные вещи обсуждаем. :)

Или (если) не получилось...

“shit happens. nuff said.” (c)[4].

Печально, но факт. Случается, что задача или какой‑либо их набор были либо сорваны по срокам, либо не удовлетворили качеством клиента. Прежде чем пороть горячку и посыпать голову пеплом, все же имеет смысл вдохнуть поглубже и подумать на тему: «Как так получилось, и что стало причиной?». И крайне желательно, чтоб причина была выявлена, четко очерчена, понятна, и понята всеми участниками событий.

По моему мнению‑опыту, свои ошибки необходимо признавать, и учиться не только их исправлять, но заранее стараться предвидеть потенциальные проблемы, которые могут возникнуть на тернистом пути как всей команды в целом, так и конкретно взятого её члена, а также разрабатываемого продукта. Здесь и литература в помощь, и «старшие» товарищи с их опытом будут нелишними.

Итоги

При организации процесса работ, повторюсь, коллегам все же нужно объяснять смысл своих решений. Это важно. Почему важно? Потому что именно кадры — это самый ценный актив. Помните старую фразу: «Кадры решают все!»? С тех пор ничего не изменилось. Еще вариант: какие‑то тонкие моменты по рабочему процессу решить коллективно, а‑ля «в курилке». Почему? По моему мнению, вовлечение в проект помогает всем набираться опыта и понимания, как организовывать те или иные моменты в работе команды. Кому‑то и пригодится потом, как знать. Кроме того, таковым подходом, как мне кажется, важно показать, что коллеги по команде — это не какие‑то там производители строк кода, а квалифицированные и уважаемые сотрудники, чье мнение также имеет вес и учитывается. Здоровая дискуссия имеет право быть.

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

При планировании работ время на подготовку оценки трудозатрат никогда не бывает потраченным впустую. Даже если эта оценка «пальцем в небо», и клиент с ней согласен, формально её необходимо провести через процесс и зафиксировать со всеми оговорками и допущениями.

Про ответственность. Увы, но с «погонами» приходит и ответственность за деятельность всей команды. К этому надо быть морально готовым заранее или тренировать себя в процессе. Демонстрировать результаты работы вышестоящему руководству, а, возможно, и непосредственно клиенту, придется именно вам.

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

Невредные советы

Что здесь хотелось бы отметить сразу как главное? Не надо стараться делать все самому, делать «как надо». Всего «в одну каску» не сделать, даже пытаться не стоит. Делегируйте. Для этого есть и команда, и собственно тим‑лид, который еще и технический эксперт (если совсем не повезло). Причем с ростом команды делегировать имеет смысл и функции/обязанности тим‑лида, т. е. дробить большую команду на мелкие. Организационный принцип деления здесь — по проектам, по экспертизе, да как угодно. Главное, не замыкать все технические вопросы только на себя. По итогу преобразований необходимо будет сделать выбор: оставаться на уровне управления одной из таких новых/старых команд или идти дальше по карьерной лестнице, т.к. управление несколькими командами — это уже следующая ступень, по моему скромному мнению.

При обсуждении задач и требований с клиентом необходимо выработать однозначно понятную обеим сторонам терминологию и фиксировать всё и вся в почте. Либо еще как‑то, но чтобы всегда было понятно, что именно и для чего мы делаем. Ну и чтобы не было потом мучительно больно от осознания упущенной детали при подготовке и согласовании задач(и). Да, я уже говорил, что это, скорее, работа product owner‑a, нежели тим‑лида? Тем не менее будем готовы и к ней.

Планируйте свое время. Почему это важно? Потому что роль тим‑лида отличается от роли рядового разработчика уже тем, что именно он координирует общую работу команды. И эта деятельность плотно связана со всевозможными совещаниями: как с клиентом, так и с непосредственным руководством, как источниками этой самой работы. Очевидно, что все это требует времени, которого всегда, особенно на старте проекта, остро не хватает. И это еще одна из причин, по которой необходимо выстраивать рабочие процессы как для команды, так и для себя лично. В числе последних, но не последних по приоритету (!) — личное расписание. В этом личном графике должно быть время на совещания с руководством и клиентом, на общение с командой в общем и индивидуальном формате (и это тоже важно!) — и на непосредственно собственную работу, которую, несмотря на новое положение, никто не отменял.

Умейте сказать «нет». Да, бывает и такое, что нет возможности провести с клиентом/руководством внезапную встречу по какому‑то срочному вопросу. Важно уметь не отказать, но предложить решение, например, с переносом даты важного совещания на другое время (день).

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

1. “нашем деле”– я имею в виду разработку ПО в целом, без привязки в какой-то либо конкретной области;

2. формальное описание с учетом проекта, требований и критериев приемки и “вот это все”;

3. Борух Спиноза;

4. «Shit my dad says» J. Halpern;