Опустим мечты учёных и фантастов 1950-ых годов о создании кибернетического сверхмозга и перейдём к практике: начиная с 1960-ых, ключевым направлением применения Искусственного Интеллекта стала автоматизация процессов управления и принятия решений. Грубо говоря, программисты думали как заменить менеджеров. В итоге получилось наоборот: менеджеры думают как заменить программистов.
Честный рассказ команды Modus , которая только что завела Storybook поверх большой легаси-базы: зачем стартуем, чего ждём и как через полгода проверим, окупился ли он.
Представьте, что разработчику нужно поправить одну кнопку — отступ или состояние наведения. Работы на минуту, но для этого нужно поднять всё приложение, залогиниться и прокликать половину интерфейса до нужного экрана. И так — каждый раз. К третьему заходу проще остановиться на «вроде норм», чем повторять этот цикл ради мелочи.
Нам это надоело и мы решили попробовать Storybook. А заодно — поставить над собой небольшой эксперимент.
Если вы сейчас решаете, тащить ли Storybook в уже живой проект, и хотите увидеть честный старт, а не сухой результат — этот материал для вас.
В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году.
Эта статья — о том, почему так происходит почти всегда, когда компания оптимизирует одну метрику, как мы это починили и — главное — как продать решение руководству. Именно на продаже всё обычно и умирает.
Привет, меня зовут Дарья, я ИТ-бизнес-партнёр в банке. Часто при внедрении ИИ возникает вопрос: а нужно ли сначала стандартизировать процессы? Какой эффект это даст?
В моей статье ниже мы подробно разберем, почему при отсутствии единых правил агент вынужден восстанавливать контекст, а не контролировать результат. На примере агента, анализирующего квартальную отчётность, мы убедимся: хаотичная декомпозиция создаёт до 262 144 вариантов структуры, тогда как стандарт сводит проверку к типовому шаблону и в модельном расчёте сокращает объём входных токенов примерно на 73%.
Как руководителю понять, чем занята ИТ-команда: сколько ресурсов уходит на поддержку, какие работы относятся к проектной нагрузке, где задачи остаются без оценки, а где назначены исполнители, но работа не движется?
В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam, поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды.
В статье разбираем архитектуру решения, логику разделения поддержки и проектных работ, состав аналитики и результаты одного из ежемесячных отчётных срезов.
«Всем привет! У нас изменения в регламенте!»
Если ваше утро начинается с такого сообщения на планерке или в чате — вряд ли его можно назвать добрым. Потому что первая реакция — «не надо!»
Сопротивление изменениям — естественная реакция системы на попытку перестройки.
Ниже несколько приемов для тех, кто внедряет изменения и несколько шагов для тех, кто эти изменения переживает.
Ко мне обратилась исследовательница — социолог, изучающий, как на самом деле устроена жизнь коллективов: репутация, доверие, признание внутри команд. Работа устроена так: клиентка каждый день отсматривает и конспектирует по десятку новых научных статей и соотносит их с собственными эмпирическими данными. Ей нужна была система, которая свяжет весь этот разнородный материал воедино и позволит с ним работать, а не просто складывать.
Привет! Я Владимир Крылов, продуктовый дизайнер и тимлид. В этой статье я поделюсь опытом проведения ретроспектив по методологии Squad Health Check, придуманной в Spotify. Расскажу, почему нам не подошел стандартный формат ретроспектив, в чём суть метода, какие темы для анализа проблем мы выбрали и к каким результатам в итоге пришли.
Привет, Хабр! Меня зовут Кира, я бизнес‑аналитик клиентского сервиса ITSM 365 и куратор командной базы знаний.
Наш продукт развивается с каждым годом, и вместе с ним растет количество клиентских обращений: их становится больше, а сами вопросы — сложнее. Если в 2015 году один бизнес-аналитик разбирал около 300 кейсов в год, то сегодня — около тысячи. При этом средняя оценка работы с обращениями остается на уровне 4,9+.
Очевидно, что чем больше людей подключается к работе, тем сложнее сохранять единый уровень экспертизы, быстрее вводить новичков в работу и не терять знания, накопленные командой. Поэтому нам нужно было сделать так, чтобы с увеличением команды росла не нагрузка на опытных специалистов, а объем знаний, доступных каждому сотруднику.
В этой статье расскажу, какие принципы и инструменты помогают нам переиспользовать знания, делать клиентов более самостоятельными и справляться с растущим количеством обращений без потери качества.
Обрисуем: вы сильный лидер, в вашем подчинении 20, 50, 100+ человек. Вы запускаете продукты, которыми реально пользуются. Вытаскиваете проекты из такого болота, от которого у других случится тик всего тела. Вы объективно сильный кандидат, дорогой и мощный управленец. Но рынок труда слеп и карьерных предложений нет.
На вопрос: «А кто и что должен предложить?», отвечу «да, много чего!».
Более удобное кресло руководителя и масштабней проект, менторство, запись подкаста или выступление на конференции, запрос на консалтинг или трекинг, партнёрство и так далее!
Но в вашем LinkedIn* тишина (и мертвые с косами стоят), интересных вакансий - полторы штуки, нетворкинг не ладится. Тем временем коллеги с меньшим опытом получают карьерные предложения одно за одним. И вы думаете: «А что не так?»
Не так - видимость. Точнее, её отсутствие.
Почти все сегодня знают про LLM и могут сравнивать модели, спорить о качестве ризонинга, важности контекста и стоимости токенов.
Но в среднестатистической компании обычно все ограничивается генерацией текстов, простым чат-ботом и редкой автоматизацией поддержки разработчиков, так как команды не знают, как подойти к выбору моделей и интеграции без лишних затрат.
Между тем инструменты для этого уже есть, например Evolution Foundation Models. И благодаря широкому пулу моделей помогают сделать продвинутый ИИ доступным для всех, а не только для сценариев разработки.
Эта статья для тех, кто на практике столкнулся с дефицитом рабочих ИИ-решений для неайтишных сценариев: для аналитиков, продактов, тимлидов и технических лидеров, которым нужно грамотно внедрить LLM в рабочие процессы от маркетинга до бэк-офиса.
Руководитель готовит расчеты, приводит факты, отвечает на возражения. Участники совещания соглашаются, но через несколько дней оказывается, что ничего не изменилось: команда работает по-старому, заказчик возвращается к прежней позиции, а решение остается в презентации.
Обычно в такой ситуации добавляют новые аргументы. Однако проблема часто не в их количестве. Человек может понимать логику предложения, но не считать его важным, безопасным или применимым к своей работе....
Недавно мне понадобилась старая заметка. Я точно помнил, что записывал её: там былы креды от сервиса (да, знаю надо хранить все в пароехарилках, но я записал как записал).
Не помнил я только, где именно это записал(
В Notepad++? В Obsidian? В сообщении самому себе? В папке проекта? Минут двадцать я перебирал места, и к концу уже не столько искал заметку, сколько пытался воскресить в памяти тот день что бы понять ход собственных мыслей
Нашлась она в OneNote. В том самом OneNote, про который я уже и забы, что он у меня вообще есть и более того хранить что то ценное.
Вот тогда до меня и дошла обидная вещь: за десять с лишним лет я неплохо научился записывать информацию и довольно плохо получать её обратно. Мест для записи у меня было столько, что одно из них выпало из моей собственной памяти.
Привет, Хабр! Меня зовут Зайцев Александр, я — руководитель продукта в ПИК. Сегодня расскажу, для чего мы в Family Manager реализовали функционал «Синхронизация параметров».
В процессе развития продукта Family Manager команда разработки неоднократно сталкивалась с одной и той же болевой точкой пользователей: библиотека семейств живет своей жизнью, а требования к элементам модели меняются быстрее, чем успевают выходить новые версии компонентов. Заказчик уточняет технические характеристики, экспертиза запрашивает дополнительные атрибуты, нормативная база обновляется — и все это требует немедленного отражения в проекте. Традиционный путь — правка файлов семейств, создание новых версий и внесение обновлений — оказывается слишком медленным, особенно когда проект уже на финишной прямой.
Именно для таких ситуаций в Family Manager реализовали функционал «Синхронизация параметров». Его главная задача — дать возможность быстро реагировать на изменение требований, не дожидаясь полноценного обновления библиотеки, и при этом свести к минимуму трудозатраты как BIM-координаторов, так и проектировщиков.
НИОКР — это тот тип проектов, где в начале пути не всегда есть готовый ответ на вопрос: «Как именно получить нужный результат?».
Сначала нужно проверить техническую возможность, исследовать варианты решения и подтвердить выбранный подход. Проблема в том, что бизнес обычно ждет понятный результат: изделие, технологию, прототип, экономический эффект, патент, новую линейку продукции. А научная или инженерная команда работает в зоне неопределенности: проверяет теории, меняет подходы, уточняет требования, сталкивается с техническими ограничениями. Отсюда рождается вечный конфликт: одни хотят управляемости, сроков и бюджета, другие — времени на исследование и право на отрицательный результат.
Хорошая новость в том, что НИОКР можно управлять. Плохая — если управлять ими, как обычным проектом «сделали план — раздали задачи — закрыли этапы», можно быстро получить красивую диаграмму Ганта, которая не имеет отношения к реальности.
Разберемся, что такое НИОКР, какие этапы проходят такие проекты, какие роли в них участвуют, какие стандарты применяются и для чего здесь нужны информационные системы управления проектами.
Полтора года назад мы работали как большинство команд разработки: заказчик приходил с задачей, мы её оценивали, согласовывали ТЗ и делали. Стандартный цикл.
Сейчас мы работаем иначе. Сами инициируем диагностику, сами ищем где автоматизация принесёт наибольший эффект, сами считаем ROI — до того как написана первая строка кода. Только потом договариваемся о разработке.
В этой статье — конкретная методология: как мы выбираем что автоматизировать, как считаем эффект в штатных единицах, как структурируем взаимодействие с промышленным заказчиком. С числами из реального проекта.
Хочу рассказать вам историю об одной хронической проблеме у каждого хостинга.
Заходит к вам пользователь, создаёт сервер. И дальше 10 секунд его держит, потом отпускает и создаёт новый сервер. И так тысячи раз. Делается это ради одной-единственной цели: при пересоздании сервера выдаётся новый IPv4-адрес.
Задача этих людей — найти в нашем пуле тот самый адрес, который их устраивает. Красивость адреса определяется по тому, где, кем и как он блокируется. Например, с какого-то в 1998 году рассылали спам, и письма с него доходят чуть хуже. С какого-то парсили Нетфликс или Пикабу, и они в чёрных списках этих ресурсов (им показывают бесконечную капчу). Кто-то болезненно засветился в Cloudflare, кто-то заблокирован в конкретном островном государстве за отзыв на местную кафешку и так далее.
Интернет настолько старый и настолько фрагментированный, что почти не осталось IPv4-адресов без истории. А учитывая, что у них ещё есть и прошлая известная геопринадлежность, международные санкции и блокировки могут быть очень запутанными.
Мы, разумеется, очищаем все свои IPv4 при закупке (а покупаем мы оптом, сразу подсетями), но мы уведомляем только основные базы вроде Спамхауса. А известных баз сотни и тысячи, и ещё есть блокировки конкретных сайтов, госструктур и плавающие показатели репутации айпишника и т. п.
Так вот, есть люди, которые перебирают адреса. Казалось бы, проблемы нет: при посекундной тарификации сколько потребил, столько и заплатил. Но они блокируют эти адреса для нормальных клиентов хостинга и потом их ещё и портят.
Бороться с этим было сложно, и 3 года мы это откладывали как могли.
Эта статья не содержит туториалы по вайбкодингу и не разбирает технически неуспешные кейсы внедрений.
Основная задача — помочь тем, кто принимает решения для таких инициатив, не прогореть на идеях быстро внедрить AI для оптимизации рутины.
Почему желание сделать быстро и дёшево может обойтись в миллионные убытки? Показываю на самой простой аналогии с IKEA, а также предлагаю 3 скрининговых вопроса для проверки кандидатов. В конце честно поговорим о том, что делать, если дорогой AI-внедренец не по карману.
Статья не про надежду. Она про то, чтобы не дать себе не увидеть реальные риски, когда кажется, что другие уже на шаг впереди. Если вы технический специалист, который испытывает сложности в том, чтобы объяснить руководителю, почему лучше два раза подумать, прежде чем что-то внедрять, — поделитесь с ним этой ссылкой.
Снаружи всё выглядит рабочим: история оценена, спринт собран, релиз уже стоит в календаре. Но одно число в Jira часто скрывает объём работы, который никто не обсудил, поэтому к концу итерации тестирование внезапно становится узким местом. Разбор семи типовых ошибок поможет понять, где возникает этот разрыв и что менять в процессе, чтобы прогноз меньше зависел от интуиции.
Мультимодельная оркестрация – модная: вместо одной модели дёргаешь несколько разом, а отдельная модель-судья сводит их ответы в один. OpenRouter продаёт это под именем Fusion, Sakana AI – под именем Fugu, и обещание у обоих одно: связка обходит любую одиночную модель. Я решил проверить на реальных рабочих задачах – и первое место действительно занял оркестратор, обойдя и Claude, и GPT, и Gemini поодиночке.
Звучит как слайд из презентации вендора – примерно это и написала про свой Fusion команда OpenRouter. Но у меня остались логи всех 541 API-вызова: токены, деньги, время. И они портят красивую картинку. Например, 68% всех денег внутри Fusion уходит на один-единственный Claude Opus – выходит, за качество я доплачиваю больше чем вдвое, по сути, за обёртку вокруг модели, которую мог вызвать напрямую.
Дальше – по логам: как Fusion устроен изнутри, какие модели он дёргает на самом деле, где оркестрация реально бьёт одиночную модель, где сливает ей, и окупается ли она своих денег и полутора минут на ответ.
