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

Я поделюсь своими впечатлениями от участия в этом формате, рассмотрю проблемные моменты и предложу, что с ними можно сделать.

Полтора года назад я принял решение уйти из небольшого московского стартапа, где занимал руководящую должность, в более стабильную вологодскую компанию: вернулся «к станку» и стал Scrum Master-ом новой команды. Но, как «офицеров бывших не бывает», так, видимо, не бывает и людей, которые могут перестать беспокоиться об эффективной разработке, даже если за неё уже не отвечают.

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

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