Адам Смит ввел понятие «разделение труда», которое призвано качественно улучшать производительность. Но, как показывает Scrum, не всегда специализация – признак эффективности. В этой статье я рассмотрю применение Scrum с точки зрения организационных структур.
О гибких методологиях я впервые услышала на лекциях по проектированию и разработке ПО, будучи студентом лет десять назад. Но тогда преподаватель настойчиво убеждал группу, что «waterfall – наше все и без ТЗ результат не очень». Многие и сейчас придерживаются данной позиции. Но почему сейчас весь проектный мир (и не только в части разработки ПО) переживает настоящий Scrum-бум? Ведь методология давно не нова и многим известна еще из университетов? Ответ: маркетинг. Но я все же попробую изложить несколько собственных предположений, как в пользу, так и против Scrum.
Начну с разделения труда, о котором впервые написал Адам Смит, предопределивший развитие экономической науки на много веков вперед. Управление проектами – это тоже экономика, вспомните ее определение. Разделение труда, или специализация, было призвано повысить производительность, закрепив выполнение функций за конкретным работником: первый – обмеряет, второй – кроит, третий – шьет, и так далее по конвейерному принципу. Никто не оспорит множество плюсов такой организации труда. Во-первых, каждый знает, чему он хочет научиться, какие навыки развить. Во-вторых, с точки зрения организации, было определено, кто и что выполняет. В-третьих, отсутствие переключений между разными видами деятельности позволяет увеличить эффективность одного работника.
Но что начало происходить, когда одним видом деятельности начинали заниматься двое, пятеро, семеро рабочих, которые становились бригадой, отделом, службой со своим руководителем, своими внутренними процессами и ролями? А чуть погодя, службы переместились в офис, обзаведясь длинными бизнес-процессами, обрастая бумагами, непроизводственного типа задачами и еще многим чем, что вызвало бюрократию и связанные с ней дополнительные транзакции. Разделение труда повышает в такой ситуации эффективность? Только не в офисе, со временем паразитирующем и на основном производстве. Показателен один пример из собственного опыта, когда однажды коллега, айтишник, сообщил: «У нас все готово! Осталось преодолеть административный барьер!». Более подходящего примера не найдешь.
Борясь за эффективность, раздувая штат узкоспециализированных профессионалов, которые призваны вносить улучшения, вгоняя их в сложную структуру, мы сами затормаживаем свое движение, размывая роли и ответственность на бизнес-единицы. Как известно, ответственность многих – это ничья ответственность. Поэтому нам, структурщикам-системщикам, приходится мириться с бесконечным режимом ожидания, ведь в каждом отделе, помимо основной, есть еще своя, особой важности деятельность. А какая – знает только черный ящик.
Факт таких ожиданий приводит к появлению еще одной роли – руководителя проектов. По сути, в идеальной системе он не нужен: все и так работает ритмично, гладко, прогнозируемо. Но, увы, мы живем не в идеальном мире, поэтому эффект появления РП неизбежен: если функциональные единицы не могут самопроизвольно выталкивать из себя, кто-то должен из них тянуть. И, как бы грубо не прозвучало, выходит, что РП – это дефект системы, признак асинхронно работающей организации. Отсюда и вырастают «костыли» организационных структур – проектно-ориентированных и даже Scrum, который тоже является «костылем» менеджмента, признаком его незрелости.
Что же такого волшебного он творит, за что удостоился сверхшума? Scrum, с точки зрения организационной структуры, создает в организации мини-организацию, вовлекая в нее разных специалистов. В Scrum, по определению, нет РП: есть владелец продукта и скрам-мастер: казалось бы, от дефекта в роли РП избавились, ведь такая команда делает ставку на высокую самоорганизацию. В такой команде нет четкого разделения функций: каждый выполняет то, чем может быть полезен, команда работает сообща и ориентирована на командную, общую цель.
Смит, так где же эффективность от разделения труда, когда опыт Scrum демонстрирует обратное? И правда, порою проще собраться и действовать самостоятельно, нежели становиться в очередь и ожидать своего часа, особенно, когда скорость изменений слишком велика и наблюдать со стороны, как плавно движется (в лучшем случае) бизнес-процесс, как где-то что-то определенно теряется и не согласовывается – верный путь к забвению.
Звучит весьма заманчиво, но нужно понимать, что использовать Scrum нужно там, где:
- кросс-функциональность не работает;
- нет фанатизма (сейчас – это всего лишь мейнстрим, Scrum – это не новый метод);
- если вам нужна скорость (но и с ней нужно научиться работать, на это уйдет далеко не один спринт).
Поэтому не стоит искать в этом методе панацею, это своего рода adhoc неработающего менеджмента, и если он может быть эффективен, то не в долгосрочной перспективе. Поэтому если у вас пожар – тушите Scram-ом. Есть вероятность, что справитесь. А как известно, пожары – они практически всюду.
Владимир, комментарий к Вашему последнему абзацу: да, по сути, из-за плохого менеджмента. И вместо того, чтобы его лечить системно, наращивают отросточек в виде скрам-команды, которая тесно взаимодействуя, оперативнее реагирует на изменения.
Смита оспаривать не буду, т.к так глубоко в его научные труды не погружалась: знаю то, о чем как бы принято знать
По п.1 это больше по специализации сейчас, чем конкретно по Смиту.
По 2 и 3 - если у Смита есть порядковая классификация, я ей вовсе не придерживалась: перечисляла имеющееся у меня представление (по опыту)
Конвейерный принцип - это не научный термин, это авторское :)
Судя по статье, автору неизвестна роль руководителя проекта. И выказанное в статье представление о том, что скрам позволяет разработать проект в порядке самоорганизации проектной группы (без руководителя проекта!), является просто пустословием.
Неужели так трудно прочесть первую часть книги Дж.К.Джонса «Методы проектирования»? Там великолепно изложена эволюция проектирования. На основе этого изложения нетрудно догадаться, как руководитель проекта может организовать «скрамную гибкость» в работе команды проекта.
.==========================================.
Для материальных объектов есть объективный-однозначный способ их представления – чертёжная модель. Она даёт концептуальное представление о проектируемом объекте. Что позволяет каждому «узкому» спецу-проектировщику увидеть своё место в общей работе.
Для ИТ-объектов, похоже, не существует такого способа представления. Сие отсутствие и является основой появления пустопорожних ррреволюционных одоробл типа скрама.
Цитата - (1) Но что начало происходить, когда одним видом деятельности начинали заниматься двое, пятеро, семеро рабочих, которые становились бригадой, отделом, службой со своим руководителем, своими внутренними процессами и ролями? (2) А чуть погодя, службы переместились в офис, обзаведясь длинными бизнес-процессами, обрастая бумагами, непроизводственного типа задачами и еще многим чем, что вызвало бюрократию и связанные с ней дополнительные транзакции. (3) Разделение труда повышает в такой ситуации эффективность? Только не в офисе, со временем паразитирующем и на основном производстве.
1. Если я правильно понял описание, то начало происходить следующее - и называется это следующее эффектом масштаба. Если люди собираются в отдел - они продолжают работать еще более эффективно за счет более глубокого разделения труда. Вторая причина эффекта от масштабов деятельности - это использование более дорогостоящего и производительного оборудования.
Потому с автором, описывающем "отрицательное", согласиться не могу.
2. При переходе в офис эффект масштаба работает точно также, как я отметил (это не все, конечно, причины более эффективной работы.
3. Повышает эффективность не РТ в данных примерах, а ЭМ. А причиной ЭМ является, в частности, РТ.
Никакого паразитирования нет. Речь идет о необходимой координации когда используется ЭМ. Другое дело, что менеджмент может быть лучше и хуже. Но к РТ это никак не относится.
И выводы такие (из текста) - они весьма банальны - плохой менеджмент хуже хорошего. Точка.
Цитата - Как известно, ответственность многих – это ничья ответственность.
Кому известно?
Если мы говорим о командной работе (которая в нашей стране пока встречается только в спорте, но наша страна - это еще не вся планета), то один из признаков команды - это командная ответственность.
Цитата - Смит, так где же эффективность от разделения труда, когда опыт Scrumдемонстрирует обратное?
Поскольку Адам Смит, к которому Вы так фамильярно обращаетесь в публикации, некоторое время назад умер, попробую ответить за него:
Если бы, уважаемая Алия, РТ (как неисчерпаемый источник повышения эффективности труда) человечество не стало применять, Вы бы сейчас занимались тем, что поддерживали бы огонь в пещере, чтобы он не затух (хотя поддержание огня - также есть одна из специализированных функций.
Но не переживайте - у Вас есть поклонники -
Валерий Овсий пишет:
Мои искренние поздравление автору за разумность подхода и рассуждений.Полностью присоединяюсь!
Реклама может быть ещё скрытой :)
Scrum - это зонтичная платформа, под зонтик которой пытаются "затянуть" всё подряд, и это означает, что обновление есть.
XP была достаточно цельной платформой, но "жадность" до добра не доведёт и увидим как Scrum расплывётся из-за подобных "поглощений" - отсутствие цельности приведёт к распаду платформы -> неизбежно деление и развитие из всей этой "кучи под зонтиком" разных платформ - уже не Scrum, в том числе, в зависимости от масштабов проектов. И это уже происходит.
Или псевдо-маркетинг :)
Но специализированные Маркетинговые технологии - это одна из основных фишек в Scrum. Впрочем, некоторые полностью или другие после переработки можно использовать и на других платформах, просто именно в практике Scrum они получили свою удачную "формулировку".
Здесь сильно не так - это не "костыль" :)
Где-то с 2005 года использовали платформу XP - eXtreme Programming - потом её "затащили" под зонтик Scrum :). Эту платформу можно использовать для разных целей. Вы правы -> Быстро сделать - пожалуйста. Но есть такая деталь - это здорово не для Реинжиниринга всего большого программного продукта, а для Усовершенствования. Вот постоянный Реинжиниринг как раз может быть признаком незрелости!
Что касается совершенно новых программных продуктов, то подобные технологии помогают создать работающий прототип продукта , который будет нравиться клиентам. Для полностью работающего и его поддержки потребуются другие технологии :) - не всё же можно затащить под один зонтик, без потери логики. Когда кто-то пишет, например, что используют в Scrum Lean или Kanban - они не знают :) что это такое - Lean и Kanban.
ни о чем...