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?» «В прошлый раз, когда я делал что-то подобное, я столкнулся с этой проблемой…» Отлично! Мы быстро оцениваем наши задачи, потому что у каждого есть контекст. Все участники проекта теперь имеют больше информации о другой проблеме, с которой мы можем столкнуться.
Если все работают над отдельным проектом с небольшим перекрытием или контекстом, планирование спринта неэффективно.