Применяемая в книге модель показана на рис. 1.4. Я называю ее моделью Менеджмента 3.0. Она рассматривает организацию с шести углов зрения. Каждый из этих компонентов описан в книге отдельно, и каждому посвящено по две главы – теоретической и практической. Но прежде чем мы начнем обсуждать модель в деталях, я считаю важным еще раз вернуться к двум базовым комплексам идей, лежащим в ее основе, а именно к гибкости и сложности, а также уделить немного времени истории каждого из этих комплексов. Глава 2 содержит краткий обзор гибких методологий разработки программного обеспечения, а в главе 3 рассматриваются основы теории сложности. Суть модели, то есть способы управления командами разработчиков, вы найдете в центральной части книги, которая открывается главой 4 «Информационно-инновационная система» и заканчивается главой 15 «Улучшение всего». И наконец, глава 16 содержит краткое заключение.
Хотелось бы мне, чтобы подобная книга попала мне в руки десять лет назад, когда я занимался своим стартапом. Но в этом случае вполне могло случиться, что я все же заработал бы свои миллионы и, по всей вероятности, вряд ли стал бы заморачиваться написанием этой книги. По-видимому, все это означает, что планирование карьеры зачастую бывает совершенно бесполезно, а неудачный проект может обернуться удачей – надо только суметь вовремя это увидеть.
Резюме
Человеческий мозг устроен таким образом, чтобы за каждым событием видеть определенную причину. Такое стремление к определению причинно-следственных связей полезно при прогнозировании и планировании. Однако очень часто ситуации куда сложнее, чем может показаться на первый взгляд. Теория сложности говорит нам, что применение линейного мышления для решения сложных проблем чревато болезненными ошибками.
Несмотря на то, что редукционизм (понимание природы системы через осмысление ее составных частей) оказался успешным в науке, в настоящее время общепризнанно, что, следуя по этому пути, можно зайти слишком далеко.
Чтобы разобраться во многих сложных проблемах, необходим более целостный подход, применяемый при изучении сложных социальных систем. Такой подход предлагает целостное представление о взаимодействиях, происходящих в группах людей.
Менеджмент 3.0 – это модель для Agile-менеджмента, которая позволяет применять подходы теории сложности к управлению командами, занимающимися разработкой программных продуктов с использованием гибких методологий.
Подумать и сделать
Давайте посмотрим, как применить некоторые идеи данной главы в вашей компании:
• Возьмите в качестве примера какую-нибудь реальную нерешенную проблему из своей профессиональной сферы. Попробуйте представить, в чем может состоять ее причина. Уверены ли вы, что эта причина – единственная? Почему вы так считаете? Обсуждали ли вы эту проблему со всеми заинтересованными сторонами? Все ли из них согласны, что проблема вызвана единственной причиной? Проведите такой же анализ для каждой из наиболее важных проблем, с которыми имеете дело. Убедитесь, что вы не упрощаете сложность данных проблем и не пытаетесь устранить причину, которая определена неправильно.
• Если сотрудники вашей компании при анализе проблем пользуются какими-то методиками анализа основной причины (например, методикой пяти «почему»), попробуйте обсудить с ними встроенную в эти методики тенденцию зачастую неоправданно упрощать отношения причины и следствия. У многих явлений, происходящих в сложных системах, имеются множественные причины, а кроме того, причины и следствия могут находиться в отношениях циклической зависимости. В таких ситуациях ни одна из причин не будет главной, поэтому методика анализа основных причин не может в полной мере отражать сложность окружающего мира. Преодолеть упрощенный взгляд на ситуацию можно с помощью дискуссии на эти темы с компетентными коллегами. Организуйте такое обсуждение.
Глава 2
Гибкие методологии разработки ПО
Каждое утро я встаю, преисполненный решимости изменить мир и прекрасно провести время. Иногда это затрудняет составление плана на день.
Э.Б. Уайт, американский писатель (1899–1985)
Для некоторых из вас эта глава необязательна. Если вы знакомы с Agile-методологиями разработки программного обеспечения[3], вы уже и так много знаете (если не все) о том, о чем тут пойдет речь. Эта глава скорее предназначена для тех читателей, которые хотели бы узнать немного больше об истории и основах гибких методологий прежде, чем мы начнем говорить о роли менеджеров в гибких организациях (глава 4 «Информационно-инновационная система»).
В этой книге я исхожу из представления, что вы знаете лишь кое-что об основах гибких методологий. А пока сделайте вид, будто считаете, что XP – это старая операционная система, и продолжайте читать.
Прелюдия к гибким методологиям
Я люблю считать деньги почти так же, как и тратить их. В начале 1990-х годов, когда я учился в Делфтском техническом университете, в свободное время я написал бухгалтерскую программу. Мне было интересно этим заниматься, несмотря на небольшое неудобство: денег, которые нужно было считать, у меня не было. Не исключено, что где-то в глубине души я надеялся, что миллионы появятся автоматически, как только я буду готов их сосчитать. Увы, этого не случилось.
Я был единственным автором этого программного продукта (около 30 000 строк кода). Я не владел формальной методологией, у меня было мало опыта создания ПО, а также не было менеджера, коуча или ментора. Но у меня имелось время, компьютер, видение и страстное желание создать великолепный продукт (рис. 2.1).
К своему удивлению, я сумел продать эту программу дюжине клиентов, и некоторые из них испытали приятный шок от того, что программный продукт может быть простым, удобным для пользователей и иметь симпатичный интерфейс (для программы, написанной в 1990-е годы). Хотя прошло уже двадцать лет, я до сих пор пользуюсь этой программой для управления своими финансами.
Как это вообще возможно? Как неопытному программисту удалось создать продукт столь высокого качества, что он работает почти безупречно вот уже почти двадцать лет?
Не имею ни малейшего представления.
Но… У меня есть список из нескольких пунктов, которые должны быть знакомы последователям гибких методологий разработки.
• Я работал над своим продуктом с энтузиазмом. У меня был кое-какой опыт взаимодействия с бухгалтерскими приложениями, и я был убежден, что их разработали в аду с целью лишить пользователей всех жизненных и душевных сил. Мое видение состояло в том, что мой продукт будет совершенно иным. В отличие от других программ, имевшихся на рынке, пользоваться моим продуктом будет одно удовольствие.
• Я сам был своим критично настроенным заказчиком. Я создавал эту программу для себя, а не для других. Безусловно, я был счастлив, когда мне удалось найти нескольких покупателей, хотя мне и не удалось заработать миллионы, на которые я рассчитывал. Но что бы я ни делал, самым важным было, чтобы продукт работал именно так, как я этого хотел.
• У меня не было плана, только список функциональных возможностей, которыми должен был обладать новый продукт. Я начал с такой наиболее часто применяемой операции, как ввод транзакций. Затем перешел к менее критичным функциям вроде составления баланса и внесения корректировок. В конце добавил такие необязательные приятные вещи, как подсказки и возможность экспорта данных. Я занимался этим до тех пор, пока мне все не надоело, и я просто не объявил продукт готовым.