Agile-менеджмент. Лидерство и управление командами - читать онлайн книгу. Автор: Юрген Аппело cтр.№ 18

читать книги онлайн бесплатно
 
 

Онлайн книга - Agile-менеджмент. Лидерство и управление командами | Автор книги - Юрген Аппело

Cтраница 18
читать онлайн книги бесплатно

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

Чем эта модель отличается от других?

Известна модель Cynefin (читается как Кеневин) (рис. 3.3a), предложенная Дэвидом Сноуденом – специалистом в области управления знаниями. Эта модель предлагает типологизировать ситуации как относящиеся к одной из четырех областей: простые, запутанные, сложные и хаотические (имеется также промежуточная категория – беспорядочные) и применяется при принятии решений и выработке политик в разных областях [Snowden 2010b].

Похожая модель была создана и профессором менеджмента Ральфом Стейси. Его модель называется матрицей согласованности и определенности (рис. 3.3b). Матрица разделена на четыре области (область простых систем, запутанных, сложных и область анархии или хаоса), размещенных вдоль двух осей: степени согласованности и степени неопределенности [Stacey 2000b].

Глава 16 в этой книге называется «Все модели неверны, но некоторые из них полезны», и это утверждение соответствует действительности. Все три приведенные здесь модели неверны, но каждая из них может быть полезна. Разница между моей моделью и двумя другими состоит в том, что в моей между запутанными и сложными системами нет четкой границы. В ней также идентифицированы шесть типов систем, а не четыре, при этом запутанные и сложные пересекаются. Если эта модель покажется вам полезной, используйте ее при оценке систем различных типов. Если нет, возьмите любую из двух оставшихся. Они тоже неплохие.

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

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

Упрощение – действия, направленные на то, чтобы сделать структуру или устройство системы более понятным (в моей модели этому соответствует движение сверху вниз).

Линеаризация – действия, направленные на то, чтобы сделать поведение системы более предсказуемым (в модели – движение справа налево).

К сожалению, на дилетантском уровне часто путают линеаризацию и упрощение. И тут-то возникают проблемы.

А как насчет сложности программного обеспечения?

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

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

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

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

Еще раз об упрощении

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

Все следует упрощать до тех пор, пока это возможно, но не более того.

Альберт Эйнштейн

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

Простота – это миф, время которого прошло, если оно вообще когда-либо существовало [Norman 2007].

В своей интереснейшей статье «Простота сильно переоценена» Дон Норман обсуждает вопрос, насколько ценно с точки зрения пользователя добавление функциональных возможностей в тот или иной продукт по сравнению с их ограниченным количеством. Обилие функциональных возможностей подразумевает иное или более сложное поведение продукта, а зачастую и его иную структуру. В моей диаграмме этому соответствует движение по обеим осям – горизонтальной и вертикальной. (Например, когда Google добавил в почтовый сервис Gmail отдельный почтовый ящик для приоритетных сообщений, поведение Gmail усложнилось. Стал более запутанным и пользовательский интерфейс, хотя для меня он остался вполне понятным.)

К сожалению, Дон Норман использует термин «упрощение» как для обозначения линеаризации поведения (движение вдоль горизонтальной оси в моей модели), так и для обозначения упрощения структуры (движение по вертикальной оси). Тем самым он сделал свой тезис достаточно запутанным, и именно поэтому многие в нем не разобрались. Может быть, для иллюстрации своей мысли ему стоило бы воспользоваться рисунками:

Цель визуального мышления состоит в том, чтобы сделать сложные вещи понятными посредством визуализации, а не в том, чтобы упростить их [9].

Вернуться к просмотру книги Перейти к Оглавлению Перейти к Примечанию