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

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

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

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

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

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

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

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

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

54

Агенты изменения

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

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

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

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

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