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

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

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

Инструкцию по созданию я тут давать не буду — этого достаточно в интернете. 

Привет, меня зовут Надя, я продуктовый менеджер сервиса «Фейскит». Наша команда делает программу, которая помогает не терять шуруповерты, болгарки и пассатижи в суровой реальности стройки. Изначально мы задумывали продукт как простой и надежный способ учета инструментов и материалов. Но жизнь распорядилась иначе: за четыре года мы прошли путь от систематизации данных из Excel-таблиц до запроса на интеграцию с бухгалтерией. Рассказываю по порядку, как все было. 

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

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

Привет, Хабр! Меня зовут Даниил Оларь, я разработчик в команде продукта MWS Tables — платформы для лёгкой автоматизации и совместной работы на базе таблиц. 

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

Мы сделали несколько таблиц с необходимой для работы системы информацией: источниками новостей (каналами), промптами для их обработки и правилами для отправки новостей получателям. 

Затем самописный бот собирает новости по каналам и автоматически загружает их в таблицу на платформе, а LLM отсеивает нерелевантные новости и собирает дайджест самых интересных материалов. И ещё один бот отвечает за публикацию новостей в нашу группу.   

В материале расскажу, как устроена каждая таблица и как настроена связь между ними. 

Привет! Меня зовут Елена Сухова, я руковожу Центром роботизации бизнес-процессов в БКС. В отличие от многих подобных центров в финансовых организациях у нас очень маленький коллектив – всего 4 человека. Тем не менее, уже 5 лет мы успешно роботизируем процессы в компании и намерены заниматься этим и дальше. Сейчас у нас в эксплуатации больше 40 роботов, которые экономят около 30 тысяч человеко-часов в год, и ещё десяток в разных стадиях разработки.

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

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

Я Степан, delivery-менеджер Outlines Tech. Поделюсь кейсом, где новые метрики не сделали проект прозрачнее, какие ошибки к этому привели и чем всё закончилось для меня.

В первой статье мы рассмотрели подходы к определению ценности ИТ-решения и её монетизации. Мы разобрались, как оценить экономический эффект от внедрения решения – разовый или постоянный. Но вслед за вопросом «Что мы в результате получим?» возникает следующий: «А во что нам это обойдётся и стоит ли оно того?». И тут со стороны финансистов начинают звучать фразы вроде «Сделайте бизнес-кейс внедрения», «Посчитайте ROI или IRR», «Подготовьте ТЭО проекта».

Цель этой статьи – разобраться в этих понятиях, понять, как они связаны между собой, и показать, как использовать их при подготовке бизнес-кейса ИТ-проекта.

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

Давайте начнем с жесткого факта: ваша экспертность не стоит ровным счетом ничего, если о ней знаете только вы, ваша команда и пара коллег по цеху.

У технарей, директоров и производственников само словосочетание «личный бренд» часто вызывает нервное “фи”. Сразу представляется инфоцыганство, толкающее воздух по цене крыла самолёта, или блогеры с их особым вайбиком в сторис. «Я же делаю серьезный бизнес, какие еще бренды? Нормального спеца и так найдут… по его делам!», - думаете вы. И фатально сливаете рынок тем, кто оказался чуть громче.

Если вы не согласны, напишите почему

А пока разложим, как вся эта пиар-машина работает для взрослых дядь и тёть

1. Маркетинг и PR «на пальцах» (для тех, кто пишет код или считает бюджеты)

У нас в компании давно живёт странная двойственность. Я как руководитель смотрю на проект сроками, вехами и деньгами. Разработчик смотрит на него колонкой «в работе». Это два разных языка, и переводчиком обычно работает статус-митинг на сорок минут, после которого никто не стал умнее.

Мы пришли к схеме, где OpenProject остаётся инструментом верхнего уровня, а канбан-доска — рабочим местом команды. У нас в роли доски PLANKA: self-hosted, с OIDC через Authentik, живёт на нашем же контуре. Ниже —  как это устроено и, что важнее, где эта конструкция ломается. Я специально не буду обещать, что всё это собирается за вечер.

К началу июля я выгорел. Первую версию я дебажил несколько недель и в какой‑то момент понял, что в 47 раз запускать симулятор я не готов. Наклепал скриншотов, сложил в папочку, показал Клоду и сказал: «Шурши и не булькай». Сам собирать вайбовую лампу дачную лампу из того что нашел в гараже.

Вернулся через 2 часа. В браузере полностью заполненная форма App Store Connect и синенькая кнопка «Отправить на проверку». Нажал. Все сработало — первая версия приложения ушла на проверку в эпл.

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

Через неделю я загружал следующую версию и решил сравнить, сколько времени на это уходит у меня самого. Не вышло вообще. Apple сыпала ошибками и душила всем чем могла: скриншоты определенного размера и формата, какие‑то подпункты, поля, про которые я не знал. Я считаю, что терпение это моя сильная сторона и его хватило на +‑ на 24 минуты. Потом я позвал Клода, у него весь процесс занял 10 минут.

Вот после этого мне и захотелось рассказать историю целиком.

Статья больше подходит для руководителя подразделения в бюджете, но общий подход думаю подойдёт и для бизнеса. Упор делается на процесс внедрения.

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

В статье представлена архитектура базы слоями, выживших плагины, переезд синхронизации с Google Drive на CouchDB на своём VPS и грабли, с которыми я столкнулась.

В программе INFOSTART A&PM EVENT 2026 формируется секция «Прикладные компетенции аналитика». Заявок в этом направлении пока меньше, чем в других, поэтому у сильного практического кейса сейчас больше шансов пройти предварительный отбор и попасть в голосование. Первый тур голосования начнется 18 августа. Заявки принимаются до 28 августа...

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

Сами собой эти соединения никуда не уходят, нужен флюс. Не тот, который на десне!

Самый распространённый флюс на наших широтах — известь.

Химия простая и красивая: CaCO₃ (известняк) при обжиге превращается в CaO (негашёную известь) и CO₂ (углекислый газ). В установке десульфурации чугуна CaO связывает серу, превращая её в CaS. Позже, при взаимодействии с SiO₂ (кремнезёмом), образуется CaSiO₃ — шлак, который отделяется от металла и уносит с собой вредные примеси.

А где взять этот CaCO₃? В карьере же!

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

Я называю это «синдромом Данилы-мастера»: специалист уже не просто решает задачу, а пытается доказать с её помощью собственное мастерство. Разберём, как перфекционизм связывается с самооценкой, почему очевидные советы о декомпозиции могут не работать и как небольшой законченный шаг возвращает человеку способность двигаться дальше.

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

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

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

Что делать, если:

• всю продуктовую разработку разместили в одном Jira-проекте, рассчитывая на «единообразие любой ценой»;

• у бэклога и процессов нет явного владельца;

• команды работают над крупным омниканальным продуктом со сквозными интеграциями и зависимостями;

• релизы взаимозависимы, классический Scrum не подходит, а переход на Waterfall никто не хочет даже обсуждать;

• методология приоритизации целей существует, но применяется только эпизодически;

• приоритеты обсуждаются раз в квартал, а затем команды самостоятельно ищут ресурсы для кросс-командных доработок.

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