[Перевод] Поглощение на практике: история из жизни

habr.png

Новость о покупке IBM компании Red Hat разделила мнение общественности. Многие небезосновательно встревожены по поводу будущего открытых продуктов Red Hat; однако, как минимум Марк Литтл, вице-президент разработки в Red Hat, смотрит на будущее оптимистично.

В одном из обсуждений опытный enterprise-программист Хэнк, который начал программировать еще под Commodore 64, поделился рассказом о том, как переживали подобные изменения компании, в которых он на тот момент работал. Эта история будет близка всем тем, чей проект когда-либо был поглощен или закрыт. Перевод публикуется с разрешения автора.

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

После этого наступает осознание того, что теперь вы занимаетесь работой, дублирующей друг друга. Поддерживаете два движка транзакций, поддерживаете два сервера сертификации, поддерживаете два…

Первые пару месяцев почти ничего не изменится — поскольку само слияние еще только предстоит провести, да и скорее всего не все контракты еще подписаны —, но эта мысль накрепко засядет в вашей голове и будет регулярно напоминать о себе ноющей болью.
Затем наступит чувство неопределенности. Допустим, вы работаете над движком транзакций, и вы уверены, что он лучше аналога от бывших конкурентов —, но будут ли этот продукт развивать и дальше? Часть ваших коллег ведет себя до раздражения расслабленно — так получилось, что они работают над проектом, для которого «двойника» не существует. Но ваши менеджеры убеждают вас: не беспокойтесь, с вашим продуктом ничего не случится.

Между тем, начинают уходить сеньоры. Вы по-прежнему успокаиваете себя: «сеньоры уходят вся время». Да, пусть это и звучит разумно, но факт остается фактом: уходит подозрительно много сеньоров.

Примерно шесть месяцев спустя начинают вспыхивать мелкие «бунты». Дело в том, что людям хочется знать, где именно они находятся. Но в итоге мало что происходит. Еще больше специалистов уходят.

Год спустя приходит приказ от «их» штаб-квартиры: мы будем производить миграцию на их платформу. Но нам не надо беспокоиться по этому поводу — ведь их платформа гораздо лучше, и X, Y, Z, над которыми мы все это время мучились, ими уже сделаны.

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

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

Что ж, после вас ждет очередная «интересная работенка». Дело в том, что ваша компания для хранения данных клиентов использовала продукт X — однако там используют продукт Y. Так что будьте добры, напишите инструмент для экспорта данных… ах да, и не забудьте, что в течение первого года он должен быть двунаправленным — для того, чтобы X и Y были синхронизированы, пока не будет завершена миграция данных всех клиентов.

Так что теперь еще целый год вы будете работать над очередным хрупким коннектором, теперь уже между двумя веб-API.

Конечно, они будут обновлять свои системы тогда, когда им это заблагорассудится — для них все в бизнесе происходит как обычно, в том числе и обновление систем. Однако, каждый раз в подобном случае коннектор будет ломаться, и кто-то будет сильно на вас зол. Процесс миграции данных будет практически завершен где-то через три года. Тех самых HR и маркетологов, которые больше всех были рады помочь вам с миграцией, вежливо попросят «на выход». Изумление и отказ поверить в происходящее на их лицах вас огорчит, но вы хотя бы сможете еще здесь остаться, поскольку вам еще нужно будет заниматься поддержкой проекта, который теперь стал легаси (даже если технологически он все еще впереди — несмотря на то, что непосредственно над ним никто не работал уже около трех лет).

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

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

Наконец, и этот этап подойдет к концу. К этому моменту практически все, что оставалось от изначальной компании, попросту исчезнет.

© Habrahabr.ru