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