Линейный и проектный менеджмент

Мое имя в Голландии не самое распространенное. Поэтому на разных этапах моей карьеры мне приходилось мириться с тем, что его часто коверкали. Временами из-за этого возникали недоразумения. Когда имена людей или названия предметов похожи, многие склонны почти не замечать остальных различий между ними. Если бы имя Эллы Фицджералд было не Элла, а Юрген, то, уверен, коллеги попросили бы меня спеть.

Мне кажется, что с термином «менеджер» есть точно такая же проблема.

В 2005 году группа людей, специализирующихся в области управления (проектные менеджеры, линейные менеджеры и др.) собрались вместе и опубликовали Декларацию взаимозависимости (рис. 2.4).

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

К сожалению, проектный менеджмент и функциональный (линейный) менеджмент часто путают. В ряде отличных книг, написанных ведущими экспертами, включая «Гибкий менеджмент» (Agile Management) [Anderson 2004], «Управление Agile-проектами» (Managing Agile Projects) [Augustine 2005] и «Гибкое управление проектами» (Agile Project Management) [Highsmith 2009], вопросы проектного и функционального менеджмента обсуждаются параллельно. Та же ситуация наблюдается и на многих форумах, в блогах и журналах. Мне бы хотелось, чтобы это было не так, поскольку проектный и линейный менеджмент — не одно и то же. Это все равно что путать разработчиков ПО с системными администраторами. Возможно, они разделяют одни и те же идеи, смеются над одними и теми же шутками и (фигурально выражаясь) стригутся и одеваются одинаково, но все же это разные люди. (Я серьезно. Попробуйте попросить разработчика софта починить вам компьютер. Но лучше даже не пробуйте.)

Не делая четкого разграничения между линейными менеджерами и менеджерами проектов, мы затрудняем понимание и теми и другими своей роли в компаниях, практикующих гибкие методологии разработки. К счастью, я далеко не единственный, кто это понимает. В нескольких книгах, вышедших задолго до моей, включая «За закрытыми дверями» (Behind Closed Doors) [Rothman, Derby 2005] и «Управление разработкой ПО на основе Lean-методологий» (Leading Lean Software Development) [Poppendieck 2009], функции линейных менеджеров в компаниях, специализирующихся на разработке ПО, изложены более четко.

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

А что касается тех, кто думал, открывая эту книгу, что я DJ Юрген, то им не повезло.

Резюме

Гибкие или Agile-методологии — это подход к разработке программного обеспечения, появившийся в 1990-е годы в качестве реакции на засилье бюрократии, а также частных методов, создаваемых каждый раз заново «под конкретную задачу» (все они не обеспечивали успешной разработки ПО).

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

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

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

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

• Взгляните на свою организацию с точки зрения семи проектных измерений (люди, функциональность, качество, инструменты, время, ценность, процесс). Учитываете ли вы все эти измерения в своих проектах по разработке ПО? Гибки ли ваши команды во всех семи измерениях? Если нет, то что вы планируете по этому поводу предпринять?
• Подумайте о менеджерах, работающих в вашей компании. Кто из них может стать потенциальным препятствием на пути внедрения гибких методологий? Можете ли вы что-то в связи с этим предпринять? Удостоверьтесь, что вы четко понимаете, что вам нужно от них, чтобы ваш подход к внедрению Agile-методологий оказался успешным.
• Всем ли ясно, кто является линейным менеджером (и по отношению к кому), а кто нет? Существует ли неясность или разногласия относительно распределения функций между линейными и проектными менеджерами? Если да, то что вы предпримете, чтобы решить эту проблему?
• Развивайте свои навыки в области Agile-методологий, подписавшись на блоги или группы, в которых обсуждается данная тематика. Актуальный список этих блогов и групп можно найти на сайте, посвященном Менеджменту 3.0 (http://www.management30.com).

Глава 3

Теория сложности

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

Герберт Бойер,

профессор биохимии

Многие эксперты в области гибких методологий согласны, что команда разработчиков представляет собой сложную адаптивную систему, поскольку состоит из множества частей, взаимодействующих друг с другом и отделенных внешней границей, и способна изменяться и учиться на собственном опыте [Highsmith 1999: 8], [Schwaber 2002: 90], [Larman 2004: 34], [Anderson 2004: 1], [Augustine 2005: 24]. Кто я такой, чтобы утверждать обратное?

Журнал «Эмерджентность: Теория сложности в применении к организациям» однажды провел обширное исследование книг по менеджменту, в которых упоминается теория сложных систем. Среди рецензентов были специалисты в самых различных областях, включая физику и математику. Все они сошлись во мнении о полезности теории сложности при управлении организациями и для менеджмента в целом:

Было зафиксировано общее согласие [рецензентов], что использование идей теории сложности имеет значительные перспективы для менеджмента как дисциплины и при практическом управлении организациями[7].

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

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

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

Необходимое предупреждение: данный обзор по необходимости неполон, излишне упрощен и временами субъективен. Но я уверен, что именно по этим причинам он будет абсолютно понятен.

Важность междисциплинарного подхода

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

Большинство университетов и исследовательских институтов организованы именно в виде таких колодцев. Физики работают бок о бок с другими физиками, биологи — с биологами, а математики — с математиками. Это привело к фрагментации науки и распространению туннельного зрения среди ученых и исследователей. Различные научные дисциплины настолько изолированы друг от друга, что ученые обычно не знают, над чем работают их коллеги [Waldrop 1992: 61].

Организационные колодцы в науке — это проблема, поскольку многие явления из разных научных областей часто похожи друг на друга. Например, некоторое время назад экономисты не могли понять природу такого явления, как «локальное равновесие», в то время как физикам уже была известна природа его физического аналога [Waldrop 1992: 139]. Фазовые переходы в физике подозрительно напоминают случаи периодически нарушаемого равновесия в эволюционной биологии. Биологи заметили, что математики могут помочь им в анализе экологии видов [Gleick 1987: 59]. А некоторые «открытия» математиков, как выясняется, были за годы до того сделаны метеорологами [Gleick 1987: 31].

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

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

Общая теория систем

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

Одним из достижений теории систем, развитие которой продолжалось вплоть до 1970-х годов, был перенос фокуса с элементов системы как таковых на организацию этих элементов. Тем самым было признано, что взаимоотношения между элементами системы — динамические, а не статические. Ученые идентифицировали и изучили такие явления, как аутопоэзис (самопостроение или способы, которыми системы конструируют сами себя), идентичность (каким образом системы можно опознать), гомеостаз (способность систем поддерживать свою стабильность) и проницаемость (то, как системы взаимодействуют с окружающей их средой) [Mitchell 2009: 297].

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

К сожалению, объединение этих первоначально разрозненных концепций не было доведено до конца (что не должно удивлять тех разработчиков ПО, которые пытались соединить различные практики или технологии). И тем не менее наследие общей теории систем весьма значительно. Почти все законы этой теории применимы и к сложным системам [Richardson 2004a: 75], и в целом эта теория продвинулась дальше, чем попытки унифицирования в области разработки программных продуктов.

Кибернетика

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

Кибернетика изучает сложные управляемые системы, имеющие цели и взаимодействующие с окружающей средой через механизмы обратной связи. Задача кибернетики — изучение процессов, происходящих в управляемых системах. Эти процессы состоят из многократных итераций какого-либо действия (которое вызывает изменения во внешней среде), получения информации о состоянии среды(данные о реакции внешней среды на совершенное действие), оценки (сравнение текущего состояния с целевым) и возврата на этой основе к совершению нового действия. Для кибернетики этот циклический процесс фундаментален.

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

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

Теория динамических систем

Если рассматривать общую теорию систем и кибернетику как ноги некоего человека, символизирующего собой всю массу знаний о поведении систем, то одной из его рук, бесспорно, будет теория динамических систем.

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

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

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

Теория игр

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

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

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

Эволюционная теория

Сейчас трудно представить себе человека, который не был бы знаком с эволюционной теорией. Она получила известность с момента выхода в свет в 1859 году «Происхождения видов» Дарвина, одной из самых знаменитых книг в истории. Практически все биологи согласны с базовыми утверждениями теории эволюции: постепенное генетическое изменение видов и выживание наиболее приспособленных организмов в результате естественного отбора.

Конечно, согласие относительно базовых постулатов не мешает бесконечным спорам биологов по поводу деталей процесса. Важность случайного генетического дрейфа (изменение вида без определенных причин), периодически нарушаемого равновесия (внезапные изменения вместо постепенных), эгоистичных генов (отбор на уровне генов, а не на уровне особей или популяций) и горизонтального переноса генов (передача генов другому организму) — все эти гипотезы многократно и страстно биологами обсуждались, принимались или опровергались [Mitchell 2009: 81–87]. (Но стоит только в качестве альтернативы предъявить биологам теорию разумного замысла, как они моментально объединяются в своем отрицании этой ненаучной ерунды.)

Эволюционная теория внесла значительный вклад в изучение всех видов систем, будь то биологические, цифровые, экономические или социальные. Утверждается, что команды, проекты и продукты эволюционируют в процессе приспособления к изменяющейся среде. И хотя «эволюционное управление разработкой» систем программного обеспечения — это далеко не та эволюция, о которой писал Дарвин, эволюционное мышление помогло разобраться с ростом, выживанием и адаптацией систем во времени. Поэтому я считаю, что эволюционная теория представляет собой интеллектуальную основу нашего знания о системах.

Теория хаоса

Хотя несколько открытий в рамках теории хаоса были сделаны ранее, настоящий прорыв был совершен в 1970–1980-х годах, а основной вклад был внесен такими людьми, как Эдвард Лоренц и Бенуа Мандельброт.

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

Еще одним из открытий теории хаоса стали фракталы и масштабная инвариантность, то есть свойство графиков, отражающих поведение систем, выглядеть одинаково независимо от применяемого масштаба.

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