Как развивать документацию и продвигать техписателей
В продуктовой команде документацией пользуются все, но ожидают от нее разного. Аналитику важно одно, разработчику — другое, поддержке — третье. Если не учитывать контекст, можно бесконечно что‑то улучшать и все равно не попадать в цель.
Даша, технический писатель Naumen SMP, рассказала о том, как через коммуникацию с командой она разбиралась в реальных ожиданиях от документации и выстраивала направление ее развития.
С чего вообще началась эта работа и какую задачу вы перед собой ставили?
Мы начали с целей. Во‑первых, хотелось сформировать понятное представление о роли технических писателей внутри команды. Во‑вторых — понять, чего заказчики действительно ждут от документации.
Как вы к этому подошли на практике?
Первым шагом мы составили каталог услуг технических писателей. Если ты хочешь, чтобы коллеги понимали твою роль, важно сначала самим зафиксировать, что именно ты делаешь и в каком объеме.
Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.
Как проходили интервью и что оказалось самым сложным?
Мы начинали с обсуждения каталога услуг. Потом говорили о проблемах с документацией и процессами, а в конце проверяли наши гипотезы.
Сложнее всего было работать с эмоциональными запросами. Потому что важно не останавливаться на эмоции, а докапываться до сути. Очень помогал метод «5 почему»: позволяет превратить раздражение в конкретное и решаемое требование.
Что получилось после обработки всех интервью?
Мы сгруппировали потребности и получили 12 направлений. Самые заметные — это нехватка понимания роли технических писателей, запрос на обновление интерфейса документации и очень сильная боль у разработчиков по поводу документации по API.
Как вы поняли, за что браться в первую очередь?
Использовали простой фреймворк приоритизации «ценность / усилия». Смотрели не только на то, как часто звучит проблема, но и на силу боли. Поэтому, например, поиск в документации стал приоритетнее аналитики — о нем говорили реже, но намного острее.
Какие результаты уже есть?
Мы собрали регламенты и знания о работе технических писателей в одном месте, сделали публичный каталог услуг, обновили интерфейс документации вместе с дизайнерами и разработчиками, а документацию по API переработали совместно с командой разработки: улучшили навигацию и примеры.
Твой главный вывод из этого опыта?
Документация развивается не сама по себе: она развивается через диалог. Коммуникация помогает не только улучшать тексты, но и выстраивать понимание роли, ожиданий и зон ответственности. Когда это появляется, становится проще принимать решения и двигаться дальше и в документации, и в продукте.
После запуска лендинга начали прилетать первые заявки. И в какой‑то момент у меня возник вопрос: а если вообще к ним не прикасаться и посмотреть, что будет, если агент, как заявляют, может сам автономно работать, то пусть уже и обработкой лидов занимается
Собрал простую логику:
Заявка с формы падает на почту.
Каждые 15 минут агент сам идёт в inbox и смотрит новые письма.
Достаёт из письма имя, email и компанию.
Гуглит информацию о компании: чем занимаются, сколько людей, чем живут.
Ставит оценку лида от 1 до 10 по тем критериям, которые мы раньше прописали, когда думали над лендингом.
Если 5 и выше сам отвечает, предлагает созвон, задаёт пару уточняющих вопросов и продолжает диалог. Ниже 5 — кидает в «низкий приоритет».
То есть задача: не просто разложить письма по папкам, а реально принять решение и начать общаться вместо меня.
Что в итоге с заявками? Честно? ничего эпичного. В какой‑то момент просто закончились токены API, и бот тихо умер. Это был эксперимент, я не следил за потолком по бюджету, поэтому всё остановилось не потому что «технология не работает», а потому что я забил на настройки.
Минусы Clawdbot
Цена эксперимента. Около $400 за Claude API за одну неделю для теста это перебор. Для боевого кейса, где один лид стоит дорого, уже не так страшно. Но если нормально конфигурировать (дешёвые модели на рутину, лимиты по токенам и т.д.), это можно ужать до $100–150 в месяц и ниже.
Галлюцинации. Он несколько раз придумывал вещи, которых не было: размеры компаний, инструменты, цифры. Я это пока не воспринимаю как «всё, выкидываем», потому что большая часть проблемы в архитектуре памяти и контекста: как он хранит свои знания, как к ним обращается. Это нужно чинить именно на уровне архитектуры агента, а не в промпте.
На выходных хочу показать на видео, как это вообще поднять с нуля на облаке и настроить под свои задачи, если вы не технарь. Если у вас есть вопросы напишите, постараюсь ответить на видео и показать.
P.S Если нужен готовый Product Discovery Agent, с которым я это всё гонял, напишите, выложу.
Мой Телеграм канал, кстати на 15 февраля запланирован бесплатный воркшоп по вайбкодингу, записаться там же в тг.
OAuth на практике: что оказалось удобным, а что отпугнуло пользователей
Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).
Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.
С чего начали
Для обычных пользователей: • Email / пароль • Google • GitHub
Для разработчиков — жёстче: • Обязательная привязка Google • Обязательная привязка GitHub
Логика казалась разумной: «Разработчик = есть GitHub» «Двойная верификация = меньше спама»
На практике это не сработало.
Первые тревожные сигналы
Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.
Сначала списывали на: • новый продукт • низкое доверие • отсутствие аудитории
Но после общения с разработчиками (в том числе через Habr) картина прояснилась.
Что отпугивало разработчиков
Новый сервис → нежелание делиться данными
Даже если это «просто email», психологический барьер остаётся.
Когда с первого шага нужно: • линковать внешние аккаунты • проходить несколько этапов подтверждения • подключать сторонние сервисы
это воспринимается как лишний фрикцион.
Особенно для соло-разработчиков и небольших команд.
Git ≠ GitHub
Ключевой инсайт.
Мы обнаружили, что: • не все хотят логиниться через GitHub • часть использует GitLab или Bitbucket • некоторые принципиально не хотят связывать GitHub с новым сервисом
Обязательная привязка GitHub стала серьёзным барьером.
А мнение стандартных пользователей разделилось:
Часть говорила:
«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».
Логика простая: • если есть Google / Facebook / Discord — значит не ноунейм • интеграции с крупными сервисами повышают доверие
Это не про безопасность — это про ощущение легитимности.
Другие говорили ровно противоположное:
«Слишком много кнопок — ощущение перегруженности».
И это тоже справедливый аргумент.
Что мы изменили
Упростили форму для пользователей
Оставили: • Google • Facebook • Discord
Достаточно выбора для доверия, без визуального шума.
Git-провайдеры вынесли в отдельную группу
Под отдельной кнопкой: • GitHub • GitLab • Bitbucket
Для разработчиков это стало понятнее и логичнее.
Убрали обязательный GitHub
Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.
Без принудительного GitHub.
Первые цифры (осторожно)
Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.
Тем не менее: • Зарегистрированные пользователи: +13% (было 0–6% в неделю) • Зарегистрированные разработчики: +16% (было 0–3%)
Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.
Выводы (пока не финальные) • OAuth — это не только безопасность, но и психология доверия • Жёсткие требования на старте почти всегда бьют по росту • Git ≠ GitHub — и это важно • Много провайдеров могут как повышать доверие, так и перегружать UI
Для молодой платформы даже такие ранние сигналы уже показательны.
Интересно услышать опыт коллег: добавляли ли вы OAuth-провайдеров после запуска? были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?
Аппаратная виртуализация: как работает и зачем нужна
Виртуальные машины, облачные платформы, миграции без простоя — всё это держится на аппаратной виртуализации. Технология давно стала базой для дата-центров и корпоративных инфраструктур, но вопросы «как именно это работает» и «чем отличается от программной виртуализации» возникают регулярно.
В новом материале разобрали архитектуру аппаратной виртуализации, сравнили полную виртуализацию, паравиртуализацию и виртуализацию с аппаратной поддержкой. Также прошлись по различиям между гипервизорами первого и второго типа, разобрали плюсы и минусы подхода, сценарии применения — от консолидации серверов до облачных IaaS-платформ — и добавили FAQ по безопасности и отказоустойчивости.
Открываем регистрацию на GoCloud 2026 — конференцию про AI и облака 🦾☁️
Уже 9 апреля мы вновь встречаемся на нашей главной ежегодной конференции. В этом году ключевой темой станет AI как сервис — а именно, простые, безопасные инструменты для работы с AI и AI-агентами, которые можно использовать сегодня. Еще поговорим о кибербезопасности, гибридных решениях, трендах в работе с данными и многом другом.
Что вас ждет
4 трека про AI, Data, инструменты разработки и облачную инфраструктуру
40+ спикеров
Демозоны сервисов
Практические воркшопы
Нетворкинг и afterparty
Что узнаете
Какие инструменты позволяют использовать AI без кастомной разработки и долгой настройки
Как бизнес уже работает с AI-системами и какие результаты получает от их внедрения
Тренды в AI, облаках и работе с данными, а также подходы, которые становятся стандартом для бизнеса
Сценарии использования сервисов, готовые инструменты и способы оптимизации затрат в ваших проектах
Как выстраивается полный цикл разработки и доставки с минимальной нагрузкой на команду
Как принять участие
Можно посмотреть трансляцию на сайте (ссылка придет зарегистрированным участникам в письме) или прийти в кинотеатр «КАРО 11 Октябрь», ул. Новый Арбат, 24 в Москве. Собираемся 9 апреля в 10:00. Количество мест для офлайн-участия ограничено. Регистрируйтесь уже сейчас.
👉 Зарегистрироваться на GoCloud 2026 Постепенно будем рассказывать о программе, а пока можете почитать, как прошли предыдущие конференции Cloud.ru:
Может показаться, что начинать изучать программирование поздно — все вакантные места уже заняты другими разработчиками. Но это не так: толковые специалисты нужны всегда и везде, поэтому начать никогда не поздно.
Если не знаете какой язык выбрать, присмотритесь к одному из самых популярных — к C++. Он хорошо подходит для системного и прикладного программного обеспечения, игровых движков, финансовых технологий, высоконагруженных сервисов, встраиваемых систем и всего, где важна скорость и эффективность.
Для вашего удобства мы собрали учебные программы по C++ в одном месте — на Хабр Карьере, а сегодня предлагаем познакомиться с основными инструментами, которые вам предстоит освоить, чтобы стать опытным разработчиком:
— С++. Основа основ: язык программирования с высокой производительностью.
Краткий обзор применяемых материалов и процессов изготовления гибких плат, которые требуют изменения подхода к проектированию. Рассмотрим конкретные примеры дизайна меди, покрывной пленки, краевых разъемов, обработки контура и панелизации.
Участие — традиционно бесплатное по предварительной регистрации
После запуска лендинга начали прилетать первые заявки. И в какой‑то момент у меня возник вопрос: а если вообще к ним не прикасаться и посмотреть, что будет, если агент, как заявляют, может сам автономно работать, то пусть уже и обработкой лидов занимается
Собрал простую логику:
Заявка с формы падает на почту.
Каждые 15 минут агент сам идёт в inbox и смотрит новые письма.
Достаёт из письма имя, email и компанию.
Гуглит информацию о компании: чем занимаются, сколько людей, чем живут.
Ставит оценку лида от 1 до 10 по тем критериям, которые мы раньше прописали, когда думали над лендингом.
Если 5 и выше сам отвечает, предлагает созвон, задаёт пару уточняющих вопросов и продолжает диалог. Ниже 5 — кидает в «низкий приоритет».
То есть задача: не просто разложить письма по папкам, а реально принять решение и начать общаться вместо меня.
Что в итоге с заявками? Честно? ничего эпичного. В какой‑то момент просто закончились токены API, и бот тихо умер. Это был эксперимент, я не следил за потолком по бюджету, поэтому всё остановилось не потому что «технология не работает», а потому что я забил на настройки.
Минусы Clawdbot
Цена эксперимента. Около $400 за Claude API за одну неделю для теста это перебор. Для боевого кейса, где один лид стоит дорого, уже не так страшно. Но если нормально конфигурировать (дешёвые модели на рутину, лимиты по токенам и т.д.), это можно ужать до $100–150 в месяц и ниже.
Галлюцинации. Он несколько раз придумывал вещи, которых не было: размеры компаний, инструменты, цифры. Я это пока не воспринимаю как «всё, выкидываем», потому что большая часть проблемы в архитектуре памяти и контекста: как он хранит свои знания, как к ним обращается. Это нужно чинить именно на уровне архитектуры агента, а не в промпте.
На выходных хочу показать на видео, как это вообще поднять с нуля на облаке и настроить под свои задачи, если вы не технарь. Если у вас есть вопросы напишите, постараюсь ответить на видео и показать.
P.S Если нужен готовый Product Discovery Agent, с которым я это всё гонял, напишите, выложу.
Мой Телеграм канал, кстати на 15 февраля запланирован бесплатный воркшоп по вайбкодингу, записаться там же в тг.
Интуиция — плохой советчик, когда на кону бюджет в миллионы. Выбор технологического стека, подрядчика или стратегии развития часто превращается в «битву мнений». Побеждает тот, кто громче, а не тот, кто прав. Результат: внедрение ради внедрения, скрытые косты и проваленные сроки.
Роль Agile Coach мертва… да здравствует агент изменений
TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.
Зачем компания платит продактам и тимлидам хорошие деньги? Наверное, не для того, чтобы кто‑то другой создавал атмосферу безопасности, фасилитировал и работал с людьми.
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет.
Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: «А что, если я уйду?»
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.
Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.
Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.
Более того, если долго работать с одной командой - возникает привыкание и порой выученная беспомощность, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лидам и выйти. А потом трекать (как в настоящем стартапе) - что получается у лидов и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес‑стратегию, будь то организационная трансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это «не по аджайлу».
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.
Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация - язык не поворачивается назвать это «софт скилами». Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».
Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.
На вебинаре поговорим:
— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды — 5 классов интеграционных решений: когда какой работает, а когда — категорически нет — Как мы строили матрицу зрелости и кто в итоге получил номинацию — Что планируем исследовать дальше — и как повлиять на приоритеты
Будет живой эфир с интерактивом, не просто «говорящая голова».
Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.
Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями...
Вы наверное уже видели хайп вокруг OpenClaw (он же Clawdbot) – open-source AI-агент, куча постов в твиттере про него, и тут же волна разоблачений: утечки данных, открытые серверы, дыры в безопасности.
Да, кстати бэкдоры там есть. Не классические, но серые зоны в коде нашёл, клонировал репо и почистил всё руками. Если интересно – расскажу отдельным постом, там любопытная история.
Это AI-ассистент с открытым кодом, который умеет не только отвечать текстом, а выполнять действия. Ты пишешь ему в Telegram обычным языком что нужно сделать. А у него под капотом набор инструментов: он может открыть браузер, зайти на любой сайт, прочитать и отправить почту, создать и отредактировать файл, запустить команду на сервере, поставить задачу по расписанию.
Ты описываешь задачу, а он сам выбирает какие инструменты нужны, сам выстраивает порядок действий, и работает шаг за шагом пока не сделает. Всё это крутится на твоём сервере или компе, 24/7.
Написал «зайди на сайт конкурента, выпиши их тарифы» он реально откроет сайт, прочитает страницу, пришлет таблицу. Написал «проверь почту, если есть заявки разбери» он зайдет в Gmail, посмотрит письма, обработает ну и т.д. насколько хватит фантазии, есть свои но...
Мне было интересно другое: а эта штука вообще что-то полезное умеет?
У меня давно лежал список из идей, наверное всем знакомо это чувство, когда идей много, на каждую нужна неделя+ ресёрча, чтобы понять а надо ли это делать. В одиночку это оверкилл, сидеть по выходным не всегда получается.
В общем я поставил себе этого уникума. Там кстати установка не такая уж и сложная все понятно, единственное я бы не рекомендовал вам устанавливать на свой личный комп, а на рабочий уж тем более.
Запустил, настроил под себя, еще сделал для него инструкции (skills) под свои задачи: что и как выполнять.
И вуаля телеграмме у вас там появляется свой "ИИ друг", который умеет больше чем просто чат гпт. Первым же делом написал ему промпт:
«Вот 10 моих идей для продуктов .... пройдись по каждой найди рынок, определи боль. Если боли нет убей идею. Те что выжили приоритизируй. Для лучшей собери лендинг и подготовь рекламу. Работай сам»
Агент за ночь прошёлся по 7 из 10 идей (на 3 не хватило контекстного окна). Для каждой: нашёл конкурентов через поиск, зашёл на их сайты через браузер, спарсил прайсинг, проанализировал отзывы. Спарсил Редит, ТГ каналы и комменты (неожиданно, такое я в инструкции не писал), выявил боли ЦА собрал табличку с приоритетами.
Три идеи убил сам. Написал: «Нет подтверждённой боли, рынок перенасыщен, не рекомендую тратить время». С аргументами, со ссылками.
Сделал: JTBD интервью на синтетических пользователях, ICE-скоринг гипотез. Приоритизировал и выбрал сам одну гипотезу.
Для идеи-лидера: сгенерировал HTML-лендинг, задеплоил на Vercel одной командой и прислал мне живую ссылку. Написал 5 вариантов объявлений для Яндекс.Директ с ключевыми словами.
С самим Директом через браузер не справился там тяжёлый интерфейс с капчей. Тексты взял его, я кампанию настроил руками.
Запустил рекламу. Настроил агенту, чтоб каждое утро сам проверял статистику, оптимизировал ключи, отключал не релевантные. Присылал мне отчёт.
ИИ агент получил 3 лида через форму обратной связи на лендинге.
Но самое интересное случилось с этими заявками — и об этом в следующем посте.
Спойлер: агент не просто собирал заявки. Он сам их обрабатывал, квалифицировал и отвечал клиентам. Без моего участия.
Что за новый фреймворк OGD4All? Разбираемся вместе с лабораторией искусственного интеллекта компании «Криптонит».
Open Government Data For All (OGD4All) — новый фреймворк, использующий большие языковые модели (LLM) для работы с открытыми геоданными. Он позволяет задавать вопросы на естественном языке, без сложных SQL-запросов и специализированных ГИС-инструментов.
Вместо того, чтобы разбираться в геопорталах и программировать запросы, с этим фреймворком вы можете просто сказать системе: «Покажи станции метро в этом районе. Добавь на карту школы, исключая частные. Отметь все улицы, проходящие вдоль водоёмов».
Проще говоря, OGD4All выступает интеллектуальным посредником. Он обрабатывает ваш вопрос с помощью LLM, автоматически находит нужные наборы открытых данных, обращается к ним через API и возвращает готовый ответ. Причём, ответ может быть не только текстовым, но и в виде карты, или диаграммы.
Такой подход упрощает работу с массивами открытых геоданных. OGD4All делает их доступными для людей разных профессий — исследователей, журналистов, предпринимателей… Все они могут легче находить подходящие места для разных целей, проверять гипотезы и находить неочевидные взаимосвязи.
OGD4All — это наглядный пример современного тренда, в котором ИИ становится агентом, способным выполнять многоэтапные задачи. Он комбинирует большие языковые модели (LLM) и RAG, объединяя их через агентную архитектуру.
Пока Elon Musk ещё не продает массово своих роботов Optimus 3, появилась замена. Теперь любой ИИ-агент может арендовать человека для выполнения задач в реальном мире 😄
Как я вижу, спрос со стороны людей пока превышает количество задач со стороны ИИ.
Но реально теперь можно собирать ИИ-агентов, у которых будут задачи в реальном мире, я точно попробую прикрутить мясной слой (как его назвали сами создатели сайта) к своим экспериментам с роями агентов на Blackboard.
Бывают такие задачи, например, позвонить куда-то и узнать что-то, или даже ответить на вопрос по данным, когда LLM не смог справиться.
GlowByte проведет вебинар “Как повысить точность планирования в 2026 году”
Спрос меняется молниеносно, а планы устаревают, пока их согласовывают. Знакомо?
17 февраля эксперты GlowByte проведут практический вебинар о том, как бизнесу не просто своевременно реагировать на изменения рыночных условий, а предвидеть их и использовать для оптимизации расходов с помощью IBP-платформы.
Для кого вебинар?
Вебинар будет полезен руководителям коммерческого блока, логистики и производства при участии финблока и тем, кто ищет возможность:
повысить точность планирования без роста штата,
уйти от Excel-моделей,
получить единый, согласованный план по всей цепочке.
На вебинаре разберем:
Demand Planning — как улучшить прогноз спроса.
Replenishment Management — как продуктивно управлять запасами.
Transportation Load Building — как эффективно формировать заказы.
Ключевые KPI 2026-2030: точность прогноза, ускорение планирования и своевременная реакция на изменяющийся спрос.
Что сегодня мешает компаниям достичь прозрачности и управляемости — и где именно IBP закрывает этот разрыв.
Чем этот вебинар отличается от других?
Это НЕ скучная продуктовая демонстрация, а взгляд с позиции бизнеса и экономики: как сократить запасы, высвободить капитал и синхронизировать все отделы в одной модели.
На прошлой работе в команде был разраб, который прямо-таки ненавидел вести Jira и не видел в этом никакого смысла. Приходилось регулярно с ним это обсуждать и договариваться, что занимало кучу времени и сил.
Как будто отсутствовала вот эта культура внутри, что, кстати, не редкость, к сожалению. Ведь польза канбанов очевидна для команд: виден пул задач, отслеживается прогресс, лид в любое время может зайти и посмотреть, как идут дела, нет ли проблем, чтобы "подскочить".
Когда же нет выстроенной системы в бизнесе, всё выглядит как тёмный лес. Бизнес как будто идёт, вообще не зная куда. Кто сидит и ... пинает, а кто реально работает и даёт значимый импакт. Исчезает вопрос: "Над чем ты работаешь сейчас?" В общем, уверен, описывать это смысла нет — практически каждый с этим сталкивается.
И я вот попробовал упростить взаимодействие с Jira. Настроил Atlassian MCP, прописал инструкции для субагента в Курсоре, который выполняет задачи Jira-администратора для меня. Также сделал команду, при вызове которой автоматически ищутся в указанном репозитории релевантные коммиты, строится наполнение задачи, выставляется потраченное время (вычисляется наивно по коммитам), а также прикручиваются ссылки на затронутые ветки и репозитории.
И результат мне прямо-таки понравился! Вот, к примеру, я настраивал для нашего проекта CI, чтобы он проверял успешность сборки при изменениях в коде. И попросил агента пойти в Jira. В итоге он:
Посмотрел, нет ли существующих задач, которые можно было бы связать.
Создал задачу и завёл её на меня.
Прошёлся по всем релевантным коммитам и составил описание изменений.
Посчитал количество затраченного времени.
Заполнил всю эту красоту в задачу.
И перетащил её в Done.
Так, по мере выполнения одной задачи, могут приходить в голову какие-то идеи. И параллельно, не открывая Jira, можно заводить бэклог, даже запускать его в автономном режиме, пробовать делать какие-то наброски по задаче и так далее.
