[{"content":"🎬 Что посмотреть и что почитать: Игра в 21 до Голой статистики доведет Продолжаем рубрику \u0026ldquo;что посмотреть\u0026rdquo; - о кино и книгах, которые попадают в ИТ-повестку. На этот раз - фильм \u0026ldquo;21\u0026rdquo; с Кевином Спейси и книга \u0026ldquo;Голая статистика\u0026rdquo;.\nСюжет, конечно, не про KPI и не про сервис-деск. Но один эпизод привлек внимание - задача с тремя дверями, за одной из которых главный приз - \u0026ldquo;Аааавтомобиииль\u0026rdquo;. Этот пример я встречал в книге \u0026ldquo;Голая статистика\u0026rdquo;. Было интересно увидеть на экране не просто математическую загадку, но и пример того, как интуиция уверенно ведет нас не туда.\n🚪 Кейс с тремя дверями Напомню. Перед нами три двери. За одной - автомобиль, за двумя другими - пусто. Игрок выбирает одну дверь. Ведущий, который знает правильный ответ, открывает одну из оставшихся дверей, за которой точно нет приза. После этого предлагает изменить выбор, и оказывается, что лучше согласиться. Вероятность выигрыша при смене двери - 2/3, без смены - 1/3.\nЭто отличный пример того, насколько опасно доверять эмоциям и ощущениям, когда мы имеем дело с данными и беспощадной наукой.\nПарадокс Монти Холла показывает, что интуиция и вероятность - не одно и то же.\nКнига будет особенно полезна аналитикам, потому что учит не торопиться с выводами и смотреть не только на цифры, но и на условия, при которых эти цифры появились.\n📊 Не только автомобили, но и телевизоры Еще один пример из книги - история про телевизоры. Исследования показали, что чем больше в доме телевизоров, тем выше у детей показатели в школе. Напрашивается простой вывод: чтобы дети лучше учились, нужно купить больше телевизоров.\nРазумеется, вывод ошибочный. Здесь показана разница между корреляцией и причинно-следственной связью. Дело не в телевизорах, а в том, что их количество связано с уровнем благосостояния семьи, а уже оно влияет и на условия обучения, и на доступ к образованию.\nДля аналитика это базовый навык. В работе мы постоянно видим связи между метриками, событиями и результатами, но не каждая связь означает причину. Книга приучает к осторожности в выводах: не принимать красивое совпадение за объяснение.\n📚 Смотреть или читать? Фильм точно стоит посмотреть. Еще лучше после фильма взяться за книгу. Она не заваливает формулами, вместо этого объясняет идеи статистики через реальные примеры, бытовые сюжеты и юмор.\nИ в этом ее польза - не только продуктовым или дата-аналитикам, а вообще всем, кто работает с данными, метриками и гипотезами. Она помогает отличать сигнал от шума, осторожнее обращаться с выводами и замечать, как легко перепутать красивую зависимость с реальным объяснением происходящего.\n🎯 Итог \u0026ldquo;21\u0026rdquo; - фильм про азарт, риск и систему. И про то, как человек начинает видеть за красивой картинкой модель, вероятность и логику принятия решения.\nКнига - следующий шаг, она показывает как работать с данными без поспешных выводов.\n","date":"2026-04-15T05:29:59Z","image":"/posts/2026/04/15-chto-posmotret-i/15-chto-posmotret-i.jpg","permalink":"/posts/2026/04/15-chto-posmotret-i/","title":"🎬 Что посмотреть и что почитать: Игра в 21 до Голой статистики доведет"},{"content":"🎲 Когда не получается выиграть, начинают менять правила Интересный инфоповод. Готовится очередная операция по спасению Почты России: законопроект с набором мер, которые \u0026ldquo;должны дать компании новые стабильные источники дохода на фоне жесткой конкуренции с маркетплейсами и частной доставкой\u0026rdquo;.\n🛳️ Любой масштаб может проиграть сервису Много лет у компании была фора, о которой любой частный бизнес может только мечтать: отделения по всей стране, узнаваемый бренд, почти обязательное присутствие в каждом населенном пункте, административный ресурс и привычка рынка жить рядом с этим гигантом.\nНо как только в логистику и доставку пришел быстрый и клиентоориентированный бизнес, внезапно выяснилось, что одной инфраструктуры мало. Оказалось, что точки можно открывать быстрее, а сервис можно делать удобнее.\n⚙️ Конкуренция заставляет быть эффективными В конкурентной среде частный бизнес, как правило, имеет высокую операционную эффективность: цена ошибки высока, а за клиента необходимо ежедневно бороться.\nНе остается права на инерцию. Нельзя годами прикрывать слабую операционную модель ссылками на социальную функцию, историческую роль или особый статус.\nЕсли сервис плохой, клиент уходит. Если издержки высокие, бизнес теряет рынок. Если медленные процессы тормозят создание ценности, это быстро становится видно в P\u0026amp;L.\n🚧 Слабость требует внешней защиты Всякий раз, когда крупный игрок начинает просить для себя специальные правила, это является очередным признанием в бессилии и неспособности к внутренним изменениям.\nЗдесь не ставится вопрос о продукте, клиентском опыте или о модернизации. Вопрос поднимается о том, как компенсировать слабую конкурентоспособность нормативным преимуществом.\n💣 Успешные игроки оказываются под давлением Когда сервис не может победить качеством, скоростью и удобством, единственным вариантом становится ослабление конкурентов вместо собственного развития.\nФормально это всегда можно объяснить заботой о безопасности, устойчивости, суверенитете или социальной роли. По сути же это всегда означает только одно: вместо того чтобы самим стать сильнее, система пытается сделать слабее рынок.\n💸 В итоге проигрывает потребитель Такой подход дает временную передышку, но не создает эффективности. Он не исправит слабую операционную модель, не улучшит продукт и, конечно, не повысит качество управления.\nНо один эффект будет точно - цена этих проблем ляжет на пользователей, партнеров и рынок в целом.\n","date":"2026-03-23T05:31:25Z","image":"/posts/2026/03/23-kogda-ne-poluchaetsya/23-kogda-ne-poluchaetsya.jpg","permalink":"/posts/2026/03/23-kogda-ne-poluchaetsya/","title":"🎲 Когда не получается выиграть, начинают менять правила"},{"content":"🧠 Про память и ее искажения У нас принято готовить отчет по инцидентам - что произошло, какие решения принимали и что нужно изменить, чтобы не повторить ошибку.\nИ вот каким наблюдением я хочу поделиться. В моменте главное - скорее восстановить сервис. Когда \u0026ldquo;всех спасли\u0026rdquo;, появляется соблазн раскидать накопившуюся очередь, ответить людям и закрыть срочные поручения - а уже потом спокойно все описать.\nНо когда \u0026ldquo;потом\u0026rdquo; наступает, картина уже расплылась, память начинает играть с нами злые шутки.\n🎭 Нам кажется, что мы все помним, но это только кажется Если не фиксировать ход расследования по мере решения, информация начинает фрагментироваться. Часть остается в переписке, что-то - в устных договоренностях и головах конкретных людей.\nЧерез пару дней команда уже не может восстановить последовательность событий. Начинаются пересказы, которые звучат абсолютно убедительно. Мозг закрывает пробелы и сглаживает углы. В результате мы спорим не о фактах, а о версиях.\n⚙️ Есть причины, которые приводят к искажениям воспоминаний Память не видеорегистратор. Мы не можем достать прошлое из архива. Вместо этого мозг собирает картину заново из обрывков контекста, эмоций и того, что мы услышали позже.\nВо время решения инцидента это усиливается тремя факторами:\nПерегруз рабочей памяти. Мысли заняты симптомами, ограничениями, коммуникацией и параллельными задачами. После тушения пожара сохраняется общий результат и несколько ярких эпизодов, а промежуточные шаги быстро стираются, особенно если сразу переключиться на новую задачу. Когнитивные искажения. Мозг цепляется за первую правдоподобную гипотезу и вместо проверки разных вариантов мы начинаем искать аргументы в пользу уже выбранного объяснения. Комментарии и чьи-то выводы подмешиваются к событиям в памяти, и мы перестаем отличать факты от чьих-то домыслов. А когда проблема найдена, причина кажется очевидной. Но на самом деле эта \u0026ldquo;очевидность\u0026rdquo; возникает задним числом - память аккуратно собирает историю из гипотез и фактов так, что она начинает выглядеть логичной и неизбежной. Смешивание источников - мы перестаем различать, откуда взялся \u0026ldquo;факт\u0026rdquo;: из логов, из чата, или из чужого рассказа. На следующий день все звучит одинаково уверенно. Мозг подменяет точность ощущением ясности.\nПоэтому мысли нужно вовремя выгружать. ✍️ Лучше один раз записать, чем сто раз вспоминать Документ стоит создавать с начала расследования и вести параллельно с работами, опираясь на собранные артефакты. Минимальный каркас, чтобы зафиксировать события:\nТаймлайн: время, события, действия, логи. Список гипотез: гипотеза - как проверяем - как опровергаем - вывод. Решения и следующие шаги: обходное решение, необходимые меры, срок, ответственный. ✅ Итог Риск потери фактов возникает когда кажется, что детали еще свежи. На самом деле память уже начала упрощать и перестраивать события.\nПоэтому поступать советую как в старой шутке: \u0026ldquo;Я не злопамятный, приходится записывать\u0026rdquo;.\n","date":"2026-03-11T05:29:58Z","image":"/posts/2026/03/11-pro-pamyat-i/11-pro-pamyat-i.jpg","permalink":"/posts/2026/03/11-pro-pamyat-i/","title":"🧠 Про память и ее искажения"},{"content":"💵 Ценность изменений и стоимость владения ИТ традиционно воспринимается кост-центром, как и любое сервисное подразделение. Но мы можем изменить это восприятие, если рассмотрим расходы на изменения как инвестиции с измеримой ценностью для бизнеса.\n🧠 Что мы измеряем Внимательные читатели, вероятно, помнят, что ранее я писал о том, как мы работаем с RFC и собираем с бизнес-заказчика пользу от реализации каждого изменения. Команды, которые встроили эту практику в свои процессы обработки изменений, при подведении итогов года могли достаточно быстро озвучить конкретную цифру экономического эффекта вместо ощущений. У нас эта цифра получилась внушительной: автоматизация процессов реально сэкономила бизнесу заметное количество денег.\nНо это лишь часть картины.\n📊 Разделяем пользу и обязательства Среди всех запросов на изменения есть особая категория - требования законодательства. Новые ставки налогов, регламентированные формы, обязательные обновления платформы под требования новых версий ПО. Такие изменения не приносят прямой экономической выгоды, но без них компания просто не сможет работать в правовом поле. Это обязательства, а не развитие и не оптимизация.\nВсе изменения мы рассматриваем как единый поток, но внутри него я предлагаю разделить запросы как минимум на две группы.\nПервая - изменения с экономическим эффектом. По ним заказчик на входе RFC фиксирует пользу, чаще всего в виде экономии человеко-часов, которые мы переводим в рубли через среднюю часовую ставку в корпорации. Из этих изменений формируется портфель ценности. Это та часть ИТ-работ, которая напрямую создает измеримую ценность для бизнеса.\nВторая группа - обязательные изменения. Законодательство, регуляторка, обновления платформы. Здесь нет и не должно быть экономических обоснований в виде ROI. Это расходы на владение реализованными решениями. Цена за то, что система живет, развивается и остается актуальной.\n🔁 Видим цену владения Если смотреть на затраты через такую призму, понятными становятся эффект от изменений стоимость владения. С одной стороны, мы можем усилить эффект от затрат на развитие - защищать инвестиции в автоматизацию не абстрактными аргументами, а портфелем ценности. С другой стороны, становится видно, во сколько на самом деле обходится содержание изменений.\nИ здесь можно наблюдать разницу между двумя подходами к разработке - сделать хоть как-нибудь чтобы работало, или сделать хорошо, чтобы и работало хорошо и эксплуатировать можно было без проблем. Одни команды тратят на обновление своих систем считанные часы, другие - недели. И это уже не про законодательство как таковое, а про архитектурные решения, уровень кастомизации и накопленный техдолг.\n🤔 А вы считаете возврат инвестиций? Друзья, какая у вас ситуация? Получается конвертировать запросы на изменения в финансовую ценность и вести диалог с бизнесом? Удалось доказать, что ИТ перестал быть кост-центром?\n","date":"2026-02-11T05:29:59Z","image":"/posts/2026/02/11-tsennost-izmeneniy-i/11-tsennost-izmeneniy-i.jpg","permalink":"/posts/2026/02/11-tsennost-izmeneniy-i/","title":"💵 Ценность изменений и стоимость владения"},{"content":"☸️ 1С DevOps для самых маленьких 2.0 - теперь на Kubernetes Сегодняшняя тема максимально прикладная - настройка сборочного конвейера для 1С.\nПоэтому менеджеры могут выдохнуть и спокойно наслаждаться лавандовым рафом. ☕\nК экранам приглашаются программисты 1С и энтузиасты, которым интересно, как все это реально работает и как можно потрогать это собственными руками.\nДовольно давно я сделал вики-проект 1c-devops-jr. Про то, как с нуля собрать CI для 1С, если у тебя нет ни Jenkins, ни SonarQube, ни понимания, с какой стороны к этому подходить.\nВсе было хорошо, конвейеры запускались. Но для их работы использовался docker-swarm. Плагин docker-swarm для Jenkins не обновлялся, а потом и вовсе перестал работать на новых версиях. С тех пор зрела идея переехать на Kubernetes - современно, модно, молодежно.\nПереезд состоялся, и я представляю вторую версию вики-проекта. Главное изменение - теперь весь конвейер работает на Kubernetes, в формате легкого и понятного k3s.\nИдея при этом не изменилась.\nТребования все те же:\nуметь держать руки над клавиатурой;\nне бояться терминала;\nбыть готовым читать README, а не только смотреть картинки (теперь картинок вообще нет 👿).\nСценарий максимально простой.\nПримерно за час на пустой виртуальной машине можно установить k3s, развернуть базовые сервисы (CI, анализ кода), запустить сборку, получить первый отчет о качестве 1С-кода.\nЭто учебный полигон, где можно безопасно потрогать CI/CD для 1С, понять базовые принципы и только потом решиться масштабировать это в бою.\nПроект по-прежнему открыт. Изучайте, пробуйте, ломайте, собирайте обратно. Пишите комментарии, задавайте вопросы, предлагайте улучшения и критикуйте.\nhttps://github.com/kropachev/1c-devops-jr/wiki\nKubernetes - в каждый дом. CI - в каждый проект. Даже если это проект на 1С.\n","date":"2026-02-02T05:29:59Z","image":"/posts/2026/02/02-1s-devops-dlya/02-1s-devops-dlya.jpg","permalink":"/posts/2026/02/02-1s-devops-dlya/","title":"☸️ 1С DevOps для самых маленьких 2.0 - теперь на Kubernetes"},{"content":"👨‍🚀 Start Where You Are - первое впечатление может быть обманчивым Продолжаем разговор о принципах ITIL. Ранее я уже писал о нескольких из них, и все они, по сути, про одно - как принимать решения не в теоретически идеальных условиях, а в суровой реальности с ограничениями, долгами и компромиссами. Сегодня обсуждаем принцип Start Where You Are.\nЗвучит банально, но именно этот принцип на практике часто нарушается.\n⚡ Первое впечатление Приходя в новый проект, легко поймать себя на знакомом импульсе: \u0026ldquo;проще все переписать\u0026rdquo;. Тот же мотив нередко звучит и при обсуждении проблем с подрядчиком, только в более аккуратных формулировках - \u0026ldquo;нужно перевнедрять\u0026rdquo;, \u0026ldquo;архитектура устарела\u0026rdquo;.\nУ этого есть простое объяснение: в первый момент мы видим не систему, а симптомы. Мы замечаем сбои, задержки, раздраженные комментарии пользователей, но почти не видим того, что остается за кадром и продолжает работать каждый день.\n🫣 Что обычно остается невидимым Ускользает от взгляда то, что любая ИТ-система не только \u0026ldquo;болит\u0026rdquo;, но и каким-то образом живет и функционирует. Она закрывает реальные бизнес-задачи, переживает обновления и авралы, выдерживает нагрузку пользователей, требования регуляторов и сложные интеграции.\nРаботать с тем, что есть - не про \u0026ldquo;оставить все без изменений\u0026rdquo;. Речь о том, чтобы сначала увидеть и зафиксировать реальность, прежде чем пытаться ее менять. Как выглядит пользовательский сценарий, где он замедляется или застревает, в каких местах решения принимаются на личном опыте и интуиции, и где процесс формально существует, но фактически держится на конкретных людях.\nВ этот момент становится понятно, что проблема вовсе не в том, что \u0026ldquo;все плохо\u0026rdquo;. Проблема в том, что \u0026ldquo;плохо\u0026rdquo; в конкретных местах и по вполне определенным причинам.\n🧱 Что бы ни случилось - пилим монолит В разработке это хорошо видно на унаследованных системах. На входе в такой проект, сразу разговор сводится к распилу монолита. Монолит кажется источником всех бед, а его разборка - универсальным решением.\nНо большинство таких систем годами доставляет ценность бизнесу. Да, через боль и с техническим долгом. Однако внутри почти всегда есть стабильные участки, повторяемые сценарии и негласные правила, благодаря которым система приносит пользу.\nПоэтому вместо глобального переписывания имеет смысл сначала понять, какие части системы действительно причиняют боль, а где монолит выполняет свою функцию и не требует немедленного вмешательства.\n🎯 Выводы Часто оказывается, что достаточно выделить несколько ключевых направлений изменений, чтобы снизить градус обсуждения с \u0026ldquo;все переписать\u0026rdquo; до \u0026ldquo;исправить конкретные проблемы\u0026rdquo;. А уже потом, в более спокойной обстановке, принимать решения о новых внедрениях и замене продуктов.\nПочти всегда решения, принятые с холодной головой, приводят к более устойчивым результатам, чем жесты отчаяния в точке безысходности. И это касается не только разработки.\n","date":"2026-01-22T05:30:00Z","image":"/posts/2026/01/22-start-where-you/22-start-where-you.jpg","permalink":"/posts/2026/01/22-start-where-you/","title":"👨‍🚀 Start Where You Are - первое впечатление может быть обманчивым"},{"content":"📊 Личные итоги года. Конец года - подходящий момент для подведения итогов. Не в формате отчета о проектах, а как анализ событий и результатов: что получилось, какие направления оказались важными и где сместился фокус.\nВ целом год для меня оказался про базовые и очевидные стандарты, которые многими игнорируются, а многим и вовсе недоступны.\nЕсли вспоминать результаты за пределами рабочей операционки, то список получается такой:\nЗавершил обучение, начатое в прошлом году, в корпоративной академии. Проект защитил с признанием экспертов. Проект был не про ИТ вообще, а про управленческий цикл - от human resource management к human capital management. Участвовал в корпоративном dev-camp с двумя докладами.\u0026ldquo;Размер XL\u0026rdquo; - про работу с проектами с миллионами строк (наша любимая ERP). И первая публичная презентация менеджера синхронизаций 1С - тогда еще без финального названия и под рабочим именем BSOD (библиотека синхронизации и обработки данных). Получил благодарность от корпорации за модернизацию и развитие внутренних сервисов. Для меня это важная фиксация того, что системная работа внутри ИТ-функции видна и признается на уровне организации. Появился телеграм-канал и сайт kropachev.digital. Незапланированное событие, скорее как побочный эффект, но в итоге стал одним из самых ценных результатов года. Появилось пространство, где можно фиксировать базовые вещи, которые в профессиональной среде принято считать очевидными, хотя на практике они регулярно отсутствуют. Завершил курс Технический директор - CTO. Польза оказалась не в перечне ролей или фреймворков, а в постоянном возврате к деньгам, ценности и ответственности за результат, а не за формальное соблюдение процессов. В качестве хобби появился проект для подключения внешних инструкций в 1С:Документооборот, который сразу был внедрен в компании. Небольшое решение, но с вполне ощутимым эффектом для пользователей. Впереди остается еще много планов и идей - и по развитию внутренних систем, и по выстраиванию более прозрачного и предсказуемого ИТ-сервиса, и по работе с отраслевыми стандартами. Оставайтесь на связи.\n","date":"2025-12-26T05:31:10Z","image":"/posts/2025/12/26-lichnye-itogi-goda/26-lichnye-itogi-goda.jpg","permalink":"/posts/2025/12/26-lichnye-itogi-goda/","title":"📊 Личные итоги года."},{"content":"🔧 Про простоту и практичность: Keep it simple and practical Продолжаем обсуждение принципов ITIL. Сегодняшняя тема - Keep it simple and practical.\nХочу поделиться историей, на этот раз не из личного опыта, а скорее интернет-байкой.\nФабрика зубных паст. Конвейер. Иногда часть коробок выходила пустой - тюбик с пастой не попадал внутрь, и появлялся брак.\n🧩 Видим проблему - усиливаем контроль Проблему заметили, приняли решение усилить контроль. На конвейере установили сложную систему обнаружения пустых коробок. Как только датчики фиксировали пустую коробку, линия останавливалась. Машинист убирал пустую коробку и снова запускал процесс.\nСистема работала. Документы были в порядке. Процесс описан. Ответственные назначены. Все по уму.\n💨 Сложное решение не всегда лучшее А потом остановки прекратились. Проверка показала - брак исчез. Все коробки полные.\nПричина оказалась банальной. Рядом с конвейером стоял вентилятор, который сдувал пустые коробки. Полные оставались на ленте - они были тяжелее. Вентилятор поставил машинист, не по проекту и без согласований. Потому что ему надоело бегать и вручную запускать линию.\n🔎 Проблема локальная, решение избыточное Это отличная иллюстрация принципа Keep it simple and practical. Проблема была локальной, решение системным и сложным, а самое эффективное улучшение оказалось максимально простым.\nВ ИТ (да и не только в ИТ, что уж там) мы регулярно наступаем на те же грабли. Мы строим сложные контуры контроля, но не убираем первопричину. Добавляем автоматизацию, но не упрощаем работу. Создаем процессы, которые работают на бумаге, но изматывают людей.\nИногда лучшее решение - это убрать лишнее и дать людям возможность делать работу. При этом реальные улучшения часто рождаются там, где есть прозрачность и контакт с исполнителями - рядом с конвейером (гемба).\n🧠 Что означает принцип Принцип Keep it simple and practical часто понимают как совет \u0026ldquo;не усложнять\u0026rdquo;, но на самом деле он про умение управлять сложностью осознанно. В ИТ сложность появляется естественным образом - через рост систем, команд и регламентов. Проблема начинается тогда, когда сложность перестает приносить пользу.\nЕсли решение нельзя объяснить простыми словами, оно требует ручного сопровождения и создает препятствия, значит, принцип нарушен - мы построили систему вокруг неудобства, а не устранили причину. Практичность - это когда решение реально работает в потоке, а не только выглядит правильным на схеме.\n✅ Вывод Сложность не признак зрелости. Зрелость - это умение выбрать простое решение, которое работает.\nИ это стыкуется с предыдущим принципом (collaborate and promote visibility). Открытость и прозрачность нужны, чтобы увидеть, где именно \u0026ldquo;болит\u0026rdquo;, и не лечить симптомы процессами. В истории с пастой \u0026ldquo;умная\u0026rdquo; система контроля решала проблему, перекладывая работу на машиниста. Вентилятор не был идеальным решением по документам, но он был идеальным решением по результату.\n","date":"2025-12-15T05:29:58Z","image":"/posts/2025/12/15-pro-prostotu-i/15-pro-prostotu-i.jpg","permalink":"/posts/2025/12/15-pro-prostotu-i/","title":"🔧 Про простоту и практичность: Keep it simple and practical"},{"content":"🎬 Data-driven трансформация на большом экране Решил разбавить посты рубрикой \u0026ldquo;что посмотреть\u0026rdquo; - фильмами и сериалами, которые попадают в ИТ-повестку. Начнем с фильма \u0026ldquo;Человек, который изменил все\u0026rdquo; (Moneyball).\n📊 Данные против \u0026ldquo;так всегда делали\u0026rdquo; \u0026ldquo;Человек, который изменил все\u0026rdquo; - редкий фильм, где драму строят вокруг Excel-таблиц и статистики. Классическая история data-driven трансформации еще до того, как это стало мейнстримом. Менелжер команды перестает полагаться на советы скаутов (рекрутеров, подбирающих игроков) и начинает смотреть в цифры: важен не образ игрока, а его вклад в победу.\nПо сути это классический кейс для ИТ-подразделения: бюджет ограничен, конкуренция за ресурсы высокая, культура \u0026ldquo;так принято\u0026rdquo; сильнее, чем привычка проверять решения по данным.\n⚾ Логика Moneyball У скаутов была одна стратегия: верить опыту и чутью. Они отбирали игроков по картинке и ощущению - как выглядит, как двигается, какую историю про него можно рассказать.\nМенеджер с аналитиком приходят с другой логикой. Вместо разговоров - таблицы. Их интересует не то, нравится ли игрок аудитории, а сколько раз он реально выводит команду на базу и приближает к победе. Поэтому тихие и \u0026ldquo;некрасивые\u0026rdquo; с точки зрения скаутов игроки вдруг оказываются ценнее раскрученных звезд.\nКлючевая метрика фильма - как часто игрок оказывается на базе. Не сила подачи и не эффектный замах, а вклад в вероятность победы. Это полностью меняет подбор состава.\nВ ИТ свои \u0026ldquo;проценты выхода на базу\u0026rdquo; - метрики, привязанные к деньгам, рискам и эффективности. Как только они появляются, мифы \u0026ldquo;нам нужно переписать все\u0026rdquo; и \u0026ldquo;срочно новый CRM\u0026rdquo; начинают звучать гораздо слабее.\n💭 Общее впечатление Для меня это история борьбы объективных цифр против субъективной веры. С одной стороны - люди, привыкшие верить только своему опыту и чутью. С другой - попытка опереться на цифры и показать, что мир уже изменился.\nФильм очень узнаваемо показывает типичные ИТ-диалоги: \u0026ldquo;у меня десять лет опыта\u0026rdquo;, \u0026ldquo;сто раз так делали\u0026rdquo;, \u0026ldquo;верим, что все получится\u0026rdquo;. Перестать самим опираться на такие доводы - уже шаг вперед.\nНебольшой спойлер: в конце фильма главный герой принимает важное решение, не опираясь на цифры, и мне кажется, в этот момент он проигрывает.\n","date":"2025-12-08T05:32:20Z","image":"/posts/2025/12/08-data-driven-transformatsiya-na/08-data-driven-transformatsiya-na.jpg","permalink":"/posts/2025/12/08-data-driven-transformatsiya-na/","title":"🎬 Data-driven трансформация на большом экране"},{"content":"❓ 5 почему - инструмент, чтобы понять боль пользователя Тойота подарила нам не только канбан, который мы все любим и постоянно используем. Есть еще дзидока и пока-йоке, о них мы поговорим отдельно. А сегодня - про другой важный инструмент: метод \u0026ldquo;5 почему\u0026rdquo;, который помогает докапываться до первопричины, а не чинить симптомы. В ИТ-сервисе метод особенно важен, потому что помогает понять потребность пользователя.\n🧩 К нам приходят с решением, а не с задачей К нам часто приходят запросы с готовым решением глазами пользователя: \u0026ldquo;добавьте поле\u0026rdquo;, \u0026ldquo;сделайте выгрузку\u0026rdquo;, \u0026ldquo;поменяйте логику\u0026rdquo;.\nУ оператора срабатывает простая логика. Попросили - сделал, тикет закрыл, SLA соблюден. В таком режиме мы не узнаем, в чем именно проблема пользователя. Есть риск додумать непонятный запрос и попасть в ловушку \u0026ldquo;я другое имелл ввиду, это же очевидно - переделывайте\u0026rdquo;.\nБыстрое выполнение создает картинку высокой скорости без лишних вопросов. Но если не задавать вопросы, мы не поймем, в чем боль и какие реальные ожидания у человека. Нашей позицией становится \u0026ldquo;мне все равно, что у тебя происходит, я просто нажму нужную кнопку\u0026rdquo;. Так ИТ застревает в роли центра исполнения, а не партнера.\n🧠 Мы хотим понять, а не допросить 5 почему - это не про контроль и не про усложнение заявок, а про живой интерес к проблеме пользователя.\nСформулированное решение в заявке - явный признак необходимости задать первое \u0026ldquo;почему\u0026rdquo;, чтобы услышать историю: что сейчас происходит, что в этом неудобно, к какой проблеме это приводит. На следующих шагах мы выходим к реальной потребности пользователя, а не к набору полей в форме.\nЦель - не допытать, а дослушать и переформулировать задачу так, чтобы и пользователю было понятно, про что его боль, и ИТ могло предложить решение именно под эту боль.\n🔨 Молоток против картины Бытовой пример. Человек просит молоток. Кажется, что проблема - в отсутствии инструмента, но настоящая боль в том, что картина до сих пор лежит на полу. Дайте молоток - чтобы забить гвоздь - гвоздь нужен на стене в гостиной - я хочу картину на стене.\nВ ИТ-сервисе \u0026ldquo;молоток\u0026rdquo; - новый реквизит, еще одна выгрузка, правка формы. \u0026ldquo;Картина на стене\u0026rdquo; - понятный отчет, меньше ошибок и штрафов, экономия времени пользователей.\n🔁 Как встроить 5 почему в процесс Хорошие новости. Внедрение метода в ИТ-сервис не требует новых форм или систем - нужно изменить культуру работы с обращениями и обучить команду задавать правильные вопросы. Но кажется, здесь-же основная сложность - мы не можем просто изменить формы и купить новую систему.\nТочно так-же, как существует необходимость понять пользователя, правило обработки запросов тоже должно быть понято. Ошибкой будет задавать вопросы \u0026ldquo;потому что у меня в скрипте написано\u0026rdquo;.\nСпросите себя - Я понимаю что действительно хочет пользователь? Какой результат будет достигнут? Это факт, или мои домыслы? Последний вопрос особенно важен - мы еще поговорим об эксперименте Хайдера и Зиммель.\n","date":"2025-12-03T05:29:59Z","image":"/posts/2025/12/03-5-pochemu/03-5-pochemu.jpg","permalink":"/posts/2025/12/03-5-pochemu/","title":"❓ 5 почему - инструмент, чтобы понять боль пользователя"},{"content":"🦒 Неочевидные факты Выходные, проведенные с детьми, могут стать источником неожиданных инсайтов. Возьмем жирафа.\nВ популярных подборках фактов часто пишут, что у него нет голосовых связок. Формулировка эффектная, но неточная: голосовой аппарат у жирафа есть, просто его звуки плохо различимы для человека.\nИнтереснее другой факт: язык у жирафа темно-фиолетовый, почти черный. Почему? Оказывается для защиты от загара. Что? Язык черный для защиты от загара? На самом деле - да. Жираф часами тянется за листьями под открытым солнцем, язык постоянно \u0026ldquo;работает на улице\u0026rdquo;, значит, его нужно защищать от солнечных лучей.\n🧪 Когда странное становится нормальным Для большинства такие детали - повод удивиться или усомниться. Что-то странное и нелогичное, не вписывается в привычную картину мира. А вот для специалиста все объяснимо: теория и накопленный опыт позволяют спокойно увидеть причинно-следственные связи.\nС квантовой запутанностью мы сталкиваемся редко, с ураганами на Сатурне, формирующими шестиугольник на полюсе - и того реже. Поэтому там люди легче признают: \u0026ldquo;я в этом ничего не понимаю\u0026rdquo;.\n💻 С ИТ все иначе С технологиями люди соприкасаются непрерывно - вы читаете этот пост с экрана сложного устройства, которое считаете простым. Возникает иллюзия, что если мы каждый день с чем-то взаимодействуем, то \u0026ldquo;примерно понимаем\u0026rdquo;, как устроены процессы внутри. А дальше включается типичная человеческая особенность - переоценка собственной компетентности в области, где нет системного образования и практики, но есть бытовой доступ.\n🙃 Кажется все проще В результате любой факт, требующий профессиональной глубины, становится объектом сомнения, шуток и попыток найти \u0026ldquo;более простое объяснение\u0026rdquo;. Программисты и менеджеры слышат это постоянно:\nПочему так сложно просто отправить письмо? Почему релиз нельзя сделать за один вечер? Зачем несколько сред, если можно одну боевую, но хорошую?\nЧем доступнее технология, тем громче обобщения и тем чаще эксперты сталкиваются с недопониманием и попытками обывателей \u0026ldquo;объяснить, как надо по-простому\u0026rdquo;, когда это \u0026ldquo;простое\u0026rdquo; на самом деле не работает за пределами бытовых сценариев. 🎯 Как говорить о сложном Если неочевидные решения не объяснены, они выглядят как странности, а не как осознанный выбор.\nЧто мы можем сделать со своей стороны?\nДокументы - максимально понятными. Ясная структура, примеры из реальных сценариев, понятные выводы. Визуализации схем архитектуры, процессов, сценариев - лучше один раз показать, чем сто раз объяснить. Учитывать аудиторию - одно и то же решение должно быть объяснимо по-разному для пользователей, менеджеров, архитекторов. Это сэкономит время на объяснении и снимет множество вопросов.\nХорошо сделанные документы, схемы и уровни представления не снижают сложность ИТ, но могут повысить уровень понимания. В этом смысле ясная документация становится таким же критичным элементом устойчивости, как резервирование, тесты и мониторинг. ","date":"2025-12-01T05:29:59Z","image":"/posts/2025/12/01-neochevidnye-fakty/01-neochevidnye-fakty.jpg","permalink":"/posts/2025/12/01-neochevidnye-fakty/","title":"🦒 Неочевидные факты"},{"content":"🔥 Пятничное: О приоритизации мер по обеспечению регламентированной информационно-процессуальной стабильности На основании решений и внутренних нормативных актов доводится до сведения, что первостепенной задачей признается осуществление безопасного, стабильного и согласованного бездействия, рассматриваемого как итог любого процесса. Достижение осязаемых результатов квалифицируется как побочное следствие и не подлежит целеполаганию. При наличии расхождений между фактическим положением дел и оформленными и согласованными документами приоритет имеет содержание указанных документов, а реальные обстоятельства подлежат игнорированию.\n👮‍♂️ О режиме защиты от информации В силу п. 1 ст. 2 соответствующих актов установлен режим защиты стабильности от информации. Ограничение доступа к сведениям опасного характера установлено для предотвращения неконтролируемого воздействия. В соответствии с п. 3 ст. 2 запрет на передачу и обмен информацией вводится во избежание проявлений прогресса и иного нежелательного развития. Любая информация рассматривается как риск отклонения от генеральной линии. Получение новых знаний, распространение аналитических материалов и инициативы по изменению порядка квалифицируются как мероприятия, отнесенные к категории усиленного регламентного контроля, и подлежат блокированию до утверждения регламента.\n🧠 О регулировании умственной деятельности Использование мыслей, выводов и иных форм умственной деятельности подлежит отдельному регулированию. Самостоятельное обдумывание и формирование суждений рассматриваются как факторы повышенного риска и подлежат пресечению до их оформления в установленном порядке. Не допускается применение несанкционированных мыслительных процессов при принятии решений.\nУполномоченное структурное подразделение по предотвращению получения информации разъясняет, что получение сведений, находящихся вне закрепленных контуров, является угрозой устойчивому функционированию системы управления и подлежит ограничению.\n📋 О порядке применения защитных мер Во исполнение Приказа о всеобщей информационной блокировке устанавливается следующий порядок:\nкаждое действие подлежит оформлению актом с последующей регистрацией; все инициативы подлежат оформлению и согласованию с Советом по согласованию советов для последующего отклонения; сведения о признаках продуктивности подлежат оформлению служебным докладом и направлению через канал утилизации; входящие сведения подлежат предварительному отнесению к потенциально опасным с оформлением мотивированного отказа в ознакомлении. ⚖ Заключительные положения Настоящим устанавливается, что получение знаний вне утвержденных инструкций, а также стремление к достижению измеримых результатов без заключения о допустимости постановки цели не допускаются. Каждое намерение, действие и суждение подлежат согласованию и блокированию по итогам рассмотрения Общественной коллегией по безопасности и Президиумом.\n","date":"2025-11-28T05:29:58Z","image":"/posts/2025/11/28-tgif-o-prioritizatsii/28-tgif-o-prioritizatsii.jpg","permalink":"/posts/2025/11/28-tgif-o-prioritizatsii/","title":"🔥 Пятничное: О приоритизации мер по обеспечению регламентированной информационно-процессуальной стабильности"},{"content":"🤗 Про пользу открытости - collaborate and promote visibility Сегодня хочу поделиться старой историей и поговорить об одном из принципов ITIL - collaborate and promote visibility.\nВернувшись со встречи, на которой обсуждалась очередная инициатива, я негодовал. В бэклоге лежала куча критичных задач по развитию бизнеса, техдолгу и обновлениям, которые объективно были приоритетнее нового запроса \u0026ldquo;просто улучшающего пользовательский опыт\u0026rdquo;. Мне было непонятно, как при такой очереди нам пытаются вставить новую задачу, да еще и просят об оперативности? Негодование довольно быстро сменилось пониманием - никто кроме нас о нашей нагрузке не знает. Естественно, коллеги будут приходить с запросами на изменения, если не видят очередь.\n📈 Видимость, это про что Что говорит ITIL? Достижение целей требует информации, понимания и доверия. Работа и ее последствия должны быть видимыми, а информация - распространяться в максимально возможной степени.\nКаждый новый запрос выглядит как единственный и срочный, потому что никто не видит контекста: сколько уже в работе и какие обязательства мы на себя взяли. Получается, без прозрачности бизнес не может принимать обоснованные решения о приоритетах, а ИТ находится под постоянным давлением из-за срочных задач.\n📊 Прозрачный бэклог вместо очереди в головах Решилось все довольно просто - доской со стикерами. Текущая работа разбита по колонкам статусов, а большая колонка очереди разделена по месяцам - когда мы ориентировочно сможем взяться за задачу. Любые новые инициативы либо вставали в конец, либо двигали все остальное, и это было сразу видно. Произошли три вещи.\nВо-первых, коллеги увидели, что их \u0026ldquo;простая доработка\u0026rdquo; конкурирует не с пустой доской, а с обновлениями безопасности, техдолгом и стратегическими задачами.\nВо-вторых, вместо \u0026ldquo;нам срочно нужно\u0026rdquo; появились вопросы \u0026ldquo;что мы готовы подвинуть\u0026rdquo;.\nВ-третьих, снизилось давление на команду: когда видно, что в работе уже 15 критичных задач, добавлять 16-ю \u0026ldquo;срочно\u0026rdquo; становится сложнее.\n🤝 Сотрудничество, а не борьба за слот Прозрачность - лишь половина принципа, вторая - именно совместная работа и общие правила игры. ИТ показывает свою загрузку, риски и ограничения, бизнес формулирует цели и критерии успеха, а все участники видят одну картину, а не ее фрагменты. Когда информация на столе, разговор меняется: вместо борьбы за слот в следующем спринте начинается совместный выбор, какие изменения дадут наибольшую ценность при имеющихся ресурсах.\n🏛 Комитеты и регулярная синхронизация Хороший инструмент для такого диалога - регулярные комитеты по изменениям и развитию. Это точка соприкосновения, где в зависимости от масштаба компании на общую карту инициатив и бэклога могут смотреть спонсоры, владельцы бюджетов, владельцы продуктов и заказчики изменений. Отличная возможность проверить, не разъехались ли цели бизнеса и ИТ, и принять осознанные решения о приоритетах и компромиссах.\n","date":"2025-11-26T05:31:30Z","image":"/posts/2025/11/26-pro-polzu-otkrytosti/26-pro-polzu-otkrytosti.jpg","permalink":"/posts/2025/11/26-pro-polzu-otkrytosti/","title":"🤗 Про пользу открытости - collaborate and promote visibility"},{"content":"🧩 АПИ один, клиентов много Когда мы проектируем интеграцию, легко попасть в ловушку: сделать АПИ \u0026ldquo;под конкретную систему\u0026rdquo;, а не \u0026ldquo;про свои данные\u0026rdquo;. Сегодня на другом конце провода одна CRM, завтра ее меняют, послезавтра BI переезжает на другую платформу - и каждый раз приходится переписывать контракт и пересобирать интеграцию.\nХочу поделиться парой советов, которые упрощают жизнь архитекторам и ИТ-менеджерам.\n💡 Не подстраивайте АПИ под конкретную систему АПИ должно описывать вашу предметную область, а не особенности клиента. Вместо \u0026ldquo;выгрузка для BI X\u0026rdquo; и \u0026ldquo;обработка заказа из системы Y\u0026rdquo; думайте в терминах сущностей и действий бизнеса: заказ, клиент, оплата, статус, документ. Если у вас есть \u0026ldquo;GET /orders\u0026rdquo; и \u0026ldquo;POST /payments\u0026rdquo;, то для этого АПИ принципиально все равно, кто его вызывает - 1С, скрипт на Python, коннектор DWH или новая CRM. Контракт опирается на модель бизнеса, а не на конкретную контр-систему.\nКак только вы начинаете подстраивать АПИ под контрагента - \u0026ldquo;подправим структуру\u0026rdquo;, \u0026ldquo;модифицируем пару значений\u0026rdquo;, \u0026ldquo;посчитаем статус в их логике\u0026rdquo; - вы зашиваете в свой ландшафт чужую кухню. Сегодня это \u0026ldquo;пара полей\u0026rdquo;, через пару лет в АПИ оказывается логика приложения контрагента. Любое их изменение становится вашей задачей.\n📦 АПИ источника - это Extract, а не весь ETL ETL - это Extract, Transform, Load: достать данные, преобразовать, загрузить. Когда вы проектируете АПИ источника, вы чаще всего на этапе Extract. Ваша задача - сказать правду и отдать данные как есть. Не как \u0026ldquo;удобнее потребителю\u0026rdquo;, не как \u0026ldquo;лучше зайдет в отчет\u0026rdquo;, а реальное состояние в учетной системе.\nДа, вы приводите даты к единому формату, поддерживаете адекватную схему для сумм и валют, фильтруете откровенный мусор и следите за безопасностью. Но все, что относится к бизнес логике потребителя и трансформации под его модель, - это уже Transform и Load, зона ответственности следующего слоя: ETL, интеграционной шины или модуля в целевой системе.\n🧱 Где заканчивается ваша модель и начинается чужая Если начать реализовывать Transform внутри АПИ, контракт привязывается к конкретной реализации на другом конце. Поменяется логика в DWH - придется менять АПИ. Поменяется структура в чужой CRM - снова придется менять АПИ. Вместо стабильного источника вы получаете живой организм, который дергают все, кому не лень.\nЗдоровая граница, где АПИ честно говорит, как устроены ваши данные и процессы, на языке ваших сущностей и статусов. Следующий слой берет эту правду и перекладывает под свои нужды. Если завтра вместо текущего потребителя появится другой, ему не придется просить вас переписать пол АПИ - он построит свой Transform и Load поверх стабильного Extract.\n⚙️ Итоги Для менеджера это еще и вопрос управляемости. Если договориться, что АПИ источника отвечает только за Extract, а вся \u0026ldquo;магия под заказчика\u0026rdquo; живет в отдельном слое, вы снижаете риск, что смена контрагента превратится в многомесячный проект по раскопкам древних интеграций.\n","date":"2025-11-24T05:31:03Z","image":"/posts/2025/11/24-api-odin-klientov/24-api-odin-klientov.jpg","permalink":"/posts/2025/11/24-api-odin-klientov/","title":"🧩 АПИ один, клиентов много"},{"content":"🔥 Пятничное. Настоящие разработчики Кажется, я нашел сборник вредных советов, которым пользуются все разработчики, аналитики и их менеджеры. Иначе сложно объяснить абсолютно шаблонное поведение вокруг сроков и результатов. Это даже не про людей - это про систему, которая поощряет тех, кто тянет до последнего.\n🙈 Вредный совет 1 Если у задачи есть срок - запомни: это не дата, к которой ее надо сделать, а дата, до которой можно расслабиться и заниматься другими задачами.\nСрок 7 дней?\nДень 1-5: каждый день уверенно подтверждай на дейликах прогресс. День 6: посмотри, что там в тикете. Теперь понятно, почему начинать надо было 5 дней назад. День 7: в день релиза сообщи, что нужно еще чуть-чуть времени, чтобы сделать качественно.\nТак ты всегда выглядишь при деле, даже если по факту ничего не сделал. 🕰 Вредный совет 2 Никогда не задавай уточняющих вопросов сразу.\nЕсли по задаче есть вопросы:\nОтложи их до следующей встречи. На встрече обсуждай все, кроме этой задачи. В день дедлайна скажи, что были вопросы, поэтому даже не начинал решать.\nТак задача проживает несколько жизней в календаре, ни разу не приблизившись к выполнению. 📞 Вредный совет 3 Коммуникации всегда нужно откладывать.\nНе решай вопросы в рабочем порядке, дождись дейлика. Не задавай вопросы, если тебя самого не спросили про задачу. В конце рабочего дня напиши, что возникли вопросы и завтра надо обсудить.\nТак у тебя всегда будет железный аргумент: \u0026ldquo;было недостаточно информации\u0026rdquo;. 📋 Вредный совет 4 Никогда не принимай решение в том же канале, где появилась задача.\nПоступила новая задача в Jira:\nСначала перенеси обсуждение в рабочий чат. Потом задай вопрос в комментариях к документации. Потом отправь информацию по почте без номера и ссылки на задачу. Наконец, собери вопросы в локальном файле и \u0026ldquo;забудь\u0026rdquo; отправить.\nК концу месяца никто уже не помнит, что вообще хотели сделать, но все очень устали от процесса. 🫷 Вредный совет 5 Никогда не начинай задачу заранее - иначе подведешь систему.\nЕсли ты сделал задачу день в день:\nТебя завалят новыми. Срок начнут резать еще сильнее. Коллеги обидятся: \u0026ldquo;нам теперь тоже так делать?\u0026rdquo;.\nПоэтому лучший способ казаться эффективным - синхронизироваться с коллективной прокрастинацией. 🥂 Выводы Только тот, кто честно следует этим советам, вечно занят, всегда в дедлайне и хронически ничего не успевает, может называть себя \u0026ldquo;настоящим разработчиком\u0026rdquo;.\nВсе остальные - игристые программисты.\nЕсли ты вдруг начинаешь решать задачи раньше срока, задаешь вопросы сразу и не откладываешь коммуникации до последнего момента - остановись. Люди могут подумать, что работать тебе в удовольствие. Но все ведь знают, что в офис ходят, чтобы уставать и впустую растрачивать время на нелюбимое занятие.\n","date":"2025-11-21T05:34:31Z","image":"/posts/2025/11/21-tgif-nastoyaschie-razrabotchiki/21-tgif-nastoyaschie-razrabotchiki.jpg","permalink":"/posts/2025/11/21-tgif-nastoyaschie-razrabotchiki/","title":"🔥 Пятничное. Настоящие разработчики"},{"content":"🤯 Agile - это не то, что вы думаете В последние месяцы, а может и годы, я все чаще слышу упреки в сторону Agile.\nПерекраивание задач, перекладывание ответственности, отсутствие структуры - список претензий уже звучит как шаблон.\nНо Agile, как и любой инструмент, - это всего лишь инструмент. Результат всегда зависит от того, в чьих руках он оказался. В манифесте нигде не написано: \u0026ldquo;не работайте со стратегией\u0026rdquo;, \u0026ldquo;устраивайте хаос\u0026rdquo;, \u0026ldquo;не планируйте дальше двух недель\u0026rdquo;. Суть Agile в другом - в фокусе на результате, а не на культуре процесса и придуманных нами же ограничениях в виде правил.\nХочу поделиться двумя случаями из практики. Первый изменил мое отношение к правилам, второй - стал для меня примером настоящего Agile.\n💙 Это лояльность к пользователю \u0026ldquo;Be a bit more flexible\u0026rdquo; - сказала мне главный бухгалтер на одном из проектов. Мы делали сервис для сотрудников с оплатой банковскими картами. Один из сценариев предполагал возврат платежей и откат всех движений, если сотрудник в отведенное время не завершил процесс. Моя позиция была проста: \u0026ldquo;не успел в срок - это твои проблемы, мы же все автоматизируем, нужно всего лишь один раз нажать кнопку в начале\u0026rdquo;.\nНа это мне спокойно привели десятки примеров, когда человек объективно может не успеть. И для нас, как для команды, нет никакой ценности в том, чтобы прервать процесс и лишить сотрудника ожидаемого результата. Даже если он сам забыл или отвлекся. В итоге для таких исключений мы добавили дополнительный шаг - приостановку процесса и коммуникацию с опциями \u0026ldquo;дождаться\u0026rdquo; или \u0026ldquo;прервать\u0026rdquo;. Легкое изменение сделало сервис заметно лучше для людей, не разрушив жесткость процесса там, где она действительно нужна.\n🤝 Готовность договариваться Второй случай совсем свежий. Мне нужно было отправить сотрудника на учебные курсы. И здесь столкнулись правила госкорпорации с регламентами учебного центра. Обе стороны были скованы типовыми договорами и этапами оплат. Для одних правила оказались важнее потребностей, вторые оказались готовы к диалогу.\nЛичное общение двух живых людей позволило одной компании получить нужный ресурс и закрыть потребность, а второй - заработать и получили лояльного клиента. Этот вопрос не решался уговорами в стиле \u0026ldquo;ну сделайте для нас исключение\u0026rdquo;. Мы спокойно разобрали условия, поняли, какие риски этими условиями закрываются, хеджировали их - и заключили договор. Ключевое здесь - готовность к диалогу, без каких-то сверхусилий.\n🎯 Люди и ценность, а не набор правил В итоге хочу сказать, что такие примеры - это и есть Agile.\nКогда люди оказываются важнее процессов.\nКогда сотрудничество оказывается важнее бесконечных согласований.\nКогда готовность и открытость к изменениям оказываются важнее жестко установленных рамок.\nAgile - это не хаос. Это когда правила служат ценности, а не ценность приносится в жертву правилам.\n","date":"2025-11-19T05:30:00Z","image":"/posts/2025/11/19-agile---eto/19-agile---eto.jpg","permalink":"/posts/2025/11/19-agile---eto/","title":"🤯 Agile - это не то, что вы думаете"},{"content":"💡 В ИТ уже все придумали Мне приходится немало взаимодействовать с поставщиками ИТ-сервисов. И часто слышу одни и те же фразы: \u0026ldquo;мы не знали, как у вас все устроено\u0026rdquo;, \u0026ldquo;мы только подключились, не знаем ваши процессы\u0026rdquo;. Формально это звучит как оправдание. По факту - признание в том, что базовые принципы ИТ-управления игнорируются. Отрасль уже нашла ответы на большинство вопросов организации работы ИТ-сервиса. Эти подходы описаны, многократно проверены на практике и общедоступны.\n📏 Используйте существующие стандарты ITIL и COBIT десятилетиями помогают компаниям выстраивать управление ИТ-услугами. 1С, взяв за основу ITIL, разработала ТКС - технологию корпоративного сопровождения. Это доступные своды рекомендаций по управлению сервисом.\nРазница между инцидентом, сервисным запросом, изменением и проблемой - не прихоть конкретного CIO, а базовая логика сервиса. Поэтому фраза \u0026ldquo;мы не знаем ваши процессы\u0026rdquo; переводится как \u0026ldquo;мы не знаем принципы управления услугами\u0026rdquo;. Проблема здесь не в уникальности компании. Проблема - в незнании базы.\n🎯 Работайте ради ценности ITIL помимо процессов отвечает на вопрос, ради чего мы все это делаем. Ключевой компонент фреймворка - это система ценности услуг (Service Value System), общая модель того, как из потребностей и возможностей создается ценность.\nИ здесь же дается объяснение, что такое ценность: ответ на наш любимый вопрос \u0026ldquo;чтобы что\u0026rdquo; - выгода, полезность, значимость чего-либо для заинтересованных сторон. Мы действуем не потому что нас попросили, не потому что нам приказали, не потому что в регламенте написано. Наша деятельность - это непрерывный процесс создания ценности. Без понимания этого принципа мы обречены бесконечно делать \u0026ldquo;что-то\u0026rdquo; ради процесса, а не ради результата.\n🤝 Приносите практики вместо отговорок От поставщика ИТ-сервисов я ожидаю не вопроса \u0026ldquo;объясните, как у вас принято\u0026rdquo;, а позиции: \u0026ldquo;мы работаем по отраслевым стандартам и готовы предложить лучшие практики\u0026rdquo;. Он может не знать деталей оргструктуры, но обязан понимать, процесс управления услугами. Зачем прятаться за фразой \u0026ldquo;это не в нашей зоне ответственности\u0026rdquo;? Это не приносит ценности, не помогает клиенту, зато снижает доверие к поставщику и выставляет его в виде дополнительного ограничения. Если вы видите свою ценность в том, что \u0026ldquo;обслуживаете сервера\u0026rdquo; и \u0026ldquo;закрываете тикеты\u0026rdquo;, вы застряли на уровне начинающего сисадмина. Бизнесу важна предсказуемость, скорость, надежность. Сервис должен выстраиваться вокруг этих результатов, а не вокруг списка рутинных операций.\n✅ Вывод прост ИТ-управление - не область, где каждая компания должна изобретать свой велосипед. Фреймворки уже сформировали фундамент, на котором можно строить собственную специфику. И если поставщик их знает и умеет применять на практике, он перестает быть просто исполнителем задач и становится партнером.\nМы в ИТ не существуем ради процессов. Мы существуем ради ценности. И требовать этого от себя и партнеров - обязанность любого ИТ-руководителя.\n","date":"2025-11-17T05:31:55Z","image":"/posts/2025/11/17-v-it-uzhe/17-v-it-uzhe.jpg","permalink":"/posts/2025/11/17-v-it-uzhe/","title":"💡 В ИТ уже все придумали"},{"content":"💥 Сила бессилия Порой кажется, что мы живем в странном мире неестественного отбора: выживает не сильнейший, не умнейший и даже не хитрейший. Выживает слабейший - тот, кто лучше всех умеет притворяться беспомощным. Система защищает слабых. В такой реальности бесполезно что-то уметь, внедрять, оптимизировать. Побеждают те, кто мастерски находит оправдания, прикрывается годами \u0026ldquo;опыта\u0026rdquo; и бесконечно повторяет \u0026ldquo;мы всегда так делаем\u0026rdquo;.\n📉 Планирование неудач Мультипликатор сроков давно заменил планирование. Задача на 5 дней превращается в 15. \u0026ldquo;Уж за такой-то срок точно все успеем\u0026rdquo;. А потом за нее берутся за день до дедлайна и внезапно выясняют, что оценка в 5 дней была не просто так. Контроль? Только на финальной стадии, чтобы убедиться в том что ничего не готово и \u0026ldquo;все полимеры потрачены\u0026rdquo;. Отличный повод рассказать о \u0026ldquo;непредвиденных трудностях\u0026rdquo; и \u0026ldquo;неожиданных сложностях\u0026rdquo;. Вместо релиза рассказы, как было тяжело, как система мешала, как не хватило пары дней.\nМир стал потворствовать этой игре. Компании вознаграждают тех, кто аккуратно оформил провал, а не тех, кто рискнул и довел сложную тему до конца. Результативность устарела. Сочувствие - новая метрика успеха.\n🪞 ИТ зеркало эпохи В ИТ все это видно особенно явно. Любое решение разбивается о сотни объяснений, почему \u0026ldquo;ничего сделать нельзя\u0026rdquo; и \u0026ldquo;у тебя ничего не получится\u0026rdquo;. Продавать неуспех стало нормой. Раньше мы рассказывали, как победили хаос. Сейчас - как \u0026ldquo;героически страдали, но обстоятельства оказались сильнее\u0026rdquo;. На полном серьезе звучат объяснения: \u0026ldquo;ну ты же понимаешь\u0026rdquo;, \u0026ldquo;задача ведь сложная\u0026rdquo;, \u0026ldquo;мы вот хотели и даже делали заявления\u0026rdquo;. Нет, я не понимаю! И отказываюсь это понимать.\nБыстрый разработчик становится угрозой для процесса. Лидер, который требует результата - \u0026ldquo;токсичен\u0026rdquo;. А тот, кто все прощает - \u0026ldquo;понимает реальность\u0026rdquo;.\n🐁 Выживает не тот Сегодня амбиция - это угроза. Рискующий, думающий, действующий - опасен для системы. Его нужно нейтрализовать регламентом, комиссией, процедурой. Побеждает не тот, кто честнее, а тот, кто хитрее в бумажной войне. Система защищает себя бесконечно создавая новые рамки и ограничения. Процессы обрастают слоями формальных согласований. Все это превращается в корпоративные догмы - уже никто не помнит зачем, но соответствовать им становится важнее, чем пробовать новые подходы и выходить на другие высоты. Как так? Архитектуры никогда не существовавших решений не проектируют по утвержденным шаблонам. Решения нерешаемых задач не рождаются из чек-листов.\nНерешительность стала компетенцией. Жалоба - инструментом власти. Неудача - новой нормой.\n🤔 А теперь вопрос Как мы оказались в мире, где сила в бессилии, а главная карьера - это карьера профессионального оправдальщика? Как вернуть ценность тем, кто берет на себя риск, принимает решения и доводит их до конца?\n","date":"2025-11-14T05:30:00Z","image":"/posts/2025/11/14-sila-bessiliya/14-sila-bessiliya.jpg","permalink":"/posts/2025/11/14-sila-bessiliya/","title":"💥 Сила бессилия"},{"content":"🐞 Баг-репорт. Диалог, а не полемика Когда баг попадает в руки разработчика, формируется тернистый путь к исправлению. Он может состоять из уверенных шагов, ведущих к быстрому исправлению, или виться бесконечной спиралью уточнений, проб и ошибок. Разница между этими сценариями часто кроется не в сложности самой ошибки, а в качестве информации.\n🎯 Планка качества Может показаться, что найти баг и написать о нем - просто. Это глубокое заблуждение, особенно когда речь идет об IT-команде, а не о конечном пользователе, который может сказать \u0026ldquo;я что-то нажал и все пропало\u0026rdquo;. Внутри IT ожидания другие. Чем больше информации передается об ошибке, тем легче и быстрее ее идентифицировать. Это не о количестве текста, а о релевантности. Шаги воспроизведения, окружение, суть ошибки и момент возникновения - все что поможет разработчику построить модель происходящего. Неточность порождает гипотезы. Гипотезы порождают ложные шаги. Ложные шаги - это потерянное время.\n🤝 Решение проблемы это win-win Решение инцидента - это не наказание, а общий успех. Когда инженер находит причину, он может сосредоточиться на решении, а не на расследовании. Если тестировщик или аналитки передают точную информацию, они дают возможность войти в контекст за минуты, а не за часы. Минуты предметного анализа экономят часы пустых поисков.\nВ мире 1С это особенно критично. Система многофункциональна, сложна и зависит от множества интеграций. Сообщение \u0026ldquo;в счет-фактуре все сломалось\u0026rdquo; породит множество гипотез. А если уточнить \u0026ldquo;при проведении СФ выданного №00277 в книге продаж строка не появляется\u0026rdquo;, тогда начинается продуктивная работа.\n🚫 Антипаттерны Приведу всего два антипаттерна, как две крайности.\n\u0026ldquo;Все сломалось, разбирайтесь сами\u0026rdquo;. Такой подход затягивает решение. Разработчик должен воспроизвести проблему, а если информации недостаточно, он начинает гадать. Приходится запускать цикл уточнений и снова тратить время. В 1С, где процессы напрямую связаны с бухгалтерией и финансами, задержка означает, что зарплаты не начислены, а отчетность в налоговую не предоставлена. \u0026ldquo;Я лучше вас знаю, это произошло, в модуле регистра сбилась нумерация и коллизия с правами доступа\u0026rdquo;. Такие предположения только запутывают и направляют по неверному пути. Вместо того чтобы разобраться в реальной причине, начинается поиск там, где ничего нет. И когда решение не найдено, наступает момент разочарования для обоих. ✅ Итог Баг-репорт - это язык профессионалов. То, что отличает специалистов от тех, кто просто приносит проблемы. Качественная информация показывает, что вы понимаете процесс, цените свое и чужое время. Вы создаете условия для быстрого и правильного решения с минимальными рисками. Это взаимное уважение, когда каждый понимает, что качество работы одного влияет на результаты другого. Когда это понимание присутствует, команда начинает работать как единый организм, а не как набор людей, занятых поиском виновных и перекладыванием ответственности.\n","date":"2025-11-12T05:30:00Z","image":"/posts/2025/11/12-bag-report-dialog-a/12-bag-report-dialog-a.jpg","permalink":"/posts/2025/11/12-bag-report-dialog-a/","title":"🐞 Баг-репорт. Диалог, а не полемика"},{"content":"💎 Талант нанимать Вспомнил давний эпизод, увидев ролик с Джеком Ма, главой Alibaba, о том, что его главная задача - находить нужных людей. На одном из проектов я запустил SonarQube и через какое-то время с одним из менеджеров обсуждал результаты анализа, сам инструмент и накопленный техдолг. Для меня Сонар был первой линией обороны в потоке бесконечных приемок и утомительных код-ревью. Коллеги, не погруженные в разработку, увидели в нем магического помощника, который находит и подсвечивает дефекты. Разговор о критериях приемки и требованиях к качеству естественно перетек в тему найма.\n🔎 Видение основателя Линейные менеджеры способны объективно оценивать кандидатов в своих доменах. Синьор проверит уровень по технике. Бухгалтер задаст вопросы про дебет, кредит и \u0026ldquo;самолетики\u0026rdquo;. Юрист пройдется по законодательству и судебной практике. Но как быть, когда нужны ключевые роли - CTO, CFO, HRD, в областях, в которых у собственника или CEO не может быть достаточной глубины. Как разглядеть то, что скрыто за идеальным резюме и уверенной подачей. В тех, кто умеет собирать сильные команды, по-видимому проявляется этот особый талант - они видят потенциал, мотивацию, зоны роста, даже если слова звучат одинаково убедительно у всех.\n⚖ Тонкая грань выбора Легко казаться, сложно быть - в управлении людьми это особенно заметно. Я даже не буду пытаться объяснить, как работает найм в таких условиях. Для меня этот дар некоторых людей остается непостижимым. Можно бесконечно улучшать процессы найма, калибровать критерии, учиться видеть слабые сигналы. И все же наступает момент, когда решение опирается на тонкое суждение, которое трудно формализовать и еще сложнее передать. Возможно, это и есть тот талант, умение соединить систему и интуицию так, чтобы команда оказывалась сильнее каждого из нас по отдельности.\n🚨 Цена ошибки Стоит признать, не все владельцы и CEO владеют этим навыком. В команды начинают попадать люди с чуждой культурой и иными целями. Напряжение растет, копится тихое раздражение. Возникает чувство несправедливости: те, кто делают, оказываются в тени тех, кто говорит. Решения становятся нелогичными, как будто их принимают не из стратегии, а из удобства момента. Слова начинают стоить дороже дела - презентации вытесняют результат, ответственность размазывается по цепочке согласований.\n✍ Выводы Сложно подвести какие-то итоги. Я не знаю как это работает и не могу объяснить. Я не верю в случай и уверен, что люди с этой суперспособностью на случай не рассчитывают, а делают уверенный выбор. Глядя на лидеров индустрии, понимаешь - однажды они сделали правильную ставку, смогли выиграть там, где большинство сошло с дистанции. Рад за тех, кому повезло стать частью таких команд. И шлю лучи поддержки остальным.\n","date":"2025-11-10T05:30:00Z","image":"/posts/2025/11/10-talant-nanimat/10-talant-nanimat.jpg","permalink":"/posts/2025/11/10-talant-nanimat/","title":"💎 Талант нанимать"},{"content":"🔥 Пятничное. Когда бумага заменяет ценность Ты замечал, как договор раздувается до ритуальной книги? В нем растут требования к отчетности - не к пониманию проблем и не к улучшению процессов, а к самому факту наличия форм. Появляются таблицы, которые никто не читает, графики, которые переделывают три раза ради соответствия шаблону, и тексты, предназначенные исключительно для аудита. В этот момент ценность перестает быть целью, а становится побочным эффектом между двумя подписями. Неделя уходит не на релиз, а на охоту за запятыми. ИТ рапортует о трансформации, а живет по тетрадке согласований.\n🧻 Бесконечный рулон бюрократии Каждый новый контракт приносит новый слой отчетности. Не потому что стало больше ценности, а потому что \u0026ldquo;а вдруг будут проверять\u0026rdquo;. Команда переквалифицируется в клерков: собери статистику, сверь с реестром, скопируй в другой реестр, отправь PDF по почте, переложи PDF в папку \u0026ldquo;финал_точно\u0026rdquo;, распечатай, подпиши, отсканируй отправь скан через ЭДО. Автоматизации нет времени махнуть рукой - завтра дедлайн по новой форме. Как в анекдоте: \u0026ldquo;почему не точишь пилу?\u0026rdquo; - \u0026ldquo;нет времени, я пилю\u0026rdquo;.\n📉 Две траектории, два мира Есть компании, которые резервируют целые дни на сбор статистики для отчетов, которые никто не откроет. И есть те, кто в это же время выпускает продукт за продуктом. Первые живут в альтернативной физике: чем больше отчетов, тем будто \u0026ldquo;выше контроль\u0026rdquo;; чем сложнее форма, тем \u0026ldquo;серьезнее подход\u0026rdquo;. Абсурд превращается в норму, и уже сложно вспомнить, ради чего вообще существует ИТ. Вторые просто работают. У них ценность первична, документ вторичен. Угадаешь, где быстрее растет выручка?\n⏳ Период отчетности Знаком термин - \u0026ldquo;период отчетности\u0026rdquo;? Календарь выгорает, оперативная работа встает, все силы уходят на ежемесячный отчет. Каждую цифру перепроверяют, потому что \u0026ldquo;если будет ошибка, начнутся разборы\u0026rdquo;. Пока ты ищешь старые логи, на вход уже прилетели две новые задачи. Для них, конечно, разработают новый шаблон. Кольцо сжимается все сильнее: подготовка отчетов становится критичным ресурсом, сама работа - фоном. Театр абсурда, где роли расписаны, а сценарий никто не помнит.\n🤦 Короче Если узнаешь в этом свою организацию - это не про дисциплину и не про зрелость. Пока ты обосновываешь каждую клетку в форме, рынок меняется. Пока команда борется с документооборотом, лучшие пишут резюме и уходят туда, где работают, а не заполняют бланки. Тем, кто еще делает продукт и приносит ценность, искренне желаю роста и смелости. Тем, кто превратил бумагу в религию, я не желаю ничего - для этого придется заполнить утвержденный бланк, собрать десяток виз, подшить оригинал и вернуться через десять дней.\n","date":"2025-11-07T05:30:46Z","image":"/posts/2025/11/07-tgif-kogda-bumaga/07-tgif-kogda-bumaga.jpg","permalink":"/posts/2025/11/07-tgif-kogda-bumaga/","title":"🔥 Пятничное. Когда бумага заменяет ценность"},{"content":"🎛️ Контролировать или управлять? Когда фреймворки управления ИТ начали входить в мою жизнь, ITIL стал фаворитом как понятный сборник практик. Однако меня интересовали и другие инструменты, в частности COBIT (Control Objectives for Information and Related Technology). Просматривая запись конференции о COBIT отметил для себя слова спикера, в которых он делился интересным случаем, с которым столкнулся занимаясь переводом фреймворка на русский язык. \u0026ldquo;Control\u0026rdquo; в COBIT, это контроль или управление? Ответ оказался простым - и то, и другое. Контроль и управление - две стороны одной медали. Без одного не бывает другого.\n✈️ Нужно вообще контролировать? Думаю, аналогия с пилотом самолета здесь будет уместна. Пилот управляет воздушным судном, контролируя показания приборов - высоту, скорость, курс, давление в системах. Без контроля не было бы управления. Данные с приборов дают пилоту картину реальности, на основе которой он принимает решения.\nТо же самое должно происходить в управлении процессами, проектами и качеством. Но часто менеджеры игнорируют \u0026ldquo;приборную панель\u0026rdquo; своих процессов и затем удивляются, почему самолет падает.\n📊 Что можно контролировать? Процессы. Для контроля и управления процессом нужны метрики. Цикл разработки, скорость доставки изменений, время обработки багов, пропускная способность команды. Регулярные ретроспективы, для анализа и оптимизации процесса. Проекты. Для управления нужен статус-трекинг, реестр рисков, анализ отклонений от плана, определение критического пути, распараллеливание задач, управление ресурсами. Код. Код отклоняется от идеала, накапливается техдолг. Чтобы управлять качеством, его нужно контролировать: статический анализ, код-ревью, и покрытие тестами. Знания. Создание, хранение, распространение и использование информации внутри команды. Актуальной документация, вики, базы знаний, шаблоны и чек-листы. 🚫 Антипаттерны \u0026ldquo;Отдам задачу программисту и все получится\u0026rdquo;. Это не управление, а рулетка с распределением и перекладыванием ответственности. \u0026ldquo;Какие сроки\u0026rdquo; как единственный инструмент управления проектом. Просто лишнее давление на исполнителя, который будет придумывать сроки, только бы отвязаться. \u0026ldquo;Все идет хорошо\u0026rdquo; как как единственный статус. Без критериев и реального контроля превращается во \u0026ldquo;все плохо\u0026rdquo; в день дедлайна.\nНельзя управлять, если не знаешь этапы процесса, игроков, текущий результат и следующие шаги. 📌 Выводы Управление - это принятие решений на основе данных. Контроль - получение этих данных Когда цель и способ управления ясны, набор необходимых метрик становится очевидным. Выберите показатели, которые отражают прогресс и качество, настройте дашборды и регулярные циклы обратной связи. Тогда контроль становится инструментом управления, а управление - не надеждой, а действием.\n","date":"2025-11-05T05:29:59Z","image":"/posts/2025/11/05-kontrolirovat-ili-upravlyat/05-kontrolirovat-ili-upravlyat.jpg","permalink":"/posts/2025/11/05-kontrolirovat-ili-upravlyat/","title":"🎛️ Контролировать или управлять?"},{"content":"🕵️ Медленная работа 1С для начинающих Не думал, что придется писать о базовых вещах, но суровая реальность показывает - даже в крупных проектах эта база часто игнорируется. И результат - потерянное время, необоснованные предположения, неправильно принятые решения. Если на руках только сама 1С можно действовать системно.\n🧭 А с чего начать? Первый вопрос, которым стоит задаться - действительно тормозит? Банально, но критически важно. Проводится миллион документов и уже 5 минут \u0026ldquo;крутит\u0026rdquo;? Или минуту открывается стандартная форма? Далее - начало тормозить, или \u0026ldquo;вот уже пять лет как тормозит\u0026rdquo;? Всегда страдали от тормозов? Или раньше летало, и вот - резко упало? Наконец - тормозит, это сколько в миллисекундах? Тормозит, потому что 2 секунды, а хотим 0,2? Или потому что 2 минуты, а всегда было 2 секунды?\nЭто база - объективная и измеримая информация. Снимает множество вопросов, сомнений и пустых предположений. То, с чего должно начинаться любое расследование. 📊 А как данные собрать? Хорошая новость. Встроенный инструментарий для базового анализа в большинстве случаев доступен из коробки. Без дополнительных инструментов. Без заббиксов и прометеусов.\n1С замеряет время выполнения ключевых операций. Кто, когда, что, сколько времени заняло. Остается за проанализировать замеры стандартными отчетами.\nОбщая диаграмма по дням - есть отклонения? По ключевой операции - есть рост времени выполнения? По пользователями - замеры нашего пользователя отличаются от общих?\nЧерез две минуты видно ясную, объективную и визуализированную картину. Пики, сравнение с прошлыми периодами, с другими пользователями.\nЭта информация определит следующие шаги. 🧪 А что дальше? Пробуем воспроизвести проблему в тестовой среде.\nИ здесь нас может ждать подвох - есть вероятность что ничего не воспроизведется. Потому что инфраструктура другая. Регламенты обслуживания БД отличаются.\nАналитик тестирует, сидя в офисе на гигабитном интернете. А пользователь за полярным кругом раздает интернет с Нокио 3310, за ноутбуком, которому сорок лет, и пытается отредактировать документ с тысячей строк.\nЕще одна развилка влияющая на следующие этапы и схему эскалации\n🛠️ А что теперь? Вся объективная информация собрана, медленная работа воспроизводится в тестовой среде - можно передать задачу программисту. И теперь программист будет работать не с перекинутой задачей \u0026ldquo;ой там что-то сломалось иди чини\u0026rdquo;, а с конкретными и понятными данными:\nКонкретные цифры о времени выполнения Информация о динамике проблемы, когда сломалось Сценарий и условия воспроизведения\nМожно не гадать, а заниматься осознанным поиском конкретной проблемы в конкретном месте. ✅ Вывод Главный вывод простой: не верьте первым ощущениям, вникайте в цифры. Системность и объективность – залог решения проблем, в том числе медленной 1С. Когда все сделано по шагам, \u0026ldquo;тормоза\u0026rdquo; превращаются из загадки в конкретную задачу, которую можно решить.\n","date":"2025-11-03T05:29:59Z","image":"/posts/2025/11/03-medlennaya-rabota-1s/03-medlennaya-rabota-1s.jpg","permalink":"/posts/2025/11/03-medlennaya-rabota-1s/","title":"🕵️ Медленная работа 1С для начинающих"},{"content":"🔥Пятничное. Бирюзовые проблемы - когда все \u0026ldquo;за\u0026rdquo;, но никто не делает Утопия XXI века. Бирюзовая команда - никакой иерархии, коллективная ответственность, равные решают вместе, горизонтальность, самоорганизация, счастье. В это веришь, пока не столкнешься с простой вещью: человеческой природой. Лень, некомпетенция, страх ответственности, желание отсидеться. И главное - размазанная ответственность.\n🎯 Мы, значит никто Когда все за все отвечают - не отвечает никто. \u0026ldquo;Мы должны сделать\u0026rdquo; мгновенно превращается в \u0026ldquo;Кто-то должен сделать, но точно не я\u0026rdquo;. В бирюзовых командах нет того, кто может настоять, проконтролировать, заставить. Это не баг - это фича модели. И этим мгновенно начинают пользоваться.\nВ команде быстро появляются люди, которые понимают: можно ничего не делать. Инициативу брать необязательно. Никто не скажет \u0026ldquo;это твоя задача, ты за нее отвечаешь\u0026rdquo;. Все будут поддерживать морально, ходить на встречи, участвовать в обсуждениях - но вместо результата будет болталогия.\n💀 В чем опасность Неравная вовлеченность. Мечта о том, что все будут одинаково мотивированы - иллюзия. Кому-то реально нужен результат. Кому-то - \u0026ldquo;и так сойдет, но если ты сделаешь, то здорово\u0026rdquo;. Угадай, кто будет тащить все на себе. Эксплуатация ответственных. Если ты оказался заинтересованным в результате - поздравляю. Будешь уговаривать, мотивировать, организовывать. А потом сам делать, потому что тебе надо, а им - нет. На митингах все будут кивать, поддерживать. Но делать не будут. Имитация деятельности. Это идеальная среда для тех, кто создает видимость. Обсуждения, синки, ретро, фасилитация - все выглядит как дело, но ничего не делается. 🍦Системная проблема Коллективная ответственность - это отсутствие ответственности. Чем больше людей отвечают за задачу - тем меньше шанс, что кто-то возьмет ее на себя.\nБирюзовые принципы хороши в теории. В жизни побеждает системность, явные роли, персональный KPI и менеджер, который не боится слова \u0026ldquo;контроль\u0026rdquo;. Не демагогия о самоорганизации, а жесткое делегирование с проверкой результата.\n💡 Что работает вместо бирюзы Персональная ответственность. Задача закреплена за человеком. Он отвечает. Не команда, не \u0026ldquo;мы\u0026rdquo; - он. Прозрачные KPI. Не абстрактная \u0026ldquo;вовлеченность\u0026rdquo;, а конкретные метрики: что сделано, что не сделано, почему и в какие сроки. Контроль. Не модно, не бирюзово. Но это работает. Делегируй, но проверяй. Доверяй, но контролируй. Лидерство. Нужен не фасилитатор и не коуч, а лидер, который принимает решения, берет ответственность и требует результат. Который может сказать \u0026ldquo;нет\u0026rdquo;, \u0026ldquo;делай\u0026rdquo;, \u0026ldquo;ты отвечаешь\u0026rdquo;. И самое главное - может выгнать из команды. 🔪 Короче Бирюзовые команды - рай для тех, кто не хочет отвечать за провал. Обертка для размывания ответственности и имитации деятельности. Когда нужен результат, а не атмосфера, такие команды проигрывают.\n","date":"2025-10-31T05:29:59Z","image":"/posts/2025/10/31-tgif-biryuzovye-problemy/31-tgif-biryuzovye-problemy.jpg","permalink":"/posts/2025/10/31-tgif-biryuzovye-problemy/","title":"🔥Пятничное. Бирюзовые проблемы - когда все \"за\", но никто не делает"},{"content":"🚀 Про гарантию качества Сегодня о гарантии работоспособности пользовательских сценариев. То есть об уверенности, что после любых доработок и обновлений ключевые операции работают как прежде. В мире 1С слишком часто звучит \u0026ldquo;все проверить невозможно, пусть пользователи тестируют\u0026rdquo;. Перекладывать ответственность на пользователей нельзя - это риск для бизнеса и удар по доверию к ИТ.\n🧪 Как добиться гарантии Получить гарантию просто - сплошное тестирование каждого релиза. Конец. Но на практике ручное тестирование дорого, долго и ненадежно из-за человеческого фактора. Альтернатива - автотесты. При каждом изменении запускать заранее подготовленный набор проверок.\nПреградой может быть отсутствие опыта - 1С-ники довольно ортодоксальны и с ужасом смотрят на что-то незнакомое.\n💼 Зачем это бизнесу Если мы, как сервис-провайдер, предоставляем бизнесу систему, то должны давать гарантию стабильности и предсказуемости. Можно тестировать руками, а можно автоматически. Это зависит от уровня зрелости ИТ. Тест-клиент появился в платформе 1С в 2012 году. Если ваши партнеры не умеют с ним работать, они отстают от отрасли \u0026ldquo;всего\u0026rdquo; на 10 лет.\n🧰 Инструменты К счастью, доступны инструменты и от самой фирмы 1С, и от сообщества:\n1С:Сценарное тестирование - запись действий пользователя и воспроизведение тестов. 1С:Автоматическое тестирование конфигураций - запуск наборов сценариев и статический анализ. xUnit для 1С - модульные тесты для функций и процедур. Vanessa Automation - сценарное тестирование, понятное аналитикам и бизнесу. 🤖 Почему Vanessa Automation Vanessa позволяет записывать сценарии и запускать их на реальной базе 1С, эмулируя действия пользователя - открытие форм, ввод данных, проведение документов. Эти сценарии многократно прогоняются автоматически или запускаются вручную, а проверки на каждом шаге подтверждают ожидаемый результат. Если что-то пошло не так - тест упадет со ссылкой на конкретный шаг. Начать можно вручную, а затем встроить прогоны в CI.\n🧑‍🎓 С чего начать Выберите Vanessa Automation как базовый инструмент. Запишите пробный сценарий - прочувствуйте простоту и скорость. Выберите 5-10 сценариев для записи, возможно, вы уже тестируете их руками. Отправьте аналитиков на курсы по автоматическому тестированию – опционально, но кроме инструмента научат еще и методологии. Введите правило: перед рефакторингом и при закрытии изменения создавать соответствующий автотест.\nЕсли есть CI (например, Jenkins-lib) - можно положить наборы тестов рядом с проектом для автоматического запуска. ✅ Итог Автотесты - реальный инструмент управления качеством. Он дисциплинирует команду (каждая доработка сразу проверяется), снижает нагрузку на поддержку, и главное - экономит нервы ваших пользователей. Фраза \u0026ldquo;пусть пользователи найдут ошибки\u0026rdquo; должна остаться в прошлом. Инструменты доступны, порог входа невысок, а выгода очевидна - меньше дефектов, быстрее релизы и больше доверия к ИТ.\n","date":"2025-10-29T05:30:00Z","image":"/posts/2025/10/29-pro-garantiyu-kachestva/29-pro-garantiyu-kachestva.jpg","permalink":"/posts/2025/10/29-pro-garantiyu-kachestva/","title":"🚀 Про гарантию качества"},{"content":"⚙️ ИТ, которое автоматизирует само себя ИТ пронизывает нашу обыденную жизнь - как новая математика или письмо. Мы соприкасаемся с результатами работы айтишников постоянно и чаще всего не задумываемся об этом. Для ИТ-компаний создание и внедрение цифровых продуктов - основная деятельность. В других это обычно ИТ-сервис - от эникейщиков до собственной внутренней разработки, для них это кост-центр. Но по сути все айтишники создают и поддерживают автоматизацию: мы помогаем делегировать машинам рутину и неинтересные задачи.\n🔁 Автоматизация как привычка И здесь есть интересный феномен: мы любим делать то, что мы делаем. Любим писать код, искать решения, автоматизировать рутину. В перерывах между потоками бизнес-задач начинается самоавтоматизация и ускорение собственных процессов: скрипты развертывания, наблюдаемость, автоматизация своей рутины. Это как роботы, которые придумывают новых роботов.\n🤖 Почему это работает Потому что собирать метрики скучно, а наблюдать на дашбордах - красиво. Потому что копаться в логах тяжело, а в ELK - просто. Потому что ошибки в журналах никто не смотрит, а на алерты в чатах реагируют быстро.\nСначала работаем с данными. Становится скучно их обрабатывать - пишем скрипт для обработки. Надоедает запускать скрипт и копировать результат - пишем бота.\nПоявляется цифровой помощник, который для нас делает отчет за пять секунд, а остальные сотрудники тратят на это день. 🎮 Мотивация инженеров Нами двигают не громкие слова, не высокие цели, не таски на доске - это просто интересно и весело. Это феномен айтишников в принципе: на работе работают, а развлекаются в опенсорсе и на хакатонах. На GitHub появляются проекты, доступные всем здесь и сейчас.\n🧩 Опенсорс и 1С Масштаб понятен на примере NGINX - веб-сервер с открытым кодом используется примерно на трети всех сайтов. Есть и множество проектов по 1С - инструменты для тестирования и сборки, контроля качества и мониторинга, гайды и инструкции. Vanessa Automation для BDD, плагин SonarQube для языка BSL - это уже классика, а не экзотика.\n⛏️ Ограничения Для таких возможностей нужен ресурс. Если в компании один эникейщик, который одновременно меняет картриджи в принтерах, готовит бюджет на коврики для мышек, ведет проекты по внедрению ERP и протирает монитор у генерального директора, то на развитие времени не останется. Не потому, что он не достиг необходимого уровня зрелости, а потому, что компания его не достигла.\n💡 Влияние на бизнес Автоматизация ИТ-процессов напрямую влияет на эффективность бизнеса. Рефакторинг снижает TCO за счет упрощения поддержки и регулярных обновлений. Внедрение CI/CD пайплайнов уменьшает количество ошибок в проде и повышает предсказуемость релизов. Создание библиотек и шаблонов ускоряет интеграции и сокращает время вывода новых функций. Метрики и наблюдаемость позволяют быстрее реагировать на сбои, снижая простои и улучшая SLA. Все это в итоге помогает бизнесу.\n","date":"2025-10-27T05:30:00Z","image":"/posts/2025/10/27-it-kotoroe-avtomatiziruet/27-it-kotoroe-avtomatiziruet.jpg","permalink":"/posts/2025/10/27-it-kotoroe-avtomatiziruet/","title":"⚙️ ИТ, которое автоматизирует само себя"},{"content":"🔥 Пятничное. Факты, которые особенно дороги Мы живем в экономике презентаций: решения и бюджеты сегодня продаются цифрами. Спонсоры, комитеты и кураторы проектов хотят видеть графики с растущими стрелками, KPI выше рынка и аккуратные проценты улучшений. Без чисел любая инициатива кажется слабой - и это создает давление на всех участников цепочки: продукт, продажи, подрядчиков.\n💬 Интересная статистика 78% компаний заказной разработки в России имеют опыт работы с крупными международными брендами. Это подтверждается анализом портфолио ведущих digital-агентств.\nПри этом 82% проектов завершаются в срок, а средняя экономия бюджета заказчика достигает 13% от первоначальной сметы. Исследования показывают, что компании, работающие по Agile и Scrum, на 43% эффективнее завершают проекты, чем те, кто использует устаревшие подходы.\nКаждый второй подрядчик предоставляет прозрачность - доступ к тасктрекеру, еженедельные демо, контроль качества. Внедрение CI/CD сокращает сроки на 67%, а количество ошибок в продакшне снижается на 84%.\nК тому же стоимость часа senior-специалиста у таких компаний примерно на 30% ниже рынка.Благодаря оптимизированным процессам.\nЗвучит впечатляюще, правда? 🎭 Неинтересная статистика А теперь главное - все эти \u0026ldquo;факты\u0026rdquo; не имеют никакого отношения к реальности.\nЦифры красивые, формулировки убедительные. Но факты не факты. И именно они особенно дороги, потому что платить за них приходится высокую цену.\nМы сталкиваемся с этим каждый день.\nКогда запрашиваем предложение от подрядчиков. Когда читаем резюме кандидатов. Когда листаем портфолио с логотипами “Сбера” и “Яндекса”. Когда слушаем рассказ о “200 успешных проектах” и “15 годах на рынке”.\nРеальность куда менее глянцевая: 73% специалистов теряют заказы из-за пустого портфолио и создают фейковые кейсы с несуществующими брендами. Логотипы крупных компаний часто означают работу через посредников, где проект трогали десятки рук. “Опыт работы с брендами” сводится к учебным задачам. 🧪 Старт реальной работы: где рушатся ожидания Когда шоу на пресейле заканчивается, вскрывается приземленная рутина:\nО лучших практиках в компаниях слышали, но превратить их в рабочую дисциплину мало кто умеет: DoR/AC/DoD остаются на слайдах, code review формально, UAT без сценариев, тестовые данные отсутствуют. Уверенные слова о владении практиками, дипломы, сертификаты, богатое портфолио, но нет умения применять знания на деле, задачи буксуют, дедлайны сдвигаются. Презентации продукта безупречные, доступно все из коробки и даже больше, а при внедрении функционал оказывается ограниченным, интеграции требуют доработок, производительность падает под нагрузкой.\nИменно здесь, при старте работ, сгорает львиная доля доверия и бюджета. 📎 P.S. Единственная невыдуманная цифра в этом посте - 73% фрилансеров теряют заказы из-за отсутствия портфолио. Но это не точно.\n","date":"2025-10-24T05:32:01Z","image":"/posts/2025/10/24-tgif-fakty-kotorye/24-tgif-fakty-kotorye.jpg","permalink":"/posts/2025/10/24-tgif-fakty-kotorye/","title":"🔥 Пятничное. Факты, которые особенно дороги"},{"content":"🔧 Инциденты в 1С: плейбук без суеты При инцидентах критично важно как можно быстрее восстановить сервис. При неопределенности команда теряет время, а пользователи ждут. \u0026ldquo;Само прошло\u0026rdquo; или \u0026ldquo;не воспроизводится\u0026rdquo;, это признак низкого уровня зрелости и отсутствия понятного процесса.\n🎯 Цель Максимально быстро восстановить работу - главная цель. Поиск корневой причины может занять больше времени, но сервис должен заработать как можно раньше. Ключевой вопрос при оценке статуса инцидента - пользователь спасен?\n⚖️ Приоритизация Сколько пользователей или процессов затронуто? Насколько критично время решения для бизнеса?\nЕсли прод упал для тысячи пользователей - немедленная эскалация и привлечение всех доступных ресурсов. Если косметическая ошибка у одного пользователя - разбор в спокойном режиме. 🌡️ Первичная диагностика Минимум данных: когда и где случилось, что делал пользователь, разовая ли проблема, сколько затронуто, были ли изменения. Проверяем базу знаний, журналы, логи, доступность серверов и обменов. Если быстрого решения нет или пошли дубли обращений - эскалируем.\n🛠️ Восстановление сервиса Workaround: перезапуск сервиса/кластера, переключение на резерв, альтернативный сценарий, откат релиза. Обязательно зафиксировать, что применен обход. Постоянное решение: после восстановления устраняем корень. 🔎 Расследование (RCA) После восстановления - ищем причину. Методика \u0026ldquo;5 почему\u0026rdquo; помогает докопаться до истины, а не остановиться на симптоме. Ошибка формы - обращение к несуществующему элементу - опечатка - тест не отловил - нет регламента тестирования. Вывод: меняем регламент.\n⚡ Быстрая диагностика Журнал регистрации: ошибки за последние часы. Нагрузки CPU/RAM/Disk на серверах 1С и СУБД. Блокировки в СУБД. Логи обменов и очереди. Технологический журнал 1С. ✅ Закрытие Пользователь подтвердил решение, решение и обход задокументированы, база знаний обновлена, тикет закрыт, меры для недопущения повторов приняты.\n🚫 Типичные ошибки \u0026ldquo;Само прошло\u0026rdquo;, \u0026ldquo;не воспроизводится\u0026rdquo; - добавьте логирование.\nИщем корень до восстановления - сначала спасти, потом разбираться.\nНет классификации - реагируем одинаково на все.\nОбвиняем пользователя - если можно ошибиться, это проблема системы.\n📈 Модель зрелости Реактивный: хаос, знаний нет, инциденты повторяются. Управляемый: регистрация, SLA, база знаний. Проактивный: мониторинг, регулярные RCA. Оптимизирующий: MTTR/SLA, автоматизация типовых решений, PDCA. Предиктивный: AIOps, авто-классификация, превенция. 📝 Чек-лист Инцидент зарегистрирован. Присвоен приоритет (Impact x Urgency). Сервис быстро восстановлен через workaround. RCA оформлен, корень подтвержден фактами. Постоянный фикс внедрен и проверен. Знания обновлены, тикет закрыт с подтверждением пользователя.\nПрофессиональная поддержка - это не отсутствие сбоев, а быстрый restore, факты из логов и регулярные улучшения по итогам каждого инцидента. ","date":"2025-10-22T05:29:59Z","image":"/posts/2025/10/22-intsidenty-v-1s/22-intsidenty-v-1s.jpg","permalink":"/posts/2025/10/22-intsidenty-v-1s/","title":"🔧 Инциденты в 1С: плейбук без суеты"},{"content":"🎭 Корпоративные ценности на стене - почему декларации не работают \u0026ldquo;Мы ценим инициативу\u0026rdquo;, \u0026ldquo;Открыты к изменениям\u0026rdquo;, \u0026ldquo;Растем вместе\u0026rdquo;.\n\u0026ldquo;Мы всегда так делали\u0026rdquo;, \u0026ldquo;Инициатива наказуема\u0026rdquo;, \u0026ldquo;Ничего не изменится\u0026rdquo;.\nРазрыв между декларируемыми ценностями и реальной культурой - не лицемерие, а симптом системной болезни. Он убивает мотивацию, гасит инициативу и делает любую трансформацию бесполезной.\n🎯 Две культуры в одной компании В организации могут жить две культуры. Официальная - на слайдах PowerPoint: \u0026ldquo;Мы ценим инициативу\u0026rdquo;, \u0026ldquo;Открыты к изменениям\u0026rdquo;, \u0026ldquo;Поощряем развитие\u0026rdquo;. И реальная - на местах: \u0026ldquo;Мы всегда так делали\u0026rdquo;, \u0026ldquo;Ничего не сработает\u0026rdquo;, \u0026ldquo;Инициатива наказуема\u0026rdquo;.\nПобеждают не слова на лендингах и конференциях, а реальные действия, то, как ведут себя люди каждый день.\n💀 Как декларации превращаются в формальность На стратегических сессиях говорят о трансформации, гибкости и росте. В отделах звучит другое: \u0026ldquo;Еще одна блажь сверху\u0026rdquo;, \u0026ldquo;Нам бы отчеты сдать\u0026rdquo;, \u0026ldquo;И так не вывозим, а они нам еще работы придумали\u0026rdquo;.\nСредний менеджмент становится фильтром между словами и действиями. Он не верит в поддержку, но знает, как выглядят разборы полетов, если эксперимент не сработает. Энтузиасты выгорают, а циники получают стабильность.\n\u0026ldquo;Мы всегда так делали\u0026rdquo; - не про опыт, а про страх. Можно годами работать по-старому и считаться надежным. А тот, кто предлагает новое, рискует. Не сработает - виноват. Сработает - \u0026ldquo;повезло\u0026rdquo;. \u0026ldquo;Ничего не сработает\u0026rdquo; - форма самозащиты. Предсказал провал - и оказался прав. Это стратегия выживания после десятков \u0026ldquo;инициатив сверху\u0026rdquo;. \u0026ldquo;Инициатива наказуема\u0026rdquo; - коллективная память. Те, кто пробовал, теперь молча наблюдают, как новые энтузиасты наступают на те же грабли. \u0026ldquo;Во всех других отделах дураки\u0026rdquo; - симптом отсутствия общих целей. Такая культура делает любые DevOps- или Agile-инициативы бессмысленными. ⚙️ Почему декларации не работают Ценности ломаются там, где слова расходятся с поведением. Говорят \u0026ldquo;ошибки - это опыт\u0026rdquo;, а через минуту требуют \u0026ldquo;чтобы больше такого не было\u0026rdquo;. Говорят \u0026ldquo;гибкость\u0026rdquo;, но для согласования простого изменения нужно три недели и пять подписей. Говорят \u0026ldquo;инициатива\u0026rdquo;, но назначают ответственных за то, чего сами боятся.\nВыстраивается защита: \u0026ldquo;сделаем вид\u0026rdquo;, \u0026ldquo;переждем\u0026rdquo;, \u0026ldquo;заполним отчет\u0026rdquo;. Люди становятся хранителями статус-кво - не из вредности, а из инстинкта самосохранения. Система поощряет тех, кто не рискует.\n📋 Итог Если топы говорят \u0026ldquo;гибкость\u0026rdquo;, а на местах \u0026ldquo;мы всегда так делали\u0026rdquo; - значит, есть разрыв между фантазиями и реальностью.\nТри вопроса для самопроверки:\nЕсть ли у сотрудников пространство для экспериментов и обучения на ошибках? Кого продвигают - тех, кто живет ценностями, или тех, кто дает результат любой ценой? Что говорят о компании те, кто уволился?\nОтветы на эти вопросы покажут настоящие ценности. Ежедневные решения - каждое \u0026ldquo;да\u0026rdquo; и \u0026ldquo;нет\u0026rdquo; - формируют культуру быстрее, чем любые стратегические сессии. Посмотрите, за что в компании наказывают и за что благодарят. ","date":"2025-10-20T05:29:59Z","image":"/posts/2025/10/20-korporativnye-tsennosti-na/20-korporativnye-tsennosti-na.jpg","permalink":"/posts/2025/10/20-korporativnye-tsennosti-na/","title":"🎭 Корпоративные ценности на стене - почему декларации не работают"},{"content":"🔥 Пятничное: Методики не работают Что общего между SMART, \u0026ldquo;5 почему\u0026rdquo;, Definition of Done, ретроспективами и Acceptance Criteria? Все про них слышали. Все кивают на тренингах. И никто этим не пользуется.\nДавайте честно: все знают как ставить задачи по SMART. Конечно все. А теперь откройте свой Service Desk и посмотрите на реальные заявки:\n\u0026ldquo;Ой, у меня что-то не работает, нашел незакрытые задачи, кстати процесс не работает, и надо проверить документы по старой заявке, в бюджете не те статьи, сбросьте мне пароль и принесите чай\u0026rdquo;.\n🎭 Красивые фреймворки и грустная реальность \u0026ldquo;5 почему\u0026rdquo; - элегантный метод поиска корневой причины. На тренингах все восторгаются: \u0026ldquo;Вот это да! Так просто!\u0026rdquo; Через неделю в продакшне падает сервис.\nПочему упало? Потому что Вася криво настроил.\nВсе, нашли виноватого, расходимся.\nНикаких пяти \u0026ldquo;почему\u0026rdquo;. Никакого поиска системной проблемы. 👌 Definition of Done - который никто не соблюдает Definition of Done фиксирует, что значит \u0026ldquo;готово\u0026rdquo; для задачи: не \u0026ldquo;код скомпилился\u0026rdquo;, а \u0026ldquo;цель достигнута без сюрпризов\u0026rdquo;. Когда DoD есть только в Confluence, а в жизни им не пользуются, релизы превращаются в русскую рулетку.\nКак это выглядит на практике:\n\u0026ldquo;Код я написал\u0026rdquo; \u0026ldquo;В моей базе работает\u0026rdquo; \u0026ldquo;Один из двадати сценариев проверен\u0026rdquo;\nDoD - не плакат в вики. Это контракт команды с бизнесом и поддержкой: если \u0026ldquo;готово\u0026rdquo; - то готово без кавычек. ⏪ Ретроспективы, которых нет Scrum Guide прямо говорит: ретроспектива обязательна. Это время, когда команда анализирует, что пошло не так и как улучшить процессы. В теории.\nНа практике:\nРетро не проводятся вообще, потому что \u0026ldquo;и так все понятно\u0026rdquo; Ретро превращаются в формальность: 15 минут, все молчат, Scrum Master сам с собой говорит На ретро находят проблемы, записывают action items\u0026hellip; и забывают про них до следующей ретро\nМетодика есть. Время выделено. Результата ноль. Потому что команда не верит, что что-то изменится. И правда не меняется - потому что action items никто не выполняет. ✅ Acceptance Criteria - которых никто не написал Acceptance Criteria должны фиксировать, что именно считается приемкой результата: условия, сценарии, границы. Когда AC нет, встречаемся на тестировании и узнаем, что бизнес \u0026ldquo;имел в виду другое\u0026rdquo;. Начинается пинг-понг: правки - возвраты - обиды.\nЗадача сформулирована общими словами: \u0026ldquo;сделать удобнее\u0026rdquo;, \u0026ldquo;ускорить обработку\u0026rdquo;, \u0026ldquo;поддержать интеграцию\u0026rdquo;. Ни одного конкретного критерия. UAT превращается в квест: каждый видит по-своему, спорим о вкусе, а не о критериях. В проде появляются сюрпризы: поведение на краях не обсуждалось, регламенты не обновлены, смежные роли не предупреждены. 🤡 Что смешного Все знаю SMART, ITIL, Agile и много других красивых слов.\nМы внедряем фреймворки, чтобы показать инвесторам или руководству: \u0026ldquo;Смотрите, мы современные, мы по ITIL работаем!\u0026rdquo; А на деле продолжаем как раньше - по наитию, через хаос и героизм отдельных людей.\nИ самое смешное? Мы жалуемся: \u0026ldquo;Вот эти ваши методики не работают!\u0026rdquo; Работают. Просто вы ими не пользуетесь.\n","date":"2025-10-17T05:29:59Z","image":"/posts/2025/10/17-tgif-metodiki-ne/17-tgif-metodiki-ne.jpg","permalink":"/posts/2025/10/17-tgif-metodiki-ne/","title":"🔥 Пятничное: Методики не работают"},{"content":"🏢 Размер XL: когда в проекте миллионы строк SonarQube тактично отмечает ERP с 14 миллионами строк как XL. Хотя, если посмотреть на размерную сетку, то Extra Large считаются все проекты с количеством строк свыше 500 тысяч.\n🖨️ Обновления вендора Конфигурации большие, изменений много. Зачем их обновлять, да еще и регулярно? Основная причина - давление регуляторов: постоянные изменения законодательства, обновления государственных и банковских сервисов, закрытие уязвимостей. Нужно сохранить накопленные изменения и не потерять совместимость.\n🐌 Как происходит обновление Типовая конфигурация: Обновить - Далее - Далее - Готово.\nИзмененная конфигурация: Обновить - Трехстороннее сравнение - Боль, слезы, страдания - Принятие и переписывание - Тестирование - Исправление - Возможно готово.\nНа что обращаем внимание:\nКонтролируем дважды измененные объекты. Игнорируем объекты без наших изменений. Проверяем работу объектов с нашими изменениями после обновления. 🧑‍🌾 Типовые проблемы Не все доработки реализуются с расчетом на последующую поддержку. Если на этапе внедрения команда эксплуатации не достигла уровня зрелости для контроля изменений, сложность обновлений возрастает. Наиболее распространены следующие проблемы:\nИзменения схем XML, макетов, форм и ролей. Артефакты прошлых неудачных обновлений. Отсутствует документация - не редкость. 🛠️ Предпринимаемые меры Чтобы не распылять внимание и сконцентрироваться на объектах в зоне нашей ответственности, а также снизить количество дважды измененных объектов при сравнении-объединении конфигураций, мы придерживаемся следующих правил:\nНастройка поддержки: объекты поставщика без изменений на замок. При объединении конфигураций они гарантированно обновятся, а Сонар проигнорирует их при анализе. Переносим изменения в код. Контролировать изменение кода проще, чем интерактивные изменения форм. Использование переопределяемых модулей. Эти модули специально созданы для корректировки функционала и изменяются гораздо реже. 🎆 Эффект Настройка поддержки может снизить количество замечаний статического анализатора в десятки раз. Остается только то, на что стоит обращать внимание. Последующая работа с этими замечаниями позволяет с пристрастием рассмотреть изменения и выявить неочевидные уязвимости. При сравнении и объединении меньше объектов требуют обработки, изменения в коде очевидны и понятны. 👌 Итог Если вы только начинаете внедрение, смотрите в сторону расширений. ИзменениеИКонтроль делает жизнь проще.\nРазмер XL - это про простые и повторяемые правила. Фиксируем свои изменения, контролируем дважды измененные объекты, не трогаем остальное - это ответственность вендора. Обновление перестает быть разовым подвигом и становится рутиной.\n","date":"2025-10-15T05:30:00Z","image":"/posts/2025/10/15-razmer-xl-kogda/15-razmer-xl-kogda.jpg","permalink":"/posts/2025/10/15-razmer-xl-kogda/","title":"🏢 Размер XL: когда в проекте миллионы строк"},{"content":"📡 Мониторинг и наблюдаемость 1С Были времена, когда задача сводилась к тому, чтобы сервер 1С просто жил. Зеленая лампочка - все хорошо; жалобы на тормоза - перезагрузим. В 2025 это не работает. Бизнес ожидает устойчивую скорость операций, а не набор разрозненных графиков. Переход от мониторинга к наблюдаемости дает понимание причин, а не только симптомов.\n🎯 От лампочек к пониманию процессов Мониторинг отвечает на базовое \u0026ldquo;жив-ли кластер, хватает-ли лицензий, не встали-ли задания\u0026rdquo;. Наблюдаемость объясняет \u0026ldquo;почему проведение документа стало дольше\u0026rdquo;, \u0026ldquo;где теряется время при закрытии месяца\u0026rdquo;, \u0026ldquo;какой узел цепочки деградирует\u0026rdquo;. Речь не о большем количестве метрик, а о связности сигналов и интерпретации. 🧭 Что меняется Планируем наблюдаемость с первого дня: критичные операции определяем на этапе внедрения, а не постфактум. Команда обретает новые компетенции: чтение технологического журнала, базовая аналитика производительности, умение связывать логи, метрики и пользовательские действия. Переходим к проактивности: система заранее сигнализирует о деградации ключевых сценариев, а не после шквала жалоб. 🧩 Почему это особенно важно для 1С Отражение бизнес-операций связывает множество подсистем, отложенные проведения, регламентные задания - без связности сигналов корень проблемы ускользает. Пользовательский опыт чувствителен к блокировкам и очередям - важнее знать, проводится-ли документ в ожидаемое окно, чем просто видеть загрузку CPU. Сезонные пики нагрузки требуют дисциплины - наблюдаемость сокращает время поиска причин и повышает предсказуемость релизов. 🔧 Практические инструменты ЦУП 1С как оперативная панель: быстро подсвечивает узкие места в реальном времени. Решения сообщества: готовые парсеры техжурнала, выгрузки в CSV, простые скрипты и дашборды - быстрый путь к наблюдаемости без больших проектов. Интеграция в общий ландшафт: данные 1С можно встраивать в корпоративные панели вместе с остальными системами, чтобы видеть одну картину. ⚠️ Типичные ошибки Сто графиков - ни одного ответа: метрики не связаны с реальными сценариями. Алерты ради алертов: шум перекрывает сигнал, люди перестают реагировать. Знания в головах: нет общего пути подключения телеметрии и единых артефактов. Разово настроили и забыли: наблюдаемость не вошла в рутину - эффект растворяется. 📏 Как замечать эффект MTTR стабильно снижается, а не только число инцидентов. Доля периодов, где ключевые операции укладываются в целевые показатели времени, растет. Постмортемы короче и предметнее: быстрее локализуем причины и фиксируем улучшения. 🔍 Выводы Мониторинг фиксирует симптом, наблюдаемость дает причинно-следственную картину. В 1С именно связность сигналов уменьшает время расследований и снижает риск сорвать критичные сроки. Начинайте с малого: выберите несколько ключевых операций, договоритесь о единых артефактах и обзорах, подключайте инструменты постепенно - дисциплина качества вырастет естественно. ","date":"2025-10-13T05:32:22Z","image":"/posts/2025/10/13-monitoring-i-nablyudaemost/13-monitoring-i-nablyudaemost.jpg","permalink":"/posts/2025/10/13-monitoring-i-nablyudaemost/","title":"📡 Мониторинг и наблюдаемость 1С"},{"content":"🔥Пятничное: Все врут Эйнштейну приписывают фразу - \u0026ldquo;Все люди лгут, но это не страшно, никто друг друга не слушает\u0026rdquo;. Все так. Но когда ты заинтересован в коммуникации и результате - начинаются проблемы.\nКаждый день одно и то же. Одни - от непонимания, другие - от страха, третьи - из корысти. В конце концов просто потому что могут. Чем меньше уровень понимания человека, тем агрессивнее его позиция - уверенность обратно пропорциональна компетенции. Когда ответственность растет, включается самозащита - страх признать незнание. Когда ставки высоки - корысть подсказывает приукрасить. Когда система не предусматривает последствия - ложь становится нормой.\n🤷‍♂️ Почему Мозг ненавидит неопределенность.\nКогда мы не знаем ответа - мы его выдумываем.\nКогда не уверены - подгоняем факты под комфортную версию.\nКогда страшно - прячем правду, потому что признать ошибку опаснее, чем допустить катастрофу.\nИ вот результат: мы строим системы, в которых ложь становится системным способом адаптации.\nПартнер врет, потому что не хочет потерять контракт. Заказчик врет, потому что не хочет выглядеть некомпетентным. Исполнитель врет, потому что боится наказания. Менеджер врет, что все под контролем.\nА потом прод падает, и все искренне удивлены: \u0026ldquo;Как же так? Все же было зеленое!\u0026rdquo; 🤝 Партнеры врутДа, поставка в срок, точно.\nДа, совместимы с вашей версией.\nУ нас есть опыт, сто раз так делали.\nПеревод: Ничего не готово, срок придумали, будет еще несколько переносов. Совместимость никто не проверял, допиливать придется на проде. С такими задачами никогда не сталкивались, но когда-нибудь разберемся.\nТочно-точно. Скорее всего. Если повезет. Абсолютно почти уверен.\n🏢 Заказчики врутМы все согласовали.\nЭто простое изменение.\nОстальное не трогайте.\nПеревод: Согласовал один департамент из десяти. Простое изменение рушит пол-системы и требует пересмотра всех процессов. Остальное - интеграция с внешними критичными системами, которая естественно перестанет работать.\nНу вы не можете что ли? Вы что, не умеете? Вы что, глупые?\n👨‍💻 Исполнители врутДокументацию подготовил.\nУже переношу на прод.\nВсе протестировал.\nПеревод: Создана пустая страница в вики. Технологическое окно закрывается через 15 минут, а чуть-чуть доработать еще на два часа. Результат не проверял, но код написан кажется правильно.\nЛучше соврать, а то заругают. Вдруг никто пользоваться не будет, ошибка и не всплывет.\n💡 Короче Люди врут, потому что мозг защищает их от страха, а система поощряет удобную ложь.\nМногие думают, что не обманывают - они искренне не видят границы своего понимания.\nПроклятие знания - эксперт не может представить, что кто-то может не понимать очевидное.\nПризнать, что не понимаешь - страшнее, чем ошибиться.\nУправляйте не тем, что люди говорят, а тем, что можно проверить.\nИ главное - не верьте никому на слово. Даже себе.\n","date":"2025-10-10T05:30:00Z","image":"/posts/2025/10/10-tgif-vse-vrut/10-tgif-vse-vrut.jpg","permalink":"/posts/2025/10/10-tgif-vse-vrut/","title":"🔥Пятничное: Все врут"},{"content":"🏦 Техдолг: когда \u0026ldquo;работает же\u0026rdquo; становится дороже нового решения Костыли, велосипеды, ошибки разработки и проектирования - удобный повод обвинить команду: это ведь они так пишут. Но откуда берется техдолг? Всегда ли это результат ошибок? Или это эффект амбиции \u0026ldquo;пятилетку за один год\u0026rdquo;?\n🤔 Выбор или случайность Когда скорость важнее качества, техдолг это осознанный кредит: команда обременяет себя обязательством, чтобы быстрее выйти в прод и проверить гипотезу или нанести мгновенную пользу. Это работает, если заранее забронированы ресурсы на обслуживание этого долга.\nЕсть и непреднамеренный техдолг: спешка, нехватка экспертизы, устаревшие технологии. Система обрастает \u0026ldquo;костылями\u0026rdquo;, которые дорого чинить. Важно замечать скрытый долг - особенно в регулярно обновляемых системах 1С.\n⏳ Проценты и риски: стоимость отсрочки Каждый отложенный рефакторинг или пропущенное обновление - заем у будущего. Проценты начисляются ростом рисков и затрат на поддержку. Чем дольше долг живет, тем выше проценты и сложнее его вернуть: новые функции выходят медленнее, растет TCO, снижается предсказуемость поставок. Запущенный техдолг превращается в долговой якорь: любой релиз требует непропорциональных усилий, а скорость развития падает.\nВажно: игнор обслуживания долга и его неконтролируемый рост приводят к остановке развития: ресурсы уходят на устранение последствий, а релизы теряют предсказуемость.\n🧰 Управление техдолгом Инвентаризация. Составьте реестр проблем: устаревший код, устаревшие версии, ручные обходные пути. Оцените критичность и влияние на бизнес. Используйте базу по инцидентам, пост-мортемы, отчеты статических анализаторов. Приоритизация. Отсортируйте по риску, фокус на узких местах, влияющих на релизы и SLA. Регулярное погашение. Включайте техдолг в план: 20% спринта или фиксированный \u0026ldquo;техдолг-день\u0026rdquo; каждую неделю. Правило регистрации долга. Тест - обязательно. Описание - обязательно. Прозрачность. Добавьте сумму долга в дашборды. 🗓 Что можно сделать уже завтра Аудит. Проведите экспресс-ревью: самые больные места по мнению команды. Жалобы из-за тормозов, регулярные инциденты, ручные исправления. От чего хочется освободиться в первую очередь? Топ-3. Выделите три самых критичных долга. План. Включите погашение в ближайший цикл: задачи, ответственные, сроки, критерии готовности. Коммуникация. Объясните бизнесу смысл \u0026ldquo;невидимой работы\u0026rdquo;: меньше аварий, стабильнее сервисы, быстрее вывод фич. 📈 Метрики Инциденты за 14 дней после релиза изменения. Динамика регистрации инцидентов снижена. Покрытие автотестами критичных сценариев. Замечания статанализа в измененном коде - 0 критических. Доля задач техдолга в каждом спринте резерв - 20%. ✅ Выводы Техдолг - инструмент управления скоростью, а не проблема сам по себе. Он оправдан при наличии понятной стратегии погашения. Берем осознанно, возвращаем по плану. Остальное - детали процесса и очередность задач.\n","date":"2025-10-08T05:29:58Z","image":"/posts/2025/10/08-tehdolg-kogda-rabotaet/08-tehdolg-kogda-rabotaet.jpg","permalink":"/posts/2025/10/08-tehdolg-kogda-rabotaet/","title":"🏦 Техдолг: когда \"работает же\" становится дороже нового решения"},{"content":"🗺 Карта интеграций 1С на одном листе: контекст + интерфейсы Чем больше систем и данных, тем сложнее удерживать целостную картину интеграций. Одна страница решает большинство проблем: видно кто с кем обменивается, зачем, как часто и как это устроено. Стандартные инструменты - Markdown, PlantUML, дисциплина.\n🎯 Зачем Быстрее согласовывать изменения: одна картинка и один список вместо длинных переписок. Понимать влияние изменений: сразу видно какие потоки затрагиваются. Подготовить наблюдаемость: добавить идентификатор запроса, цель сервиса и версию обмена. 🧭 Принципы Карта должна оставаться читаемой: только ключевые системы и связи, без перегрузки деталей. На схеме только смысл обмена и укрупненные классы данных, технические детали держим в описаниях ниже. Владелец по роли, не по ФИО; если один для всех - укажите это в шапке, не повторяйте в каждой строке. Частота по-человечески: каждый час, ночью, по событию. Храним описания в вики (Confluence/Obsidian/Notion) или в GitHub - правки через PR/ревью, ссылки на регламенты рядом. 🗂 Как описывать интерфейсы без таблиц Формат - одна строка на обмен. Если за все потоки отвечает одна роль - укажите это один раз в шапке: \u0026ldquo;Владелец по умолчанию - Поддержка 1С\u0026rdquo;.\nПримеры:\n1C:ERP -\u0026gt; Bitrix24 - контрагенты, каждый час, http. 1C:Billing -\u0026gt; 1C:ERP - акты, оплаты, один раз в день в 23:00, ftp. 1C:ERP -\u0026gt; 1C:Документооборот - контрагенты и договоры, по событию, http.\nМинимум, что указываем: что передаем, откуда и куда, как идет обмен (отправляем или забираем), как часто, каким протоколом. Если владелец отличается от общего - укажите его. 🧩 Контекстная схема C4 Инструмент выбирайте любой, понятный команде: PlantUML, drawio, figma. Главное - читаемость и общий язык уровня контекста.\nКак не перегружать схему:\nНе перечисляйте все справочники и документы на стрелках. Подписывайте потоки укрупненно: \u0026ldquo;справочники\u0026rdquo;, \u0026ldquo;документы\u0026rdquo;, \u0026ldquo;события\u0026rdquo;. Если потоков много - объединяйте их в одну связь и раскрывайте уровнем ниже. Для перегруженных зон тоже делайте отдельную детализацию. Держите легенду с условными обозначениями рядом со схемой. 🚀 С чего начать Выписать все известные обмены и системы - без перечисления полей БД. Нарисовать контекст с ключевыми системами и каналами, без перечисления всех справочников и документов. Описать критичные интерфейсы по формату одной строки. Пустоты пометить TBD. Закрепить правило: любое изменение интеграции - сначала согласование схемы и описания, потом разработка. 📌 Итоги Один лист убирает основную неопределенность и ускоряет согласование.\nРоли и простые ожидания по времени возвращают предсказуемость без новых инструментов.\nХраним как код - карта живет, а не пылится в презентации.\n","date":"2025-10-06T05:30:00Z","image":"/posts/2025/10/06-karta-integratsiy-1s/06-karta-integratsiy-1s.jpg","permalink":"/posts/2025/10/06-karta-integratsiy-1s/","title":"🗺 Карта интеграций 1С на одном листе: контекст + интерфейсы"},{"content":"🔥 Пятничное: Безумие меняться нормально Сумасшедший ты или нет, определяет сторона решетки по которую ты находишься. Большинство создает нормальность. Не истина. Не логика. Не эффективность. Просто статистика. Плюс один голос - и цирк становится зравым смыслом.\n🧨 Проблема для ИТ ИТ живет парадоксом: создаем технологии будущего - управляем принципами прошлого. Говорим об agile - строим водопадные иерархии. Призываем к DevOps - сохраняем силосы между разработкой и эксплуатацией. Препятствие не в системах, а в мышлении, которое их окружает.\nЗдоровая инженерная культура снижает выгорание и повышает производительность. Но когда \u0026ldquo;нормой\u0026rdquo; объявляют костыли и авралы, никакие практики не взлетят - система сама себя возвращает к привычному статусу-кво.\nТехнический долг - лишь видимая часть айсберга. Под водой - годами накопленные компромиссы в коммуникациях, процессах и принятии решений. Культура наказывает за эксперименты и поощряет стабильность. В итоге решения технически работают, но стратегически мертвы. Диктатура хозяйственников - технологии затратны. Сокращаются бюджеты, обучение, эксперименты. Получаем имитацию внедрения вместо реального изменения. Когда ломается - виновата программа, которая якобы сложная, сырая и медленная, а не изначально возведенные надуманные рамки и ограничения. Магическое мышление пользователей - нужно как у лидеров рынка, но проще, дешевле и быстрее. Удобно как таблица - но функционально как ERP. Сроки ставятся без обсуждения с теми, кто будет строить. Реальность берет свое - включается культура обвинений. Обвинения важнее решений - найти виновных и переложить ответственностьэто ключ к выживанию в корпорациях. Система тормозит - вы плохо сделали. Предупрждали о последствиях - нас не волнует, это ваши проблемы. При этом требуются инновации и цифровизация без готовности менять привычки. 🤪 Кто сегодня определяет нормальность финансисты, видящие в ИТ лишь центр затрат; операционщики, для которых стабильность любой ценой важнее изменений; руководители направлений, ревниво сохраняющие свои процессы неизменными; пользователи, сопротивляющиеся изменениям, но требующие результата.\nИх хор легко перекрикивает голос тех, кто понимает технологические ограничения и стоимость решений. Решения принимаются эмоциональным большинством, а не компетенцией. 💉 Выход Проблема не в компетенциях ИТ. Проблема в том, что решения о технологиях системно принимают люди, которые в технологиях не разбираются, но отказываются это признать. Нормы формируются там, где громче, а не там, где точнее.\nНастоящая трансформация начинается с честного признания границ компетенции и отказа путать управленческую решительность с технической грамотностью. Центр тяжести решений должен быть у тех, кто проектирует и несет ответственность за архитектуру. И да, пора перестать требовать невозможного в нереальные сроки - с последующим удивлением, почему ИТ опять не справилось.\nНорма или отклонение - решает сторона решетки. По какую сторону собираешься стоять ты - в толпе, которая делает абсурд нормой, или там, где сегодняшнее безумие завтра станет стандартом?\n","date":"2025-10-03T05:30:44Z","image":"/posts/2025/10/03-tgif-bezumie-menyatsya/03-tgif-bezumie-menyatsya.jpg","permalink":"/posts/2025/10/03-tgif-bezumie-menyatsya/","title":"🔥 Пятничное: Безумие меняться нормально"},{"content":"🧭 Adaptive IT: гибкость как конкурентное преимущество Гибкость в ИТ - дисциплина, а не хаос: скорость изменений при сохранении предсказуемости, качества и безопасности.\n🔎 Почему сейчас В VUCA-мире жесткие процессы становятся ограничителем роста. Когда изменения происходят быстрее, чем срабатывают согласования, а исключения становятся правилом - пора переосмыслить управление ИТ-процессами. Я предлагаю не отказываться от процессов, а адаптировать их.\nТрадиционные фреймворки хороши в предсказуемом мире. Сегодня это роскошь.\nITIL 4 уже впитал идеи Agile и DevOps. Важно не какой фреймворк мы выбрали, а как применяем: классический ITSM тянется к формальному RFC на каждое изменение, тогда как гибкое управление переводит стандартные изменения в self-service с постфактум-аудитом.\n🧩 Баланс управления в ИТ: от центра к федерации В контексте запросов бизнеса на изменения ИС даже небольшие доработки - уточнить отчет, добавить поле в форму, поправить обязательный атрибут в обмене - часто вязнут в рутине: там, где бизнес ожидает быстрый эффект, процедура включает длинную цепочку согласований и архитектурных комитетов. С другой стороны, поток несогласованных локальных правок по запросам разных подразделений без общего видения порождает тупиковые ветви развития и базу легаси - в итоге дешевле перевнедрить, чем поддерживать.\nФедеративная модель помогает держать баланс:\nцентр задает ограничивающие правила: безопасность, стандарты интеграций, единые справочники и форматы данных, правила классификации запросов бизнеса. команды совместно с владельцами процессов принимают решения в пределах этих границ: приоритизацию изменений, шаблоны процессов, мониторинг. для высокорисковых или межсистемных запросов - короткие контрольные этапы и комитет по изменениям; для типовых и понятных - каталог стандартных изменений и self-service с постфактум-аудитом. ⚖️ Градация правил Главная ошибка - считать, что гибкость = хаос. Современное управление ИТ - это не отказ от правил, а их градация.\nбезопасность и compliance: строгие требования и полный цикл согласований. стандартизация и тираж: рекомендуемые пути с упрощенным прохождением. 💡 Три сигнала для трансформации Когда стоит внедрять гибкие подходы:\nВремя на согласования превышает время на реализацию - если RFC обсуждается дольше, чем делается изменение. Исключения стали нормой - когда большая часть процессов идет через escalation и \u0026ldquo;экстренные\u0026rdquo; процедуры. Команды обходят официальные процессы - растет shadow IT, потому что официальные каналы слишком медленные. ✅ Итог Гибкое управление ИТ - не про отказ от процессов, а про их эволюцию. В мире, где изменения происходят каждую минуту, статичные регламенты становятся тормозом. Встраивайте гибкость в ткань процессов: переключение режимов по метрикам, умную маршрутизацию и явную градацию правил. Это сохраняет предсказуемость, ускоряет поставку и превращает адаптивность в конкурентное преимущество.\n","date":"2025-10-01T05:29:59Z","image":"/posts/2025/10/01-adaptive-it-gibkost/01-adaptive-it-gibkost.jpg","permalink":"/posts/2025/10/01-adaptive-it-gibkost/","title":"🧭 Adaptive IT: гибкость как конкурентное преимущество"},{"content":"🎓 Доступность формирует навыки - навыки определяют выбор Лицензии и поддержка дают SLA, безопасность, ответственность вендора и соответствие аудиту - предсказуемость и надежность, вот за что платит энтерпрайз. Но выбор платного продукта формируется задолго до продакшена - в школе, вузе и хоумлабе.\n🧠 Суть Комьюнити лицензии и учебные редакции - это воронка навыков. Если 90% потенциальных кандидатов уже работали с продуктом, их проще нанимать и быстрее выводить на результат. В долгую это формирует спрос на уровне корпораций: в итоге мы платим за те продукты, с которыми команда уже работала на практике.\n🔎 Примеры - коротко VMware: убрали free-ESXi - энтузиасты ушли в Proxmox/XCP-ng; вернули в 8.0U3e, но без vCenter и с ограничениями - многие уже не хотят возвращаться. Microsoft: бесплатный Hyper-V Server остановили на устаревшей версии 2019 - для учебных классов и хоумлаба логичнее Linux/KVM и Proxmox. 1С: комьюнити лицензия позволяет развить навыки разработки, но не дает потренироваться с кластером и отказоустойчивостью. Мини-сервер упирается в 1 рабочий сервер кластера и 5 пользовательских сессий - для обучения программированию ок, для архитектурных сценариев тесно. 🧭 Как не убить воронку навыков Выбор стека следует за рынком навыков - где проще получить опыт бесплатно, там больше кандидатов завтра. Time-to-productivity снижается, когда у джунов есть опыт учебных редакций, а у мидлов - хоумлаба. Закрывая бесплатный вход, вендор толкает сообщество к opensource - через 5-10 лет именно эти люди будут определять корпоративный стек. ❓Актуальные вопросы Можем ли мы нанять команду под выбранный стек быстро и без переплаты? Сколько из наших кандидатов уже трогали этот продукт в школе, вузе или хоумлабе? Каков баланс навыков на рынке, доля кандидатов с опытом и как это влияет на наш стек? Сколько стоит онбординг по стеку X в сравнении с открытой альтернативой - где быстрее и дешевле? ✅ Финал\nЭнтерпрайз в любом случае заплатит - вопрос кому. Ставить палки в колеса энтузиастам - значит растить комьюнити конкурентов. Комьюнити-версии - это не благотворительность, а инвестиция в будущий стек: шире воронка навыков сегодня - устойчивее поставки и дешевле найм завтра.\n","date":"2025-09-29T05:30:00Z","image":"/posts/2025/09/29-dostupnost-formiruet-navyki/29-dostupnost-formiruet-navyki.jpg","permalink":"/posts/2025/09/29-dostupnost-formiruet-navyki/","title":"🎓 Доступность формирует навыки - навыки определяют выбор"},{"content":"🔥 Пятничное: Что на столе, то и в голове Свалка на вашем столе - это свалка в приоритетах: ваш \u0026ldquo;творческий беспорядок\u0026rdquo; не признак гениальности, а симптом профессиональной деградации.\nКто не может удержать порядок на расстоянии вытянутой руки, не удержит фокус на инциденте, не закроет регресс и не доведет RFC до приемки. Визуальный шум ворует когнитивную полосу пропускания - это нейроэкономика внимания, а не вкусовщина, и не прикрывайтесь Эйнштейном и псевдонаукой - бардак остается бардаком.\n💡3 ключевые мысли: Беспорядок на виду усиливает конкуренцию стимулов - мозг отстреливает помехи вместо решения задач. Производительность проседает даже у квалифицированных и замотивированных. Хаос может и подогревает креатив. Но нас ценят не за вдохновение, а за предсказуемость поставки. Менеджерам порядок дает более консервативные и надежные решения, которые выигрывают в операционке. В конце концов это риск. ISO 27001 требуют clear desk/clear screen - не оставляйте клиентские данные на столе и на экране. Это контроль, а не мода. 🤥 Мифология грязного стола Да, существуют исследования о том, что беспорядок якобы стимулирует творчество. Только вот есть, как говорится, нюанс: эти эксперименты длились несколько часов в лабораторных условиях. А вы работаете в этом хаосе годами.\nРазница между \u0026ldquo;творческим беспорядком\u0026rdquo; в эксперименте и вашим столом - как разница между контролируемым взрывом и аварией на химзаводе. В лаборатории беспорядок создавали специально, а у вас он результат лени и отсутствия системы.\n💣 Правда о хламе Захламленный стол - это:\nПотерянное время: минуты в день на поиск нужных предметов - часы и дни вы теряете на перебирание хлама. Стресс для коллег: исследования показывают, что беспорядок на рабочем месте повышает уровень кортизола у присутствующих. Ваш стол буквально отравляет атмосферу в офисе. Снижение продуктивности: хаотичная среда ухудшает концентрацию и принятие решений. Пока вы ищете ручку в горе мусора, ваш мозг работает как старый жесткий диск с 90% фрагментацией. Репутационные риски: заказчики и руководство формируют мнение о вашем профессионализме за 3 секунды взгляда на рабочее место. Угадайте, какое мнение складывается о разработчике с кладбищем кофейных стаканчиков? 🎯 Твой стол - твой прод В ИТ мы имеем дело с системами. Хорошие системы предсказуемы, структурированы, документированы. Если вы не можете организовать 1 квадратный метр личного пространства, как вы будете организовывать инфраструктуру на тысячу пользователей?\nВаш стол - это ваш персональный продакшн. И если он выглядит как после DDoS-атаки, то что говорить о качестве вашего продукта?\n🧨 Финал Творческий беспорядок - привилегия гениев уровня Эйнштейна. Остальным нужна дисциплина.\nВаш захламленный стол не делает вас творческим. Он делает вас непрофессиональным, медленным и стрессом для окружающих.\nПрекратите искать оправдания в псевдонауке. Уберите свой стол. Прямо сейчас.\n","date":"2025-09-26T05:32:08Z","image":"/posts/2025/09/26-tgif-chto-na/26-tgif-chto-na.jpg","permalink":"/posts/2025/09/26-tgif-chto-na/","title":"🔥 Пятничное: Что на столе, то и в голове"},{"content":"🖼️От проектов к продуктам: как перестроить управление ИТ Проект - этап жизни продукта, а не конечная цель. Проектная логика работает внутри продуктовой модели.\n🧩 Когда проекта недостаточно В корпоративных системах вроде ERP проект внедрения - не финал, а лишь этап. Сразу после релиза запускается непрерывный поток изменений: регуляторные требования ЦБ/ФНС, закрытие уязвимостей, синхронизация с соседними системами и обновления платформы. Формальное закрытие проекта дробит ответственность: техдолг и инциденты переходят в эксплуатацию, которая не участвовала в архитектурных решениях интегратора. KPI \u0026ldquo;срок/бюджет\u0026rdquo; слабо коррелируют с бизнес-ценностью - стабильностью сервиса и удовлетворенностью пользователей. Управление требует продуктовой рамки: единая команда и владелец продукта, прозрачный roadmap, сервисные метрики (CSAT, время реакции, MTTR, дефекты в течение 14 дней после релиза). Проект - инструмент для крупных вех внутри жизненного цикла продукта.\n🧭 Как работает продуктовый взгляд Длинный жизненный цикл. ERP, HR-системы, личные кабинеты - не разовые инициативы, а продукты с годами развития и поддержки. Единый центр ответственности. Владелец продукта и стабильная кросс-функциональная команда отвечают за ценность, качество и бюджет. Планирование по ценности. Roadmap с квартальными целями и измеримыми результатами вместо \u0026ldquo;финальной даты\u0026rdquo;. Сервисные метрики. Помимо сроков и бюджета фиксируем Lead Time, CSAT/CSI, дефекты после релиза, долю повторных обращений. Проекты как вехи. Миграции, внедрение модулей и крупные релизы оформляем как проекты, но ответственность остается у продуктовой команды. 🔄 Что меняется Коммуникация с бизнесом. Обсуждаем не \u0026ldquo;закрытие проекта\u0026rdquo;, а целевые изменения метрик продукта к конкретному периоду и ожидаемую бизнес-ценность. Бюджетирование. Финансирование распределяем по продуктам и их roadmap; видна структура затрат на поддержку и развитие. Предсказуемость поставок. Ритм релизов и постмортемы уменьшают инциденты после релиза. Управляемый техдолг. Доля времени на снижение долга закреплена в планах; архитектурные решения проходят через продуктовый контур. ✅ Выводы Проект - инструмент внутри продукта, а не цель.\nПродуктовая модель делает ценность измеримой и непрерывной, а ответственность - адресной.\nДля менеджеров это переход от управления \u0026ldquo;сдачей работ\u0026rdquo; к управлению жизненным циклом продукта и его метриками.\n","date":"2025-09-24T05:30:00Z","image":"/posts/2025/09/24-ot-proektov-k/24-ot-proektov-k.jpg","permalink":"/posts/2025/09/24-ot-proektov-k/","title":"🖼️От проектов к продуктам: как перестроить управление ИТ"},{"content":"🧠 Управление знаниями в ИТ: от хаоса к системе Отсутствие единой точки доступа к знаниям приводит к тому, что опыт расползается по чатам, головам и папкам, а решения не переиспользуются системно. В итоге ценные знания уходят вместе с людьми, а повторяющиеся задачи выполняются заново.\nКак превратить это в воспроизводимую систему управления знаниями?\n🎯 Пять уровней зрелости Уровень 1: Базы знаний нет - решения ищутся с нуля и держатся в памяти отдельных специалистов.\nУровень 2: Есть разрозненные записи - единого хранилища нет, много дублей и устаревших материалов, ответственность за обновление не закреплена.\nУровень 3: Развернута централизованная база - определен процесс добавления и актуализации, назначены владельцы разделов, покрыты типовые вопросы и известные ошибки.\nУровень 4: База встроена в процессы Service Desk - статьи обновляются после инцидентов и изменений, есть рейтинги, отзывы и peer review по критичным документам, поддерживается актуальность.\nУровень 5: Управление знаниями стало культурой - межфункциональное покрытие и самообслуживание, семантический поиск и чатботы, постоянный анализ пробелов и проактивное обновление контента.\nБольшинство ИТ-команд застревают между уровнями 2 и 3. Оценка помогает понять точку старта и следующий шаг роста. Про оценки уровня зрелости я уже писал отдельный пост.\n📋 Практические инструменты захвата знаний Что именно фиксируем: признаки, решения, контекст, ссылки на артефакты и владельцев\n🧨 Post-mortem как источник знаний:\nОбязательный post-mortem после каждого major incident Шаблон: симптомы, первопричина, действия по предотвращению Привязка решений к конкретным системам и процессам Ссылка на отчет прикрепляется к карточке инцидента\n📖 Документирование изменений: Документация содержит раздел \u0026ldquo;Зависимости с другими системами\u0026rdquo; Чек-листы проверок после внедрения Связи с существующими инструкциями по эксплуатации 🔧 Интеграция в операционные процессы Service Desk: типовые решения (сброс пароля, доступы, частые ошибки) документируются как инструкции для L1 Change Management: каждое изменение дополняет существующие процедуры или создает новые Incident Management: нестандартные решения попадают в базу знаний для повторного использования Problem Management: анализ первопричин формирует превентивные инструкции и каталог обходных решений 🎯 Итог Эффективная база знаний - побочный продукт операционки, а не отдельный проект. Начните с простых шагов:\nкаждый инцидент - post-mortem и workaround каждое изменение - обновленная документация каждая типовая заявка - короткая инструкция для L1. встройте контроль за этими пунктами в регулярные ревью. ","date":"2025-09-22T05:29:59Z","image":"/posts/2025/09/22-upravlenie-znaniyami-v/22-upravlenie-znaniyami-v.jpg","permalink":"/posts/2025/09/22-upravlenie-znaniyami-v/","title":"🧠 Управление знаниями в ИТ: от хаоса к системе"},{"content":"🔥 Пятничное: Алерт-зомби и эпидемия шума Видно все - решается ничего. Алертов сыпется столько, что внимание стало дефицитом: смотреть некогда, разбирать некому, ответственности нет. Чаты горят, графики красные и полное спокойствие.\nКогда все важно - не важно ничего. За ночь прилетает сотня срабатываний. Информационные сигналы топят боевые - тот самый on-call, ради которого вообще существует алертинг.\n📉 Эволюция мониторинга Первый месяц: бежим разбираться с каждым уведомлением.\nТретий месяц: смотрим только на \u0026ldquo;критичные\u0026rdquo;.\nПолгода: реагируем, когда звонят пользователи.\nГод: звук уведомлений \u0026ldquo;временно\u0026rdquo; выключен.\nПолтора года: главный мониторинг - телефон службы поддержки.\nСамая надежная метрика - не SLI, а \u0026ldquo;звонит помощник директора\u0026rdquo;. Секретарь стал SRE и системой раннего оповещения для репутационных рисков.\n🧊 Театр наблюдаемости Сотни \u0026ldquo;бздынь\u0026rdquo; без реакций - игнор по умолчанию, а не баг. Чем громче мониторинг, тем тише команда: любое ЧП пролистывается как рутина. Алерты по \u0026ldquo;железу\u0026rdquo; без связи с SLO и симптомами игнорируется первым - красиво мигает, пользы ноль. Сигнал без владельца - это ничья ответственность и ничье действие. Стратегия \u0026ldquo;давайте пока оставим\u0026rdquo; создаем музей шума. Папка \u0026ldquo;не критично\u0026rdquo; - кладбище ответственности. 🤔 Пятничные вопросы Сколько систем шлют одно и то же разными словами? Вы узнаете о проблемах из helpdesk раньше, чем от мониторинга? Есть алерты, которые срабатывают ежедневно полгода? Кто ваш самый надежный источник - Zabbix или секретарь? 🧨 Финал Если алерт не ведет к действию, он не существует. Это художественная литература в формате push.\n","date":"2025-09-19T05:30:00Z","image":"/posts/2025/09/19-tgif-alert-zombi-i/19-tgif-alert-zombi-i.jpg","permalink":"/posts/2025/09/19-tgif-alert-zombi-i/","title":"🔥 Пятничное: Алерт-зомби и эпидемия шума"},{"content":"✅ Закрыли тикет - не реализовали ожидания. Как превратить обещания в результат. Критерии приемки фиксируют ожидаемое поведение системы глазами пользователя. Это рабочий контракт результата: что именно изменится для пользователя, при каких условиях это поведение считается достигнутым, каким способом мы это докажем.\nВ проекте существуют две истории. Первая - деловая: \u0026ldquo;сделайте интеграцию Биллинг и ERP\u0026rdquo;. Вторая - аналитическая: последовательности, соответствия, транспорт, схема API. Критерии приемки собирают эти истории в единую точку фокуса - измеримую цель, понятную бизнесу, разработке и тестам.\n🎯 Что такое acceptance criteria Acceptance criteria - набор проверяемых условий, по которым задача считается завершенной. Это не про \u0026ldquo;когда будет готово\u0026rdquo;, а про \u0026ldquo;что именно считается готовым\u0026rdquo; и как это доказать.\nКлючевые свойства:\nПроверяемость - каждый пункт можно протестировать. Измеримость - есть конкретные пороги и параметры. Независимость - пункты проверяются отдельно. Понятность - формулировки на языке бизнеса, без внутренних технических деталей. Форма записи:\nКороткая User Story: кто и зачем. Критерии приемки списком. Для сложных сценариев - Given - When - Then.\nGiven: В системе есть товар \u0026ldquo;PearBook 15 PRO\u0026rdquo; с остатком 5 шт на складе \u0026ldquo;Основной\u0026rdquo;\nWhen: Пользователь создает документ \u0026ldquo;Реализация\u0026rdquo; и добавляет 10 шт этого товара\nThen: Система показывает предупреждение \u0026ldquo;Недостаточно товара на складе (доступно: 5 шт)\u0026rdquo; 🔌 Понятный кейс \u0026ldquo;Реализация товаров\u0026rdquo; и контроль остатков\nКак менеджеру по продажам, мне нужно видеть остатки при оформлении реализации, чтобы не продавать несуществующий товар.\nПри добавлении позиции показывается доступный остаток на выбранном складе. Доступный остаток на дату документа считается так: фактический остаток - резервы - товар в исходящих перемещениях + товар во входящих перемещениях. При недостатке остатка - предупреждение красным, оформление можно продолжить. Обновление остатков при смене склада или даты без перезагрузки формы. 🧩 Почему это важно AC переводят \u0026ldquo;сделать интеграцию\u0026rdquo; в \u0026ldquo;какие документы появятся в ERP, как они трансформируются, с каким допуском по данным и за какое время они туда попадут\u0026rdquo;. По AC удобно писать автотесты (Vanessa Automation) и включать их в CI. Для демо - живой чек-лист: \u0026ldquo;что обещали - что сделали\u0026rdquo;. 💡 Итог SLA отвечает \u0026ldquo;когда будет готово\u0026rdquo;.\nAcceptance criteria отвечают \u0026ldquo;что именно считается готовым\u0026rdquo; и служат контрактом ожиданий между бизнесом, аналитикой и разработкой.\n🙋‍♂️ Проверьте ваш бэклог: у скольких задач AC уже можно превратить в автотест и добавить в CI?\n","date":"2025-09-17T05:30:00Z","image":"/posts/2025/09/17-zakryli-tiket/17-zakryli-tiket.jpg","permalink":"/posts/2025/09/17-zakryli-tiket/","title":"✅ Закрыли тикет - не реализовали ожидания. Как превратить обещания в результат."},{"content":"🔎 Инцидент, запрос на обслуживание, изменение - где границы и как не путать Четкие границы между инцидентом, запросом на обслуживание и запросом на изменение - это скорость и предсказуемость. Далее - простой детектор и чек-листы для бизнес-приложений.\n🧠 Что есть что Инцидент - неплановое прерывание сервиса или ухудшение качества. Цель - быстро вернуть норму. Запрос на обслуживание - формальная просьба пользователя о предоставлении стандартного сервиса/доступа/информации/операции в бизнес-приложении. Не меняет конфигурацию сервиса, выполняется по заранее описанной процедуре, часто автоматизируется и не требует отдельного согласования. Запрос на изменение - добавление, модификация или удаление элементов сервиса, инфраструктуры или кода, способное повлиять на сервис. Требует оценки риска и авторизации и планирования. 🧭 Быстрый детектор границ Есть деградация или простой - инцидент. Ищем обход, откат, перезапуск. Ничего не сломано, нужна операция в бизнес-приложении: доступ, отчет, выгрузка, консультация - запрос на обслуживание. Нужно изменить конфигурацию/код/инфраструктуру - запрос на изменение. 🔍 Запрос на обслуживание и изменение - простые проверки Меняется ли состояние рабочей среды (конфигурация, код, интеграции)? Да - это запрос на изменение. Нет - запрос на обслуживание. Можно ли автоматизировать выполнение без влияния на сервис? Это запрос на обслуживание. Требуется тестирование/окно внедрения/план отката? Да - запрос на изменение. 🧩 Примеры в 1С Не проводят документы в 1С из-за блокировок - инцидент. Цель - восстановить работу, при необходимости откатить релиз. Создать пользователя 1С и выдать доступ к отчетам - запрос на обслуживание. Без комитета по изменениям. Обновление конфигурации по требованиям регулятора - запрос на изменение. Оценка риска, окно, откат, уведомления. Новый обмен 1С - Bitrix24 или смена схемы сообщений - запрос на изменение. Планирование, тестирование, откат. Разовая выгрузка данных или подготовка отчета без изменений кода - запрос на обслуживание. Изменился адрес вебхука CRM, обмены перестали приходить - инцидент. Быстрые правки, восстановление. 🚫 Антипаттерны Регистрируем инцидент как запрос на обслуживание - теряем скорость реакции и увеличиваем среднее время восстановления. Ведем стандартный запрос на обслуживание через изменения - тормозим поток. Подменяем запрос на изменение запросом на обслуживание (\u0026ldquo;просто попросили настроить\u0026rdquo;) - копим неучтенные риски. ✅ Зачем это разделение Разделение потоков убирает конкуренцию задач: срочные сбои не вытесняются рутинными просьбами, запросы по каталогу исполняются быстрее за счет стандартизации и автоматизации. Изменения планируются, детально прорабатываются, проходят оценку риска и план отката - меньше сбоев. Четкая классификация дает честные метрики и предсказуемые сроки - легче защищать бюджет и управлять приоритетами.\n","date":"2025-09-15T05:30:00Z","image":"/posts/2025/09/15-intsident-zapros-na/15-intsident-zapros-na.jpg","permalink":"/posts/2025/09/15-intsident-zapros-na/","title":"🔎 Инцидент, запрос на обслуживание, изменение - где границы и как не путать"},{"content":"Чему я научился, став родителем Важные управленческие навыки приходят не только из книжек. Отцовская повседневность дает свои уроки: эмоциональный интеллект и терпимость к неопределенности. Эти навыки не про мягкость, а про результат команды и бизнеса.\n🧠 Важнее позволить выиграть Победа ребенка важнее моей собственной. Нередко я осознанно даю ребенку выиграть спор - его внутренняя уверенность и опыт роста важнее моей личной правоты. В офисе это тоже работает. Сотрудникам важно получать собственный опыт, знать, что их слышат, что они участвуют в принятии решений, что руководитель готов к диалогу. Опыт может быть и негативным, но с контролируемыми последствиями. Лидерство - это не демонстрация того, что ты умнее всех, а создание условий для роста в команде.\n🧩 Мир сложнее, чем кажется Малыш видит, как папа ведет машину, и думает: просто сел - и поехал. Взрослея понимает, что нужны правила, навыки, опыт и ответственность. В ИТ-менеджменте ярко проявляется эффект Даннинга - Крюгера: со стороны многое кажется очевидным, пока не достигнешь точки взросления, где видно, насколько система сложнее, чем казалась. Это работает внутри команды, когда без погружения совершаются попытки сделать скоропалительные выводы о простоте задачи. И это работает снаружи, когда заказчики пытаются транслировать свое видение о решениях, сложности и сроках. Отцовство научило меня учитывать такую особенность в ежедневной работе. Люди делают все это не со зла, и они не виноваты. Надо принять эту особенность и встраивать в свою работу.\n🌫 Терпимость к неопределенности Родительство - это ежедневная работа в условиях полной неопределенности. Не знаешь, с каким настроением проснется ребенок, как отреагирует на твои решения, какие идеи родились у него в голове и требуют немедленного воплощения. При этом нужно сохранять спокойствие, принимать решения и двигаться дальше. В операционке работает так же - изменения требований, новые срочные вызовы, аварии, капризы. Не паниковать. Если знаешь, что что-то неизбежно, к этому можно подготовиться. Гибкость для изменений, буфер для срочных поручений, DRP для инцидентов.\n⏳ \u0026ldquo;Да никак\u0026rdquo; и теория ограничений Есть популярная шутка: у многодетной матери спрашивают, как она все успевает, а она отвечает: \u0026ldquo;Да никак\u0026rdquo;. У всех систем есть ограничения. Мы не можем сделать все - но можем сделать главное. Или важное. Или нужное. Когда у тебя трое детей, карьера, учеба, проекты и ограниченное время, быстро понимаешь - идеальное выполнение всех задач невозможно. Но можно определить узкие места и сфокусироваться на них. Вместо попыток оптимизировать все процессы одновременно - находить главное ограничение в системе и критический путь в проекте. Отказываться от интересных задач ради решения важных. Корректировать личные приоритеты ради общих.\nВ итоге не все будет сделано. Но все, что можно было сделать, будет сделано.\n🎯 Итог Став родителем, я многому научился и много скорректировал в своем видении. Две вещи считаю особенно важными, которые делают меня сильнее как менеджера: давать команде пространство для роста и спокойно работать в тумане неопределенности. В мире, где простых задач почти не осталось, именно это дает предсказуемый результат и рост автономности команды.\n","date":"2025-09-14T06:22:58Z","image":"/posts/2025/09/14-chemu-ya-nauchilsya/14-chemu-ya-nauchilsya.jpg","permalink":"/posts/2025/09/14-chemu-ya-nauchilsya/","title":"Чему я научился, став родителем"},{"content":"🔥 Пятничное: Ваши ДевОпсы в наших ОдинЭсах не нужны Конечно не нужны. Понадобятся только в трех редких случаях: когда важно видеть, что именно поменяли; когда завтра должно работать так же, как сегодня; когда не хочется платить штрафы. Но это же мелочи, правда?\n🎭 Добро пожаловать в сказку стабильности Релиз раз в квартал - идеально совпадает с отчетными циклами. Что может пойти не так? Ручная проверка - лучший способ ничего не пропустить. Особенно если тестируют пользователи на проде. Телефонный мониторинг - если сломается, позвонят. Если не позвонят - не сломалось. 🧘 Мантры спокойствия У 1С есть хранилище - Git не нужен. Есть конфигуратор - зачем IDE. Есть коробочное решение - значит практики разработки не нужны. Вики не нужен - у нас есть бородатый программист в свитере - он и так знает. 🪙 Экономика молчаливого согласия Быстрые правки приносят мгновенную пользу - последствия оплатит будущая команда. Нет прозрачности - нет неудобных вопросов. Нет практик - нет сравнения по метрикам. 🪓 Почему DevOps тут \u0026ldquo;не нужен\u0026rdquo; - 7 железных аргументов Скорость важнее - главное вкатить, если что - потом разберемся. \u0026ldquo;Так исторически сложилось\u0026rdquo; - идеальная архитектурная стратегия. \u0026ldquo;Наш кейс уникален\u0026rdquo; - универсальный адаптер к любым правилам. Откатов нет - потому что все выкатывается идеально. Бэкапы не нужны. Тесты - дорого. Исправления в проде - дешево и сердито.\n6️⃣ \u0026ldquo;У нас и так работает\u0026rdquo; - любимая предпосылка к длинной ночи восстановления. 🚨 Спойлер: все это работает ровно до Аудита, где спросят \u0026ldquo;кто, когда и на основании чего менял\u0026rdquo;. Массового сбоя перед зарплатой. Ухода бородатого программиста в свитере. Обновления, которое \u0026ldquo;почти не затрагивает учет\u0026rdquo;. Почти. 🧯 Вывод без иллюзий Стратегия \u0026ldquo;и так работает\u0026rdquo; тоже рабочая. Многие оставляют все как есть. Жили ведь как-то наши предки: \u0026ldquo;релизы вручную\u0026rdquo;, \u0026ldquo;откат не предусмотрен\u0026rdquo;, \u0026ldquo;решения по ощущениям\u0026rdquo;. И не жаловался никто.\nКакую метрику вы покажете в понедельник? Вроде все работает, никто не жалуется? Или - реальные цифры?\n","date":"2025-09-12T05:30:00Z","image":"/posts/2025/09/12-tgif-vashi-devopsy/12-tgif-vashi-devopsy.jpg","permalink":"/posts/2025/09/12-tgif-vashi-devopsy/","title":"🔥 Пятничное: Ваши ДевОпсы в наших ОдинЭсах не нужны"},{"content":"🤖 Цифровые ассистенты Цифровые ассистенты становятся частью рабочего процесса. Такие ассистенты есть и у нас.\n❓ Зачем Дашборды и отчеты - это база. Но их нужно целенаправленно формировать, часто они доступны только во внутренней сети, а использовать их удобнее для детального анализа. Для быстрых реакций удобнее получать итоговую сводку прямо в профильный чат в Telegram. Коротко, по делу, в момент события. Менеджеры могут отключить уведомления, зная при этом, что им всегда доступен актуальный статус.\n👷‍♂️ Машинист конвейера 1С Следит за пайплайном и внесенными изменениями.\nприсылает статусы сборок в чат предупреждает о сбоях сборки шлет сжатые отчеты по внесенным изменениям 👩‍💼 Ассистент разработки 1С Удерживает разработчиков в фокусе и сокращает рутину.\nсигналит о конфликтах и техдолге формирует дайджесты активности в репозитории напоминает о зависших и назначенных задачах 🙋‍♀️ Ассистент техподдержки 1С Наш новичок, который проходит стажировку.\nсообщает о запросах, не взятых в работу проверяет классификацию обращений присылает сводку SLA и оценок пользователей ⚙️ Как это работает Машинист конвейера реализован в пайплайн Jenkins. Он автоматически отправляет статусы сборок и информацию о падениях Telegram-чат. Ассистенты разработки и техподдержки реализованы через платформу n8n. Мы используем ее для интеграции с Jenkins и Sonar, N8n слушает события, обрабатывает их и формирует краткие сообщения в Telegram. 📈 Результат для команды Разработчики получают быструю сводку о результатах коммитов Техподдержка акцент на решении проблем, и уведомления требующие срочного внимания А для меня целостная картина - скорость поставки, качество релизов, удовлетворенность пользователей 💡 Инсайт Telegram-боты не заменяют дашборды. Они делают управление ближе и быстрее, помогая команде держать руку на пульсе.\n","date":"2025-09-10T05:30:00Z","image":"/posts/2025/09/10-tsifrovye-assistenty/10-tsifrovye-assistenty.jpg","permalink":"/posts/2025/09/10-tsifrovye-assistenty/","title":"🤖 Цифровые ассистенты"},{"content":"🏗️ Модель C4: одна история - четыре масштаба Визуализация через несколько уровней детализации - это простой способ превратить сложную систему в понятную картинку, одинаково полезную бизнесу и разработчикам. Описание от общего к частному помогает нам самим увидеть состав, границы и роли участников на старте. Постепенное углубление помогает понять детали реализации и объем необходимых изменений - это упрощает диалог с бизнесом о сроках и стоимости.\n🎯 Зачем нам C4 Быстрее согласования изменений. Общий словарь без переводчика между бизнесом и ИТ. Ключевые зависимости и риски интеграций видны на одном экране. Понятные границы ответственности. 🗺️ Четыре масштаба - что смотреть Context - пользователи и системы в общем ландшафте. Container - приложения, БД, брокер сообщений, основные связи. Component - ключевые блоки внутри приложения и их роли. Code - детали реализации и ссылки на исходники. 🔗 Кейс: 1С и Битрикс24 Context: менеджер проектов - 1С - Битрикс24 - сроки синхронизации. Container: брокеры, веб-интерфейсы, api, информационные базы. Component: схема сервиса, потоки и валидаторы данных, точки интеграций. Code: методы api, структуры данных, последовательности вызовов. ✅ Итог C4 дает руководителю масштабируемый способ вести разговоры на нужном уровне детализации - бухгалтер и разработчик слышат друг друга, а менеджеры принимают решения без десяти слайдов.\n","date":"2025-09-08T05:30:00Z","image":"/posts/2025/09/08-model-c4-odna/08-model-c4-odna.jpg","permalink":"/posts/2025/09/08-model-c4-odna/","title":"🏗️ Модель C4: одна история - четыре масштаба"},{"content":"🔥 Пятничное: Жизнь по течению \u0026ldquo;Да, без проблем, опыт есть, люди есть! Сто раз так делали. Завтра все сделаем.\u0026rdquo;\n\u0026ldquo;Баг? Но не воспроизводится же. На проде воспроизвелся? Завтра все исправим.\u0026rdquo;\n\u0026ldquo;У нас все готово! Мы все обновили! Завтра запускаемся\u0026rdquo;\nНикто, конечно, завтра не сделал, не исправил и не запустил.\n🎯 Контекст и портрет Знакомая ситуация? Это валюта людей на легке. Они расплачиваются ею чужими ночами, вашими сроками и репутацией. В 1С это бьет больнее обычного: регламентированная отчетность не переносится на понедельник, конфигурации сцеплены, один кривой коммит - и расчет зарплаты стоит. Новое правило на firewall и сервис недоступен. СУБД не обслуживается и все трмозит. Место на диске закончилось - ваша одинэс опять не работает! 😱\n🎭 Кому выгодна легкость Легкость выгодна тем, кто меряет продуктивность обещаниями, а не поставками, тем, кому нужен очередной герой для шоу в чате, пока учет стоит или сеть не дышит, тем, кто прикрывает распад дисциплины красивыми словами про гибкость. Бизнесу это не выгодно. Бизнесу нужен прогнозируемый результат и чистая пятница без паники. Цена легкости видна без дашбордов: чужие ошибки съедают слот под фичи, релизы ползут вправо, окна изменений горят, пользователи учатся не верить ИТ, команда варится в вечном пожарном режиме и выгорает. Каждый новый \u0026ldquo;быстро поправим\u0026rdquo; обходится все дороже - и деньгами, и людьми.\n🧷 Парадокс делегирования С такой культурой делегировать невозможно. Нужно закодить фичу - становишься программистом, потому что твой контрагент обещать умеет, а программировать - нет. Нужен план проекта - становишься проектным менеджером, потому что твой ПМ не знает, как планировать. Нужно построить дом - становишься строителем, потому что у бригадира язык длинный, а бригада строить не умеет. Впору задуматься о системе социального рейтинга.\n❓ Как дела, друзья? Так что за пятница у вас сегодня - день результата или день обещаний? Кого вы выращиваете - спасателей-рассказчиков или инженеров, которые могут отвечать за результат?\n","date":"2025-09-05T05:30:00Z","image":"/posts/2025/09/05-tgif-zhizn-po/05-tgif-zhizn-po.jpg","permalink":"/posts/2025/09/05-tgif-zhizn-po/","title":"🔥 Пятничное: Жизнь по течению"},{"content":"🧭 Среда изменений Недавно я писал о брифе как первом контакте с RFC. Прежде чем подготовленный бриф уйдет на согласование, он проходит еще один важный этап - анализ на признаки проекта.\n🎯 Зачем Анализ помогает отделить операционные изменения, которые можно провести в штатном потоке RFC, от инициатив, требующих проектного управления. Смысл прост: чем раньше мы понимаем масштаб и риски, тем меньше возвратов и повторных кругов согласования, тем предсказуемее становится дорожная карта.\n🧮 Как принимаем решение Мы смотрим на кроссфункциональность изменения, его влияние на действующие процессы и соответствие корпоративным регламентам и нормативным актам. А главный индикатор - верхнеуровневая оценка трудозатрат. Если установленный лимит плановых затрат превышен, решение уходит на уровень проектного комитета. На этом уровне разговор ведется на языке денег и сроков, поэтому трудозатраты переводим в финансовое выражение: стейкхолдерам важны бюджет, график и ожидаемый эффект, а не сторипойнты и часы. Проектный комитет подключается потому, что крупные суммы часто выходят за рамки текущих бюджетов и требуют дополнительного финансирования, а также ясного понимания окупаемости и влияния на компанию.\n🛠️ Модель реализации Крупные изменения способны надолго заблокировать ресурс внутренней команды. Чтобы не останавливать операционную деятельность и поток мелких RFC, масштабные задачи могут передаваться внешней команде. Это управляемый компромисс: внутренние ресурсы остаются на поддержке и эволюции систем, а внешняя команда берет на себя реализацию основной части проекта.\n🗺️ Практика, решения и маршруты согласования Заказчик, получая на согласование бриф с заключением, понимает, через какие этапы пройдет его изменение. На этой стадии он принимает решение: продвигать инициативу и готовиться к защите на проектном комитете, или снизить уровень амбиций и требований, оставив изменение в контуре RFC. Далее применяется соответствующий маршрут: если изменение укладывается в лимит и критерии RFC - стандартный путь руководитель инициатора - владелец процесса - руководители затронутых подразделений. Если лимит превышен или обнаружены признаки проекта - проектный путь: концептуальное предложение с финансовой оценкой рассматривает проектный комитет.\n💡 Совет Классифицируйте инициативы по масштабу и рискам - маршрут и инструмент под задачу: малые - RFC внутри, крупные - проектный контур и внешнее исполнение.\n","date":"2025-09-03T05:29:59Z","image":"/posts/2025/09/03-sreda-izmeneniy/03-sreda-izmeneniy.jpg","permalink":"/posts/2025/09/03-sreda-izmeneniy/","title":"🧭 Среда изменений"},{"content":"🎓 День знаний: какие уроки выбираем мы 1 сентября традиционно ассоциируется с новыми знаниями для детей - они идут в школы, строят фундамент будущих успехов. А что насчет нас, взрослых? Готовы ли мы проходить новые уроки?\nКонечно, мы постоянно учимся, читаем, посещаем курсы, обмениваемся опытом с коллегами. Но самые ценные уроки остаются за рамками формального образования - это жизненные инсайты, которые формируют нашу зрелость и управленческие решения.\n🔍 И опыт - сын ошибок трудных Мы сами решаем, чему учиться у жизни. Дефицит готовых ответов в бизнесе компенсируется вниманием к ситуациям, умением признавать ошибки и делать из них шаги к развитию. Взрослый руководитель делает выбор: пропускать уроки жизни мимо или использовать их для роста - пересматривать привычное, быть открытым к изменениям, внедрять новые подходы и улучшать процессы.\n🎭 Быть важнее, чем казаться Кто-то ищет оправдания и старается казаться успешным. Но в долгосрочной перспективе успех приходит к тем, кто честен с собой и командой, ценит реальное развитие выше внешнего образа, готов работать над собой и признавать свой опыт.\n👀 Как ваше решение выглядит со стороны Решение искать оправдания - образ мастера объяснений и эксперта по отговоркам. Иногда помогает здесь и сейчас, но подрывает уверенность, что завтра будет лучше. Решение признать и действовать - вы выглядите гибким и честным профессионалом, который берет ответственность и меняет систему. Растет доверие, снижается трение в согласованиях. 🤝 Что возвращает людей к вам снова? Уверенность, что вы найдете самые убедительные оправдания - или уверенность, что вы готовы идти навстречу и расти под новые требования? То, что вы расскажете про свои ограничения - или то, что непрерывные улучшения - часть вашей стратегии, и ограничения превращаются в точки роста? \u0026ldquo;Мы не виноваты\u0026rdquo; - или \u0026ldquo;мы уже скорректировали процессы, добавили проверку в тесты и обновили инструкцию\u0026rdquo;? 📣 Будь готов В День знаний призываю коллег помнить: новые знания не ограничиваются учебниками. Самое ценное - тот практический опыт, который мы ежедневно приобретаем и осознанно используем, чтобы стать сильнее как лидеры и как команда.\n","date":"2025-09-01T05:30:00Z","image":"/posts/2025/09/01-den-znaniy-kakie/01-den-znaniy-kakie.jpg","permalink":"/posts/2025/09/01-den-znaniy-kakie/","title":"🎓 День знаний: какие уроки выбираем мы"},{"content":"🔥 Пятничное: RFC Деду Морозу Дорогой Дедушка Мороз, пишу тебе RFC. Сделай, пожалуйста, чтобы все там работало как надо. Зарелизь в следующую пятницу - заживем счастливо. Дорогой пользователь, спасибо, что обратились в наше самое лучшее агентство по разработке. Мы очень любим размытые и непонятные запросы без владельцев и ответственных. У нас лучшие практики ожидания ответов, проведения бесконечных совещаний и безупречные шаблоны бесполезных протоколов. Вот и вся стратегия. С одной стороны культ волшебной кнопки, с другой - ритуалы ради ритуалов. Между ними результат, который так и не родился. Дальше будет нытье, обвинения и легкая тоска менеджера. Решений не будет.\n🌀 Манифест искривленной разработки Мы тщательно изучили лучшие способы ничего не делать, при этом выглядя очень занятыми. В результате пришли к следующим ценностям:\nПроцессы и протоколы важнее результата и ценности. Ожидание ответов важнее проактивного движения вперед. Согласования и бесконечные копии важнее личной ответственности. Отчетные артефакты важнее реальных изменений в продукте.\nПравая часть, возможно, пригодится когда-нибудь, но левую мы неизменно ценим выше. 🫠 Манифест безответственного заказчика Мы любим результат, который случается сам, и изменения без владельца. С этой высокой планкой зрелости мы пришли к таким ценностям:\nУверенность, что сами разберутся, важнее активного участия. Письмо через неделю важнее оперативной обратной связи. Срочно и бесплатно важнее реалистичных сроков и бюджета. Изменения по ощущениям важнее данных и метрик.\nМы что-то слышали про правую часть, но то, что слева - красивее. 🎯 Проектное бинго Письмо отправлено - ждем 48 часов. Если не приходит ответ - ждем дольше. Инициируем совещание для обсуждения спорных вопросов, но пока не знаем каких. Запускаем протокол для \u0026ldquo;ну а как без протокола?\u0026rdquo;. Добавляем спонсора в копию - теперь точно поедет. Еще одно согласование, чтобы окончательно размыть ответственность. Церемониально эскалируем - кто первый пожаловался, тот и победил. 🚫 Итогов нет Все трудятся в поте лица. Ничего не меняется. Все сделали все, что могли, но никто ничего не мог. Когда письма к Деду Морозу встречаются с культами протоколов, проект превращается в бега по кругу. Главное - провести совещание для согласования следующего круга.\n","date":"2025-08-29T05:30:00Z","image":"/posts/2025/08/29-tgif-rfc-dedu/29-tgif-rfc-dedu.jpg","permalink":"/posts/2025/08/29-tgif-rfc-dedu/","title":"🔥 Пятничное: RFC Деду Морозу"},{"content":"🧠 RCA в сервис-деске: от самообороны к партнерству Один из типичных паттернов техподдержки - защитная реакция. Пользователь жалуется на ошибку, а сервис-деск отвечает в оборонительном тоне:\n\u0026ldquo;Система работает корректно\u0026rdquo; \u0026ldquo;Вы сами ошиблись\u0026rdquo; \u0026ldquo;Такое поведение задокументировано\u0026rdquo;\nКажется, мы защищаем себя. На самом деле - подрываем доверие.\n💡 Сервис-деск нужен пользователям, а не системе.\nКогда пользователь открывает отчет и не видит нужную сумму, ему не поможет информация о регистрах, по которым считаются обороты. Он видит проблему - и ожидает решение. 🎯 Когнитивная ловушка Формально мы выполнили SLA - дали ответ. Фактически мы ничего не решили - только заглушили жалобу аргументами. Каждое \u0026ldquo;система работает правильно\u0026rdquo; приводит к падению доверия и росту \u0026ldquo;тихого негатива\u0026rdquo;. 🔍 Где проходит черта Формальность: закрыть тикет текстом \u0026ldquo;так работает\u0026rdquo;. Партнерство: спросить себя \u0026ldquo;а почему?\u0026rdquo;, копнуть глубже и дойти до корня. Почему в регистре нет нужной суммы? Почему регистратор не сделал движений? Как сделать так, чтобы сумма появилась? 💡 Вывод Сервис-деск, который защищает пользователя, выигрывает доверие.\nСервис-деск, который защищает систему, проигрывает все.\nРазница между \u0026ldquo;мы ответили\u0026rdquo; и \u0026ldquo;мы решили\u0026rdquo; - это признак зрелости и ценности в глазах бизнеса.\n","date":"2025-08-27T05:30:00Z","image":"/posts/2025/08/27-rca-v-servis-deske/27-rca-v-servis-deske.jpg","permalink":"/posts/2025/08/27-rca-v-servis-deske/","title":"🧠 RCA в сервис-деске: от самообороны к партнерству"},{"content":"📜Бизнес-функциональные требования, когда и зачем БФТ - договор на языке пользователей о том, как будет работать система: сценарии, CJM, блок-схема процесса, понятные границы. Без технических деталей - они пойдут в ТЗ.\n🎯 Когда требуется БФТ Мы эксплуатируем внутренние сервисы. БФТ готовим тогда, когда меняется опыт пользователя или его сценарии, либо появляется новый путь в системе. Цель - договориться на языке пользователей о новом поведении системы, границах и критериях приемки.\n🚦Триггеры для БФТ: новые шаги в процессе, статусы, роли, поля, формы, уведомления; новый путь или пользовательская история, которая ранее отсутствовала; изменения модели данных или обменов, которые пользователь увидит в отчетах, виджетах, интеграциях; 🧩 Артефакты БФТ: CJM ключевых ролей и точек контакта; блок-схема процесса (AS-IS/TO-BE) с границами и исключениями; user stories с примерами и ожидаемым результатом; список исключений и результат на языке пользователей. 🛠️Когда без БФТ можно обойтись минорные изменения, где смысл и риск очевидны: новая колонка в отчете, переименование кнопки, сортировка по умолчанию, обязательность поля без изменения логики процесса. Здесь достаточно RFC с описанием и ожидаемым результатом. изменения, не затрагивающие пользовательский опыт: изменение API, индексы в таблицах, оптимизация запросов или обновление вендора. ","date":"2025-08-25T05:30:00Z","image":"/posts/2025/08/25-biznes-funktsionalnye-trebovaniya-kogda/25-biznes-funktsionalnye-trebovaniya-kogda.jpg","permalink":"/posts/2025/08/25-biznes-funktsionalnye-trebovaniya-kogda/","title":"📜Бизнес-функциональные требования, когда и зачем"},{"content":"🔥 Пятничное: Презумпция вины ⚠️ Если думаешь, что прозрачный процесс с множеством этапов и контрольных точек спасет проект от провала - ошибаешься. Делаешь схемы.\nФормируешь To-Be.\nРаспределяешь роли и сценарии.\nПроводишь демо.\nПроводишь приемку - аплодисменты, брызги шампанского, канкан.Кажется, победа.\n❌ А через день после релиза звучит обвинение: \u0026ldquo;Ошибка! Как такое могли допустить?!\u0026rdquo;\nПриговор уже вынесен - на плахе затягивают узел.\nПользователи ликуют: \u0026ldquo;ну наконец-то этих зазнавшихся айтишников поставят к стенке\u0026rdquo;.\nВсе уверены, \u0026ldquo;Акела промахнулся\u0026rdquo;, и с удовольствием готовы унижать и растаптывать.\n🔍 Команда поднимает артефакты: требования, схемы, протоколы приемки. И вдруг оказывается - это не ошибка.\nЭто явное требование, которое проходит через весь проект с самого старта.\nПоказываешь пользователю - и слышишь в ответ:\n\u0026ldquo;А, ну ладно… но мы ж не обращали внимание\u0026rdquo;.\n💥 Так что вопрос не \u0026ldquo;как избежать ошибок\u0026rdquo;, а \u0026ldquo;готов ли ты жить с вечным ощущением, вины\u0026rdquo;.\n","date":"2025-08-22T05:30:00Z","image":"/posts/2025/08/22-tgif-prezumptsiya-viny/22-tgif-prezumptsiya-viny.jpg","permalink":"/posts/2025/08/22-tgif-prezumptsiya-viny/","title":"🔥 Пятничное: Презумпция вины"},{"content":"📉 Тревожные новости о рынке AI 🤷‍♂️ Gartner падает, OpenAI предупреждает о пузыре рынка AI Акции Gartner за месяц упали на 28%. Наш Gartner, публикующий Hype Cycle и другую аналитику о тенденциях в IT, переживает не лучшие времена. В начале года компания запустила AskGartner - AI‑инструмент, который должен выдавать релевантные инсайты для клиентов. Первые пользователи сообщали о 30-50% экономии времени при принятии решений. А сейчас инвесторы выводят деньги.\nСледом новости от OpenAI. Сэм Альтман предупреждает о риске \u0026ldquo;AI‑пузыря\u0026rdquo;, сравнивая происходящее с дот‑комами. Забавно, что такие заявления звучат на фоне планов по масштабному расширению дата‑центров, стоимостью в триллионы долларов. При этом новая модель GPT‑5 получила смешанные отзывы.\n💡 Что объединяет эти истории? AI перестал быть экспериментом. Это уже часть бизнес‑стратегий, как для аналитических компаний вроде Gartner, так и для всех нас. Но одновременно это и источник системных рисков. Кажется, ожидания потребителей тоже завышены: от AskGartner ждут 99 % экономии времени, а от GPT‑5 - полной магии и того, что \u0026ldquo;все само сделает\u0026rdquo;. Такой разрыв между ожиданиями и реальностью может привести к болезненному протрезвлению. То, на чем сегодня строятся продукты и стратегии, завтра может обрушить капитализацию.\n🤔 В интересные времена живем AI ускоряет принятие решений и повышает эффективность - и в то же время создает новые уязвимости для бизнеса и рынков. Gartner и OpenAI движутся в одном направлении, но давление ощущают оба: один - от инвесторов, другой - от масштабов ответственности.\n❓Планируете внедрять AI? Уже внедрили? Внедрили и разочаровались?\n","date":"2025-08-20T05:29:59Z","image":"/posts/2025/08/20-trevozhnye-novosti-o/20-trevozhnye-novosti-o.jpg","permalink":"/posts/2025/08/20-trevozhnye-novosti-o/","title":"📉 Тревожные новости о рынке AI"},{"content":"🧭 CJM - навигатор в изменении пользовательского опыта CJM не вместо ТЗ, а вместе. Карта показывает почему и откуда берется требование. ТЗ перестает быть списком хотелок и превращается в список конкретных болей и решений. Это инструмент для коммуникации с пользователями на простом языке - вместо десятков страниц объяснений.\n⚖️ Когда делаем CJM Меняется сценарий пользователя. Добавляются или убираются шаги, меняется последовательность, появляется новый интерфейс или роль - CJM обязательна. Кросс-функциональные стыки. Карта помогает увидеть ожидания на границах ролей. Технические изменения без влияния на сценарий. API, оптимизации, обновления платформы, отчеты - можно пропустить. 🧩 Как превращаем CJM в артефакты RFC: к моменту CJM уже согласован как предварительный этап. Карта уточняет границы и зависимости. При необходимости дает основания скорректировать цели и ограничения. ТЗ: As-Is + To-Be. Отмечаем, что уже есть и чего не хватает - получаем перечень фич и интеграций для новой схемы. Видно, что меняется для пользователя и какое ограничение снимаем. План работ. Идеи из карты - в бэклог, приоритезируем по тому, какие ограничения снимаем в первую очередь, без чего нельзя стартануть, а что лишь дополняет и улучшает опыт. 🗺️ As-Is - To-Be в 3 шага Собрать факты: где пользователи спотыкаются, исключения, ограничения. Нарисовать путь: боли и ограничения. Сформировать To-Be: какие шаги убрать/автоматизировать, какие правила/интерфейсы/интеграции нужны и какие ограничения снимаем. ⚠️ Типичные ошибки Рисуем как сами поняли. Валидируем карту с 2-3 реальными пользователями. Путаем CJM с процессными или архитектурными схемами. CJM про опыт пользователя. BPMN, sequence и C4 будут отдельными артефактами. Забываем обновлять. Все изменения на последующих шагах должны быть сопоставлены с картой. 🎯 В чем выигрыш Решения становятся прозрачными. какой шаг убираем, что автоматизируем, что заставляем пользователя делать руками. Предсказуемость. карта легко превращается в приоритезированный бэклог. Меньше споров - больше предметности. видны реальные точки боли и препятствия. 🔥 Даете заказчикам десятки страниц БФТ, а когда что-то пошло не так говорите что надо было читать внимательнее? Или используете инструменты визуализации чтобы просто объяснить сложное?\n","date":"2025-08-18T05:29:59Z","image":"/posts/2025/08/18-cjm---navigator/18-cjm---navigator.jpg","permalink":"/posts/2025/08/18-cjm---navigator/","title":"🧭 CJM - навигатор в изменении пользовательского опыта"},{"content":"🔥 Пятничное: Автоматизация не приносит ценности бизнесу Как тебе новая система? О, она просто замечательная! Теперь за день я успеваю разложить на пять пасьянсов больше! 🎬 Классический кейс про картошку Два фермера выращивают картошку. 4 мешка в месяц. Пришел регулятор и пришлось нанять бухгалтера - теперь один мешок уходит на формирование отчетности.\nПрофит компании снизился до 3 мешков - суровая современная реальность.\nБухгалтеру тяжело (не то что этим счастливым ребятам в поле). Расчетов много, требования регулятора постоянно меняются. Надо помочь и внедрить автоматизированную систему.\nПотратили 5 мешков картошки, 3 месяца и нервы всей деревни. Система заработала. Теперь любой отчет формируется одной кнопкой.\nА картошки на выходе все еще 3 мешка. 😱\n🔎 Суть проблемы Закон Паркинсона: работа раздувается под отведенные время и бюджет. Даже если мы все автоматизируем, сотрудники продолжать тратить на работу по 8 часов в день. Парадокс продуктивности ИТ: технологии сами по себе не повышают производительность. Без смены процессов, метрик и распределения выгод эффекта в цифрах не будет. 🎯 Выводы Все RFC в вашем бэклоге полностью утилизируют бюджеты и принесут компании ноль пользы. Компания все еще будет выпускать по три мешка картошки. Без Definition of Value не будет ценности: Если автоматизируется 80% рутины и тысяча человекочасов в год, результатом должен быть пересмотр KPI и схемы оплаты. Автоматизация без пересмотра правил - дорогая иллюзия прогресса. Ломайте связку \u0026ldquo;вложили в систему - платим и работаем по-старому\u0026rdquo;. Иначе получите ту же деревню с тем же бухгалтером, только с очень красивой системой и очень дорогими пасьянсами. 🙃 Вы автоматизируете, чтобы менять правила игры - или просто ускоряете привычный хаос?\n","date":"2025-08-15T05:30:00Z","image":"/posts/2025/08/15-tgif-avtomatizatsiya-ne/15-tgif-avtomatizatsiya-ne.jpg","permalink":"/posts/2025/08/15-tgif-avtomatizatsiya-ne/","title":"🔥 Пятничное: Автоматизация не приносит ценности бизнесу"},{"content":"📝 Что писать в ТЗ ТЗ - инструмент, а не ритуал. Цель не в том, чтобы \u0026ldquo;заполнить все разделы\u0026rdquo;, а в том, чтобы собрать именно те артефакты, которые необходимы для понимания задачи и приемки результата. \u0026ldquo;А вот в шаблоне было\u0026rdquo; - не аргумент. ИТ - интеллектуальный труд, здесь нужно думать, а \u0026ldquo;копать от забора до обеда\u0026rdquo; не получится.\n1️⃣ Контекст определяет содержание Вместо тысячи слов - схема процесса. Это почти универсальное дополнение, полезное в большинстве ТЗ: любая схема понятнее сплошного текста, особенно если решение нужно \u0026ldquo;продать\u0026rdquo; пользователям или стейкхолдерам.\nВ остальном отталкиваемся от потребности: содержание ТЗ должно отражать суть задачи и делать ожидаемый результат понятным всем участникам.\nИнтеграция - сиквенс-диаграмма Изменение сценария пользователя - CJM и бизнес-функциональные требования Перенос данных - таблица соответствий и правила трансформаций Новый отчет - описание колонок, источников и логики заполнения 2️⃣ Проверяй ценность Если раздел не помогает понять результат, принять решение, реализовать функцию или провести приемку - убираем или заменяем. Иногда диаграмма и таблица заменяют десятки страниц текста.\nДобавляй только то, что снижает риск неоднозначного толкования Оставляй минимум, достаточный для понимания и проверки Фиксируй риски и открыто предупреждай о возможных сложностях 3️⃣ Думай как человек ТЗ - это не заклинание. Его сила в том, что оно помогает другому человеку понять замысел и реализовать его без потери смысла.\nПиши простым языком Сложное выноси в визуализации Формулируй ожидаемый результат и критерии его проверки 📋 Мини чек-лист перед стартом Цель и метрика успеха Границы: что делаем, чего не делаем Формат: схема, сиквенс, CJM, таблица, описание отчета Способ внесения изменений Итог: не ищите универсальный шаблон. Каждый проект требует своего набора разделов и форматов. Поняв принцип, вы составите ТЗ, которое действительно работает - и для интеграций, и для UI-изменений, и для сложных отчетов.\n","date":"2025-08-13T05:33:53Z","image":"/posts/2025/08/13-chto-pisat-v/13-chto-pisat-v.jpg","permalink":"/posts/2025/08/13-chto-pisat-v/","title":"📝 Что писать в ТЗ"},{"content":"📌 Первый контакт с RFC - как мы навели порядок в бэклоге Когда задач в бэклоге много, у каждой стоит пометка \u0026ldquo;срочно\u0026rdquo;, а новые запросы продолжают сыпаться каждый день, команда теряет контроль над порядком. Все превращается в гонку, где побеждают задачи, чьи инициаторы громче всех и настойчивее о них заявляют.\n🛠 С чего начали Наведение порядка мы начали с запроса актуализации приоритетов через менеджеров подразделений. Наша цель заключалась не только в том, чтобы актуализировать бэклог, но и в том, чтобы провести приоритизацию. Для этого мы предложили собственную градацию приоритетов - от задач, связанных с требованиями законодательства и достижением ключевых KPI компании, до косметических улучшений. Актуализация через менеджеров позволила понять текущие потребности и расставить приоритеты. Создание шаблона стало следующим шагом в систематизации работы.\n📄 Шаблон RFC Чтобы прекратить захламление бэклога, мы встроили в шаблон RFC обязательные поля: причину изменений, ожидаемую выгоду для компании и блок с ожидаемым эффектом. Такой подход позволил выровнять восприятие важности задач, задать единые правила и сразу видеть, какие задачи дадут быстрый и ощутимый эффект, а какие никогда не окупят вложенные ресурсы. Теперь каждый запрос проходит \u0026ldquo;первый контакт\u0026rdquo; по стандартизированному процессу. Это не спасает от всех переделок, но значительно снижает риск работать \u0026ldquo;вслепую\u0026rdquo;, когда ИТ и бизнес понимают задачу по-разному.\n⏳ Лимит времени На этот первый контакт мы закладываем не более двух часов. Этого достаточно, чтобы понять видение бизнеса, сформировать свое понимание решения и оценить масштаб задачи. Иногда приходится погружаться глубже, но мы не передаем RFC дальше, пока обе стороны не договорятся о сути и целях.\n🎯 Решение о старте Первый контакт позволяет не тратить дорогие ресурсы аналитиков на глубокую проработку каждого запроса. На этом этапе мы собираем только необходимый минимум, формируем high-level estimate по трудозатратам и рискам и используем эти данные для решения: стартуем работу или нет. Если задача признается полезной и попадает в план, на следующих этапах аналитики детально прорабатывают требования и проектные решения. На первом контакте цель проще - понять, стоит ли вообще ввязываться и в какие сроки реалистично запланировать выполнение задачи.\n💡 Итог Такой подход отсекает непроработанные идеи, сокращает число ненужных переделок, помогает быстро выделить задачи с максимальной отдачей и отодвинуть те, что не принесут ценности, а также делает взаимодействие команды и бизнеса более прозрачным.\n","date":"2025-08-11T05:30:00Z","image":"/posts/2025/08/11-pervyy-kontakt-s/11-pervyy-kontakt-s.jpg","permalink":"/posts/2025/08/11-pervyy-kontakt-s/","title":"📌 Первый контакт с RFC - как мы навели порядок в бэклоге"},{"content":"🔥 Пятничное: Пользователи - главные враги собственной системы? Большинство проблем во внутренних системах возникают не из-за багов или вендора, а из-за самих пользователей и заказчиков. Вместо того чтобы разобраться в коробочном функционале, они с порога требуют доработок \u0026ldquo;под себя\u0026rdquo;. А ИТ, в свою очередь, заставляют воплощать в жизнь весь этот цирк без разбора.\n📊 85% внедрений обходятся без доработок Простая статистика внедрения подсистем ERP:\n42% - запуск без изменений: типовое решение работает \u0026ldquo;из коробки\u0026rdquo;. 43% - внедрение с незначительными доработками (1-10% кода). 13% - проекты с существенными правками (11-30% кода). 2% - отчаянные случаи (около 50% кода переписано).\nВывод: 85% компаний живут на стандартном функционале и не пришивают лишние рюши. 🏦 Здравое большинство vs активное меньшинство Крупный бизнес с серьезными бюджетами может позволить себе тяжелый люкс. Изучают методологию, потом осторожно докручивают детали сами формируя новые лучшие практики.\nНо активное меньшинство с бюджетом \u0026ldquo;два доширака\u0026rdquo; почему-то решает, что \u0026ldquo;коробка\u0026rdquo; их стесняет. Они уверены, что создают статусный люкс, превращая систему в цыганщину из золотых рюшечек и свистелок. Итог:\nОбновления по цене новой системы. Сроки релизов растягиваются на недели. Появляется \u0026ldquo;гениальная идея\u0026rdquo; не обновляться вовсе. Упреки в сторону ИТ: \u0026ldquo;А что так долго? А вы что не можете? А вы что не профессионалы?\u0026rdquo; ⛔ Право вето спасает систему Если вам когда-либо отказали в реализации очередного хотелки по доработке - скажите спасибо! Скорее всего, ИТ спасли вашу систему от вас же самих. Отказавшись вносить сомнительное изменение, они сохранили целостность, поддерживаемость и стабильность.\nИногда самое полезное улучшение - оставить систему элегантной и все-таки прочитать инструкцию.\n🗣 Какой образ ближе вашей компании? И как этот образ выглядит в глазах окружающих? Если вам кажется, что на вас твид от кутюр, а коллеги видят карнавальный балаган, возможно, пора снять пару слоев украшений.\nИллюстрация из внутренней презентации о работе с техдолгом на больших проектах ","date":"2025-08-08T05:30:00Z","image":"/posts/2025/08/08-tgif-polzovateli/08-tgif-polzovateli.jpg","permalink":"/posts/2025/08/08-tgif-polzovateli/","title":"🔥 Пятничное: Пользователи - главные враги собственной системы?"},{"content":"🔧 Одностраничное соглашение - фундамент качества 🔥 Приходя на \u0026ldquo;горящий\u0026rdquo; проект хочется немедленно включить DevOps-турбо-режим: настроить CI, написать сотни автотестов\u0026hellip;\nНо \u0026ldquo;вкрутить Jenkins\u0026rdquo; - не значит навести порядок. Роботы без контекста - просто тревожные лампочки. Инструменты требуют время на установку и обучение. Команде непонятно, зачем \u0026ldquo;роботы\u0026rdquo; мешают им писать код. Первые замечания от статического анализатора будут восприняты как обвинение \u0026ldquo;вы все пишете неправильно\u0026rdquo;.\n🧭 Первый бесплатный шаг Начни с диалога и одностраничного соглашения о разработке. Такое соглашение может поместиться на одну страницу и сразу снять большинство вопросов:\nЦель. Объясни единые договоренности о методах внесения изменений в поддерживаемые конфигурации чтобы сократить трудозатраты на обслуживание. Стандарты 1С. Система стандартов и методик разработки уже существует. Это база, на которую будет опираться команда. Маркеры в коде. Маркеры в изменениях кода вендора помогут контролировать сохранения модификаций при больших объединенинях и анализе изменений. Один коммит - одна задача. Комментарий к помещаемому изменению должен содержать номер задачи и общее описание изменения. Префиксы для новых объектов. Одинаковые префиксы в виде кода проекта или компании, как и маркеры в коде, позволят легко отличить проектные решения от рудиментов неудачных обновлений. Модификация только в коде. Использование общих переопределяемых модулей для модификаии форм упростит и ускорит обновления. Настройка поддержки типовых объектов. Снимай замок только с изменяемых объектов. Сразу будет видно объекты без наших модификаций, а сонар проигнорирует такие объекты, позволив сконцентрироваться только собственных изменениях.\nДоговор фиксирует идею. Когда позже появится CI, он лишь формализует то, о чем команда уже договорилась - робот подтвердит договоренности, а не \u0026ldquo;обрушит\u0026rdquo; красными ошибками.\nДокумент собирается за час, согласовывается командой и заменяет бесконечные \u0026ldquo;а давайте вот так\u0026rdquo; одним понятным ориентиром. 📊 Почему это работает Единый канон убирает бессмысленные споры о \u0026ldquo;верном\u0026rdquo; стиле, договорились - делаем. Простая трассировка позволяет быстро понять, кто и зачем изменил код - ревью и аудит ускоряются. Метки и префиксы сводят к минимуму \u0026ldquo;археологию\u0026rdquo; и сокращают время обновления: нетиповые фрагменты видны сразу. Границы ответственности ясны: одна задача - один коммит - одна причина для отката, если что‑то пошло не так. Экономия времени - меньше поисковых вопросов, меньше ручного слияния, больше часов на развитие продукта. Одна страница договоренностей не ускорит релизы сама по себе, но снимет хаос и освободит часы команды на реальные улучшения вместо повторного \u0026ldquo;археологического\u0026rdquo; труда.\n","date":"2025-08-06T05:30:00Z","image":"/posts/2025/08/06-odnostranichnoe-soglashenie/06-odnostranichnoe-soglashenie.jpg","permalink":"/posts/2025/08/06-odnostranichnoe-soglashenie/","title":"🔧 Одностраничное соглашение - фундамент качества"},{"content":"☀️ RFC начинается с \u0026ldquo;зачем\u0026rdquo;, а не с \u0026ldquo;как\u0026rdquo; Пользователь создает запрос на изменение: \u0026ldquo;Добавьте галочку\u0026rdquo;. Кажется просто - но это уже готовое решение. А действительно ли нужна именно галочка?\n🤷‍♂️ Почему \u0026ldquo;сразу делать\u0026rdquo; опасно Ненужные изменения ломают типовую методологию 1С. Каждый \u0026ldquo;быстрый фикс\u0026rdquo; усложняет поддержку и увеличивает техдолг. Пользователь остается недоволен: получил кнопку, а задача все равно не решена. 📝 Мини-чек-лист первого соприкосновения с RFC Слушаем боль, не решение. Записываем проблему словами бизнеса. \u0026ldquo;5 почему\u0026rdquo;. Выясняем корневую потребность. Проверяем существующую методологию. Ищем готовую возможность \u0026ldquo;из коробки\u0026rdquo;, чтобы не изобретать велосипед. Сравниваем варианты. Обучение, консультация, настройка, код. Формализуем пользу. Если остается код - считаем экономию/выручку. Документируем вывод. Решение + обоснование в карточке RFC. 💡Не путайте функциональные требования с проектными решениями 🛑\u0026ldquo;Добавьте табличную часть Источники финансирования\u0026rdquo; - это проектное решение, указание что и как сделать.\n✅\u0026ldquo;Система должна позволять выбирать несколько источников финансирования для одного проекта\u0026rdquo; - это функциональное требование, описание что должна уметь система, без навязывания конкретного способа реализации.\n☝️Cначала формулируем что и зачем, а как (справочник, табличная часть, кнопка) оставляем команде архитекторов и аналитиков.\n🤝 Выгоды подхода Партнерство вместо \u0026ldquo;сделайте\u0026rdquo;. Мы не отказываем, а вместе формулируем цель и предлагаем выгодный путь. Экспертиза защищает архитектуру. Команда ИТ берет ответственность за техрешение, сохраняя чистоту кода и снижая техдолг. Быстрее к результату. Без лишней разработки time-to-market сокращается, релизы становятся стабильнее. ROI на каждой правке. Показываем экономию и рост выручки до начала работ. Рост T-shape-команды. Вопросы \u0026ldquo;почему\u0026rdquo; прокачивают кросс-компетенции внутри ИТ и бизнеса. 🖐 Ваша команда уже спрашивает \u0026ldquo;почему\u0026rdquo; перед тем, как обещать срок реализации?\n","date":"2025-08-04T05:30:00Z","image":"/posts/2025/08/04-rfc-nachinaetsya-s/04-rfc-nachinaetsya-s.jpg","permalink":"/posts/2025/08/04-rfc-nachinaetsya-s/","title":"☀️ RFC начинается с \"зачем\", а не с \"как\""},{"content":"🔥 Пятничное: Пользователям не нужны надежные системы Выстроил процессы? Закрыл баги? Написал скрипты для операторов и сделал систему настолько устойчивой, что она работает сама?\nПоздравляю - ты только что создал самую скучную систему на свете. Она не ломается, не бесит и не требует героизма. Никому нет до нее дела.\nПока ты считаешь каждую минуту простоя деньгами и репутацией, по соседству процветает другой мир. В нем uptime - лишь скучный фон, а главные герои - те, кто спасает всех в последний момент.\nСистема хрупкая, чинится вручную, зато каждый фейл превращается в шоу. Баг? Зовут тебя лично. Ошибка? Ты выходишь на сцену в белом плаще и собираешь аплодисменты. Пользователи жаждут личного внимания, топ-менеджеры восхищаются мгновенной реакцией - и никто не думает, сколько это стоит.\n🙃 Надежная система убивает героев. Нет бед - нет спасителей. Нет багов - нет аплодисментов. Но вместе с бедами уходят техдолг, штрафы и бессонные ночи. Стоимость постоянного \u0026ldquo;тушения пожаров\u0026rdquo; быстро превосходит цену устойчивой архитектуры.\nБизнесу зачастую удобнее вызвать героических айтишников \u0026ldquo;пожарить баги\u0026rdquo;, чем заранее инвестировать в рутинный, безликий процесс. Ведь герой видим, а зрелая инфраструктура - нет.\n💼 ROI устойчивости 1 аварийный релиз в квартал = +20 ч перегрузки команды, задержка выпуска фич и неминуемый откат. 24×7 on-call ради \u0026ldquo;трещащей\u0026rdquo; системы = +30 % к ФОТ SRE и консультантов. Один простой на 30 минут = просто потерянная выручка. Надежная система = предсказуемая выручка и уверенный рост бизнеса. 📈 Невидимая стабильность Если ты оцениваешь стоимость риска, сокращаешь техдолг и превращаешь ИТ из пожарной команды в предсказуемый сервис, аплодисментов станет меньше - зато бизнес растет быстрее, а команда не выгорает.\n💥 Так что же на самом деле нужно пользователям и бизнесу? Герой, который чинит хаос, или лидер, который убирает хаос еще до того, как он случится?\nПока ты в тишине строишь устойчивость, помни: твой главный фан-клуб - это финансовый директор, CEO, который считает деньги, и рекрутер, который видит, как ты сохраняешь команду сильной и мотивированной.\n","date":"2025-08-01T05:30:00Z","image":"/posts/2025/08/01-tgif-polzovatelyam-ne/01-tgif-polzovatelyam-ne.jpg","permalink":"/posts/2025/08/01-tgif-polzovatelyam-ne/","title":"🔥 Пятничное: Пользователям не нужны надежные системы"},{"content":"📊 5 шагов к сильному сервис-деску: наш опыт самооценки и роста Быстрое обслуживание без системности редко бывает устойчивым. Мы честно оценили, где мы находимся сейчас и в какие стороны стоит расти. Для этого разработали компактный опросник на базе ITIL 4 и теперь делимся опытом, как это можно сделать в любой команде.\n⚙️ Экспресс-оценка: что и как мы делаем 1️⃣ Определяем практики. Берем восемь ключевых практик, которые формируют пользовательский опыт и качество поддержки:\nService Desk Incident Management Service Request Management Problem Management Knowledge Management Service Level Management Service Catalogue Management Continual Improvement\n2️⃣ Выделяем факторы успеха (PSF). Для каждой практики формулируем три критических фактора успеха (Practice Success Factors, PSF), которые влияют на эффективность процесса.\n3️⃣ Ставим оценки. Оцениваем каждый PSF по шкале 1-5:\n1 - Initial: процессы ad-hoc, все зависит от отдельных людей.\n2 - Repeatable: есть базовые процедуры, но контроль слабый.\n3 - Defined: процессы документированы и стандартизированы.\n4 - Managed: показатели измеряются, решения принимаются на основе данных.\n5 - Optimizing: процессы постоянно улучшаются и автоматизируются.\n4️⃣ Фиксируем уровень способности (Capability Level). Для каждой практики определяем минимальный достигнутый уровень: чтобы перейти выше, должны быть выполнены все критерии текущего и нижележащих уровней. Если какой-то критерий не выполнен - остаемся на предыдущем уровне.\n5️⃣ Формируем план действий. Четко видим зоны роста и описываем инициативы, которые помогут их закрыть. 💡 Зачем это нужно Получаем ясные приоритеты: оценка показывает, куда направить усилия и инвестиции в первую очередь. Становится проще объяснять менеджменту и команде, почему именно эти изменения важны. Прогресс можно измерять в динамике - это мотивирует команду и дает основу для публичных успехов. 👇 Если хотите получить наш опросник - напишите об этом в комментарии, я отправлю его вам в личку.\n","date":"2025-07-30T05:29:59Z","image":"/posts/2025/07/30-5-shagov-k/30-5-shagov-k.jpg","permalink":"/posts/2025/07/30-5-shagov-k/","title":"📊 5 шагов к сильному сервис-деску: наш опыт самооценки и роста"},{"content":"🪞 Рефлексия - заключительный, но не менее важный элемент еженедельного ревью После того как команда просмотрела все метрики и обсудила результаты недели, мы переходим к неформальной части - рефлексии.\n🎯 Зачем нужна рефлексия Помогает осознать сильные стороны и порадоваться достижениям. Дает возможность открыто обсудить трудности и скорректировать подход на следующую неделю. Поддерживает культуру безопасного общения без формальных ограничений. 📋 Как фиксируем информацию Мы ведем два самостоятельных списка, которые заполняем на завершающем этапе сервис-ревью.\nЧто получилось хорошо Пример: автоматизировали выгрузку лога - сэкономили 2 часа в день. Над чем нужно поработать Пример: дублируем статусы в почте и чате - стоит выбрать один канал. 🔍 Как проводим рефлексию Напоминаем цель: обменяться успехами и зонами роста без обвинений. Обычно достаточно 5-10 минут, но жесткого таймера нет. Один и тот же факт может появиться в обоих списках: \u0026ldquo;внедрили алерт, но триггер оказался слишком чувствительным\u0026rdquo;. Результаты фиксируем в вики. Через неделю проверяем, какие пункты из зоны роста перешли в зону успехов. 📈 Итог Рефлексия - зеркало команды: помогает увидеть и радости, и трудности. Свободный формат без строгих требований делает ее комфортной и искренней. Благодаря этому даже молчаливые участники знают: их голос услышат, когда им будет чем поделиться.\n🤔 А как ваша команда создает пространство для безопасного обсуждения успехов и ошибок?\n","date":"2025-07-28T05:43:10Z","image":"/posts/2025/07/28-refleksiya---zaklyuchitelnyy/28-refleksiya---zaklyuchitelnyy.jpg","permalink":"/posts/2025/07/28-refleksiya---zaklyuchitelnyy/","title":"🪞 Рефлексия - заключительный, но не менее важный элемент еженедельного ревью"},{"content":"🔥 Пятничное: Инцидент дешевле бесконечного аптайма Одна лишняя \u0026ldquo;девятка\u0026rdquo; в SLA звучит круто, но за нее платят не клиенты, а ваш бюджет и скорость изменений.\n🎯 Почему доступность 100 % почти всегда неоправданна Чем ближе к идеалу, тем экспоненциальнее растут затраты: резервирование, дублирование, 24 × 7 on‑call. Риск все равно остается: человеческий фактор, внешние зависимости, форс‑мажоры. Бизнес‑ущерб от редкого падения зачастую ниже, чем цена \u0026ldquo;вечной готовности\u0026rdquo;. 📊 Экономика аптайма 99 % - ≈ 88 ч простоя в год; базовый CAPEX; дежурство в рабочие часы; скорость изменений 100 %. 99.99 % - ≈ 53 мин простоя; CAPEX×1.5; + дежурный SRE; скорость изменений -10 %. 99.999 %* - ≈ 5 мин простоя; CAPEX× 3-5; 24 × 7 on‑call; скорость изменений -30 %.\n99.999 % возможны лишь при строгих условиях: дежурные могут вручную мгновенно переключить сервис на резерв или откатить релиз, и на критичных системах действует жесткий \u0026ldquo;код‑фриз\u0026rdquo; - минимум изменений, только проверенные патчи. ⚙️ Инцидент как бесплатный аудит RCA без сантиментов вскрывает самые болезненные места. Жесткий план: у каждого провала появляется владелец и дедлайн. Финансовый эффект: устраненный класс проблем экономит месяцы бессонных дежурств. 🛠 Бюджет ошибок - альтернатива бесконечного аптайма Лимит боли: определяем лимит суммарного простоя за квартал - ровно столько, сколько бизнес готов \u0026ldquo;заплатить\u0026rdquo; за инновации. ⚠️ Если вы не банк или центр управления полетами, то, скорее всего, можете позволить себе такой лимит. Условие игры: каждая упавшая минута \u0026ldquo;откупается\u0026rdquo; только после полного RCA и четкого плана действий с владельцем и сроком. Зачем считать: простои становятся прозрачным KPI; когда \u0026ldquo;банк\u0026rdquo; ошибок пуст, и бизнес, и ИТ получают сигнал - пора совместно вкладываться в надежность (резервы, автоматизацию, тесты). Реинвестируем экономию: деньги, не сгоревшие на лишних \u0026ldquo;девятках\u0026rdquo;, вкладываем в автоматизацию, тесты и мониторинг - падаем реже, поднимаемся быстрее. 🤔 Контрольные вопросы для фанатов 99.999 % Цена минуты: когда вы последний раз показали бизнесу, сколько стоит одна минута простоя вашего сервиса? Замороженные фичи: сколько релизов вы отменили или отложили ради еще одной \u0026ldquo;девятки\u0026rdquo; - и кто оплатил эту задержку? Реальный RCA: сколько денег вы уже сожгли на круглосуточные дежурства, потому что один критичный патч все еще не в проде? On‑call vs падение: есть ли цифры, что ваш 24 × 7 дежурный обходится дешевле, чем пять минут падения раз в квартал? 💡 Итог Полное отсутствие сбоев - дорогое и неоправданное удовольствие. Грамотно разобранный инцидент дешевле \u0026ldquo;стерильного\u0026rdquo; аптайма и движет систему к зрелости. Вместо гонки за лишней \u0026ldquo;девяткой\u0026rdquo; инвестируйте в культуру RCA, автоматизацию и тесты - ROI будет выше.\n","date":"2025-07-25T05:34:13Z","image":"/posts/2025/07/25-tgif-intsident-deshevle/25-tgif-intsident-deshevle.jpg","permalink":"/posts/2025/07/25-tgif-intsident-deshevle/","title":"🔥 Пятничное: Инцидент дешевле бесконечного аптайма"},{"content":"🛠️ Отчет об инциденте: превращаем проблемы в опыт Инциденты случаются даже в лучших сервисах. Итог падения определяется нашей реакцией: это может быть паника и поиск виновных или шанс стать лучше и сделать систему надежнее. В основе ITSM лежит создание непрерывного потока ценности - даже ошибки должны работать на развитие. Поэтому главное правило разбора таково: Мы разбираем систему, а не людей. Задача руководителя - понять, где защита дала сбой, и направить усилия на укрепление сервиса.\n🔎 Как проходит разбор Мы исследуем каждый инцидент - от краткого описания и момента обнаружения до проверки бэклога и фиксации опыта с корректировками, уделяя особое внимание пяти ключевым факторам. Они раскрывают корневые причины и формируют план действий, задавая направление дальнейших улучшений.\n⚠️ Последствие Что увидели пользователи и бизнес: масштаб сбоя, количество обращений, финансовые потери. Чем точнее цифры, тем выше приоритет контрмер.\n🛠️ Восстановление Пошагово фиксируем, как мы вернули сервис в норму. В итоге получается сценарий оперативного восстановления на случай повторения: скрипты, плейбуки, резервные инструменты.\n🔁 Повторение Когда корневая причина найдена, оглядываемся назад: были ли похожие инциденты, вызванные тем же фактором? Если да, анализируем, какие меры уже предпринимались и почему проблема всплыла снова. Важно убедиться, что новые корректировки действительно предотвратят повторение.\n🔍 Корневая причина Метод \u0026ldquo;пяти почему\u0026rdquo; приводит к источнику сбоя: пробел в тестах, ручная операция, уязвимость бизнес-процесса и т.д. Найдя корень, определяем, можем ли мы устранить его полностью.\n💡 Опыт и корректирующие действия Фиксируем три параметра: улучшение, ответственный, срок.\nЕсли влияние высокое, а повторение неминуемо - создаем задачу на перманентное решение.\nЕсли влияние низкое, а исправление дорого - описываем обходной способ и переносим задачу в резерв.\n🧮 Приоритизация изменений Мы оцениваем три фактора:\nвлияние инцидента на бизнес и пользователей; вероятность повторения; трудозатраты на перманентное решение.\nЕсли сбой разовый, а стоимость исправления высока, ресурсы направляем на более критичные улучшения. 🌱 Культура без обвинений Ошибка в коде - расширяем тесты и усиливаем код-ревью.\nЧеловеческий фактор - обновляем чек-листы и проводим дополнительное обучение.\nНедостаточный мониторинг - расширяем метрики и настраиваем алерты.\nТак каждое событие становится кирпичиком зрелости. Мы уходим со встречи без чувства вины и с четким пониманием, как сделать сервис надежнее.\n","date":"2025-07-23T05:34:33Z","image":"/posts/2025/07/23-otchet-ob-intsidente/23-otchet-ob-intsidente.jpg","permalink":"/posts/2025/07/23-otchet-ob-intsidente/","title":"🛠️ Отчет об инциденте: превращаем проблемы в опыт"},{"content":"💡 Запросы на изменения - превращаем RFC в убедительные цифры и демонстрируем пользу Продолжаем серию о сервис‑ревью. Работа с изменениями - тема отдельного разговора, а вот их результаты мы фиксируем именно на регулярных оперативных обзорах сервиса. Сегодня - блок \u0026ldquo;Реализованные изменения за неделю\u0026rdquo;.\n🎯 Зачем считать выгоду Убеждаем бизнес инвестировать: цифры \u0026ldquo;-160 ч. ресурсов бухгалтера\u0026rdquo; или \u0026ldquo;-6 ч. ежемесячно на рутину\u0026rdquo; звучат убедительнее, чем \u0026ldquo;улучшили форму\u0026rdquo;. Фиксируем эффект команды: каждое улучшение попадает в общий \u0026ldquo;портфель ценности\u0026rdquo;, который легко показать при подведении любых итогов. Формируем базу кейсов: ссылка на инструкцию + краткая выгода = готовый материал для внутренних анонсов и KPI‑ревью. 🗂 Мини‑шаблон для сводки Каждая реализованная доработка описывается четырьмя пунктами:\nСистема (ERP, ECM, HRM и т. д.) Заголовок изменения (кратко, понятное бизнесу название или ID RFC) Польза (конкретная метрика: часы, ₽, %) Подробности (ссылка на инструкцию или регламент) Примеры оформления: HRM - \u0026ldquo;Авансовые отчеты\u0026rdquo;\nПольза: -80 ч. бухгалтеров в месяц, полный отказ от бумаги Подробности: инструкция \u0026ldquo;Авансовый отчет\u0026rdquo; в Базе знаний ACC - \u0026ldquo;Автоматическое заполнение заявки на ДС\u0026rdquo;\nПольза: экономия ~15 мин на заявку, -16 ч. в месяц Подробности: обновлена инструкция в базе знаний ECM - \u0026ldquo;Шаблон заполнения договора\u0026rdquo;\nПольза: шаблон экономит до 750 ч. в год Подробности: инструкция \u0026ldquo;Шаблоны в договорах\u0026rdquo; 🔍 Как превращаем \u0026ldquo;факт изменения\u0026rdquo; в \u0026ldquo;ценность для бизнеса\u0026rdquo; До начала работ - вместе с бизнесом фиксируем ожидаемую выгоду (часы, деньги, экономию и т.д.). Это обязательный атрибут каждого RFC. Исключения - требования регуляторов, результаты аудитов или обязательные обновления вендоров, где ценность задается внешними факторами. После релиза - запрашиваем обратную связь . Фиксация - подводим итоги нанесенной пользы по мере релизов. Презентация - на сервис‑ревью показываем итог недели: \u0026ldquo;Экономим 200 ч. и ≈ 500 000 р. в год\u0026rdquo;. 📝 Итог Запрос на изменение без измеримой выгоды - это просто строчка в ченджлоге. Когда у каждой реализации есть цифра, ссылка и четкая история, ИТ-сервис превращается из \u0026ldquo;центра затрат\u0026rdquo; в центр создания ценности.\n","date":"2025-07-21T05:29:59Z","image":"/posts/2025/07/21-zaprosy-na-izmeneniya/21-zaprosy-na-izmeneniya.jpg","permalink":"/posts/2025/07/21-zaprosy-na-izmeneniya/","title":"💡 Запросы на изменения - превращаем RFC в убедительные цифры и демонстрируем пользу"},{"content":"Пятничное: Больше чатов - Богу чатов Хроника Васиного погружения в корпоративный шум 📥 День 1. \u0026ldquo;Добро пожаловать!\u0026rdquo; HR кидает ссылку на company-team. Десятки \u0026ldquo;🎉 Welcome!\u0026rdquo; вперемешку с обязательными объявлениями. Спасибо, уже потерял первую задачу в ленте.\n📥 День 3. \u0026ldquo;Командный чат, держи мемы\u0026rdquo; Вася вступает в team‑dev. Каждый пуш дублируется в канал; поверх этого - котики для \u0026ldquo;тимбилдинга\u0026rdquo;. Красный кружок \u0026ldquo;+99\u0026rdquo; мигает все чаще.\n📥 День 10. \u0026ldquo;Срочно, кто писал этот код?\u0026rdquo; Создают feature‑legacy‑urgent. Руководитель тэгает всех \u0026ldquo;на всякий случай\u0026rdquo;. Пол‑команды получает уведомление о баге, который чинят двое.\n📥 Месяц 1. \u0026ldquo;Запускаем проект Х!\u0026rdquo; Появляется project‑x‑obeya‑room. Нет отдельного чата - нет проекта. Внутри: все менеджеры, половина фронтенда, бухгалтер и случайный стажер.\n📥 Месяц 3. \u0026ldquo;Документация? Ищи в переписке!\u0026rdquo; У Васи уже девять рабочих каналов. Любое \u0026ldquo;а где дока?\u0026rdquo; превращается в скролл‑квест по тысячам сообщений.\n📥 Месяц 4. \u0026ldquo;Support? Это для слабаков!\u0026rdquo; У Васи диссонанс. Сервис-деск пустой, а все загружены решением срочных запросов. Пользователям гораздо быстрее бросить сообщение (голосовое 😈) в общий чат. Тикеты не создаются, SLA не стартует, история решения теряется.\n📥 Месяц 6. \u0026ldquo;+999 … и больше\u0026rdquo; Счетчик непрочитанного уходит в космос - мессенджер просто рисует \u0026ldquo;999+\u0026rdquo;. Здесь проблемы не решают, ими обмениваются в реальном времени.\n📉 Цена шума (то, что не видно в KPI) Чат вместо трекера - MTTR ⬆️ Дольше простаивают сервисы, больше штрафов по SLA. Массовые тэги - Lead Time ⬆️ Продукт выходит позже, time-to-market ползет вправо. \u0026ldquo;Документация в переписке\u0026rdquo; - Повторы задач, ФОТ ⬆️ Платим дважды за одно и то же решение. 9+ каналов на человека - Часов фокуса ⬇️ Снижение NPS/CSI: пользователи видят \u0026ldquo;вечное переключение\u0026rdquo;. Мемы в производственных потоках - Выгорание ⬆️ Отток ключевых инженеров. 💸 Финансовый штрих Команда из 10 человек, теряя \u0026ldquo;всего\u0026rdquo; 30 мин в день на лишние пинги, за год прожигает больше 1000 оплачиваемых часов - это половина годового оклада инженера плюс задержки релизов, которые напрямую бьют по выручке.\n🤬 Кто молодец? Менеджеры, плодящие каналы ради каждого чиха - \u0026ldquo;видимость работы\u0026rdquo; важнее смысла. Любители тэгать всех подряд - проще утопить всех в шуме, чем назначить ответственного. Культисты \u0026ldquo;быстрой реакции\u0026rdquo; - считают продуктивность таймстампами, а не результатом. Хранители мемов - рабочий чат превращен в стендап; ТЗ тонет в смайлах. Молчаливые \u0026ldquo;наблюдатели\u0026rdquo; - сидят \u0026ldquo;на всякий случай\u0026rdquo;, надувая счетчик подписчиков и масштаб хаоса. 🎯 Пятничный вопрос:\nСколько чатов у тебя ждут твоего внимания прямо сейчас?\nИ кто виноват, что ты даже не знаешь точную цифру? 😉\n","date":"2025-07-18T05:30:00Z","image":"/posts/2025/07/18-tgif-bolshe-chatov/18-tgif-bolshe-chatov.jpg","permalink":"/posts/2025/07/18-tgif-bolshe-chatov/","title":"Пятничное: Больше чатов - Богу чатов"},{"content":"⏳ Среднее время решения - от быстрого реагирования к быстрому результату. 🎯 Почему и зачем\nПосле первичного отклика начинается главное ожидание - когда проблема уйдет. Чем короче этот промежуток, тем меньше тревоги у пользователя. Незакрытое обращение заставляет людей \u0026ldquo;держать в голове\u0026rdquo; проблему и периодически спрашивать о статусе - лишний шум для команды. Быстрое решение возвращает сотрудников к работе и избавляет от соблазна эскалации и поиска обходных путей через личные сообщения и чаты. Среднее время решения делает видимым узкое место процесса и показывает, где автоматизация или новые скрипты дадут наибольший эффект. Системное снижение показателя прямо превращается в экономию человеко‑часов и рост удовлетворенности. 🔍 Как мы смотрим на метрику Разбивка и динамика Как и в случае с временем реакции, на графиках мы разбиваем заявки по типам и по услугам. Контрольная линия для решения 4 часа - все, что дольше, автоматически считается поводом для разбора. В динамике с начала года смотрим доли решенных заявок в разбивке \u0026lt; 30 минут, до 1 часа, до 4 часов и все что больше. Визуализация Столбчатая диаграмма среднего времени решения за неделю - разбиваем по услугам и типам заявок, видно какие системы тянут показатель вверх. Линейный график среднего времени решения в динамики с начала года показывает, как время решения ведет себя неделю к неделе: всплески моментально заметны. Столбчатая диаграмма с количеством решенных задач за неделю - разбиваем по услугам, видно колько заявок закрыто каждой командой и где нагрузка выше. Столбчатая диаграмма с распределением по временным промежуткам - показывает динамику изменения времени решения. 🛠 Как работаем с решениями дольше 4 часов 1️⃣ Каждую неделю формируем короткий список таких заявок и отвечаем на два вопроса:\nПочему так долго? Не было готового скрипта для оператора; Инструкция в базе знаний отсутствует или устарела; Процесс содержит лишние шаги; Зависели от внешнего подрядчика; Форс‑мажор или пиковая нагрузка. 2️⃣ Что изменить, чтобы не повторять заминку?\nНаписать или обновить скрипт/инструкцию? Автоматизировать ручной шаг? Пересмотреть SLA с подрядчиком? Задокументировать \u0026ldquo;известную проблему\u0026rdquo; и инициировать изменение системы? 3️⃣ Можем внедрить изменение?\nПри возможности внедряем изменение. 💡 Итог Средним временем решения управлять сложнее, чем скоростью первой реакции: здесь замешаны регламенты, скрипты и интеграции. Но именно поэтому метрику нужно измерять - управляем только тем, что видим.\nЗа прошлый год, введя регулярный разбор \u0026ldquo;длинных\u0026rdquo; заявок и прицельные улучшения, мы сократили среднее время решения в три раза.\nОдна агрегированная цифра в отчете - лишь отправная точка; дробите показатель, визуализируйте тренд и превращайте каждую аномалию в конкретное действие - тогда метрика станет реальным инструментом эффективности.\n🫵 А как у вас? Отслеживаете, сколько реальных часов уходит на закрытие задач? Что помогло ускориться?\n","date":"2025-07-16T05:30:00Z","image":"/posts/2025/07/16-srednee-vremya-resheniya/16-srednee-vremya-resheniya.jpg","permalink":"/posts/2025/07/16-srednee-vremya-resheniya/","title":"⏳ Среднее время решения - от быстрого реагирования к быстрому результату."},{"content":"⏱ Время реакции - первый показатель доверия к ИТ‑сервису 🎯 Почему важно\nПервая минута после заявки формирует ощущение \u0026ldquo;меня услышали\u0026rdquo;.\nКаждое повторное \u0026ldquo;вы получили?\u0026rdquo; бьет по доверию и создает лишний шум в канале поддержки.\nБыстрая отбивка показывает, что сервис‑деск - самый короткий путь к решению: когда ответ приходит за минуты, пользователи не пытаются обходить процесс через личные обращения к менеджерам или неформальные чаты.\nКроме того, высокая скорость первой реакции напрямую влияет на удовлетворенность пользователей и снижает потери рабочего времени компании, когда люди не отвлекаются на повторные уточнения и ожидания.\n📊 Как анализируем Разбивка по услугам За каждой услугой могут стоять отдельные исполнители и разные группы пользователей. Такая разбивка помогает понять, кто отвечает за обработку, где заявки \u0026ldquo;застревают\u0026rdquo;, как быстро берутся в работу и как различаются потребности пользователей между услугами. У каждой команды свои процессы и инструменты; разбивка позволяет увидеть, где внутренние ритуалы замедляют старт работы. Разбивка по типам заявок Инциденты, запросы на обслуживание и изменения имеют разные SLA. Смешивание скрывает реальные риски по срочным задачам. Мы берем заявку в работу сразу; при нехватке деталей оперативно запрашиваем их у пользователя - первая реакция не задерживается. Динамика с начала года Еженедельно отслеживаем на графиках, как меняется доля заявок с реакцией \u0026lt;5 мин и \u0026gt;30 мин. Сдвиг распределения отражает улучшения. Настройки дашбордов, уведомления, повышенное внимание к скорости реакции. Отмечаем пики (праздники, массовые инциденты) и фиксируем корректирующие действия - менеджмент видит, что \u0026ldquo;провалы\u0026rdquo; - исключения, а не новая норма. Визуализация Круговая диаграмма - срез за текущую неделю; распределяет заявки по диапазонам времени реакции (\u0026lt; 5 мин, 5-10 мин, 10-30 мин, \u0026gt; 30 мин). Столбчатая диаграмма - динамика с начала года по неделям; наглядно показывает, как растет \u0026ldquo;зеленая\u0026rdquo; зона и сужается \u0026ldquo;красная\u0026rdquo;. Менеджмент быстро считывает тренд без необходимости вчитываться в цифры. 🔎 Детальный разбор заявок \u0026gt; 30 минут Каждую неделю формируем список всех заявок, где первая реакция заняла более 30 минут. Для каждой записи фиксируем услугу, момент создания, причину задержки и ответственного за исправление. Главное - быстро найти первопричину и оценить, насколько реально ее устранить: уведомления можно настроить, фильтры на дашборде поправить, а если оператор не жмет \u0026ldquo;взять в работу\u0026rdquo;, нужна адресная работа с человеком и KPI, а не техническая правка. Итоги разбора оцениваем на возможность изменений в процессе и, где это реально, запускаем внедрение. Так метрика становится инструментом реальных улучшений, понятным менеджменту. 💡 Итог Одна усредненная цифра удобна для отчета, но бессильна для изменений.\nРазбейте метрику, чтобы увидеть настоящие проблемы и превратить их в конкретные действия.\nПродемонстрируйте \u0026ldquo;зеленые\u0026rdquo; графики менеджменту и пользователям - это наглядное доказательство, что сервис‑деск действительно работает и повышает удовлетворенность, снижая потери времени компании.\n","date":"2025-07-14T05:29:59Z","image":"/posts/2025/07/14-vremya-reaktsii/14-vremya-reaktsii.jpg","permalink":"/posts/2025/07/14-vremya-reaktsii/","title":"⏱ Время реакции - первый показатель доверия к ИТ‑сервису"},{"content":"🔥 Пятничное: Обновим HR‑систему? А если на самом деле нужен отчет, которого там нет? \u0026ldquo;Срочно поставьте апдейт! У всех отделов висит старая версия\u0026rdquo; \u0026ldquo;Так точно, капитан!\u0026rdquo;\nКоманда выкатывает релиз - тикет зеленый, SLA соблюден \u0026ldquo;Вы издеваетесь? Отчет о текучести все так же не формируется\u0026rdquo; \u0026ldquo;Какой еще отчет?\u0026rdquo; Мы сделали задачу, но не решили проблему - тот самый парадокс \u0026ldquo;5 минут против 8 часов\u0026rdquo;.\n🚩 Почему \u0026ldquo;сделать, как просят\u0026rdquo; = потерять время 1️⃣ Пользователь описывает средство, а не цель: считает, что обновление магически все починит, а нужна всего лишь новая форма отчетности.\n2️⃣ У него нет необходимых компетенций: выбирает самый очевидный костыль.\n3️⃣ Мы измеряем исполнение, а не эффект: заявка закрыта - график зеленый, ценность для бизнеса красная.\n🛠️ Роль сервис‑деска - устранять боль, а не ставить галочки Сервис‑деск существует, чтобы решать боль. Пользователь может не уметь формулировать задачу - специалисты переводят \u0026ldquo;как?\u0026rdquo; в \u0026ldquo;зачем?\u0026rdquo; и только потом выбирают инструмент. Регулярные сервис‑ревью показывают, где тикет решен, а проблема еще жива.\n🔍 Как выяснить потребность без допроса \u0026ldquo;чтобы что?\u0026rdquo; \u0026ldquo;В релизе появился модуль “Начисления”. Он решит задачу?\u0026rdquo; - \u0026ldquo;Нет, нужен отчет по отпускам\u0026rdquo;. \u0026ldquo;В ченджлоге исправлена ошибка совмещений. Ее ждете?\u0026rdquo; - \u0026ldquo;Нет, нужен фикс задвоения данных\u0026rdquo;. \u0026ldquo;После апдейта меняется интерфейс отчетов. Это то, что нужно?\u0026rdquo; - \u0026ldquo;Интерфейс ок, но нужен экспорт в ГосРосСельХозСтрахВозПароВоз😲\u0026rdquo;.\nКаждый вопрос - мягкий детектор реальной цели. 📉 Почему одни метрики не спасут Зеленый SLA ≠ высокая лояльность: \u0026ldquo;CEO доволен графиками, пока HR не взорвется под Новый год\u0026rdquo;. Молчание ≠ согласие: \u0026ldquo;да кто эти отчеты смотрит\u0026rdquo;. eNPS - запоздалый рентген: \u0026ldquo;SLA 99 %, eNPS -23\u0026rdquo;. 💬 Что думаете? Сразу делать, что попросили: \u0026ldquo;Мне сказали - я сделал. Мое дело маленькое\u0026rdquo;. Всегда уточнять: \u0026ldquo;Эти пользователи вообще ничего не понимают. Вечно от них одни проблемы\u0026rdquo;. Сначала подумать: \u0026ldquo;Запускаем процесс согласования. Через неделю проведем общее собрание\u0026rdquo;. ","date":"2025-07-11T05:30:00Z","image":"/posts/2025/07/11-tgif-obnovim-hr/11-tgif-obnovim-hr.jpg","permalink":"/posts/2025/07/11-tgif-obnovim-hr/","title":"🔥 Пятничное: Обновим HR‑систему? А если на самом деле нужен отчет, которого там нет?"},{"content":"⭐ Удовлетворенность пользователей - почему оценки ниже 5 важнее самой пятерки Мы привыкли радоваться пятеркам в сервис‑деске. Но зрелая команда смотрит прежде всего на все оценки ниже максимума. Именно там скрыты реальные инсайты для улучшения сервиса.\nСегодня на обзоре Уровень удовлетворенности пользователей и Обратная связь по департаментам\n🎯Уровень удовлетворенности пользователей (CSAT) Шкала оценок и нашего внимания\n5 - \u0026ldquo;Все отлично\u0026rdquo;. Фиксируем как best practice и ищем возможность масштабировать опыт. 4 - Незначительные шероховатости (скорость, коммуникация). Анализируем детали, уточняем ожидания, рассматриваем возможность улучшения. 1-3 - Ощутимое недовольство, негатив и риск эскалации. Ищем причины и возможности для исправления или улучшения с участием менеджера, принимаем корректирующие меры. Правило недели: любой балл \u0026lt;5 обсуждаем на ближайшем сервис‑ревью и используем как возможность для улучшений.\n⚠️ Почему 4 - это тоже проблема Размытые ожидания. Пользователь доволен, но не впечатлен. Эффект \u0026ldquo;снежного кома\u0026rdquo;. Мелкие недочеты копятся и превращаются в инциденты. Потенциальная потеря eNPS. Пользователь с оценкой 4 реже рекомендует сервис коллегам. ⚖️ Баланс действий и возможностей Хотя мы разбираемся с каждой оценкой ниже 5, меры по результатам анализа принимаем не всегда. Сначала оцениваем соотношение пользы и затрат, технические и финансовые ограничения. Деньгами можно залить любую проблему, но бюджет - реальное ограничение, поэтому важно держать баланс между ожиданиями сотрудников и ресурсами компании.\n📊Обратная связь по департаментам Цель - услышать каждый голос. Нам важно, кто возвращается с оценкой. Чем ближе к 100 % охвату, тем меньше слепых зон.\n🛠️ Лучшие практики для повышения охвата Встраивание фидбэка в рабочий процесс. Форма оценки направляется автоматически при закрытии заявки через ITSM‑систему. Простая и понятная форма обратной связи. Кликнуть на оценку и написать комментарий, если хочется. Демонстрация результата. Встраивайте итоги фидбэка в регулярную публичную отчетность, чтобы показать, что услышан каждый голос. 🕸️ Почему важен именно охват Слепые зоны. Без оценки мы знаем, что помогли, но не знаем, как воспринята помощь. \u0026ldquo;Тихий негатив\u0026rdquo;. Молчание прячет недовольство, которое позже всплывает эскалацией. Показатель доверия. Высокий охват = готовность делиться опытом. 📋 Тактический чек‑лист 🗂️ Форма обратной связи. Обязательный пункт \u0026ldquo;Оцените обслуживание\u0026rdquo;.\n⏳ Окно 24 часа. Даем возможность пользователям оценить работы по заявке или возобновить, перед тем как заявки будет окончательно закрыта.\n📊 Дашборд. Отслеживаем тренд \u0026ldquo;% закрытых заявок с оценкой\u0026rdquo; - индикатор культуры фидбэка.\n🏅 Геймификация. Ищем мотивирующие механики, учитывая риск искусственного роста заявок.\n💡 Выводы Пятерки мотивируют, четверки и ниже улучшают сервис. Мера без действия - просто цифра. RCA для каждой оценки \u0026lt;5 - ядро улучшений. Аналитика по департаментам = зеркало культуры обратной связи. Чем выше охват, тем яснее влияние ИТ‑сервиса. Польза для бизнеса. Высокий охват фидбэка подсвечивает узкие места процессов, сокращает простой, экономя драгоценное время сотрудников. Развитие команды. Анализ оценок \u0026lt;5 и участие в RCA - коллективная практика всей команды, укрепляющая общие компетенции и ответственность за сервис. ","date":"2025-07-09T05:29:59Z","image":"/posts/2025/07/09-udovletvorennost-polzovateley/09-udovletvorennost-polzovateley.jpg","permalink":"/posts/2025/07/09-udovletvorennost-polzovateley/","title":"⭐ Удовлетворенность пользователей - почему оценки ниже 5 важнее самой пятерки"},{"content":"📝 Поступившие и решенные заявки 🎯 Продолжаем обзор метрик еженедельного сервис-ревью\nНа повестке сегодня - две ключевые метрики:\n📥 Поступившие заявки Количество новых обращений за неделю показывает:\nНагрузку на команду Уровень цифровизации процессов Эффективность каналов самообслуживания 💡 Почему здесь цифровизация и самообслуживание? Чем выше цифровизация процессов и лучше работают каналы самообслуживания, тем меньше пользователей вынуждены обращаться в сервис-деск по простым вопросам:\nЕсли доступ можно получить через автоматизированный портал, не нужно создавать заявку. Если есть актуальная база знаний, снижается поток однотипных вопросов вроде \u0026ldquo;Где найти форму?\u0026rdquo; или \u0026ldquo;Как сформировать отчет?\u0026rdquo;. 🔻 Итог: Меньше рутинных заявок Выше удовлетворенность пользователей (они получают ответ сразу, без ожидания) Команда освобождается для решения инцидентов и задач, которые действительно требуют инженерного участия\n⚠️ Однако при запуске новых цифровых сервисов поток заявок может временно вырасти, пока пользователи привыкают к изменениям и осваивают новые инструменты. ✅ Решенные заявки Метрика решенных заявок показывает:\nФактическую производительность команды Баланс между входящими и закрытыми задачами 💡 Что здесь важно для нас? В основном заявки закрываются в срок, в рамках SLA.\nНакопление возможно только по отложенным задачам, но их влияние на общую картину обычно незначительно.\n📊 Как мы это анализируем? Мы формируем отдельные графики:\nПоступившие и решенные заявки с начала года В разрезе услуг и типов заявок (запросы на обслуживание и инциденты) Аналогичные графики за прошлый год, чтобы выявлять сезонность, корреляции и прогнозировать нагрузку 🔎 Зачем это нужно? ✔️ Прозрачность: все участники видят реальную картину\n✔️ Оценка результатов цифровизации и эффективности самообслуживания\n✔️ Формирование базы для диалога с бизнесом на языке фактов, а не ощущений\n✔️ Отслеживание динамики для принятия решений по ресурсам и приоритетам\n","date":"2025-07-07T05:30:00Z","image":"/posts/2025/07/07-postupivshie-i-reshennye/07-postupivshie-i-reshennye.jpg","permalink":"/posts/2025/07/07-postupivshie-i-reshennye/","title":"📝 Поступившие и решенные заявки"},{"content":"🔥 Пятничное: Зачем решать заявку за 5 минут, если в SLA 8 часов? 💭 Однажды в сервис-деск: 9 утра, поступает заявка.\nФактическое решение - займет 5 минут.\nА в SLA написано 8 часов.\n🛑 Что делает команда?\n\u0026ldquo;Да подождет. У нас SLA - 8 часов\u0026rdquo;.\n🔍В итоге: ✅ Заявка закрывается в 17:30.\n💯SLA выполнен.\n🏅Команда - молодцы.\n😡Пользователь - в бешенстве.\n⚖️ Парадокс SLA: Мы думаем, что покупаем скорость решения, но на самом деле покупаем гарантию, что задача будет сделана когда-нибудь в пределах SLA.\nПоэтому длинные SLA такие дешевые: бизнес платит не за быстрый результат, а за возможность команде решать задачу тогда, когда им удобно.\n🔀 Другой кейс: Пользователи требуют: Нам нужно решение срочно, буквально за 10 минут!\n🏆Команда хлопает в ладоши: Нет проблем. Пересчитываем SLA и договор на сервис. Срочная обработка всех заявок - это +3 дополнительных инженера в смену.\nЦена решения заявки вырастет в 5 раз.\n💸 После встречи со спонсором: Да не обязательно за 10 минут. Можно и полдня подождать. И даже если завтра решите, то тоже хорошо. 🤷‍♂️\n💡 Экономика SLA проста: 💰Чем меньше время решения - тем выше цена заявки.\nМы оплачиваем не только работу, но и готовность команды немедленно отреагировать.\n⌛Чем больше SLA - тем дешевле, но…\nПользователь ждет, копится раздражение, падает ценность сервиса в глазах бизнеса.\n🤔 Главные вопросы: Вы уверены, что SLA отражает реальные потребности бизнеса, или просто выбран \u0026ldquo;по шаблону\u0026rdquo; из старых регламентов?\nЗаявки решаются в соответствии с приоритетами бизнеса, или по принципу \u0026ldquo;как удобно команде\u0026rdquo;?\nПоказываете ли вы бизнесу цену скорости решения? Иногда достаточно озвучить цену мгновенной реакции, чтобы срочность снизилась.\n","date":"2025-07-04T09:05:10Z","image":"/posts/2025/07/04-tgif-zachem-reshat/04-tgif-zachem-reshat.jpg","permalink":"/posts/2025/07/04-tgif-zachem-reshat/","title":"🔥 Пятничное: Зачем решать заявку за 5 минут, если в SLA 8 часов?"},{"content":"📊 Что такое SLA и почему это важно Продолжаем разговор про сервис. Сегодняшняя тема - SLA (Service Level Agreement), договорное обязательство:\n🤝 Каждый запрос обрабатывается в установленный, заранее согласованный срок.\nЕсли заявка обрабатывается дольше - она фиксируется как просроченная.\n🛡️ Почему SLA важен для всех сторон ✔️ Для заявителей (пользователей, заказчиков):\nЧеткое понимание, когда будет предоставлено решение, без лишних уточняющих звонков и писем. SLA создает уверенность и прогнозируемость обслуживания.\n✔️ Для исполнителей (IT-команды, подрядчиков): SLA задает приоритеты и прозрачные рамки работы. Помогает организовать процессы так, чтобы запросы обрабатывались именно в оговоренные сроки. Показывает руководству и бизнесу, что команда работает стабильно и соблюдает договоренные обязательства. 📌 В итоге SLA - это баланс интересов: клиент получает гарантии качества, команда - четкие ориентиры и подтверждение своей эффективности.\n📅 Зачем разбираем SLA каждую неделю Оперативный контроль: выявляем каждую просроченную заявку, анализируем причины и устраняем их, чтобы это не стало системой, а команда быстро адаптировалась и исключала повторные нарушения. Контроль годового SLA: именно по годовому показателю подводятся общие итоги выполнения обязательств. ⚠️ Когда действуют санкции В SLA прописан допустимый буфер: несколько просрочек могут пройти без последствий. После превышения лимита начинают действовать санкции: штрафы, снижение KPI или другие договорные меры. 💡 На что обращать внимание при работе с SLA Прозрачные, легко измеряемые метрики (например, время обработки запроса в установленный срок). Регулярный пересмотр SLA и процессов, чтобы цели всегда соответствовали задачам бизнеса. Остановка таймера, когда требуется ожидание информации от пользователя. Автоматические уведомления при риске нарушения SLA. Четко прописанные пороги санкций, чтобы избежать спорных ситуаций. ✅ Итог SLA - это не просто цифра:\n✔️ Гарантия для бизнеса: заявки обрабатываются в согласованный срок\n✔️ Четкие правила для команды: приоритеты, зоны ответственности, прозрачность работы\n✔️ Инструмент управления качеством: помогает минимизировать риски и строить зрелую ИТ-сервисную модель\n🔜 На очереди динамика поступления заявок.\n","date":"2025-07-02T05:33:06Z","image":"/posts/2025/07/02-chto-takoe-sla/02-chto-takoe-sla.jpg","permalink":"/posts/2025/07/02-chto-takoe-sla/","title":"📊 Что такое SLA и почему это важно"},{"content":"🧠 Понедельничная привычка: сервис-ревью как старт недели По пятницам мы не подводим итоги недели - в этот день сервис-деск работает на полную, закрывая все срочные задачи перед выходными.\nА вот в понедельник начинаем неделю с полноценного сервис-ревью, чтобы видеть общую картину и принимать решения на основании данных.\n💡 Что включает наше сервис-ревью? 1️⃣ Уровень SLA за неделю и с начала года\nАнализ просроченных заявок Причины задержек и решения для соблюдения сроков\n2️⃣ Поступившие заявки за неделю Графики по услугам и типам (инциденты, запросы на обслуживание) Всплески, аномалии и сравнение с прошлым годом для прогнозирования загрузки\n3️⃣ Решенные задачи за неделю Динамика по услугам и типам заявок\n4️⃣ Уровень удовлетворенности пользователей Количество оцененных заявок и разбивка по оценкам Все отзывы ниже 5 баллов разбираются индивидуально, чтобы улучшать сервис и стремиться к максимальной оценке\n5️⃣ Обратная связь по департаментам Кто чаще всего оценивает нашу работу Кто не дает обратной связи вообще\n6️⃣ Время реакции Разбивка по услугам и типам Динамика за год и детальный разбор всех случаев с реакцией \u0026gt;30 минут\n7️⃣ Среднее время решения Графики по услугам и типам Анализ всех решений \u0026gt;4 часов для выявления потребности в скриптах для операторов, инструкциях или изменении процессов\n8️⃣ Реализованные изменения за неделю Какие запросы на изменения реализованы Ожидаемая польза, ссылки на инструкции - база для анонсов и демонстрации ценности для бизнеса\n9️⃣ Все инциденты за неделю Каждый инцидент имеет отчет о корневых причинах и действиях для недопущения повторений\n🔟 Рефлексия Что получилось хорошо Где наши точки роста 🎯 Почему это важно? Такие обзоры позволяют команде:\n✅ Видеть слабые места\n✅ Закреплять успехи\n✅ Учиться и развиваться\n✅ Строить сервис, которому доверяют\n🔭 Астрологи объявили июль месяцем сервис-деска. Постов на эту тему станет больше - про метрики, ритуалы и то, зачем вообще за всем этим следить.\n","date":"2025-06-30T05:30:00Z","image":"/posts/2025/06/30-ponedelnichnaya-privychka-servis-revyu/30-ponedelnichnaya-privychka-servis-revyu.jpg","permalink":"/posts/2025/06/30-ponedelnichnaya-privychka-servis-revyu/","title":"🧠 Понедельничная привычка: сервис-ревью как старт недели"},{"content":"🤔 Пятничное: Программисты ошибаются, потому что мы им позволяем. Проекты 1С часто живут годами и включают несколько конфигураций с тесными связями между модулями.\nИзменение одного механизма может влиять на работу в другом месте - и неожиданно станет проблемой в проде.\nЧасто доработки делают внешние подрядчики. Тестирование - вручную, и только в зоне изменений.\nО побочных эффектах узнаем по всплескам инцидентов в сервис-деск.\nДаже если бы команда решилась проvводить полное ручное тестирование при каждом изменении, бюджеты и сроки взлетели бы в разы - динамика изменений раздула бы ресурсы до неприемлемых величин.\n❗ Это не вина разработчиков - это сломанная система.\n🧩 С чем мы сталкиваемся Копипаст с небольшими правками, без учета контекста, приводит к непредсказуемым логическим ошибкам. Функции, рассчитанные на простые сценарии, падают при нетиповом вводе или редких сочетаниях. Потеря производительности, проявляющаяся только при реальной нагрузке и больших объемах данных. Отсутствие логов и инструментов аналитики, из-за чего выявление причины сбоя превращается в \u0026ldquo;угадайку\u0026rdquo;.\n📌 В результате даже маленький коммит становится шагом в неизвестность - не по вине программиста, а потому что система не защищает никого: ни инженера, ни менеджера, ни бизнес. ✅ С чего начать CI/CD. Даже простой процесс сборки и проверки в пайплайне снизит риски. Автотесты - пусть и запускаемые вручную перед релизом. Это базовая страховка, куда проще начать, чем сразу автоматизировать все. Статический анализ и мониторинг. Используйте SonarQube или аналогичные инструменты, чтобы находить копипаст-ошибки, логические дырки и узкие места до выката.\nИнженерная зрелость - это не отсутствие багов.\nЭто когда система: защищена от хаоса изменений, способна обеспечивать непрерывность сервиса, сохраняет репутацию и уверенность менеджмента. ","date":"2025-06-27T10:59:59Z","image":"/posts/2025/06/27-tgif-programmisty-oshibayutsya/27-tgif-programmisty-oshibayutsya.jpg","permalink":"/posts/2025/06/27-tgif-programmisty-oshibayutsya/","title":"🤔 Пятничное: Программисты ошибаются, потому что мы им позволяем."},{"content":"\u0026ldquo;Соберите отчет за год\u0026rdquo; - фраза, после которой разработчики открывают логи, менеджеры - почту, а аналитики - глаза. Потому что метрик нет. Никто не думал о них в момент запуска.\nА зря.\n🧩 Отчетность - не финал проекта, а его часть с первого дня Когда мы запускаем систему или внутренний сервис, в фокусе - фичи, инфраструктура, сроки.\nРеальность такова, что редко кто-то заранее думает о том, как потом показывать эффективность.\nНо проходит полгода или год - и требуется подготовить сводку о результатах и выводах.\nИ тут начинается интересное.\nЕсли ты не заложил логику сбора данных с самого начала - останется только восстанавливать события по логам, ощущениям, кускам excel, пытаться вспомнить, придумывать или искать людей, которые уже не в команде.\n⏰ Наступает момент, когда требуется собрать статистику А на руках не только цифр нет, так еще и непонятно какими показателями делиться.\nчастота пользовательских ошибок и инцидентов? активность по каждому модулю или сервису? использование ключевых функций? обратная связь от пользователей? ворклог по задачам команды? затраты по направлениям? насколько реально используются внедренные решения?\nЕсть только фрагменты логов, письма в почте и смутные воспоминания. 💡 Что делать Определить метрики до запуска.\nНе для KPI, а чтобы понимать, как продукт влияет на пользователей и бизнес: рост активности, снижение времени обработки, удовлетворенность пользователей. Продумать сбор данных.\nАвтоматически - хорошо.\nНо даже простая форма, в которую команда каждый день заносит ворклог, работает лучше, чем \u0026ldquo;отчет раз в месяц из головы\u0026rdquo;. Сделать результаты видимыми.\nДашборды могут быть доступны внутри компании.\nКогда данные доступны, ими пользуются.\nКогда их нет - спорят о чувствах. 📈 Автоматизация отчетности - это не про контроль. Это про управление. Позволяет говорить языком фактов Упрощает диалоги с бизнесом, спонсорами, аудиторами Защищает от выгорания: не нужно заново собирать то, что можно было вести регулярно Дает уверенность: ты знаешь, а не догадываешься 🛠️ Мы не только запускаем продукты, но и эксплуатируем. Продукт должен не только работать, но и показывать, как он работает.\nДумай об отчетности с первого дня - себе же сэкономишь недели в будущем.\n","date":"2025-06-25T05:29:59Z","image":"/posts/2025/06/25-soberite-otchet-za/25-soberite-otchet-za.jpg","permalink":"/posts/2025/06/25-soberite-otchet-za/","title":"\"Соберите отчет за год\" - фраза, после которой разработчики открывают логи, менеджеры - почту, а аналитики - глаза."},{"content":"В команде ИТ мы стремимся минимизировать субъективность в обсуждениях. Когда звучат фразы вроде \u0026ldquo;все тормозит\u0026rdquo; или \u0026ldquo;ничего не работает\u0026rdquo;, важно, чтобы у нас были инструменты, которые позволяют отличать восприятие от реальной ситуации.\nЭто было две работы назад, но подход до сих пор считаю актуальным.\nВ тот момент было принято решение внедрить метрики и визуализацию производительности 1С - и это изменило культуру взаимодействия внутри команды и с пользователями.\nТак у нас и появились Prometheus, Grafana и экспортер метрик из 1С.\nНекоторое время телевизор в кабинете отображал графики с замерами, где вместе с пользователями можно было убедиться, что на самом деле - \u0026ldquo;не так уж и медленно\u0026rdquo;.\nА бывало, что система действительно начинала тормозить - только теперь мы узнавали об этом раньше пользователей.\nНо важнее всего - это, конечно, доверие к нашим сервисам.\nИз этого опыта родился отдельный проект на GitHub.\nА сам мониторинг стал уже вторым внешним сервисом в нашем стеке.\nПервым был CI: тогда к одинокому 1С присоединились Jenkins, Docker, Sonar…\nНо об этом - в другой раз.\n*Индекс APDEX, равный 1, означает, что все операции в системе выполнены в пределах целевого времени.\nЭто идеальный результат и в большинстве случаев означает, что оптимизация не требуется.\n","date":"2025-06-23T05:30:00Z","image":"/posts/2025/06/23-v-komande-it/23-v-komande-it.jpg","permalink":"/posts/2025/06/23-v-komande-it/","title":"В команде ИТ мы стремимся минимизировать субъективность в обсуждениях."},{"content":"Цель Проект создан как простой путеводитель для запуска CI при разработке в 1С. Скорее всего будет полезен клиентам (заказчикам), которые столкнулись с проблемами качества, или находятся в начале пути разработки, при этом не имеют никаких компетенций ни в программировании, ни в администрировании.\nМинимальный результат Статический анализ кода (соответствие стандартам разработки).\nМаксимальный результат (в планах) Сценарное и регресс-тестирование (чтобы новые изменения не ломали старые, а при обновлении все само проверялось).\nОбщие положения в разработке Требования Способность держать руки над клавиатурой. Готовая виртуальная машина, или компьютер, на котором ее можно запустить. Разработка ведется с использованием Хранилища (если нет - создайте хранилище 🤷🏻‍♂️) Желание и воля. Отсутствие бюджета (опционально). Порядок установки Подробное описание установки и запуска описано в разделе Wiki, или папке docs текущего проекта.\nБлагодарности На запуск собственной сборочной линии вдохновило видео Сборочная линия с нуля. Jenkins, GitLab, SonarQube и EDT за один вечер. Ссылка по теме на infostart Быстро в Jenkins\n","date":"0001-01-01T00:00:00Z","image":"/projects/1c-devops-jr/cover.png","permalink":"/projects/1c-devops-jr/","title":"1c-devops-jr"},{"content":"Расширение добавляет в 1С:Документооборот работу с внешними инструкциями и регламентами, которые хранятся во внутренних wiki-порталах (Confluence, Notion и др.). Цель - открыть и читать материалы не покидая 1С, прямо из карточек документов, задач и процессов.\n🤷 Зачем это нужно? Решение позволяет сотрудникам работать с актуальными инструкциями и регламентами компании непосредственно из интерфейса системы документооборота, не переключаясь между различными платформами. Это экономит время и обеспечивает единый источник корпоративных знаний.\n✨ Возможности ✅ Единый интерфейс - доступ к внешним инструкциям через интерфейс 1С:Документооборот ✅ Сохранение поддержки - конфигурация остается на поддержке поставщика ✅ Актуальность данных - работа с актуальными версиями инструкций из корпоративных вики-поратолов ✅ Привычный интерфейс - работа в знакомой среде 1С 📦 Требования 1С:Документооборот редакция 2.1 или 3.0 Доступ к корпоративному вики-порталу (Confluence, Notion и т.п.) 🛠️ Установка Файл расширения (.cfe) доступен в разделе Releases\nУстановка осуществляется стандартным для 1С способом.\nПланируемые изменения Использование поля HTML-документа для отображения без скачивания текста инструкции Предложить новую функцию или сообщить об ошибке можно в разделе Issues.\n⚖️ Лицензия Материалы распространяются под лицензией MIT.\nСвободно используйте и адаптируйте для своих проектов с указанием источника.\n","date":"0001-01-01T00:00:00Z","permalink":"/projects/1c-ecm-ext-doc/","title":"1c-ecm-ext-doc"},{"content":"Цель Расширение предназначено для добавления в конфигурацию 1С подсистемы управления синхронизацией данных с внешними источниками. Оно позволяет хранить параметры подключений, определять правила и расписания синхронизаций, а также обрабатывать данные при загрузке и выгрузке. Проект реализован как расширение конфигурации.\nОбщие положения В разработке. Ограничения Для корректной работы требуется ручная настройка подключений и прав пользователей. Совместимость предполагается с конфигурациями созданными с использованием БСП, разрабатывается и тестируется на ERP 2.5. Описание Основные функции расширения:\nНастройка параметров подключений к внешним базам данных (сервер, имя БД, тип подключения). Определение запросов к внешним источникам и сопоставление данных. Формирование правил синхронизации: расписание, объекты обмена, направления. Структура метаданных Объект Тип Назначение МС_ЗапросыКВнешнимИсточникам Справочник Задания (запросы) на обмен с внешними источниками МС_НастройкиПодключений Справочник Параметры подключения к внешним источникам МС_НастройкиСинхронизации Справочник Правила синхронизации (что, куда и когда загружать) Порядок установки Скачать последнюю версию в разделе релизов.\nДобавить расшерение.\n","date":"0001-01-01T00:00:00Z","permalink":"/projects/1c-sync-manager/","title":"1c-sync-manager"},{"content":"Этот репозиторий - набор статей и минимальных примеров, чтобы любой владелец GitHub-аккаунта мог бесплатно запустить сайт-визитку или страницу проекта на Hugo и GitHub Pages.\nВсе это просто и бесплатно с использованием GitHub Pages даже без собственного домена. Если есть собственный домен, то GitHub Pages можно бесплатно использовать для хостинга сайта.\nВарианты использования сайта:\n👤 Персональная визитка 🏢 Портфолио проектов 📚 Документация 📝 Блог 🎨 Лендинг Почему Hugo Hugo - это один из самых быстрых генераторов статических сайтов:\n✅ Быстрая скорость - сайт собирается за секунды\n✅ Простота в использовании - минималистичный синтаксис\n✅ Не требует базы данных - только файлы и Git\n✅ Поддержка тем - множество готовых тем на Hugo Themes\nВозможности 🎯 Поддержка GitHub Pages 🔄 Автоматическое развертывание через GitHub Actions 🌐 Многоязычная поддержка 📱 Адаптивный дизайн 🎨 Кастомизация оформления 📖 Wiki Все материалы доступны в GitHub Wiki - это наиболее удобный формат для чтения и навигации.\nТам статьи оформлены в виде справочника и связаны между собой ссылками.\n🤝 Обратная связь и вклад Если нашли неточность, хотите дополнить или улучшить статью - оформите Pull Request или создайте Issue в репозитории.\nWiki открыта для обновлений и совместного развития.\n⚖️ Лицензия Материалы распространяются под лицензией MIT.\nСвободно используйте и адаптируйте для своих проектов с указанием источника.\n","date":"0001-01-01T00:00:00Z","permalink":"/projects/hugo-site-guide/","title":"hugo-site-guide"},{"content":"Расширение 1С для настройки обработчиков событий объектов в пользовательском режиме, без изменения основной конфигурации.\nО проекте Расширение предназначено для настройки обработки событий объектов 1С:Предприятия через пользовательский интерфейс.\nПроект находится на ранней стадии разработки. Функциональность меняется, часть возможностей не реализована, структура объектов и интерфейсов может быть пересмотрена.\nЦель Преследуемые возомжности:\nнастраивать обработчики событий без доработки основной конфигурации использовать визуальный режим настройки при необходимости добавлять произвольный код переиспользовать решение для разных типов объектов Поддерживаемые объекты Планируется поддержка следующих типов объектов:\nсправочники документы бизнес-процессы задачи Основные возможности Предусмотрены следующие направления развития:\nподписки на события объектов настройка условий срабатывания выполнение действий по настроенным правилам режим конструктора режим произвольного кода Статус Проект в статусе work in progress.\n⚖️ Лицензия Материалы распространяются под лицензией MIT.\nСвободно используйте и адаптируйте для своих проектов с указанием источника.\n","date":"0001-01-01T00:00:00Z","permalink":"/projects/object-event-handlers/","title":"object-event-handlers"},{"content":"Сборник заметок и практических рекомендаций по работе с Proxmox VE — системой виртуализации на базе KVM и LXC.\nПроект ориентирован на программистов 1С и начинающих пользователей, которые делают первые шаги в установке, настройке и администрировании домашнего.\n📘 О проекте Этот проект — не учебник и не официальная документация.\nОсновное назначение — не забыть как сделал.\nЗдесь собран личный опыт, проверенные решения и заметки по настройке Proxmox VE, которые помогут:\nустановить систему и настроить сетевые интерфейсы; организовать хранение данных (LVM, Directory); создать виртуальные машины и контейнеры; обеспечить доступ по HTTPS и автоматическое получение сертификатов; интегрировать дополнительные сервисы (TrueNAS, Traefik, Keycloak и др.). 📖 Wiki Все материалы доступны в GitHub Wiki — это наиболее удобный формат для чтения и навигации.\nТам статьи оформлены в виде справочника и связаны между собой ссылками.\n💡 Для кого полезен проект Новичкам, впервые устанавливающим Proxmox VE. Домашним энтузиастам, собирающим собственный сервер или хост для лаборатории. 🤝 Обратная связь и вклад Если нашли неточность, хотите дополнить или улучшить статью — оформите Pull Request или создайте Issue в репозитории.\nWiki открыта для обновлений и совместного развития.\n⚖️ Лицензия Материалы распространяются под лицензией MIT.\nСвободно используйте и адаптируйте для своих проектов с указанием источника.\n","date":"0001-01-01T00:00:00Z","permalink":"/projects/proxmox-notes/","title":"proxmox-notes"}]