Вот кстати, небольшое отступление от записи про кроссфункциональность — но полезно его как-то осознать. Подумайте минуточку о полномочиях product owner’а в том виде, как они записаны в Scrum Guide. Оказывается, что это человек, который единолично определяет, что делает команда и зачем это нужно — то есть product goal, причем с очень широкими полномочиями относительно «продукта» — буквально «владеет» им, может внезапно решить, что цель протухла и надо бежать в противоположном направлении, или вообще прикрыть лавочку. Добавим к этому еще и способность команды сделать «продукт» от и до, ту самую «кроссфункциональность», и получим крайне стремную с точки зрения бизнеса ситуацию — есть руководитель, определяющий буквально все, касающееся продукта, есть команда, способная затащить сложную задачу, кто им мешает оформиться в отдельную ОООшку и послать всю организацию к ебеной матери?
Да, Матвейчев яркими примерами показывает, «Почему американцы побеждают» (обязательно перечитайте!), но обратите внимание, что относится это к политическому консалтингу, где, во-первых, игра зачастую идет в режиме «все или ничего», а во-вторых — время существования кроссфункциональной команды строго ограничено, после выборов она будет распущена безо всяких последствий. Обычный бизнес предпочтет как-то ограничить и полномочия «продакт-менеджера» (да, это уже не совсем product owner в смысле скрама, но по части определения целей они схожи), и обложить его творчество какими-то рамками, вот хотя бы даже возьмем пример с «согласованием у юристов» — пусть даже наличие отдельного юридического отдела замедляет работу, но оно же и ограничивает «владение продуктом». С точки зрения стабильности «бизнеса» нет ничего лучше обычной функциональной структуры — может быть, укрупненной, пример с раздельными «отделом фронтендеров», «отделом бекендеров» и «отделом тестирования» — это дичь (хотя часто встречающаяся), но в целом нормально выглядит структура R&D, когда условные «технари» собраны в один или несколько отделов, а все остальные вспомогательные по отношению к этому процессу функции — в функциональных подразделениях.
Впрочем, и тут есть забавные нюансы — например, такое разделение на «тематические» подразделения и «всех остальных» в Роскомиксе выглядело примерно так: есть «тематическое подразделение», сидящее на каком-то определенном внешнем заказе или типе заказов, в этом отделе собраны формально все необходимые инженеры, конструкторы, программисты, техники, … — в общем, все технические специалисты. Если тематическому подразделению надо что-то купить — то отдел закупок один на все предприятие, надо идти на поклон туда; согласовать договор с внешним контрагентом — к юристам; отправить официальное электронное письмо — тоже процесс, требующий одобрения от соответствующего подразделения. Разумеется, компетентность «общих» для всего предприятия закупщиков или юристов была ниже плинтуса. Скажем, чтобы купить достаточно дорогой прибор, надо было самостоятельно собрать три коммерческих предложения от разных поставщиков, подготовить проекты договоров, … — то есть буквально выполнить работу отдела закупок, да еще и объяснить контрагентам, что это пока так, собираем предложения, а когда купим — хер его знает. В итоге оказывалось, что в «тематическом» подразделении есть люди, числящиеся «инженерами», но фактически занимающиеся закупками, договорной работой, или даже буквально маркетингом — от поиска клиентов до организации стендика на отраслевых мероприятиях (да-да, вот вам и полная «кроссфункциональность»). Про «теневое IT» и «серую кассу», наполняющуюся самым невыгодным для родного завода образом, думаю, не стоит даже и задумываться :)
И второе очень сложное требование к product owner’у — кроме определения product goal, цели «с точки зрения бизнеса», этот же человек должен заниматься работой с «беклогом», то есть списком задач, причем обычно крайне «узкотехническим». Фактически, нужно сочетать в одном человеке две совершенно противоположные вещи, а это встречается крайне редко. Более того — для выходца «из менеджмента» все правила скрама покажутся детской возней в песочнице, особенно — когда начнется игра в planning poker. Для выходца «из технарей» — наоборот, совершенно неподъемной окажется «управленческая» работа (которая скрыта за словами вроде communicating, буквально «донести до команды необходимость выполнить задачу»), да и по части целеполагания возникнут вопросики.
И кстати, в достаточно большой организации не поможет и внедрение Scrum’а «сверху», которое обычно происходит, когда кто-то из руководства решит прочитать что-то о «революционном методе управления проектами» — потому что противодействие возникнет и на уровне «среднего менеджмента», тех самых кандидатов в product owner’ы — потому что вместе с офигенными полномочиями на «владельца продукта» свалится и офигенная ответственность, а суть карьеры многих «управленцев» как раз и состоит в избегании любой ответственности, местами — буквально по разделу General Interference with Organizations and Production из Simple Sabotage Field Manual. В результате у всех причастных возникает желание «все поменять, ничего не меняя», и поэтому внедрение Scrum обычно сводится к следующему — открываем Scrum Guide, внимательно читаем, вычеркивая обязанности и полномочия «по существу» — а с другой стороны, уделяем параноидальное внимание «ритуалам». Нет ничего проще «внедрения Scrum» в «функциональной» команде — скажем, состоящей исключительно из тестировщиков — просто добавляем в календарь бессмысленные «дейлики» и раз в две недели — «планирование спринта» (которое сводится к определению, сколько типовых задач из Jira можно будет переложить из графы «надо сделать» в графу «сделано»).
А в следующий раз — напишу немножко про «матричную структуру» — которую, внезапно, у нас толком не понимают, и совершенно шикарный способ ее поломать :)
