pip install spire.pdf.free

2. Обзор принципа работы

Оба метода корректировки полей, описанные в статье, строятся на единой логике — разница лишь в расчете размеров и параметрах отрисовки:

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

• Уменьшение полей : Сократить размер страницы PDF и обрезать лишние белые края исходной страницы за счет смещения координат отрисовки контента.

Общий алгоритм работы: загрузка исходного PDF → расчет нового размера страницы → перебор страниц с генерацией шаблонов → создание новых страниц и перерисовка содержимого → сохранение нового файла и освобождение ресурсов.

3. Увеличение полей страниц PDF на Python

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

from spire.pdf.common import SizeF
from spire.pdf import PdfDocument
# 1. Загрузка исходного PDF-документа
original_pdf = PdfDocument()
original_pdf.LoadFromFile("sample.pdf")
# 2. Задание собственных размеров добавляемых полей со всех четырех сторон
margin_top = 40
margin_bottom = 40
margin_left = 40
margin_right = 40
# 3. Расчет нового размера страницы по размеру первой страницы (подходит для всех страниц документа)
first_page = original_pdf.Pages[0]
new_page_width = first_page.Size.Width + margin_left + margin_right
new_page_height = first_page.Size.Height + margin_top + margin_bottom
new_page_size = SizeF(new_page_width, new_page_height)
# 4. Создание нового PDF-документа и перерисовка всех страниц
new_pdf = PdfDocument()
for page_idx in range(original_pdf.Pages.Count):
# Генерация шаблона исходной страницы с сохранением всего контента
page_template = original_pdf.Pages[page_idx].CreateTemplate()
# Добавление новой страницы заданного размера
new_page = new_pdf.Pages.Add(new_page_size)
# Отрисовка исходного контента в левом верхнем углу новой страницы, автоматически формируя равномерные пустые поля
page_template.Draw(new_page, 0.0, 0.0)
# 5. Сохранение файла и освобождение ресурсов
new_pdf.SaveToFile("increase_pdf_margins.pdf")
original_pdf.Dispose()
new_pdf.Dispose()
print("Увеличение полей PDF завершено!")

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

Результат работы:

4. Уменьшение полей страниц PDF на Python

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

from spire.pdf.common import SizeF
from spire.pdf import PdfDocument, PdfMargins
# 1. Загрузка исходного PDF-документа
original_pdf = PdfDocument()
original_pdf.LoadFromFile("sample.pdf")
# 2. Задание размеров пустых полей, которые нужно обрезать со всех четырех сторон
reduce_top = 60.0
reduce_bottom = 60.0
reduce_left = 40.0
reduce_right = 40.0
# 3. Расчет нового размера страницы после обрезки полей
first_page = original_pdf.Pages[0]
new_page_width = first_page.Size.Width - reduce_left - reduce_right
new_page_height = first_page.Size.Height - reduce_top - reduce_bottom
new_page_size = SizeF(new_page_width, new_page_height)
# 4. Создание нового PDF-документа, перерисовка и обрезка пустых краев страниц
new_pdf = PdfDocument()
for page_idx in range(original_pdf.Pages.Count):
page_template = original_pdf.Pages[page_idx].CreateTemplate()
# Добавление новой страницы без стандартных полей
new_page = new_pdf.Pages.Add(new_page_size, PdfMargins(0.0))
# Смещение координат отрисовки в противоположную сторону для обрезки исходных белых краев
page_template.Draw(new_page, -reduce_left, -reduce_top)
# 5. Сохранение файла и освобождение ресурсов
new_pdf.SaveToFile("decrease_pdf_margins.pdf")
original_pdf.Dispose()
new_pdf.Dispose()
print("Обрезка полей PDF завершена!")

Основное пояснение : Из размеров страницы вычитается величина обрезаемых пустых отступов, при этом координаты отрисовки контента сдвигаются влево и вверх. Благодаря этому исходные пустые края страницы выходят за границы новой страницы, достигая эффекта обрезки белых полей.

Результат работы:

5. Важные замечания

• Единицы измерения : Все значения полей в коде заданы в стандартных единицах PDF (пунктах). 1 дюйм ≈ 72 пункта; при необходимости значения можно свободно пересчитывать и корректировать.

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

• Освобождение ресурсов : Обязательно вызывайте метод Dispose() для освобождения ресурсов документа, чтобы избежать постепенного переполнения оперативной памяти.

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

6. Итог

С помощью библиотеки Free Spire.PDF for Python можно минимальным и эффективным кодом реализовать ручную настройку полей PDF без использования программ Adobe и сложных алгоритмов парсинга PDF. Два набора кода из статьи покрывают два наиболее распространенных сценария: добавление пустых отступов и обрезка белых краев . Код лаконичный, снабжен полными комментариями и может быть напрямую интегрирован в скрипты автоматизированной обработки документов, офисные утилиты и программы пакетной обработки файлов.

1. Роль (role) — кем «выступает» модель при ответе: редактором, финансовым аналитиком, строгим экзаменатором. Задаёт точку зрения и словарь, с которого модель отвечает.

2. Контекст (context) — вводные, которые нужны, чтобы задача была понятна: кто аудитория, какая ситуация, что уже известно.

3. Задача (task) — что конкретно нужно сделать, сформулированное как действие.

4. Формат ответа — в каком виде должен быть результат: список, таблица, объём, структура.

5. Ограничения и запреты — что нельзя делать или от чего явно нужно воздержаться.

6. Критерии качества — по каким признакам понять, что результат хороший.

7. Примеры (few-shot — «несколько образцов» в промте, показывающих желаемый результат на конкретных случаях).

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

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

Семь частей — это не единственная возможная разбивка (в разных источниках по промт-инжинирингу встречаются схожие, но не идентичные классификации), а рабочий чек-лист, удобный для диагностики. Ценность не в точном числе «7», а в привычке проверять каждую часть по отдельности, а не оценивать промт как единое целое. При итеративной доработке (урок 02-12) эта разбивка особенно полезна: вместо «допиши что-нибудь» можно точно сказать себе — «результат не подошёл по формату» или «не хватило критерия качества» — и поправить именно эту одну часть, не трогая остальные.

Вторая деталь для тех, кто пишет промты для API и системных промтов : роль и часть ограничений часто выносят в системный промт (system prompt), который задаётся отдельно от собственно пользовательского сообщения и держится в силе на протяжении всего диалога, — в отличие от claude.ai, где всё это обычно пишется одним сообщением.

@Claudeprofi_bot

Интересный комплект для конструирования интеллектуального робота-автомобиля. После сборки и программирования на Arduino или Python робот сможет отслеживать линии, обходить препятствия, дистанционно управляться и тд. Имеет контроллер esp32. Стоит такой набор около 4 900 руб. Кому интересно, ссылка на такого робота

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

Прикольный набор для сборки двуного мини-робота, который умеет выполнять различные команды, ходить, танцевать, следить за объектом и тд. Стоит такой около 4 000 руб. Ссылка на него

Ещё она модель интеллектуального робота-автомобиля на обычных колёсах для сборки и программирования. Такой стоит около 3 300 руб. Ссылка на него

Набор для сборки робота на гусеницах и с камерой 3МП. Умеет распознавать препятствия, ездить по линии, воспроизводить мелодии и тд. Стоит такой около 8 700 руб. Ссылка на него

Набор для сборки умного робота-автомобиля Picar-X AI для Raspberry Pi. Стоит такой около 5 800 руб. Ссылка на него

Программируемый мобильный робот с большими глазами. Стоит такой комплект для сборки около 4 600 руб. Ссылка на него

Крутой бионический робот-паук для Arduino. Возможность управления через Wi-Fi. Стоит такой паучок-конструктор около 4 800 руб. Ссылка на него

Интересный умный дом для Arduino. Обучающий набор подойдёт для начинающих программистов и детей от 8 лет. Простой и увлекательный способ освоить основы электроники и программирования. Используя среду ACECode и Arduino IDE, вы можете изучить логику написания кода на C++ и научиться применять его в своих проектах. Стоит такой набор 3 600 руб. Кому интересно, ссылка на него

P.S

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

Также не забывайте добавлять страницу в закладки, чтобы не потерять и заказать понравившиеся наборы роботов позже.

Реклама: ООО "АЛИБАБА.КОМ (РУ)" ИНН: 7703380158

MarkItDown Desktop — это графическое приложение, построенное на официальной библиотеке Microsoft MarkItDown. Оно предоставляет простой интерфейс для преобразования документов Word в файлы Markdown без написания кода.

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

Шаг 1: Скачайте и установите MarkItDown Desktop

Перейдите на страницу релизов GitHub и скачайте последнюю версию MarkItDown Desktop.

После установки откройте приложение.

Шаг 2: Выберите документы Word

Импортируйте свои файлы Word в приложение.

Инструмент поддерживает распространённые форматы Word и может обрабатывать несколько документов пакетами.

Шаг 3: Преобразуйте файлы Word в Markdown

Запустите процесс преобразования и экспортируйте созданные файлы Markdown.

Преобразованный Markdown сохраняет многие важные структуры документа:

• Иерархию заголовков

• Абзацы

• Нумерованные и маркированные списки

• Таблицы

• Гиперссылки

• Полужирный и курсивный текст

Ограничение обработки изображений

Хотя MarkItDown Desktop обнаруживает изображения, он преобразует их в синтаксис изображений Markdown вроде:


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

Поэтому MarkItDown Desktop не рекомендуется для документов, где важны изображения .

Лучшие сценарии использования

Выбирайте MarkItDown Desktop, когда вам нужно:

• Пакетное преобразование множества файлов Word

• Чистое извлечение текста

• Файлы Markdown для документации или версионного контроля

• Преобразование, где изображения не требуются

Метод 2: Преобразование Word в Markdown онлайн

Лучше всего для: быстрых преобразований, нечастого использования

Для пользователей, которым нужно преобразовать лишь несколько документов Word, онлайн-конвертер обычно является самым быстрым решением. Установка программного обеспечения или технические знания не требуются. Такие инструменты, как Word2MD, позволяют преобразовывать документы прямо в браузере с помощью простого рабочего процесса «загрузить и скачать».

Шаг 1: Откройте онлайн-конвертер

Откройте страницу преобразования Word в Markdown в браузере.

Шаг 2: Загрузите документ Word

Перетащите файл Word в область загрузки.

Шаг 3: Скачайте файл Markdown

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

Преобразованный файл сохраняет:

• Заголовки

• Абзацы

• Списки

• Таблицы

• Гиперссылки

• Форматирование текста

Преимущества

Онлайн-преобразование даёт несколько преимуществ:

• Не требует установки

• Работает в Windows, macOS, Linux, iOS и Android

• Простой рабочий процесс с перетаскиванием

• Подходит для разовых преобразований

Что учесть

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

Лучшие сценарии использования

Выбирайте онлайн-конвертер, когда вам нужно:

• Быстрое разовое преобразование

• Преобразование с разных устройств

• Простой рабочий процесс в браузере

Метод 3: Преобразование Word в Markdown с помощью ChatGPT

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

ChatGPT предлагает альтернативный рабочий процесс преобразования документов, который отличается от жёстких конвертеров на основе правил. Вместо простого выполнения предустановленных правил форматирования ChatGPT понимает контекстное содержание документа и выполняет дополнительные пользовательские задачи через разговорные подсказки. На основе больших языковых моделей он точно разбирает форматирование Word и переводит каждый элемент в стандартный синтаксис Markdown, охватывая весь список ниже:

• Уровни заголовков → # / ## / ###

• Обычные абзацы основного текста

• Полужирный, курсивный, зачёркнутый текст

• Упорядоченные и неупорядоченные списки

• Нативные таблицы Markdown

• Гиперссылки

• Блоки кода

• Ссылки на изображения

• Блочные цитаты

• Горизонтальные линии

Шаг 1: Загрузите документ Word

Загрузите файл Word в окно чата ChatGPT.

Шаг 2: Опишите требования к преобразованию на естественном языке

Ручная настройка параметров преобразования не требуется — просто опишите требования к форматированию через разговорные подсказки.

Пример шаблона подсказки:

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

ChatGPT интерпретирует структурную логику вашего документа и генерирует дополнительный персонализированный контент вместе с форматированным Markdown.

Шаг 3: Вычитайте и экспортируйте итоговый результат Markdown

Полный результат Markdown будет содержать:

• Полностью преобразованную нативную структуру документа, соответствующую исходному макету Word

• Необязательные резюме по разделам

• Настроенную перестройку контента по запросу

• Строгое соблюдение указанных вами правил форматирования Markdown

Гибкие два режима обработки изображений

ChatGPT поддерживает два разных режима обработки изображений для разных сценариев использования:

1. Ссылки-заполнители Markdown (встроенный синтаксис-заполнитель)


2. Извлечение отдельных файлов изображений из исходного файла Word, при этом экспортированный файл Markdown ссылается на эти отдельные внешние файлы изображений

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

Ключевые ограничения, которые стоит отметить

Качество преобразования на основе генеративного ИИ продолжает улучшаться.

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

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

Идеальные сценарии применения

ChatGPT — оптимальный выбор для рабочих процессов, требующих:

• Одновременного преобразования Word в Markdown и резюмирования контента

• Логической реорганизации и перестройки исходного содержимого документа

• Разговорного управления на естественном языке вместо жёстких интерфейсов инструментов

• Более адаптивной, интеллектуальной обработки форматирования, чем у обычного ПО с фиксированными правилами преобразования

Метод 4: Преобразование Word в Markdown с помощью Python

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

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

Используя библиотеку обработки документов, такую как Spire.Doc for Python, вы можете интегрировать преобразование Word в скрипты, приложения или автоматизированные рабочие процессы.

Шаг 1: Установите Spire.Doc for Python

Установите библиотеку с помощью pip:

pip install Spire.Doc

Шаг 2: Сохраните Word как Markdown в Python

Следующий фрагмент кода загружает файл .docx и сохраняет его напрямую как файл .md:

from spire.doc import *
from spire.doc.common import *
document = Document()
document.LoadFromFile("input.docx")
document.SaveToFile(
"output.md",
FileFormat.Markdown
)
document.Close()

Сгенерированный Markdown сохраняет:

• Заголовки

• Абзацы

• Списки

• Таблицы

• Ссылки

• Форматирование текста

Извлечение изображений как отдельных файлов

По умолчанию изображения могут быть встроены как строки Base64.

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

Следующий подход извлекает изображения и заменяет ссылки на изображения Base64 относительными путями:

import re
import base64
import os
from spire.doc import *
from spire.doc.common import *
def convert_word_to_markdown_with_images(input_path, output_path, image_dir="images"):
# 1. Convert using Spire first
document = Document()
document.LoadFromFile(input_path)
document.SaveToFile("temp.md", FileFormat.Markdown)
document.Close()
# 2. Create image directory
os.makedirs(image_dir, exist_ok=True)
# 3. Read and process the Markdown file
with open("temp.md", "r", encoding="utf-8") as f:
content = f.read()
# 4. Find and replace Base64 images
pattern = r'!\[([^\]]*)\]\(data:image/([^;]+);base64,([^)]+)\)'
def replace_base64(match):
alt_text = match.group(1)
img_type = match.group(2)
base64_data = match.group(3)
# Generate filename
img_count = replace_base64.counter
replace_base64.counter += 1
filename = f"{image_dir}/img_{img_count:04d}.{img_type}"
# Decode and save image
img_data = base64.b64decode(base64_data)
with open(filename, "wb") as f:
f.write(img_data)
# Return reference path
return f''
replace_base64.counter = 1
new_content = re.sub(pattern, replace_base64, content)
# 5. Save the processed file
with open(output_path, "w", encoding="utf-8") as f:
f.write(new_content)
# Clean up temporary file
os.remove("temp.md")
# Usage
convert_word_to_markdown_with_images("input.docx", "output.md")

Лучшие сценарии использования

Преобразование на Python идеально подходит для:

• Автоматизированных систем обработки документов

• Сервисов пакетного преобразования

• Веб-приложений

• Конвейеров документации CI/CD

• Пользовательских рабочих процессов генерации Markdown

Как выбрать подходящий метод преобразования Word в Markdown

Лучший метод преобразования зависит от вашего рабочего процесса:

• Нужно простое пакетное преобразование?

→ MarkItDown Desktop

• Нужно быстрое преобразование без изображений?

→ Онлайн-конвертер

• Нужно понимание контента или резюмирование?

→ ChatGPT (или аналогичная LLM)

• Нужна автоматизация и полный контроль?

→ Программирование на Python

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

Заключение

Преобразование документов Word в Markdown можно выполнить несколькими способами: от простых настольных приложений до полностью автоматизированных программных решений.

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

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

"Нам поставили задачу сделать ... Обычно это делается через ... стоимостью 50 тысяч рублей, за 1 день, но у нас его не оказалось, поэтому мы ...." Ключевое в "мы" - 2 инженера с суммарным ФОТ в 1 млн. руб. МЕСЯЦ делали то, что "обычно" делается 1 человеком за 1 день с устройством за 50 тыс. руб.

Если делать "как обычно" задача решается с бюджетом в 73 тыс. руб.

Если делать "по докладу", то задача решилась с бюджетом в 1 млн. руб т.е. в 13,7 раз дороже. При этом 2 инженера выпали из бизнес-процессов на месяц и не принесли прибыли.

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

Я смотрю материалы конференций. Слежу за трендами в ИТ. Ситуация выше - ПРАВИЛО, а не исключение. Безусловно я не отслеживаю каждый тренд, но по тем проектам за которыми слежу:

- уровня библиотек / сервисов уровня ОС/виртуализации - 90 % изменений экономически хуже, чем без изменений;

- уровень прикладных решений - 70 % изменений экономически хуже, чем без изменений;

То есть ситуация пришла к тому, что НЕ ДЕЛАЯ НИЧЕГО бизнес ПОЛУЧАЕТ БОЛЬШЕ.

Проблема существует на 2-х уровнях:

- управление в ИТ;

- инженеры в ИТ;

Рассмотрим на примере Яндекс.Навигатора, как наиболее для меня показательном.

Самим приложением я пользуюсь 10+ лет.

В 2016 году оно меня полностью устраивало. Как есть. Приложение занимало 106 Мб.

В 2022 году приложение (алгоритм поиска пути) поменяли и оно стало годиться только для того, чтобы прокладывать маршрут туда, куда 1 раз в жизни едешь и нет времени/сил вручную просидеть над картой.

В 2024 году Навигатор стал сбивать нормальный маршрут на свой высер (о чём я писал пост Яндекс.Навигатор и идиотизм)

В 2026 году "голое" приложение занимает 430 Мб. И с позиции потребителя оно ХУЖЕ, чем в 2016-м. При этом для использования в формате "мозгов" для головного устройства автомобиля оно требует подписку.

Подведём итог - за 10 лет приложение стало в +/- 4,3 раза больше, требует более нового железа, в приложении появилась куча багов, приложением пользоваться стало хуже, чем 10 лет назад.

Вопрос: а за что отдел разработки Яндекс.Навигатора 10 лет получал зарплату? Больше, дороже, хуже? А зачем?

Если мы посмотрим на жизненный цикл продукта, то увидим такую картину, которую можно изобразить классическим "крестом" спроса/предложения:

Если мы отсортируем возможности ("фишки") приложения так, чтобы слева были самые востребованные, то получим такое соотношение возможностей приложения и ресурсов, которое оно требует.

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

На графике отчётливо видно, что с момента пересечения каждое изменение делает продукт ХУЖЕ... НО!

Рассмотрим это с позиции всех участников, снизу вверх.

Пользователю нужно чтобы приложение имело меньше багов и весило меньше. Довольно быстро 85 - 90 % потребностей пользователя приложение закрывает полностью.

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

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

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

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

Суть конфликта в том, что за всё платит Пользователь через Собственника.

Пользователь "голосует ногами" к конкуренту, его деньги не попадают к Собственнику. Как следствие Собственник режет бюджеты ИТ. А кто кого "съест" из менеджера и разработчика - плевать. В целом даже если оба уйдут - отлично. Приложение хуже становиться не будет и отток клиентов уменьшится.

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

20+ лет таких инженеров подвергали остаркизму. Есть огромная библиотека мемов, поговорок и т.д. и т.п.

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

Пользователя и Собственника совершенно не ебёт как именно решена задача.

Если приложение на 100 Мб удовлетворяет мои потребности, то для Пользователя "хорошо" это:

- Приложение стало занимать меньше места;

- Приложение стало работать быстрее на том же железе.

Всё остальное - плохо! Вообще всё!

Для Собственника важен баланс затрат и выручки. То есть:

Если выручка в начале года была А, затраты Б, количество клиентов К, то "хорошо" это (н - начало года, к - конец года):

- в расчёте на пользователя (Ак - Бк) > (Ан - Бн)

- Кк > Кн;

Всё остальное - плохо! Вообще всё!

Так вот сегодня почти всё ИТ, это плохо. И с позиции Пользователя и с позиции Собственника.

Забавно, но у ИТ есть прекрасная, но позорная корреляция - АвтоВАЗ. Та же динамика - стоимость растёт, а качество не так чтобы очень...

В 2020 - 2025 году трогать ИТ-департаменты было нельзя из-за ковида и СВО. Теперь стало можно.

!!! ВАЖНО ПОНИМАТЬ !!! У собственников бизнеса есть свой "Хабр". Только он не в Интернете, а в кафе, встречах и банях. Где оффлайн эти самые собственники общаются и делают пометки в блокнотиках. И обсуждают сотрудников, решения. В целом всё тоже самое, что и в ИТ-сообществе. Только вопросы там задают другие и ответы там ждут в другой форме.

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

И там гордятся тем, что продажи повышаются, стоимость решения уменьшается, а спектры задач расширяются.

Второе !!! ВАЖНО ПОНИМАТЬ !!!! на работе зарплату платят не за то, что вы можете чем-то выпендриться на Хабре или конференции. Зарплату платят за решение задач. И зарплату платит Вам Пользователь через Собственника. И размер зарплаты напрямую зависит от того, насколько удовлетворены эти категории людей. Если Пользователь не удовлетворён, то он идёт к конкуренту и денег на зарплату нет. Если Собственник не удовлетворён, то он полученные от Пользователя деньги положит к себе в карман. Не устраивает? Ну пили сам свой бизнес.

Ковид и СВО не вырастили ИТ. Они ЗАСТАВИЛИ бизнес переплачивать. Как врачам непосредственно в ковидные времена. А как только хромого вылечили, он первым делом бросает свою трость...

Что делать?

Решать проблемы. Список того что не устраивает бизнес и пользователей:

1. Не прозрачность решений. Каждое изменение должно быть обоснованным с рассмотрением вариантов. То есть мы делаем А потому что оно стоит Х, вариант Б стоит 2Х, вариант В стоит Х/2, но есть 80 % вероятность проблемы Г, которая будет стоить 10Х. Раньше бизнес слышал "Нужно Д", про себя матерился, но давал деньги... Это время прошло.

2. Достоверность. Приходит Менеджер ИТ к начальнику и озвучивает схему выше. По факту оказалось, что Х это 5Х, а у конкурента сделали Б и оказалось, что там не 2Х, а 0,75Х. В сауне с конкурентом собственника высмеяли за 5Х вместо 0,75Х... Но он не будет собирать всех и орать. Это в госсекторе так можно. Просто в следующий раз ваши слова считаются истиной на 20 % и как только будет вариант, которому верят хотя бы на 25 %, Вас будут заменять.

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

Кто сможет работать по новому - останется, остальных рано или поздно из ИТ выдавят. Скорее рано, чем поздно.

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

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

Бывайте ихтиандры, потом сюрпризом будет.

И качества ИТ-продуктов: Яндекс. Когда левая рука не знает, что делает правая

Тут надо сделать остановку и ввести крайне важный "дисклеймер" (предупреждение). Уже излагал в посте Почему ИТшники не линейные работники поэтому просто процитирую себя:

Поэтому ИТ, хоть и является крайне важной отраслью, но её сотрудники являются сервисно-сопровождающим классом. А тем, у кого подгорает от этого... Мир не обязан подстраиваться под чьи либо хотелки, он такой, какой есть.

Почему позиционирование ИТ как сервиса/поддержки имеет принципиальную важность?

Возьмём ТО автомобиля. Клиент платит за то, чтобы автомобиль продолжал ездить. И он готов за него платить МИНИМАЛЬНУЮ стоимость. То есть никто делать ТО каждые 100 - 500 - 1000 км не будет. Принципиально. Заказчик (бизнес) платит за результат. Запустим аллегорию булки хлеба и сделаем точкой отсчёта 2010 год в котором собственно всё уже оказалось настолько запущено, что сор выполз из избы. Итак 2010 год, булка хлеба стоит 10 рублей, весит 1 кг и на вкус 10 из 10. Сделаем ещё пару важных предупреждений и пойдём по хронологии:

В прошлых постах не освещено, но тоже крайне важно:

С позиции бизнеса ИТ, это как с позиции коллективного запада понятие "русский", то есть от начальника ИТ и ниже (для англичанина/француза русские это не только жители России, и даже не только украинцы, белорусы... Но и всякие литовцы/латыши/узбеки/киргизы и т.д. и т.п.).

Для точного понимания нужно всё-таки ещё раз повторить кто такие "бизнес", "собственник", "предприниматель","капитал" и "капиталист" и каково их позиционирование.

Бизнес - коллективная деятельность направленная на извлечение прибыли или получение иного результата.

Собственник - человек, который вложил личные средства в бизнес. Личные - ключевое для понимания.

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

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

Капитал - совокупность активов, как в виде денег так и в виде собственности.

Ключевая цель капитализма - преумножение капитала. То есть чистая сумма активов должна постоянно возрастать. Для чего рост активов должен превышать инфляцию. То есть:

Если инфляция составляет А в год, а сумма активов Б, то по итогам года (В) сумма активов должна отвечать следующему соотношению: В > А + (А * Б)

Ключевая формула бизнеса: прибыль = выручка - расходы

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

Тут надо остановиться и прямо указать один момент. Вы с объявления аллегории видели ИТ-термины? Нет. И не увидите. С позиции собственников бизнеса ИТ (как и любое другое подразделение) это "чёрный ящик" куда вкладывается А рублей в начале года и от которого ждут В рублей в конце. Что происходит внутри этого ящика капиталистов и бизнес волнует точно так же как шерифа проблемы негров т.е. извините за прямоту - абсолютно похуй.

ИТ - сообщество. Как и в любом сообществе тон задаёт крайне небольшое меньшинство, которое умеет громче всех кричать. Как зоошиза. Разбор "стандартов" в ИТ я уже делал:

Ответ QuazZ в «Айтишники vs юзеры»

Так же, его делали и другие люди с аналогичным результатом.

"Чистый код" замедляет работу приложений в 20 раз

Так же я разобрал почему для бизнеса 1С круче всего остального:

Продолжение поста «Насколько разные "программист" и "программист 1С"?»

Но @astrobeglec, же дебил и ничего не понимает...

Так вот возвращаемся из вводной части к аллегории. Сор из избы вышел в 2010. Предположим что инфляция 0, чтобы не рожать лишние расчёты и сущности:

Динамика:

2010 год, булка хлеба стоит 10 рублей, весит 1 кг и на вкус 10 из 10.

2015 год, булка хлеба стоит 20 рублей, весит 1 кг и на вкус 10 из 10.

2018 год, булка хлеба стоит 40 рублей, весит 0,9 кг и на вкус 9 из 10.

2020 год, булка хлеба стоит 100 рублей, весит 0,8 кг и на вкус 9 из 10.

2021 год, булка хлеба стоит 120 рублей, весит 0,7 кг и на вкус 9 из 10.

2022 год, булка хлеба стоит 150 рублей, весит 0,6 кг и на вкус 8 из 10.

2023 год, булка хлеба стоит 250 рублей, весит 0,5 кг и на вкус 7 из 10.

2024 год, булка хлеба стоит 275 рублей, весит 0,4 кг и на вкус 6 из 10.

2025 год, булка хлеба стоит 300 рублей, весит 0,3 кг и на вкус 5 из 10.

Ломать ИТ хотели ещё в 2020-2021-м годах. Но сперва ковид, а потом СВО не дали запустить механизм. В 2026 произошли сразу 2 события, которые позволили запустить процесс:

1. Перестали появляться блокирующий факторы типа ковида/сво.

2. Появился крайне удобный инфоповод - искусственный интеллект, который позволил замаскировать (т.е. послужить удобным прикрытием) для процессов.

И процесс запустили. Какой процесс? Типичный для бизнеса, который до этого работал со 100 % эффективностью. Урезание бюджетов. Помните высказывание (по словам В. В. Полеванова) Ржавого в начале 00-х?

Что вы волнуетесь за этих людей? Ну, вымрет тридцать миллионов. Они не вписались в рынок. Не думайте об этом — новые вырастут.

Абсолютно тот же процесс сегодня запущен в ИТ. Бизнес видел, что булка хлеба может стоить 10 рублей за кг с качеством 10 из 10. Там понимают, что новые потребности требуют не 1 булку хлеба, а 10. И что рост в 10 раз приведёт к падению качества... Ну например до 8 из 10.

Поэтому где-то на бумагах (а не в компьютерах) или в блокнотах лежат согласованные крупными игроками планы доведения к 20ХХ году стоимости 10 кг хлеба с качеством 8 из 10 до 100 рублей.

Не вписавшиеся в план капитал не волнуют.

То, что мы видим сейчас - процесс понимания насколько сильно можно и нужно давить на ИТ. Это ещё даже не начало самого процесса.