• небезразлична к социальным проблемам?
• считает, что каждый должен принимать участие в тестировании продукта?
• оперативно реагирует на внешние угрозы?
• считает, что тестирование практичности программы имеет решающее значение?
• считает сверхурочную работу обычным делом при отставании от графика?
Следующий этап — выбор действий, формирующих корпоративную культуру. Какие препятствия вы сможете преодолеть при этом, какие решения сможете принять, какие проблемы затронуть и на какие конфронтации пойти ради воспитания необходимой культуры? Подумайте об этом и приготовьтесь последовательно воплощать принятое решение. Помните: в конечном счёте культура все равно возникает, пытаетесь вы направлять её формирование или нет.
Корпоративная культура и технологические приёмы
Другой аспект культуры состоит в использовании и освоении внутренних технологических приёмов. Характерной чертой некоторых культур является наличие множества технологических приёмов разработки, в то время как у других их почти нет. Молодые компании часто неохотно осваивают новые технологические приёмы, тогда как в более крупных организациях без них не обходится ни одно задание. По мере роста группы следует подумать о том, как вы собираетесь осваивать новые технологические приёмы. Какие типы приёмов необходимы, а без каких можно обойтись? Как не впасть в крайность, пустив всю работу на самотёк или изнурив себя разными правилами и положениями?
Вот некоторые правила, которых полезно придерживаться при росте организации:
• Взвешивайте затраты на внедрение технологических приёмов и пользу от них
Необходимо сразу распознавать ситуации, когда добавление нового приёма не принесёт пользы. Польза от каждого дополнительного этапа или процесса должна окупать затраты на его внедрение. Порой это трудно выяснить сразу, и в сомнительных случаях лучше отказаться от внедрения новшества.
Если вы чувствуете, что новый процесс необходим, важно знать, как его внедрить. Новые технологические приёмы приносят наилучшие результаты, когда они чётко определены, а их внедрение сулит очевидную выгоду (обеспечивая реальные и измеримые результаты) и не встречает сопротивления коллектива. Если новый приём соответствует этим критериям, велик шанс, что его можно будет с успехом использовать.
С другой стороны, если приём описан туманно, не имеет очевидной ценности или команда не принимает его, следует ещё раз спросить: а нужен ли он? Я не имел в виду, что следует вовсе отказаться от его внедрения, просто нужно быть уверенным, что выгода от внедрения перевесит затраты. Также неплохо было бы проработать проблемы, которые могут встретиться на пути внедрения нового приёма. Не следует спешить с добавлением новых приёмов, но как только исчезли последние сомнения в их необходимости, следует без колебаний приступать к внедрению.
• Прежде, чем внедрять новые приёмы, нужно извлечь максимум из имеющихся
Один из самых обескураживающих аспектов разработки ПО — внедрение новых приёмов, в то время как команда не полностью использует все возможности имеющихся. В вашей команде так быть не должно. За правильное использование имеющихся приёмов отвечают менеджеры и ведущие специалисты. Можно потерять доверие участников команды, санкционируя добавление новых технологических приёмов и игнорируя те, что уже есть. Если обнаружится, что ни один из имеющихся документированных приёмов не используется полностью, созовите собрание группы и решите, представляют ли они ценность. Да — оставьте их и используйте «на все сто». Нет — избавьтесь от лишних технологических приёмов. Что толку держать приёмы, развесив их по стенам, как картины? Они только портят интерьер.
Суть в следующем: нужно внедрить минимальный набор технологических приёмов, необходимый для выполнения работы и следить за тем, чтобы группа освоила их в совершенстве. Не следует осваивать новые приёмы, если вы сами не уверены, что они будут задействованы в полной мере. Группа должна знать: уж если вы решили что-то сделать, то сделаете это непременно.
• Взвешивайте потребности отдельного специалиста и всей команды
Обычно новые приёмы осваиваются, чтобы удовлетворить потребности всей команды. Однако порой новые приёмы вводятся, лишь чтобы облегчить жизнь нескольким людям или даже одному человеку. В этих случаях надо тщательно проанализировать все затраты и выгоды. Если для внедрения этого приёма придётся просить группу сделать что-то сверх запланированного с существенными затратами, нужно быть уверенным, что польза для немногих участников группы стоит затрат, на которые придётся пойти остальным. Если они несоизмеримы, от нового приёма следует отказаться, в противном случае надо разъяснить причины всем, кого коснётся внедрение нового приёма и кому придётся вкладывать в него своё время и силы, чтобы обеспечить его стопроцентное использование.
Из собственного опыта
Как-то раз в NuMega было предложено при регистрации каждой ошибки сопровождать её сведениями о программно-аппаратной конфигурации компьютера, на котором она была обнаружена. Предложение должно быть полезным для тех, кто смог бы легче находить определённые типы ошибок с его помощью и прекрасно подходит для разнородных сред или в случае команд, где разработчики рассредоточены. Однако это стало бы настоящим препятствием для остальных участников группы, которым приходится вводить информацию вручную и без ошибок. Но нашу среду нельзя назвать ни разнородной, ни географически рассредоточенной.
Представляет ли новый приём ценность для компании? Иногда — да, когда дополнительная точная информация позволит легче устранять ошибки, но число таких ошибок не превышает 5-10 в месяц. Однако затраты на ввод этой информации, который должны были выполнять 15 человек на протяжении всего внутреннего цикла разработки (особенно когда приходилось регистрировать до 10 ошибок в день), не стоили потенциальной пользы. Кроме того, большинство ошибок воспроизводилось на любой машине, в противном случае было нетрудно связаться с офисом, откуда поступило сообщение об ошибке, и выяснить необходимую информацию о конфигурации.
Отвергнув это предложение и множество ему подобных, нам удалось поддерживать накладные расходы низкими и в полной мере задействовать имеющийся арсенал технологических приёмов.
Типичные проблемы и их решение
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Проблемы с ранжированием
• Не держите ранжирование в секрете
Не скрывайте факт, что в компании ведётся ранжирование сотрудников, хотя вывешивать транспарант с рангами на виду у всех тоже не стоит. Людям важно знать, что их личный вклад востребован, будет оценен по достоинству и его учтут при распределении различных привилегий и компенсаций.
• Не затрудняйте переход из одного круга в другой
Не стройте искусственных преград между внешним, средним и внутренним кругами. Единственным способом перехода в высшие круги должно быть повышение личного вклада, а единственной причиной перевода в низшие — недостаточный вклад. Кроме того, обязательно нужно отмечать стабильные результаты переводом из внешнего круга в средний, а хроническое снижение качества работы — переводом из внутреннего круга во внешний.
Как сказано выше, при переходе работника из одного круга в другой непременно нужно обсудить это с ним. Позитивные переходы должны быть отмечены и поощрены. Негативные переходы тоже следует отметить и обсудить с глазу на глаз.
• Не заводите фаворитов
Не допускайте использования рангов для определения фаворитов и не путайте его со средством вознаграждения любимчиков. Ранг должен быть основан исключительно на личном вкладе работника. Если ваш друг из группы не вносит вклад наравне с остальными, он не должен участвовать в получении благ наравне с остальными, и точка. Если вы не в состоянии пойти на такое решение, следует вовсе отказаться от ранжирования.
• Играйте честно
Некоторые считают ранжирование сплошным обманом. Причина может быть в том, что ранее этим людям уже приходилось сталкиваться с некорректным использованием ранжирования (см. обсуждение фаворитизма выше). Но с другой стороны, ранжирование никогда не бывает честным, если под честностью понимать уравниловку. Ранжирование призвано не уравнять всех, но помочь при распределении ресурсов на основе размера личного вклада, отметить выдающиеся достижения и стимулировать дальнейшие успехи. В мире, где ресурсы ограничены, нужно найти способ распределения ресурсов, и, вероятно, нет ничего лучше, чем распределение на основе вклада в создание продукта или работу коллектива.
Проблемы с культурой
• Культуру можно изменить
Одна из самых серьёзных проблем с культурой — в ощущении её неизменности. Корпоративная культура больших коллективов и компаний кажется особенно непоколебимой. Хотя изменить культуру может быть трудно, это вполне возможно, если руководство всерьёз на это решилось. Кроме того, в отдельных подразделениях часто складывается собственная микрокультура, созданная в рамках корпоративной культуры, изменить которую сравнительно легко.
• Если организация растёт
По мере роста организации очень важно прививать корпоративную культуру новым работникам. Особенно часто быстрый рост штата отмечается в начинающих компаниях, поэтому там следует особенно тщательно следить за сохранением основных корпоративных ценностей. Для этого следует не забывать о таких вопросах:
— кто мы?
— чем мы занимаемся?
— почему мы делаем своё дело лучше, чем кто-либо другой?
— чем мы отличаемся от других?
— что мы ценим?
Проследите, чтобы все работники компании знали ответы на эти вопросы и эти знания передавались новичкам. Будет ли это собрание с участием участника группы администраторов или просто обсуждение коллегами по команде — вопросы культуры непременно следует обсуждать в открытую и со всей серьёзностью, которой они заслуживают.

Глава 5
Инструментальные программы
В компании NuMega мы использовали лишь те инструментальные программные средства, которые были жизненно необходимы для нашей работы и вписывались в наш стиль работы. Из всех доступных инструментов мы больше всего применяли и полагались на систему управления исходным кодом и систему устранения проблем и неисправностей (поиска «жучков»). Возможность приспосабливать эти продукты к нашим нуждам позволила ускорить работу — вся команда использовала их почти каждый день.
Средства управления исходным кодом
Ваш исходный код — это второй наиболее важный актив проекта, после людей, конечно. Следовательно, во всех проектах, связанных с разработкой ПО, даже в тех, где задействован всего один человек, должна быть обеспечена целостность исходного кода. В течение цикла разработки вам потребуется проверять, обновлять, контролировать и пересматривать изменения в исходном коде. С ростом количества людей, работающих над проектом, и сложности проекта эти требования станут ещё более критичными. Мы рассмотрим основные возможности программного обеспечения по управлению исходным кодом и обсудим некоторые простые приёмы, позволяющие максимально увеличить его полезность.
О чём пойдёт речь
Продукты по управлению исходным кодом хранят файлы с кодом, отслеживают их версии, управляют файлами, составляющими проект, и предоставляют следующие функции.
• Хранение файла и его прошлых, настоящих и будущих версий
Система управления исходным кодом будет обслуживать все порученные ей версии файлов. Она сможет выдать любую версию файла, размещённую в системе. Эта возможность необходима, если вы собираетесь строить приложение на основе предыдущих версий, и особенно важна при одновременном создании нескольких версий одной программы.
• Отслеживание истории изменений для каждого файла
При любых изменениях в файлах система управления исходным кодом внесёт нужные сведения в историю изменений: дату, время, пользователя и обычно небольшое примечание пользователя о природе изменения и его масштабе. Часто эти комментарии — единственное, чем вы располагаете. (Эта информация поможет новым разработчикам втянуться в проект.)
• Группирование файлов
С ростом сложности проекта возникает необходимость группировать файлы: по назначению (например, по подпроектам или подсистемам) или по функциям (например, тестовые задания, спецификации и документация).
• Маркировка файлов, связанных с конкретным выпуском программного продукта
Система управления исходным кодом позволит пользователям пометить определённые версии файлов всего проекта/подпроекта. Это позволяет чётко маркировать или идентифицировать файлы, составляющие определённый выпуск ПО.
• Блокировка и разблокировка файлов
В процессе разработки доступ к рабочему набору файлов требуется более чем одному человеку. Если какой-то файл не используется кем-то ещё, система управления исходным кодом заблокирует файл и выдаст его пользователю для работы. Это действие предотвратит изменение и возможную порчу файла другими пользователями. Когда тот, кому выдан файл, завершит свою работу и возвратит файл в систему, файл будет разблокирован, и появится возможность доступа и выдачи этого файла другим пользователям. Иногда двум разработчикам необходимо одновременно редактировать один файл. Для таких случаев имеется возможность обойти блокировку файла, но тогда координировать все изменения придётся вам. Наиболее изощрённые продукты по управлению исходным кодом обеспечивают множественную выдачу файлов, автоматически совмещая изменения, сделанные в двух файлах. Однако это может быть опасно, так что большинство разработчиков выполняют операции по слиянию вручную (контролируют этот процесс).
Что туда входит
Удобное расположение всех файлов и информации, связанной с проектом — это страшная (но излечимая) головная боль при разработке ПО.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36