Ну вот! Наконец-то первые проблески интеллекта. Так глядишь и правда человеком станет. (Это, кстати, почти не шутка. Напишу как-нибудь почему)

Стоимость обслуживания. Неочевидное

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

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

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

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

Не заполнить контентом

У Ильи Бирмана вышел любопытный пост про кнопку «Стать клиентом». Вкратце он про то, что кнопка «Стать клиентом» ничего не значит. Если написать «Записаться на шиномонтаж», «Купить подписку», то будет понятнее.

В ЦМСках и ЦРМках есть похожая проблема. Если вы видели бэкофис-интерфейсы условного Битрикса, то там, конечно же есть всякие страницы, инфоблоки, виджеты и прочее-прочее-прочее. И всё это надо мучительно заполнять контентом. А хотелось бы добавлять товары, создавать рубрики каталога, писать статьи, создавать подборки и делать кучу разных полезных вещей ещё. А не страдать об формы, которые никакого отношения к задачам сайта не имеют.

Как вы наверное поняли, это продолжение вчерашней мысли про бэкофис.

Главный секрет успеха любого проекта

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

В проблеме сколько угодно может быть виноват условный Вася, а Маша не прислала вам письмо вовремя, Жира забанила ваш аккаунт потому что санкции, новая версия библиотеки сломала сборку, бессовестный менеджер постоянно просил решить задачи АСАП, задолбали правки и т.д.

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

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

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

Феномен Джобса

Чем дольше Эпл живёт без Джобса, тем очевиднее, что мы понимаем ситуацию наоборот. У многих разработчиков и особенно дизайнеров какие-то завышенные ожидания от их продукции. Кажется, что это связано с тем, что Стив Джобс (создатель первого Айфона на минуточку) появился в их жизни в период их пубертата.

На самом деле Эпл всегда была, есть и будет обычной корпорацией, как Гугл, Амазон, Майкрософт, Фейсбук, Самсунг, а работают там такие же люди, как и во всей Айтишечке. На Ютубе (организация финансируется Гуглом) миллиард видосов про то, как успешно пройти собеседование в компанию, которая отбирает только лучших специалистов в мире™.

Стив Джобс же обладал минимальным набором качеств эффективного капиталиста:
1. Умел считать деньги и время (Ну ладно, не всегда умел, но когда его первый раз выперли Эпл, пришлось понять, что деньги компании не бесконечные и тоже научиться их считать)
2. Умел продавать свои идеи инвесторам и исполнителям
3. Выжимать всё из людей и заставлять их делать как ему нужно
4. Был беспринципным засранцем

История, которая прекрасно иллюстрирует все четрыре пункта:

В начале 1975 года Джобс вернулся в Atari. Тогда шла доработка игры Breakout и была объявлена премия за оптимизацию схемы игры в размере 100 долларов за каждый исключенный из схемы чип. Джобс вызвался взяться за эту работу, но так как плохо разбирался в разработке электронных схем, вынужден был обратиться к Возняку, работавшему тогда в Hewlett-Packard. Дополнительная сложность заключалась в сроках — Джобс заявил, что работу нужно было выполнить за 4 дня. На разработку такой схемы обычно требуется несколько месяцев, но Джобс смог убедить Возняка, что тот справится за 4 дня.

Возняк практически не спал четверо суток, днём работая на основной работе, но выполнил задание, разработав за отведённое время схему игры. При этом, к большому удивлению инженеров Atari, он использовал всего 45 чипов (подобные схемы тогда содержали 130—170 чипов, а наиболее удачно разработанные — 70—100 чипов). За эту работу Джобс передал Возняку чек на 350 долларов. Однако позднее выяснилось, что Джобс обманул своего партнёра, сообщив, что в Atari ему заплатили только 700 долларов. Джобс умолчал об объявленной премии в 100 долларов за каждый сэкономленный чип, которая на самом деле в сумме составила 5000 долларов. Получалось, что эту премию Джобс полностью присвоил себе. Кроме того, четырёхдневный срок Джобс тоже выдумал, потому что хотел успеть на ферму Фридланда к сбору урожая яблок и торопился на самолёт. Получив деньги, он бросил работу в Atari.

И только после всего этого Джобс верил в то, что может изменить мир. Только. После. Этого. Изменить мир и на этом заработать. А как иначе? Вокруг нас сотни тысяч людей, которые знают как улучшить что угодно, без шуток, но никогда не пытались посчитать экономику этого улучшения. И если спросить у них: «чувак, окей, отличная идея, давай пустим пять твоих следующих годовых премий на это?», нетрудно догадаться, что услышишь в ответ.

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

Поэтому, если вам уже не 18-22 года, нужно завязывать грезить по Эпл и принять мир с его капиталистическим устройством и разобраться, как и почему внедряются улучшения при капитализме. Тогда вам станет понятно, почему на проблему, которая обозначена на картинке всем наплевать, и что можно с этим сделать.

Я попробую рассказать вам об этом в следующем посте.

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

Добрый день! Прекрасный вопрос!

Смена ЛПР или даже аккаунт-менеджера со стороны клиента — это вообще одна из ключевых болей подрядчиков. Ситуацию можно рассмотреть с многих углов, но я постараюсь дать вам конкретный совет:

Проведите повторную пусконаладку

Думаю, что когда вы начинали работать с вашим клиентом, то первые две-три итерации у вас были проблемы, которые как-то разрешали, вырабатывали протоколы, которые (надеюсь) фиксировали в виде скриптов или документов. Со временем вы начали понимать друг-друга с полуслова и механизм стал работать практически без сбоев. То есть вы пусконаладили все процессы.

Вот возьмите весь этот опыт, назначьте встречу с новым менеджером, и пройдитесь по всем вопросам подробно и участливо.
Разберите ситуации на примерах.
Если вы обмениваетесь каким-то данными/выгрузками, то проведите внеплановый тестовый обмен.
Покажите как вы ставите и принимаете задачи.
Убедитесь, что менеджер добавлен во все ЦРМки, ЦМСки, Хелпдески и прочие важные системы.

Даже если вам кажется, что клиент должен был сам сделать это всё, не факт, что он это сделал. Чем больше компания, с которой вы работаете, тем выше риски, что человеку просто отгрузили проект, а предыдущий человек ушёл на повышение или в другую компанию и у него сейчас примерно такая же история «Я НИЧЕГО НЕ ПОНИМАЮ».

А если вы работаете с корпорацией, то в 99% случаев виноваты будете вы. С этим нет смысла бороться, проще разработать протоколы дэмедж-контроля и следовать им в таких случаях.

При смене ЛПР или аккаунта у клиента дэмедж-контроль — это проактивный онбординг нового человека в проект. Так вы прикроете задницу и себе и ему и не будете в аврале тушить пожары, когда из-за непонимания ситуации нужные данные не будут загружены в базу, а завтра уже старт проекта.

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

Как программисты-технократы увеличивают стоимость поддержки продукта

К нам пришёл проект на поддержку, который построен вокруг получения и обработки больших массивов данных из разных источников. Проект написан на Ларавеле (это такая болванка того, чтобы быстро и понятно запускать веб-сервисы), всё чистенько, аккуратно, по гайдлайнам, архитектурные решения все по делу. С точки зрения программирования всё хорошо. Но при этом каждый день приходят по 10 писем от пользователей, что не работает то, не грузится сё, непонятно тут, непонятно там. При этом пользователей у проекта не сказать, что много. То есть в процентном соотношении большое количество пользователей страдают.

Но как же так?

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

Возьмём простой пример. Есть в системе загрузка экселевского файла: пользователь загружает файл с шестью столбцами с определёнными заголовками, файл обрабатывается, данные появляются в табличке на сайте. Очень простая история. Что же тут может пойти не так?

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

А ещё она не обрабатывает файлы, если файл с таким именем уже был загружен ранее.

И делает это МОЛЧА. То есть никакого лога, никакой обратной связи пользователю по результатам обработки, ничего! Просто пропускает строки.

И вот пользователь, значит, загрузил файл, сидит ждёт данные. А их нет или есть, но не все. Что он делает дальше? Правильно пишет обычное письмо: «Я гружу на ваш портал данные, у меня ничего не грузится, что делать?» Не питайте иллюзий, это типовое обращение в поддержку. И вот оператор поддержки будет по крупицам вытаскивать хоть какую-то информацию. И это будет цепочка из 20 писем. Пользователь будет раздражаться, что вместо решения проблемы, его просят какие-то скриншоты отправлять, файлы присылать и вот эти вот все типовые издевательства.

Стоимость такой переписке в человекочасах колоссальная!

А все потому что программист-технократ не понимает, что пользователи сделают всё не идеально:
— Прочитают инструкцию и поймут её не так
— Будут грузить файлы с 5, 7, 10 столбцами
— Будут грузить не данные, а какую-то чушь
— Будут грузить не эксельки а цсвшки
— Ещё как-то развлекут систему

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

А в реальности пользователь сидит в шумном офисе, ему постоянно пишут в телегу, в таск-трекере и так миллион задач, а тут ещё начальник эти грёбаные файлы попросил грузить, 1С-ники обещали автоматизировать, но у них тоже задач дохера, в базе тоже чёрти-что, АААА, скорее бы пятница.

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

По горячим следам

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

А иначе это какой-то GPT-программист, который умеет только ТЗ в код переводить. Ценность такого человека сомнительная.

Ладно, вот вам отличная актуальная рабочая шутейка:

— Слыш, ты в интернете только такой смелый? Да я тебе глаз на жопу натяну в реале!
— Да? Ну давай! Приезжай!
— Приеду!
— Приедешь?!
— Приеду!
— Когда? Буду ждать!
— У тебя во вторник и четверг во второй половине дня слоты есть?

Обрабатываем ошибки правильно

Ранее, я писал, что обрабатывать ошибки надо правильно. Наши разработчики пофиксили проблему

Дано
нужно принять CSV-файл и загрузить данные из него в базу.

Как было
Файл загружался, метод загрузки возвращал «Accepted for handle», далее стартовала задача, проходила по всему файлу построчно, выкидывала строки, если в них не 6 столбцов, остальные загружала в базу.

    while ($file->valid()) {
      $data = $file->fgetcsv(';');
      if (!is_array($data) || count($data) !== 6) {
        continue;
      }
    }

Делала это молча, отчёта о результате работы не было. Разработчики на другой стороне не понимали, почему данные не загружаются или загружаются частично. Это вызывало конфликты и многонедельные переписки с 20 людьми в копии.

Никуда не годится!

Как стало
Реализовали проверку данных сразу в процессе загрузки и возврат ошибок в виде JSON-объекта. Разделили метод загрузки, на два: один просто проверяет файл, а второй проверяет и загружает в базу. Первый нужен, чтобы пробовать загружать, исправлять и пробовать ещё раз. То есть для разработки. Второй для реальной загрузки. Самый сок этой работы именно в обработке ошибок. О ней подробнее.

Чтобы сделать всё правильно, определимся с тем, как мы реагируем на ошибки. В информационных системах есть два подхода. Первый — когда мы находим ошибки, стараемся их поправить и только в самых крайних случаях просим у пользователя помощи. Так, например, устроены парсеры HTML в браузерах.
Второй подход — найти все ошибки и показать их пользователю, не пытаться ничего исправлять.

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

О загрузке CSV мы уже знаем очень много, поэтому есть две типовые проблемы: кодировка и разделители. Они происходят из того, что Microsoft Excel по умолчанию разделяет значения в файле, который имеет тип *значения разделённые запятой* точкой с запятой. А ещё русская версия экселя сохраняет CSV в кодировке Windows-1251. Да, в 2024 году! Да, последняя версия тоже! Думаю, что это уже скорее для обратной совместимости.

В нашей системе, мы имеем гибрид. Она принимает файлы с разделителем ;, но при этом в кодировке UTF-8. Почему так мне не ведомо, но переделать пока нет возможности, потому что система уже запущена и работает. Уже есть много клиентов и каждый день подключаются новые.

Тезисы для самопроверки
1. Находим все ошибки, но не исправляем их
2. Даём разработчику максимум информации для устранения ошибок
3. Все данные должны быть указаны, никаких значений по-умолчанию

Соответственно, делаем проверку на кодировку:

  "errors": [
    {
      "code": "invalid_encoding",
      "message": "Неправильная кодировка файла"
    }
 ],

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

  "errors": [
    {
      "code": "invalid_encoding",
      "message": "Файл должен быть в кодировке UTF-8, текущая кодировка: Windows-1251"
    }
 ],

Вот! Другое дело! Теперь понятно, чего мы ждём.

⬇️⬇️⬇️

⬆️⬆️⬆️
Далее переходим к содержимому файла. Проверяем структуру. Заголовок и значения. Заголовок файла нам ни зачем не нужен, но так как мы хотим, чтобы разработчик сделал работу ответственно, то формально требуем его наличия:

  "errors": [
    {
      "code": "missing_header",
      "message": "В файле отсутствует заголовок"
    }
 ],

Что-то забыли... Помочь разработчику понять, как исправить проблему. Добавим полезную информацию:

  "errors": [
    {
      "code": "missing_header",
      "message": "Нет заголовка в файле. Убедитесь, что первая строка в загружаемом файле вот такая: article;subject;date;quantity;source;address"
    }
 ],

Теперь проверим количество столбцов в строке:

  "errors": [
    {
      "code": "missing_header",
      "message": "Неверное количество значений в строке"
    }
  ],

И опять. В какой строке? Каких значений? Дополним вывод

  "errors": [
    {
      "code": "invalid_row",
      "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа",
      "row": 2,
      "content": [
        "24422",
        "Товар 1",
        "2024-06-30",
        "1",
        "any",
        "",
        ""
      ]
    }
  ],

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

  "errors": [
    {
      "code": "invalid_row",
      "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа",
      "row": 2,
      "content": [
        "24422,\"Товар 1\",\"2024-06-30\",\"1\",\"any\",\"\","
      ]
    }
  ]

Теперь про значения по-умолчанию. Одним из значений в строке должен быть адрес. Но может получиться так, что адреса нет. В таком случае мы могли бы принимать пустую строку. Но мы этого не сделаем, так как хотим, чтобы разработчик сделал работу добросовестно и сам отработал такие ситуации в своих данных. Поэтому при пустом адресе мы сообщаем такое:

  "errors": [
    {
      "code": "empty_address",
      "message": "Пустой адрес. Если у торговой точки нет адреса, то передавайте строку «Без адреса»",
      "row": 2
    }
  ],

В сообщении сразу подсказка и номер строки с ошибкой.

Всего ошибок около 30, я показал вам самые интересные случаи.

Обрабатывайте ошибки правильно, пересылайте своим разработчикам, всем чмоки!

Медиаинвестиции

Вам покажется, что пост про политику, но он про то, как эффективно работать в Ай-Ти и не только

Не перестаю удивляться количеству людей, которые хотят изменений в России путём свержений/революций, отмены государства и прочего анкапа. Они собираются в могучие кучки в фейсбуке, телеге, твитере и распространяют по интернету эту ересь. При этом эти же люди работают в России, получают зарплату, всякие социальные ништяки и прочие блага развитой страны. Это такой запредельный диссонанс, что, кажется, надо объяснить, почему так вести себя невыгодно.

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

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

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

Айтишник — новый юрист

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

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

В любой современной компании, которая что-то делает в интернете невозможно обойтись без айтишника. Кто вообще будет с этим зоопарком взаимодействовать?

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

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

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

Это я уже молчу, что мы, компания «до 50 штатных сотрудников» вынуждены мониторить сервисы компаний, в которых одних разработчиков от 1000.

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

Если вам сейчас хочется написать «А вот мы пользуемся X и у нас 500 лет ничего не ломалось», так 500 лет назад ещё не было недельных спринтов и релизов. которые всё ломают.

Преждевременная корпорация

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

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

Провожу инвентаризацию дел, готовлюсь к 2025 году

Если вы хоть немного застали 90-е в России, то обязательно посмотрите филь Бык с Юрой Борисовым.
До последний трёх минут фильма, вы решительно не будете понимать, зачем я вам рекомендую эту грязь смотреть. Но, поверьте, так надо.

Я на последней минуте не мог сдержать слёзы. Честно. Не помню когда последний раз у меня фильм вызывал такие сильные эмоции.

Сейчас все обсуждают ФЗ-168 о защите русского языка. Но кому, как не нам, айтишникам, знать, как защищать язык по-настоящему.

Даже если твой продукт называется по-русски, то безжалостный ХТТП-протокол скажет тебе Error: Invalid character in header content ["X-Market-Integration"]. Потому что законом за номером РФЦ-2616 в заголовках разрешены только следующие символы
1. Alphanumeric characters: a-z, A-Z, and 0-9
2. The following special characters: _ :;.,\/"'?!(){}[]@<>=-+*#$&`|~^%

И ничего с этим никто делать не будет!

⬆️⬆️⬆️
Или вот

Большие суммы денег, оказывавшиеся в руках человека в силу обстоятельств военного времени, становились серьезным испытанием моральноэтических норм и провоцировали на совершение преступления. Показательный в этом смысле случай произошел 2 октября 1942 г. у железнодорожного полотна на 239 км к ст. Сухиничи (Калужская обл.).

Сержант с тремя красноармейцами обнаружили погреб с советскими деньгами. В погребе было 9 мешков с частично обгоревшими деньгами, сумму можно было определить приблизительно в 2 млн руб. Кроме того, рядом в колодце была насыпана гора разменной монеты. По документам, найденным вместе с деньгами, выяснилось, что деньги брошены в октябре 1941 г. управляющим Брянским отделением Госбанка СССР при эвакуации из Брянска в Калугу. Деньги пролежали весь период оккупации (эта территория была освобождена от немцев в январе 1942 г.).

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

…

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

…

В октябре 1941 г. перед отправкой без нарядов и фондов им было отпущено с базы 3 т масла, 3 т колбасы, 3 000 банок консервов. В пути по приказу начальника эшелона вагон с продуктами был вскрыт, для питания людей было использовано 3 мешка муки, 4 мешка сахара, 1 мешок картофельной муки. Из-за отсутствия контроля и охраны из вагона было похищено хлеба на 1 836 руб. и колбасы на 1 176 руб.

…

Анализ материалов судебных дел показал, что значительная доля хищений совершалась работниками транспорта. Так, за 8 месяцев 1942 г. за хищения было осуждено 1 969 работников транспорта (39 % к общему числу осужденных).

39% Карл!

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

И это всё не смотря на то,что:

Тенденцию усиления репрессивного характера правоприменительной практики демонстрируют статистические данные: за 2-е полугодие 1941 г. из общего числа осужденных (2 389 чел.) было осуждено по закону от 7 августа 1932 г. – 961 чел., а по ст. 162 п.п. «г» и «д» УК – 1 428 чел., и за 2 месяца 1942 г. из общего числа всех осужденных (2 589 чел.), осуждено по закону от 7 августа 1932 г. – 1 322 чел., по ст. 162 УК – 1 267 чел. Возросло число осужденных к высшей мере наказания: если за второе полугодие 1941 г. к высшей мере наказания приговорили 228 человек и к лишению свободы на 10 лет – 872 чел., то за два месяца 1942 г. к высшей мере наказания было приговорено 188 чел. и к лишению свободы – 1 164 человек.

Можете сами походить по ссылкам на смежным документы и поофигевать от души.
На минуточку, СССР вступил в экзистенциальную войну, войну на выживание. И при живом-то Сталине и критически важной для страны задачи творилось такое! И низкий поклон тем, кто, несмотря на этот вопиющий ужас с задачей эвакуации справился.
⬇️⬇️⬇️

⬆️⬆️⬆️
Русская модель управления на самом деле устроена так: пока жареный петух в жопу не клюнет определённый континент лениво и относительно аккуратно ворует деньги у государства. А когда наступает аврал и всё надо срочно и ради блага ещё можно без лишней бюрократии действовать, на сцену выходят Темщики! Эти ребята знают, что в таких условиях, можно замутить какую-нибудь Смуту, наворовать как не в себя и свалить куда-то, где их не заденут последствия их же действий. А захватит ли Германия СССР их не беспокоит. Они уже в Аргентине в своём особняке с выходом на пляж, мутят новую темку. Да, кого-то посадят, кого-то расстреляют, но и там тоже люди. Вдруг может получиться поделиться.

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