Agile-менеджмент. Лидерство и управление командами

Не злоупотребляем ли мы научным подходом?

При обсуждении гибких методологий разработки ПО мы регулярно слышим такие научные термины, как самоорганизация и эмерджентность.

Основная причина, почему теория сложных адаптивных систем актуальна при разработке программного обеспечения, это продвигаемая ею концепция эмерджентности и эмерджентных результатов^[10].

Например, колония муравьев, мозг, иммунная система, Scrum-команды и город Нью-Йорк будут самоорганизующимися системами^[11].

Scrum – это не методология, не четко расписанный процесс и не набор процедур. Это открытый фреймворк при разработке программного обеспечения. Применяемые правила ограничивают поведение сложной адаптивной системы, в результате чего система самоорганизуется и приходит в состояние, адекватное решаемой задаче^[12].

Насколько оправданно применение теории сложности к разработке программного обеспечения? Согласны ли сами специалисты по сложным системам, что такие термины, как самоорганизация и эмерджентность, применимы не только к описанию муравейников, мозга и иммунной системы, но также и к Agile-командам?

Некоторые ученые уже обрушились с критикой на людей вроде нас за то, что мы заимствуем их научную терминологию. Они утверждают, что мы берем термины, не вникая в их значение, и используем научные понятия, не имея на то достаточных концептуальных оснований. И еще они говорят, что нас опьяняют сами слова вне связи с тем, что они на самом деле означают [Sokal 1998: 4].

По правде говоря, я здесь немного сжульничал. Разнос, который Сокал устроил тем, кто использует теорию сложности (или скорее злоупотребляет ею), адресован в первую очередь не сторонникам Agile-методологий, а людям в целом. Но сигнал мы услышали. Чтобы усвоить его еще лучше, вот цитата, напрямую относящаяся к существу вопроса:

Нет ничего неожиданного в том, что гуру теории сложности очень расстроены тем, насколько безответственно терминология их теории используется в литературе и дискуссиях, касающихся менеджмента – бывает, что она используется чуть ли не в метафорическом смысле. Один [такой гуру] зашел настолько далеко, что, отмечая полезность подобных книг для менеджеров, всерьез рекомендует вымарывать из них любые ссылки на теорию сложности^[13].

Ох!

Впрочем, я вновь немного сжульничал. Эта критика была направлена против литературы по менеджменту, в которой авторы злоупотребляют терминами теории сложности, а не против книг о гибких методологиях. Но все же… лучше внять и этому предупреждению.

Мы обязаны проявлять осторожность при переносе терминологии из науки о поведении сложных систем в другие области, включая менеджмент и разработку ПО. Например, когда небольшая шероховатость, возникшая в ходе проекта по разработке ПО, неожиданно выливается в большие проблемы, нет ничего легче, чем заявить, что это проявление «хаотического» поведения системы. Но если мы при этом не понимаем, что с научной точки зрения означает термин «хаос», то сильно рискуем стать посмешищем в глазах специалистов по теории сложности…

Итак, будет ли использование понятия самоорганизация злоупотреблением научной терминологией?

А как насчет «эмерджентного дизайна»? Это тоже злоупотребление?

Лично я так не думаю. Но в любом случае будет разумно сохранять критичность и здоровую долю скепсиса.

В этой книге я пишу об идеях и концепциях из теории сложности, которые мы могли бы применять при управлении командами разработчиков ПО. И хотя я ловлю себя на том, что меня тоже опьяняют слова, я собираюсь пользоваться соответствующей терминологией с учетом точного значения того или иного научного термина и только при условии, что для этого имеются достаточные основания.

Новая эра: мышление в категориях теории сложности

Если вы применяете теорию сложности в контексте разработки программных продуктов и менеджмента в целом, это значит, что вы приняли решение рассматривать свою организацию как систему.

В этом нет ничего нового. Системная динамика, первоначально возникшая в 1950-х годах (не путать с теорией динамических систем), разрабатывалась как инструмент, призванный помочь менеджерам лучше понимать и совершенствовать производственные процессы. Она была одним из первых методов, продемонстрировавших, что даже те организации, что кажутся простыми, могут проявлять неожиданное нелинейное поведение [Stacey 2000a: 64]. Системная динамика показала, что структура организации, с ее многочисленными циклическими взаимноблокирующими взаимодействиями и частыми задержками реакции, может сильнее воздействовать на поведение организации, чем параметры ее отдельных компонентов. Системная динамика помогла менеджерам улучшить понимание бизнес-процессов и в то же время привлекла внимание к тому, что свойства организации часто становятся результатом ее поведения как целостной системы и не могут быть сведены к свойствам образующих ее индивидуумов. Системная динамика не будет частью суммы наших знаний о системах. Это просто инструмент (вроде старого калькулятора), интересный для менеджеров со склонностью к математике.

В 1980-х годах возникла новая идеология, в чем-то схожая с системной динамикой, получившая название системное мышление и обязанная своей популяризацией книге Питера Сенге «Пятая дисциплина»^[14] [Senge 2006]. Системное мышление представляет собой набор установок при решении «проблем», которые рассматриваются как часть более обширной системы. Системное мышление фокусируется на циклических взаимоотношениях между компонентами системы и нелинейных причинно-следственных связях внутри нее. Часто это позволяет избежать непредвиденных последствий, риск возникновения которых повышается, если компоненты рассматриваются изолированно. Системное мышление в чем-то похоже на системную динамику, однако в последней при анализе последствий альтернативных решений широко применяются симуляции и математические расчеты. Системное мышление считается более субъективным в своей оценке сложных структур, поскольку его концепция более расплывчата [Forrester 1992]. Основная ценность системного мышления состоит в том, что оно позволяет людям сосредоточиться на проблемах систем, а не людей. Я бы сказал, что системное мышление похоже на старую фотокамеру, которая может дать менеджерам более полную картину их организаций с интересных, но субъективных ракурсов.

Исследование сложности в социальных системах ведется в рамках социологического направления, которое принято называть социологическая системная теория. К сожалению, ни системная динамика, ни системное мышление в явном виде не признают, что любые попытки проанализировать и применить социальную сложность на основе подхода сверху вниз будут нереалистичными [Snowden 2005]. Использование упрощенных симуляций при описании поведения организаций или кружков, соединенных стрелками, для описания взаимодействия между командами или людьми создает ложное впечатление, что менеджеры в состоянии проанализировать свои организации, внести в них изменения и направить в нужное русло. Конечно же, системная динамика и системное мышление не отрицают существование нелинейных процессов, но все равно они исходят из базовой идеи, что топ-менеджмент в состоянии каким-то образом сконструировать «правильную» организацию, которая будет выдавать «правильные» результаты. Все эти подходы недалеко ушли от детерминистского мышления XIX века [Stacey 2000a]. Но XXI век – век сложности. Это время, когда менеджеры приходят к осознанию, что для управления сложными социальными системами необходимо понять, как они формируются и растут, а не как их конструировать.

В этой книге теория сложности применяется последовательно и в полном согласии с ее основными постулатами нелинейности, недетерминизма и неопределенности. Менеджмент 3.0 базируется на мышлении в категориях сложных систем. Оно исходит из представления, что менеджеры неспособны конструировать самоорганизующиеся команды и управлять ими. Таким командам надо давать возможность формироваться и развиваться постепенно. Управление организациями с помощью негибких моделей или жестких планов неэффективно. Продуктивность – это постепенно проявляющееся свойство, возникающее благодаря самоорганизации и эволюции команд. Мне нравится сравнивать этот тип мышления с источником света или энергии, который дает начало всему и благодаря которому произрастают все плоды. Калькуляторы и камеры – весьма интересные устройства, но без света они бесполезны.

В главе 4 мы направим этот поток света на команды разработчиков ПО и увидим, каким образом первый компонент Менеджмента 3.0 помогает таким командам расти, самоорганизовываться и адаптироваться к изменениям в среде.

Резюме

Теория сложности – междисциплинарный подход к исследованию систем, развивающий достижения общей теории систем, кибернетики, теории динамических систем, теории игр и эволюционной теории.

Широко признано, что выводы теории сложности применимы к социальным системам, примерами которых будут команды разработчиков ПО, хотя еще не до конца понятно, насколько далеко следует заходить по пути переноса концепций из одной дисциплины в другие.

Одно из важных наблюдений состоит в том, что сложность системы (то, насколько она предсказуема) и запутанность ее структуры (то, насколько легко ее понять) – далеко не одно и то же. Еще одно важное наблюдение – многие сложные системы могут адаптироваться к изменениям в среде. Такие системы называют сложными адаптивными системами (САС).

Социологическая системная теория – дисциплина, рассматривающая социальные группы в качестве сложных адаптивных систем.

Подумать и сделать

Давайте посмотрим, как применить некоторые идеи из данной главы в вашей компании:

• Развивайте свою способность к мышлению в категориях сложных систем. Подпишитесь на блоги или группы, в которых обсуждаются темы, связанные с самоорганизацией команд и использованием теории сложности при управлении организациями.

Глава 4
Информационно-инновационная система

Когда актер приходит ко мне, чтобы обсудить свою роль, я говорю ему: «В сценарии все написано». Если он спрашивает «А какова моя мотивация?», я отвечаю: «Твоя зарплата».

Альфред Хичкок, режиссер (1899–1980)

Проекты по разработке программного обеспечения являются сложными адаптивными системами. Эту точку зрения разделяют многие эксперты по разработке ПО и проповедники гибких и бережливых методологий. Но что делает адаптивные системы действительно рабочими?

По словам Митчелла Уолдропа, автора книги «Сложность: Новая наука на границе упорядоченности и хаоса» (Complexity: The Emerging Science at the Edge of Order and Chaos), основным предметом дискуссий в Институте Санта-Фе (лидер мировых исследований в области сложных систем) стали состоящие из агентов системы. Этими агентами могут быть молекулы, нейроны, веб-серверы и рыбы. А также люди, которые постоянно организуются и реорганизуются в более крупные объединения, образуя новые структуры с поведением, несводимым к поведению составляющих их элементов [Waldrop 1992: 88].

Когда я смотрю на проекты по разработке ПО, я вижу людей, которые постоянно организуются и реорганизуются в более крупные объединения (проектные команды, социальные группы, временные группы для решения какой-либо проблемы, комитеты и так далее). Новые структуры образуются также на уровне проектных команд и начинают демонстрировать эмерджентное поведение. Очевидно, что, как и другие сложные системы, проекты по разработке ПО состоят из агентов (людей), которые взаимодействуют друг с другом и образуют интегрированное целое. (Обратите внимание, что термин агенты в сложных системах означает всего лишь взаимодействующие элементы или части и не имеет никакого отношения к программным агентам, которые создаются разработчиками.)

Хотя проекты по разработке ПО могут состоять из большого количества элементов, истинными агентами будут только люди, которые представляют собой активные элементы (рис. 4.1). (На более высоком уровне агентами также можно считать сами команды.) Функциональные требования, спецификации, артефакты, инструменты, технологии и процессы не будут агентами, поскольку они не могут самостоятельно организовываться, реорганизовываться или инициировать взаимодействие с другими элементами проекта. В рамках проектов только люди имеют необходимую способность к взаимодействию и организации, но также им нужна энергия для проявления этих способностей. Поэтому создание у людей энергии и становится первым императивом модели Менеджмента 3.0, и данная глава в основном о людях. Но прежде чем на них сосредоточиться, мы должны поговорить об организациях.

Инновации – ключ к выживанию

В любой конкурентной среде ключом к выживанию будут инновации. Это вопрос жизни и смерти для компаний во всем мире [Davila 2006: 6]. Как правило, максимум ценности в сфере бизнеса создается в результате инноваций [Highsmith 2009: 31]. Организации, конкурирующие на рынке знаний (включая компании, разрабатывающие ПО), должны фокусироваться в первую очередь на инновациях, отмечает профессор Икудзиро Нонака в своей статье «Компания, создающая знания» [Nonaka 2008]. И это относится не только к компаниям этого типа, утверждает Роберт Остин – ученый, который специализируется на креативности и инновациях. В условиях, когда современные технологии постоянно снижают стоимость итераций, компании все в большем числе индустрий могут конкурировать в области инноваций [Austin, Devin 2003: 53].

Надо же, какое совпадение…

Понятие «инновации» находится в центре внимания наук, изучающих сложные системы. Исследователи обнаружили, что сложные адаптивные системы активно ищут для себя позицию между упорядоченностью и хаосом, поскольку инновации и адаптация происходят, когда системы находятся «на кромке хаоса» [Kauffman 1995]. В биосфере примерами инноваций могут служить некоторые виды обезьян, кротов и осьминогов. И конечно, пудели (что подтверждает наличие у природы своеобразного чувства юмора). Исследователи утверждают, что в основе инноваций в физическом мире, биологии, психологии и других сферах лежит то самое интересное состояние между упорядоченностью и хаосом, которое мы называем сложностью.

Согласно таким публикациям, как «Сложность и инновации в организации» [Fonseca 2002] и «Перспективы теории сложности в применении к инновациям и социальным изменениям» [Lane 2009], инновации – характерное явление типа «снизу вверх». Эти авторы подчеркивают, что программы инноваций обречены на неудачу, если они спускаются вниз топ-менеджментом и сопровождаются назначением лиц за них ответственных (которым и поручается труднейшая задача изобрести что-то новое). Такой подход представляет собой наивную попытку управлять будущим и базируется на причинно-следственном детерминизме. Подобные программы просто не работают.

Теория сложности утверждает, что инновации могут быть лишь эмерджентным результатом, запланировать который невозможно. Чтобы возникло нечто новое, необходима основа, на которой оно может возникнуть. Я идентифицировал пять драйверов инноваций (рис. 4.5), которые мы сейчас и обсудим.

Знания

Как отмечают Дон Тапскотт и Энтони Уильямс в книге «Викиномика» [Tapscott, Williams 2008]^[15], инновации предполагают присутствие в компании категории сотрудников, чья деятельность связана с обработкой имеющейся и получением новой информации. К этой категории относятся разработчики, дизайнеры, архитекторы, аналитики, тестировщики и другие профессионалы в области создания ПО. Чтобы подчеркнуть, что в новых условиях в основе многих профессий лежит работа с информацией, гуру менеджмента Питер Друкер предложил термин «интеллектуальный работник». Идею, что знания становятся топливом для инноваций, впоследствии поддержали многие эксперты в области бизнеса (например, Икудзиро Нонака [Nonaka 2008]).

Именно так все и происходит в проектах по разработке ПО. Знания позволяют нам создавать новые программные продукты для заказчиков, представляющие собой бизнес-ценность, которой они ранее не располагали. Таким способом наши проектные команды превращают знания в инновации.

Знания образуются через постоянное поступление информации из внешней среды через образование и обучение, запросы и спецификации, измерения и обратную связь, имея своим результатом непрерывное накопление опыта. Команда разработчиков ПО будет системой, которая потребляет и трансформирует информацию, на выходе обеспечивая производство инноваций.

Некоторое время назад нейробиологи выяснили, что в человеческом мозгу невозможно локализовать конкретные участки, где хранится информация. В отличие от данных, записанных в двоичной системе счисления, которые помещаются в четко определенные ячейки в памяти компьютера, в человеческом мозгу знания хранятся в распределенном виде. Если небольшая часть мозга по какой-либо причине отключена, высока вероятность, что знания не пострадают. Хранение знаний в мозгу организовано подобно существованию информации в интернете – в виде параллельной распределенной системы, которой свойственна значительная избыточность, поскольку одни и те же данные хранятся во многих местах и при этом отсутствует централизованное управление информацией. Некоторые называют это «голографической памятью» по аналогии с голограммами, которые многократно сохраняют информацию о целостном трехмерном изображении в каждом участке пластинки [Hunt 2008: 48].

Это означает, что узлы информационных сетей (примерами которых будут человеческий мозг, интернет, социальные группы) сохраняют работоспособность даже в случае лишь частичного доступа ко всей сети, хотя производительность падает одновременно со снижением числа соединений. Точно к такому же выводу в своих исследования пришли Роб Кросс и Эндрю Паркер, опубликовавшие свои результаты в книге «Невидимая сила социальных связей»^[16]. Они обнаружили, что вовсе не профессиональные знания людей будут самым надежным индикатором их результативности. Гораздо важнее количество и качество связей, которыми данный индивидуум обладает в организации [Cross 2004: 11].

Учитывая, что знания, используемые в проектах, в значительной степени неявные или подразумеваемые (не задокументированы и трудны для передачи), люди в организации должны передавать их друг другу посредством «осмотической коммуникации» в процессе совместной работы [Cockburn 2007: 202]. Следовательно, критически важно, чтобы люди, входящие в команду разработчиков, хотели сотрудничать друг с другом и делиться этими знаниями. (Мы вернемся к проблемам коммуникации в главе 12 и 13. В данный момент нас интересуют лишь аспекты, связанные с людьми.)

Разработчики ПО конвертируют информацию в инновации, и это полностью созвучно с фактом № 22 из книги Роберта Гласса «Факты и заблуждения профессионального программирования»:

80 % усилий по созданию ПО приходятся на интеллектуальную деятельность. Значительная часть этой деятельности креативна. И лишь небольшая часть – чисто техническая^[17].

 

Профессия разработчиков ПО заключается в решении проблем. Гласс выполнял свои измерения на примере системных аналитиков, и мы уже знакомы с его выводом, что они проводят 80 % своего времени в размышлениях. Я думаю, что то же самое относится и ко всем остальным участникам проектных команд (может быть, за исключением некоторых бизнес-консультантов).

То же самое исследование, проведенное Глассом, показало, что 16 % интеллектуальных задач, с которыми имеют дело разработчики, требуют креативности. Это в очередной раз подтверждает тезис о том, что креативность играет важную роль в процессе превращения информации в инновации.

Креативность

Креативность – критически важная переменная в процессе создания ценности на основе знаний [Kao 2007]. Креативность заключается в способности отходить от шаблонных подходов при создании нового, предлагать новые ответы на основе старой информации и видеть решения там, где до этого никто их не видел. (Иногда это выглядит как кража старых идей и заметание следов, чтобы никто об этом не узнал.)

Важность знаний в качестве исходного сырья для креативности в настоящее время широко признается исследователями [Runco, Pritzker 1999]. Имеются подтверждения, что креативность в первую очередь базируется на знаниях людей и способности комбинировать несходные понятия, в результате чего возникают новые способы смотреть на вещи. С точки зрения наивных и неопытных наблюдателей, креативность часто похожа на магию. Но в реальности она возникает на плодородной почве знаний ценой многих часов тяжелого труда и размышлений.

Не существует единого определения креативности или общепринятого понимания ее природы. В литературе по психологии можно найти по меньшей мере 60 различных определений этого термина. Тем не менее существует достаточно распространенная точка зрения, что креативность проявляется в способности создавать идеи, которые одновременно оригинальны и полезны.

Оригинальность

Намерение (или надежда) многих разработчиков таково: решать проблемы, разрабатывая программное обеспечение, подобное которому еще никто никогда не создавал (при этом каждый из них хочет, чтобы это удалось именно ему, а не кому-нибудь другому!). Чтобы сделать каждую строчку кода уникальной, к их услугам такие методы, как объектно-ориентированное программирование, компонентное программирование, сервисно-ориентированная архитектура и рефакторинг. В глубине души разработчики полагают, что в идеальном мире каждый отрезок кода должен существовать в единственном экземпляре. В попытках реализовать эту утопию у них существенно больше возможностей, чем, например, у писателей, художников, архитекторов или парикмахеров. В арсенале представителей других креативных профессий нет такого разнообразия приемов. (Не исключено, что они даже не знают, что такое абстрактные конструкции или косвенная адресация.)

Полезность

Аналогичным образом второе намерение большинства разработчиков таково: создать полезное программное обеспечение. Вполне возможно, что ни один другой вид деятельности в сфере бизнеса не внес такой вклад в повышение глобальной производительности. Мне встречалось мнение, что ценность программных продуктов с точки зрения бизнеса на несколько порядков превышает ценность любых других креативных продуктов. И вряд ли с разработчиками ПО можно даже отдаленно сравнивать писателей, художников, архитекторов и парикмахеров. (Единственное исключение я готов сделать для рок-звезд.) При этом разработчики даже не считают себя «креативными» со всеми расплывчатыми коннотациями, которые связаны с этим словом. У большинства из них далеко не артистический темперамент. Они просто хотят создать нечто, чем будут пользоваться. (Не будем здесь говорить о том огромном количестве функционала, который создается ими в надежде, что он будет кому-нибудь нужен, но которым так никто и не пользуется.)

По всей видимости, в основе разработки программных продуктов лежит креативность, то есть создание продуктов одновременно оригинальных и полезных. Наиболее известная модель креативного процесса была предложена Грэмом Уоллесом и Ричардом Смитом в вышедшей в 1926 году книге «Искусство мыслить» (The Art of Thought). Описанный ими креативный процесс, включающий пять стадий, столь же применим к созданию ПО, как и к любому другому творческому процессу. Вообразим, например, что вам поручено улучшить работу сайта. В этом случае пять стадий креативного процесса могли бы выглядеть следующим образом:

1. Подготовка. Нахождение и определение измерения, в котором локализуется данная проблема; например, сколько времени уходит на выполнение (некоторых) запросов к серверу базы данных.

2. Обдумывание. Размышления о проблеме как в сознательном, так и в подсознательном режиме, например, когда вы принимаете душ, играете в покер и обсуждаете с друзьями последний фильм про Бэтмена (возможно, даже делая все это одновременно).

3. Интуитивное предчувствие. Осознание, что решение может быть найдено в улучшении модели данных, а не в более эффективной структуре запросов или более совершенном оборудовании, как вы думали до сих пор.

4. Озарение. Внезапное осознание, что решение может заключаться в «денормализации» некоторых таблиц базы данных, что ускорит обработку запросов.

5. Проверка. Испытание нового подхода, проверка его эффективности и работа по совершенствованию, пока не будут получены желаемые результаты.

Это и есть креативность. Данный процесс используется при сборе информации от будущих пользователей продукта, анализе и дизайне, тестировании и в ходе любых других этапов разработки программного продукта.

А также при написании книг.