Сообщений 3 
Оценка 65 
Оценить 
| Сообщений 3 Оценка 65 Оценить
|
Одна из излюбленных тем, которую поднимает в своих работах Алистэр Коуберн – модель разработки ПО как коллективной игры, направленной на достижение определенного результата (создание программного обеспечения) при неких заданных условиях (ограниченность в человеческих, временных и финансовых ресурсах). Эта модель позволяет по-новому посмотреть на отрасль, работая в которой мы привыкли оперировать исключительно техническими и инженерными метафорами. Проблемы успешности и неуспешности проекта приобретают другую окраску, позволяют нам находить нестандартные выходы из сложных ситуаций.
В первой части статьи вы познакомились с критикой привычной «инженерной» модели создания программного обеспечения и узнали основные ее недостатки:
После этого мы рассмотрели новую модель, которую Алистэр Коуберн предлагает в качестве альтернативы – модель кооперативной игры:
| ПРИМЕЧАНИЕ Первая часть статьи была опубликована в июньском номере журнала «Технологии клиент-сервер» и на сайте http://www.maxkir.com Перевод и цитирование дается по следующим работам: «Software Development as a Cooperative Game», «The Cooperative Game Manifesto for Software Development», «The End of Software Engineering and the Start of Economic-Cooperative Gaming», с ведома и разрешения автора (Alistair Cockburn, Humans and Technology, arc@acm.org.) |
Новая модель, модель кооперативной игры, сразу же дает нам основные составляющие, необходимые для успеха любого проекта по разработке ПО: сотрудничество, общение, цена, качество и достаточность коммуникации. Кроме того, она указывает на дополнительные моменты: талант и умения каждого индивида, отношения между этими индивидами в парах и в группах, ценность и сохранение «сработавшихся» команд, сокращающиеся доходы при использовании в процессе тщательного моделирования и документации, а также важность умения учиться и применять разные стратегии в разных ситуациях.
Теперь обратимся к тому, как можно на практике применять модель кооперативной игры, и как она объясняет успех или неудачу проектов, которые не ложатся в привычную «инженерную» модель, и которые принято считать «аномальными».
Иногда работающая вместе группа людей преодолевает трудности, связанные с индивидуальными склонностями и различиями, и создает то, что Том ДеМарко называет «слаженной командой» (‘jelled team’).
| ПРИМЕЧАНИЕ Tom DeMarco, “Deadline”, 1997; русский перевод книги готовится выйти в издательстве «Питер» в 2005 году. Отдельные главы можно прочитать на сайте переводчиков http://www.maxkir.com. |
В дальнейшем состав такой команды лучше всего вообще не изменять, и вот почему:
Руководитель может захотеть разбить такую «сложенную» команду на части, чтобы каждый ее член мог принести свои знания и умения в другие команды. В этом случае он уподобляет себя садовнику, который «прививает» культуру одной команды на другую, как это делают с деревом или виноградной лозой.
Однако если подыскивать более точную метафору, то было бы уместно сравнить сработавшуюся команду не с лозой или деревом, а со скаковой лошадью, у которой все части организма постепенно пришли в идеальную форму. Так вот, переводя человека из сработавшейся команды в другую, вы отрезаете ногу своей скаковой лошади и пришиваете ее другой лошади в надежде, что эта последняя теперь будет быстрее бегать. Опытный руководитель прекрасно знает, что группа людей должна потратить некоторое время на то, чтобы сработаться и преодолеть сложные моменты, связанные с индивидуальными чертами характеров ее членов. Только после этого они выработают собственные оптимальные способы общения и приобретут опыт совместной работы.
Вводить в сложившуюся команду новых людей – еще одна серьезная проблема, которая стоит перед руководителем. Лучше всего вводить новичков в команду постепенно (я специально называл эту стратегию Ежедневный Уход, чтобы показать протяженность процесса). Таким образом, вновь прибывший сможет познакомиться с командой и ее стилем работы, не отвлекая при этом других. Кроме того, руководитель может использовать другую технику для обучения – парное программирование, замечательный механизм для передачи информации новичку о состоянии дел в проекте путем личного общения.
Разработка программного обеспечения всегда ограничена в ресурсах и перегружена разнообразными ограничениями:
При разработке любого проекта приходится выбирать что-то одно в ущерб другому. Если команда стремится работать как можно быстрее, она неизбежно начнет экономить время на документации и обучении новых сотрудников. Если же сделать упор на документации и обучении, то работа пойдет медленнее. Идеального равновесия, которое так часто ищут сами разработчики и их руководители, просто не существует. В лучшем случае, можно попытаться достичь динамического равновесия, при котором каждый следующий шаг компенсирует предыдущий. Команда должна при этом постоянно играть своими ресурсами так, чтобы полученные результаты были адекватными или удовлетворительными с точки зрения конечной цели.
Хороший игрок знает, что модель или документация далеко не всегда должна быть полной, завершенной, отражать текущее состояние дел, и даже вообще быть правильной. Маркер-напоминание всего лишь напоминает. Единственная его задача – позволить игрокам сделать следующий шаг в игре. Информационный маркер должен дать новичку возможность задать правильный вопрос или указать ему на другой маркер. Если у команды нет дополнительных ресурсов, а разработка ведется в быстром темпе, то лучше довольствоваться тем, чтобы средства общения были «адекватными» или «удовлетворительными».
Концепция «достаточности» в коммуникации позволит нам легко объяснить успех многих проектов, в которых использовался «небрежный» процесс разработки, краткая документация и т.д. (несколько примеров таких проектов мы приведем ниже). Их успех заключался в том, что разработчики останавливали работу над средствами коммуникации тогда, когда эти средства становились достаточно хорошими, чтобы выполнить свою функцию, и не более.
Это второй урок, который участники проекта могут извлечь из модели кооперативной игры. Взвешивая стоимость альтернативных вариантов развития проекта, они понимают, чему надо уделять больше внимания, а что можно прекратить, ввиду текущего состояния дел и их приоритетности. Соответственно, они могут менять последовательность выполнения задач, довольствоваться такими проектировочными документами, которые станут хорошим подспорьем к программному коду, но не будут отражать его текущее состояние. План проекта тоже можно использовать для выработки стратегических решений, а не для того, чтобы всегда отражать там текущее состояние дел. Можно попросить тех, кто занимается сбором требований к системе, ограничиться ровно таким количеством информации, которое понадобится для работающих над проектом проектировщиков (а не для несуществующей идеальной команды проектировщиков). Можно перейти на средства коммуникации, более быстрые, чем письма и документы, например, личное общение или короткие видео ролики. И наконец, принимать решения нужно исходя из того, какие у вас проектировщики (эксперты, сидящие рядом в одной комнате, или же новички, работающие удаленно в разных часовых поясах), и какую систему вы создаете (может ли ошибка в ней привести к гибели людей или же просто к временным неудобствам)
| ПРИМЕЧАНИЕ Более подробно эти вопросы освещаются в книге Алистэра, посвященной методологии Crystal, предварительная версия которой выложена у него на сайте http://alistair.cockburn.us. |
Теоретически, при принятии решений во внимание должны приниматься реалии текущей игры и условия следующих игр. Однако очень часто тот, кто принимает решения, несет ответственность только за данную игру, и ни за что более. Именно поэтому его беспокоит только текущее состояние дел, которое он старается улучшить за счет последующих игр. Такая стратегия может оправдывать себя только короткий период времени; если следовать ей долго, она приводит к саморазрушению всей системы. Модель кооперативной игры предлагает хороший выход из данной ситуации: чтобы защитить интересы и нужды последующих игр, надо сделать так, чтобы у тех, кто принимает решения сейчас, была прямая заинтересованность в исходе следующих игр. Найдется ли такой человек – это другой вопрос, но он относится, скорее, к понятию «хорошая игра» или «плохая игра». Знание концепции кооперативной игры еще не избавляет от проблем и не гарантирует успеха. Оно помогает понять, из чего складывается хорошая игра, а из чего – плохая.
Впрочем, для опытных разработчиков все приведенные выше факты отнюдь не являются откровением. Это странно, и это настораживает. Чем же руководствуется опытный программист, оценивая возможный успех или неуспех конкретного проекта, если это не относится к понятию «инжиниринг»?
В 1991 году я начал работу в рамках проекта по созданию новой методологии в IBM Consulting Group. Мы интервьюировали разработчиков и руководителей, расспрашивали их о том, что они делали, какие приемы срабатывали, а какие нет, чего они ожидали от тех или иных методик разработки, и каковы были приоритеты в работе. Больше всего меня поразило то, что они практически не касались вопросов, которые, как я тогда считал, были самыми главными: в частности, использование средств моделирования и моделирование как таковое. Тем не менее, эти два пункта были последними в списке приоритетов, которые нам называли.
Вместо этого я удивленно записывал фразы, ставившие меня в тупик. Я даже не знал, как интерпретировать, к примеру, слова одного из наиболее успешных руководителей проектов:
"Дайте мне максимум четыре человека, одну большую комнату для работы и доступ к пользователям, и мы будем поставлять систему каждый месяц или два. Это все, что мне нужно. Если бы мне дали много людей, я бы согласился максимум на восемь человек и две комнаты. Но не больше."
Можно предположить, что говорящий такие слова – плохой руководитель. Конечно, ведь он не может справиться больше, чем с восьмью подчиненными. Однако разве это он пытается до нас донести? Нет, он описывает те приемы работы, которые дают реальный результат. По крайней мере, это подтверждено его личным опытом.
А вот еще одна цитата. Чтобы правильно интерпретировать ее мне понадобилось немало времени. Здесь мой собеседник говорит о гордости за проделанную работу:
"Ну, конечно, система работает. Ничего не сломано, все в порядке. Однако этого недостаточно, чтобы я поехал домой с чувством гордости за то, что я сделал за сегодняшний день."
Однако еще более загадочной была другая фраза, которую я слышал довольно часто от разных людей, и которая постоянно ускользала от моего понимания:
"В критический момент несколько человек взялись за работу и сделали все, что было нужно."
Эта фраза не давала мне покоя. Что это – героизм, сигнализирующий об отсутствии грамотного управления проектом? Тогда почему множество команд говорят о нем с гордостью, а не со стыдом? Нужно ли это поощрять или, наоборот, исключать из процесса работы? «Инжиниринговая» модель ничем не могла мне помочь.
Аномалии такого рода были описаны и в более ранних исследованиях. Джеральд Вайнберг (Gerald Weinberg) в конце 60-х рассказывает о том, как из помещения убрали торговые автоматы, и это негативно сказалось на работе. Обратите внимание на лексику, которую использует этот исследователь (и его коллеги) – она очень похожа на ту, что мы используем для описания кооперативных игр:
«В компьютерном центре одного крупного университета [...] была большая общая комната для того, чтобы студенты и другие пользователи могли прорабатывать проблемы и задачи, связанные с программированием. В соседней комнате работала консультационная служба – наиболее сложные проблемы помогали решать два ассистента-выпускника.
В одном из углов этой общей комнаты стояло несколько торговых автоматов..., и шум и гомон тех, кто возле них собирался, иногда становился просто невыносимым для консультантов из соседней комнаты. ... Руководитель компьютерного центра лично исследовал вопрос. Пробыв в помещении не более 15 секунд, он вернулся в свой офис и тут же дал указание убрать автоматы из общей комнаты.
Через неделю после того, как автоматы убрали, а на стенах повесили надписи, призывающие к сохранению тишины, руководитель опять был вынужден разбираться с жалобой. На этот раз студенты пришли жаловаться на недостаточно хорошее обслуживание в консалтинговой службе. Руководитель отправился туда – и что же? Он увидел две огромные очереди, которые даже не помещались в комнате для консультаций! Пришлось спросить консультантов, почему они вдруг стали работать гораздо медленнее. По неизвестной причине, ответили консультанты, посетителей стало гораздо больше, чем раньше.
Две недели руководитель пытался выяснить, в чем причина такого наплыва посетителей. Однако все курсы читались в обычном порядке, и никто из преподавателей не замечал ничего необычного. ... Через некоторое время ответ был найден. Причина крылась в торговых автоматах!
Когда торговые автоматы размещались в общей комнате, вокруг них всегда собиралось большое количество людей. И вовсе не для того, чтобы просто пошуметь и весело провести время, как вскоре открыл для себя этот руководитель. Естественно, студенты покупали кофе и разговаривали – но разговаривали они о своих программах! А поскольку проблемы у многих из них были схожи, то зачастую тут же, у автоматов, находился кто-то, кто уже знал решение. Благодаря такому неформальному консультированию, настоящая консалтинговая служба требовалась студентам гораздо реже, настолько редко, что с ней могло справиться всего два ассистента».
Ди Хок (Dee Hock) описывает, как была разработана первая клиринговая система для кредитных карт VISA. Ее создала команда, у которой, как казалось вначале, не было нужной квалификации для такой работы, и которая использовала вызывающе неформальный процесс разработки:
«Мы решили, что сами будем своим главным подрядчиком, который раздает отдельные задания отдельным разработчикам, а потом координирует и реализует результаты. Согласно общепринятому мнению, при создании компьютеризированных коммуникационных систем этот способ является одним из наихудших.
Мы сняли дешевое помещение в пригороде и предпочли потратить деньги на улучшение условий работы, в частности, купили медицинские шторы на вращающихся рамах и с их помощью поделили большое помещение на удобные рабочие места.
Вскоре заработал процесс самоорганизации. Одна из стен была превращена в некое подобие календаря – сверху выстроились все дни, отведенные на разработку системы. Кто-то взял грязную чашку из-под кофе и подвесил ее на длинную веревочку, которую приколол к текущему дню. Каждая задача записывалась на отдельный листок, где указывались конечный срок выполнения задачи и имя человека, который за нее взялся. Любой мог изменять что угодно относительно задачи – ее срок или описание. Единственным условием было обязательно сообщить об этом тем, кого это могло затронуть. В любой момент времени можно было быстро получить полную картину происходящего, увидеть, как растет и развивается система. Люди видели, что весь проект зависит от их работы, и что их работа связана практически со всеми другими задачами. Около стены постоянно собирались группы разработчиков – они обсуждали насущные нужды и проблемы и, как только проблемы были решены, опять расходились по рабочим местам. Когда задача была выполнена, соответствующий листок убирали с доски. С каждым днем чашка на веревочке неумолимо приближалась к краю доски.
Если какой-то листок оставался за веревочкой, всегда находилась группа добровольцев, готовых помочь доделать эту задачу. Успеть сделать свою работу вовремя и помочь другому стало почетной привилегией. При этом никто не чувствовал себя униженным от того, что ему помогают. Все прекрасно понимали, что в такой геркулесовой задаче, как данный проект, каждый может оказаться «по ту сторону веревочки» и принять помощь коллег.
То и дело возникали стихийные лидеры, не по чьему-то приказу, а совершенно естественным образом. Это было время изобретательности и находчивости. Процветали индивидуальность и разнообразие. Люди сами удивлялись своим успехам и радовались, видя, сколько нераскрытых ранее талантов проявляется сейчас в их коллегах.
Служебное положение ничего не значило. Власть над другими, чины – все это стало бессмысленным. Время тоже потеряло всякий смысл. Все были увлечены мыслью о том, что своими руками создают что-то невероятное. Постепенно сложилась настоящее сообщество – единство целей, принципов и людей. В команде культивировались индивидуальность, изобретательность и творчество, а вместе с ними у людей появилось чувство общности, чего-то большего, нежели просто интересная работа, выгода и денежное вознаграждение.
Никто никогда не забудет чувство единения ума, тела и души в процессе работы, как не забудет он и главное открытие – такое единение возможно только в неразрывной связи с другими людьми, работающими в едином порыве над общей целью. Деньги – лишь немногое из того, что принес проект разработчикам. ...
Никто так никогда и не снял грязную веревочку, и чашку тоже так и не помыли. Система под названием BASE-1 появилась в оговоренный срок, стоимость разработки осталась в рамках бюджета, а функциональность системы превысила все ожидания».
С традиционной точки зрения такой процесс должен был бы привести к полному провалу проекта. Однако если рассматривать вышеописанное как кооперативную игру, то становится понятно: ставка на общение, сотрудничество, доверие, общность интересов и гордость за свою работу не может не привести к успеху.
Конференция NATO, состоявшаяся в 1968 году, настолько изобилует аномальными (с точки зрения «инжиниринговой» модели) высказываниями, что я просто не могу привести здесь их все, статья – неподходящий для этого жанр. Ограничусь лишь несколькими:
Фрэзер (Fraser): «Проектирование и реализация проходили как последовательность отдельных фаз... . Результатом каждой фазы был продукт, который можно было использовать, а время между окончанием одной фазы и началом другой уходило на правку и переосмысление существующего дизайна системы, который мог меняться в процессе работы над системой. Так, по окончании первой фазы мы получили не только готовую к использованию систему, но и информацию, что изменения в дизайне системы могут позволить нам сделать нашу программу лучше и дешевле. Вся вторая фаза ушла на реконструирование всей системы, которое, как показал наш дальнейший опыт, было полностью оправдано... Последнее значительное изменение в дизайне системы было сделано тогда, когда мы заметили, что один из участков системы медленно, но верно становится все более сложным и запутанным». (Стр. 11-12)
Смит (Smith): Меня до сих пор поражает то, как мы пытаемся создавать программные приложения... Все доккументы, связанные с программой, классифицируются как технические чертежи. Все начинается со спецификаций планирования, далее идут спецификации функциональности, реализации и т.д и т.п. Если вы посмотрите на PERT диаграмму, то увидите, что под всю эту деятельность отведено очень много точек. Однако при этом в каждой из этих точек результатом будет только появление новых документов и ничего кроме этого. Вот так и в моей компании, к сожалению, люди до сих пор путают меню программы и меню в ресторане. (стр. 52)
Кинслоу (Kinslow): Процесс проектирования системы итеративен. Однако и в нем может что-то не сработать, если вы, конечно, не находитесь в лаборатории. По-моему мнению, проектирование системы состоит из следующих стадий:
Росс (Ross): Самое ужасное в создании программного обеспечения – это концепция, которой, к сожалению, все всегда следуют: сначала нужно определить, что вы собираетесь делать, а потом неукоснительно этому следовать. Отсюда и все наши беды. (стр .21)
Перлис (Perlis): Человек, работающий в проекте по производству программного обеспечения может без особого труда общаться с пятью коллегами. Точно так же он может и управлять таким же числом подчиненных и всегда иметь представление о том, кто чем занимается. Таким образом, можно было бы распределить 120 человек по трем иерархическим уровням так, чтобы каждый должен был общаться не более чем с восьмью коллегами – уровнем ниже и уровнем выше... (стр. 51).
Оплер (Opler): Кажется, я знаю, как организовать приемлемый уровень общения для проектов, в которых задействовано от 10 до 50 человек... каждый член команды получает папку с пятью-шестью страничками, где изложены первые идеи и решения относительно проекта (включая страницу с общим указателем). По ходу проекта каждый из его участников привносит в описание свои листы, которые должны быть одобрены руководством. ... У этого метода есть интересный побочный эффект. Как-то я заметил, что одна часть получающейся книги заполняется медленнее других – и своевременно обнаружил нерадивого работника, которого нам пришлось уволить. (стр. 55)
Фрэзер (Fraser): Вопрос о том, как организовывать течение информационного потока внутри команды, зависит, в основном, от размера этой команды.
Я участвовал в проекте, где было занято 30 человек ... И у нас было три, нет, скорее, даже четыре формы информационных потоков. Первая основывалась на том, что компилятор был написан на языке высокого уровня и, таким образом, частично предоставлял свою собственную документацию. Вторая форма заключалась в том, что документация содержалась в устройстве с произвольным доступом, куда регулярно обращались все члены команды. Собственно, это был металлический шкафчик для бумаг в моем офисе. ... Наверное, это была основная форма коммуникации из всех, которые у нас были. Главным ее достоинством было то, что существовал только один официальный набор информации по проекту. Кроме того, этот набор был снабжен системой указателей (индексом), которая, несмотря на свою грубость и приблизительность, оказалось достаточной для того, чтобы каждый мог найти, в случае необходимости, нужную ему информацию. ...
Была и четвертая форма коммуникации, которая есть в каждом проекте, и которую, мы, наверное, использовали не так широко, как следовало бы. В любой организации есть люди, которые весьма успешно разносят слухи. Так вот, многие проблемы разработки могут быть обнародованы и даже решены, если вы начнете поощрять (в разумной степени) распространение слухов. (стр. 55)
С такими же примерами мы сталкиваемся и в 1999 году. Вот выдержка из описания работы команды, которая работала на верхнем уровне Модели Развития Функциональных Возможностей Института программной инженерии (Software Engineering Institute's Capability Maturity Model.) Обратите внимание на важность, которую придают здесь вопросам доверия, коммуникации, гордости за проделанную работу и личные взаимоотношения между индивидуумами:
...Чтобы работать с максимальной отдачей, инженеры должны быть мотивированы и энергичны; им необходимо проявлять изобретательность, заботиться об уровне качества продукции; более того, они должны любить свою работу, испытывать удовольствие от того, что они делают и лично быть заинтересованными в успехе проекта. Так бывает только тогда, когда менеджмент доверяет инженерам процесс эффективной работы, а инженеры доверяют менеджменту процесс управления и поддержки. ... Кроме того, в обязанности менеджмента входит слежение за тем, чтобы инженеры следовали принятым методам работы, а в командах не возникало бы межличностных проблем.
Итак, модель кооперативной игры подсказывает нам несколько областей для дальнейших исследований.
Во-первых, это человеческие способности к созданию программного обеспечения:
Во-вторых, исследования могут касаться области механизма принятия решений, ограниченного рациональностью с одной, и несовершенными формами общения – с другой.
И, наконец, третья тема исследований лежит в области финансирования проектов. Возможно, здесь понадобится использовать знания о финансировании венчурных капиталов и стратегий торговли опциями.
И тут я не могу не предостеречь будущих исследователей. Помните старую сказку о человеке, который ночью потерял свой кошелек и искал его под фонарем? Прохожий остановился и спросил его, где тот обронил кошелек. «Да где-то там», – говорит человек, указывая куда-то в темноту. «Но почему же ты ищешь его здесь, а не там, где потерял?!!» «Потому что здесь светлее», – ответил он. Так вот, когда я предлагаю те или иные темы для исследований в нашей области, я часто слышу ответ: «Мы не изучаем вопросы поведения людей, потому что мы – специалисты в компьютерной области. Не то, чтобы эти темы совсем нас не интересовали, но все же это не для нас». Им просто нравится искать под фонарями, а вот углубляться в темноту совсем не хочется.
Однако, если мы с вами работаем в области производства программного обеспечения, то именно на нас лежит обязанность узнать, как нам лучше делать свою работу. Если для этого нужно исследовать что-то связанное с психологией человека, значит, нужно это сделать. Нам ведь не нужно поднимать все темы, связанные с этой необъятной наукой. Достаточно остановиться лишь на вопросах изобретения и общения, которые связаны с кооперативными играми. Сюда, разумеется, входят мотивация, награда, страх, доверие, дружелюбие, гордость, эго, общность, модальности в коммуникации, а также создание новых идей в одиночку и группами.
Быть может, мы опять, как это уже случалось раньше, углубимся в новую область и узнаем то, чего не знают до сих пор другие специалисты. А может, мы перенесем в свою область знания из других наук (испытанный подход, уже приносивший хорошие плоды). Как бы то ни было, пора обратиться к человеку – активному компоненту процесса создания программного обеспечения. Безусловно, это тоже часть нашей работы.
Алистэр Коуберн о цикличности исследований и о себе:
«Как и полагается настоящему методологу, основа моей работы – сбор сырого материала: человек говорит «Мы делали то-то и то-то. И получилось вот так». Я фиксирую этот факт, потом собираю подобные факты. Потом я обращаюсь к когнетике, нейролингвистическому программированию, социологии, этнографии, теории организации и личностных типов и ищу в них ответ на свои вопросы – что есть причина и что есть следствие, что же такое эта самая «экология», которая окружает программирование. Теперь это уже не просто наблюдения, это мои собственные идеи, которые я начинаю проверять на собранных фактах. Те, что мне нравятся и, кажется, кое-что объясняют, я оставляю. Потом строю догадки относительно теории, которую можно наложить на собранные факты.
После этого я стараюсь разрушить эту теорию, найти ее слабое место. Ну, хорошо. Если честно, то мне не очень хочется разрушать свою теорию. Я действительно очень хочу, чтобы она оказалась верной. Поэтому, наверное, я вообще не очень-то пытаюсь ее поломать. Я не показываю свои наработки самым ярым своим оппонентам, потому что они разрушат все слишком быстро. Вместо этого я преподношу свою теорию программистам – иногда прямо по ходу проекта – и смотрю, как они реагируют на мои находки. Однако как бы я не желал, чтобы мои теории оказались правильными, опыт показывает, что я продвигаюсь вперед в своих изысканиях только тогда, когда они разрушат мои первоначальные построения.
Как я сумел заметить за последние десять лет, существует некий цикл. Начинаю я довольно неподготовленным – с какой-то догадки. Потом я изучаю все, что касается этой темы, и наконец, начинаю думать, что уже что-то знаю. Таким образом я оказываюсь на верхушке колеса. Я заявляю о своей новой теории, пытаюсь ее использовать и тут же обнаруживаю, что она не работает. Я понимаю все меньше и меньше, пока я не убеждаюсь, что на самом деле не знаю ничего, и не впадаю в депрессию. И тут-то я замечаю какой-то важный факт, который до этого ускользал от меня, или меня посещает новая идея, и я вновь начинаю собирать информацию.
Колесо взлетает вверх, потом опускается вниз. За последние десять лет я проделал весь круг уже раз шесть и хорошо знаю это чувство».
| Сообщений 3 Оценка 65 Оценить
|
