Проблемы в работе с технической командой. Шпаргалка для менеджера

23 декабря 2021

  • Автор: Алексей Голубев

  • Сложность: легко

  • Время: 5 мин

Для проектного менеджера, создание любого продукта — это общение с клиентом, организация работы команды и контроль выполнения поставленных задач в установленные сроки. В случае с внедрением нового IT-специалиста, в процессе реализации проекта часто возникает ряд проблем, которые всем мешают. Что это за проблемы и как их решать, рассказал Lead Software Engineer at SoftServe Алексей Голубев.

Это четвертая статья цикла «Шпаргалка для проектного менеджера». В первых трех говорили про интервью с девелоперами, онбординг IT-специалистов и эстимейт от разработчиков.

Проблемы во время реализации проекта

Слишком объемная «таска»    

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

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

Сложная задача

Иногда во время эстимейта технический специалист может ошибиться в оценке, и уже в процессе понимает, что задача слишком сложная для него. В этом случае для PM-а есть два варианта решения: пригласить стороннего эксперта (если вопрос в домене или технических моментах, с которыми ранее никто в команде не сталкивался) либо организовать investigate для своего подопечного. С точки зрения усиления и развития команды, второй вариант предпочтительней при условии, что нет рисков по срывам сроков.

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

Например, сервер держит одновременно 100 запросов, а нужно расширить до 1000. Разработчики в команде не знают, что делать: подключать еще один сервер, новую библиотеку или настроить стороннее ПО. Чтобы решить проблему, создается отдельная задача под investigate c выделением определенного времени конкретного специалиста для изучения данного вопроса. По завершению сотрудник приходит с отчетом о проделанной работе и вариантами, что можно сделать. В итоге выбираете наиболее приемлемый способ решения задачи. Аналогичная история может быть не только с техническими вопросами, но и с бизнес-составляющей проекта.

Сомнения в качестве работы девелоперов

Хотя бы раз в своей карьере, каждый Project Manager задавал себе вопрос, действительно ли сотрудники так хороши в профессиональном плане, как казалось во время их найма на работу. Чаще всего сомнения возникают, когда в частях проекта, за которые отвечает конкретный специалист, постоянно появляются баги. Явным индикатором того, что разработчик или разработчица плохо справляются со своими задачами, служат замечания тестировщика (QA-инженера), появляющиеся с заметным постоянством. Поэтому, если увидите множество задач от QA к конкретному техническому специалисту, вводите код ревью. Это значительно снизит число ошибок, поможет избежать рефакторинга.

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

баннер TechMind

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

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

Церемонии: а тут что не так?

Церемонии в широком понимании этого слова — это ретро, дейли и другие подобные встречи. Они должны помочь сплотить команду воедино, сделать ее работу более эффективной. Только вот не всем разработчикам и другим IT-специалистам они нравятся, некоторые и вовсе считают церемонии пустой тратой времени. Отсюда и появляются следующие проблемы:

  • Саботаж. Специалист игнорирует встречи либо ходит на них исключительно из-за того, что так сказало начальство. Тут важно уточнить, в чем причина такого поведения. Возможно митингов очень много, поэтому сотрудники на них не успевают либо  не видят в них ценности. В первом случае проектному менеджеру стоит подумать об оптимизации количества митингов и их длительности. Во втором — нужно донести полезность подобных встреч для команды и работы в целом.
  • Пассивность. Частая история, когда часть команды активно участвует в обсуждении вопросов на встречах, а остальные выступают в качестве вольных слушателей. В итоге эффективность подобных мероприятий далеко от 100%. Поэтому, если видите, что кто-то постоянно просто «отбывает повинность», обязательно уточните у этого человека причину нежелания участвовать в обсуждениях. Возможно он или она стесняется (часто такое можно заметить за новичками в команде). Исходя из этого принимайте решение, как в дальнейшем проводить встречи.
  • Падение перфоманса. Обычно происходит, когда каждый день проходит много митингов или они неудобно расположены в общем графике. В итоге разработчики быстро устают, а их рабочая эффективность падает из-за рваного темпа. Чтобы подобного не происходило, составьте удобное расписание встреч и скорректируйте их количество.

Это основные проблемы, которые связаны с церемониями на протяжении всего времени реализации проекта. Теперь давайте поговорим о том, что и как может сделать Project Manager, чтобы повысить эффективность новичка и команды в целом.

Налаживаем работу команды IT-специалистов

«Важней всего погода в доме» — отличная фраза, которая характеризует принцип эффективной работы любой IT-команды. Если внутри коллектива царит дружеская атмосфера, есть взаимопонимание и правильно организовано взаимодействие между специалистами, — результат общей работы в разы лучше. Чтобы достичь этого, PM может использовать следующие инструменты:

  • One to One встречи. На тех же ретро далеко не каждый сможет высказать свое недовольство работой кого-то из коллег. Аналогичная история с рассказом о видении своей роли в коллективе и в целом о проблемах в нем, о предложениях и идеях по улучшению работы. На встрече tet-a-tet для многих это сделать проще, чем во время обычных митингов, при условии, что PM создаст доверительную обстановку. Здесь ваша задача, как проектного менеджера, максимально узнать о тревогах и желаниях своего подопечного, найти к нему подход и помочь найти решение проблем, связанных с ним и работой в команде.
  • Team building. Что может быть лучше «для склейки» коллектива воедино, чем  общение вне работы? Только это должно быть мероприятие, которое понравится всем. Задача PM-а в данном случае — спланировать team building, аргументировать его проведение перед руководством (и получить бюджет), организовать и провести.
  • Ротация. Обычно под этим подразумевают удаление или замену «токсичных» людей в команде. Бывают ситуации, когда человеку просто надоел проект. Тогда лучше его отпустить и перевести на другой, чтобы такой специалист остался внутри компании. Так вы всегда сможете к нему обратиться в случае необходимости. Например, взяли кого-то на его позицию и необходим быстрый онбординг на ваш проект. Обычно в подобных случаях не отказывают в небольшой помощи.
  • Разделение на зоны ответственности. Далеко не всегда необходимо это делать, но порой эффективней часть обязанностей проектного менеджера разделить между участниками команды. Например, тот же deploy. Нет смысла тратить время на обучение всех разработчиков, что и как нужно делать, когда можно эту задачу поставить на кого-то одного и сделать его ответственным. Тут важно, чтобы вы, как руководитель команды, правильно выбирали людей под ту или иную задачу.

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

Алексей Голубев

Lead Software Engineer в SoftServe. Эксперт в разработке веб-приложений и кроссплатформенных решениях под мобильные устройства и персональные компьютеры. Основной стек разработки .NET и JavaScript, full-stack разработчик. Строил малые PоC-решения и большие проекты для государственных структур.