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