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