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