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

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

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

Miro продали в 13 раз дешевле оценки 2021 года, и я пошёл считать, что вышло из нашей попытки уйти от подписок. За год мы заменили Tilda, Confluence, Jira и Slack своим кодом, целей было две: экономия и гибкость. Экономии не получилось: по полной ставке сеньора и с учётом владения первый год ушёл в минус около 2 млн. Гибкость, кажется, получилась, и выяснилось, что трекер до рабочего состояния доводит не разработчик, а скрам-мастер. В статье цифры по четырём заменам, инцидент с уязвимостью в авторизации, который заставил поставить ревью второй нейронкой, и критерий из трёх вопросов, что переписывать не стоит.

31 августа прод моего приложения пролежал около часа.

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

Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.

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

Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic‑Graphics‑Music, где баш‑скрипты по имени платы строят проект, сразу сказал «А давайте перепишем все на питон». И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.

А теперь посмотрим, что из этого получилось.

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

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

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

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

Недавно OpenAI выпустила GPT-6 Astra. Новая модель стала лучше работать с длинными и сложными задачами, большим контекстом, файлами и инструментами. Для меня это интересный релиз ещё и потому, что AI я в основном использую не для написания кода. Я PM, поэтому мои основные задачи это требования, Jira, документы, анализ информации, планирование и подготовка материалов. Появление более мощных инструментов отлично экономит время, но не отменяет базовой логики: распределять ресурсы с умом и контролировать точки отказа. В этой статье делюсь личным опытом: как построить удобный loop взаимодействия с AI, почему Astra нужна далеко не всегда и какие проблемы процессов не решит даже самый продвинутый алгоритм.

В предыдущей статье мы разобрали пятое базовое понятие BABOK — Контекст (Context). Мы выяснили, что контекст — это не фоновое знание, а структурированный анализ среды, который определяет границы возможного решения.

Теперь цепочка почти замкнута: мы нашли нужных людей (Stakeholders), поняли что им нужно (Needs), спроектировали переход (Change), выбрали решение (Solution) и убедились, что оно жизнеспособно в данной среде (Context). Остаётся один — финальный и, пожалуй, самый честный — вопрос:

А зачем всё это было нужно? И как мы поймём, что оно сработало?

Именно на него отвечает шестое и последнее базовое понятие BABOK — Ценность (Value). Оно завершает цепочку. Разберём, что такое ценность в понимании BABOK и почему без её измерения работа аналитика технически никогда не завершена.

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

Мы в «Фалькон Тех» уже 9 лет разрабатываем цифровые решения для умного города на основе видеоаналитики и машинного зрения. В статье рассказываем, почему продукт и разработка должны работать в связке, а не передавать друг другу задачи по цепочке.

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

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

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

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

В этом материале расскажу подходе PES (Persona–Execution Separation), отделяющем «личность» виртуального агента от задач.

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

Привет, Хабр!

Мы убеждены, что при проектировании систем их нужно, прежде всего, тщательно продумывать и моделировать. В крупной организации на это накладывается столько разночтений, согласований и неизбежного недопонимания, что кому‑то просто необходимо предотвращать скатывание системы в хаос, одновременно её корректируя и развивая. О том, как это сделать программному архитектору, системному аналитику и людям, принимающим решения, рассказала Дайана Монталион в своём труде «Изучаем системное мышление», недавно пополнившем наш книжный зоопарк. Дайана Монталион более 20 лет занимается программной архитектурой и создаёт передовые программные системы для таких организаций как Стэнфордский университет, фонд Билла и Мелинды Гейтс, газеты The Economist и портала Wikimedia. Основала компанию Mentrix Group, занимающуюся разработкой ПО и оказанием сопутствующих услуг. Также ведет семинары по системному мышлению, технологической архитектуре и нелинейным подходам к разработке ПО. Предлагаем вам подробный обзор книги от блогера Хави Агирре, подробно проштудировавшего её.

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

В статье рассказываю, почему связка «агент + skill + API» может стать новым интерфейсом управления сайтом, где админка всё ещё удобнее и почему хороший API при таком подходе становится только важнее.

Почему ИИ нельзя внедрить как ERP, нельзя раздать как Office, и что тогда остаётся

В ТЗ на «внедрение ИИ» перед самым конкурсом вписали маленький пункт: перевести перевод внутренних документов с ПРОМТа на нейросеть. Документы конфиденциальные, в облако нельзя, а то, что влезает в закрытый контур, испытаний не проходит — и контракт на десятки миллионов повис на одном абзаце. Разбираю, почему ИИ нельзя внедрить как ERP и нельзя просто раздать как Office, что реально влезает в контур (с ценами в рублях), и как мы вытащили задачу из клетки, которая не закрывается ничем.

Мы собирались начать автоматизацию закупок с одного завода: провести пилот, отладить решение и потом тиражировать его на остальные предприятия. План выглядел профессионально и безопасно – пока директор по закупкам не оценил пересечение процессов четырёх заводов в диапазоне 40–60% в зависимости от площадки и участка процесса. Это был не формальный расчёт, а суждение человека, который видел закупочную работу всех предприятий. Его хватило, чтобы увидеть риск: один завод не был уменьшенной копией остальных. Выбрав его пилотом, мы могли сначала автоматизировать значительную часть локальной специфики, а затем переделывать решение при каждом тиражировании.

Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией и технической поддержкой ИТ-инфраструктуры. Agent-Ops — проект открытой отраслевой методологии совместной работы инженеров и ИИ-агентов. Мы начали разрабатывать его весной этого года и сейчас выложили первый кандидат версии 0.4.0 на GitHub и GitVerse. Одновременно, на конференции IT Elements 2026 мы договорились о совместной работе с инженерами из 2х других компаний, они стали у нас maintainers. Поэтому сегодня Agent-Ops - это не инициатива только одной компании, а совместной работа нескольких. Надеюсь, количество единомышленников будет увеличиваться. Приглашаем контрибуторов развивать этот проект вместе с нами.

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

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

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

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

По данным отраслевых исследований, до 40% внедрений информационных систем управления проектами (ИСУП) заканчиваются отказом от их использования или переходом в режим «формального присутствия». Большинство неудач корнями уходит не в качество конкретного ИТ‑продукта или технологическую экспертность вендора \ поставщика решения, а в сам подход или логику выбора.

В интернете регулярно появляются обзоры «100 ИСУП 20ХХ года», которые скорее делают рекламу конкретным продуктам или провайдерам, но мало помогают конкретной организации с конкретным выбором. И это лишний раз подчеркивает неоднозначность и сложность такого выбора для поддержки именно вашей проектной деятельности именно в вашем организационном кейсе.

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

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

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