загрузка...

Культура программирования в Мicrоsоft


Трудно переоценить роль и значение культуры разработки программного обеспечения. Изучая эту, наиболее типичную компанию, занимающуюся разработкой ПО, Фред Муди (Fred Moody) в своей книге «I Sing the Body Electronic» 22 (Электронное тело пою) показывает, насколько глубоко укоренилась в индустрии программирования культура нердов. Этот писатель и журналист, пишущий на околокомпьютерные темы, провел год в стенах Microsoft, наблюдая за созданием нового мультимедийного продукта, названного в итоге «Explorapedia». Муди получил свободный доступ в Microsoft, и его книга рисует откровенную картину жизни и культуры ведущей компании индустрии. Если вы не поняли этого по продуктам Microsoft, то эта фирма глубоко чтит программирование, но не осознает или почти не осознает потребность в проектировании взаимодействия. Эта книга содержит захватывающее исследование процессов, происходящих в культуре программирования.
Во вступлении Муди готовит почву:
В Мiсrоsоft корпоративная структура формируется из небольших команд, работающих над конкретными продуктами. Команды самостоятельно определяют свою внутреннюю иерархию и сами организуют работу. Это рискованный подход, ведь степень неконтролируемости таких коллективов немыслима в обычных американских корпорациях.
Мiсrоsоft известна тем, что нанимает очень одаренных и очень напористых молодых людей чуть ли не со школьной скамьи. Муди пишет:
«Было такое ощущение, что банда подростков проскользнула в штаб-квартиру какой-то корпорации после окончания рабочего дня и забралась в зал заседаний совета директоров, чтобы поиграть в бизнес».
Мiсrоsоft известна и тем, что нещадно эксплуатирует эти молодые таланты, чтобы получить от них как можно больше. Муди пишет:
«В кампусе всегда очень беспокойно, и там постоянно импровизируют».
Эта книга – замечательный рассказ о том, насколько часто методы разработки в Мiсrоsоft произвольны, непрофессиональны и какое морально разлагающее действие они оказывают. Муди и сам был озадачен увиденным, но не сомневался, что увидел нечто важное. А увидел он, что всем здесь заправляют программисты. И даже если не делают этого явно, то делают это опосредованно, силой своей воли. Муди ни в единой букве не подвергает сомнению собственное и общественное мнение, что программистам и следует быть у руля, однако отмечает трение, разногласия, неприятные эмоции и ощущение провала, характерные для такой ситуации. Вот что он пишет:
Не могу сказать, что хорошо понимаю, что происходит в Мicrosoft. Грустная действительность такова, что покинул я кампус в большем замешательстве, чем когда прибыл туда. Оглядываясь на уже написанные страницы, я прихожу в еще большее недоумение и все еще не в состоянии определить, что за история рассказывается на них – история успеха, или же история поражения, или история успеха, замаскированная под историю поражения, а быть может, история поражения, замаскированная под историю успеха.
Разумеется, Фред стал свидетелем создания танцующего медведя – продукта, безотрадно сложного в применении, единственным достоинством которого стали возможности, не существующие где-либо еще.
Проект Explorapedia – классический пример деградации типичного процесса разработки. Ни минуты не сомневаюсь, что продукт стал провалом. Муди же смутило то, что продукт был сдан вовремя и принес прибыль. На последних страницах книги, озаглавленных автором «Postmortem», он пишет:
До первого контакта с Мiсrоsоft мне и в голову не приходило, что я могу стать летописцем провального проекта. И все же, практически с самого начала и до конца моего пребывания в компании, я считал, что являюсь свидетелем предметного урока в том, как не следует создавать продукт. Все, кто имел отношение к проекту Explorapedia, были настолько несчастны и злы, непрестанно говорили о раздражении и разочаровании, что какой еще вывод я мог сделать, как не тот, что волею судьбы становлюсь свидетелем катастрофы? Однако проект был несомненной победой.
Удивительно? В следующем предложении какие-то два слова отделяют Муди от термина «танцующий медведь», он пишет:
«Каждая из возможностей Explorapedia в отдельности – лишь бледная пародия на изначальный замысел… и, тем не менее, эта энциклопедия стала на рынке единственным продуктом в своем роде».
Легко победить, не имея конкурентов, обладая поддержкой приводящего в трепет брэнда Microsoft, ее связей чудовищных размеров банковского счета.
Слабость продукта – фактор, превосходящий по губительности все прочие. Ближе к концу книги автор цитирует участницу проектирования Сару Фокс (Sara Fox), которая смотрит на …книгу издательства Dorling Кindersley, положенную в основу Explorapedia. Она шокирована тем, что книга предоставляет читателям больше свободы в изучении, чем компьютер. Ведь компьютер, предполагалось, станет великой силой, освобождающей от ограничений печатной книги. В книге, указала она, текст свободно окаймлял изображения, и читатели имели возможность листать страницы в свое удовольствие, окидывая взглядом огромные объемы информации. Ехplorapedia же принуждает их рыться в пронумерованных всплывающих окошках, каждое из которых содержит лишь несколько предложений. Это был отвратительный парадокс: компьютер имел ограничений больше, чем книга. «Dorling Кindersley сделало противоположное тому, что делали мы, а мы превратились в посредников».
В Microsoft самые важные проекты задумываются, управляются, реализуются программистами. Проект мультимедийного компакт-диска, описанный в книге Муди, был в некотором роде исключением, потому проектировщики вовлекались в него на каждом шаге. Однако они никоим образом не проявили умения, которые я считаю обязательными для роли проектировщика взаимодействия. Казалось, они совершенно не имеют представления о важных для проектировщика взаимодействия вещах: не понимают до конца, что в действительности делают программисты, не понимают принципы и методы процесса проектирования взаимодействия, не знают состава пользователей продукта и не понимают этих пользователей. Муди ясно показывает, что единственные таланты проектировщиков Microsoft заключались в сообразительности, безграничной энергии и чувстве прекрасного.
Таким образом, Муди и мог увидеть только дисфункциональную модель.
«Задание проектировщиков состояло в том, чтобы напридумывать как можно больше возможностей, разработчики сопротивлялись во имя сроков сдачи, а работа менеджера продукта заключалась в медитациях и выдаче вердиктов».
Любые антагонистические отношения, подобные описанным, обязательно приводят к тяжелым последствиям. Страдают люди, продукт или же компания.
Сотрудники Microsoft, работавшие над проектом, остались столь же непросвещенными, как Муди. Кевин Геммил (Kevin Gammill), ведущий программист:
Кэролин постоянно называет это Адским проектом, а Крэйг не перестает повторять, что никогда еще ему не приходилось проходить через подобное. Но Крэйг также не перестает повторять, что мы совершили эту ошибку и еще вот эту ошибку, а еще вон ту ошибку с энциклопедией Encarta, и вот сейчас снова ее совершаем. А Сара твердит, что «жизненный цикл продукта такой… цикличный». Здесь каждый проект такой! Мы повторяем, что учимся на своих ошибках… однако снова и снова проходим через ту же [непечатное слово].
Эти неформальные портреты от Геммила захватывают не меньше, чем железнодорожная катастрофа. Читатель, не знакомый с индустрией программного обеспечения, может испытать соблазн списать изложенное на гиперболы или обвинить Муди в выборе нетипичного человека из этой культуры. Однако Геммил – архетип, поэтому его поведение весьма типично. Я встречал сотни мужчин и несколько женщин в точности таких, как он.
Членам той команды было нелегко говорить с Геммилом даже в относительно нормальной ситуации. Между разработчиками и дизайнерами в Мiсrоsоft пролегала гигантская культурная пропасть. Разработчик часто не мог заставить дизайнера понять простейшие элементы проблемы программирования. Так же часто дизайнеры неделями трудились над каким-то аспектом продукта лишь для того, чтобы, показав результат разработчику, получить грубый ответ, что реализация задуманного невозможна.
В последние годы ситуация несколько улучшилась, но эти два лагеря буквально говорили на разных языках, рассматривая мир компьютеров с противоположных интеллектуальных, культурных, психологических и эстетических полюсов. Дизайнеры приходили в Мiсrоsоft из гуманитарных дисциплин; разработчики – из мира математики и науки. Разработчики смотрели на дизайнеров сверху вниз, поскольку считали их мышление нечетким и неструктурированным, а вкусы непостоянными. Дизайнерам казалось, что разработчики лишены воображения, консервативны, склонны отвергать предложения по дизайну сразу же, не пытаясь найти способ претворить их в жизнь. Поскольку программирование оставалось для разработчиков необъяснимым таинством, они не имели возможности оценить весомость доводов разработчиков о том, что нарисованное невозможно реализовать.
«Дизайнеры, – любил говаривать Том Корддри, – это непременно женщины, они болтливые, живут в мансардах, сидят на вегетарианских диетах и носят в ушах найденные предметы. Разработчики – обязательно мужчины, питаются приготовленным на скорую руку и произносят только одно слово: «Неверно».
Он мог бы еще добавить, что дизайнеры и разработчики разрешают конфликты различным образом. Когда разработчики, склонные к вспышкам озорных игр, начинают осыпать дверь кабинета дизайнера шариками из детского помпового ружья, жертва жалуется вышестоящему начальству. Разработчик же сам открывает ответную стрельбу.
Я хочу подчеркнуть, что Мiсrоsоft и Муди говорят «дизайнер» там, где я употребляю слово «графический дизайнер». Графический дизайнер обладает развитым чувством прекрасного, мыслит зрительными образами, умеет делать наброски или рисовать. Такой человек участвует в каждом, без исключения, нашем предприятии по проектированию. Однако дизайнеры вносят свою магию в наши работы лишь после того, как подготовленные проектировщики взаимодействия завершат основную работу по концептуальному и поведенческому проектированию.
Кстати сказать, сварливое «неверно», цитируемое Корддри, – хорошая иллюстрация к фразе По Бронсона: «Не я ответил неправильно, вы задали не тот вопрос».
Муди очень хорошо осознавал уникальные культурные отличия программистов и посвятил множество красочных пассажей описаниям их резкого, высокомерного, претенциозного отношения, однако он не смог оценить этих людей. В своем описании контакта программиста Геммила, питающегося гамбургерами, и женщины-«вегетарианки», дизайнера Кэролин Бьерк, Муди дает в корне неверное истолкование:
Ответы Геммила на вопросы Бьерк больше походили на игривое поддразнивание, однако его манера поведения и поза, несомненно, говорили о враждебном настрое. Он сидел, выпрямив спину, словно проглотил аршин, непрерывно постукивал по полу ногой и барабанил пальцами по столу. Создавалось впечатление, что он предпочел бы находиться в любом другом месте, но только не здесь. Его реакцию на вопросы Бьерк можно было измерять по частоте касаний ногой пола и барабанной дроби пальцев. Частота эта повышалась с ростом сложности реализации возможности, о которой шла речь.
Муди относит раздражение Геммила на счет «сложности» предприятия. Сильнее ошибиться невозможно. Программисты обожают сложности. Чем сложнее проблема, тем больше удовольствия в ее решении. Сложность часто становится основным мотивирующим фактором для хороших программистов. Раздражение Геммила происходит из перспективы писать скучный код, и еще – из-за утраты полного контроля в пользу человека, которого он не уважает, то есть в пользу Бьерк, которая не имеет отношения к техническим вопросам и чьи решения кажутся Геммилу взятыми с потолка. Разумеется, Геммил никогда не скажет об этом открыто, он и сам, вероятно, этого не осознает – но будет использовать сложности, как отвлекающий маневр, чтобы снять с себя ответственность.
Человек, собирающийся возглавить команду разработчиков, должен пользоваться их уважением. Работа программистов устрашающе сложна и предъявляет высокие требования, и программисты ревностно защищают свою территорию. Любой, кто попытается возглавить программистов, потерпит поражение, если только не знает и не уважает работу программистов во всех аспектах. В Microsoft, да и в большинстве других компаний, есть программисты, а есть «мелкие» люди, и эти мелкие люди не смеют даже надеяться повлиять на цикл разработки продукта.
При этом Мicrosoft имеет несомненный успех, что порождает печальный побочный эффект. Многие компании копируют культуру Microsoft, стремясь повторить ее успех. Копирование атрибутов успеха вместо его причины – ошибка распространенная. Это все равно что увидеть револьверы генерала Джорджа Паттона, украшенные перламутровыми рукоятями, и прийти к ошибочному выводу, что можно стать хорошим стратегом, только если носишь изысканное личное оружие.
Непреднамеренно Муди отмечает еще один интересный аспект нашей культуры разработки программного обеспечения.
Многие руководители, обладающие богатым опытом в создании и продвижении на рынках программных продуктов, никогда не применяли проектирование взаимодействия. При этом одни продукты оказывались успешными, другие терпели неудачу, тогда как процесс создания оставался неизменным. Отсюда они сделали вывод, что успех или поражение программного продукта зависит от фортуны; успешная программа – это все равно, что выигрыш на скачках. В истории Муди все говорило о провале, а продукт стал успехом. В случае General Magic, речь, о которой шла в главе 6, все указывало на успех, а продукт провалился. Поиск в ошибочных местах не позволил им обнаружить закономерность, и они просто предположили, что результаты случайны. Ситуация напоминает историю о врачах девятнадцатого века, которые не знали, что является причиной малярии, пока не выяснилось, что переносит заразу анофелес, малярийный комар. Тогда считалось, что заболевание разносится вечерним воздухом и выбирает жертв случайным образом, а единственная защита от этой смертоносной лихорадки – удача. После обнаружения правильной причинно-следственной связи заболевание быстро победили.
Культурная изоляция
В большинстве компаний-разработчиков наиболее опытные программисты берут на себя ответственность за самые сложные части программы. Взамен они получают некий барьер против раздражающих звонков по вопросам технической поддержки: когда звонят реальные конечные пользователи программы, их соединяют с сотрудниками службы технической поддержки или менее заслуженными программистами. В тех редких случаях, когда пользователю удается добраться до ведущего программиста, это происходит потому, что пользователь продемонстрировал свои познания младшему программисту или сотруднику службы поддержки. Следствие такой фильтрации: чем более высоким рангом обладает программист, тем меньше он контактирует с типичными, заурядными пользователями. Он начинает ошибочно предполагать, что «его» пользователи являются типичными.
Пример: Sagent Technology, поставщик систем управления данными для рынка корпоративных вычислений. В этой компании главным специалистом в области баз данных является Влад Горелик (Vlad Gorelik), о компетентности которого в программировании ходят легенды. Непосредственно он общается лишь с теми клиентами, которые способны трепаться о «сегментации запросов», «распределении задач» и «кубах данных» с той же степенью увлеченности. И не удивительно, что Влад считает типичного пользователя Sagent Information Studio бывалым специалистом по базам данных.
Напротив, Алиса Блэр (Alice Blair), менеджер компании по Information Studio, проводит львиную долю времени в разговорах с потенциальными покупателями продукта. Она объясняет этим людям, что может продукт, каковы его базовые функции. Как следствие, Алиса считает, что в пользовательской аудитории много тех, кто не знаком с продуктом, и тех, кто обладает лишь базовыми навыками работы с компьютером. Неудивительно, что, по ее мнению, большинству клиентов требуется поддержка.
Кендал Косби (Kendall Cosby) работает в службе технической поддержке Sagent. Он не общается с экспертами и новичками. В основном ему приходится работать с конечными пользователями среднего уровня. Поскольку продукт применяется для поддержки принятия решений, Кендал находится в постоянном контакте с финансовыми и рыночными аналитиками, которые мало что знают о компьютерах и базах данных, но в своей работе зависят от возможности обращаться к хранилищам данных и анализировать тенденции в продажах. Собеседники Кендала не очень хорошо разбираются в компьютерах, и ему хотелось бы, чтобы продукт скрывал сложную функциональность или не содержал таковой вовсе. Из всех троих наиболее точным видением клиента обладает Кендал, однако именно Влад и Алиса имеют больше возможностей влиять на архитектуру продукта, поскольку занимают соответствующие должности.
В старинной притче несколько слепых впервые в жизни встречают слона. Первый трогает слона за ногу и объявляет, что это «очень похоже на дерево. Второй трогает слона за бок и объявляет, что это «очень похоже на стену». Третий трогает слона за хобот и объявляет, что это «очень похоже на змею». Подобно этим слепым, Алиса, Кендал и Влад имеют весьма различающиеся мнения о том, на что похожи клиенты, поскольку общаются с непересекающимися подмножествами пользователей. Более того, каждый обладает четкими эмпирическими свидетельствами в подтверждение своих выводов. И чтобы получить точный портрет, необходим человек, отвлеченный от ежедневных вопросов, как разработки, так и продаж.
Шкурный интерес
Весьма значимым фактором в культуре разработки программного обеспечения является уединенность. Программисты сидят поодиночке. Конкретный код набирается только одним программистом. Код в компьютере по преимуществу невидим, и его практически никогда не читают. Чтение чужого кода походит не на чтение книги, а скорее на чтение чужих конспектов, записанных непостижимой тайнописью. Программирование настолько сложно, что требует целеустремленного сосредоточения и многих часов непрерывной работы. Программисты чутко относятся к этой замкнутости и всему, что с ней связано. Никто не способен проконтролировать, что делает в своем коде программист. Программисты знают, что качество их кода – вопрос, главным образом, их же собственной добросовестности. Начальство может требовать качества, но не будет тратить время и силы на то, чтобы удостовериться в существовании этого качества. Расшифровка кода может отнять больше времени, чем было изначально затрачено на его написание. Программистам известно, что их личные решения и действия оказывают большее влияние на конечный продукт и удовлетворенность пользователя, чем какие-либо другие соображения. В конечном итоге они лично будут ответственны за успех продукта. Они знают, что глубоко заинтересованы в успехе игры.
Одиночество программиста обостряет его ощущение собственной власти. Некоторые испытывают дискомфорт, но еще больший дискомфорт доставляет им передача полномочий тем, кто не столь заинтересован в исходе. К советам маркетологов, руководителей, проектировщиков программисты относятся со здоровой долей скептицизма. Они знают, что приняв совет, который окажется ошибочным, примут всю вину за произошедшее, потому что к моменту наказания советчика уже и в помине не будет.
Когда программистам разрешается самостоятельно выполнять проектирование взаимодействия, это приводит к некачественному проектированию, а кроме того имеет еще и дополнительный эффект: программисты теряют уважение к процессу проектирования.
Программисты уже так много раз успешно продирались через процесс проектирования, что привыкли игнорировать его ценность. Когда компания, наконец, нанимает проектировщика взаимодействия, программист само собой, относится к его работе снисходительно.
Это приводит к общему недостатку уважения к проектировщику, к процессу проектирования, и, что прискорбно, к собственно проектированию. Такое неуважительное отношение укрепляет внутрикультурную оценку проектирования, как мнения или туманного совета, тогда как на деле это четкое, конкретное и недвусмысленное указание. Поскольку программист, имея на это все основания, считает, что его прихоть имеет вес не меньший, чем чье-то простое мнение, он полагает себя вправе выбирать приглянувшиеся элементы архитектуры из спецификации. Он считает письменную спецификацию не чертежом, но страницей газеты, на которой публикуются письма в редакцию. Некоторые абзацы занимательны, но неверны, другие полезны, но не имеют отношения к делу. К несчастью, программист принимает эти решения, исходя из соображений реализации или собственных предпочтений, а потому решения часто ошибочны.
С другой стороны, каждый программист имеет в запасе ужасные истории о том, как хорошие продукты превращаются в неудачные из-за дурацких указаний, исходящих от руководителей, точно так же не понимающих, чего может хотеть пользователь. Мне вспоминается один высокопоставленный руководящий работник, который ненавидел клавиатуру, а потом требовал, чтобы все программы компании управлялись только мышью. А другой высокопоставленный руководящий работник, неуклюжий в обращении с мышью, заявил, что все программы компании должны управляться только с клавиатуры. Это пагубное проектирование, основанное на личных предпочтениях, вызвало в обеих компаниях взрыв отчаяния.
* * *
Конечно, существуют программисты, сознательно выбирающие злобное и разрушительное поведение, однако, если судить по тем многим программистам, что встречались мне, они столь же редки, как зубы у курицы. Программисты – как пилоты истребителей: после длительного обучения и трудного достижения пика своих способностей они неизбежно начинают считать непрограммистов менее компетентными. Разработчики программного обеспечения уважают других в привычных областях деятельности, но если непрограммист ступает в мир программирования, как описывал Муди, программисты ведут себя покровительственно или даже высокомерно.
Программист имеет все основания презрительно посмеиваться над дилетантами, сующими нос в мир разработки программ. Точно так же, если программист постучится в дверь финансового инспектора и начнет проверять выкладки по возвратам, инспектор сможет с полным правом посмеяться над самонадеянностью и заносчивостью сунувшегося не в свое дело программиста.
Сложность как раз в том, что проектирование взаимодействия и реализация взаимодействия тесно переплетаются в типичном процессе разработки. Руководитель может попросить изменить поведение программы, но не попросит программиста сменить методы разработки. Но именно потому, что поведение и реализация столь тесно связаны, невозможно посягнуть на одно, не создав впечатления покушения и на второе. Это одна из трудностей, наблюдавшихся Муди в Мiсrоsоft.
Люди, вовлеченные в создание продуктов, основанных на программном обеспечении, хотят, чтобы уж их-то продукты были просты в применении. Как следствие, они постоянно вторгаются на территорию программистов, у разработчиков же никогда нет лишнего времени, и такие вторжения могут делать их вспыльчивыми. Многие уединяются и лишь по крайней необходимости общаются с теми участниками команды, которые не занимаются программированием. Тамра Хитершоу-Харт (Таmrа Heathershaw-Hart) поведала мне о своих приключениях в роли технического писателя, которому требуется получать информацию от программистов.
Я обнаружила, что подкуп гораздо эффективнее уговоров. В основном использовала шоколад. Подкуп действовал настолько хорошо, что однажды руководитель группы, пав на колени, публично извинялся передо мной, что забыл уведомить об изменениях в продукте. (Да, свое угощение он все равно получил.) В одной компании пристрастившийся к шоколаду инженер рассказывал мне обо всех изменениях, внесенных его коллегами, чтобы получить и их шоколад. До открытия такого способа подкупа я потратила массу времени сверхурочно, пытаясь выяснить, каким образом изменился продукт. Подкуп же позволил сократить сверхурочную работу раза в два.
Эта история занимательна потому, что, обладая хоть каким-то опытом в деле разработки программного обеспечения, мы немедленно признаем, что она правдива. Услышь вы историю про инспектора, вынужденного подкупать шоколадкой клерка, работающего с дебиторскими счетами, чтобы получить информацию по сегодняшним депозитам, вы бы пришли в изумление, негодование и отнеслись бы к рассказу с недоверием.
* * *
Многие руководящие работники привыкли, что подчиненные немедленно реагируют на любое указание или даже мягкий намек, исходящий от начальства. Они воображают, что программисты (технический персонал) не слишком высоко находятся на тотемном столбе власти, и поэтому послушно будут следовать указаниям вышестоящих. С точки же зрения программиста руководящий работник в этой игре ничем не рискует, поэтому повиноваться не хочет. Независимо мыслящий разработчик программного обеспечения не изменит свой код просто потому, что кто-то этого потребовал, независимо от важности персоны попросившего.
Если вы хотите изменить существующий код, необходимо, прежде всего, изменить сознание программиста. Он заинтересован как в сохранении существующего кода, так и в том, чтобы избежать кажущихся ненужными усилий, направленных на изменение кода. Нельзя просто потребовать, а тем более попросить, но следует представить рациональную, обоснованную причину для изменений. Причем представить в терминах, понятных инженеру, и из уст человека, кровно заинтересованного в исходе.
В высшей степени точный и разоблачающий анализ образа мыслей и поведения программистов приводит в своей книге Пол Глен (Paul Glen) 23 . Искренне советую прочитать ее всем, кто хочет глубже изучить программистов и их культуру.
<< | >>
Источник: Алан Купер. Психбольница в руках пациентов. 2007

Еще по теме Культура программирования в Мicrоsоft:

  1. Культура программирования
  2. Раздел IIМАКРОЭКОНОМИЧЕСКОЕ ПРОГРАММИРОВАНИЕ
  3. ПРОГРАММИРОВАНИЕ БЮДЖЕТНОГО СЕКТОРА
  4. ПРОГРАММИРОВАНИЕ ДЕНЕЖНОГО СЕКТОРА
  5. ПРОГРАММИРОВАНИЕ ВНЕШНЕГО СЕКТОРА
  6. ПРОГРАММИРОВАНИЕ
  7. ПРОГРАММИРОВАНИЕ
  8. 1.1. Методология процедурно-ориентированного программирования
  9. Нетрадиционные4.2.2.1.Методы линейного программирования
  10. ПРОГРАММИРОВАНИЕ РЕАЛЬНОГО СЕКТОРА
  11. 1.2. Методология объектно-ориентированного программирования
  12. МАКРОЭКОНОМИЧЕСКОЕ ПРОГРАММИРОВАНИЕ ДЛЯ ОТКРЫТОЙ экономики
  13. Глава 8 Отмирающая культура
  14. Корпоративная культура
  15. ПРОЕКТИРОВАНИЕ ОРГАНИЗАЦИОННОЙ КУЛЬТУРЫ