Прежде всего это репутация и возможность максимально адекватно передать дела и знания по проектам и продуктам в случае, если замена по каким-то причинам не нашлась или малый срок передачи дел. Это мой личный опыт, а также опыт пары коллег, которые уходили с аналогичной поддержкой.
Согласен, логика «хуже не будет» абсолютно здравая. Но любая перестройка операционки — это всегда риск и ломка привычек.
Для изменений нужен либо карт-бланш сверху, либо сильная воля снизу:
Трансформационных лидеров сейчас нанимать и наделять полномочиями боятся — ставки слишком высоки, а среда меняется быстрее, чем окупается реорганизация.
Транзакционные руководители, призванные «сохранять и не ломать», просто не имеют мотивации и навыков проводить реформы.
Вот и получается пат: первых не нанимают или не дают развернуться из-за страха неопределенности, а вторые по своей природе не полезут оптимизировать то, что хоть как-то функционирует. Исключения точно есть, но система чаще выбирает тактику замирания.
При адекватном расставании отличный вариант — оставить человека на парт-тайм или консультации на пару месяцев. Ни один чек-лист не предусмотрит 100% нюансов и вариантов развития событий, особенно если специалист работал в компании не один год.
Свободная конкуренция и развитие процессов возможны только тогда, когда есть устойчивый, прозрачный сигнал от среды: куда и в каких рамках мы движемся.
У нас же бизнес получает сразу три взаимоисключающих импульса: «импортозамещаться», «осваивать» или «ждать у моря погоды». Ровно эти три вектора порождают адептов, искренне считающих соседей идиотами.
Когда у менеджмента нет понимания правил игры даже на горизонте года, невозможно проектировать «AI-first компании» и выстраивать здоровую культуру. В такой неопределенности менеджмент закономерно скатывается в имитацию, сгон людей в офисы и отчетность по потраченным токенам.
Инициатива звучит по-корпоративному масштабно, но попытка написать "национальные стандарты" для технологии, которая кардинально меняется каждые три месяца — занятие весьма специфическое.
А главного слона в комнате подсветили ближе к концу статьи: реальный рынок сейчас пишет код с помощью OpenAI и Anthropic. Пока вся индустрия на практике использует Claude через прокси, нам предлагают стандартизировать процессы на уровне Минцифры.
Единственное, в чём гигантам и государству действительно стоило бы объединить усилия — это железо и локальный хостинг мощных Open Source моделей, чтобы код не улетал во внешние API. А как именно крутить промпты в IDE, разработчики без стандартов Минцифры как-нибудь разберутся.
На самом деле ИИ сейчас подсветил давнюю проблему: полное смешение понятий Output (количество выкаченного кода/фич) и Outcome (реальная бизнес-ценность). Появился дешёвый инструмент генерации гипотез, и незрелый менеджмент принял эту скорость за эффективную работу.
А декларируемый POM во многих компаниях был не более чем карго-культом. Как только у руководства появился инструмент, позволяющий срезать углы, вся "продуктовая культура и автономность команд" моментально рассыпалась, уступив место директивному микроменеджменту.
Думаю, маятник качнется обратно к здравому смыслу только тогда, когда стоимость поддержки "ИИ-мусора" в кодовой базе начнет превышать гипотетическую выгоду от его быстрого релиза»
Советы по выживанию в духе «смотреть по сторонам, как пешеход» логичны, но они лечат симптомы. Если лиду приходится тратить 30–40% времени на кулуарные игры, составление «карт влияния» и войну с соседними отделами, то кто будет заниматься инженерией? В долгосрочной перспективе такие компании всегда проигрывают тем, где процессы выстроены прозрачно, а метрики бьют родственные связи.
Защищать команду надо, безусловно. Но иногда лучший способ защиты — увести её в нормальное место.
Переучиваться из технаря в политика — весьма спорная затея. Если же приходится оставаться в такой системе, нужно находить адекватного партнёра внутри компании (например, сильного продуктовика или стейкхолдера), который будет заинтересован прикрывать спину и расти на успехах вашей команды.
P.S. Политика есть в любой системе, вопрос лишь в том, до какого уровня вниз она прорастает. Если это опустилось уже до уровня тимлидов — компания тяжело больна.
У вас получилась advanced версия примитивов и они отлично расширяют картину. Пара уточнений… точка действительно превращается в звезду или группу точек (в зависимости от подхода), проект часто в ломанную или дугу, но имеет начало и конец. Процесс эволюционирует в спираль, как в примерах Toyota.
Единственное, по поводу чего хочется подискутировать — это продукт. Я вижу его, как микс из предыдущих элементов. Как мне кажется, в усложненном варианте мы любую организацию можем назвать продуктом и тогда комбинация из проектов, исследований и процессов выглядит органично.
Именно подобную логику я хотел упростить до примитивов. Точка — начало любой геометрической фигуры. Отрезок (может быть не прямым) — это движение от точки до точки. Окружность — частный случай отрезка (дуга), который замыкается сам в себя. Спираль — эволюция окружности, а как следствие, логическое объединение всех предыдущих форм.
Во-первых, я говорил об уменьшении нагрузки на мышцы спины, если не понятно из контекста. Нагрузка на позвоночник незначительна в обоих случая в пределах нормы, т.к. работа идёт со своим весом и подходит для основной массы. При наличии отклонений в здоровье, упражнения подбираются индивидуально.
«…очень подвержен травмам» — о каких травмах вы говорите, вы издеваетесь? :)
По поводу отклячивания задницы я позволю не согласиться с тем, что это неправильно.
При отклячивании просто снижается нагрузка на пресс и спину, кроме того нагрузка смещается к верхней части грудной мышцы.
Соответственно при прогибании корпуса нагрузка смещается к нижней части грудной мышцы.
Отжимания — это очень гибкое упражнение, в котором множество вариаций и все они преследуют свои цели.
:) в оригинале был мудрый филин и ответ его звучал примерно:
«Я ж стратег, а это тактика…»
Анекдот заставляет улыбнуться, но если вы не умеете делегировать полномочия и сосредотачиваться на глобальных задачах, а распыляетесь на каждую микро-цель, то ваше место исключительно в роли тактического исполнителя.
Не возомнившие, а выросшие из программистов и умеющие решать глобальные задачи.
А описанный продукт позволяет на нужном уровне абстракции удобно работать с кодом.
Этакая лёгкая интеграция чего-то вроде UML-представления с живым проектом. )
Все верно. Ставка по договору ГПХ сильно не обогатит.
В вашей терминологии и ценностях мотивации нет.
Прежде всего это репутация и возможность максимально адекватно передать дела и знания по проектам и продуктам в случае, если замена по каким-то причинам не нашлась или малый срок передачи дел. Это мой личный опыт, а также опыт пары коллег, которые уходили с аналогичной поддержкой.
Согласен, логика «хуже не будет» абсолютно здравая. Но любая перестройка операционки — это всегда риск и ломка привычек.
Для изменений нужен либо карт-бланш сверху, либо сильная воля снизу:
Трансформационных лидеров сейчас нанимать и наделять полномочиями боятся — ставки слишком высоки, а среда меняется быстрее, чем окупается реорганизация.
Транзакционные руководители, призванные «сохранять и не ломать», просто не имеют мотивации и навыков проводить реформы.
Вот и получается пат: первых не нанимают или не дают развернуться из-за страха неопределенности, а вторые по своей природе не полезут оптимизировать то, что хоть как-то функционирует. Исключения точно есть, но система чаще выбирает тактику замирания.
Многое упирается в градус отношений на выходе.
При адекватном расставании отличный вариант — оставить человека на парт-тайм или консультации на пару месяцев. Ни один чек-лист не предусмотрит 100% нюансов и вариантов развития событий, особенно если специалист работал в компании не один год.
Свободная конкуренция и развитие процессов возможны только тогда, когда есть устойчивый, прозрачный сигнал от среды: куда и в каких рамках мы движемся.
У нас же бизнес получает сразу три взаимоисключающих импульса: «импортозамещаться», «осваивать» или «ждать у моря погоды». Ровно эти три вектора порождают адептов, искренне считающих соседей идиотами.
Когда у менеджмента нет понимания правил игры даже на горизонте года, невозможно проектировать «AI-first компании» и выстраивать здоровую культуру. В такой неопределенности менеджмент закономерно скатывается в имитацию, сгон людей в офисы и отчетность по потраченным токенам.
Инициатива звучит по-корпоративному масштабно, но попытка написать "национальные стандарты" для технологии, которая кардинально меняется каждые три месяца — занятие весьма специфическое.
А главного слона в комнате подсветили ближе к концу статьи: реальный рынок сейчас пишет код с помощью OpenAI и Anthropic. Пока вся индустрия на практике использует Claude через прокси, нам предлагают стандартизировать процессы на уровне Минцифры.
Единственное, в чём гигантам и государству действительно стоило бы объединить усилия — это железо и локальный хостинг мощных Open Source моделей, чтобы код не улетал во внешние API. А как именно крутить промпты в IDE, разработчики без стандартов Минцифры как-нибудь разберутся.
А в B2B ждем смарт-контракты. В ближайшее время их будут пилотировать, а на 27-28 раскатывать уже по рынку.
На самом деле ИИ сейчас подсветил давнюю проблему: полное смешение понятий Output (количество выкаченного кода/фич) и Outcome (реальная бизнес-ценность). Появился дешёвый инструмент генерации гипотез, и незрелый менеджмент принял эту скорость за эффективную работу.
А декларируемый POM во многих компаниях был не более чем карго-культом. Как только у руководства появился инструмент, позволяющий срезать углы, вся "продуктовая культура и автономность команд" моментально рассыпалась, уступив место директивному микроменеджменту.
Думаю, маятник качнется обратно к здравому смыслу только тогда, когда стоимость поддержки "ИИ-мусора" в кодовой базе начнет превышать гипотетическую выгоду от его быстрого релиза»
Советы по выживанию в духе «смотреть по сторонам, как пешеход» логичны, но они лечат симптомы. Если лиду приходится тратить 30–40% времени на кулуарные игры, составление «карт влияния» и войну с соседними отделами, то кто будет заниматься инженерией? В долгосрочной перспективе такие компании всегда проигрывают тем, где процессы выстроены прозрачно, а метрики бьют родственные связи.
Защищать команду надо, безусловно. Но иногда лучший способ защиты — увести её в нормальное место.
Переучиваться из технаря в политика — весьма спорная затея. Если же приходится оставаться в такой системе, нужно находить адекватного партнёра внутри компании (например, сильного продуктовика или стейкхолдера), который будет заинтересован прикрывать спину и расти на успехах вашей команды.
P.S. Политика есть в любой системе, вопрос лишь в том, до какого уровня вниз она прорастает. Если это опустилось уже до уровня тимлидов — компания тяжело больна.
Подскажите, а есть ли у вас мысли, как этот уровень "архитектоники" можно более-менее экологично и прагматично оценивать?
Спасибо, я надеялся на подобный комментарий!
У вас получилась advanced версия примитивов и они отлично расширяют картину. Пара уточнений… точка действительно превращается в звезду или группу точек (в зависимости от подхода), проект часто в ломанную или дугу, но имеет начало и конец. Процесс эволюционирует в спираль, как в примерах Toyota.
Единственное, по поводу чего хочется подискутировать — это продукт. Я вижу его, как микс из предыдущих элементов. Как мне кажется, в усложненном варианте мы любую организацию можем назвать продуктом и тогда комбинация из проектов, исследований и процессов выглядит органично.
Именно подобную логику я хотел упростить до примитивов.
Точка — начало любой геометрической фигуры. Отрезок (может быть не прямым) — это движение от точки до точки. Окружность — частный случай отрезка (дуга), который замыкается сам в себя. Спираль — эволюция окружности, а как следствие, логическое объединение всех предыдущих форм.
Вопрос, а есть ли адекватные альтернативы?
Для огромной армии пользователей нет понятия адресная строка.
Как и нет понятия командная строка.
А нерв защемить и во время чистки зубов можно.
«…очень подвержен травмам» — о каких травмах вы говорите, вы издеваетесь? :)
При отклячивании просто снижается нагрузка на пресс и спину, кроме того нагрузка смещается к верхней части грудной мышцы.
Соответственно при прогибании корпуса нагрузка смещается к нижней части грудной мышцы.
Отжимания — это очень гибкое упражнение, в котором множество вариаций и все они преследуют свои цели.
if (li.nextSibling == null) { li.hasChildNodes() && (subtree = li.childNodes[1]); for (var i=0; i<subtree.childNodes.length; i++) subtree.childNodes[i].className = "last"; }хотя бы на
if (li.nextSibling == null && li.hasChildNodes() && (subtree = li.childNodes[1])) { subtree.className = "last"; }и стиль прописывать не для li.last, а для ul.last li
«Я ж стратег, а это тактика…»
Анекдот заставляет улыбнуться, но если вы не умеете делегировать полномочия и сосредотачиваться на глобальных задачах, а распыляетесь на каждую микро-цель, то ваше место исключительно в роли тактического исполнителя.
А описанный продукт позволяет на нужном уровне абстракции удобно работать с кодом.
Этакая лёгкая интеграция чего-то вроде UML-представления с живым проектом. )