Дневник руководства SWE №1

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

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

1. Длинная петля обратной связи

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

Качество кода

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

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

Система сборки

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

  • Тестируйте на уровне PR, а не после слияния
  • Агрессивное кеширование зависимостей — Пример GitHub Actions

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

2. Избыток решений

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

  • Какое решение следует использовать для связи модуля A и модуля B?
  • Какой инструмент следует использовать для анимации элемента?
  • Как я должен задокументировать повторно используемый модуль, который я только что добавил?

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

Чем больше выбора вы предоставляете людям, тем больше помощи в принятии решений вам нужно предоставить. — Ричард Х. Талер, автор книги «Подталкивание: улучшение решений о здоровье, богатстве и счастье»

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

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

  • Однозначный
  • Высокая доступность
  • Поместите в контекст

Мой выбор для разработки надлежащей поддержки показан на рисунке 2.

3. Встреча с трудностями

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

Так что, даже если вы просто приглашенный участник, вы должны спросить себя, является ли встреча — и ваше присутствие — желательной и оправданной.

— Эндрю С.Грув, High Output Management

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

4. Взаимодействие между командами

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

  • Создание приветственных встреч с определенной командой
  • Создайте канал связи (например, Slack) с этой конкретной командой

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

5. Управление билетами

Вы должны проверить, сколько времени ваши инженеры тратят на следующие виды деятельности:

  • Обновление статусов билетов
  • Добавление тикетов и комментариев
  • Оценка

Две вещи могут сократить время, необходимое для обслуживания заявок: автоматизация и интеграция. Несколько примеров:

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

Краткое содержание

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

Спасибо, что прочитали эту статью.

Не стесняйтесь задавать мне вопросы в разделе комментариев, если у вас есть какие-либо проблемы!