Новый 15-летний проект без команды и документации: как мы выжили

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

Итак, это история о том, как мы выживали, когда не ясно было, как выживать. Сразу скажу: не пытайтесь это повторить...

Закон Мерфи

Зимой 2016, когда мы с женой поехали в круиз на Карибы, по возвращении я приехал в офис хорошо отдохнувший, без особого желания напрягаться после отпуска. Все было довольно предсказуемо: мы выдали релиз перед Рождеством, ошибок обнаружено не было, да и свой проект я знал досконально. Но законов Мерфи никто не отменял: если все идет хорошо, значит вы что-то упускаете. В обед мне назначили митинг у Senior Director, но ничего не предвещало беды...

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

Любой нормальный человек подумал бы об увольнении, но уволиться я не мог. Было два пути: либо плакать и страдать, либо думать и делать. Пришлось идти вторым путем.

Думать и делать: кто нужен в команду

Первое, с чего пришлось начать, — это формирование команды. Но самое интересное, кто нужен в команду — было не ясно.

Многие менеджеры скажут, что нужно было согласовать KT (Knowledge Transfer) plan или что-то подобное, и, конечно же, он у нас был. Но план хорош, когда его готовы выполнять, а выполнять программисты из Коннектикута его не хотели и не собирались.

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

Я поехал поговорить с ними за ланчем. Они рассказали мне, как получают звонки от клиентов о том, что система списала деньги с аккаунтов, но при этом кредиты не зачисляются в системе, и еще много такого, от чего у меня носки сползли в кросовки... После этого ситуация стала совсем печальная.

Как впоследствии окажется, архитектура системы напоминала мне паутину. Было понятно только, что есть ядро, написанное на .NET 2.0/4.0 на базе COM/DCOM технологии, был API, написанный на ASP-Classic, и VB 6.0, интегрированный с ядром посредством COM-компонентов, а также фронтенд, написанный на HAHTSite Scenario Service (Java) cо своим скриптовым языком, с вкраплениями jQuery/Bootstrapper и т. д. Что-то ходило в базу через .NET SQL, что-то через OBDC, что-то через Microsoft Access. Все это было приправлено интеграцией с внешними библиотеками обработки пространственных данных MapInfo/MapXtreme и многим другим.

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

Команда и работа

Стало ясно, какая команда нужна, и выглядела она так: четверо программистов с нашей стороны с хорошим знаниями .NET, а также знаниями VB6.0 и опытом работы с пространственными данными. К работе подключили BA с нашей стороны, поскольку проект не содержал вообще никакой документации. То есть за 15 лет никто не удосужился вообще что-то задокументировать. В команду включили QA, потому что было не ясно, как вообще можно проверить эту систему на работоспособность, начать ее менять и мигрировать.

Со стороны клиента нам назначили BA, которая сидела в Чикаго, PM, который сидел в Лос-Анджелесе, Product, который сидел где-то в Коннектикуте, и одного Release-инженера, который сидел в одном кубике со мной.

Клиентский бизнес-аналитик ушла через месяц после того, как оказалась на нашем проекте, привнеся больше хаоса, шума и беготни, чем пользы. Формализация артефактов и вся работа по формированию документации легла на плечи нашего BA. Это был первый камень с моих плеч. По крайней мере, если бы она не ушла сама — мне бы пришлось думать, как сделать так, чтобы на проекте ее не было. А тут такой подарок...

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

«Самый медленный верблюд»

Стоит еще сказать о release-инженере на стороне клиента, так как это отдельная история. Есть старое утверждение, что «караван идет со скоростью самого медленного верблюда». Так вот, релиз-инженер не стороне клиента был не просто медленным верблюдом, он был гирями на моих ногах. И вот теперь стояла задача избавиться от него, но при этом сохранить дружеские отношения, не показать клиенту, что он не справился со своей работой, потому что на другом проекте он ведет весь деплоймент. То есть конфликтовать было нельзя, а работу он свою явно не тянул.

У него была идея разбить все на модули, сделать компонентный деплоймент. Отлично, это ему и поручили. После двух недель мозгового штурма у него стали закипать мозги от проекта: он пытался билдить проект и полностью, и частично, и покомпонентно — UI отдельно и back-end отдельно. Когда идеи исчерпались, он сказал, что development team должна разобраться и предоставить ему исправление ошибок билда. Я думаю, для многих знакомая ситуация — когда во всем должны разобраться программисты. Но пойдем дальше.

Так и было сделано, я ему отправил пояснения его ошибок и пошел дальше работать. Указав при этом руководству, что не могу выделять больше времени на разработку стратегии релиза, потому что есть текущие более критические задачи. Ему пришлось снова уйти в мозговой штурм на неделю или две. В общем после десяти вот таких итераций, а также мягкого намека руководству, а еще и после того, как появились сложности с релизами на других проектах, наш клиентский release-инженер сказал: «Не могли бы вы это взять на себя?». И героически ушел решать проблемы, «созданные им же самим».

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

Первый программист уволился в конце марта

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

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

Кстати, на мое замечание о связанности системы мне четко ответили, что система, доход которой исчисляется несколькими десятками миллионов долларов, не может быть плохой :) И вот как парировать такой аргумент? Да никак. Вы можете только взять и сделать так, чтобы она приносила еще больше прибыли.

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

Второй программист ушел в апреле

Работу пришлось разбить на несколько частей. Я занялся полностью суппортом, так как другого способа просто не было. Никто лучше нас систему не знал, ни у кого не было понимания, как работает код и как можно поддерживать более 40 тыс. аккаунтов с более чем 6000 конфигураций на существующих 23 серверах. Двое ребят в Киеве начали разбираться в GUI и API, параллельно пересаживая его на более стабильную и современную платформу. Один человек занялся рефакторингом существующего ядра. BA начала работу над документацией: как система работает, какие есть конфигурационные настройки и как они влияют на работу приложения. QA занялся покрытием системы интеграционными тестами, разработкой тест-планов и стратегией тестирования.

Третий программист... на него я зла не держу

Третий программист, который в основном занимался конфигурированием системы, смог провести ряд сессий и как минимум предоставить нам базовую информацию, как работает система и как построен процесс конфигурирования в системе. Он уволился в июне... на него я зла не держу.

Начиная с апреля, моя работа состояла в том, чтобы прийти утром — выписать на доске проблемы, которые я планирую решить, и в течение дня менеджер просто подходил и расставлял на доске приоритеты. Никой Jira, TFS или Trello. Есть проблема — подходите, пишете на доске ее номер и все. Я знаю, что ее нужно решить раньше, чем проблему под ней. Затраты на коммуникации практически свелись на нет, так как объем приходящих проблем был просто колоссальный. Я мог в день закрыть 30 багов и на следующий день проснуться с еще 30-ю новыми. Но через два месяца я уже знал ответы практически на 90% всех возможных вопросов, имел рабочую среду разработки и рабочий environment c возможность отладки, имел доступ ко всем production-системам.

Подходим к стабильной стадии

К осени у нас уже был рабочий прототип UI, написанный на Angular + ASP.NET MVC, документация и что самое главное — понимание, как работает система. И все казалось не таким страшным, но клиент решил отказаться от нового UI, сохранить сервера на Windows Server 2003 и попытаться мигрировать существующую систему в новый data-центр. И моя жизнь опять приобрела темный оттенок.

В нашей компании более 20 тыс. человек. И когда я попытался поискать кого-то с навыками работы c HAHTSite Scenario Server, я нашел только одну девочку, которая добавила это в описании своего проекта, еще когда пришла джуном, и даже не могла пояснить, что это значит и как это работает. Bот такой легаси код, пацаны...

Документацию по HAHTSite мы выкачали где-то на китайских сайтах, как и документацию по остальным компонентам. Компоненты работы с пространственными данными уже не поддерживались производителем, и клиент не хотел платить за лицензию. Я вспомнил VB 6.0, который учил еще на 2 курсе университета, и вы даже не представляете, что значит найти рабочий инсталлятор VS 6.0. Я научился реверс-инженерить программы, когда ты запускаешь код и просто с помощью Process Explorer-а видишь, как выполняется программа, что она берет из реестра, какое событие она передает, какую переменную инициализирует, смотришь через WireShark, куда отправляются пакеты и что возвращается обратно. Это магическое зрелище... и нудное одновременно.

В результате

На сегодняшний момент проект вошел в стабильную стадию, продукт стабильно генерирует миллионную прибыль ежегодно и масштабирован на нескольких десятках серверов. Потратили мы на проект около 2 лет, а на более-менее стабильную стадию мы вышли через 12-16 месяцев. Сейчас полностью построен билд-процесс и процесс тестирования, написана тонна документации, клиент спит спокойно и большинство ребят уже на другие проектах. И я хочу уже подвести вас к выводу, который я сделал:

КОМАНДА — ЭТО ВСЕ!

Меня часто пытаются убедить, что процессы главнее, что все заменяемо и что менеджмент — это главное, а исполнители нет. Но сделал бы я этот проект с другими людьми? Я думаю, нет.

Спасибо ребята! Вы лучшие!

Советы

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

Вот советы, которые я бы дал (постараюсь избегать общепризнанных очевидностей):

Убедитесь в адекватности клиента вообще. Если клиент вам доверяет и понимает, что вероятность провала высока, и при этом дает кредит доверия, то практически половина работы сделана.

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

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

Всегда планируйте с запасом. Даже если вы сэкономите время на одной задаче, вы его с лихвой потратите на другую.

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

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

Вовлекайте команду в общение с клиентом. Это, с одной стороны, разгрузит вас от задач по коммуникации, с другой — позволит команде участвовать в процессе и держать руку на пульсе. В общем не старайтесь быть «бутылочным горлышком».

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

Старайтесь внедрять новые практики в проект. В нашем случае клиент не понимал, зачем строить CI/CD, и предлагал не тратить на это время сейчас. Мы выделили на это время за счет других задач и построили систему локально, потом перенесли ее на сторону клиента. Когда стала задача, что нам нужен CI/CD, — у нас он уже был, и клиент остался доволен, хотя, по сути, он за это заплатил за счет других задач.

Также старайтесь, чтобы программисты работали локально. Я не знаю, откуда взялась тенденция заставлять людей работать через RDP, — но это просто убивает желание работать на корню. Все должно быть локально и по возможности автоматизировано. Это позволит вам понимать систему как никому другому. Если вы можете поднять систему локально, это значит, что вы ее знаете досконально.

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

Учитесь другим технологиям, пока работаете над проектом. Когда вы уволитесь — все ваши знания будут никому не нужны :) Но когда вас спросят, можете ли вы работать в критической ситуации, — вы точно будет знать, чего это стоит и сколько за это просить.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Блин полдня смотрел как висит офигезный текст и никто не комментит :)

То ли лонгрид и народ забил, то ли не дочитали до пассажа про 35 млн, то ли надо было заголовок поменять на «Как мы заработали 10 млн за два года и убили попа»

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

И да, теперь ДОУ вылезет по запросу HAHTSite в топ выдачи :)

135 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Питання на паралельну тему: як такі красиві діаграми взаємозв’язку об’єктів, які щезли можна автоматично намалювати на FE проекті з Backbone.js ?

Если вы про диаграмму зависимостей. Нарисуйте в VS.NET и экспортаните в SVG. Там никакой магии — обычный XML. А потом если нужно сделайте темплейт и бандите его в Backbone как вам нужно.

Я уже обрадовался, что это домен никто не купил, а оказывается занят уже кем-то.

якщо абстрагуватись від Backbone.js, то запит javascript library graph visualization повертає багато варіантів
а побудувати граф залежностей — то окрема задача, дивлячись, що в вас за мета

Спасибо за описанный опыт

А вообще довольно занимательно если подумать тут вот капитаны периодически толкают речь за то якобы отечественному аутсорсу переходить от бездуховной гребли (и низкомаржинальности ага ага) к продукта созданию а тут вот выходит совсем наоборот пришёл бездуховный аутсорс и отобрал работу у программистов маленькой уютной ламповой продуктовой (!) компании кстати сам по себе продукт как продукт вполне годен реализация уже дело десятое о чём кстати в свою очередь непременно расскажут вам капитаны Настоящих Контор аля Стартапов (с последним айфоном и макбуком ага ага).

Так сказать нэвдобно выйшло я щетаю ))

А так все таки приятные люди:

youtu.be/1sXFSqK6q9U

— и не скажешь что могут вот так запросто нож в спину или не нож и не в спину ((

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

И вот ведь какая штука все программисты значит ушли всё бросили и ушли все 4 (четыре) штуки а Vice President Software Engineering значит остался.

А сама контора так и вообще Founded in 1930. Чего программисты обиделись непонятно ((

? Не пойняв.
Alex, ти провів reverse engineering ? :)

Та нє ну яке там просто маю рефлекторний досвід

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

вот ето всьо.

Доречі дуже рекомендую там і так можна накопати купу всього зокрема цілком годної документації по проекту яка #внєзапно велася або навіть збереглася на якомусь «випадковому» форумі тощо.

Аlex, тут не совсем все верно. Это продукт был разработан другой компанией и к этом компании имеет мало отношения. В силу административных перестановок продукт передали в руководство этой компании. И у меня лично нет претензии к менеджменту, им тоже пришлось не сладко. Наша часть состояла в том, чтобы технически довести проект до состояния, когда он стабилен и не приносит головной боли. Я и сказал в конце,

Убедитесь в адекватности клиента

, и менеджмент тоже прикрывал нас от давления сверху, так что у меня нет никаких претензий. Все делали свою работу и в большинстве своем не всегда приятную. И лично о Vice President Software Engineering могу сказать, что очень хороший менеджер. Именно человек на своем месте, я бы сказал, мне бы поучиться многому у него.

Прикольно... картинки в тексте по ходу самоликвидировались... )) и текст соотв. подпилился... ))

Под лозунгом «КОМАНДА — ЭТО ВСЕ!» исчез список членов, собственно, команды. Ха-ха-ха, то есть мяу.

Подозреваю, что фотки и имена ребят, могли трактовать как нарушение NDA. И думаю это причина, малого количества подобных статей из за ограничений.
Статья очень интересная и познавательная.
Получая $35 млн. скопить такой технический долг... Бизнес всегда будет экономить и тянуть до последнего, а потом еще чуть чуть. На то он и бизнес. Но меня статья заставила задуматься а как можно было иначе, как можно было быстро писать продукт, зарабатывать на нем, развивать его и при этом оставаться на острие технического прогресса? Тут кто-то в комментах сказал, рано или поздно любой код станет Lagacy — но не ужели нет вариантов?

могли трактовать как нарушение NDA. И думаю это причина, малого количества подобных статей из за ограничений.

Давайте уж тогда уж напишу как есть причина малого количества подобных статей что кроме общих пунктов и формальных NDA участников другой информации в ней нет. Вот например:

КОМАНДА — ЭТО ВСЕ!

— но старую команду уволили настолько что послужило поводом для написания статьи как желенджа всего проекта а почему?

Получая $35 млн. скопить такой технический долг...

Ну какой «технический долг»?

Как впоследствии окажется, архитектура системы напоминала мне паутину. Было понятно только, что есть ядро, написанное на .NET 2.0/4.0 на базе COM/DCOM технологии, был API, написанный на ASP-Classic, и VB 6.0, интегрированный с ядром посредством COM-компонентов, а также фронтенд, написанный на HAHTSite Scenario Service (Java) cо своим скриптовым языком, с вкраплениями jQuery/Bootstrapper и т. д. Что-то ходило в базу через .NET SQL, что-то через OBDC, что-то через Microsoft Access. Все это было приправлено интеграцией с внешними библиотеками обработки пространственных данных MapInfo/MapXtreme и многим другим.

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

— вот это и есть описание _реального_ продукта в отличие от сугубо абстрактно сервисного аутсорса об котором даже написать за 2 года казалось бы работы особо нечего потому что на самом деле «всё уже украдено до нас» а «работа» в основном состоит в том что кто-то где-то уволился (ай какой нехороший!) а при этом у «компании» код на сервере оказался внезапно зашифрован zend (как случай из реальной практики и смотрите как мощны мои лапищи никаких NDA вот что значит опыт) ай как неудобно получилось ай какие нехорошие программисты взяли уволились а код зашифровали тот самый который #внезапно таки приносит условных $35 млн (пусть и из другого контекста) работает последних 15 лет в конторе которая немного не дотянула до 100 так бывает ))

Даже более того «следи за рукой»:

К осени у нас уже был рабочий прототип UI, написанный на Angular + ASP.NET MVC, документация и что самое главное — понимание, как работает система. И все казалось не таким страшным, но клиент решил отказаться от нового UI, сохранить сервера на Windows Server 2003 и попытаться мигрировать существующую систему в новый data-центр.

Т.е. оп же ж обратно же ж таки всё работало #внезапно настолько хорошо что даже 7 (семеро) специально обученных украинцев привезённых в неволе в далёкий штат Милуоки таки _разобрались_ и то не за 2 (два) года а очень даже вполне себе «уже к осени» и вообще «всё оказалось не таким страшным» так где же ж «технический долг»? Ещё раз напомню об тех самых $35 млн revenue и таки да это и есть продукт кстати до того работавший силами уже 4 (четырёх) программистов (и одного VP of engineering конечно же ж #сарказм).

Вот другой пример из классики продукта совсем свежий «чуваки у вас на сайте paging не работает (формируются неверные ссылки на страницы) как результат чего ваши клиенты чисто физически не смогут попасть дальше первой страницы вот описание исправления заапрувьте пож мы тут же ж выкатим» а в ответ «да мы знаем (здесь не помню точную формулировку что-то вроде как-нибудь потом) но сделайте нам пож экспорт оттуда» а ну ок. Об каком «техническом долге» вообще речь если вот скажем:

В нашем случае клиент не понимал, зачем строить CI/CD, и предлагал не тратить на это время сейчас.

Это обычная практика ничего сколь-либо сверхтехнологичного в таких проектах нет (давайте только не будем считать VB 6 и «работу с пространственными данными» высокими технологиями XXI века наравне с ангуляр реакт и агиле #сарказм) в основном всё сводится к «внутрикорпоративным манёврам» вроде:

Мы выделили на это время за счет других задач и построили систему локально, потом перенесли ее на сторону клиента. Когда стала задача, что нам нужен CI/CD, — у нас он уже был, и клиент остался доволен, хотя, по сути, он за это заплатил за счет других задач.

Вот вы поняли кто за что когда и как «по сути заплатил»? )) «Ну как-нибудь так» (к) (тм)

ЗЫ: не записывайте пож на мой счёт якобы я ругаю или неодобряю сабж я так не делаю ))

Вы абсолютно правы, не было там никакого технического долга. Но был риск, что когда что-то упадет, поднять будет некому.
И вот эту проблему параллельно с багфиксом ребята и решали.
Кстати, на этом фоне становится понятным нежелание клиента строить CI/CD.

Но был риск, что когда что-то упадет, поднять будет некому.

Ну логично же ж они же ж всех разработчиков выбросили на мороз а морозы в штате милуоки весьма суровые! ))

ЗЫ: скажем в этот год по слухам было до 28 ниже нуля по цельсию сам не проверял но инфа не расходится с остальными данными по всему миру этот год морозы суровые даже вон на киевщине как раз #внезапно зима ))

рано или поздно любой код станет Lagacy — но не ужели нет вариантов?

— legacy )) как правило нет когда речь идёт о бизнесе реального сектора. Расписывать почему?

Потому что он меняется постоянно? Адаптируется под рынок?

Как часто вы покупаете стол? Когда последний раз покупали? В Киеве обещают таки запуск «икеи» пойдёте менять старый стол на новый?

:) я не понимаю Вашей аллегории но она мне нравится :)
Нет не пойду. Но мой стол вполне современный, и если сломается — я знаю где и за сколько мне его починят.

:) я не понимаю Вашей аллегории но она мне нравится :)

Холодильник? Каждый год новая модель! Когда пойдёте покупать новый?

Стиральная машина? Как насчёт простите унитаза и раковины в ванной и скажем смесителя в рукомойнике? Шланг для душа? Шины в авто?

Вот здесь на форуме есть где-то по соседству тема за электронные декларации спд фоп мол сама суть не меняется и то довольно давно но как-то там меняется «внутренний формат» поля там какие-то что-то ещё из-за чего таки _приходится_ постоянно «адаптироваться под рынок» точнее под изменения и вот что интересно _бизнесу_ это вовсе не нравится.

Подозреваю, что фотки и имена ребят, могли трактовать как нарушение NDA. И думаю это причина, малого количества подобных статей из за ограничений.

Угу. Згідно NDA, команду після закінчення роботи з проектом ліквідовують (за рахунок замовника).
По достовірним даним, на сьогоднішній день вже ліквідовано більше тисячі українських сеньорів, що працювали на CIA, NBA, DOD, FBI і NASA. Імя іх нєизвєстно, подвіг іх бєссмєртєн ©

Але все що попадає в інтернет там і залишається. Гугл-кеш наше все:

webcache.googleusercontent.com/...​&cd=1&hl=en&ct=clnk&gl=ua

Картинки и схемы попали под NDA. Я немного подчищу и скорее всего вернем. My bad !!

Рис 2 таки потерялся мне удалось сохранить только в скриншоте ((

ЗЫ: продам недорого! ))

В заголовке

Новый 15-летний проект без команды и документации

А судя по телу поста ваше вступление в права собственности сопровождали 5+ месяцев.

Теперь передайте воображаемому коллеге документацию (которую вы, видимо, написали) без поддержки, и подумайте какими словами он вас будет вспоминать.

По итогу вам очень-очень нежно передали некоторое legacy.

Два года чтобы перелопатить чужое г**но и выложить его заново как свое, успешно после этого забыв о нём. Впрочем, ничего удивительного, в этом же и есть суть нашего аутсорса.
Автору респект, показал что главное для инженера — работу работать, а не код писать да о технологиях рассуждать. Но всё равно остаюсь при мнении, что это потраченные впустую 2 года. Судя по всему за это время поехать на карибы ещё раз не очень получилось, поэтому надеюсь в конце достойно отдохнул :)

Два года чтобы перелопатить чужое г**но и выложить его заново как свое, успешно после этого забыв о нём. Впрочем, ничего удивительного, в этом же и есть суть нашего аутсорса.

а почему ты думаешь, что это ваш аутсорс? я так думаю что это таки наш аутсорс, так как насколько я понимаю это случилось однажды в Америке :)
Я это к тому, что нет никаких сакральных проектов и сакральных знаний которыми обладают какие то сферические инженеры где то на берегах слоновой кости.

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

А у тех пятерых, которые с Украины тоже были такие договоренности?

И сколько из 35-45 млн/год $ перепало Вам? :)

Еще вот интересно, есть ли проекты, которые через 15 лет не становяться legacy и ужасными? Те которые переписываються каждые два года на новый Angular, потом на React, потом на Vue?

Компания работает как вендор — цель была показать, что при хорошей команде и плохом продукте, команда может его не только вывести в стабильную версию, но увеличить прибыльность. А насчет проектов вы абсолютно правы. Как говорил мой друг — все автомобили рано или поздно становятся Деу Ланосами:))

все автомобили рано или поздно становятся Деу Ланосами

wwwa.autotrader.ca/...​owCpo&orup=5_15_0&sprx=-1

Все кроме Ford Mustang и DeLorean DMC-12 :)) Не принимайте все дословно. В большинстве случае, все проект пройдут стадию роста, стабилизации и заката, а может реинкарнации...

Дело не в старой технологии, а в том насколько она тесно связана с остальными компонентами. Будь это хоть часть на коболе, если изменение в другой части не обязывает разбираться в ней — то никакой проблемы с легаси нет. И ещё лучше, если это компонент, который достаточно хорошо задокументирован и достаточно отделен от общей системы, чтобы при желании переписать его без излишних усилий.

Полагаю те в которых «главный программист» не «уходит внезапно» первым из всей (т.е. вообще всей) команды программистов оставив после себя только чистый ноутбук т.е. скажем отличный проект отличный клиент и вообще люди все хорошие и тут #внезапно все ушли а главный программист потративший на это 15 лет (здесь предположительно и видимо утрированно) вдруг решил не оставить после себя ничего? Ну бывает... наверное всё было очень хорошо просто человек такой попался редиска.

Чехов писал письма о том, что если вы в первом акте повесили на сцене жену, то в последнем она должна выстрелить.

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

Почему?

Извините, про жену совсем не понял. Она тут вообще ни при чем, кроме того, что поддерживала меня все это время.

Об этом я и сказал.

Жена была упомянута во первых строках вашей эпистолы, а далее нигде не упоминается и, как уже выяснено, вообще ни при чём.

На нее свалился тоже весь груз этого. Одно дело, когда Вы приходите рады, то что делает, другое дело, когда Вы возвращаетесь домой — а мысли у вас, что завтра еще один такой же день. Это сложно для семьи тоже.

Хорошая статья. Правдивая.

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

другим проектом, который достался компании в результате поглощения

Когда отжать отжали, а что делать с награбленным — не знают. «War.. war never changes.» ©.

Блин полдня смотрел как висит офигезный текст и никто не комментит :)

То ли лонгрид и народ забил, то ли не дочитали до пассажа про 35 млн, то ли надо было заголовок поменять на «Как мы заработали 10 млн за два года и убили попа»

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

И да, теперь ДОУ вылезет по запросу HAHTSite в топ выдачи :)

Не влезай — убъет, а лезть надо.

Кому надо? Зачем надо?

На все эти вопросы ответов не было. Но одно было ясно как божий день — все программисты скоро уволятся, а работа системы не должна остановиться...

Эта цитата не отвечает на поставленные вопросы.

Вы вот ответьте (для себя хотя бы) на поставленные вопросы, и тогда станет понятно, почему никто не комментил «офигезный текст». Та и сейчас именно текст не особо коментят.

Та и сейчас именно текст не особо коментят.

на этом срач не поднимешь

как по мне так отвечает, но у каждого свое мнение

фреймворки про которые никто не слышал

это будущее любого фреймворка

Кажется я даже знаю компанию от которой этот проект достался :)

Нет это не я. :) Но мой недавний проект оооочень напоминает то что вы описали и такое дежавю у меня возникло.

Честно говоря не понимаю вот этого сочетания.

С одной стороны ты пишешь

если вам «повезло» попасть в подобный проект. Честно — я бы рекомендовал начать искать другую работу

С другой

Третий программист, который в основном занимался конфигурированием системы, смог провести ряд сессий и как минимум предоставить нам базовую информацию, как работает система и как построен процесс конфигурирования в системе. Он уволился в июне... на него я зла не держу.

На остальных получается держишь. Почему? Ты же сам написал: если нужно геройствовать — увольняйтесь.

как я понял, это те трое, которые на стороне клиента занимались системой, но саботировали("сидячая забастовка") передачу знаний о ней.

просто досиживали свое время ничего не делая. понять можно, простить нет)

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

Иначе я бы как начальник тоже начал действовать не по бумаге

А как? Я не знаю что в США, но на Украине если тебя «уходят» в связи с сокращением штатов, напрягаться и передавать дела никто не будет. Ответить на вопросы это да, но не более

подворотня все дела =DDD

Ты думаешь человек прошедший подворотню будет передавать дела лучше?

Ну напрягаться не надо а хотя бы 60%рабочего плана выполнять стоит. Иначе я бы как начальник тоже начал действовать не по бумаге

1) И шо ты зделаеш? :)
2) Почему 60%, может можно сторговаться на 57-58%?

А если серьездно, то эта ситуация четко показывает: почему лучше сразу уволить и заплатить выходное пособие, чем дать поработать на время передачи дел.

— поработать еще 2-4 недели и получить и зп и пособие, делать минимум но провести кучу митингов с новой командой для КТ

А можно же в течении 2-4 недели катать по 10 писем в день, переносить митинги и как результат получить ЗП где-то за 2 доп месяца, сваливая все на плохую комуникацию с разработчиками из какой-то страны из Африки, или Азии, или где там эта Украина находится.

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

Правильно менеджерам было не завязывать все на одного человека. А так у них был один, который подерживал все ядро, делал всю магию и деплоил это все руками на продакшен. Другой занимался UI и абсолютно не знал, что происходит дальше и третий, который занимался базами-данных и все. Я так понимаю первые понимал своe приоритетное положение и хотел выбить себе как можно больше плюшек (акции или рост ЗП или позицию), но видно планка была настолько высокая, что даже в этом случае было проще отдать проект нам.

Если не завязывать на одного человека, то надо в 2-3 раза больше людей на проект (соответственно, в 2 раза больше расходы), и делаться будет тоже в 2-3 раза медленнее (еще умножаем на 2 расходы).

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

А в контракте написано, что человек отвечал за непрофессионализм вендора? :)
Но-но-но, так можно и негативный отзыв на ДОУ ... то есть гласдоре получить.
Если бы могли уволить «в соответствии с контрактом», то уволили бы.

Толку то его держать такого?

Вот именно. Человек может работать или на 100%, или нет смыла его держать. А грань между 60% или «ну ты что ли митинг организуй» и 10% или «во всем виноват Раджеш» настолько расплывчатая что ее просто нет.

Просто вместо полюбовного месяца-двух передачи проекта — минимальный срок начиная с момента извещения

2-4 недели, теперь 1-2 месяца.
Суть простая: работник получает «пособие» (деньги за минимальный срок с момента извещения) + ЗП за весь период от того как он понял что его сливают до извещения о сокращении.
Минимизировать вы тут можете только второй пункт, который работнику не гарантирован, значет и терять ему нечего.
Если работник хочет увеличить свою прибыль, то он это может сделать только за счет __увеличения__, снова же, второго пункта.

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

Я не мог уволиться:)) У меня виза L1 была на тот момент. Можно наверно было стать в позу и не делать, но тогда я все равно поехал бы домой. При переезде в другой штат — это также задержки в процессе оформления грин-карты.

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

Так ті, хто звалив, я так розумію, до такої ситуації і довели. І, підозрюю, на початку їх було більше ніж троє.

Возможно. В целом мы отдавали технический долг, которые кто-то создал за те 15 лет.

Компании платила премии регулярно командe. Менеджмент понимал, что проект сложный и наш и клиента.

Хороший вопрос — Вы меня даже поставили в тупик. Да, я бы не рекомендовал кому-то идти на такие проекты. В начале была идея перевести хотя бы UI на новые технологии, это не бог весть что, но уже более менее интересная задача. Но разобраться со всем этим стоило титанических усилий. Я бы сказал, что это характеризует степень синьорности каждого из членов команды, есть задача — ее нужно решить. И если где-то по тексту звучит осуждение, но наверно я не достаточно смог выразить, как я благодарен ребята за то, что они сделали. Каждый из них внес свой незаменимый кирпич, чтобы стена стояла :)) Извините, что немного философски получилось.

Не понял комментария. Поясните.

Но всё же... Есть задача, которая
1.Не принесёт сколько нибудь ценного(то есть оплачиваемого) опыта
2. Потребует доучивать в свободное время технологии, чтобы оказаться на плаву
3. Утомительна

Какой смысл решать, если можно просто свалить? Это могут быть какие то карьерные соображения, или больше денег, или попросту деваться некуда. Как было у тебя.

В этой связи нельзя ли рассказать что удалось хорошего получить для себя? Речь шла о повышении зарплаты, на сколько денег в среднем удалось повысить? Можно в процентном отношении.

Я ждал, что кто-то меня спросит, а что в конечном счет получил для себя.
1.Первое в моем случае все просто — проект мне позволил продержаться в США до получение грин-карты.
2.Был рост по ЗП, но не могу сказать, что он был существенным — особенно в США.
3.Отличные отношения с клиентом, мне даже вице-презиндент написал в linkedIn фидбек, не знаю, пригодиться или нет. По крайней мере могу на кого-то сослаться в будущем.
4.Наверно скилы кризис деливери-менеджера я прокачал значительно.
5.Есть побочные, пока жена была беременная — я ее не обременял переездами.

Думаю это все. Ну еще вот статью смог написать :))

мне даже вице-презиндент написал в linkedIn фидбек, не знаю, пригодиться или нет.

О! тут следы! можно почитать что за контора и вообще... ))

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

Я бы еще уточнил, что речь идет о технологиях, которые в дальнейшем нафиг не нужны. HAHTSite Scenario Server, говорите...?

HAHTSite Scenario Server, говорите...?

Учите что-то новое и перспективное. Я бы скривил душой, если бы написал что поработав с такой зрелой системой энтерпрайс уровня выведет Вас на новый уровень. Да, мне это конечно дало хорошее понимание COM/DCOM, а куда его применить.. хз :))

Я не мог уволиться:)) У меня виза L1 была на тот момент. Можно наверно было стать в позу и не делать, но тогда я все равно поехал бы домой. При переезде в другой штат — это также задержки в процессе оформления грин-карты.

А 7 человек из вашей комманды тоже грин-карту ждали? [Тут толжин быть смайлик с улыбкой, но как-то даже не смешно]

Да, тут вы правы — я работал, потому что у меня нет гринки и мне деваться некуда, а ребята могли бы и отказатьcя. У каждого были свои какие-то мотивы я думаю, и проект не был вечным. В идеяле — если бы отписался каждый из них. Для QA это был хороший челенд, для BA тоже была задача хоть и сложная, но позволяла бы всегда поставить себе плюс в резюме. Девелоперам конечно пришлось тяжелее всего.

Для QA это был хороший челенд, для BA тоже была задача хоть и сложная, но позволяла бы всегда поставить себе плюс в резюме. Девелоперам конечно пришлось тяжелее всего.

От совсем чуть-чуть недотянули:
Для девелоперов — это возможность поработать со зрелой системой энтерпрайз класса :)

Фактически реклама ЕПАМа получилась прекрасная:
Разгребая гуано у нас вы сможете получить челендж, строчку в резюме и спасибо от вашего менеджера, который дожидается получения грин-карты [От чесно не знаю смеятся или плакать]

EPAM я не рекламировал вообще. Вы думаете в GlobalLogic, DataArt или еще где-то нет подобных проектов ? Вы конечно можете давить, что я ждал грин-карт, но при этом мотивировал людей работать за призрачные цели и

возможность поработать со зрелой системой энтерпрайз класса

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

Вы конечно можете давить, что я ждал грин-карт, но при этом мотивировал людей работать за призрачные цели и

Что значит давить?
В описанной вами ситуации, вы единственный человек с понятной мотивацией. Вопрос к дургим «действующим лицам».

но тут так не получится. Это же бизнесс не для дураков и люди все понимают.

Угу особенно КуА с челенджем и БА со строчкой в резюме.

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

Не факт что легко. Но эта фраза как-то напоминает «Лучше быть багатым и здоровым, чем бедным и больным».

Вы думаете в GlobalLogic, DataArt или еще где-то нет подобных проектов ?

Я знаю что они есть и не только в тех компаниях что мы тут упоминали. И это очень грустно. Грустно потому что индустрии от таких проектов никакой пользы нет. Явный тому пример, советы из статьи: частично очевидные, частично противоречивые, частично утопичные. (Плодить еще 2 десятка комментов и их обсуждать у меня нет желание, если что)

Мотивация грин-картой у всех, кто приехал сюда по L1, O1, J1, H1B итд. Не важно, делал бы я этот проект или другой, мотивация все равно бы осталась. Тут вопрос в другом, что я уйти не могу. Ты цепью привязан к работодателю и ругаться тебе просто не имеет смысла, да и особо не получается. Все это уже много раз обсудили на DOU.

QA предлагали релоцироватся, так как реально сильный и отличные парень. BA было тяжело, так как писать приходилось документацию по проекту, который мы не знаем, и не могли ей иногда даже рассказать, как все работает. Я же говорю — ей пришлось очень тяжело. И да — в таком проекте мало мотивации, но хоть из этого надо извлекать какую-то пользу.

Не факт что легко. Но эта фраза как-то напоминает «Лучше быть багатым и здоровым, чем бедным и больным».

Да неужели. Вот вы бы куда пошли работать, на проект, что я описал, или в Google с новыми технологиями и без особых напрягов. А людей куда будет лучше искать?

Я знаю что они есть и не только в тех компаниях что мы тут упоминали. И это очень грустно. Грустно потому что индустрии от таких проектов никакой пользы нет.

Вы думаете у нас в Украине не пишут гомно-кода? Или думаете все такие проекты существуют, только где-то там у буржуев ? Да, такие проекты есть и да, ребята взяли и из гомна сделали более нормальный легаси-проект, который приносит деньги и не создает клиенту головной боли. И вот когда у клиента возникнет вопрос куда идти делать новый проект — куда он пойдет ? Он может пойти к нам в Украину, а может в Индию, а может в Польшу, а может еще куда-то.

Явный тому пример, советы из статьи: частично очевидные, частично противоречивые, частично утопичные.

Дайте свои советы, напишите свой проект, опишите свой опыт. Я же сказал, что в статье не будет крутых, но очевидных вещей. Ты просто берешь, пробуешь одно, пробуешь другое, пробуешь третье, четвертое, пятое, шестое, до тех пор пока не решишь проблему.

Не важно, делал бы я этот проект или другой, мотивация все равно бы осталась.
Можно наверно было стать в позу и не делать, но тогда я все равно поехал бы домой. При переезде в другой штат — это также задержки в процессе оформления грин-карты.

Ок.

Да неужели. Вот вы бы куда пошли работать, на проект, что я описал, или в Google с новыми технологиями и без особых напрягов. А людей куда будет лучше искать?

Лучше? Если вы про проще, то уж явно не на описанный вами проект, об этом и была фраза про бедного и больного.

Вы думаете у нас в Украине не пишут гомно-кода?

Пишут. И это попод затаскивать больше гуана?

И вот когда у клиента возникнет вопрос куда идти делать новый проект — куда он пойдет ?

В порядке важности:
1) Туда куда ему посоветуют консалтеры (откуда сейлсы сработают быстрее)
2) Туда куда разрешит регулятор (если это энтерпрайз)
3) Туда где будет дешевле
4) Туда где возьмутся за его гуано систему (пока что мы здесь)

Грустно потому что индустрии от таких проектов никакой пользы нет.

что вы имеете в виду под этой расплывчатой формулировкой?

что вы имеете в виду под этой расплывчатой формулировкой?

Если очень кратко:
В лучшем случае — 7 ИТ-специалистов про...ралы часть своей жизни
В случае похуже — условный «кастомер» теперь знает кто будет разгребать его гуано. Тут надо понимать что это он про гуано знает, а вот куда отдавать дорогие и технически сложные проекты — это ему еще надо решить.

зато теперь у них есть в портфолио дорогой кейс и все знают, что эта контора разгребет любое говно

и рано или поздно их попросят это усовершенствовать и переписать

и хрен теперь заказчик просто так и дешево свалит от них к другому исполнителю

в истории украинских галер сотни таких историй. именно за умение разгрести говно и потом за умение из него построить что-то стоящее у наших и заказывают

и рано или поздно их попросят это усовершенствовать и переписать

Вот вы сейчас мне систему со скидкой 90%, а потом когда-то я вам отдам дорого проект. Так что ли? :)

именно за умение разгрести говно и потом за умение из него построить что-то стоящее у наших и заказывают

Угу, уверен что сейлсы и цены тут совсем не причем.

даже этот текст местами похож на рекламу епам-а.

«разребем любое уг. дорого. цинично.»

еще б перевести на английский и понеслась

Я не пытался сделать рекламу компании, в которой работаю — но я хотел подчеркнуть ребят, потому что они по сути 90% успеха это проекта.

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

«вы ж не хотите, чтоб оно упало? а они уже ж как мы и хотели сделали вот ту кнопку круглой...»

кто вам вообще сказал, что они взяли дешево за проект?

автор сказал ))

2.Был рост по ЗП, но не могу сказать, что он был существенным — особенно в США.
что-то стоящее у наших и заказывают

Например?

Спасибо. Честно сказать я сомневался, когда ее писал. Думал не пойдет, надо что-то космическое, а тут один треш.

Це краще, чим «космические корабли, бороздящие просторы Большого театра» :)

Зимой 2016, когда мы с женой поехали в круиз на Карибы, по возвращении я приехал в офис хорошо отдохнувший, без особого желания напрягаться после отпуска.
что система, доход которой 35 миллионов долларов в год, не может быть плохой
На сегодняшний момент проект вошел в стабильную стадию, продукт стабильно генерирует более $45 млн прибыли ежегодно и масштабирован на 35 серверах.

Внимание, вопрос: Сколько из 10 млн прибыли получили 7 человек, указанных в статье как герои?

+ 200$ к зп, если «комитет» пройдут :)

это ж клиент получил, а не ЕРАМ

Мы же вендор для клиента, поэтому мы бы все равно ничего не получили — понятно, что менеджмент получил свою плюшки. Да и мы как вендор тоже стали надежным партнером для компании. Компания платила бонусы ребятам.

Приблизно стільки ж, скільки б вони покрили зі своєї з/п якщо проект провалився б і приносив би на 10 мільйонів менше

Это называется отчуждение прибавочной стоимости.

Мабуть «Скільки процентів від ...» ;)

клиент решил отказаться от нового UI, сохранить сервера на Windows Server 2003 и попытаться мигрировать существующую систему в новый data-центр.

так ви таки дописали йому фронтенд на HAHTSite і VB6 ?
однако, клієнт дивний — хто ж це потім підтримувати буде. чи ви довічний контракт на саппорт підписали, кров’ю ? :)

Да, все дописали, разобрались с HAHTSite, разобрались с VB6.0, дописали новую функциональность, разработали им билд процесс. Сейчас все ушло на стадию поддержки и они заморозили внесении каких-либо изменений. Сейчас проект мигрирует на Java и Cloud Foundry.

Хм. Вы мигрируете на Cloud Foundry и переписываете .NET/ COM/DCOM на Java ? Это ж титанический труд!

Хм. Вы мигрируете на Cloud Foundry и переписываете .NET/ COM/DCOM на Java ? Это ж титанический труд!

Вот у нас тут МинИнфраструктуры хочет строить ХайпУА (Хиперлуп такой). Это ж титанический труд! ... Сколько бабла нужно ... освоить!

Не сравнивайте распил бабла и работу по миграции на иной стек — распил это народная традиция :)

Не сравнивайте распил бабла и работу по миграции на иной стек — распил это народная традиция :)

1) Миграция на новый стек — это и есть распил бабла. Проблема в том что скоуп такой миграции не ограничен, точнее ограничен годовым бюджетом, как и ХайпУА.
2) Народная? Скорее международная, на западе пилят куда больше, когда возможность появляется.

распил это народная традиция :)

Вот за американский народ щас абыдна была...

ЗЫ: а уж за индусский... ))

Через год мне дошло от топ-менеджмента, что если бы они знали, что мы проект доведем до такой стабильной стадии, они бы его не мигрировали. Возможно не делали бы это сейчас, но тогда все думали, что ситуация просто критическая и нужно что-то делать. И в целом это стратегия компании мигрировать все на Pivotal Cloud Foundry.

Підписатись на коментарі