Иллюстрация к статье от animitate

В этом году я получил очень специфичный опыт тимлидерства. Мало того, что это был мой первый опыт тимлидерства, так еще и проекты нужно было стартовать с нуля, и команды были собраны ровно под эти проекты. Никто из нас до этого вместе не работал и не имел четкого представления об опыте, знаниях и возможностях друг-друга. Заспойлерю сразу, что проекты не совсем настоящие. Это часть учебной программы Engineering Doctorate (EngD) в техническом университете Эйндховена. Чтобы было понятно о чем идет речь вкратце опишу суть программы (если сама программа вам не интересна, то следующий абзац можно пропустить).

Об EngD

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

О проекте

В первом проекте команда состояла из девяти человек. Каждый член команды по умолчанию является разработчиком и в дополнение ему назначается определенная роль scrum команды. У нас были Software Architect, Project Manager, Product Owner, Test Manager, Quality Manager, Configuration Manager, Scrum Master и два Team Lead’a. Нам предстояло провести небольшое исследование и разработать прототип инструмента, который позволил бы проводить анализ качества электричества и предсказывать потенциально проблемные участки сети. Представитель компании в данном проекте предоставлял экспертизу в сфере производства электроэнергии. 

Проблемы и выводы

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

Неверная оценка возможностей членов команды

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

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

Выводы

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

2. Назначая задачу, нужно убедиться, что человек понял, что от него требуется и что он знает, что нужно делать. Это очень легко сделать, если просто попросить человека описать то, как он планирует работать над задачей

3. Явно проверять прогресс по задачам. Формат вопрос-ответ (Как там оно? - Нормально) не работает. 

Неявная коммуникация при постановке задач

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

Выводы

1. Уделять время написанию и постановке задач, разбивать задачи на мелкие куски

2. Поинтересоваться, как человек лучше воспринимает информацию. Текстом или через диалог

3. При общении нужно убедиться, что ты, либо тебя поняли правильно. Избегать возможности появления домыслов настолько, насколько это возможно

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

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

Выводы

1. В дополнение к скрам ретроспективам, проводить регулярные сессии для обмена знаниями

2. Сильнее вовлекать людей в ревью кода

Игнорирование гайдлайнов для работы над проектом

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

Выводы

1. Структурировать и приводить информацию в форму, удобную для восприятия

2. Проводить презентации и обсуждения

3. При коммуникации гайдлайнов объяснять, не только то, что нужно делать, но и то, что будет, если не выполнять эти гайдлайны. Объяснять, как это скажется на проекте и работе в команде, как это повлияет на качество кода, на сложность работы над проектом и на скорость выполнения задач

Непонимание того, что тимлид - это тимлид не только команды, но еще и сам себе тимлид

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

Выводы

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

P.S.

Во втором проекте мне довелось совмещать две роли (Team Lead и Configuration Manager) в команде состоящей из Software, Automotive и Mechatronics инженеров. Я ожидал, что выводы из первого проекта помогут мне значительно улучшить работу над вторым, но там я столкнулся с совершенно иными проблемами и наделал новых ошибок. Об этом будет написано в Опыт неопытного тимлида Ч.2. 

Полезные ссылки:

Про этапы формирования команд: Tuckman stages of group development

Про стили управления: Ситуационное лидерство: четыре стиля и необходимые качества