Бардак в управлении. Пример из жизни.

Время от времени в блогах встречаются темы о плачевном состоянии отечественного менеджмента и клиническом бардаке, создаваемом отдельными лоботрясами на важных постах. Особенно в гос. компаниях. Хочется дополнить список рассказов еще одной историей и заодно пояснить, что плохое бывает не только "у нас" и слабый менеджер явление, скорее планетарное, чем чисто отечественное. Речь пойдет о внедрении ClearCase в компании, где мне довелось работать. Думаю, что CC в представлениях не нуждается, но на всякий случай - ClearCase это такая дорогущая VCS (Version Control System) от Rational (IBM).


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

Предыстория aka "О компании".
Несколько слов о самой организации и культуре разработки в ней. Пациент - средних размеров (зарубежная) хардварная контора. Куча офисов по всему миру, но в этой истории, в поле нашего зрения будут только два из них.Офис разработчиков в Москве и офис разработчиков в Сан-Франциско (?).
Я работал в московском офисе, в отделе, занятом разработкой софта. Спустя какое-то время после устройства на работу, с удивлением для себя обнаружил, что система контроля версий в отделе/филиале/компании не используется. Соответственно, на ближайшем из совещаний предложил начать использовать (внутри отдела) этот полезный инструмент. Смысл ответа был примерно таким: пробовали, использовали, потом забили. "Зачем она нужна не очень понятно. И без нее все хорошо". Хорошо так хорошо, ответил я и тут же установил себе локальный SourceSafe. Была такая простая программулина от Microsoft. Несмотря на скромные размеры и возможности, вести с ее помощью небольшие проекты было весьма удобно. Контора жила своей жизнью, я своей и мы счастливо занимались каждый своими делами.

По сложившейся ситуации мои задачи лежали немного в стороне от производимых отделом embedded-проектов, поэтому созерцать происходящее удавалось немного со стороны.
(Разработка в основном велась на какой-то из версий Embedded Visual C++).

Итак о происходящем. Время от времени меня звали на помощь, когда речь шла о какой-то нетривиальной ошибке.
Тогда я имел удовольствие познакомиться со структурой наших проектов. Эта прелесть заслуживает отдельного описания. Когда-то давно, один умный человек написал первое приложение под одну из наших железяк. Вскоре кому-то другому понадобилось писать следующее приложение, во многом похожее на первое (скорее всего речь шла об адаптации под новую железку). Сделано это было с подкупающей простотой - первый проект был скопирован в директорию по соседству, а затем в него были внесены необходимые изменения. Процентов 90 кода осталось прежним. Потом потребовалось третье приложение - и рядом с первыми двумя, выросла третья директория. Потом еще одна. И еще. Так их стало количество выросло до 15-20. Тогда кому-то в душу начали закрадываться сомнения "а правильным ли путем мы идем"? Его сосед, будучи не в силах отказаться от паттерна копи-паст, чтобы не травмировать коллегу, копировал давно знакомый код уже не в общую, а во вложенную папку - количество проектов снаружи не изменилось, а что там внутри - дело десятое.
Спустя несколько лет каждый файл оказался скопированным бессчетное количество раз и разобраться во всем переплетении кода не могла ни одна живая душа.
Когда это безобразие всем порядком поднадоело, достойные люди договорились, что большие никто не будет плодить новые директории, а будут использованы файлы из существующих проектов.
Однако бардак вышел на качественно новый уровень, потому как быстренько было найдено противоядие. Никогда не догадаетесь какое. Директории уже действительно не копировались, но! Когда в какой-то из файликов требовалось внести изменение, внутрь добавлялась конструкция #ifdef #else #endif. После #else использовался старый код, а после #ifdef новый. Потом - в настройках проекта определялся макрос. Макрос определялся для одного единственный файла (!!) проекта. Обнаружить такую пакость в среднем проекте практически нереально.
Часто, компиляция рабочего проекта превращалась в подбор необходимых макросов в каких-то cpp файлах. Это был реальный кошмар.

(Большой вопрос, почему из общего кода не пытались сделать библиотеку. Скорее всего никто не хотел брать на себя ответственность за такой проект. Или на это не хотели выделять время. Не знаю.)

Присказка закончена. Теперь сама история.

В один прекрасный день менеджмент решил поощрить инженеров и было принято решение о дорогостоящей покупке, позволяющей упростить жизнь разработчиков: ClearCase!
Когда начальник сообщал об этой новости он всеми силами пытался выдержать оптимистичный тон и рассказать насколько это полезное приобретение и как оно упростит жизнь. Да и квалификацию поднимет. Получалось у него не очень убедительно. Коллеги изрядно приуныли. Я сочился счастьем - наконец-то! Такая полезная вещь!
Кстати, о стоимости внедрения. Счет исчислялся миллионами. Из них треть была направлена на покупку лицензий ПО и две трети на обучение персонала. (Имел ли место здесь откат и если да, то сколько он составлял - понятия не имею).

До Москвы отголоски праздника жизни доехали в виде небольшой бандерольки. Внутрях у нее был мануал (ксерокопия методички по ClearCase) и золотой диск с гордой надписью маркером "ClearCase". Чем оно по сути отличалось от продукции первых пиратских ларьков - не знаю. Скорее всего ничем.
Опустим праздник освоения и начала использования.

Расскажу об очень интересной практике - способе мержинга файлов.
Сразу после начала использования ClearCase (внезапно) оказалось, что код написанный разными командами, надо как-то объединять (тут должен стоять смайлик с кривой ухмылкой). Делать это каждый день оказалось слишком хлопотно, поэтому для простоты, мержинг между кода решили проводить раз в неделю - в пятницу. Коммуникации между командами были откровенно слабыми.
В начале рассказа я упоминал, что один офис разработчиков находился в Москве, второй в Калифорнии. На практике это означает 11 часов разницы между офисами. Т.е. последний московский трудоголик уходил из офиса до того, как первый американский приходил на работу. Поэтому специалисту занимавшемуся мержингом кода оставалось только догадываться, что там написали другие люди в другой стране со своими другими проблемами.
Когда стало понятно, что мержинг это отдельная задача и она требует отдельных усилий, было принято решение поручить ее какому-то сотруднику. Ни за что в жизни не догадаетесь кому.

Ответственным за мержинг проектов был назначен системный администратор!!! Описываю гениальную схему работы. Последний русский трудоголик вносит изменения в ClearCase в 18-00 по Мск. Спустя 11 часов (18-00 в С-Ф) последний американский трудоголик вносит изменение в ClearCase и делает автоматический мерж (и случается ахтунг). Админ запускает студию и исправляет ошибки.

У нас был "хороший админ" (это цитата). Он исправлял ошибки (компиляции, конечно) и уходил домой с чистой совестью. Действительно, хороший админ. Безусловно, это был второй ахтунг и почище первого - как может человек будучи не в курсе проектов вносить в них изменения?!

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

Потом "хороший админ" уволился (или повесился). Пришел плохой админ. Он не знал C++ и не мог мержить файлы. Как-то раз он даже приезжал в Москву с целью поговорить с моим начальником и привести безобразие к какому-то нормальному виду. Начальник делал каменное лицо и с головой уходил в работу. Когда каменное лицо переставало помогать, начальник прятался от админа по всем щелям. Щелей было много, а дней командировки мало. Так и уехал админ домой, даже не обсудив толком проблему.
Тогда поведение начальника вызывало мое хмурое неодобрение, но сейчас понимаю, что этот мудрый человек видел невозможность улучшений в сложившемся болоте.

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

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

Какие выводы удалось сделать для себя.
1. Решать надо реально существующие проблемы. Наиболее простым способом. Без лишних затрат.
2. Любой инструмент можно использовать неподобающим образом. Чем сложнее инструмент тем более неподобающим образом он может быть использован.

Надеюсь, Вас подобные ситуации будут обходить стороной :)