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

Я готовил участок под модульный дом в тайге, находясь за 3 500 км от объекта. Нулевой цикл занял четыре месяца и стоил около 2,8 млн ₽ еще до первого фундаментного блока. В статье разбираю, как искал землю, делал топосъемку, подводил электричество, организовывал подъезд и контролировал подрядчиков удалённо – с цифрами, ошибками и выводами по планированию. 

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

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

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

Планирование времени это же целая «наука», до момента когда я стал интересоваться и применять методики тайм‑менеджмента, не представлял как много уходит времени мимо и расходуется не эффективно. Но стал ли я от этого успешнее, продуктивнее. Стало ли мне легче?

Кен Гриффин, основатель Citadel (по состоянию на начало 2026 года, Citadel признан самым прибыльным хедж-фондом за всю историю, и управляет больше чем 60 миллиардами долларов) рассказал о том, как компания формирует культуру победителей и как не задохнуться от бюрократии, когда у тебя тысячи сотрудников.

С конца 2025 года РКН подал не менее 8 исков против крупных разработчиков игр. Но эта статья — не про игры. Точнее, не только про них.

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

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

Четвёртая статья из серии. Предыдущие: манифест, итерация 0, итерация 4 убита.

В прошлом посте я закончил так:

> Эту работу агент не сделает. Реализовать — сделает. Придумать — моя задача.

С того поста — 20 часов и 20 коммитов. На код пришлась небольшая часть. Основная — на методику.

Что не сработало в первой версии

Схема была такая: пользователь отвечает → маленькая LLM классифицирует «вопрос + ответ» в массив сигналов с весами → сигналы накапливаются → детерминированный код назначает карту по порогу.

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

Что такое методика в моём случае

Представьте: совещание. Руководитель разбирает чужой проект, но смотрит почему-то на вас. Голос становится холоднее. Пауза затягивается.

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

Четыре человека. Четыре реакции. Один нейробиологический механизм возрастом несколько сотен миллионов лет.

Тонкости юзер-стори, устаревшие стори-пойнты, обманывающая команда, токсичность, гайд по дедлайнам, глава из руководства по P3.express и всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

Тогда, стоит напомнить, что магия вне Хогвардса запрещена 🙃

Я регулярно вижу одно и то же: в компанию вливаются бюджеты, заходят дорогие и не очень консультанты, рисуются красивые схемы (но, чаще некрасивые). Процессы переписываются. Люди — нет.

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

Раньше можно было приписать «Agile», и добавить x100 к стоимости, сейчас лучше выбрать «AI». Хе‑хе.

Штат раздувается. Роли множатся. Ответственность размывается. Это как поменять море на океан, но продолжать плыть с дыркой в лодке.

Самое неприятное: вы ещё и платите за это 🙂

В публикации предлагается формальная математическая модель, связывающая накопленный Cost of Delay C(t) и остаточный Expected Monetary Value EMV(t) как взаимно обратные (комплементарные) функции относительно исходной ценности V₀. Показано, что для всех пяти канонических профилей CoD по Д. Райнертсену (Urgency, Fixed Date, Intangible, Expedite, S-curve) точка пересечения кривых CoD и EMV всегда лежит на уровне V₀/2, а отличается только скорость её достижения. Этот результат даёт руководителю проекта универсальный индикатор break-even задержки и основу для количественной приоритизации портфеля задач по WSJF/CD3.

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

За две статьи меня успели оклеветать: копирайтером, который вылез из тени своего спеца и ИИшкой:

Я руководитель проектов и у меня есть команда разработки продуктов. Аналитики исследуют и анализирует новые фичи, пишут спецификации. Есть разработчики и тестировщики. Есть DevOps, который чинит CI и выкатывает релизы. И даже есть технический писатель анализирует изменения и обновляет документацию.

Обычная продуктовая команда разработки.

Только людей в этой команде нет.

Все исполнители - AI-агенты…

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

Современные AI-агенты способны выполнять работу разных инженерных ролей, так почему бы не управлять ими как полноценной командой? А для управления использовать те же подходы, которыми мы давно управляем человеческими командами: Kanban, Scrum, Agile, Definition of Done, декомпозиция, pipeline, review, escalation.

Эта статья — про мой практический опыт такого подхода. Не про «AI заменит программистов». Не про «теперь можно не думать». И не про «вот магическая кнопка, которая делает продукт». Скорее наоборот: чем больше AI пишет кода, тем важнее становятся процесс, постановка задачи, спецификации, тесты, CI, документация и контроль состояния.

Моя рабочая практика сложилась таким образом, что почти всю жизнь я проработал в стартапах самых разных отраслей, и моей задачей было вывести компанию на приемлемый зрелый уровень. Здесь следует сразу обозначить, что именно я подразумеваю под стартапом, поскольку различных определений много. Итак, стартап - это организация, которая не понимает, что именно она делает, на чём она зарабатывает. Стартап - не обязательно молодой бизнес. Бывают компании, которые не выходят из состояния стартапа и 5 лет, и 10 лет.

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

Таблица 1. Стадии развития организации

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

Если погуглить «payment hierarchy», найдёте десяток исследований TransUnion за 15 лет. Они отслеживают одну вещь: в какой последовательности заёмщик с несколькими долгами уходит в просрочку, когда денег на всё не хватает.

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

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

У нас всё ровно наоборот.

От руководителя, точнее от его решений зависит в бизнесе слишком много.
Nokia, Motorola, Volkswagen, Tesla и другие больше компаний были или уничтожены, или потеряли репутация из-за действия именно руководителя.
Именно поэтому в MBA и EMBA так важно провести аудит тараканов мышления у руководства бизнеса.
Для этого я разработал простой тест из трёх вопросов.

1. Как правильно Молдавия или Молдова/ Алматы или Алма-Ата.

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

2. Почему большой внешний долг США - это не проблема для экономии США.

(госдолг США - это лакмусовая бумажка для понимания насколько руководитель понимает как работает экономика.
Вероятно, он даже не понимает, что кредит дают тому у кого есть деньги или в кого верят.
Ну или он пересмотрел телевизор, и тогда это вообще тяжёлый случай)

3. Почему атомная энергетика самая неэффективная и дорогая из всех видов.

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

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

Как сделать так, чтобы продукт или фича работала для пользователя? Ответ в этой статье.

Привет, на связи Саша Солдатов, CEO REB8T! Сегодня расскажу про четыре инструмента, которые наша команда использует в работе на каждом проекте: JTBD, ICE-приоритизацию, User Flow и UX-гипотезы.

Огромное спасибо нашему Lead UX/UI Вере Ксенофонтовой, которая собрала этот материал и разложила всё по полочкам для вас и нашей команды!

А теперь, начнём!

Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.

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

Обычно аналитик долго пишет ТЗ, когда пытается делать три вещи одновременно: понять задачу, спроектировать решение и оформить это всё в документ. Это как сервировать праздничный стол, не решив, что будете готовить, и параллельно искать рецепт в интернете. В голове разные интеллектуальные процессы смешиваются в одну кучу и возникает ступор. 

На связи Ольга, бизнес-аналитик в Outlines Tech. Расскажу, как я погружаюсь в новую задачу, чтобы составить техническое задание за 30 минут. По моей методике 80% работы над ТЗ — понять и договориться, 20% — зафиксировать всё в документ. Так не придётся торопиться и придумывать текст с нуля или вносить правки на ходу.