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

Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.

От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.

В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.

Скажите, вот когда у вас на проекте срываются сроки, когда бэклог растет, а скорость, кажется, падает — что чаще всего звучит как универсальное решение? Правильно: «Надо распараллелить!» Взять больше людей. Разбить задачу на подзадачи. Запустить процессы одновременно. Кажется, что если одна команда делает функцию А, а вторая — функцию Б, то автомобиль… простите, продукт — соберется в два раза быстрее.

Но почему же тогда так часто это не работает? Почему добавление людей в проект иногда его только тормозит?

К моменту прихода Ли Якокки (легенда менеджмента производства авто, создатель Форд Мустанг) Крайслер находилась на грани банкротства. Чтобы не потерять бизнес Якока закрывал убыточные заводы, продавал непрофильные активы, изменил отношения с поставщиками, сконцентрировал все усилия на создании новой линейки автомобилей — K‑Car и другие. Принятые меры позволили оживить бренд, погасить долги и начать рост бизнеса. 

ЭТО - НЕ ПРО ОШИБКУ КАДРОВ. Это про систему, где клиническая неспособность становится культом, а профессиональный кретинизм возводится в ранг гениальности. История о том, как в команду внедряют "ментального инвалида" на позицию продакта, и его начальник - сентиментальный идиот наверху - с благоговением принимает этот дефект за "нестандартное мышление".

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

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

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

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

В статье разбираем интеллектуальный конформизм (на примере экспериментов Аша), почему он так живуч в разработке, и почему тестировщик часто становится первым безопасным голосом несогласия. Плюс — как shift-left помогает встроить это несогласие в работу так, чтобы оно снижало риски, а не повышало градус в чате.

Когда я пришёл в последнюю компанию тимлидом, первое время ушло на знакомство с командой, ближайшими планами, запуском проекта и задачами адаптации. Через пару недель стало понятно, что пора организовывать работу команды вокруг развития продукта и людей. Я опирался на предыдущий опыт и составил для себя чек‑лист, который разложился на три блока: спринт, команда и продукт.

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

Эта статья – детальный обзор работы с Библиотекой объектов в nanoCAD BIM Строительство 25 – ключевом инструменте для наполнения информационной модели. Рассмотрены принципы работы с параметрическими элементами, структура библиотеки и её интеграция с Диспетчером проекта.

Отдельное внимание уделено настройке библиотек в корпоративной среде с помощью Менеджера библиотек, а также процессу создания пользовательских объектов.

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

Привет, я Максим Королев из Петрович-ТЕХ, занимаюсь уровнем сервиса. Моя роль — в том числе про “как хороший сервис показать пользователю, чтобы тот не отказался от нового/сложного/страшного инструмента”.

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

Решили сделать семейство Telegram-ботов, которые сократили время на создание повторяющихся задач на 50–70%, подняли заполняемость до 100%, ускорили реакцию на инциденты.

Если в новом году хотите запилить много микроавтоматизаций через боты, наш кейс к вашему столу: вот как вышло у Петрович-ТЕХа.

Привет, Хабр! Меня зовут Грищенков Евгений, я системный аналитик Fix Price. В этой статье расскажу о собственном приложении FixMark. Отгрузка в коробках уменьшает затраты на транспортную и складскую логистику. Для маркировки коробок используются общепринятые SSCC-коды (сокращение от Serial Shipping Container Code), которые облегчают отслеживание грузов и помогают автоматизировать логистические операции, позволяя идентифицировать грузы на всех этапах транспортировки. Фактически один SSCC-код агрегирует данные о штрих-кодах всех товаров внутри коробки, позволяя проводить операции со всем содержимым через одно сканирование.

Разбираем, как мгновенно сделать AI-тесты на примере правил Хабра и как искусственный интеллект их проверяет!

Дни ручного создания тестов и проверки сотен ответов — в прошлом. Показываем на живом примере, как AI теперь делает это за вас: генерирует вопросы из документа за секунды и придирчиво проверяет текстовые ответы, как строгий, но справедливый эксперт. Читайте разбор кейса и готовый алгоритм действий.

Ваша компания гордится круглосуточной работой, крутыми проектами и руководителями, выросшими из инженеров. Но знаете ли вы, что эти поводы для гордости создают для вас (для вашей организации и лично для вас) самые труднорешаемые проблемы?

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

Это базовая методичка по канбан. На пальцах объясняю, как устроен метод и даю рабочую схему, как внедрить его в команде.

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

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

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

Тем, как правильно это делать, мы сегодня и займёмся.

В компаниях регулярно всплывает спор, который очень похож на инженерный: «Мы делаем правильно, но медленно» vs «Мы делаем быстро, но криво».

На уровне разговоров это обычно превращается в конфликт стилей:

Удивительное наблюдение. Товарищ жалуется на нехватку сил:

— А как ты отдыхаешь? — интересуюсь я.
— А как-как — дела закончу и могу в комп поиграть. — рассказывает он хвастая своими игровыми новинками.
— И играешь небось с того же компа на котором 5 минут назад работать закончил? — Ну да…

Мы с вами знаем таких людей: может отпахать 10-ти часовую смену, а потом засесть еще и в игру.

Парадокс. Люди часами-днями рубят монстров в игре на износ. Тратят время, силы, ресурсы, разгоняют психику. Устают, а усталости не чувствуют.

И внедряя геймификацию в бизнес мы формируем такой же эффект. Нам надо, чтобы люди тратили (или зарабатывали нам) деньги и не задумывались. Чтобы были увлечены процессом, как игрой.

Как так получается?
Есть одна вещь, которая хорошо объясняет этот феномен.

Если коротко, то, конечно, есть. Но я бы не писала об этом, если бы все было так просто.

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

Сделаем шаг назад и попробуем описать термины «продукт» и проект» и их связь. Вот и все 😊. Собственно, на этом шаге и стала очевидна первопричина всех споров.

В классических стандартах PMBOK, PRINCE2, ISO 21500, ICB «продукт» рассматривается как конечный результат проектной деятельности под запрос. Например, нам заказали строительство дома. Проект – это вся деятельность: планирование, закупка материалов, работа строителей, контроль сроков и бюджетов. Продукт - сам дом, который мы получаем в конце целиком или по частям (кухня, гостиная и т.д.).

В Agile-методологиях Scrum, Kanban, SAFe, Lean «продукт» - это ценность, которая развивается и поддерживается итеративно, понятие «проект» почти исчезает.  Например, продукт – дом пригоден для жизни уже после первых итераций, но со временем только улучшается. Проект – работа с итерациями (Scrum), поток задач (Kanban), оптимизация процесса строительства (Lean). То есть в классических стандартах проект «больше» продукта, в Agile – наоборот. Важно, что здесь мы не говорим об однозначном соответствии классических стандартов со способом реализации, то есть сравнение классические стандарты vs Agile‑методологии это не то же самое, что и Waterfall vs Agile, ведь и в классических стандартах, например, PMBOK, описывается управление проектами через «гибкие» методологии.

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

12 января 2026 года исполнилось 119 лет со дня рождения Сергея Павловича Королева. Его нет с нами уже более полувека, но созданный им космический «задел» до сих пор определяет контуры не только российской, но и мировой космонавтики. Мы живем в эпоху Илона Маска и частных стартапов, возвращения на Луну и полетов к Марсу. При чем здесь советский конструктор, родившийся при царе? Ответ прост: именно Королёв заложил фундаментальные принципы, на которых стоит наше сегодняшнее представление о космосе как о пространстве для жизни, работы и мечты.

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

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

Найти квалифицированного исполнителя для выполнения технически сложной задачи не так просто. Но практика показывает, что еще сложнее найти квалифицированного заказчика.

Эта статья — крик души Кирилла, основателя одной ИТ‑компании и руководителя подразделения в другой (обе специально не называю). Работал 20 лет в ИТ, писал код, управлял проектами, продавал, сделал пару ИТ бизнесов. Далее рассказ от его имени. 

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