5 главных ошибок ИТ-команды: как с ними справиться

Меня зовут Алексей Щеткин, я руководитель отдела в техническом департаменте PARMA TG. Начал управлять командами в 2014 году, до этого времени работал разработчиком, поэтому знаю «внутреннюю кухню». Сейчас я помогаю командам настраивать процессы и добиваться желаемых результатов.

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

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

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

Тимлиду важно научиться делегировать. С этой задачей справиться легче, если составить портрет нескольких дней — выписать все задачи и распределить их на три категории:

После этого — оценить ресурсы команды и распределить задачи между сотрудниками.

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

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

Благодаря общему обсуждению, постановка реализуется максимально прозрачно: понятны приоритеты коллег, сформировано единое понимание результата.

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

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

Классический кейс: задачи разработчиков уже спланированы на неделю. Руководитель проекта передает требование заказчика о новой функциональности. Чтобы реализовать доработку, сотрудникам придется задерживаться на работе несколько дней.

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

Продвинутые программы-планировщики помогут расставить приоритеты, видеть загрузку коллег, управлять смещением сроков проекта и минимизировать «овертаймы».

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

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

Найти баланс между реализацией нового и доработкой текущего помогут инструменты.

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

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

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

Работа с причиной ошибки. «Механическая» правка ошибок редко приносит результат — поток багов не сокращается. Стоит уделять время изучению деталей и анализу причин появления ошибок. Это способствует снижению количества багов.

Совместная работа над устранением багов. Это поможет быстрее обнаружить причины багов и сократить время на их устранение. Для такой работы стоит подбирать сотрудников одного уровня компетенций, чтобы распределение работы в паре было справедливым.

Каждая ситуация индивидуальна, но есть универсальный алгоритм:

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

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

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

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

Тимлиду важно разбираться в специфике работы команды. Личностные качества тоже важны — они помогут быстрее выстроить коммуникации и занять позицию сильного лидера.

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

Системное мышление поможет видеть картину в целом и грамотно расставлять приоритеты.

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

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

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

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

Уверенность, выдержка, смелость и открытость помогут в принятии непопулярных решений.

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