Приглашаю разобраться со смысловой “гидрографией” реки Амазонки. Притоком какой системы является законодатель мод облачного бизнеса AWS. И что это за исторические повороты реки в логотипах.

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

Вася уволился.

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

Пришлось срочно искать оборудование, пересматривать сроки и объяснять пользователям, почему обещанная услуга пока недоступна. Один из заказчиков вполне обоснованно спросил: «Вы же сказали, что все готово?»

Согласование-то прошло без замечаний, но проблема все равно обнаружилась, позже, при непосредственной подготовке оборудования к установке. 

Привет, хабр! Я Коля Паршуков из Tevian, решил поделиться интересным опытом по взаимодействию с роботом‑уборщиком вместе с технологиями компьютерного зрения. 

Представьте обычный продуктовый магазин. Несколько рядов стеллажей, тысячи товаров и примерно столько же ценников. Цены регулярно меняются, и после очередного обновления админ магазина должен убедиться, что на полке действительно висит та цена, которая сейчас находится в учётной системе. Но есть нюанс — проверять всё вручную долго, муторно и скучно.

Вокруг ИИ-агентов столько шума, что хочется поскорее отдать им всю рутину: пусть отвечают клиентам, ищут документы и разбираются с заказами.

Модель, промпт, удачный пример — и вот агент читает договор, находит спорные пункты и сам заводит заявку юристу. Зал аплодирует. А потом выясняется: на соседнем договоре он ошибается, заявка существует только в его ответе, а без автора проект никто не может даже запустить.

Агент пишет «заявка создана» с той же уверенностью, с какой пишет «добрый день», поэтому убедительная демонстрация ничего не говорит о том, работает ли решение.

Трудясь над проектом, пройдя через N‑е количество ретроспектив, которые, к слову, из раза в раз мало отличались друг от друга, наш SCRUM‑мастер придумал фишку — делегировать проведение ретро кому‑нибудь из участников команды. Следующий ведущий избирался случайным образом. И вот, когда очередь дошла до меня, я, обнявшись с Cursor, подготовил данж для команды. О самом данже и о том, что из этого получилось — постараюсь поведать в этой статье.

Привет, Хабр! Меня зовут Всеволод Гришин, я инженер данных направления BI в «ДАР» (ГК «КОРУС Консалтинг»). В этой статье хочу рассказать, как в проекте, который изначально планировался как запуск системы финансового планирования, общий бэклог стал не внутренним инструментом, а основным способом взаимодействия заказчика и команды исполнителя. Это первая часть материала: здесь разберу, почему заказчику это нужно и как преодолеть сопротивление идее.

Вы объясняете задачу двум людям одними и теми же словами. Один через час приносит черновик. Второй через день приходит с десятком вопросов, а через неделю выясняется, что понял задачу по-своему. Проще всего решить, что второй слабее. Но честнее признать, что вы говорили на языке первого.

Когда я начинала руководить командами, я считала, что справедливо — это со всеми одинаково: одинаково ставить задачи, хвалить и критиковать. На деле я со всеми говорила так, как удобно мне: быстро, коротко, без «как дела». Половине команды это подходило. Вторая половина команды не всегда делала то, что было нужно, и я долго не понимала почему.

Недавно Алексей Ахмеев, руководитель Управления информационной безопасности Своего Банка, выступил на Практическом интенсиве по информационной безопасности для CIO, где затронул тему, с которой рано или поздно может столкнуться любая компания: как действовать, когда ИБ-инцидент уже произошел, а руководство ждет ответов.

Алексей с удовольствием поделился материалом с Хабром. Мы собрали основные тезисы его выступления и разобрали десять вопросов, к которым CIO стоит быть готовым в первые часы после инцидента.

Всем привет, это команда SimpleOne. В этом году мы провели исследование ITSM, ESM и ИИ в российских компаниях: 56 анкет собрали на конференции ITSMF 2026, ещё 43 — опросом более широкого круга специалистов, где преобладают средний и крупный бизнес. Потом положили две группы рядом и посмотрели, где они расходятся сильнее всего.

На канбан-доске всё зелёное, задачи закрываются, команда отчитывается об успехах. А проект уже летит в пропасть — просто руководитель пока об этом не знает. Покажу, почему даже идеальный порядок в задачах не спасает от хаоса, как находить проблемы до срыва дедлайнов и что обнаружил ChatGPT, когда я дал ему покопаться в проектах через MCP.

Статья для менеджеров и продактов, которые хотят строить продукт с ИИ-агентом сами, не вставая в очередь к разработчикам и не читая код.

Агент пишет: “Готово, все тесты проходят”. Дальше у меня два пути: поверить или показать тому, кто разбирается. Показать некому. Разработчика в проекте нет, а сам я код не читаю.

Я продакт. Делаю расширение для Chrome. Весь код написали два ИИ-агента, Claude Code и Codex.

Дальше расскажу, как устроил проверки и работу с агентом:

«Внедрим ИИ, и через полгода половина команды не понадобится». Такую установку я встречаю у руководителей чаще, чем хотелось бы. Картинка у них простая: агент получает задачу одним промптом, пишет код, сам его тестирует и выкатывает, а людям остаётся нажать Merge.

На практике ИИ — не волшебная палочка, а ещё один инструмент, быстрый и мощный. Его нужно настроить под проект, дать ему контекст и проверять каждый результат. Без этого команда с каждым багом на проде переписывает куски системы, плодит новые баги, и так по кругу.

В прошлой статье «ИИ раздали — пользоваться не научили» я разбирал, почему ИИ не окупается, если раздать его командам и ничего больше не менять. В этой покажу, как работаю по спецификациям (SDD) с OpenSpec, какой контекст и какие скиллы нужны агенту и почему без людей с компетенциями всё это не взлетает. Пишу для разработчиков и лидов, которые настраивают процесс, и для руководителей, которые решают, как внедрять ИИ.

Клиент уверен, что нашёл пятьдесят человек под проект, а назавтра на проходной стоит четверо. Это не невезение и не плохой подрядчик - это обычная арифметика воронки найма линейного персонала, которую почти никто не считает заранее. Разберём, в чём разрыв между количеством откликов и количеством людей на объекте, и как посчитать резерв, чтобы выход не сорвался.

Почти пятнадцать лет проекты в КРОК вели в Clarity, и за это время компания ее переросла. Нужна была замена, и сложность заключалась в роли этой системы. Она стоит в середине цепочки, по которой данные о проектах уходят в таск-систему и корпоративную отчетность, так что менять ее пришлось прямо внутри работающего процесса.

Привет, Хабр! Я Марина Конова, ИТ-директор КРОК. Расскажу, как мы больше года вели проекты в двух системах параллельно и постепенно перевели их в Directum Projects. Встроили новую систему в ландшафт и перенесли активности: сначала действующие, а теперь и архив из 28 тысяч. Гладко прошло не все. В разгар миграции процесс пришлось остановить на месяц, чтобы разобраться с ошибками при переносе записей о трудозатратах. От коробочного модуля учета времени мы отказались в пользу своего решения, а саму систему заметно доработали под наши процессы. Каждую новую версию Directum Projects мы проверяем вместе со своими доработками, и переход на нее занимает до двух месяцев. 

Привет, Хабр! Я Алеся Бикбулатова, руковожу отделом обучения IT-холдинга ICL, а еще тренер и фасилитатор. В этой статье я хочу честно поговорить о выгорании лидеров: почему самые ответственные часто оказываются в зоне риска, как отличить обычную усталость от устойчивого истощения, где провести границу между эмпатией и самопожертвованием и что можно сделать уже на этой неделе.

Есть множество проектов, в которых нужно разработать какое-либо ПО с жёсткими ограничениями по бюджету. Хочу поделиться своим методом работы с такими проектами.

Это не серебряная пуля, но, думаю, мой опыт будет интересен. В основном такой подход я практикую для небольших проектов: срок разработки — до 14 месяцев, а общее количество участников команды — до 10 человек. Для более крупных проектов такой подход уже не подойдёт: сделать их бюджетно — совсем другая история.

Сразу уточню границы. Речь не о ситуации, когда денег нет совсем, а о проекте, на который есть примерно 60–70% от необходимой суммы. Этот диапазон основан на моём личном опыте нескольких проектов, а не на универсальной формуле: конкретный результат зависит от системы, команды и ограничений заказчика. Размер возможной экономии сильно зависит от квалификации техлида проекта. Также рассказ будет о создании чего-то нового, когда нельзя просто переиспользовать предыдущий опыт и готовые наработки. Не все описанные шаги нужны для каждого проекта, но пропускать их стоит осознанно, а не потому, что на них якобы нет денег.

Саймон Уордли руководил прибыльной компанией, но не понимал, куда она движется и на правильном ли вообще пути. Поиск ответа привёл его к картам.

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

Карта не скажет, какой путь выбрать, но поможет обсудить варианты и принять решение.

Саймон Уордли руководил прибыльной компанией, но не понимал, куда она движется и на правильном ли вообще пути. Поиск ответа привёл его к картам.

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

Карта не скажет, какой путь выбрать, но поможет обсудить варианты и принять решение.

Уход ключевого разработчика может обнажить проблему, которая годами оставалась незаметной: команда формально владеет модулями, но фактически не знает, как с ними работать. История Git позволяет оценить концентрацию авторства и заранее увидеть, какие файлы останутся без активного автора, если уйдёт лидер. В статье разбираем методику расчёта truck factor, шесть типичных управленческих ошибок и то, как AI‑агенты дополнительно усложняют оценку распределения знаний.

Привет! Меня зовут Константин Замков, я главный менеджер в компании «СИБИНТЕК». Я занимаюсь управлением проектами и портфелями проектов и являюсь сертифицированным профессионалом (PMI PMP, PMI PfMP, PSM‑I). За годы работы с корпоративными ИТ‑инициативами я заметил, что успех проекта во многом определяется еще до того, как разработчик пишет первую строчку кода.

На старте проекта часто отсутствует практически все, что впоследствии кажется очевидным. Нет детальных требований и плана работ, нет оценки стоимости и утвержденного бюджета. Есть только идея или общая проблема, которую необходимо решить с помощью ИТ.

В этой статье я хочу поделиться своим опытом применения последовательного подхода к подготовке и запуску корпоративного ИТ‑проекта от первого обращения бизнеса до получения финансирования и перехода непосредственно к реализации.

Привет, Хабр. Я Михаил Мирошников из департамента данных и рекомендательных систем B2C Сбера. Расскажу о переменах в подготовке банковских коммуникаций: об ИИ-генерации текстовых форматов, их почти моментальном согласовании при помощи LLM-проверок и о том, куда это всё ведёт контентные команды.

Команда стабильно выполняет задачи, руководство довольно результатами, а повышения всё нет. Более того, чем лучше вы справляетесь, тем больше работы получаете и тем меньше времени остаётся на то, что действительно влияет на карьерный рост. Почему надёжные руководители застревают на своих позициях и как перейти от бесконечной текучки к участию в стратегических решениях? Разбираемся на конкретных примерах.

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

ИИ действительно позволил мне делать то, о чём раньше я мог только мечтать. Но вместо свободного времени я получил проблему, к которой совершенно не был готов.

Кажется, технический прогресс немного вышел из-под контроля.

Питер Брейгель Старший. «Алхимик», около 1558 года. До появления ChatGPT оставалось примерно 464 года.

Неспокойный во всех отношениях 2026 год. Мы, как самые большие молодцы, стараемся вывезти на себе всё возрастающую сложность перемен. Как лидеры наших команд, мы должны показывать пример, воодушевлять других, и конечно, быть в основных трендах профессии.

Все пишут, как ИИ поменял жизнь разработчика. Наш коллега IC стал эффективнее, он стал быстрее доносить пользу до продакшена, он настраивает себе все эти скиллы и MCP. В тысячах статей и сотне тысяч комментариев под ними программисты ведут бесконечный холивар: надо использовать ИИ всегда или только по особому случаю, тупеет ли человек от частого употребления ИИ или нет, больше стало багов или меньше.

Но что с управлением процессом производства ИТ-содержащего продукта на уровне команд? Понимаем ли мы реально, на каком вулкане сидим?

Я долгое время кодил, а теперь управляю командами в ИТ уже 5-й год. Мне, как и многим другим, сначала казалось, что процесс перехода на AI-driven development будет медленный, и мы всем сообществом что-нибудь придумаем. Но сейчас, в конце 2026, я стою и смотрю на эту картину, как тот зевака на балконе бейрутского отеля, который уже увидел взрыв в порту, но ещё не ощутил приход воздушной волны.

Давайте поговорим об этом?

В 2022 году у нашей команды была конкретная задача: подготовить локальную замену глобальной CRM так, чтобы сотрудники могли продолжать привычную работу без сбоев. Система уже была частью повседневных процессов. В ней планировали визиты к специалистам здравоохранения, фиксировали результаты взаимодействий и работали с коммуникациями.

Главным стимулом для локализации стал риск отключения глобального решения. Но были и другие причины: желание получить больше гибкости в развитии системы, упростить ряд процессов и объединить несколько существующих локальных решений в единую платформу.

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

Спустя несколько лет стало понятно, что результат оказался значительно масштабнее первоначального замысла.

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

За годы работы с данными компании научились хранить и использовать их так, чтобы не выпускать наружу. По крайней мере, некоторые. Но ИИ подкинул новые вызовы. С одной стороны, без него уже никуда, с другой — если передавать внешней модели данные без защиты, это может обернуться катастрофой. Так что внедрять ИИ в бизнес нужно с умом. А как — расскажем на примере успешного кейса финансовой компании. Передаем слово спикеру.

Всем добрый день! Меня зовут Борис Кузнецов, я руководитель Управления стратегических проектов в компании Единый ЦУПИС. Мы уже больше года используем таск-трекер Shtab в закрытом контуре, а недавно внедрили Shtab AI, чтобы оптимизировать работу с задачами и информацией.

Хотим поделиться опытом использования инструмента: как пришли к его необходимости, как внедряли и что учли, чтобы чувствительные данные компании не выходили наружу.

Привет, я руководитель группы экспериментальных клиентов Kokoc Performance (входит в Kokoc Group). Наша команда составила полный пошаговый план GEO-продвижения: что делать на каждом этапе, какие данные собирать и как оценивать результат.

Гайд подойдет владельцам сайтов, маркетологам, SEO-специалистам и командам, которые хотят системно зайти в продвижение через нейросети, не делая работу наугад. 

Сейчас интересный этап в развитии GEO. С одной стороны, канал очень перспективный. Все эксперты рынка сходятся на том, что скоро искать товары или услуги все чаще будут через нейросети, а не через классический поиск. С другой стороны, канал развивающийся, и пока работают простые методы продвижения. 

Сейчас ситуация в GEO похожа на зарождение классического SEO. Лет 20 назад для ранжирования в поиске можно было наспамить ключами на страницах сайта, поставить ссылок на внешних источниках и получить профит в виде позиций и трафика. Потом алгоритмы усложнились, но те игроки, которые успели на этом этапе приобрести устойчивую репутацию бренда и стать лидером в своей тематике, пронесли этот результат через годы. Пословица «Куй железо, пока горячо» выглядит тут максимально уместно.

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

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

Почти более 200 катушек с компонентами уже пересчитаны. Сколько деталей - понятно. Что это за детали и для каких плат они нужны - знает только инженер, которому теперь предстоит неделя сортировки и учёта. Мы дали офис-менеджеру телефон с МиниМаксом, который читает фотографии катушек и каталог компонентов. Получился небольшой склад, который помогает распознать детали, разложить их по коробкам и собрать комплектацию для производства. Расскажу, как он устроен и почему инженеру теперь хватает полдня вместо недели

Летом я сам, без команды, сделал под это бота в Telegram. Код писал ИИ-агент, а задачи, решения и проверка были на мне. Первая рабочая версия заработала меньше чем через неделю, еще два с половиной месяца ушло на доработки под мои собственные поручения. Идея у бота одна: у поручения на девятерых девять отдельных отметок, каждый отчитывается сам за себя, вся группа видит, кто сдал, а тем, кто не сдал, бот пишет в личку.

В какой‑то момент осмысливая работу с клиентами и задачу удешевления разработки клиентского решения я пришёл к тому, что в нашей индустрии существует шкала видов клиентских решений, которая практически плавно простирается от коробочного решения до полной и бескомпромиссной заказной разработки.

Ты решил создать свою первую игру. Ура! Но с чего начать? С изучения матчасти, конечно же. А в ней говорится, что каждый уважающий себя геймдизайнер сначала должен написать дизайн-документ.

Работаете над одним проектом в ChatGPT, Claude и других AI-сервисах? Тогда наверняка сталкивались с необходимостью заново передавать требования, ограничения и ранее принятые решения.

В статье покажу, как организовать общий проектный контекст с помощью GitHub, чтобы разные AI-платформы могли работать с актуальной информацией. В основе подхода - открытый проект AI Context Kit. Разберём его структуру и практический пример передачи контекста между ChatGPT и Claude.

Обычно на крупных производствах за информационную безопасность отвечает огромный департамент. Мы — одна из самых маленьких команд в отрасли. При этом у нас хорошие показатели. По результатам внешнего аудита прошлого года мы получили больше 92% соответствия требованиям, и по отраслевым бенчмаркам держим высокий уровень зрелости ИБ.

Меня зовут Андрей Нуйкин, я руковожу отделом информационной безопасности ЕВРАЗа. Зона ответственности моей команды — это больше тысячи разработчиков, десятки тысяч пользователей, промышленная инфраструктура, а ещё множество ИТ-подрядчиков. И теперь ещё одна из актуальных болей — сотрудники, которые всё чаще пытаются навайбкодить себе сервисы с ИИ.

В этой статье расскажу, как мы выстроили работу так, чтобы наша небольшая команда могла эффективно защищать компанию такого масштаба. И почему для этого нам не пришлось вводить драконовские ограничения и запреты по принципу «как бы чего ни вышло». Надеюсь, ИБ-специалисты, которые сейчас отлаживают у себя процессы, смогут почерпнуть для себя наши практики. 

Ценовая власть (Pricing power) - популярный термин, часто используемый Уорреном Баффетом для описания идеального бизнеса. Посмотрим на примере Ferrari.

Всем привет! Я Дмитрий Шихаев, маркетолог для IT-компаний. Сейчас работаю с крупными IT-заказчиками, помогаю выводить технологические продукты на рынок и развиваю направление ABM-маркетинга в России.

Но путь к этому был далеко не сладким. Когда-то мы с товарищем Гошей, у которого за плечами были базовые знания BASIC и опыт работы с конструктором BAS, решили практически без денег и опыта создать собственный софт для массовой отправки качественных персонализированных деловых писем.

Сегодня разработчику стыдно вспоминать эту историю, поэтому его лицо скрыто в контенте, а имя изменено. Он вырос в сильного специалиста и мы работаем вместе до сих пор.

А тогда бюджет у нас был как у студента за неделю до стипендии, техническая команда состояла из двух калек - маркетолога без знаний IT-внутрянки и начинающего автоматизатора, зато амбиции были как у всего состава Кремниевой долины.

Повышение ценного сотрудника кажется простым способом удержать его в компании, особенно когда бюджет ограничен, а планы горят. Но если человек ещё не готов к новой роли, последствия могут затронуть всю организацию и обернуться накоплением управленческого долга. Разбираемся, почему такие кадровые решения обходятся компаниям дороже, чем кажется, и как преждевременное повышение влияет на работу команд.

Привет, Хабр! Меня зовут Александр Антипов, я продакт-оунер MWS Tables — платформы для совместной работы и автоматизации на базе таблиц. Раньше на платформе таблицы приходилось собирать вручную: добавлять столбцы, выбирать типы полей, устанавливать фильтры и т. п. Теперь у нас появился ИИ-помощник, создающий таблицы по простому текстовому описанию. А ещё мы научили его связывать таблицы между собой, писать формулы, настраивать отображение данных и делать многое другое. 

Сегодня я покажу, как применять новые возможности на практике.