Отвага и отвага: как мы выбирались из полного абзаца с неработающей ERP на 39 производствах
39 наших площадок вагоноремонтных депо перешло из холдинга РЖД в Группу ОМК. Нам надо было за год перейти на новую систему управления производством, потому что оставаться в ИТ-ландшафте железных дорог было нельзя. Мы выбрали 1С ERP и восемь месяцев от ТЗ до дедлайна вместе с подрядчиком героически внедряли первую её очередь.
Итогом стало:
- Прошлая система отключена.
- Новая система запущена в фактической альфе, функционал — около 40%, и она не работала.
- Пользователи из депо готовы поднять нас на вилы, сжечь и растоптать. И повторить.
- Многие данные вбиваются без проверок сотрудниками цехов, то есть в первичке — настоящий ад. Чтобы вы понимали, какой: чуть не влетели на 29 миллиардов рублей, потому что кто-то забил серийный номер в стоимость.
- Железо не тянет всё это на местах, в том числе и серверы.
- Каналы тоже всё это не тянут. Между двумя полями ввода на одной форме — от 30 секунд до разрыва и вбивания всех данных заново.
- Поскольку мы успели собрать ТЗ только с центрального офиса, от региональных депо появляются всё новые и новые требования.
- Мало кто понимает, как это всё работает, а надо править прямо в бою.
- Вторая-третья линии поддержки (пять человек нашего ИТ-отдела) не понимают мастеров, первой линии вообще нет, и ресурса нет, чтобы её создать. Хвост обращений — несколько тысяч неотвеченных тикетов.
- Ковид и карантины.
- Бухгалтерия немного нервничает.
А дальше — обычная для вагоноремонтного депо ситуация: нужно любыми доступными средствами выполнить задачу. Выбора нет!
Собственно, продолжаю рассказывать, что именно мы сделали.
Подробно про то, как мы попали в эту ситуацию, — вот тут в первом посте.
Команда
Во-первых, за год мы нашли новых людей, и от пяти человек изначального отдела нас стало чуть больше. Сначала по ролям у нас были руководитель ИТ-отдела, проект-менеджер (он же — аналитик), два разработчика, архитектор. Добавилось шесть человек функциональщиков для работы прямо конкретно с беклогом. Они понадобились потому, что команду консультантов наши мастера цехов просто не понимали и сообщали, что они говорят на каком-то «курином языке». В целом это известная проблема производств: наши мастера не были готовы строить диалог с людьми, которые ось не щупали.
На первой линии накопилось несколько тысяч неотвеченных тикетов. Официальный SLA был от недели до никогда. Люди почему-то смекнули, что никто не отвечает, перестали обращаться и стали вместо поддержки писать «матерные» письма руководству.
Поскольку очень многие документы проводились к этому моменту методом брутфорса ударами по клавиатуре (я сейчас не шучу), в исходных данных было много ошибок. Мы решили ввести в дело шесть человек из числа функциональщиков, которые били бы по ночам тех, кто неправильно вбивает помогали бы распутывать этот хаос, а подрядчик № 2 дал инструмент и методологию закрытия.
Людей-функциональщиков мы взяли максимально близко от функций производства. То есть закупщика из регионального депо, одного мастера, одного экономиста при депо и так далее, и всех — из разных городов: Ульяновска, Красноуфимска, Кургана, Арзамаса. Собрали их и сообщили, что они завязывают со своими прошлыми делами и начинают разбирать всё это безобразие, пока хаос не станет чуть меньше. Ну то есть они будут жить со всеми депо. Сразу скажу, что это было одним из лучших решений по исправлению ситуации. Когда мастер подошёл к функциональщику и попытался что-то доказать, его ждал далеко не «куриный язык», а разборчивый человекочитаемый мат с интуитивно понятным интерфейсом. Взаимопонимание сразу наладилось, потом прошло несколько циклов пятничного слаживания команд. Но эффективность проекта от этого сильно выросла. В городах, где таких функциональщиков не было и подходить было не к кому, они с этой командой общались просто по телефону.
Команда функциональщиков «data quality» не только исправляла ошибки, но и искала корневые причины этих ошибок, то есть ходила к конкретным людям и объясняла, как правильно делать такую же операцию дальше.
Главной проблемой было то, что типовая ERP не пытается контролировать в моменте логику цепочки документов, давая очень много свободы пользователям (очевидно, это заточено на то, что пользователь — бухгалтер, экономист, закупщик или продажник с пониманием процесса). А у нас большая часть пользователей — мастера и операторы. Мастеру пофиг на списание, заказ, остатки, ему важно закончить работу с колёсной парой и приступить к следующей. Поэтому, если в поля вбить что-то, что поможет закрыть окно, — это подходит.
Жара добавляло то, что по всем процессам после входа в ОМК у нас творились изменения. Всё было в движении — от кадров до инфраструктуры ИТ. Например, за время проекта сменилось огромное количество функциональных заказчиков ключевых блоков. Только директоров по экономике было четверо. Последнего мы называли v4_final.
Взаимодействие с конечными пользователями
Это была самая большая боль этого проекта. Мало того, что у нас всё пошло не так, но нас со всех сторон ещё и материли. В целом спасибо, что только материли, потому что в депо много тяжёлых штук.
Основной плач был про то, что: «Мы не можем ремонтировать вагоны, потому что зачем сотрудникам бухпрограмма?» Напомню, что раньше было две софтины: одна — с привычным и понятным интерфейсом, где мастера в два клика обозначали свои операции. Она была максимально заточена под конкретное производство и всё дописывала сама, собирая только необходимый минимум данных. Дальше мастер видел готовый документ и мог его поправить, если что-то в умолчаниях было не так. Вторая — SAP ERP — касалась только учёта. Теперь на базе 1С ERP мы делали сразу всё в одном месте. А как я уже говорил, 1С сделана для усреднённого человека, то есть ни для кого конкретного. Эта универсальность в перспективе означала, что дальше можно будет очень сильно вырасти в эффективности и всё кастомизировать, но здесь и сейчас это были неудобные незнакомые интерфейсы, куча лишних диалоговых окон, повторяющиеся тупые запросы и лишние с точки зрения людей в депо операции и документы.
И сделать с этим быстро ничего нельзя.
Здесь нас выручил директор по экономике — тот самый v4_final. Это было, пожалуй, самым грамотным решением проекта, которое я тогда не до конца понимал. Мне казалось, что он собирает лишние совещания, и можно потратить время гораздо лучше. Он сказал, что иногда нужно проводить еженедельные встречи — два или три раза в неделю — и собирать вообще всех ключевых пользователей. То есть итого — около 200 человек из 1 000 пользователей. Собирали огромную видеоконференцию, где спрашивали людей, что у них не так на этой неделе. Показывали какие-то хорошие практики, делились практическим опытом, как обходить баги и как правильно дышать, чтобы всё не рухнуло.
Внезапно оказалось, что «Да-да, мы страдаем», и факельное шествие не детализируется на «А что именно не так?» Не так всё! И вообще вы неправильные и делаете неправильный мёд. Тезисов нет, информации нет. Точнее, конкретные тезисы для занесения в беклог попадались существенно реже ожидаемого. 80% времени занимало то, что я назвал бы ворчанием. Порой громким. Именно это меня смущало во встречах.
Оказалось, что главный эффект — это комната, где можно было покричать, и становилось легче. Люди видели, что у всех так, что с этим надо жить. А потом не появлялось оправданий вроде «Я не знал, меня не спросили, мне не показали». Мы всё у всех спрашивали, всё показывали, всё до всех доводили и из этого потока ловили зёрна здравых идей для доработок.
Дальше мы прошли несколько стадий:
Первая — полное отрицание. Активная часть кричит лозунги по типу »1С — г…о!», «Да эта программа — для пивного ларька!» — мы понимаем, но нужна конкретика, а её тогда не было. Молчаливая часть аудитории мыслит так: «Сказали делать — ну, значит, надо… Будем через боль и слёзы пользователей вносить данные… Молчать, не подсвечивать проблемные зоны». И те, кто понимает, зачем всё это, тащат свои идеи для улучшений. Из двух пилотных депо одно оказалось строго против программы для пивного ларька, а второе как раз зацепилось за цель сделать лучше и активно продвигало идеи, которые меняли процесс.
В общем, симптом первого этапа: «Ура! У них ничего не получится!»
Вторая была уже такой: «Ура! Всё плохо, и у них ничего не получается!» Это когда мы уже видели, что ситуация под контролем.
Третья: «Да, работает, но всё равно очень плохо работает и лучше не станет».
Четвёртая стадия, которая тоже уже пройдена: «Да, работает, вроде нормально, но мы уверены, что это ненадолго!»
Сейчас у нас уже пятая: стабильное развитие, и мы даже иногда слышим благодарные отзывы на новый функционал, что он стал ближе к народу и для народа.
Забегая вперёд, скажу, что сейчас директор по экономике, который провёл эту психологическую операцию, стал управляющим директором. Полностью заслуженно!
Фекан мамонта
Техника в депо на ряде рабочих мест не удовлетворяла требованиям. Это нивелировалось тем, что везде стояли тонкие клиенты и локальные сервера. В архитектуре — звезда, где в центре — ЦОД, а по лучам — депо, локальные расчёты не предполагались. Но при этом нужно было уметь работать с веб-компонентами 1С, а они сделаны не для… Короче, они плохо совместимы с IE 6.0 и Pentium II MMX 233. Ладно, я утрирую, такой мы нашли только один, но было много машин с 1 Гб оперативной памяти при том, что для работы браузера надо хотя бы два.
Серверный парк тоже нас подвёл, как я уже говорил в прошлой части. Мы-то закупились по минимальным системным требованиям, а оказалось, что всё чуточку не так. Минимальные — это когда оно в принципе запускается, но все страдают. В смысле больше, чем обычно. Мы привыкли к мощностям РЖД, где был ЦОД неизвестного нам объёма, но там работало три огромных вагоноремонтных предприятия, и ни у кого никогда не было проблем. Системе — годы от момента внедрения.
Проблемы у нас появились сразу, когда вместо 50 человек подключились 500. А надо было 1 000.
Четыре разрыва
Каналы тоже не были готовы к такой нагрузке. Как оказалось. Про то, что нам понадобится другая утилизация и что надо будет уходить с инфраструктуры РЖД, мы знали давно и успели подготовиться. Но мы подготовились организационно, то есть убедились, что каналы до всех площадок (составляющих нашу частную сеть) чисто наши и при смене холдинга договоры с провайдерами не пострадают.
Засада была в том, что мы не видели проблем, т. к. на каналы никто никогда не жаловался. Потому что одна из исторических систем (как раз важная для производства) была построена на основе распределённой БД, и при падении канала в депо работа продолжалась локально.
Весь прикладной софт тоже учитывал особенности каналов и мог работать асинхронно, то есть не падал при пропадании связи на несколько секунд на радиорелейном соединении. А радиорелеек до территории депо у нас было много где. Условно подул ветер или пошёл снег — и вот начинаются кратковременные проблемы, которых мы просто не видели из-за отличий сетевой обработки на прикладном уровне.
Когда мы сменили архитектуру, у нас сразу выросли количество одновременных подключений и требования к каналам. 1С требует синхронной работы, то есть на отправленный пакет сразу должен прийти ответ. Если канал отваливается, то веб-компонент показывает ошибку. Другими словами, любая задержка вела к тому, что надо вернуться в начало документа и заполнять его заново.
Веб-компоненты плохо работали с серверными тормозами (а, напомню, они были). При ожидании больше 30 секунд браузер говорил, что сервер долго не отвечает и надо перезагрузить: пользователь в 90% случаев перезагружал, как было предложено. Тонкий клиент работал лучше: он просто никак не показывал, что тормоза — это что-то из ряда вон, просто висел (на экране «крутилось колесико», как нам говорили пользователи).
С каналами у нас была отдельная эпопея, если коротко — многое удалось переделать за несколько месяцев. Ещё пошли в сторону тонких клиентов везде, где можно, и стало постабильнее. Про каналы, пожалуй, стоит рассказать отдельно, но в итоге всё же проблему по большей части победили. В смысле пользователи продолжают страдать, но кто-то привык, кто-то знает, как легче страдать, кто-то страдает меньше, да и общее число страданий уменьшилось где-то втрое.
Что делали
Итак:
- Расширили количество людей на проекте, чтобы можно было не увеличивать долг по отчётности, а уменьшать. ИТ-блоку даже пришлось совместно с HR проводить замеры времени на ввод документов и считать численность операторов, необходимую дополнительно для обеспечения ввода.
- Выделили ту самую «икс-команду» функциональщиков, про которую уже говорили — людей с производства, которые точно знали, что делать, и могли, как спецназ, решать любые вопросы.
- Группа на стороне второй и третьей линий тоже подросла и выполняла задачи взаимодействия с подрядчиком, развития и т. д.
- Сделали эту модель совещаний, когда все ключевые люди были в курсе и не могли потом говорить, что они не знали, им не сообщили и т. п., то есть убедились, что если пользователи не за нас, то хотя бы не будут ставить палки в колёса внедрению (как это часто случается).
- Обновили серверный парк, сильно его расширили. Купили дополнительные СХД и сервер. Продуктивные сервера 1С были переформированы в полноценный кластер (отдельно сервера СУБД, приложений для пользователей, приложений для фоновых заданий, приложений для расчёта себестоимости, лицензирования).
- Ещё докинули мощностей на прод.
- Разобрались с каналами (это отдельная эпопея).
- Занялись парком оборудования пользователей на местах.
Начиная с января 2022 года работа по закрытию периодов уже пошла более-менее штатно. А с апреля 2022-го мы вышли на полностью своевременное закрытие периодов в 1С по утверждённым бизнесом графикам.
Команда «data quality» была передана ИТ-блоку и плавно переформатирована в поддержку первой линии. Смысл был не исправлять ошибки, как они раньше делали, а не допускать их и обучать пользователей.
Пока мы закрывали год с подрядчиком № 2, подрядчик № 1 продолжал работы по второму этапу проекта. Разойтись не решились, так как уже многое было сделано и наработано. Если расходимся, то начинай сначала.
И вот к осени 2022 года мы были готовы переносить новую версию на продуктив.
Первое большое техническое окно мы согласовали на целые выходные — с вечера 21 октября 2022-го (пятницы) до утра понедельника, 24 октября. Запустились, сутки ждали, но реструктуризация базы никак не заканчивалась. Мы поняли, что это что-то бесконечное, и приняли решение, что мы откатываемся назад и идём выяснять причины. Так и завершилась попытка № 1.
За две следующие недели нашли и пофиксили причины, а в начале ноября ушли на вторую итерацию. Новое окно взяли с вечера 4-го по 7 ноября 2022 года. На этот раз мы провели обновление за три бессонные ночи и запустили пользователей.
Конфликт блокировок
С первых же часов после обновления мы столкнулись с новыми проблемами. Как только объём пользователей перевалил критическую массу в 200–300 человек, начались постоянные блокировки по основным таблицам производства. Лаги с привычных 30 секунд в критичных случаях стали достигать минут. В редких ситуациях — часов. Это ухудшалось кучей не столь больших, но от этого не менее значимых проблем по всем остальным блокам.
Конфликты блокировок решаются не очень просто. Точнее, есть очевидные способы вроде правильного индексирования таблиц и добавления новых индексов так, как подсказывает SQL. Это даёт десятки процентов ускорения, но принципиально ситуацию не меняет.
Мы вывели эксперта со стороны подрядчика № 2 и человека с нашей стороны специально под эту задачу. Они начали разбирать каждую блокировку. Берётся тормозящая операция, надо разобраться, что там блокируется и почему. Наиболее очевидное — кто-то блокирует целую таблицу на операцию, хотя ему нужна только небольшая её часть. Но чтобы с этим разобраться, нужно посмотреть, как именно и где 1С решает, что блокировать. По факту это означало, что код многих операций нуждался в уточнении: это что-то вроде рефакторинга пополам с оптимизацией.
С другой стороны, мы знали проблемные отчёты — обычно за большой период. С прошлой системы у людей осталась привычка выгружать вообще все «сырые» данные за период в XLS, а уже затем делать формулами всякие преобразования. Идея, что можно получить агрегат уже из SQL, была для них незнакомой и местами пугающей. В общем, по всей базе они собирали джойн, которым так известен интерфейс 1С, и оставляли его считаться, чтобы получить свои данные. Иногда сборка такого отчёта занимала часы, на которые и блокировались все другие пользователи: они страдали, а работа системы кратно замедлялась. Мы выявляли людей с такими отчётами, били по рукам. Люди плакали, говорили: «Нет, нам нужны данные от момента рождения Вселенной до её тепловой смерти». Просто ограничивали выборку, перенастраивали отчёт.
Далее практически весь 2023 год был посвящён развитию внедрённого функционала и выстраиванию работы на стабильное развитие системы по заявкам на изменение от бизнеса.
С подрядчиком № 1 мы расстались. У него был гештальт по поводу обновления 2022 года. Он его закрыл, провёл несколько месяцев опытно-промышленной эксплуатации, сделал ещё ряд доработок, про которые забыли, и на этом попрощался… Пообещал гарантию, и мы его больше не видели.
С подрядчиком № 2 мы остались, он нам регулярно помогает с заковырками расчёта себестоимости и развитием системы.
Год тестов на продуктиве
Получилось, что некоторое время в начале проекта у нас не было стейджинга, мы каждый раз ловим исключения и ошибки уже на продуктиве.
Так, в феврале 2023 года мы начали запускать функционал по допуску вагонов на пути общего пользования (внешняя ОТК), построили интеграцию, запустили сначала на одном депо и вроде всё отладили. Но когда пошли на тираж по всем депо, выяснилось, что у системы-источника на стороне РЖД многие поля приходят не справочниками, а просто текстами, или даже могут быть не заполнены. Пришлось в очередной раз экстренно делать заплатки, чтобы не остановить работу бизнеса.
Акт допуска — это документ о внешней приёмке из системы РЖД. Его отправляет система-оркестратор. Это не конечная система, а один из шлюзов. Есть несколько источников с разными справочниками. В тестовом депо конкретный приёмщик работал только в одной из этих систем. И работал по шаблонам, которые знал как свои пять пальцев. Он даже неклассифицированные поля заполнял идеально унифицированно, педантично и однообразно. Отладку мы прошли успешно, потом запустились по всей стране. И полетели акты из других систем и с другими классификациями. В любом поле могла прийти не такая информация, которую мы ждали. Мы ожидали однозначного соответствия элементу какого-то справочника. Патчили уже на живых данных. Сначала снизили требования до однозначного нечёткого поиска, потом убрали жёсткие привязки и дали возможность пользователям выбрать то, что они считают правильным. Через выборы пользователей получили базу соответствий, накатили её. Обучили систему на этом, снова включили жёсткие привязки, сейчас стабильно работает.
В следующий раз, запуская функционал обмена данными с РЖД для ремонта деталей, мы уже пошли запускать небольшими группами (по пять–семь депо, начав с одного и длительно обкатав на нём процесс). Благодаря этому запуск прошёл для бизнеса без потрясений, а для нас — без факельных шествий.
И да, про всё это мы параллельно проводили вебинары, и на них из 500 присутствовавших всего несколько человек задавали вопросы, причём парочка с формулировками: «Я, наверное, пропустил…», «Можете повторить?»
Снова обновление, и снова не всё как по маслу
Всё то время, пока шёл проект, мы были на версии 1C ERP 2.5.4, с которой стартовали внедрение. Вендор 1С к этому времени убежал уже очень далеко в новых релизах типовой «коробки». Например, на осень 2023-го из стабильных версий была как минимум 2.5.8, там много всякого нового функционала. 1С ERP развивается вообще семимильными шагами. Обновляться надо с точки зрения поддержки законодательства и всех остальных фишек. И плюс приходит оптимизация по многим алгоритмам.
Первую половину 2023 года мы собирались с мыслями. В середине года несколько месяцев готовили обновление (то есть адаптацию всех наших доработок под новую версию «коробки»), тут как раз пришёлся в тему подрядчик № 2, который остался у нас на поддержке. Он подготовил нам обновление с 2.5.4 на 2.5.6. В этом обновлении для нас не было какого-то особо нового функционала, скорее всякие небольшие фишечки. Но, тем не менее, нужно поддерживать стабильную версию от вендора.
В общем, несколько месяцев мы его готовили и в пятницу 13 октября уже планировали стартовать. Но управляющий директор в последний момент пришёл и сказал: «Баста! Сегодня я вам обновления не дам».
После нескольких итераций согласования удалось выбить новую дату техокна в ночь с 31 октября на 1 ноября 2023 года. Когда мы уже были готовы дёргать рубильник на переключение после поверхностной проверки функционала, то заметили несколько задвоенных объектов и решили потратить ещё час, чтобы разобраться. И не зря! Мы дотаскивали там новый функционал, который был дописан через добавление новых реквизитов. И вот всё то, что мы дописали поверх, вызвало дублирование. Это вызвало бы коррапт базы до степени, что пришлось бы создавать временные таблицы для спасения данных, перекладывать их туда, а потом — обратно. Мы сами отменили обновление.
Далее согласовали ночь с 18 на 19 ноября 2023 года, и вот тогда мы обновились. Это заняло 12 часов, мы запустили пользователей, снова получили блокировки в системе и ряд пользовательских ошибок, которые все выходные героически исправляли.
Ещё одна новая неожиданная проблема — когда этап ЗаписьСформированныхДвижений стал длиться вместо двух-трёх 20–30 часов. Причина — полное отключение функционала параллельной записи в регистр, которое сделал вендор. После нескольких недель уточнений нам удалось зарегистрировать официальную ошибку. Вендор её устранил в тестовой версии 2.5.17, теперь адаптируем её под наш релиз.
Обновление с 2.5.6 на 2.5.7 провели в апреле 2024 года уже на опыте с первой попытки. Конечно, не без проблем после этого (с нашими любимыми блокировками), но уже существенно спокойнее и слаженнее.
Мораль
1С ERP достаточно давно развивается, но изначально поставщиками требований к системе были машиностроение и приборостроение, где чётко известны маршрутная карта и спецификация производства, где что-то берётся, списывается, выпускается и продаётся. А у нас ничего не производится. У нас вагону оказывается услуга, нам нужно те параметры, с которыми вагон приехал на ремонт, восстановить до нормативных.
Этот блок на тот момент не был практически никак реализован, да и сейчас пока далеко не продвинулись.
Поэтому потребовалось доработать систему в части функционала. Плюс есть ещё специфика в учёте вагонов и интеграции с этими системами, а ещё — с использованием серийных деталей со своими номерами с характеристиками. Каждая деталь с точки зрения системы должна трекаться по истории и быть уникальной. Ещё их можно снять с одного вагона, отремонтировать и поставить на другой. Плюс дополнительно — требования от бизнеса: мы хотим видеть себестоимость конкретной работы на конкретном вагоне.
То есть сначала мы дорабатывали всё под себя, потом 1С обновляла базу, мы обновлялись, смотрели, что отвалилось, и снова дорабатывали обратно. У хороших подрядчиков это занимает два-три месяца. Иногда доработки приводили нас в такие дебри, что мы откатывались на базовую версию и терпели её ограничения, потому что код 1С иногда бывает уровня «Не влезай — убьёт!».
Производство всё это время не останавливается.
Но всё же пока что мы изрядно отстали от типовых обновлений, и нам только предстоит их нагнать. Но знаете, я всё равно скажу, что мы довольны проделанной работой. Вот хоть тапками в меня кидайте, хоть напалмом жгите, а мы всё же молодцы!
Ближайшие планы
Вот так выглядит наша система на конец 2023 года:
Сегодня у нас 1 000 одновременно работающих пользователей в пике. Четыре терабайта — объём текущей базы, и единая база с 1 января 2021 года. По 200 гигабайт — ежемесячный прирост базы, сканы документов хранятся во внешней системе. И более полутора миллионов документов вводится ежедневно руками пользователей. Это кроме тех, которые ещё генерятся всякими обработками, распределения и так далее.
Уже готовим обновление на версию 2.5.8. Потом нужны построение процессов автоматического переноса обновлений на продуктив и организация автоматического тестирования. Если получится, то приготовим смузи.
Лучший проект 2022 года
Если вы сейчас читаете всё это, то примерно представляете, как мы себя чувствовали. Когда в 2023 году стало понятно, что мы дотащили всё это и это более-менее работает, мы испытывали удовлетворение только от того, что стало легче, и всё это более-менее закончилось. И тут подрядчик № 2 предложил нам заявиться на премию »1С: Проект года». По нашим внутренним ощущениям на тот момент — можно было заявиться на другое слово, начинающееся на «п», созвучное с «эпик фейл», но никак не «проект года». Но мы кивнули, потому что от нас было ничего не надо.
Через некоторое время нам вдруг начали писать бывшие коллеги с железных дорог и поздравлять с победой. В премии. Мы такие: «А в какой?» Они: «Лучший проекта года». Мы: «Спасибо!» И про себя — что это закончилось. Но всё же было приятно!
А самое смешное во всём этом то, что даже если бы мы знали, что будет происходить и как, мы всё равно ввязались бы в эту историю, потому что у производства была необходимость. Может, с опытом подошли бы по-другому, но в том состоянии, скорее всего, прошли бы примерно тот же путь.
Habrahabr.ru прочитано 2706 раз
