Не позволяйте этим ошибкам разрушить производительность инженеров

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

За последние 10 лет работы разработчиком и инженером-менеджером я заметил несколько ошибок, которые наиболее негативно повлияли на производительность инженера:

Многократная смена инструментов

Существует множество инструментов управления проектами. Некоторые из них представляют собой целые наборы с кучей плагинов (например, JIRA), а другие — гораздо более легкие решения (например, Trello). Точно так же существует множество мнений о том, какой инструмент лучше. Это может означать, что некоторые люди хотят использовать тот же инструмент, который они использовали в течение последних 5 лет, потому что они знают его и это удобно, в то время как другие хотят прыгать и пробовать следующую новую вещь.

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

Как избежать

  • Не выбирайте новые инструменты в вакууме. Возможно, у кого-то уже есть опыт работы с инструментом, и он знает, почему он подойдет или не подойдет вашей команде. Может быть, инженеры предпочитают инструмент с разными представлениями, а исполнительной команде нужен инструмент, который может создавать определенные отчеты. Получите несколько входов.
  • Выберите свой набор инструментов и придерживайтесь его в течение определенного периода времени. Это не означает, что вы не можете оценить новые инструменты, но как только вы решите использовать что-то, вы должны дать команде шанс преодолеть первоначальный барьер «использовать что-то новое». Установите количество времени, которое кажется разумным для всех.
  • Знайте, когда вам следует измениться. Если инструмент стал настолько плохим, что все жалуются или шутят о нем, есть вероятность, что они избегают этого инструмента и, вполне возможно, фрагментируют информацию, работая вне его в инструменте. они больше нравятся.

Изменение методологий

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

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

Как избежать

  • Знай свою команду. Если ваша команда привыкла к быстро меняющейся среде в стиле Канбан, не пытайтесь внедрить Scaled Agile Framework (SAFe). Постарайтесь выбрать методологию, которая хорошо сочетается с характером вашей команды и предпочтительным стилем работы.
  • Знай свою отрасль. С другой стороны, если вы работаете в строго регулируемой отрасли (например, в здравоохранении), процессы SAFe могут вам подойти.
  • Не будьте фанатиком. Независимо от того, какую методологию вы используете, ее можно адаптировать в соответствии с вашими потребностями. Некоторые настройки могут быть действительными и хорошими, но просто убедитесь, что вы не скрываете настоящие проблемы. Никакие правила необходимы для точного соблюдения, и люди, которые навязывают правила команде ради правил, подрывают моральный дух.

Позволить менеджеру по продукту управлять командой разработчиков

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

Управление продуктом/проектом и инженерия — разные дисциплины. Хотя они должны работать вместе, у них разные сильные и слабые стороны.

Как избежать

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

Узкофокусные показатели

Заманчиво иметь одну метрику, которая является ключевым показателем того, как работает команда инженеров, но такой метрики не существует. Я уже писал ранее о том, что команды иногда попадают в ловушку, используя Velocity как самую важную метрику, но то же самое может случиться с любой метрикой. Разработка программного обеспечения (особенно в больших командах) — очень сложная система, и попытка сосредоточиться только на одном показателе сильно упрощает ее.

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

Как избежать

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

Какие ошибки управления проектами стоили вашей инженерной команде времени и денег? Как вы к ним обращались?