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

Когда я выкладывал на Хабре кейс по поиску внутренних резервов для развития предприятия (https://habr.com/ru/articles/1038894/), мне казалось что я излагаю какие-то базовые вещи, которые должны быть всем известны. И я очень удивился, когда оказалось что это далеко не так. По этой причине я решил что есть смысл начать объяснять всё сначала. Тем более, что моё понимание бизнес-способностей, как инструмента управления, несколько эволюционировало за время, прошедшее с публикации предыдущих вводных материалов. Поэтому начинаю с новой вводной статьи на тему «что такое бизнес-способности» и предполагаю в дальнейших материалах выкладывать дополнения, формирующие целостное понимание бизнес-способностей и планирования / управления на их основе.

0.86.0-beta.1 - это большой бета-цикл: агент получил единый дом в интерфейсе, у Yttri появился первый плагин (интеграция с Obsidian) и сама платформа плагинов, на Mac с Apple Silicon заработал альтернативный локальный движок MLX, а голосовой ввод и запись прошли через плотную серию фиксов стабильности. Ниже - по разделам, что из этого видно пользователю.

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

В результате в 1970 году им была написана книга «Необыкновенный теннис для обыкновенного игрока».

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

Практический dev-story о том, почему AI-агент для реальной работы - это не чат с моделью, а система из задач, браузеров, проверок, журналов, ограничений и внешних интеграций. На примере публикационного пайплайна: сайты, CMS, соцсети, cron, browser sessions, anti-false-success, CRM, нейросеть, видео контент и SEO-грабли. От настройки до практического применения.

Привет, Хабр! Меня зовут Лера, я технический писатель в Авито. Сегодня в статье хочу рассказать о книге, которая около 40 лет остаётся настольной для руководителей, предпринимателей и менеджеров по всему миру. Речь пойдет о книге «Цель» Элияху Голдратта. 

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

И хотя действие книги происходит на производстве в 1980-х годах, её проблемы удивительно актуальны для современной IT-индустрии: перегруженные команды, бесконечные очереди задач, локальная оптимизация метрик, зависимости между командами и попытки ускорить всё одновременно. Как со всем справиться? Надеюсь, статья приблизит вас к ответу на этот вопрос. 

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

В 1975 году Фредерик Брукс выпустил книгу «Мифический человеко-месяц». Она появилась не потому, что он решил написать очередной учебник по менеджменту. До этого Брукс руководил разработкой операционной системы OS/360 в IBM - одного из самых масштабных программных проектов своего времени. Когда всё закончилось, ему было что рассказать.

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

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

В прошлой статье я писала про то, что значит быть Internal PO, когда у продукта нет клиента с улицы. Естественный следующий вопрос: а как в таком случае доказывать ценность в цифрах? Вот с этим и разберёмся.

Все цифры в примерах ниже — условные, для иллюстрации метода.

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

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

Меня зовут Алексей Ильичев, я программный инженер по образованию. Во время обучения работал на фрилансе в зоне фронтенда. И получил предложение заняться бэкендом в части разработки плагинов для САПР (систем автоматического проектирования) AVEVA для нефтяных платформ. Мне в моменте стало интересно, и все, за уши не оттянешь. 

Сейчас я работаю в управлении инженерными данными в Цифровом СИБУРе. Когда строят крупный завод, все его системы сначала проектируют в 3D-модели: трубопроводы, оборудование, арматура (задвижки, клапаны, вентили, все, чем можно перекрыть поток), кабельные трассы, эстакады. Каждый объект в модели должен быть проименован, то есть назначен идентификатор в виде тега. 

Тег — это уникальное имя, сформированное по специальным правилам, по которому объект потом найдут на реальном заводе, включат в реестр обслуживания, загрузят в систему управления инженерными данными – наша внутренняя разработка. Без тегов 3D-модель просто геометрическая болванка, которую можно использовать только в качестве опорной модели, от которой на стройке нет толку.

Могу точно сказать, что почти весь бизнес теряет до 50% своей эффективности из-за того, что разные отделы/департамента тупо не могут найти общий язык, а часто и откровенно враждуют друг с другом. Вот мой топ 3 отделов/департаментов, которые не любят особенно актуально:

Работа проектного института охватывает полный цикл строительного проекта: от изысканий и BIM-моделирования до авторского надзора. Его специалисты уже несколько лет работают в программах комплекта nanoCAD Инженерный BIM (с апреля 2026 года – nanoCAD комплект Инженерия). Но для комплексного BIM-процесса недоставало ключевых звеньев: мощных инструментов архитектурно-строительного моделирования и единой среды для данных.

Было принято решение внедрить nanoCAD BIM Строительство (конфигурация «Архитектура») и CADLib Модель и Архив, чтобы научиться создавать 3D-модели архитектурной части, отработать процедуры информационного моделирования и выпустить собственные автоматизированные шаблоны. Полигоном для экспериментов стал реальный проект малоэтажного гражданского здания.

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

В этой статье мы собрали несколько рекомендаций для руководителей, ИБ-специалистов и других участников проектов по защите КИИ, основанных на нашем опыте. Как субъекту КИИ выбрать подходящего интегратора? Как наладить взаимодействие внутри проектной команды, чтобы избежать организационных проблем? Какие технические и юридические нюансы стоит учесть? Ответы — под катом.

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

Вы сидите в очередном Телемосте, Толке или Тимсе, смотрите на мозаику из лиц и аватарок и понимаете: время мучительно тратится впустую.

Всем привет! В предыдущих двух статьях нашего цикла – шесть основ бизнес-анализа мы с вами разобрали первые два базовых понятия Бизнес-анализа – Заинтересованные стороны (Stakeholders) и Потребность (Need).  Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», т.е. определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес-аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.

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

Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).

Фиксить рутинные баги — это отстой. Никто в здравом уме не просыпается с мыслью: «О, как же я хочу сегодня весь день ковырять чужой легаси-код, чтобы понять, почему кнопка в IE11 уезжает на три пикселя влево!»

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

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

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

Короче, нас засыпало. Если раньше приходило 10–15 в месяц, то стало 10–15 в день. А дальше классическая дилемма:

— Если заставить сеньора месяц разгребать минорные баги, он просто выгорит и уйдёт.

— Нанимать джунов фиксить баги — хорошая идея, но не в этом случае.

— Поручить всё это дело нейросетям — возможно, выстрелить себе в ногу.

А когда мы пропускали шанс выстрелить себе в ногу? Короче, сейчас процесс выглядит так: баг попадает на доску в нашем Кайтене, летит в специальную колонку, там его подхватывает модель, пишет фикс, делает саморевью, делает тесты, собирает Pull Request, второй независимый агент в репозитории делает ещё контрольное ревью, и дальше это попадает на ревью к человеку.

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

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

Джефф Безос не вывел бы Amazon на вершину рынка, не овладев искусством принятия решений. В письме акционерам в 2015 году он предложил разделять решения, с которыми регулярно сталкиваются предприниматели и руководители, на два типа.

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

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

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

Масштабы одиночества среди лидеров: Глобальная проблема