• Культуры программных проектов: глава 3

    Posted on February 10th, 2010 Александр Орлов 4 comments

    Глава 3: Культурные Метафоры

    Очаровательные значения

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

    Судя по многочисленным исследованиям, оказывается, что мы используем метафоры постоянно. Они настолько распространены, что мы даже не осознаём, что используем их.

    Небольшая замечательная книга «Метафоры, по которым мы живём», написанная  Lakoff и Johnson, показывает, как ещё с младенчества мы учим основные пространственные метафоры вроде вверх – это хорошо, вниз – это плохо. Мы держимся за них, исследуем и расширяем всю нашу жизнь: «Пора повысить уровень жизни!»; «Его шансы на повышение всё ниже и ниже!» Позже мы узнаём о других метафорах, где идеи получают направление: «Я вижу, куда вы направляетесь с этим!»; «Я просто не пойму, откуда взялся этот парень!». Потом о том, что время – это деньги: «Таким способом ты сэкономишь много времени»; «Мы инвестировали месяца в этот проект». И потом мы проводим остаток жизни, создавая новые более богатые метафоры, переплетённые самыми разными способами. Эти метафоры формируют наше мышление и мировоззрение, позволяя нам исследовать идеи и делиться ими с другими.

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

    Мой коллега услышал о новой книге о DDD (Domain Driven Design). Он подумал, что она может быть интересной, и спросил меня, о чём это. Я объяснил, что это означает достаточно тщательное исследование области бизнеса, чтобы построить её модель в программном виде. У меня не было возможности углубиться в более детальное объяснение, так как он сразу же понял эту метафору о построении модели и, следуя её значению, закатил мне длинную лекцию на тему DDD, о которой у него вдруг оказались глубокие познания!

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

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

    Связь видна сразу, так как значение очевидно. Метафоры работают замечательно.

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

    Но если бы кто-то сказал «дот ком гамбургер», то большинство из нас вряд ли бы преуспели в связывании значения гамбургера и того, что случилось с дот комами. Гамбургеры – это довольно слабая метафора для дот комов.

    Разве что вы работаете в индустрии гамбургеров и можете найти некую связь.

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

    Многие программисты с пониманием улыбаются, когда кто-то говорит: «Мой менеджер – тупой босс Дилберта», но их менеджерам эта фраза вряд ли понравится (если только они не думают о своём боссе точно так же!). Чтобы метафора сработала, её значение должно иметь смысл конкретно для того, к кому она обращена.

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

    Я сказал коллеге метафору своего брата, что программирование – это решение кроссвордов. Эта метафора сработала для моего деда, но коллега был шокирован и возмущён. «Это не так!» – сказал он, – «У кроссвордов всего один правильный ответ, а в программировании их несколько». Метафора, так хорошо воспринятая дедушкой, не сработала для коллеги.

    Мой коллега предложил другую метафору: «Программирование – это игра для молодых людей.»

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

    Столкновения Культур

    Удобные, понятные метафоры помогают людям меньше беспокоиться при поиске решения проблем, с которыми они сталкиваются в течение дня. Люди, которым подходят одни и те же метафоры, разделяют общий взгляд на вещи и решают похожие задачи похожими способами. Эти люди будут понимать друг друга с полуслова и притягиваться друг к другу. А те, кто не разделяет их взглядов, будут смотреть на мир иначе, с трудом вписываться в коллектив, и, скорее всего, не задержатся в нём надолго.

    Компания СамоСервис попросила меня помочь в построении одной из их команд. На тот момент было пять вакансий. Мы получили 585 заявок на эти места. Из них отобрали двадцать финалистов, которые казались очень способными.

    С ними побеседовали потенциальные будущие сотрудники и менеджеры. В итоге наняли только двоих. Двое получили отказы, так как явно приукрасили свои способности в резюме. А 16 были отвергнуты из-за личностных нестыковок: «Он просто не вписывается в команду»; «Я не могу представить себя, работающим с ней»; «Он тут никому не понравится».

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

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

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

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

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

    Я хорошо знаю кое-кого, кто лично пережил столкновение культур. После многомесячного процесса найма он уволился в первые несколько недель работы. Руководство не хотело его отпускать и предложило выбрать почти любую позицию в компании. Поискав с неделю он сказал: «Тут нет места, где бы я смог что-то изменить к лучшему. Позиции варьируются, а культура нет.» – и ушёл.

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

    «Самые лучшие» в итоге ничего компании не дали. Мораль сей басни такова: не нанимайте людей, чтобы они что-то изменили, если вы не готовы изменить культуру.

    Эмоционально Заряженные Метафоры

    Позвольте мне остановиться на минутку и предупредить.

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

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

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

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

    Негативно Заряженные Метафоры

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

    Я слышал, как один человек поносил методилогию, называя её подходом 1984 года к разработке приложений, намекая на ужасы одноимённой книги Джорджа Оруэлла. Я знаю людей, которые стали побаиваться довольно популярной методологии, когда слышали, что её называют Лабораторией Безумного Учёного, ассоциируя методику с работой лунатиков, преследующих собственные опасные желания.

    Положительно Заряженные Метафоры

    Конечно же, тот же фокус можно проделать и с целью привлечения людей на свою сторону.

    Я слышал, как один менеджер по продажам постоянно называл методологии и инструменты, которые он продавал, Последним Словом Техники – что не шибко много говорит вам о способе применения на проектах, но вполне может дать клиенту приятные ощущения комфорта. А один из моих бывших начальников называл свою любимую довольно устаревшую методологию Практиками, Проверенными Годами, при этом клеймя новую многообещающую методологию Дикой Дорогой к Хаосу. Нетрудно догадаться, как регировало руководство, когда им предлагали выбрать между Практиками, Проверенными Годами, и Дикой Дорогой к Хаосу.

    Нейтральные Метафоры

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

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

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

    Когда я впервые услышал о методологиях, к которым тянутся люди Сервисной Культуры, их восновном называли Легковесными методологиями. Те, кто придумал эту метафору, надеялись, что люди поймут подразумеваемое отсутствие бюрократии. И тем не менее, многие ассоциировали Легковесность с ненадёжностью, а потому решали, что нет смысла их рассматривать. Методололгии быстро переименовали в Проворные (Agile).

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

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

    Обнаружение Культурных Метафор

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

    • Заводская Культура
    • Дизайнерская Культура
    • Сервисная Культура

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

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

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

    Тем не менее, культурные привязанности могут быть довольно сильными, и даже сегодня некоторые люди, несмотря на все доказательства, цепляются за Научную Культуру и во всех неудачах обвиняют недостаточно строгое следование правилам, лежащим в её основе. Если кому интересно, то Научная Культура более подробно описана в Приложении А, а тут мы её более обсуждать не будем.

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

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

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

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

    А может и нет.

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

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

    А Сервис может заставить вас скривиться от образов хамящих продавцов, работающих за мизерную плату.

    Культуры, имеющие один набор ассоциаций для кого-то, могут иметь совершенно другой набор для другого.

    Доминирующие Метафоры

    Я обнаружил, что кроме самого названия каждая из трёх культур подкреплена ещё и одной доминирующей метафорой:

    • Заводская Культура: Разработка приложений – это заводской конвейер
    • Дизайнерская Культура: Разработка приложений – это архитектурный дизайн
    • Сервисная Культура: Разработка приложений – это удовлетворение заказчика

    Каждая из трёх доминирующих метафор окрашивает наше суждение и направляет наши линии мысли довольно эмоциональным способом.

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

    Один знакомый из отдела продаж рассматривал разработку приложений как жидкость. Об одном проекте он сказал «Мы будем доить эту корову годами», а о другом «Компания должна вынуть пробку в этом проекте.» Я было подумал, что столкнулся с ещё одной метафорой о разработке программных приложений, но потом до меня дошло, что он говорил не о проектах, а о деньгах, заработанных или потраченных проектами. Он говорил о жидком капитале. (Прим.: Игра слов. В англ. языке liquid – означает ликвидный и жидкий.)

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

    • Заводская Культура: Разработка приложений – это заводской конвейер

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

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

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

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

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

    • Дизайнерская Культура: Разработка приложений – это архитектурный дизайн

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

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

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

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

    • Сервисная Культура: Разработка приложений – это удовлетворение заказчика

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

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

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

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

    Следственные Метафоры

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

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

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

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

    Культуры Заводская Дизайнерская Сервисная
    Доминирующие Метафоры
    Разработка приложений – это Конвейер Дизайн Архитектуры Удовлетворение клиента
    Аспекты продукции
    Программы Жёсткие Гибкие Мягкие
    Дизайн – это Проект Техническая деятельность Людская деятельность
    Требования Записываются Моделируются Делятся
    Аспекты людей
    Менеджеры – это Командиры и Надзиратели Лидеры Референты
    Команды – это Рабочие Эксперты Сотрудники
    Заказчики – это Покупатели Деловые люди Короли
    Аспекты рисков
    Содержание Фиксировано Уточняемо Вечно меняется
    Время – это Деньги Качество Изменения
    Качество Проверяется Это Стабильность Это приёмка клиентом
    Деньги – это Стоимость Производительность Незначимое
    Аспекты Контроля
    Успех – это Соответствие нормам Продукция с правильным дизайном Счастливые Заказчики
    Неудача Наказуема Код-Спагетти Выявляется рано
    Растрата Небрежность Бюрократия Низкая ценность
    Прогресс – это Завершение задачи Улучшение дизайна Частые поставки

    Что особенно интересно в этой таблице, так это то, что многие из перечисленных значений сами являются метафорами. Это следственные метафоры доминирующих метафор культур. Когда кто-то говорит «Программы жёсткие», или «Деньги – это Производительность», или «Время – это Изменение», то совсем не нужно это воспринимать буквально. Даже те, которые поначалу кажутся буквальными, вроде «Качество проверяется», «Дизайн – это техническое действие», и «Неудача выявляется рано», тем не менее, являются метафоричными для представителей соответствующих культур, поскольку каждая из них запускает мысленную цепочку ассоциаций, приводящих к сути вопроса.

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

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

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

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

    Две недели спустя они сделали презентацию иполнительному вице президенту. Мне повезло присутствовать на этой презентации. Каждый раз, когда они представляли очередной сценарий, вице президент встревал с вопросами о деталях пользовательского интерфейса: «Будут ли результаты поиска слева или справа?», «Какую цветовую схему будете использовать на окошках критериев поиска?», «Это будет квадратная или круглая кнопка?»

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

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

    Метафоры и Методологии

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

    Процесс развития смысловых значений неизменно ведёт к новым внутренним метафорам, сплетая вместе новые концепции, новые словари и новые соотношения, котрые сами по себе тоже подвержены постоянным личным рекурсивным толкованиям. Эти постоянные открытия являются «Ага!» моментами, ибо метафоры ведут нас к свежим интересным выводам.

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

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

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

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

    Компания, публикующая статистику, наняла меня на два месяца в помощь старшему архитектору приложений, чтобы помочь с определённым замысловатым дизайном. Изучив требования я открыл текстовый редактор и начал набирать некий код: небольшой тест, проверяющий одно из требований. Архитектор предостерёг меня, что если начальник отдела меня увидит за этим делом, то мне сделают суровый выговор. Но ведь настоящие архитекторы зданий создают мини-копии конструкций и тестируют их, попробовал оправдаться я. Но он сказал, что к нам это не имеет отношения. Методологическая книга говорит, что архитекторам нельзя писать код; они рисуют высокоуровневый дизайн, который затем передаётся старшим разработчикам, которые пишут детальный дизайн, которые в свою очередь дорабатываются младшими разработчиками. Эта буквальная интерпретация их методологии показалась мне ненормальной, поскольку архитекторы не имели возможности убедиться в надёжности их дизайна.

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

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

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

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

     

    4 responses to “Культуры программных проектов: глава 3”

    1. “Он говорил о жидком капитале.” перевод не очень понятен.

      Возможно, в оригинале идет речь о ликвидном капитале (http://translate.google.ru/#en|ru|liquid%20capital)? В таком случае использованная метафора опирается еще и на игру слов: в английском слово liquid может иметь значения “жидкий” и “ликвидный”

    2. Хороший комментарий, спасибо. Добавил как примечание.

    3. Pavel Drobushevich

      Часть про метафоры очень напомнила часть 2.1 (Метафоры, позволяющие лучше понять разработку ПО) из фундаментального “Совершенного кода”.

    4. [...] Глава 3 [...]

    Leave a reply

    You must be logged in to post a comment.