Переоценен ли инженерный процесс?

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

Эта статья – краткое напоминание о том, что действительно важно, и на что менеджеры инженеров (Engineering Manager) должны тратить свое время и силы.

За время своей работы я провел интервью со множеством людей. И каждый раз неизбежно вставал вопрос: “Как устроен ваш инженерный процесс? Вы agile-команда?” На текущий момент термины agile, scrum, спринт используются очень свободно, и я осмелюсь утверждать, что врядли мы все одинаково понимаем их значение. Как мы пришли от первоначального Agile-манифеста к тому, что имеем сейчас?

Процесс является ключевым моментом при формировании инженерных команд. На мой взгляд – это наименее важный аспект, но люди тянутся к нему, потому что он прост и легко осязаем.

Что действительно важно

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

Что необходимо для достижения этого?

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

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

Что может сделать технический руководитель чтобы удовлетворить эти требования?

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

Может ли процесс в этом помочь?

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

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

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

Вывод

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

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