В школе я часто слышала фразу: «Ну, вам нужно выбрать: шашечки или едем?». А еще: «Определись: ты к умным или к красивым?».
Когда выросла, оказалось, что профессиональный мир тоже как-будто стремится разделиться на два лагеря: тех, кто про мозг и технологии, и тех, кто про красоту и коммуникации.
«Оборот» – карточный рогалик про то, как маленькая команда с агентами доживает до первого большого запуска. Его собрали агенты за четыре дня: 28 выпусков с 13 по 16 октября. Человек в это время ставил задачи и играл руками. На полноценный плейтест каждой версии людей бы не хватило, поэтому баланс держал бот: перед каждой правкой он отыгрывал сотни сезонов.
Ниже – как это было устроено: какое число считали целью, где бот проигрывал и какие правила поменялись по его логам.
Вы внедрили ИИ-агента в свою работу. Он показывает информацию по счетам, формирует сводки, разбирает входящие сообщения и делает ещё много полезного. Но на каком уровне автоматизации вы находитесь? И что делать дальше?
В этой статье разберём, что такое ИИтизация, как внедрить ИИ-агента в рабочий процесс и почему следующий шаг - не обязательно более умный агент, а движение в сторону AI-Native-подхода к управлению процессами. В своей практике я выделяю 5 уровней ИИтизации (красивая формулировка для обозначения автоматизаций с помощью ИИ), все примеры рассмотрим на одном простом процессе - обработке входящих заявок.
При длительной работе с AI над одним проектом постепенно накапливаются решения, требования и договорённости. Со временем модель может перестать учитывать часть этой информации, опираться на устаревшие решения или противоречить ранее согласованным требованиям.
Разберём, как организовать проектный контекст с помощью ChatGPT Projects, инструкций, документов и памяти, а главное - как поддерживать его в актуальном состоянии.
Сейчас модно говорить, как стало классно делать приложения / проекты / продукты с ИИ-агентами. Сел, накинул 1–2 промпта — и у тебя уже за вечер запущенное приложение. Но если погрузиться в процесс создания какого-либо продукта, то разработка — это всего лишь небольшая его часть.
Когда я буду большим, я ограничу себе созвоны до часа в день.
Расшифровки созвонов уже давно стали обыденностью для гиков, организаций из IT и диджитала. Так и на наших созвонах с волонтерами и партнерами SPB Founders уже регулярно появляется дополнительный участник – бот-notetaker. После онлайн-встречи остаются расшифровка, краткое содержание и задачи, поэтому привычка вести параллельно заметки у меня постепенно отпала (примерно с 2023 года, если честно – отсутствие записи считаю теперь признаком просто дружеской онлайн-вечеринки или страшно секретных переговоров). С одним из авторов сервисов транскрибации до бума ИИшных сервисов мы даже долгое время делали митапы SPB Founders как с большим профи в звуке и видеотрансляциях, но после его переезда за пределы России и выхода кучи ИИ-альтернатив только изредка пользуемся его решением.
Как оказалось, выгрузку аудио или видео на расшифровку или формат «бот из приглашения в календаре сам заходит в Zoom и всё записывает даже без меня» уже далеко не единственный: встречу можно писать прямо с компьютера с захватом аудиоканала или вообще использовать ИИ--транскрибатора, встроенного в саму ВКС. Стало интересно посмотреть, насколько эти подходы сейчас отличаются, и в каких случаях каждый удобнее. Для сравнения взял только то, где появлялся сам и активировал расшифровку за осень 2026го: Zoom, mymeet.ai, Speech2Text.ru, МТС Линк, Контур.Толк и Яндекс Телемост. К счастью, делать саммари после встречи умеют уже все – поэтому этот критерий не вошел в таблицу.
Оговорка: в следующей части я попробую шире копнуть, сравнив уже только независимые решения-транскрибаторы, но пока смотрел только знакомые.
Об инфраструктурной археологии, реальных путях доступа и попытке перейти от исторически накопленных разрешений к управляемой модели. Практический опыт разработки инструмента для аудита прав доступа в AD, на серверах и сервисах. С чего начал, с чем столкнулся. И какие сделал для себя выводы.
В какой бы автоматизированный и удобный сервис вы ни зашли, вам все равно придется настраивать много конфигураций руками. А для этого нужно понимать, что как устроено и какие функции (и в каком объеме) могут закрыть ваши задачи. Разве что внедрить в сервис толкового ИИ-ассистента, который все объяснит, да еще и в режиме агента сделает работу за вас.
Я давно мечтал, чтобы в MWS Tables появилось нечто подобное. Хочется, чтобы ИИ-машина оперировала существующими данными, создавала таблицы и связи между ними, писала формулы, собирала представления и отвечала на вопросы по содержимому пространства.
Так вот, в обычный рабочий день я зашел в MWS Tables и внизу интерфейса обнаружил волшебную кнопку со звездочками. И это могло значить только одно: вы читаете новый обзор на свежую функцию.
Проверим же, насколько она полезна.
На сцене — руководитель проекта. В отчете, который он через несколько часов предоставит топам, все хорошо: задачи выполняются, бюджет под контролем, критических рисков нет. Только вот за кулисами скрывается одна большая проблема — ключевой разработчик ждет доступы от заказчика уже неделю. Из-за этого тестирование не началось, а команда продолжает планировать работы так, будто ничего не произошло.
Добро пожаловать на голодные игры в мир управления проектами, где между статусом в системе и реальным положением дел иногда простирается пропасть.
Привет, Хабр! Меня зовут Антон Ивахненко, я глава по технологиям группы Рунити. Последний год ко мне всё чаще приходят с одним и тем же вопросом, только в разных формулировках. «А действительно ли команде нужно столько людей?», «Давайте сделаем ее меньше, но будем успевать больше», «Как нам сделать команду эффективнее?». Обычно это звучит от нетехнического топ-менеджмента, и за этим стоит понятное давление: рынок с одной стороны, новые технологии с другой, и от ИТ ждут оптимизаций.
Проблема в том, что вопрос почти всегда задают неправильно. Размер команды — последний рычаг, а не первый. Перед тем как кого-то нанять или уволить, есть смысл разобраться, что вообще происходит с командой и задачами, которые в нее приходят.
Дальше — попытка систематизировать подход, который я держу в голове. Готовым фреймворком его не назову: скорее это модель, которую полезно примерить к своей ситуации и проверить, работает она у вас или нет.
Этот текст будет полезен, прежде всего CTO, руководителям разработки, техлидам и продактам, которые защищают размер команды перед бизнесом и часто слышат «сократить» или «нанять». Но здесь есть рамка для разговора: почему ценность, эффективность, объем задач и форма команды важнее, чем сам найм или увольнение. Речь о том, как разработка превращается в кост- или профит-центр.
А вы сразу начали использовать новую систему управления проектами?
Привет, Хабр! Знакома ли вам ситуация, когда внедренная ИСУП остается лежать на «полке» несмотря на все затраты: анализ процессов, закупку лицензий, настройку рабочих мест, миграцию данных и обучение сотрудников? Разберемся в статье, где искать проблему и возможно ли полностью отказаться от привычных инструментов в пользу единого ПО.
Если одну и ту же скучную операцию я делаю руками второй раз, где-то в мире грустит один AI-агент. А если третий — вероятно, уже и Python-скрипт.
За последнее время я поймал себя на том, что всё реже хочу самостоятельно разбирать Excel, конвертировать документы, писать одноразовые утилиты и разбираться с очередной ошибкой в терминале.
Не потому, что разучился. Просто теперь многие из этих задач можно делегировать AI-агенту, который не только подскажет решение, но и выполнит его.
Собрал пять повседневных сценариев, в которых AI-агенты действительно экономят мне время. Без фантазий про замену целых профессий — только практические примеры, ограничения и немного боли от ручной работы.
Есть старые системы, которые работают как часы. Они годами встроены в бизнес-процессы, обмениваются данными с другими приложениями, а пользователи знают их сценарии почти наизусть. Поэтому выключить такую систему потому, что просто хочется более современный стек, довольно сложно. Но рано или поздно технологию всё равно приходится менять. И тут возникает закономерный вопрос: как перенести систему, от которой зависит привычная работа пользователей, на новую технологическую платформу и при этом не потратить на миграцию годы и огромную команду?
В НЛМК ИТ мы решили проверить на реальном проекте не только новый инструмент, но и новый подход к организации разработки. Вместо привычной проектной группы мы дали задачу одному инженеру, который координировал команду ИИ-агентов.
На первом этапе эксперимента трудозатраты IT на разработку сократились в 10 раз. Но самое интересное произошло уже после миграции. Мы оставили ИИ-агента работать внутри новой системы — теперь он помогает пользователям.
Получилась история не только о том, как переписать legacy с помощью ИИ, а о том, что происходит с разработкой и поддержкой, когда у инженера появляется слаженная команда цифровых помощников.
Привет, Хабр! Меня зовут Александр, я тимлид в СВОЙ Тех. ИИ работает со мной каждый день: пишет код, помогает с ревью, разбирает документацию. Друзья и родные тоже пользуются им всё чаще. Но многие обращаются с нейросетями так, будто купили феррари, чтобы слушать в ней радио. Мотор мощный, а машина так и не выезжает из гаража: спросить, перевести, уточнить термин — и закрыть вкладку. Я и сам поначалу ездил ненамного дальше: просил написать регулярку или накидать типы для ответа API, а остальное делал руками.
Но когда хочется выйти за рамки разовых вопросов, возникает другая проблема: непонятно, с чего начать. Материалов полно: Telegram-каналы, посты в Threads, курсы с обещаниями «50 промптов, которые изменят не только вашу работу, но и жизнь». Встречается и другая крайность — университетские программы с линейной алгеброй и статистикой, хотя вам пока нужно научиться решать повседневные задачи. Хорошие прикладные курсы тоже есть, но как понять, какие из них стоят вашего времени?
Я отобрал шесть курсов — по два от каждой компании — и выстроил из них маршрут в три этапа: от базовых приёмов работы с ИИ к более сложным задачам. Курсы разных платформ дополняют друг друга и постепенно добавляют новые навыки. Проходить все шесть необязательно — можно сразу начать с этапа, который подходит под ваш опыт и задачи.
Речь пойдет об инструменте, который поможет выбрать вариант решения, даже если вы выбираете куда поехать в отпуск. Мой опыт сложился в крупных корпоративных проектах, где я проработала бизнес-аналитиком более 15 лет, поэтому все мои примеры именно от туда.
Что обычно прячется за кулисами задач по проектированию изменений в системах или процессах? Для развития темы это важно, хотя у кого-то такое напоминание может вызвать легкий нервный тик.
Стендапы проводятся, но никто не слушает. Ретроспективы есть, но ответы одни и те же. Метрики считаются, но ничего не значат. Почему Agile превращается в зомби, почему коучи и новые фреймворки не помогают – и как поставить системе точный диагноз. Взгляд на IT-процессы из авиационной литейки, где ошибка измеряется в браке.
Два года назад наш проектный офис в Professional Services был похож на пожарную команду: мы постоянно тушили пожары, сжигали людей (нет, не буквально) и не понимали, почему одни PM справляются, а другие выгорают за полгода. В какой-то момент я осознал простую вещь: мы нанимаем за практические навыки, а увольняем за неумение коммуницировать. PM может идеально знать Jira и строить диаграммы Ганта, но если он не может управлять ожиданиями заказчика или эскалировать проблемы правильно и вовремя — проект обречен.
Проблема в том, что софт-скилы сложно измерить. «Коммуникабельный» — это сколько в процентах? «Проактивный» — как это проверить на собеседовании? Пришлось строить систему, которая отвечает на эти и другие вопросы. Работа еще не окончена, но уже принесла измеряемый результат.
Эта игра получила две номинации IGF, выиграла призы Excellence in Design и Excellence in Audio, вышла на PS3 и PC и собрала хорошие отзывы критиков, а студия, которая её сделала, после успешного релиза фактически развалилась, а один из двух сооснователей выгорел и ушёл в найм. Ни провала, ни скандала, ни закрытого издателя, просто четыре года разработки человеческих жизней были потрачены. Что за игра, если не узнаете, напишу в конце.
Историю постмортема я знаю из первых рук. В начале десятых мой знакомый, сваливший в Штаты за длинным баксом, вдруг вернулся в родной Питер без этого самого длинного бакса, зато с Шеви Тахо и долгами, проработав аутсорсером в той студии от первого коммита почти до закрытия. Тахо ему потом пришлось продать, потому что расход небольшого заводика накладывает некоторые ограничения на бюджет, но история не об этом...
Идея игры возникла случайно, когда команда делала техническое демо для совсем другой игры и добавила туда отладочный режим, чтобы отматывать время назад и повторять участки геймплея, обычная сейчас вещь, без которой ловить баги в динамичной игре довольно больно. В итоге они решили превратить саму перемотку времени в кор механику игры.
Операционная рентабельность выше 50% и запуск в срок — это не удача и не «хороший заказчик», а следствие нескольких простых закономерностей. Индустрия внедрения 1 С:ERP выработала их через годы удачных и провальных проектов, хотя редко проговаривает вслух. Ниже — семь опор, на которых держится рентабельный проект, и то, что они дают на практике.
Я руковожу отделом разработки в видеосервисе. Расскажу про инцидент, который мы пытались разобрать как ошибку конкретного человека, а в итоге нашли дыру в процессе. История банальная ровно настолько, чтобы случиться у многих.
Что произошло
Задача: изменить стоимость тарифа подписки.
Тестировщик проверил основные сценарии: активация подписки, автопродление, отключение, обработка платежей. Все прошло, задача уехала в прод. Через несколько недель начали приходить жалобы. Выяснилось: у пользователей, у которых есть история платежей, но подписка на текущий момент не активна, при обращении к разделу подписки падает фатальная ошибка.
Сценарий звучит экзотично ровно до момента, когда понимаешь, сколько у сервиса таких пользователей. Любой, кто когда-то оформлял подписку и потом отписался, попадает в эту категорию.
