#процессы_в_it — Public Fediverse posts

Разработка перестает быть главным дефицитом. За что теперь будут платить в IT?

Есть профессии, ценность которых определяется не только тем, что человек умеет делать, но и тем, насколько редким остается ресурс, которым он управляет. В IT таким ресурсом много лет была разработка. Хороших инженеров не хватало, бэклог почти всегда был длиннее возможностей команды, а любое заметное изменение продукта стоило времени и денег. Поэтому вместе с хорошей идеей возникал вопрос: хватит ли у разработки людей, времени и бюджета? Вокруг этого ограничения выросла привычная структура. Бизнес приносит идеи, продакт расставляет приоритеты, разработка говорит, сколько можно сделать и когда. Потом начинаются дорожные карты, планирование и торг за ресурсы. Влияние тоже концентрируется там, где дефицит: если без вашей функции следующий шаг невозможен, ее мнение весит больше. Теперь это ограничение ослабевает. Разработка перестает быть настолько дефицитной, и вместе с этим начинают меняться ценность ролей, ответственность и влияние внутри команды. Что же изменилось на самом деле? Самое простое объяснение обычно звучит так: AI теперь пишет код вместо людей. От этой фразы у разработчиков часто дергается глаз, и это понятно. Сложные системы не стали простыми. Архитектура никуда не делась, legacy тоже, а прод по-прежнему умеет падать ночью. Меняется другое. Само производство кода ускоряется, а весь путь от идеи до работающего продукта сокращается куда медленнее. JetBrains весной 2026 года сформулировала это довольно приземленно: генерация кода становится дешевой и перестает быть главным бутылочным горлышком. Главная сложность смещается к вопросу, соответствует ли результат замыслу, и сколько вся система в итоге стоит.

https://habr.com/ru/articles/1093004/

#руководитель_проектов #cto #зарплаты #руководитель_продукта #техлид #процессы_в_it #роли_в_команде #влияние_на_бизнес #влияние_ии #itруководитель

«Я думал, вы уже начали» — почему задачи зависают между «готово» и «взял»

11:07 — разработчик пишет: «Готово, можно смотреть». 11:10 — менеджер уверен, что задача уже ушла в тестирование. 13:00 — выясняется, что проверка на стороне тестирования не начиналась. Никто не забыл про задачу и не нарушил процесс. Она просто зависла между «готово» и «взял». Такие паузы редко выглядят критичными, но именно из них складываются задержки релизов, сорванные сроки и ощущение, что все постоянно заняты, а работа движется медленнее, чем должна. Я работаю QA-инженером в Ozon Tech и часто вижу, как задачи переходят между разработкой, тестированием, менеджерами и другими командами. Статус в тикете может быть обновлён, договорённость в чате зафиксирована, но ни то ни другое не гарантирует, что следующий шаг кто-то действительно принял. В статье разберу несколько типичных ситуаций, в которых происходят паузы и теряется следующий шаг, и покажу, как их распознавать. В конце соберу короткий чек-лист передачи задачи и формулировки, которые можно использовать в чатах и таск-трекере.

https://habr.com/ru/companies/ozontech/articles/1078568/

#handoff #передача #управление_разработкой #коммуникация_в_команде #jira #софтскиллы #softskills #джира #agile #процессы_в_it

Как мы за год снизили зависимость от наставников и ускорили адаптацию аналитиков

Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка. У нас был онбординг для новых аналитиков, и он не работал. Спустя месяц новички все еще не могли выполнить базовую задачу без помощи наставника. Мы решили подойти к онбордингу как к продукту: с метриками, жизненным циклом, MVP, UAT и поддержкой — и за 320 часов перепроектировали процесс с нуля. Что изменилось: 1. Сделали результат онбординга измеримым. 2. Сократили время адаптации: через неделю аналитик готов к работе. 3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников. 4. Лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла.

https://habr.com/ru/companies/tbank/articles/1074724/

#онбординг_сотрудников #адаптация_сотрудников #процессы_в_it

Эх, невизуальная доступность, как же тебя наладить

Казалось бы, на дворе 2026 год, есть статьи про доступность (и ещё больше на английском) и, собравшись организовать повышение доступности у себя в отдельно взятом «корпоративном микрорайоне», просто берёшь, читаешь, сталкиваешься с тем, что о процессах организации разработки и тестирования accessibility мало что есть, но не останавливаешься, так как молод, полон сил и наивен, и проживаешь год, полный удивительных приключений и невыносимой радости бытия. Меня зовут Шуст Иван, за мной закреплено более 15 продуктовых команд, что делают фичи ежедневного входа, профиля, истории операций и связанные с безопасностью. Поэтому я, как лид, имею прямое отношение к процессам внедрения accessibility в Альфе, проживший последний год, пытаясь наладить и внедрить процессы accessibility, расскажу о всех граблях, которые мы собрали. Вы узнаете о рабочих подходах при работе с доступностью и как делать вот точно-точно не надо . Технических подробностей будет мало. Но будет очень много про процессы/политику/конфликты, — всё то, что так сильно любят лиды будет интересно всем. В общем, добро пожаловать под кат.

https://habr.com/ru/companies/alfa/articles/1072440/

#accessibility #доступность #процессы_в_it #разработка_мобильных_приложений #тестирование #a11y

Автоматизация в отделе дизайна: опыт перестройки процессов

Всё началось на обычной стратегической сессии в конце 2025 года. Мы с коммерческим директором обсуждали планы на следующий год, пересматривали процессы и думали, где теряем время. Тогда и появился вопрос: а где искусственный интеллект действительно может быть полезен нашей команде? Расскажу, что мы перепробовали, какие задачи отдали машине и почему начинали совершенно не с нейросетей. Сразу скажу: это не история успешного успеха. Где-то мы правда сократили время в разы, где-то только учимся, а где-то честно признали, что человек пока справляется лучше.

https://habr.com/ru/articles/1067718/

#процессы_в_it #дизайн #исследование #искуственный_интеллект #автоматизация #цифровизация

Process Forge — фреймворк для создания AI-процессов

На новогодних каникулах 2026 в одном из чатов Joomla-сообщества коллега по цеху поделился промптом для ИИ-агента и результатом этого промпта. За неделю до этого он впервые попробовал Gemini CLI. Я до этого ИИ пользовался только в веб версиях и в целом меня это устраивало. Увидев простыню текста, запрос в CLI и простыню ответа первое, что меня охватило: "Я НЕ ХОЧУ вот это всё изучать! Опять что-то новое, надоело...". Потом были стадии проб и ошибок, попыток использовать готовые пакеты community skills с гитхаба с ролевым внушением "ты супер-пупер мега-бэкенд-Joomla разработчик с 40-летним опытом, сделай мне красиво". Где-то в середине этого полугодия я стал формализовать свои процессы (а это не только разработка). Формализация привела к моему пониманию некоторых базисов, которые общие для всех процессов. Об этом чуть ниже. Теперь я хочу представить на суд уважаемой публике свои наработки по фреймворку для создания формализованных процессов работы для ИИ-агентов - Process Forge (GitHub) .

https://habr.com/ru/articles/1066916/

#процессы #процессы_разработки #процессы_в_it #вайбкодинг #вайбпрограммирование #joomla #вебразработка

30 минут против месяца. Цена идеальных процессов в разработке

Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке. До банка я почти не работал в командах с выстроенными процессами. Суета, спешка, неадекватные сроки, переработки до ночи и постоянное тушение пожаров - всё это было привычной частью работы. Я видел, как команды выгорали, а проекты разваливались из-за отсутствия процессов. В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами. Ну что могу сказать - я попал. Только вот ожидания и реальность оказались совершенно разными. В этой статье я расскажу, всегда ли выстроенные процессы идут на пользу, скучаю ли я по тому самому рабочему хаосу и что в итоге выбрать разработчику: свободу и скорость или предсказуемость и порядок.

https://habr.com/ru/articles/1046393/

#процессы #карьера #java #банк #разработка #сравнение #опыт #опыт_разработчика #процессы_разработки #процессы_в_it

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

В первой части я и коллеги из Сбера, Яндекса, VK, AvitoTech, ВТБ и 2ГИС рассказывали, какими нейросетями пользуются каждый день и как это упрощает их работу. Но есть и обратная сторона. В продолжении мы поделимся тем, какие задачи принципиально делаем только руками и какой громкий хайп вокруг нейросетей оказался переоценённым.

https://habr.com/ru/articles/1040210/

#бигтех #процессы_в_it #дизайн #искусственный_интеллект #uiux

671 Allow в Claude Code за день: как родился сетап Spec-build

Это история о том, как попытка починить маленький раздражитель в Claude Code неожиданно привела меня к полноценному сетапу для разработки фич совместно с AI‑ассистентом. Приложил немного музыки для атмосферы.

https://habr.com/ru/articles/1038096/

#claude #claudecode #ииассистент #ии #методология #дизайн #процессы_управления #процессы_в_it #искусственный_интеллект #сетап

Разработка через капсулы. Капсулы и AI-агенты: как передать опыт разработчика машине

В первой части я рассказал, что такое капсула и зачем упаковывать опыт. В второй части — как мы построили капсульный фреймворк для микросервисов. Если вы не читали предыдущие части, советую начать оттуда. В этой части я покажу, что происходит, когда к капсуле подключается AI-агент. Почему жёсткая структура капсулы — это именно то, что нужно агенту. И как опыт, упакованный в капсулу, становится опытом, которым может пользоваться машина.

https://habr.com/ru/articles/1014136/

#архитектура #системный_анализ #процессы_разработки #процессы_в_it #nodejs #распределенные_системы #ai #агенты_ии

Одна ошибка — и ты ошибся. Провалы во внедрении ESM / ITSM-систем

Система управления сервисами — универсальная таблетка для оптимизации сервисных процессов и способ вывести обслуживание бизнеса на новый уровень. Так говорят многочисленные маркетинговые материалы. А как на самом деле? Забегая вперед, скажу: во многих случаях — да, ESM / ITSM действительно полезны. Однако за красивыми цифрами часто скрывается сложный, а порой и болезненный путь. Многие проекты внедрения сталкиваются с неожиданными препятствиями, не достигают заявленных целей или, что еще хуже, создают новые проблемы и заставляют сотрудников искать обходные пути. Я Сергей Вараксин — методолог-аналитик Directum, сертифицированный эксперт по ITIL4. В этой статье на примере реальных кейсов разберу наиболее распространенные причины, по которым система не оправдала ожиданий. Я расскажу, почему даже технически грамотное внедрение может не принести пользы бизнесу, как методологические просчеты сводят на нет усилия команды и чего точно не стоит делать, если ваша цель — не просто запустить систему, а выстроить эффективную сервисную модель.

https://habr.com/ru/companies/directum/articles/1009050/

#itsmсистема #esm #внедрение #ошибки_управления #service_desk #процессы_в_it #itil

Сказ о том, как мы процессы разработки в GRI меняли. Часть 1

Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI. За последний год компания заметно выросла: команд стало больше, изменений и интеграций — тоже. А процессы в разработке долго оставались такими же, какими были пару лет назад. В какой-то момент это перестало «склеиваться» само собой: ответственность размылась, централизованной точки входа в команды не было, а коммуникация стала слишком неэффективной. Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу.

https://habr.com/ru/companies/gri/articles/1007224/

#процессы #процессы_в_it #процесс_разработки #роли_в_разработке #управление_разработкой #процессы_в_компании #процессы_в_командах #процессы_разработки

Как сделать арт-аутсорс предсказуемым: система метрик для PM

Статья для PM и тимлидов, которые работают в арт‑аутсорсе или других креативных командах с высокой вариативностью задач. Я разбираю систему из четырёх метрик — estimation accuracy, task complexity, variability и volatility — которая помогает видеть устойчивость проекта, прогнозировать перегрев и принимать управленческие решения без усиления контроля над командой. Внутри: как считать каждую метрику, как читать их вместе, как внедрить без потери доверия художников и тимлидов, и какие ошибки я совершила на старте.

https://habr.com/ru/articles/1004944/

#project_management #геймдев #estimation_accuracy #управление_проектами #управление_проектами_и_командой #процессы_в_it #аутсорсинг #метрики_процесса #product_management

Почему процессы в продуктовой IT-команде не работают

В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах». Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:

https://habr.com/ru/articles/991958/

#проектный_менеджмент #продуктовый_менеджмент #itкомпании #процессы_управления #процессы_разработки #процессы_в_it #процессы_команд #процессы_в_командах #pmbok

Разрабатываем тестовый стенд с автономным ИИ-агентом QA, способным заменить тестировщика в команде разработки бэкенда

В этой статье я представил концепцию многофункционального тестового стенда с ии-агентом QA, предназначенным для эффективного и качественного решения любых задач тестирования бэкенда. Это решение позволяет создавать, запускать, отлаживать и хранить тестовые сценарии для сервиса без необходимости заботиться о инфраструктуре, контрактах API и других характеристиках сервиса. Важным преимуществом приложения является автономный ии-агент QA, который может решать до 85% задач тестировщика и в перспективе может полноценно заменить QA в команде разработки бэкенда.

https://habr.com/ru/articles/986350/

#ai #qa_automation #backend #golang #ииагенты #ииассистент #команда_разработки #процессы_разработки #процессы_тестирования #процессы_в_it

Архитектурное ревью, или Как согласовать проект с ИБ с первого раза

Наверняка вы сталкивались с проблемой согласования фичи со службой безопасности. В большинстве случаев этот процесс превращается в головную боль для программиста из-за множества непонятных этапов и деталей. Регулярно встречая подобные проблемы в своей работе, мы во Flowwow решили внедрить процесс, который помог не только снизить на треть количество времени на анализ корневых причин сложных инцидентов, но и значительно упростить согласование фич для программистов. Этот процесс получил кодовое название ADR.

https://habr.com/ru/companies/flowwow/articles/979842/

#adr #информационная_безопасность #документация #документация_it #devsecops #архитектура_приложений #согласование #процессы_разработки #процессы_в_it #flowwow

Как повысить эффективность команды за 10 минут? Просто попробуйте эти 7 канбан-досок

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

https://habr.com/ru/companies/yougile/articles/968462/

#канбан #канбан_доска #система_управления_проектами #система_управления_задачами #тасктрекер #таскменеджер #управление_командой #управление_проектами_и_командой #управление_людьми #процессы_в_it

Чужой среди своих: как аналитику войти в уже сработавшуюся команду

Привет! Меня зовут Инесса. Я — аналитик в компании fuse8. Предлагаю сегодня поговорить о том, как встроиться в уже сработавшуюся команду. По моему опыту, это всегда испытание. Почти как игра в русскую рулетку: не знаешь, как команда примет новичка и как быстро он подстроится под общий ритм. Новому человеку нужно время на адаптацию, обучение и погружение в процессы. И только потом можно по-настоящему оценить его вклад.

https://habr.com/ru/articles/960758/

#аналитика_проекта #коммуникация_в_команде #коммуникации_с_заказчиками #процессы_в_it #планирование_проекта #планирование_цикла_разработки #организация_процессов #документация_проекта

ИИ при найме

Тренд 2025 года: в некоторых бигтехах кандидату дают сложную задачу и разрешают пользоваться ChatGPT. Мол, мы же всё равно работаем с ИИ, давайте проверим, как кандидат с ним ладит. Звучит прогрессивно, на деле - странновато. Если смотреть глубже — это далеко не первый случай, когда компании увлекаются "модными форматами собеседований". И далеко не всегда это заканчивалось хорошо.

https://habr.com/ru/articles/938588/

#найм #найм_в_it #управление #управление_проектами #управление_разработкой #разработка #itкомпании #стартапы #процессы_в_it #процессы

Как продукт превращается в свалку возможностей

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

https://habr.com/ru/articles/936202/

#фичи #управление #управление_проектами #управление_разработкой #управление_продуктом #разработка #itкомпании #процессы #процессы_в_it #стартапы

Микросервисы — удача или катастрофа для стартапа?

Микросервисы звучат заманчиво, но для стартапов это может оказаться роковой ошибкой. Неужели это идеальный кандидат на неудачу?

https://habr.com/ru/articles/934386/

#микросервисы #управление #управление_проектами #управление_разработкой #разработка #itкомпании #стартапы #малый_бизнес #процессы #процессы_в_it

Agile! — паразит поедающий до костей

И как же из паразита сделать симбиота? Agile — слово, которое стартапы любят произносить на каждом питче.

https://habr.com/ru/articles/932658/

#agile #управление #управление_проектами #управление_разработкой #разработка #itкомпании #стартапы #малый_бизнес #процессы #процессы_в_it

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

Кажется, что чтобы наладить коммуникации в команде особых усилий не требуется. Многие руководители проектов думают: «люди и так договорятся» и поэтому часто фокусируются исключительно на «жестких» аспектах (сроки, бюджет, процессы). Однако именно коммуникации являются тем «клеем», который скрепляет все остальные процессы проекта и напрямую влияет на его успех или провал. И недооценивать их — ошибка. Привет, Хабр! Я Марина Евстафьева, HRBP в КОРУСе, со мной Анастасия Криулина, фасилитатор и ведущая командных сессий. Сегодня мы поговорим о важном аспекте управления командами, который часто упускают из вида — коммуникациях. О том, какими они должны быть, как их выстроить и что важно учитывать. Чтобы не загружать вас теорией, мы решили продемонстрировать все на реальных историях, свидетелями которых были сами.

https://habr.com/ru/companies/korus_consulting/articles/930232/

#управление_командой #коммуникации #коммуникация_в_команде #управление_проектами #управление_персоналом #управление_проектами_и_командой #конфликты #процессы_в_it #процессы_команд #процессы_управления

Синдром бесконечного релиза

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

https://habr.com/ru/articles/928782/

#управление #управление_проектами #разработка #релиз #процессы #процессы_в_it #ускорение #ускорение_разработки #малый_бизнес #старпат

Как выстроить работу с фичами в мобильной разработке — и не плакать

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

https://habr.com/ru/articles/917614/

#Фичи #аналитика #мобильное_приложение #процессы_в_it #Требования #продуктовый_подход #разработка_приложений

Почему ты пропустил баг? Или как настроены процессы в обеспечении качества

Мне нравится наблюдать за менторами, которые учат быть независимыми в тестировании и слать всех нафиг т.к. тестирование это не поиск багов, а сравнение ожидаемого результата с фактическим, и если нет требований, то и сравнивать нечего! Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано... Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды. Какой баг?

https://habr.com/ru/articles/915708/

#тестирование_по #qa #обеспечение_качества #процессы_тестирования #процессы_разработки #процессы_в_it #agile #поиск_багов

Как посчитать производительность команды разработки?

Среди топ‑менеджеров, а также линейных руководителей в IT‑компаниях периодически возникает вопрос: является ли та или иная команда разработки производительной? Пытаясь ответить на этот вопрос, многие приходят в тупик, так как осязать цифровое производство крайне непросто, а уж измерить его — тем более! В данной статье мы с вами попробуем разобраться, каким образом все‑таки можно попробовать измерить производительность команды разработки . Также стоит подчеркнуть, что все описанное в статье уже применяется в IT компании Flang , в которой я на данный момент времени являюсь CTO.

https://habr.com/ru/articles/907432/

#эффективность_работы #управление_разработкой #управление_командой #измерение_производительности #метрики_производительности #процессы_разработки #процессы_управления #процессы_в_it

Оценка задач в IT: делать или не делать — вот в чем вопрос?

Оценивать ли время на выполнение задач в IT? А может быть просто пойти и начать делать? А может быть можно оценить объем задач, а не время? И что же вообще нужно и можно оценить? В этой статья я рассказываю про 4 метода оценивания задач в IT — от угадывания до хороших и честных расчётов.

https://habr.com/ru/articles/901578/

#оценка_задач #оценка_времени #оценка_трудозатрат #оценка_проекта #процесс_разработки #процессы_в_it

[Перевод] Влияние LLM на людей, процессы, продукты и общество в разработке ПО: исследование с ранними пользователями

В начале марта вышло любопытное исследование от PhD студентов Computer Science университета Северной Каролины: «Влияние больших языковых моделей на людей, процессы, продукты и общество в разработке программного обеспечения: комплексное исследование с ранними пользователями». Исследование базируется на 16 глубинных интервью разработчиков – ранних адептов LLM. Структура организована вокруг четырёх измерений – разработчики, процессы, продукты и общество и посвящено влиянию больших языковых моделей (LLMs) — таких как ChatGPT, Gemini и GitHub Copilot — на разработку программного обеспечения. В ответах представлены некоторые инсайты как LLM помогает в разработке (например, подходы внедрения LLM в производственный процесс). Мы прочитали 40 страниц мелким шрифтом и делимся самым интересным.

https://habr.com/ru/articles/892506/

#llm #процессы #процесс_разработки #процессы_в_it #ai4dev

Что такое карты процесса-опыта, зачем они нужны разработчикам и как их применять

Карта процесса-опыта — это новый отечественный метод визуализации, ваш GPS в мире хаотичных бизнес-процессов. Разработчики и бизнес-аналитики часто блуждают, теряясь в сложных взаимодействиях. Карта процесса-опыта помогает эти связи описать и исправить, построить маршрут без лишних крюков и тупиков. Карту сейчас внедряют как обязательный метод для создания антихрупких IT-продуктов. Рассказал о нём Андрей Шапиро на встрече комьюнити Skillbox Code Experts. Основные мысли из выступления я изложила в этой статье. Привет, Хабр! Андрей Шапиро @xraizor — автор метода «Карта процесса-опыта», проектировщик цифровых систем, арт-директор и партнёр «Бындюсофт». А ещё, дизайнер интерфейсов, который всю жизнь проектирует цифровые продукты, думая про это. Уже 18 лет занимается и продуктовой, и заказной разработкой, два года успел поработать дата-сайентистом и даже недолго побывал трейдером. Андрей вместе с Александром Бындю @AlexanderByndyu пытаются отделить от себя методы, которыми пользуются все эти годы, описать их и передать сообществу, чтобы вместе развивать. Карта процесса-опыта — это один метод из трёх, используемых в так называемом фреймворке проектирования социотехнических систем. Сегодня речь пойдёт о ней.

https://habr.com/ru/articles/885220/

#менеджмент #управление_проектами #управление_разработкой #управление_проектами_и_командой #управление_продуктом #cjm #blueprint #bpmn #процессы #процессы_в_it