Алия Хайруллина Менеджер, Челябинск
В идеальной системе Scrum не нужен: все и так работает прогнозируемо. Но и сам он, как метод управления проектами, не идеален, утверждает Алия Хайруллина.
Адам Смит ввел понятие «разделение труда», которое призвано качественно улучшать производительность. Но, как показывает Scrum, не всегда специализация – признак эффективности.
В этой статье я рассмотрю применение Scrum с точки зрения организационных структур.
О гибких методологиях я впервые услышала на лекциях по проектированию и разработке ПО, будучи студентом лет десять назад. Но тогда преподаватель настойчиво убеждал группу, что «waterfall – наше все и без ТЗ результат не очень».
Многие и сейчас придерживаются данной позиции.
Но почему сейчас весь проектный мир (и не только в части разработки ПО) переживает настоящий Scrum-бум? Ведь методология давно не нова и многим известна еще из университетов?
Ответ: маркетинг.
Но я все же попробую изложить несколько собственных предположений, как в пользу, так и против Scrum.
Начну с разделения труда, о котором впервые написал Адам Смит, предопределивший развитие экономической науки на много веков вперед. Управление проектами – это тоже экономика, вспомните ее определение.
Разделение труда, или специализация, было призвано повысить производительность, закрепив выполнение функций за конкретным работником: первый – обмеряет, второй – кроит, третий – шьет, и так далее по конвейерному принципу. Никто не оспорит множество плюсов такой организации труда.
Во-первых, каждый знает, чему он хочет научиться, какие навыки развить. Во-вторых, с точки зрения организации, было определено, кто и что выполняет.
В-третьих, отсутствие переключений между разными видами деятельности позволяет увеличить эффективность одного работника.
Но что начало происходить, когда одним видом деятельности начинали заниматься двое, пятеро, семеро рабочих, которые становились бригадой, отделом, службой со своим руководителем, своими внутренними процессами и ролями? А чуть погодя, службы переместились в офис, обзаведясь длинными бизнес-процессами, обрастая бумагами, непроизводственного типа задачами и еще многим чем, что вызвало бюрократию и связанные с ней дополнительные транзакции.
КАКОЙ ТЫ ЮТУБЕР | ТЕСТЫ
Разделение труда повышает в такой ситуации эффективность? Только не в офисе, со временем паразитирующем и на основном производстве.
Показателен один пример из собственного опыта, когда однажды коллега, айтишник, сообщил: «У нас все готово!
Осталось преодолеть административный барьер!». Более подходящего примера не найдешь.
Борясь за эффективность, раздувая штат узкоспециализированных профессионалов, которые призваны вносить улучшения, вгоняя их в сложную структуру, мы сами затормаживаем свое движение, размывая роли и ответственность на бизнес-единицы. Как известно, ответственность многих – это ничья ответственность.
Поэтому нам, структурщикам-системщикам, приходится мириться с бесконечным режимом ожидания, ведь в каждом отделе, помимо основной, есть еще своя, особой важности деятельность. А какая – знает только черный ящик.
Факт таких ожиданий приводит к появлению еще одной роли – руководителя проектов. По сути, в идеальной системе он не нужен: все и так работает ритмично, гладко, прогнозируемо.
Но, увы, мы живем не в идеальном мире, поэтому эффект появления РП неизбежен: если функциональные единицы не могут самопроизвольно выталкивать из себя, кто-то должен из них тянуть. И, как бы грубо не прозвучало, выходит, что РП – это дефект системы, признак асинхронно работающей организации.
Отсюда и вырастают «костыли» организационных структур – проектно-ориентированных и даже Scrum, который тоже является «костылем» менеджмента, признаком его незрелости.
Что же такого волшебного он творит, за что удостоился сверхшума? Scrum, с точки зрения организационной структуры, создает в организации мини-организацию, вовлекая в нее разных специалистов.
В Scrum, по определению, нет РП: есть владелец продукта и скрам-мастер: казалось бы, от дефекта в роли РП избавились, ведь такая команда делает ставку на высокую самоорганизацию. В такой команде нет четкого разделения функций: каждый выполняет то, чем может быть полезен, команда работает сообща и ориентирована на командную, общую цель.
Смит, так где же эффективность от разделения труда, когда опыт Scrum демонстрирует обратное? И правда, порою проще собраться и действовать самостоятельно, нежели становиться в очередь и ожидать своего часа, особенно, когда скорость изменений слишком велика и наблюдать со стороны, как плавно движется (в лучшем случае) бизнес-процесс, как где-то что-то определенно теряется и не согласовывается – верный путь к забвению.
Звучит весьма заманчиво, но нужно понимать, что использовать Scrum нужно там, где:
- кросс-функциональность не работает;
- нет фанатизма (сейчас – это всего лишь мейнстрим, Scrum – это не новый метод);
- если вам нужна скорость (но и с ней нужно научиться работать, на это уйдет далеко не один спринт).
Поэтому не стоит искать в этом методе панацею, это своего рода adhoc неработающего менеджмента, и если он может быть эффективен, то не в долгосрочной перспективе. Поэтому если у вас пожар – тушите Scram-ом.
Есть вероятность, что справитесь. А как известно, пожары – они практически всюду.
1
