Управление проектами *

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

На INFOSTART A&PM EVENT 2026 секция будет посвящена работе с требованиями, данными и знаниями, описанию сложных систем, взаимодействию со стейкхолдерами и повышению качества анализа.

На экране идет диалог: 

— Она мне уже неделю не отвечает

— Это редфлаг. Не пиши ей больше

— Но я не хочу ее потерять!

А на фоне кто-то играет в Minecraft, GTA или другую игру. 

Не спрашивайте, в чем тут юмор. Просто так уж повелось.

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

Ещё мы шьём скины из Фортнайта, например, очень гордимся вот этим бананом (коллекция мерча Epic Games ехала по всему миру — от Японии до Мексики и Бразилии).

А так нашу работу (мы называемся Uniko), скорее всего, вы видели на сотрудниках Яндекса, VK, Касперского, КРОК, ОККО, Aviasales и в Сколково.

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

Собственно, самый лютый вин, который у нас случался, — когда команда Assassin's Creed Valhalla заказывала себе внутренний мерч, у них был вариант взять одежду от Reebok, с которыми у студии была официальная коллаборация и релиз в магазинах. Но команда выбрала наши худи, потому что качество ткани, швов и посадки оказалось по факту лучше.

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

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

Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. Недавно я разбирал подход, применяемый нами в крупных внедрениях 1С. От подготовки и предпроекта до эксплуатации: какие инструменты используем, как фиксируем договоренности и за счет чего удерживаем проект в управляемом состоянии.

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

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

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

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

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

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

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

Так в Гринатоме (ИТ-интеграторе Росатома) мы начали разработку Атом.Око. Это система, которая не просто видит текст на скане, а понимает структуру документа. Вытаскивает реквизиты, проверяет наличие подписей и печатей.

На фото: один из пользовательских снимков

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

К счастью, у нас есть резервный спутник! Из материнского контейнера он вышел чуть позже и выше. Думаю, у него ещё неделя. Так-то мы рассчитывали на несколько месяцев.

И это далеко не всё, что случилось в этой истории.

Вообще, тут две истории, которые сплелись в небольшой ад. Первая — это ожидание и реальность от софта и связи с наземным гридом. Нам пришлось переписывать стек протоколов, потому что в сыром SSH могла дойти половина команды. Например, мы отправляем rm -rf /home/pi/tmp/cache, а приходит rm -rf /home/pi. Это было бы очень забавно.

Очень много приколов с оптимизацией: например, чтобы сделать фотографию не чёрного экрана, надо как-то попасть в Землю. Спутник неуправляемо вращается, двигателя у него нет — поэтому надо дождаться, пока в кадр попадёт планета, и снимать. Так вот, код там прямо из 90-х — камера делает серию из 5 снимков с паузами, а затем основным считается тот JPG, который больше весит. Это значит, что в нём больше значимых пикселей, и это, вероятно, планета.

А, да, и потом американский NORAD перестал давать нам данные о положении спутника, и пришлось стучать в МГУ за матмоделью орбитальных расчётов, которые корректировались по тому, где мы последний раз видели спутник и куда он ушёл.

Итак, наш первый спутник год назад вышел на орбиту и вещал оттуда веб-страницу по радиоканалу. Этот новый спутник, уже с мини-сервером на борту и с доступом по SSH, должен был стать первым полноценным VDS в космосе.

Естественно, всё, что могло пойти не так, пошло не так!

История Леопольда Ашенбреннера ещё недавно выглядела как почти идеальная иллюстрация того, как можно заработать на революции искусственного интеллекта.

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

Привет, Хабр! Меня зовут Дима, я бизнес‑аналитик в команде внедрения Naumen. Большая часть моей работы — это коммуникация: с клиентами, разработчиками и коллегами внутри команды. Почти вся она происходит онлайн.

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

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

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

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

Обычный сценарий здесь — взять бриф и пойти делать. Я потратил три недели на интервью с руководителями направлений и разбор их рабочих файлов, прежде чем что-то строить. Выяснилось, что дашборд по маркетингу отвечал бы на вопрос про малую часть выручки, а основной денежный процесс компании — роспись, распределение сеансов по кинотеатрам, — не имеет ни одной управленческой метрики. Ни плана, ни факта относительно плана, ни замера качества. При этом через него проходит более 200 фильмов в год по более чем 150 кинотеатрам и примерно 500 залам.

Дальше — как устроен ИТ-ландшафт компании, которая делает десятки миллионов долларов кассы на Excel-файле со 150 вкладками, где именно там теряются деньги, и как я оценил размер потерь, когда сравнивать не с чем. Спойлер по методу: никакой магии, оценка построена на публичных бенчмарках производительности и честно помечена как нижняя граница.

В предыдущей статье мы разобрали четвёртое базовое понятие BABOK — Решение (Solution). Мы выяснили, что оптимальное решение — не то, которое технически совершенно, а то, что наилучшим образом закрывает сформулированную потребность в данном контексте с учётом реальных ограничений. Ключевое словосочетание здесь — «в данном контексте». Но что именно скрывается за этим словом?

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

Разберём пятое базовое понятие BABOK — Контекст (Context).

Десять лет в таможне, второй пилот детсадовского возраста, привычная стабильность и… 25 отказов от IT-компаний в один день. Кажется, это идеальный рецепт для того, чтобы смириться и опустить руки. Но сегодня я — бизнес- и системный аналитик, кайфующий от задач, «которые никто даже трехметровой палкой трогать бы не захотел». Это моя честная история о том, как перебороть карьерную инерцию, превратить опыт госслужбы в хард-скиллы и найти ту самую команду, где тимлид перед дейликом «обнял, приподнял и покружил».

Мы создали и выпустили первую версию, MVP - альфа-релиз Платформы GameDevAdvisor! Инструмент полного цикла сопровождения игрового проекта. От витрины, где можно заявить о своем проекте, понять его риски, рассчитать фин. модель и найти эксперта в команду, до запроса юридического сопровождения, оформления права собственности на IP. *В настоящее время Платформа работает в тестовом режиме.

Данная статья является продолжением ранее опубликованной статьи об управлении рисками в индустрии GameDev. В этой части я расскажу о дальнейшем развитии проекта GameDevRiskAdvisor, в частности о причинах создания, запуске MVP и развитии Платформы GameDevAdvisor.

14–15 августа в Санкт-Петербурге прошел INFOSTART CIO CAMP 2026 - закрытая двухдневная встреча ИТ-директоров, руководителей ИТ-подразделений и центров компетенций 1С. В этом году мероприятие собрало более 70 участников. Первый день посвятили деловой программе, второй - командной регате в Финском заливе.

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

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

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

В таких ситуациях важнее не знание конкретного шаблона, а способность разобраться в контексте, увидеть ограничения и выбрать подход. Этому посвящена секция «Прикладные компетенции аналитика» на INFOSTART A&PM EVENT 2026.

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

Поэтому эта история будет не только про очередной ИИ-инструмент, но и про команду из 16 человек, которая за несколько месяцев изменила привычный способ работы и перестроилась в пять микроюнитов.

Привет, Хабр! Меня зовут Сергей Чистяков, в ИТ я с 2006 года. Веду канал в телеграм. Сейчас работаю техлидом в Райффайзен Банке и строю систему автоматизации бизнес-процессов, в которой вместе работают люди и агенты. Расскажу про воркшоп, на котором никто не научился писать автотесты, двухдневный дофаминовый шок и пять маленьких команд, которые начали проводить задачи через весь цикл разработки и построили для этого собственный workflow поверх нескольких репозиториев.

На Хабре немало статей о том, почему Agile не работает. И в большинстве из них авторы справедливо отмечают, что ритуалы превратились в формальности, Scrum выродился в бюрократию, команды имитируют активность. Всё так.

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

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

Эта статья — не про то, что Agile плох. Она про то, как сделать его работающим.

Корпоративную НСИ не всегда можно «сначала почистить», потому что иногда единого корпоративного объекта данных ещё нет. Разные системы могут содержать разные, но обоснованные части одного объекта. Тогда задача проекта – не выбрать самую удобную базу, а определить, где возникает каждый значимый факт, кто отвечает за его смысл, какой источник считается авторитетным и кто завершает спор. Эту неопределённость удобно разбирать через карту источников и ответственности за данные.

Что общего у лучших инвесторов, предпринимателей, игроков в покер и других профессионалов, работающих с неопределённостью?

Какие принципы помогают принимать сильные решения там, где ничего нельзя знать наверняка?

2 августа 2026 года должен был наступить один из ключевых дедлайнов EU AI Act.
27 июля вступил в силу AI Omnibus и часть high-risk требований получила новые даты.

В лучших традициях менеджмента: release date давно стоит в календаре, а непосредственно перед ней выходит обновление roadmap.

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

Теперь правила для high-risk use cases из Annex III применяются с 2 декабря 2027 года, а для AI, являющегося продуктом или компонентом безопасности регулируемого продукта по Annex I, с 2 августа 2028 года. Однако мы должны учитывать важный нюанс: AI Act не перенесли целиком.