Возвращаясь к истории IT, надо сказать, что функциональная ориентация сотрудников проявлялась не только в организации отделов, но и в том, что даже будучи включенным в проектную команду каждый специалист ориентировался на решение только своих задач. Эта привычка, подлежащая искоренению. Да, мы ценим те компетенции, которые необходимы для проекта, и которые привели к включению в команде, но при этом полагаем, что конечная цель по решению задачи, которая стоит перед командой – важна и ожидаем сотрудничества и вклада даже в том случае, если профессиональные компетенции в моменте не востребованы. В IT вопрос стоял остро, и в ранних работах по Agile были жесткие формулировки: любой член команды может и готов решить любую из задач. А, чтобы вывести людей из функциональных границ, рекомендовалось, как возможная практика на начальном этапе внедрения, просто распределять задачи по жесткой очереди или даже по жребию, чтобы все быстро получили нужные компетенции. Позднее от этого отказались, и сейчас определение кроссфункциональной команды именно такое, как я написал выше. При этом приветствуется умение решать задачи из смежных областей, а не узкая специализация, чтобы команда могла справляться с неоднородным потоком задач. И, более того, узкие специализации бизнес-аналитиков и системных аналитиков объединились в просто аналитика, который заодно может являться в команде тестировщиком, аналогичные процессы можно проследить среди специализаций разработчиков. А в целом это соответствует общему современному тренду перехода от I-людей с одной специализацией к T-людям, умеющим работать и в смежных областях, и даже к m-людям, имеющим несколько глубоких специализаций.

Просто в IT это началось лет на 10—15 раньше, чем в остальных отраслях и не называлось таким образом.

Второе изменение организации – разделение ответственности менеджера, на мой взгляд, является ключевым. Его часто не акцентируют, а просто сообщают, что согласно Scrum Guide, команда включает в себя Владельца продукта (Product Owner), членов команды разработки (Development Team) и Скрам-мастера (Scrum Master). Product Owner отвечает за продукт, то есть за содержание той ценности, которую команда создает, команда разработки создает эту ценность, а фокус Скрам-мастера – помощь команде в ее самоорганизации для того, чтобы поставлять эту ценность быстро и качественно. Такое разделение решило старый спор о том, кто лучший руководитель в инженерных проектах – специалист в предметной области, или универсальный менеджер, который в предметной области не разбирается, зато обладает нужными soft skill, которые отсутствуют у предметника.

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

В целом ответственность за технические решения по реализации лежит на команде. Scrum не говорит, как именно она устроена, однако он явно выделяет мероприятия, на которых реализация должна быть прояснена достаточно для уверенной оценки ее трудоемкости. И детали отдает на самоорганизацию команды. При этом, если компания устроена так, что в командах много новичков с недостаточным опытом, то часто выделяется роль технического лидера (Tech Lead) или архитектора – опытного специалиста, отвечающего за технические решения. Но это должно быть обосновано, и не случайно это не проявлено в Scrum Guide: если команда включает опытных самостоятельных разработчиков, то выделение ответственного за технические решения наоборот. является вредным и демотивирует других членов команды, превращая их в исполнителей. Поэтому лучшая практика – когда технические решения готовит исполнитель, а по существенным вопросам предлагает их членам команды на review. Отдельно надо подчеркнуть, что основная ответственность за организацию работ лежит на команде, а не на Scrum Master, который лишь помогает команде соорганизоваться. И это третье изменение – управление через самоорганизацию, блокировка микроменеджмента. Во всех учебниках по менеджменту говорят, что микроменеджмент не эффективен, что руководитель должен организовать работу так, чтобы не быть поглощенным операционной системой, ежедневно раздачей задач. А в Scrum это просто сделали на уровне процесса – в нем нет места, где можно отдать указания. Вообще. И если у члена команды с решением задачи возникают трудности – то он тоже не идет к кому-либо за указаниями, а запрашивает помощь по своему выбору, не отдавая при этом ответственность. А чтобы он не забыл и не стеснялся это делать, в процедуру ежедневных встреч (Daily Scrum Meeting) включен вопрос – что мешает продвигаться к решению задач.