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

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

    Глава 2: Правила игры

    Я не виноват

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

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

    Кого же мы можем обвинять в провале проектов? Точно не себя! Это всё те придурки!

    Был 1988 год. Я только выпустился из университета и начал работать программистом. Глава компании Ричард созвал митинг всех девелоперов. «Я не доволен количеством багов в нашем софте. Если так будет продолжаться и далее, я уволю всех младших программистов, а менеджеры будут программировать.» Новые программисты, включая меня, сидели в ужасе, а более опытные закатывали глаза.

    Когда проект идёт плохо, мы склоняемся к мысли «Кто вообще мог надеяться на удачу в этом месте? Проект был обречён изначально, с этими клоунами в командах и ленивыми неудачниками, отвечающими за критические участки работы!»

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

    Год 2008. Я директор в большом известном доткоме. Логан, старший директор, не мог понять, почему постоянно пропускаются сроки. Он следил за сроками столько, сколько кто-нибудь мог вспомнить, но несмотря на постоянные изменения тактики, они постоянно ускользали у него из рук. У Логана возникла новая идея: «Слишком много проектов не укладываются в сроки. Теперь, когда вы услышите крайнюю дату, мысленно вычитайте две недели. Тогда все проекты будут сделаны вовремя или даже раньше срока!» Менеджеры мысленно заворчали. Позже, один из них мне сказал в корридоре: «Логан никак не поймёт; это всего лишь ещё одна тупая идея, которая увеличит стресс, уменьшит качество продукта и не принесёт ни капельки пользы в плане соблюдения сроков.»

    Игра по другим правилам

    Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?

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

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

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

    А откуда люди берут эти свои разные правила? Похоже, что ответ зависит от опытности человека.

    Начинающие: Предписанные правила

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

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

    В качестве примера такой группы правил, названной методологией, давайте заглянем в книгу Unified Software Development Process (USDP), от Booch, Jacobson и Rumbaugh, опубликованную Addison Wesley в 1998. Вот некоторые случайно выбранные правила:

    Страница 19: «При назначении ресурсов менеджер проекта должен минимизировать передачу артефактов из одних рук в другие так, чтобы ход процесса был максимально гладким.»

    Страница 34: «Разработчики начинают работу со сбора требований заказчика в виде юзкейсов. Затем они анализируют и разрабатывают систему так, чтобы она соответствовала юзкейсам, создав сперва аналитическую модель, а потом и имплементацинную модель.»

    Страница 76: «Архитектура создаётся архитектором заранее (во время фазы детализации требований). Это требует существенных предварительных затрат времени.»

    В книге сотни таких правил, а сама книга – это всего лишь подмножество более полного Rational Unified Process (RUP), который доступен по подписке.

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

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

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

    Получается, что методики, нацеленные на начинающих, предписывают авторитарные правила, которым надо следовать, авторы которых обещают: «эти правила работали для меня, и если вы будете им следовать, как положено, они и для вас сработают».

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

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

    Несмотря на заявления, ни одна методология ещё не стала тем самым набором правил для разработки приложений. Я видел, как некоторые консультанты отмахиваются от этого неудобства скользкими советами вроде: «Не существует идеальной методологии; вам нужно выбирать методологию, подходящую вашей организации, от проекта к проекту».

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

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

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

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

    Например, Ричард и Мэл были начинающими программистами в английской компании EDP. Ричард и Мэл мне сказали: «Нам не нужны никакие вонючие правила; мы просто делаем проекты». Я в этом усомнился и стал слушать разговоры в команде в течение целого дня. Вот некоторые вещи, услышанные мной:

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

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

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

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

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

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

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

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

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

    Большая американская компания – назовём её ИнтерСофт – купила задокументированную методологию у компании, которую назовём МетодВаре. МетодВаре была сертифицирована третьим уровнем СММ.

    Компания ИнтерСофт была впечатлена этим уровнем сертификации; она узаконила методологию компании МетодВаре. Меня это малость передёрнуло. Я объяснил, что СММ нацелена на то, чтобы показать зрелость процессов в организации (то есть в МетодВаре), а не зрелость методологии, которую они продают.

    SEI CMM определяет пять уровней зрелости. Первый – это вцелом неконтролируемый хаос. Второй – это когда некоторый контроль существует и применяется на некоторых проектах. На третьем уровне методология детально задокументирована и является обязательной во всей организации.

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

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

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

    На одной конференции я встретил тимлида. Его команда использовала RUP и его унифицированный язык моделирования UML. Они использовали коллаборационные диаграмы UML как часть своей работы над дизайном, но заспорили о том, не являются ли последовательные UML диграмы лучше. Они беспокоились, правильный ли путь они выбрали, и спросили меня, не надо ли им переключиться.

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

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

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

    В прошлом я пытался объяснить начинающим программистам, что нет ничего зазорного в том, чтобы искать в методологии руководства, даже на довольно детализированном уровне, но нельзя ожидать, что она будет ответом на все вопросы. Игра «разработка приложений» существенно сложнее монополии, шахмат и футбола. В ответ на это я обычно вижу кивок головы, но я уверен, что люди редко воспринимали мою теорию. Чаще меня спрашивали: «Ну, и какую же методологию мы тогда должны использовать?» Начинающим трудно отбросить комфорт абсолютной уверенности.

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

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

    Опытные: Статистические Значения

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

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

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

    В книге Тома Демарко и Тимоти Листера Peopleware есть история забастовки под названием работай-по-правилам. В ней рабочие букввально следовали формально навязанным правилам (процедурным руководствам), и, разумеется, прогресс сильно застопорился. Знание, когда правилам следовать, а когда нет, очень важно для эффективной работы. Вот, где опыт играет главную роль.

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

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

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

    Эксперты: Эволюционирующие Метафоры

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

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

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

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

    Что ж, статистика вроде этой не особо пригодна к использованию!

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

    Ясно, что они не специально скрывали свои know-how, а скорее изобретали их на лету. Такой ответ внезапно пришёл мне в голову во время разговора с одним довольно высокопоставленным менеджером софтверовой компании. У парня не было никакого опыта программирования, на котором можно было бы базировать свои решения, но он был уверен в своей способности вести проекты. По мере разговора с ним становилось ясно, что его решения, как и решения других экспертов, действительно генерировались на лету. Ключом было его обращение к своему опыту из других проектов. Он занимался умственной гимнастикой, трансформируя все свои знания из одного типа бизнеса (менеджмент консалтинг) в другой (разработка приложений). Другими словами, он брал набор глубоко устоявшихся метафор и на их основе создавал правила и статистику, которыми руководствовался при ведении проекта.

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

    Метафоры позволяют нам работать с незнакомой областью в терминах знакомой.

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

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

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

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

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

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

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

    Конкретный пример: однажды я работал с Эн Верховен – директорм одного известного вебсайта. Раньше Эн работала ресторанным менеджером. Рестораны – это очень стрессовая среда, где обслуживание клиента жизненно важно. Я заметил, что при каждом возникавшем кризисе на проектах Эн сразу же вспоминала свою лучшую метафору: держи хаос на кухне (в нашем случае разработчиков), спрятанным от посетителей (заказчиков).

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

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

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

    Leave a reply

    You must be logged in to post a comment.