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

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

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

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

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

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