Comments 23
"Пора начать создавать" - подумал автор, и попросил нейросеть написать статью.
Спасибо за комментарий. Честно говоря, нейросети здесь ни при чём — текст писался головой и руками, на основе многолетнего опыта. Если вам кажется иначе, возможно, потому что мысли в статье совпадают с тем, что многие инженеры чувствуют, но редко высказывают вслух. Но если у вас есть конкретные замечания по сути — с удовольствием обсужу. А так, это типичный хабровский скепсис и обесценивание чужого труда через обвинение в использовании ИИ.
Да уж, автор сам не придерживается своих же "Аксиом", странная статья, разрозненная, "плакатная" с кричащими лозунгами. Все в куче, все в ...
Спор «лозунги vs аналитика» вечен.
Спасибо за обратную связь. Статья действительно получилась насыщенной, и её цель — скорее задать вопросы, чем дать готовые ответы. Если какие-то аксиомы показались вам противоречащими содержанию, буду рад услышать, какие именно и в чём противоречие. Конструктивная критика помогает дорабатывать мысли.
Скажу сразу, я не стану анализировать всю статью из-за отсутствия мотивации это делать. Другими словами статья не создает эту саму мотивацию - подумайте над этим.
Второй момент - статья, я так понимаю, это скорее крик о наболевшем, чем помощь в чем-то читающему, но "жизни" в этом нет - нужен конкретный кейс и на основе этого кейса показывать "причину".
По аксиомам - почти что все. Возьмите свою же статью и проанализируйте с позиций своих же аксиом. Вот пример, конкретно для Вас "Результат важнее отчёта. Формализация без решения реальных проблем — зло." Как Вам результат написания статьи?
В статье больше принципов, чем кейсов. Формат получился декларативным. Возможно, стоило сразу добавить конкретный разбор ситуации «до/после», чтобы аксиомы не воспринимались как лозунги.
Теперь к вашему вопросу про результат.
Если аксиому «Результат важнее отчёта» применить к статье. Результат — не количество символов и не карма, а возникшая дискуссия и выявленные точки сопротивления. По комментариям уже видно, где формулировки требуют уточнения, а где есть расхождение в понимании.
Приведенная аксиоматика, касается проектирования устойчивой архитектуры, для свободного развития, экономической среды, какой бы она ни была, ИТ, уголь, металлургия, образование.
Если смотреть прагматично, статья свою функцию выполняет: она проявляет проблему и собирает разные позиции. Это и есть измеримый эффект.
Если текст не мотивирует разбирать его — это тоже результат. Значит, он попал не в ваш текущий запрос. Это нормально.
Но критика формата без анализа содержания оставляет разговор на уровне впечатлений. Если есть желание двигаться глубже — давайте выберем одну аксиому и проверим её на практике. Без конкретики сложно двигаться дальше.
попробуйте заменить в Вашем последнем ответе:
Если аксиому «Результат важнее отчёта» применить к статье.
на
Если аксиому "Результат важнее отчёта. Формализация без решения реальных проблем — зло." применить к статье.
"Формализация без решения реальных проблем — зло." - вы это упустили намеренно?
В целом:
будьте внимательны к тому, о чем Вам пишут - не вырывайте контекст
дискуссия - не мотивация в данном случае для людей в комментариях - их больше не будет.
Вы правы, вторую часть формулировки в цитате опущена — хорошо, что обратили внимание.
Если применять аксиому целиком — «Результат важнее отчёта. Формализация без решения реальных проблем — зло» — то к статье она применима в первую очередь к автору.
Если текст становится декларацией без операционализируемой модели — это и есть риск формализации. В этом смысле ваше замечание про необходимость кейса — по делу. Без приземления в конкретную ситуацию принципы могут восприниматься как риторика.
При этом сам факт того, что вы проверяете текст на внутреннюю непротиворечивость, как раз и есть проверка на результат: работает ли тезис на практике. Если бы он не задевал — не было бы и этой линии обсуждения.
Про «дискуссия ≠ мотивация» — совпаление частичное. Мотивация возникает там, где есть узнавание своей проблемы. Если узнавания не случилось — значит, текст не попал в конкретный запрос. Это тоже диагностический сигнал.
Спасибо за внимательность к формулировкам. Она повышает точность дискуссии.
Начали за здравие...
Создавать, а не внедрить и мигрировать...
Ну думаю почитаю сейчас вдохновляющие примеры. Miro, Avito, Skyeng... Сам обожаю сделать что то новое инновационное. Если оно потом живёт 10+ лет без моего участия, то прямо успешный успех.
При чём здесь выбор дистрибутива, например? При чём здесь архитектура на века? Большинство успешных компаний не стоило архитектуру на века, а изменяло её в процессе, адаптируясь под бизнес требования, конкурентов, технологии.
Ну и роль неких руководителей сильно приувеличена. Ютуб, Google, Open AI, WhatsApp, Amazon, Meta, FIGMA.. Это истории не про боссов или архитектуру, а про предпринимателей.
Windows пришло на замену MS DOS, плавно вытесняя её с поддержкой совместимости. Опять про бизнес. UNIX тогда бесплатный был и сносно работал, только вот по пользовательскому опыту и прикладному ПО близко не доганял даже MS DOS, не то что Windows.
В общем, завязывайте с циклом статей непонятно про что.
Спасибо за развёрнутый комментарий и вопросы — это действительно ценно. Попробую ответить по пунктам, чтобы было понятнее, о чём текст.
При чём здесь выбор дистрибутива?
Дистрибутив в контексте статьи — это не просто набор пакетов, а воплощение стратегии развития. Выбирая «Альт» с собственным репозиторием или «Астру», зависящую от Debian, мы выбираем не софт, а модель будущего: либо самостоятельность в принятии решений, либо зависимость от внешних факторов. Для бизнеса это вопрос устойчивости: сможет ли компания адаптироваться, когда внешняя среда резко изменится (как это уже происходит с санкциями и блокировками).При чём здесь архитектура на века?
Под «архитектурой на века» понимать надо, не догму, а фундамент, позволяющий гибко меняться без потери управляемости. Это как строить дом на сваях, а не на песке: если грунт (рынок, технологии) меняется, можно надстроить этажи, не перестраивая основание. Те компании, которые вы упомянули (Google, Amazon и др.), начинали с очень гибкой архитектуры, но постепенно вкладывались в её развитие, чтобы масштабироваться. Их успех — не отсутствие архитектуры, а умение её эволюционировать.О каких компаниях я говорю?
Речь идет о российском контексте, где многие организации вынуждены мигрировать на отечественное ПО. Здесь примеры западных гигантов не всегда применимы, потому что условия другие: ограниченный рынок, зависимость от госрегулирования, санкционные риски. Но общий принцип остаётся: любой бизнес, который хочет долгосрочной устойчивости, должен закладывать в архитектуру возможность независимого развития.Про Windows и UNIX
История Windows — это во многом маркетинг и связи, а не техническое превосходство. Но это подтверждает мою мысль: успех часто определяется не только качеством кода, но и тем, кто контролирует экосистему. Именно поэтому важно, чтобы российские разработчики имели контроль над своей экосистемой, а не просто копировали чужие решения.Завязывать ли с циклом статей?
Если бы все думали как вы, возможно "здесь никого бы и не было как и там". Но судя по откликам (и плюсам, и минусам), тема важна для многих. Будем продолжать, потому что считаем необходимым обсуждать эти вопросы открыто и без иллюзий. Спасибо, что потратили время на развёрнутый ответ — он помогает лучше сформулировать мысли в будущем.
Прочитал только начало - что инженегры не заботятся о документации. Дальше читать не стал, потому, что автор явно не в ладах с реальностью или где-то в подворотне опыта нахватался. И у нас и на западе инженера учат тому, что он производит бумажку. Ту самую спецификацию продукта, документацию. И это в любой нормальной конторе есть - иначе каким надо быть укурком чтобы платить инженеру за отсутствие результата.
Вы не дочитали, поэтому упустили важную деталь. Вовсе не утверждается, что инженеры не должны создавать документацию. Напротив, только за качественную, живую документацию, которая отражает реальность. Речь шла о бесполезных многотомных отчётах, которые пишутся для галочки и которые никто не читает — в том числе потому, что они не соответствуют действительности. Если в вашей компании инженеры создают именно работающую документацию — честь им и хвала. В нашем опыте такое встречается реже, чем хотелось бы.
Они не качают пакеты из Debian. Они берут исходники у авторов и сами собирают систему.
Если завтра интернет-кабель перерубят с обеих сторон, «Альт» продолжит выпускать обновления.
Не смог читать. Извиняюсь. Просто потерял мвсль где-то на 3м 4м абзаце и только боль за потреченное время
Ну хоть комментариев наберёт себе под постом. Руководитель не хочет читать тонны номенклатуры не из-за лени, а когнитивного перегруза или его избежания.
Когнитивная перегрузка — серьёзная проблема. Но избегание нагрузки не решает её, а лишь откладывает. Если руководитель не вникает в суть, он рискует принимать решения вслепую. Статья как раз о том, что нужно искать баланс: не утопать в деталях, но и не уходить в полное игнорирование. В идеале — выстраивать процессы так, чтобы ключевая информация была доступна и понятна без чтения томов. Это и есть задача лидера — создать такую систему.
По мне все по делу написано. Сам работаю в конторе в которой из-за импортозамещения годами отработанные системы ломают через колено. Все делается в авральном режиме и о документации можно только мечтать.
Спасибо за отклик, и пример из практики.
То, что вы описываете, — типичный эффект реактивных решений: когда стратегический вопрос подменяется срочной задачей «срочно заменить». В итоге фокус смещается на миграцию как процесс, а не на устойчивость системы в будущем.
Именно поэтому в статье акцент сделан не на самом факте импортозамещения, а на том, как оно реализуется — с архитектурным пониманием или в режиме аврала.
Очень ценно, что тема отозвалась вашим личным опытом. Именно такие процессы (как у вас) помогают увидеть проблему не абстрактно, а вживую. Если захотите поделиться деталями вашего кейса, это могло бы стать отличной основой для отдельного разбора.
Ответственность важнее регламента. Целеполагание и осознание своей деятельности — цель ежедневного труда
Я работаю простым инженером в финтехе. Можно сказать, что мне "снизу" видно слишком мало
Да и сужу сугубо по собственному эмпирическому опыту
Большие органации без качественной базы регламентов, процессов ознакомления всех участников процесса с основными положениями этих регламентов и без инструментов принуждения следования регламентам - они как общество без законов. Всё скатывается в хаос. Взаимодействие со смежными подразделениями в нерегламентированных процессах - это некачественное выполнение задачи, нарушение любых разумных сроков или вовсе отсутствие обратной связи, как бы ты не пытался достучаться до смежника: почта, корпоративный мессенджер, корпоративная звонилка - тебя везде проигнорят, потому что каждый сотрудник итак загружен на 200%. Если в договоре с контрагентом не прописаны SLA на предоставление обратной связи и санкции за нарушение SLA, значит у вас нет взаимодействия с контрагентом. Недоступность вашего бизнес процесса из за аварии на сервисе контрагента - самого контрагента не волнует. Устранят как устранят, а может и вообще не устранят, а может настроить на письма от вас фильтр на безвозвратное удаление?
Возможно я некорректно понял контекст. Ответственность конкретно вас, как руководителя - важнее регламента. Согласен
С "общей" ответственностью не согласен. Она не то чтобы менее важна, чем регламент, её вообще не существует
Спасибо за подробный и честный комментарий.
Вы описываете очень знакомую ситуацию: когда отсутствие чётких регламентов и SLA действительно превращает взаимодействие в хаос. На операционном уровне без формализованных процессов большая организация не работает — здесь с вами сложно спорить.
В статье, вероятно, не до конца чётко разведены уровни.
Регламент — это инструмент.
Ответственность — это субъект.
Если есть регламент, но нет субъекта, который реально отвечает за результат, регламент превращается в формальность.
Если есть ответственность, но нет процессов — возникает хаос.
Поэтому тезис «ответственность важнее регламента» не про отмену регламентов, а про приоритет причин над инструментами. Регламент без владельца — мёртвый документ. Ответственность без процессов — управленческая иллюзия.
Вы правы и в другом: «общая ответственность» часто размывается до состояния «никто не виноват». В таком виде она действительно не существует. Ответственность всегда персонализирована.
Спасибо, что подсветили эту грань. Возможно, в следующем материале стоит чётче развести уровни: стратегический, процессный и личный.
Мы устали делать вид. Почему пора перестать «внедрять и мигрировать» и начать создавать