Неоднократно упоминавшийся на нашем портале Чарльз Бетц (Charles Betz, среди прочего автор «Digital Practitioner Body of Knowledge (DPBoK)», являющейся базой для соответствующей сертификации от The Open Group, консорциума, разработавшего TOGAF, IT4IT, к которым, кстати, Чарльз тоже приложил руку) опубликовал на прошедшей неделе любопытный фрагмент своей беседы с Agile-классиком Доном Райнерстеном (Don Reinertsen). Дон – автор книг «Разработка продуктов за половину времени» («Developing Products in Half the Time»), «Управление дизайн-фабрикой» («Managing the Design Factory»), «Принципы потока продуктовой разработки» («The Principles of Product Development Flow: Second Generation Lean Product Development»).
В интервью эксперты рассуждают о недостатке автономных (читай «продуктовых») команд – сложности накопления и доступа к экспертизе по сравнению с командами/специалистами с узкой специализацией, привлекаемыми для решения различных задач.
В этом небольшом тексте есть хорошая формулировка проблемы, описанной автором теории ограничений Э.Голдраттом.
«Люди просто не понимают, как измерять производительность общей сервисы {shared service – службы/команды, которые могут быть задействованы в решения различных задач, например, в разработке и поддержке различных продуктов; классический сценарий для функциональной организационной структуры}. Они наивно полагают, что, поскольку они тратят деньги на производство продукции, они должны измерять затраты на единицу продукции. Что ж, если вы измеряете общие сервисы по стоимости на единицу продукции, вы приходите к минимизации времени простоя в сервисе {команде, каждой команде}, поэтому вы переходите к более высоким уровням утилизации. К сожалению, сочетание высокой утилизации и колеблющегося спроса создаёт серьезные проблемы с очередями, которые затем приведут к длительному и непредсказуемому времени отклика.»
Также Дон интересно описывает заблуждение некоторых управленцев.
«Да, люди продолжают приходить ко мне и говорить, что для достижения желаемого результата их программы им нужен прямой контроль над всеми, кто влияет на этот результат. Они говорят: «Мне нужно, чтобы моя команда занималась закупками; мне нужно, чтобы в моей команде были инженеры-технологи; мне нужны QA в моей команде».
Я спрашиваю их: «А зачем они вам?» Они говорят: «Потому что их работа важна и влияет на мою способность добиваться хороших результатов». Затем я говорю: «Вам нужна команда расчета заработной платы в вашей команде?» Они говорят: «Нет, зачем мне это?» Я говорю: «Ну разве зарплата не важна? Разве люди не любят получать чеки вовремя?» И они говорят: «Да, это важно, но бухгалтерия делает свою работу – они делают то, что должны делать».
И я говорю: «Получается, вам не нужна дюжина дополнительных наборов навыков, которыми вы сможете управлять в своей команде. Вам нужно сделать так, чтобы эти общие ресурсы соответствовали тому, что вам действительно нужно. Когда вы работаете с общими ресурсами, которые реагируют на запросы и соответствуют вашим ожиданиям, и ваш реальный уровень обслуживания удовлетворяется, тогда у вас нет желания испытывать дополнительную головную боль, связанную с управлением ещё одной группой специалистов. Вам нужно сосредоточиться на том, как вы измеряете производительность ваших общих ресурсов и как дать людям возможность достичь этой производительности. Решите эту проблему, и вам не будет интересно привлекать их к себе в команду».
Любопытно, означает ли это, что, по мнению эксперта, можно полностью отказаться от автономных команд? Shared services ничуть не хуже. «Вы просто не умеете их готовить»©. Нужно лишь определить правильную систему измерения.
И хотя с последним тезисом в общем трудно поспорить (система измерения действительно должна быть правильной), с таким лёгким отказом от продуктовых команд согласиться сложно.
Интересно.
Обычно очень сложно сформулировать эти самые требования к конкретному “Shared service”, поэтому проще забрать к себе спецов и ими типа управлять.
Но любая специализация всегда будет эффективнее универсалов.