This is part 3 in a series on project management for software engineers.

Легко попасть в ловушку, используя неформальные беседы для продвижения вашего проекта.

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

Мы должны быть настроены на совместную работу.

Мне нравится иметь в виду дух антигениального придурка. Антиблестящий рывок:

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

Вот 7 дискуссий, которые стоит пересмотреть с учетом этого:

1. Обзоры дизайна

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

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

Очевидная польза обзоров дизайна состоит в том, чтобы избежать ловушек. Здорово, когда истерзанный войной инженер может объяснить: «Я видел что-то подобное в прошлом, а потом пришлось исправлять это другим способом».

Делайте все возможное, чтобы учитывать обратную связь — не прячьте голову в песок.

2. Каналы связи

Два основных канала связи для проектов — это слабый канал и группы электронной почты.

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

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

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

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

3. Стендапы, ориентированные на проект

«Мне не нужно, чтобы ты говорил мне, чтобы я выступал».

Да, нет. Вероятно, у вас есть стендапы, которые кажутся пустой тратой времени. Или, может быть, вы пробуете новое увлечение писать свои стендап-обновления (тоже пробовали, не сработало).

Самые эффективные стендапы, в которых я участвовал, касались конкретных проектов. Они сосредоточились на одном проекте, в котором все активно сотрудничали. То, над чем я работал вчера, влияет на то, что вы делаете сегодня.

Кто-то может сказать: «Я пытался запустить это, но постоянно получаю эту ошибку». И я могу сказать им: «Вот вики, которую я написал о том, как решить эту проблему. Извини, я не сказал тебе раньше».

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

4. Общайтесь один на один

До COVID вы могли подойти к столу товарища по команде, чтобы решить проблему.

Мы обсуждали что-то в slack, а потом спрашивали: «Вы можете поговорить об этой проблеме?» "Конечно." Я бы подошла. Может быть, отвести их к ближайшей доске и нарисовать схему системы.

Или мы обсуждали проблему за обедом. «Можете ли вы объяснить ту вещь, над которой вы работаете? Я все еще не понимаю». И я уходил со словами: «О, вот как это работает».

Равные один на один, к сожалению, неестественный способ сотрудничества.

Мой совет: держите их в неформальной обстановке и относитесь к ним как к возможности для взаимного обучения.

6. Обсуждение дизайна

Команда, собравшаяся вокруг доски, — классический инструмент совместной работы.

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

Документируйте текущие проектные решения, чтобы инженеры в будущем знали, почему были приняты те или иные решения.

7. Проектно-ориентированное планирование спринта

Как и стендапы, несфокусированные встречи по планированию спринта могут наскучить вам до слез.

Ключ к успешному планированию спринта — сфокусироваться на одном проекте.

У нас есть две дюжины задач, которые нужно оценить и расставить по приоритетам. Идем задание за заданием: «Сколько баллов, 1, 2, 3…» Кто-то поднимает 1 палец, кто-то 3. «Хорошо, а почему ты думаешь, что 3? И почему вы думаете, что это 1?» «В прошлый раз, когда я делал что-то подобное, я столкнулся с этой проблемой…» Отлично! Мы быстро оцениваем наши задачи, потому что у каждого есть контекст. Все участники проекта теперь имеют больше информации о другой проблеме, с которой мы можем столкнуться.

Если все работают над отдельным проектом с небольшим перекрытием или контекстом, планирование спринта неэффективно.