«Агитировать разработчиков за agile – все равно, что рассказывать, что Земля круглая. Да, еще встречаются заказчики, предпочитающие долгий и нудный процесс по ГОСТу (он же waterfall) с производством тонн документации, которую никто никогда читать не будет, но обычно в таких проектах истинной целью является не создание реально работающей системы, а правильно оформленное расходование бюджетных средств.
Agile в индустрии программного обеспечения стал нормой жизни. Ибо нет сегодня другой методологии, позволяющей управлять проектами в условиях высокой неопределенности и изменчивости требований.»
Статья журналиста-аналитика Станислава Макарова.
Вообразите, если бы вам пришлось управлять проектом по разработке программного продукта при помощи традиционного документооборота – входящих-исходящих, служебных записок, протоколов совещаний и прочей бюрократии. Каковы шансы уложиться в срок и в бюджет? Правильно, нулевые. Не поможет даже самый жесткий контроль исполнения. И вовсе не потому, что ваши программисты бездельники и разгильдяи, которые даже на работу не могут вовремя прийти, одеваются странно и занимаются непонятно чем.
Проблемы в самой методологии: предполагается, будто бы можно все заранее предвидеть и дать исполнителям четкие инструкции, что делать. В идеальной системе это могло бы сработать, но, увы, чаще всего мы имеем множество отклонений от плана, которые никакой, даже самый мудрый начальник не мог предусмотреть.
Вот здесь система и начинает давать сбои, поскольку каждое изменение нужно согласовать по иерархической цепочке. Все участники процесса предпочитают сливать ответственность, чтобы не оказаться в итоге крайними – инициатива наказуема! На начальника сваливается куча мелких вопросов, которые ему надо разруливать лично. Цикл принятия решений растягивается, сроки плывут – и виноватых нет, если только специально не назначат кого-нибудь потом. Командно-административная система не обладает достаточной гибкостью, чтобы успевать реагировать на изменения обстановки, будь то встретившиеся трудности при реализации проекта, либо новые требования заказчика.
Короче говоря, начальник всегда прав. А если не прав, то смотри пункт первый. Все сидят и ждут руководящих указаний, горизонтальные связи не работают.
Документооборот – вовсе не такая безобидная вещь, как кажется. На самом деле, это воплощение управленческой концепции, в основе которой лежит строгая иерархия, недопущение инициативы и отсутствие коллективной работы.
В общем, все сводится к классическому принципу «разделяй и властвуй».
Стоит организации чуть подрасти, как она начинает мечтать внедрить документооборот, чтобы все было «как у больших». Никто не спорит, порядок в документах нужен, а то, не ровен час, нагрянут всякие контролирующие инстанции или затеряется в потоке важный документ от клиента. Все это правильно, только не надо начинать копировать государственную бюрократию в ее худших проявлениях.
Если взять по-крупному, СЭД покрывает две функциональных области:
Так сложилось исторически и сейчас нет смысла ломать копья, правильно это или нет. Примите как факт.
СЭД — это одновременно и репозиторий документов (Document & Records Management System) и система управления организацией (Workflow & BPM, Collaboration и проч.) Причем, сложилась практика использования систем в основном по образцу советских учреждений с их бессмысленной и беспощадной бюрократией. Более половины организаций в исследовании IDC называют СЭД средством автоматизации бизнес-процессов. (На втором месте идет ERP, а собственно BPM-системы – в самом конце.)
Так вот, документировать деятельность нужно. Иначе можно запросто лишиться лицензии, сертификации, профакапить контракт, потерять, не дай Бог, персональные данные или еще что-то важное. Но вовсе не обязательно ставить знак равенства между документированием и процессами.
Подумайте о процессах отдельно. Не попадайте в ловушку отживших традиций. Ведь основное умение «эффективного менеджера» – свалить ответственность на других, чаще всего на подчиненных. Понятие «команды» в идеологии СЭД напрочь отсутствует, есть только «исполнители», колесики и винтики корпоративной или государственной машины.
Теперь, внимание, вопрос: Можете назвать хотя бы один действительно крутой продукт, который был бы разработан в подобной бюрократической среде?
И вопрос №2: Разве разработка софта чем-то принципиально отличается от других видов коллективной деятельности? Так почему бы не применить agile за пределами команды разработчиков, на всех бизнес-процессах организации? Увы, здесь мы сталкиваемся с почти непреодолимой стеной непонимания…
Менеджменту учат в бизнес-школах. Все, точка. Айтишники ничего не могут знать об управлении процессами, их дело – программировать. Если в курсе MBA не говорится об agile-методологиях (а это так и есть!), то нечего и огород городить. Очень похоже на историю о турецком астрономе из Маленького принца.
В нашем случае, боюсь, не поможет даже пиджак и галстук. Заказчики настаивают на реализации при помощи новейших ИТ-систем отживших методов управления и не готовы принять новые методологии из рук ИТ.
Неэффективность традиционного менеджмента применительно к разработке программ обнаружилась давно. Книга Фредерика Брукса «Мифический человеко-месяц» о трудностях управления проектом по созданию IBM OS/360 и неудачных попытках его ускорения путем привлечения большего числа программистов вышла в 1975 году. С тех пор мало что изменилось – менеджеры все также ошибочно полагают, что проблемы можно решать увеличением числа людей или «заменой исполнителя», как они любят говорить.
Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по двум причинам.
Если есть N программистов, то количество пар программистов N(N-1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому, начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Если сроки сорваны, наем новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
При очень большом числе программистов проект может быть вообще никогда не закончен: из-за общей неразберихи, попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается (глава 2). (цитирую по Википедии)
Замените программистов на инженеров, технологов, менеджеров по продажам в B2B, специалистов по развитию бизнеса, переводчиков, юристов, дизайнеров – вы получите такую же картину. Везде, где конечный результат зависит от взаимодействия людей в команде и выстроенных отношений с заказчиком, закон Брукса работает. Иначе говоря, везде, где в работе есть интеллектуальная составляющая, механическое масштабирование ресурсов не помогает. И не помогают грозные приказы сделать все в срок, а не то всех уволим – уникальные специалисты это вам не сборщики хлопка.
В этом суть конфликта: нынешние управленческие практики выросли из задач управления производством и вооруженными силами, где работает механическое масштабирование, и результат мало зависит от личности исполнителя. Вам же не важно, какой именно рабочий стоит у станка, да? А с теми категориями сотрудников, кого относят к 'knowledge workers' такой фокус не проходит. Нельзя поручить перевести половину книги одному переводчику, а половину другому. Адвокаты не могут ходить на слушания одного дела по очереди, нужно время, чтобы включиться в процесс. Поэтому-то и нужны методы управления, учитывающие творческий и коллективный характер работы, – agile в всех своих проявлениях – Scrum, Kanban, LEAN и пр.
Считать СЭД и всю парадигму управления «от документооборота» абсолютным злом было бы сильным преувеличением. Конечно, есть области, где это вполне успешно работает. Но есть и такие, где применение бюрократических процедур категорически противопоказано. (Как большинство читателей знает из собственного опыта, к таковым относится разработка ПО.)
Но в чем разница?
Применимость методологии определяется природой объекта управления, процессов, которые мы собираемся автоматизировать. Фреймворк Cynefin (произносится 'киневин', это слово валлийское, придумал его проф. Дэйв Сноуден), определяет четыре домена: простой, усложненный, сложный, хаотический. В каждом домене действуют свои законы и правила.
Нетрудно предположить, что СЭД будет вполне хорошо работать в домене Simple, автоматизируя разные рутинные процедуры. Главное свойство этого домена – четкие и понятные причинно-следственные связи. То есть, можно написать регламенты, установить нормативы – и вперед! Люди здесь взаимозаменяемы, можно поставить любого минимально обученного оператора и качество процесса не изменится.
Следующий домен, Complicated (усложненный), характеризуется механической сложностью – когда на первый взгляд непонятно, но если разобраться, то все логично и предсказуемо, также возможны небольшие вариации, к которым система адаптируется. Из практики документооборота можно привести в пример процесс управления договорами – теоретически, можно очень детально расписать процесс согласования и утверждения, только все понимают, что в реальной жизни могут быть приняты любые решения вопреки регламенту, если это будет в интересах бизнеса.
В этом домене СЭД еще работают нормально, пока не встретятся с какой-нибудь исключительной ситуацией. Если исключительных ситуаций становится слишком много, то организация переходит в режим «ручного управления», когда руководитель пытается рулить всем лично, и мы, де-факто, оказываемся в домене Complex, в царстве сложных систем, где лучшие практики не работают, где прошлый опыт если и повторяется, то каждый раз в каком-то измененном виде. Помните высказывание «в одну реку нельзя войти дважды»? Как раз такой случай.
Большинство организационных систем именно таковы. Все, что касается стратегического управления, развития бизнеса, инноваций, вывода продуктов на рынок, маркетинга, и т.д. и т.п. – в общем, все процессы, слабо поддающиеся формализации, где потенциально есть конфликт интересов разных участников, можно считать сложными системами. Поэтому ситуация «лебедь, рак и щука», когда ведомства или департаменты не могут решить вопрос, требующий совместных усилий, является вполне обычной.
В домене Complex подход к управлению, основанный на СЭД, становится категорически вредным. «В ответ на ваш входящий – наш исходящий» – и так хоть сто раз подряд, только дело не двигается с места. Потому что в рамках бюрократической парадигмы самое главное – спихнуть ответственность на кого-то другого, а не прийти к общему пониманию и найти оптимальное решение.
Методология Agile, пожалуй, это самый ценный подарок бизнесу от ИТ. Только бизнес не готов взять это из наших рук, поэтому придется внедрять agile партизанскими методами, добавляя в продукты новые фичи, ориентированные на поддержку новых методологий работы. Эти новшества проникают в компании под флагом гибкости и адаптивности бизнес-процессов, на что менеджмент смотрит благосклонно – надо же соответствовать духу времени!
На самом же деле, это настоящая подрывная инновация (disruptive innovation), мина замедленного действия, заложенная под прежние методы организации работы. Потому что новые ECM и BPM системы нацелены на поддержку горизонтального взаимодействия в командах, не отрицая привычной «вертикали власти», на быстрое создание приложений для конкретных бизнес-задач с фокусом на конечный результат и измеримые KPI, имеют встроенные средства обмена сообщениями и другой информацией – почти как соцсеть, только (тсс!) никому не говорите!
Итого, можно немного перефразировать Agile-манифест разработчиков ПО, и получится вот такой вот Agile-манифест СЭД:
К слову сказать, сами термины Agile ECM и Agile BPM уже вполне широко используются, многие компании выпустили свои продукты, позиционируя их в классе Agile. Так что, лед тронулся!
Agile в индустрии программного обеспечения стал нормой жизни. Ибо нет сегодня другой методологии, позволяющей управлять проектами в условиях высокой неопределенности и изменчивости требований.»
Статья журналиста-аналитика Станислава Макарова.
Причем здесь документооборот?
Вообразите, если бы вам пришлось управлять проектом по разработке программного продукта при помощи традиционного документооборота – входящих-исходящих, служебных записок, протоколов совещаний и прочей бюрократии. Каковы шансы уложиться в срок и в бюджет? Правильно, нулевые. Не поможет даже самый жесткий контроль исполнения. И вовсе не потому, что ваши программисты бездельники и разгильдяи, которые даже на работу не могут вовремя прийти, одеваются странно и занимаются непонятно чем.
Проблемы в самой методологии: предполагается, будто бы можно все заранее предвидеть и дать исполнителям четкие инструкции, что делать. В идеальной системе это могло бы сработать, но, увы, чаще всего мы имеем множество отклонений от плана, которые никакой, даже самый мудрый начальник не мог предусмотреть.
Вот здесь система и начинает давать сбои, поскольку каждое изменение нужно согласовать по иерархической цепочке. Все участники процесса предпочитают сливать ответственность, чтобы не оказаться в итоге крайними – инициатива наказуема! На начальника сваливается куча мелких вопросов, которые ему надо разруливать лично. Цикл принятия решений растягивается, сроки плывут – и виноватых нет, если только специально не назначат кого-нибудь потом. Командно-административная система не обладает достаточной гибкостью, чтобы успевать реагировать на изменения обстановки, будь то встретившиеся трудности при реализации проекта, либо новые требования заказчика.
Короче говоря, начальник всегда прав. А если не прав, то смотри пункт первый. Все сидят и ждут руководящих указаний, горизонтальные связи не работают.
Документооборот – вовсе не такая безобидная вещь, как кажется. На самом деле, это воплощение управленческой концепции, в основе которой лежит строгая иерархия, недопущение инициативы и отсутствие коллективной работы.
В общем, все сводится к классическому принципу «разделяй и властвуй».
Ловушка документооборота: двойное назначение СЭД
Стоит организации чуть подрасти, как она начинает мечтать внедрить документооборот, чтобы все было «как у больших». Никто не спорит, порядок в документах нужен, а то, не ровен час, нагрянут всякие контролирующие инстанции или затеряется в потоке важный документ от клиента. Все это правильно, только не надо начинать копировать государственную бюрократию в ее худших проявлениях.
Если взять по-крупному, СЭД покрывает две функциональных области:
- Документирование деятельности организации;
- Управление бизнес-процессами.
Так сложилось исторически и сейчас нет смысла ломать копья, правильно это или нет. Примите как факт.
СЭД — это одновременно и репозиторий документов (Document & Records Management System) и система управления организацией (Workflow & BPM, Collaboration и проч.) Причем, сложилась практика использования систем в основном по образцу советских учреждений с их бессмысленной и беспощадной бюрократией. Более половины организаций в исследовании IDC называют СЭД средством автоматизации бизнес-процессов. (На втором месте идет ERP, а собственно BPM-системы – в самом конце.)
Так вот, документировать деятельность нужно. Иначе можно запросто лишиться лицензии, сертификации, профакапить контракт, потерять, не дай Бог, персональные данные или еще что-то важное. Но вовсе не обязательно ставить знак равенства между документированием и процессами.
Подумайте о процессах отдельно. Не попадайте в ловушку отживших традиций. Ведь основное умение «эффективного менеджера» – свалить ответственность на других, чаще всего на подчиненных. Понятие «команды» в идеологии СЭД напрочь отсутствует, есть только «исполнители», колесики и винтики корпоративной или государственной машины.
Теперь, внимание, вопрос: Можете назвать хотя бы один действительно крутой продукт, который был бы разработан в подобной бюрократической среде?
И вопрос №2: Разве разработка софта чем-то принципиально отличается от других видов коллективной деятельности? Так почему бы не применить agile за пределами команды разработчиков, на всех бизнес-процессах организации? Увы, здесь мы сталкиваемся с почти непреодолимой стеной непонимания…
История о турецком астрономе
Менеджменту учат в бизнес-школах. Все, точка. Айтишники ничего не могут знать об управлении процессами, их дело – программировать. Если в курсе MBA не говорится об agile-методологиях (а это так и есть!), то нечего и огород городить. Очень похоже на историю о турецком астрономе из Маленького принца.
В нашем случае, боюсь, не поможет даже пиджак и галстук. Заказчики настаивают на реализации при помощи новейших ИТ-систем отживших методов управления и не готовы принять новые методологии из рук ИТ.
Неэффективность традиционного менеджмента применительно к разработке программ обнаружилась давно. Книга Фредерика Брукса «Мифический человеко-месяц» о трудностях управления проектом по созданию IBM OS/360 и неудачных попытках его ускорения путем привлечения большего числа программистов вышла в 1975 году. С тех пор мало что изменилось – менеджеры все также ошибочно полагают, что проблемы можно решать увеличением числа людей или «заменой исполнителя», как они любят говорить.
Мифический человеко-месяц
Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по двум причинам.
- В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие;
- Программисты должны тратить часть времени на взаимодействие друг с другом.
Если есть N программистов, то количество пар программистов N(N-1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому, начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Если сроки сорваны, наем новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
При очень большом числе программистов проект может быть вообще никогда не закончен: из-за общей неразберихи, попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается (глава 2). (цитирую по Википедии)
Замените программистов на инженеров, технологов, менеджеров по продажам в B2B, специалистов по развитию бизнеса, переводчиков, юристов, дизайнеров – вы получите такую же картину. Везде, где конечный результат зависит от взаимодействия людей в команде и выстроенных отношений с заказчиком, закон Брукса работает. Иначе говоря, везде, где в работе есть интеллектуальная составляющая, механическое масштабирование ресурсов не помогает. И не помогают грозные приказы сделать все в срок, а не то всех уволим – уникальные специалисты это вам не сборщики хлопка.
В этом суть конфликта: нынешние управленческие практики выросли из задач управления производством и вооруженными силами, где работает механическое масштабирование, и результат мало зависит от личности исполнителя. Вам же не важно, какой именно рабочий стоит у станка, да? А с теми категориями сотрудников, кого относят к 'knowledge workers' такой фокус не проходит. Нельзя поручить перевести половину книги одному переводчику, а половину другому. Адвокаты не могут ходить на слушания одного дела по очереди, нужно время, чтобы включиться в процесс. Поэтому-то и нужны методы управления, учитывающие творческий и коллективный характер работы, – agile в всех своих проявлениях – Scrum, Kanban, LEAN и пр.
Почему лучшие практики не всегда лучше
Считать СЭД и всю парадигму управления «от документооборота» абсолютным злом было бы сильным преувеличением. Конечно, есть области, где это вполне успешно работает. Но есть и такие, где применение бюрократических процедур категорически противопоказано. (Как большинство читателей знает из собственного опыта, к таковым относится разработка ПО.)
Но в чем разница?
Применимость методологии определяется природой объекта управления, процессов, которые мы собираемся автоматизировать. Фреймворк Cynefin (произносится 'киневин', это слово валлийское, придумал его проф. Дэйв Сноуден), определяет четыре домена: простой, усложненный, сложный, хаотический. В каждом домене действуют свои законы и правила.
Нетрудно предположить, что СЭД будет вполне хорошо работать в домене Simple, автоматизируя разные рутинные процедуры. Главное свойство этого домена – четкие и понятные причинно-следственные связи. То есть, можно написать регламенты, установить нормативы – и вперед! Люди здесь взаимозаменяемы, можно поставить любого минимально обученного оператора и качество процесса не изменится.
Следующий домен, Complicated (усложненный), характеризуется механической сложностью – когда на первый взгляд непонятно, но если разобраться, то все логично и предсказуемо, также возможны небольшие вариации, к которым система адаптируется. Из практики документооборота можно привести в пример процесс управления договорами – теоретически, можно очень детально расписать процесс согласования и утверждения, только все понимают, что в реальной жизни могут быть приняты любые решения вопреки регламенту, если это будет в интересах бизнеса.
В этом домене СЭД еще работают нормально, пока не встретятся с какой-нибудь исключительной ситуацией. Если исключительных ситуаций становится слишком много, то организация переходит в режим «ручного управления», когда руководитель пытается рулить всем лично, и мы, де-факто, оказываемся в домене Complex, в царстве сложных систем, где лучшие практики не работают, где прошлый опыт если и повторяется, то каждый раз в каком-то измененном виде. Помните высказывание «в одну реку нельзя войти дважды»? Как раз такой случай.
Большинство организационных систем именно таковы. Все, что касается стратегического управления, развития бизнеса, инноваций, вывода продуктов на рынок, маркетинга, и т.д. и т.п. – в общем, все процессы, слабо поддающиеся формализации, где потенциально есть конфликт интересов разных участников, можно считать сложными системами. Поэтому ситуация «лебедь, рак и щука», когда ведомства или департаменты не могут решить вопрос, требующий совместных усилий, является вполне обычной.
В домене Complex подход к управлению, основанный на СЭД, становится категорически вредным. «В ответ на ваш входящий – наш исходящий» – и так хоть сто раз подряд, только дело не двигается с места. Потому что в рамках бюрократической парадигмы самое главное – спихнуть ответственность на кого-то другого, а не прийти к общему пониманию и найти оптимальное решение.
Agile ECM и Agile BPM
Методология Agile, пожалуй, это самый ценный подарок бизнесу от ИТ. Только бизнес не готов взять это из наших рук, поэтому придется внедрять agile партизанскими методами, добавляя в продукты новые фичи, ориентированные на поддержку новых методологий работы. Эти новшества проникают в компании под флагом гибкости и адаптивности бизнес-процессов, на что менеджмент смотрит благосклонно – надо же соответствовать духу времени!
На самом же деле, это настоящая подрывная инновация (disruptive innovation), мина замедленного действия, заложенная под прежние методы организации работы. Потому что новые ECM и BPM системы нацелены на поддержку горизонтального взаимодействия в командах, не отрицая привычной «вертикали власти», на быстрое создание приложений для конкретных бизнес-задач с фокусом на конечный результат и измеримые KPI, имеют встроенные средства обмена сообщениями и другой информацией – почти как соцсеть, только (тсс!) никому не говорите!
Итого, можно немного перефразировать Agile-манифест разработчиков ПО, и получится вот такой вот Agile-манифест СЭД:
К слову сказать, сами термины Agile ECM и Agile BPM уже вполне широко используются, многие компании выпустили свои продукты, позиционируя их в классе Agile. Так что, лед тронулся!
