Книга: Человеческий фактор в программировании

53 Культурное изменение

53

Культурное изменение

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

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

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

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

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

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

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

Первый важный вопрос: где находятся профессиональные ноу-хау организации? Хранятся главным образом в головах сотрудников? Являются частью коллективного фольклора — «здесь принято делать так»? Или же они формально закреплены в методах и процедурах? Другими словами, где «живет» практический опыт и кто им «владеет»? Сколько ноу-хау можно найти в корпоративных руководствах и инструкциях? Куда нужно пойти, чтобы узнать о ходе разработки программного обеспечения? Полагается ли ваша компания всегда и во всем на знания и умения ее блестящих и опытных сотрудников? Что можно узнать, околачиваясь в столовой или слушая разговоры в коридорах? Определяется ли «наилучший способ» на основе личных предпочтений? Или же «хорошее программирование» основано на неписаных законах о том, что работает и что не работает? Как происходит накопление знаний с каждым новым проектом — индивидуально, или распространяется по всей группе, или же эти знания добавляются в архивы и формальные инструкции, принятые в организации?

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

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

Если новые технологии и методы применяются неверно, то их внедрение будет затруднено, а шансы на успех — малы. Например, один из методов перехода к широкому применению объектно-ориентированного проектирования может заключаться в привлечении большой группы консультантов. Они придут со своим рациональным и унифицированным «Объектным методом для разработки гигантских приложений» (Object Method for Engineering Giant Applications, OMEGA) в комплекте с семью томами технологических руководств и предложат несколько ступеней обучения с применением интегрированного CASE-инструмента. Такая участь может ожидать группы, в которых традиционно применяется дисциплинированное проектирование, а полки заставлены замусоленными руководствами по стандартам. Однако группа свободно мыслящих программистов, работающих по своим собственным стандартам, будет увиливать от таких занятий, чтобы покодировать. Они не станут читать инструкции и не будут обращать внимание на всю эту «корпоративную чепуху». Их методы, так же как и их умения и способности, сугубо индивидуальны. Для того чтобы до них «достучаться», вам не нужно загонять их в большой класс на просмотр учебного видеофильма или отдавать в руки бездумного инструктора. Они привыкли на свой страх и риск определять, что стоит изучать, и самостоятельно доставать необходимые материалы, поэтому каждого из них нужно убеждать в отдельности, а затем обеспечивать их локальными ресурсами для индивидуального практического обучения.

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

Одни и те же инструменты разные группы могут применять по-разному. Групповое обеспечение (groupware) может подойти для организации, в которой принято тесно сотрудничать при проектировании и принятии решений. Однако группа разработчиков-одиночек, которые любят работать обособленно, вряд ли заинтересуется Lotus Notes. В компании кодирующих ковбоев сложное групповое обеспечение станет не более чем причудливым средством для дружеской переписки.

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

Кто-нибудь будет маринованную свеклу?

Из журнала Software Development, том 2, № 12, декабрь 1994 г.

Оглавление книги