Менеджмент цифрового мира - страница 19

Возвращаясь к истории 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 должен быть специалистом в бизнесе. Впрочем, такое разделение сильно зависит от характера проектов и взаимоотношений с заказчиком, эти границы подвижны. Просто надо учитывать, что в разных книгах эта граница проведена по-разному, в зависимости от опыта автора.