"Наблюдение" об одной компании: SoluDyne
13.07.2013 Суббота 01:58
Пожалуй, настало время рассказать про дела давно минувших дней — про самую необычную из моих работ.
Это был российский офис норвежской компании, называющейся SoluDyne. Опыт, который я получил работая в ней, поистине уникален, и прочитав этот пост вы поймёте, почему. Я продержался в компании всего полгода — меньше чем где бы то ни было. Причиной тому — крайне необычные порядки, состоящие почти из одних запретов, граничащих с паранойей, превращавшие рабочий процесс в какое-то бессмысленное кликанье по клавишам, от которого не получаешь никакого удовольствия. Короче, долго распространяться не буду, просто приведу список "необычностей", который я начал вести ещё работая в той компании.
- Начнём с того, что программистский бизнес компании заключается в разработке одного-единственного продукта. Это нечто монстроидальное, объединяющее в себе функции CRM, ERP, bug tracking system, e-mail и, возможно, чего-то ещё, до чего я не успел докопать. В том, что продукт только один (его название, кстати, совпадает с названием компании), разумеется, нет ничего предосудительного — многие фирмы разрабатывают только один продукт и довольно успешны на этом поприще. Но тут ситуация несколько иная. А именно — разработка этого продукта ведётся уже лет пятнадцать, и сказать, что продукт морально устарел значит не сказать ничего. Где-то глубоко внутри в принципе неплохая архитектура за пятнадцать лет обросла такой массой плохо спроектированного хакообразного кода, написанного на всём чём можно — от C++ до VB и .NET, что сделать какое-то изменение, не задев ненароком чего-то ещё, практически нереально (либо потребуется очень большое количество времени на то, чтобы рассмотреть все возможные побочные эффекты). В итоге девяносто процентов времени шесть программистов и технический директор занимаются бесконечным исправлением багов. Бесконечным потому, что исправление одного бага порождает пару новых в совершенно непредсказуемых местах системы. Новые баги могут обнаружиться сразу, а могут — через полгода. Так и идёт работа своим чередом, подпитывая саму себя.
- Наверное, для любого здравомыслящего и инициативного человека первой мыслью, пришедшей в голову после прочтения предыдущего абзаца, будет мысль о том, что в данной ситуации логично было бы предложить начальству и коллегам модернизировать код, по возможности переписав его на новые рельсы, попутно вычистив и сделав более простым в поддержке и улучшении. К сожалению, нас тут ждёт разочарование. Такие попытки предпринимались и мной, и до меня, и, вполне возможно, будут предприниматься после меня. Однако все подобные инициативы встречают на своём пути непреодолимое сопротивление начальства, которое, судя по всему, вполне устраивает сложившаяся ситуация — бесконечное исправление багов.
- "Некоторые вещи, которые у нас изначально планировалось выполнить за полчаса, выполнялись пять лет" — слова (точная цитата), сказанные как-то техническим директором компании, когда он рассказывал мне про историю разрабатываемого ими продукта. Уже одно это высказывание достойно занесения в анналы ибо говорит многое об организации работы в компании.
- Использование "смайликов" с "негативными" эмоциями запрещено во всех средствах коммуникации внутри компании — в частности в электронной почте и корпоративном чате. "Негативный" смайлик — это например такой: 
. Это не шутка, это правило существует и обязательно к соблюдению для всех сотрудников компании. Смысл его, видимо, в том, что в нашей компании всё настолько позитивно, что ничего негативного в ней быть не может в принципе. Об этом правиле я узнал из уст начальства и коллег сразу после первого использования такого смайлика в корпоративном чате.
- Следующий пункт является логическим развитием предыдущего. Эта компания настолько позитивна, что тут запрещены слова "проблема" (problem, issue), "ошибка" (error) и "баг" (bug). Вместо них разрешено использовать только эвфемизмы: "наблюдение" (observation) и "находка" (finding). Это может казаться полным бредом, но это тоже абсолютно серьёзное правило, обязательное к соблюдению всеми, в том числе начальством.
На самом деле, корни этого растут вот откуда. Поскольку разрабатываемой в компании системой пользуются как сами сотрудники компании, так и её клиенты, то в принципе понятно нежелание руководства позволять клиентам видеть в системе сообщения о том, что кто-то где-то нашёл в системе, за которую клиент платит деньги, ошибку. Поэтому правило исторически было такое — любая проблема, найденная в системе, изначально получает статус "наблюдения", и только после тщательного изучения и оценки руководящим составом может перейти в статус "ошибки" или "бага" и подвергнуться исправлению. Но так было давно. И было ли, неизвестно. На практике же баги никогда не становятся таковыми, а так и остаются "наблюдениями" и "находками". То есть заменяются полноценными эвфемизмами. И если кто-то думает, что эта странность ограничивалась электронной почтой и документацией, он ошибается. В устной речи всё было абсолютно точно так же. Фраза "да, это файндинг" для посвяшённого означала "да, это действительно баг". А само слово "баг" было табу.
- Несмотря на как бы типа позитивный корпоративный дух, запрещающий использовать всякий негатив в виде смайликов и неполиткорректных слов, весь российский офис, что называется, разговаривает матом. Пару недель я это терпел, но затем написал на весь офис письмо с вежливой просьбой прекратить безобразие. Помогло, но не в полной мере — мат нет-нет да и прорывался. Но всё же гораздо реже.
- Электронная почта в компании практически не используется, хотя каждому работнику и заводится корпоративный почтовый ящик. На первое же моё письмо по рабочему вопросу, направленное по e-mail'у, мне было сказано, что вся деловая переписка должна вестись в разрабатываемом продукте. Что, учитывая его тормознутость и недружественность к пользователю, делает эту самую переписку крайне трудоёмким и небыстрым занятием.
- "Простым программистам" запрещено говорить такую вещь как "выполнение задачи приостановлено" (the task is put on hold). Приостановить выполнение задачи — привелегия норвежского начальства и не иначе. Это правило я тоже выявил эмперически.
- Известно, что среди программистов нередко практикуется работа из дома. Это совершенно нормальная, широко распространённая практика. Например, в Microsoft совершенно нормальным является разослать всем коллегам письмо типа "Я сегодня неважно себя чувствую и буду работать из дома". Никто слова не скажет. Вот и в компании, о которой идёт речь, тоже позволяется иногда работать из дома. Но есть одно "но". Запрещено использовать корпоративный VPN на домашнем компьютере... Э-э... Когда я об этом узнал, у меня возник небольшой когнитивный диссонанс. А как же тогда работать из дома? Оказывается, из дома надо работать на рабочем компе, который надо носить с собой из офиса. Не, ну тоже вариант, конечно, но зачем таскать домой комп если дома уже есть один? Кроме того, корпоративные ноутбуки были, мягко говоря, тормозные и не поддерживали подключение внешнего монитора. Знаете, пялиться в маленький 14-тидюймовый экранчик тормозного компа когда рядом стоит нормальная, в два раза более быстрая машина с большим экраном — это по меньшей мере противоестественно.
- Все средства разработки (Visual Studio, SQL Server tools и т.д.) установлены на виртуалках, находящихся в сети, полностью отрезанной от интернета. На корпоративных компах не установлено ничего кроме VPN-клиента к этой сети. Более того, между виртуалками в этой сети и корпоративным ноутбуком запрещён (техническим способом) любой copy-paste. Что всё это значит? А это значит, что если, например, вы, пытаясь решить какую-то проблему, нашли в интернете интересующий вас фрагмент кода, вы просто физически не можете скопировать его в код программы, которую пишете. НИКАК! Ибо единственная связь между виртуалкой, на которой вы пишете код, и вашим локальным компьютером — это экран remote desktop'а! Ни e-mail'а, ни FTP, ни HTTP, ни copy-paste, ни расшаривание локальных дисков — ничего это не работает. Поэтому фрагмент кода из интернета придётся набирать руками. Это приводило к том, что программисты, пытаясь обойти запрет, юзали распознавалки текста (!), чтобы скопировать текст хотя бы в направлении из виртуалки в локальный комп. В обратном направлении задача не решалась, судя по всему, вообще никак. Если действительно возникала необходимость положить что-нибудь на виртуалку — например надо было поставить какую-нибудь тулзу для дебагинга — надо было согласовывать этот вопрос сначала с главным архитектором, сидящим в Норвегии, затем с админом, сидящим там же. Затем они сами, если решали, что необходимость действительно есть, клали нужную толзу на виртуалку, и только тогда тулзу можно было начинать использовать.
Для чего существует это ограничение? Я смог придумать только одно объяснение — в тебе видят человека, который потенциально хочет навредить компании, например похитив интеллектуальную собственность — программный код, к которому тебе дали доступ.
- Небольшой штрих к портрету компании. Наше с ними общение началось с того, что они попросили меня прислать им по электронной почте скан диплома. Это было ещё до интервью, то есть это было первое, что они попросили меня сделать, после того, как посмотрели резюме. Это единственный случай в моей обширной практике. Все остальные компании и до, и после этой всегда удовлетворялись строчкой в резюме, в которой указанан ВУЗ, который я закончил. Люди в этой компании мне не доверяли что-ли? 
- Когда я пришёл, мне выделили часть работы, слабо связанную с работой, выполняемой другими программистами. Довольно удачно, подумал я, значит будет больше свободы. Но я ошибся. Свою работу я начал выполнять, используя Visual Studio 2010 (хотя на дворе был 2012-ый год и Visual Studio 2012 вовсю использовалась). Но через некоторое время меня настойчиво попросили задаунгрейдить проект до предыдущей версии Visual Studio — 2008. Причины для меня до сих остаются загадкой.
- Я уже упоминал корпоративный чат, он же "Operation office". Это такое окошко, в котором каждый может написать некий текст, и этот текст появится в аналогичном окошке у каждого, кто подключен к этому чату. Участие в чате обязательно для всех программистов. Кроме того, в нём присутствует норвежское начальство (архитектор, админ, другие начальники). В Operation office принято писать вопросы начальству, отчитываться о проделанной работе и т.п. Кстати, несмотря на как бы навороченность разрабатываемого продукта, и наличие некой подсистемы управления задачами, в которой в каждый момент времени задача назначена на одного конкретного человека, при переводе задачи с себя на другого человека (например, когда программист переводит завершённую задачу на тестера), этот человек не получает совершенно никаких уведомлений о том, что на него назначена новая задача. Поэтому о таких событиях, когда задача меняет "хозяина", нужно было сообщать всем в Operation office. Что мы имеем в итоге? В итоге мы имеем превосходный источник назойливого спама, ибо 97 процентов сообщений в этом чате предназначено другим людям, но читать эти сообщения приходится, иначе есть риск пропустить "своё" сообщение. Кроме того, если не открывать окошко чата когда туда пришло сообщение, то окошко будет назойливо мигать до тех пор пока ты не сдашься и не посмотришь, кто и что там написал. Думаю, излишне объяснять, как именно это сказывалось на производительности труда.
- Юмор абсолютно исключён! Это я тоже выяснил эмпирическим путём, написав как-то в тестовых данных что-то про Путина, который прилетел в голубом вертолёте. Шутку попросили убрать. Повторяю, это были ТЕСТОВЫЕ данные.
- Выше я уже писал про виртуальные машины. На самом деле, более полно схема выглядела так: физическая машина -> локальная VM -> удалённая VM (доступ по RDP). То есть обязательным требованием было наличие локальной виртуалки, с которой уже осуществлялся доступ к удалённой виртуалке, на которой собственно стояла студия и другой софт и где велась разработка. Суть этой схемы осталась для меня загадкой. А вот недетское торможение из-за использования виртуалки на слабом ноуте я помню по сей день.
- Доступ в VPN осуществлялся с использованием токена — электронного ключа, отображающего меняющийся раз в минуту код. Это стандартная практика, и тут всё нормально. Однако когда у меня оный токен однажды сломался, выявилось сразу два неприятных момента. Во-первых, меня пожурили за то, что я, мол, неаккуратно обращался с токеном, вследствие чего он, якобы, и сломался. То, что это первый сломавшийся токен в моей жизни из нескольких штук, которые я использовал на протяжении нескольких лет в разных конторах, никого не смутило. Во-вторых, новый токен мне не могли выдать целую неделю. Всё это время я пользовался кодами, высылаемыми мне в чате начальством из Норвегии, которое брало эти коды со своих токенов. Не, я против этого ничего не имел, но как же безопасность? Как же все эти параноидальные правила, описанные выше? Какой в них смысл если можно вот так запросто воспользоваться кодом начальника и делать от его имени что угодно?
- Технический директор питерского филиала, судя по всему, следил за тем, кто и когда приходит на работу и уходит с неё, анализируя лог местного раутера. Об этом удалось догадаться по косвенным признакам. Например, однажды придя на работу он вдруг начал возмущаться, что кто-то прописал себе static IP. Как об этом можно узнать, не анализируя лог раутера? В другой раз, он, придя на работу ПОЗЖЕ меня, спросил, почему я опоздал на работу на пятнадцать минут. Когда я его спросил, как он об этом узнал, техдир ответил: "Есть способы". В общем, большой брат не дремлет. 
- Софт на локальных виртуалках устанавливается с VHD (image диска) с предустановленным ПО, и устанавливать что-то дополнительное самовольно — запрещено.
- Рабочее время — строго не менее восьми часов. Но это-то ладно, проблема в том, что это — чистое время. То есть, оно не включает в себя обед, перерывы на чай, перекуры, разговоры по телефону на темы, не относящиеся к работе, чтение новостей и проч. На самом деле, любой, кто работал программистом, знает, что всё перечисленное — часть работы. Без этих перерывов на действия, вроде бы не относящиеся непосредственно к работе, работать невозможно, ибо программирование — это интеллектуальная деятельность, и мозгу нужно иногда давать расслабляться. Кроме того, сам факт едва ли не поминутного учёта деятельности сотрудника, по меньшей мере неприятен. Опять возникает ощущение, что тебе не доверяют и видят в тебе человека, который потенциально хочет навредить компании.
- Выше я написал, что бОльшая часть работы — исправления багов. На самом деле, работа в этой компании делилась почти поровну между исправлением багов и ручным регрессионным тестированием. Друзья мои, ничего скучнее чем ручное регрессионное тестирование существовать просто не может. Из раза в раз прощёлкивать всю эту кривую тормозную систему в поисках багов, которые появляются в результате исправления других багов, — этого врагу не пожелаешь. Что самое интересное, моя единственная реальная программистская задача в этой конторе заключалась в написании системы автоматизированного тестирования. И я её написал. И написал для неё тесты, которые по сути устраняли необходимость ручного регрессионного тестирования. Но внедрить это новшество не удалось. Инновация не смогла преодолеть иннертности, консервативности и закоснелости, полностью поглотивших мозги людей в этой конторе. Сняв меня с задачи автоматизированного тестирования, меня поставили снова тупо кликать мышкой, выискывая, что же сломали последние баг-фиксы. Отмечу, кстати, что этой бессмыслицей — исправлением багов и дальнейшей регрессией — занимались все в российском офисе, включая технического директора.
В общем, уже месяца через три после начала работы я начал задумываться о том, что, как говорится, пора валить. И я действительно решил начать поиск работы к новому году, но всё произошло быстрее. Как-то на ежедневном малоосмысленном скайповом митинге с норвегами, мне стало настолько скучно, что я включил какое-то видео из ЖЖ. К моему великому удивлению, звук из видео каким-то неведомым образом прошёл к скайп и стал слышен всем. Я, конечно, быстро просёк тему и всё выключил, но было поздно — страшное правонарушение было совершено. После митинга ко мне подошёл технический директор и при всех сотрудниках объявил, что так делать нельзя и что одного уже уволили за нечто подобное и что я вполне могу стать следующим. На следующий день я написал заявление об увольнении по собственному желанию. Уж лучше уволиться самому, чем ждать кода тебя выгонят с позором, здраво рассудил я.
Я ни секунды не жалею, что ушёл из той конторы.
UPDATE. По поводу ноутов, которые не подключались к внешним мониторам, это я наврал. Конечно, в офисах мы работали за нормальными мониторами. Но дома у меня были сложности с подключением такого ноута к своему монитору. Как минимум, ноуты не поддерживали HDMI, по которому у меня соединены мой собственный ноут с монитором, значит надо было искать VGA-кабель, и это меня окончательно обломало.
UPDATE 2. Ещё одну интересную особенность забыл упомянуть. Каждый сотрудник компании получал специальный никнейм, который использовался для идентификации сотрудника в деловой переписке, присутствовал как часть адреса его электронной почты и т.д. Это, разумеется, нормально. Очередная странность заключается в том, что этот никнейм было принято использовать для обозначения данного сотрудника вообще всегда — даже в устном общении. У меня, например, был ник VBS. Так что обычным делом было услышать в офисе что-нить типа "этот файндинг исправлял VBS".
UPDATE 3. Ещё вспомнил "странность". По результатам исправления каждого бага надо было заполнять специальную форму в продукте компании. В эту форму помимо прочего обязательно заносился полный список изменённых файлов. Причём для каждого файла помимо имени указывался путь во внутренней иерархии классов системы. Этот путь мог быть весьма длинным. Проблема была в том, что форма эта заполнялась на локальной виртуалке, в то время как изменённые файлы находились на удалённой. Между ними, как вы помните, связи помимо RDP-десктопа нет. Поэтому и пути, и имена файлов приходилось набирать вручную. Понятно, что при этом легко ошибиться. Кроме того, хотя это и не было нигде прописано в виде правила, в эту форму для каждого изменённого файла было также принято заносить фрагмент исходного текста с выделенными цветом изменениями. Короче говоря, что такое source control, людям, придумавшим всё это, было, судя по всему, неведомо. Хотя с другой стороны весь исходный код хранился в TFS... 
Вот такая дребедень...