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

Хороший (хоть и слегка чересчур эмоциональный) пост бывшего сотрудника NASA Кейси Хэндмера, собравший огромное количество фактов об истории и текущем состоянии американской космической капсулы Orion. $30 млрд потрачено, один полёт за 20 лет, теплозащитный экран трескается и откалывается кусками, батареи трижды перепроектировали, электрика сбоит по разу в день, а NASA собирается отправить четырёх астронавтов в дальний космос на аппарате, чья система жизнеобеспечения ещё ни разу не испытывалась в полёте. Продолжение серии переводов, начатой со статей «Отмена SLS: разве мы просим слишком много?» и «SLS по-прежнему является национальным позором».

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

Ошибки в бизнесе стоят дорого. Иногда — слишком дорого.

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

Есть паттерн, который видит каждый, кто работает с агентами: первые 5–15 минут уходят не на задачу, а на "ориентацию". Где точка входа? Откуда растут зависимости? Почему эта библиотека, а не другая? Кто считает это публичным API? В маленьком проекте раздражает. В большом — превращается в постоянный налог на токены и внимание.

DSP (Data Structure Protocol) "выносит карту проекта наружу" — в простой, версионируемый, языковой граф, который живёт рядом с кодом и доступен агенту как постоянная память.

k-kolomeitsev/data-structure-protocol

Цель в архитектуре сформулирована так:

1) Цель и границы

Цель DSP — хранить минимальный, но достаточный контекст о репозитории/системе артефактов в виде графа «сущности → зависимости/публичный API», чтобы LLM могла:

- быстро находить нужные фрагменты по UID,

- понимать «зачем» сущности существуют и «как» они связаны,

- не требовать загрузки исходников целиком в контекстное окно.

DSP — это долговременная память и индекс проекта для LLM. Агент может в любой момент выполнить поиск (grep) по проекту, найти нужные сущности по описаниям/ключевым словам и от найденного UID раскрутить весь граф связей: входящие зависимости, исходящие импорты, реципиентов через exports. Это заменяет необходимость «помнить» структуру проекта или загружать его целиком — вся карта проекта всегда доступна через .dsp.

Иногда в человеке возникает странное чувство.

Ты вроде занят. В календаре что-то стоит. Руки что-то делают. Мозг даже устал. Но внутри — неприятное, липкое ощущение: я делаю что-то не то.

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

Я заметил это чувство и сначала попытался отмахнуться: “ну, просто устал”, “надо собраться”, “завтра будет легче”. Но оно не уходило. И тогда я сделал непривычную вещь: начал разбирать не себя, а задачу.

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

А если честных аргументов нет — появляются сомнения. И эти сомнения разъедают мотивацию намного сильнее, чем усталость.

Дальше — хуже: я смотрю на список дел и вижу десятки задач. И все они… как будто равнозначны.

Как выбрать?

Чем отличаются китайские дроны Tello от российских «Геоскан» и как они применяются в образовании школьников: практический опыт в Центре гуманитарных и цифровых профилей «Точка роста».

Привет, Хабр! Меня зовут Григорий и я руковожу департаментом продуктового дизайна в «Лаборатории Касперского». Хочу рассказать историю, которая началась как форс-мажор, продолжилась как управленческий челлендж и закончилась как хорошая тренировка, позволившая нам проверить устойчивость процессов, силу команды и надежность новых технологических партнёров.

Речь пойдёт о том, как в один момент может перевернуться жизнь целого дизайн-департамента (и не только), вынужденного сменить основной рабочий инструмент с Figma на Pixso и как грамотная организация работы помогает минимизировать влияние на непрерывность бизнес-процессов при экстренном переходе на другое решение.

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

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

Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC.

За годы в ИТ я видел десятки команд, которые буквально тонут в техническом долге, но даже не осознают этого. Они продолжают героически вкатывать хотфиксы, год за годом пересобирать один и тот же код и удивляться: почему скорость упала, а пользователи ноют?

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

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

Без магии, зато с метриками, ролями и реальными кейсами.

Привет, Хабр! Как вы считаете, что делает проект управляемым? На мой взгляд, это не только про грамотное планирование или профессиональную команду, но и возможность отследить промежуточные результаты. Истинный контроль рождается там, где есть возможность вовремя остановиться, оглядеться и убедиться, что всё идет по плану. В проектном управлении такие моменты называются контрольными точками (КТ). В статье расскажу, чем отличаются КТ от вех, и как с их помощью выстроить эффективную проектную деятельность.

Вы наверняка ловили себя на том, что раз за разом копипастите в чат с ИИ одни и те же инструкции: «Пиши на TypeScript», «Не используй сторонние библиотеки», «Добавляй тесты». В программировании мы по сути называем это нарушением принципа DRY (Don't Repeat Yourself). Но почему мы продолжаем это делать при общении с нейросетями?

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

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

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

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

«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

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

Стратегия важнее технологии. Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.

Финансовое мышление. Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.

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

В 2022 году мы приняли решение объединить множество показателей, связанных с разработкой, в интегральную метрику Contribution. Данной метрикой мы диагностируем Code review и считаем вклад разработчика в продукт.

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

Сейчас расскажу, зачем это нужно и как мы пришли к этой метрике.

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

В 2026 году регулирование в области персональных данных в России вышло на принципиально новый уровень. Принятые в 2024–2025 годах поправки в КоАП и отраслевые законы превратили формальное соблюдение бумажных требований в вопрос экономического выживания компаний. Штрафы за утечки теперь исчисляются миллионами и даже процентами от годовой выручки, а регуляторы получили инструменты для автоматического мониторинга нарушений.

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

О чем эта статья

«Как дела? Не могу говорить, все горит!»

Реальность B2B SaaS (как и в большинстве направлений разработки) последние пару лет — это перманентный пожар. Заказчик просыпается с новыми вводными, рынок штормит, приоритеты меняются быстрее, чем успеваешь обновить Jira.

Как обеспечить устойчивое развитие IT-ландшафта под нужды бизнеса и снизить затраты на развитие в горизонте

Изображение от rawpixel.com на Freepik

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

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

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

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

В релизе 1.26 языка Go, выпущенном в этом месяце, есть полностью переписанная подкоманда go fix. Go fix использует набор алгоритмов для обнаружения возможностей улучшения кода; часто для этого применяются более новые фичи языка или библиотеки. В этом посте мы сначала покажем, как использовать go fix для модернизации кодовой базы на Go. Во второй части статьи мы расскажем о лежащей в основе этой подкоманды инфраструктуре и её эволюции. В третьей части мы познакомим вас с тематикой инструментов анализа с «самообслуживанием», которые помогают мейнтейнерам модулей и организациям кодироовать собственные правила и рекомендации.

Линус Торвальдс и его друзья рассказали журналисту The Register Стивену Дж. Вогану-Николсу, как сольный проект на Linux превратился в «глобальный джем-сейшен».

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

Но в P&L (Profit and Loss) нет заметного роста. И в какой-то момент возникает вопрос, который неприятно задавать: Если команда хорошая, почему бизнес не чувствует этого в прибыли?