Классические театры часто строились во времена, когда об инклюзивности не задумывались. Однако сегодня даже легендарные сцены адаптируют пространство под нужды всех зрителей. Яркий пример – Большой театр в Москве. При грандиозной реконструкции, завершенной в 2011 году, архитекторы и строители заложили специальные решения для зрителей с инвалидностью. В театре появились:
Стремительное развитие информационных систем и технологий породило некогда считавшуюся немыслимой ситуацию: завершение использования программного обеспечения стало обыденностью и возможностью для компании повысить свои конкурентные преимущества. Как бы парадоксально это не звучало, но сейчас дела обстоят именно так. Изначально жизненный цикл программного обеспечения предполагал прохождение ряда состояний, включающих пред-проект внедрения, проект имплементации и пост-проект, на которых доказывалась целесообразность продукта, велась разработка, а далее – поддержка и развитие. До недавнего времени все шло именно так, а сопровождение и развитие решения могли выполняться годами.
Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.
Цель данной статьи состоит в рассмотрении заключительного этапа жизненного цикла программного обеспечения, подходов и методов применимых к нему для обеспечения разумного завершения использования софтверного продукта и его замены на прочие решения, что обеспечит непрерывность бизнес-процессов организации. Достижение цели потребует проработки следующих вопросов:
"Claude, создай мне воркфлоу в n8n" — работает или хайп?
Я настроил Claude Desktop для работы с n8n. Две недели тестил. YouTube обещает магию. Реальность оказалась сложнее: он теперь джун, а я слежу, чтобы не накосячил.
Что работает: анализ воркфлоу, поиск узких мест. Что не работает: создание сложных процессов, редактирование без глюков.
В статье — инструкция по настройке + честные выводы.
Максим Курбатов, руководитель продукта BIM Inspector (ПИК Digital)
В современном проектировании BIM-модели становятся всё более сложными, а требования к их качеству — строже. Проверка соответствия модели внутренним стандартам, ГОСТам и регламентам — неотъемлемая часть рабочего процесса. Однако ручная или полуавтоматическая проверка быстро превращается в узкое место: десятки правил, сотни элементов, часы ожидания результата.
В ПИК мы столкнулись с этой проблемой на практике. Когда проверка одной модели стала занимать до часа, стало ясно: подход «нажми и жди» больше не масштабируется. Мы задались целью не просто ускорить проверку, а полностью исключить её из активного участия проектировщика. Так родилось решение, которое мы называем «умные фермы» — распределённая система фоновой автоматической проверки BIM-моделей.
Любите настолки? И я люблю. Не только играть в них, но и разрабатывать. Правда, процесс это настолько длительный и непростой, что в основном мои амбициозные идеи умирали на бумаге. Пока на помощь не пришел генеративный ИИ.
Меня зовут Андрей Шумаков, я scrum-мастер, а также куратор по розничному бизнесу в центре развития гибких практик разработки и внедрения продуктового подхода в ПСБ. Мой интерес к настолкам в том числе рабочий: я создаю бизнес-игры. В этой статье расскажу, как создал бизнес-игру с помощью искусственного интеллекта. Scrum-мастера, берите на заметку! Под катом объясню в деталях, как составить хороший промпт и какие именно задачи поручить ИИшке, чтобы она не галлюцинировала излишне, не путалась в контексте и выдавала результат, который потом можно итерировать своими руками. Поехали!
ArchiMate, являясь языком проектирования архитектуры, предоставляет чёткую систему взаимосвязей между объектами. Эта система задаёт возможные варианты отношений для конкретной ситуации и контекста. Учитывая универсальность языка, это огромное преимущество — с его помощью можно описать как бизнес-архитектуру, так и системную, и технологическую.
В данной статье я приведу пример моделирования в нотации ArchiMate для ситуации, когда необходимо смоделировать бизнес-процесс сложной и противоречивой предметной области. Такая задача часто встречается при автоматизации процессов государственных органов и организаций, работающих в строгих законодательных рамках.
Представьте: вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратить юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений.
Помню, в далеком 2014 году, когда я примерял на себя роль проджекта, частенько срывался на продакта: «Мы же договорились! У нас дедлайн через неделю, команда уже работает! Зачем ты снова все меняешь?!»
Он спокойно отвечал что-то типа: «Есть новые данные из исследований пользователей: эта фича не подходит. Зачем делать то, что заведомо не будет работать?»
Я был уверен: продакты - это самодуры и саботажники, которые не понимают важности сроков и бюджетов. Они вечно всё переделывают, задают свои «зачем» и «почему», вместо того чтобы просто дать команде работать.
3 года спустя, будучи в роли продакт-менеджера, уже сам превратился в того самого «саботажника». Теперь я смотрел на проджектов и думал: «Как можно слепо выполнять план и не задумываться о ценности и смысле того, что делаешь? Процессы ради процессов - это путь в никуда».
Еще через пять лет, став СРО, я понял, что этот спор бессмысленен. Продакты и проджекты не враги. Это две руки одного тела, правое и левое полушария одного мозга. Проблема не в том, кто прав, а в том, что каждый подход работает в свое время и на своем месте.
В сегодняшней статье расскажу, как понять, когда нужны продакты, когда проджекты, и как они вместе влияют на компанию, продукт и их эволюцию.
Привет! Это моя первая статья на Хабре, а к ее созданию меня подтолкнуло решение кейсов для отбора на стажировку от Т-Банка - я проделывал большой объем работ, но фидбека по кейсу не получал, лишь сухое "Спасибо за участие! К сожалению..." и т.д. Подобная фраза никак не помогала мне прогрессировать, находить точки роста и выявлять ошибки в моем решении, поэтому я решил выложить результат работы здесь в надежде на обратную связь от читателей - было бы очень приятно и познавательно услышать, что можно улучшить или доработать. Приятного чтения!
Привет! Я Олег Бугримов, руковожу командой разработки ML-платформы в Авито. В статье расскажу, почему мы решили делать ML-платформу и какие инструменты у нас уже есть. Материал будет полезен ML-инженерам и техлидам, которые хотят сократить время на рутину, обеспечить команду единым набором инструментов, а также повысить качество и скорость разработки ML‑решений.
Сегодня расскажу о том, как подружил бота с GPT через OpenAI API.
Получилось быстро и почти без проблем, но есть нюанс, который видно невооружённым взглядом :-)
Когда команда растет вместе с проектной нагрузкой, задачи перестают умещаться в блокнотах или Excel. В каждой ИТ-команде, маркетинговом отделе или проектном офисе задаются главным вопросом: где и как фиксировать задачи, чтобы ничего не потерять? Казалось бы, ответ понятен — есть десятки таск-трекеров, которые помогут упорядочить этот процесс. Только как выбрать подходящий сервис?
Как бывший бизнес‑аналитик, и тот, у кого журнал абсурда, под конец года, начал трещать по швам, хотел бы описать мой самый любимый процесс.
Начинается процесс, как обычно, с благих намерений. С желания сделать идеально. Но где‑то на полпути к «идеально» происходит незаметный и фатальный сдвиг. Цель подменяется процессом. Достижение результата становится не главным, главным становится бесконечная полировка и оптимизация пути к нему.
Это и есть Процесс Вечного Улучшения (ПВУ) — форма перфекционизма, выдающая себя за добродетель.
В начале ноября после очередной шок-статьи, оказавшейся пустышкой, у меня появилась идея сервиса, который будет анализировать новости при помощи ИИ — рассказываю, что я делаю, и что из этого всего получается.
Это реальная история, не байт.
Когда слышишь слово «API», первое, что приходит в голову — это технический набор функций для программистов. Но в нашей работе с Ozon Seller API я убедился, что API — это целый продукт, в котором нужно думать не только о коде, но и о двух разных аудиториях, метриках, бизнес-логике и даже внутренней политике большой компании.
Seller API обслуживает сотни тысяч активных продавцов, а также тысячи десятки тысяч разработчиков и интеграторов, которые строят на его основе свои решения. При этом у нас есть серьезный вызов — сделать так, чтобы API был удобен и надежен для обеих аудиторий, при этом оставаясь прозрачным и стабильным интерфейсом.
Меня зовут Лев Савельев, я старший менеджер по продукту Ozon Seller API. В этой статье расскажу, как мы развиваем Seller API как продукт, с какими вызовами столкнулись, какие ошибки сделали и чему научились, и как вся работа связана с экосистемой Ozon — порталом dev.ozon.ru и существующим Магазином приложений для селлеров.
Внедрили Agile, проводите дейли и ретроспективы, делите работу на спринты — но результата нет. Пожары задач, техдолг растет, команды не успевают. В чем проблема?
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем.
Разберемся, в чем настоящая проблема и как ее решить.
Business Capability Map (карта бизнес-способностей) — это один из ключевых артефактов в современных подходах к управлению корпоративной архитектурой, особенно в таких методологиях, как TOGAF, ArchiMate и других архитектурных фреймворках. В данной статье разберемся с определением что же такое бизнес-способность, и приведем пример карты бизнес-способностей небольшого бизнеса в области обучения.
Ред-флаги и принятие своей ценности в общении с партнером. Даю три простых шага к принятию своей ценности независимо от поведения партнера, три неочевидных смысла, почему партер не прощаясь уходит и ред-флаги 2025-2026 года
Привет, Хабр! Меня зовут Станислав Якуш, я директор по развитию информационных технологий в «Группе Лента» (Lenta tech). Меня часто спрашивают: зачем крупному ритейлеру лезть на конкурентный IT‑рынок? Ведь своя‑то обойма задач всегда есть. Ответ прост: сегодня ИТ — это уже не просто затратный центр, а потенциальный драйвер роста и источник прибыли. В Lenta tech мы решились на этот поворот и сейчас активно его проживаем — без глянца, зато с реальными кейсами, ошибками и первыми результатами.
Многим компаниям знакома ситуация, когда сотрудники не справляются с объемом информации, разбросанной по документам, инструкциям, регламентам и учебным материалам. Приходится тратить время на поиск, обращаться к коллегам, затягивать процесс обучения и онбординга. Знания есть, но они не работают в нужный момент.
