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

Всем привет от Петра Третьяка, который за 10 лет в управлении проектами ни разу не видел, чтобы крупный релиз вышел ровно в ту дату, которую назвали на старте. Ни разу. При этом все на старте в эту дату верили: и заказчик, и команда, и я сам.

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

Но с каждым днём кубики становятся мельче, а модели — сложнее и реалистичнее. Работа требует всё больше концентрации и времени.

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

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

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

Почему одни User Story работают как часы, а другие становятся источником бесконечных багов и ночных звонков? За годы работы в FinTech собрал коллекцию типичных ошибок, из‑за которых команды теряют драгоценное время. В статье — живые кейсы, наглядные диаграммы, разбор INVEST и практики Three Amigos, которые снижают число дефектов. Рассмотрим, как превратить сырую идею в зрелую User Story с чёткими критериями приёмки и нефункциональными требованиями.

За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.

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

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

Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека.

Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.

И это не исключение. Это нормальное состояние большинства организаций.

Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».

В IT разработке результат дает не один человек, а команда. А в любой команде (даже если она работает на полной удаленке) будут отношения. А где есть отношения, там есть манипуляшки.

Мир неидеален, на солнце есть пятна, не все проекты делаются в срок, начальники орут, исполнители молча соглашаются с невыполнимым и доблестно выгорают - короче, все неидеально.

Но если все так, то как сохранить себя в этом бардаке, как работать максимально эффективно с совершенно разными людьми?

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

Эта статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи тут, на Хабре.

Итак, поехали!

Этот текст о применении ИИ-агентов для задач управления проектами.

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

Иными словами, ИИ-агент не просто отвечает, а формирует вашу картину проекта. А это уже совсем другой уровень управленческого риска.

Как связаны ИТ и строительство? Очень тесно — через методологию управления.

Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!

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

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

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

Фича-тоглы: мир удобства без лишней настройки

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

Каждый раз, когда какой‑то продакт с гордостью говорит: «Я сам собрал прототип за вечер на AI/no‑code», я не вижу в этом геройства. Я вижу главу продукта, который превратился в ещё одну пару рук для дешёвого билдинга. Вижу человека, который перестал быть «мозгами продукта» и стал универсальным солдатом, которого удобно использовать, но невозможно уважать как продуктового специалиста.

Продолжение цикла про карьерные переходы моего клиента топ‑менеджера из IT‑блока в «Газпром». Четвертая тактика — про репутацию без рилсов, подписчиков и погони за охватами.

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

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

Вам же, если вы читаете этот текст, скорее всего, нужно другое.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»

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

Ваш мозг - самый ненадежный инструмент

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

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

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

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

Цифровые продукты не развиваются в отрыве от среды. И пока проект находится в разработке, меняются приоритеты бизнеса, ситуация на рынке, а исполнитель продолжает работать по уже устаревшему ТЗ. В итоге проект сдан в срок, но результат не решает актуальные задачи бизнеса.

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

В статье операционный директор CleverPumpkin Владислава Ларкина рассказывает, как компания выстраивает отношения со своими клиентами, чтобы знакомство переросло в долгосрочное партнёрство. И какие процессы помогают команде брать на себя больше ответственности, а бизнесу получать предсказуемый результат.

Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».

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

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

То есть уже понятно, что:

Последние годы в IT‑командах регулярно встречаю один и тот же паттерн — у техлидов и различных руководителей самого среднего звена.

Назову его Геннадий. Техлид. В команде за глаза зовут «Ещё Подумаем». Восьмой год в роли. Выбор фреймворка — две недели. Приоритеты спринта — три встречи. Даже «куда идём обедать командой» превращается в опрос в чате.

Геннадий — человек, который всегда знал, как надо. Уверенный. С позицией. Решал сам — это было его.

Перестало работать.

HR считает его выгоревшим, отправляет в отпуск. Он возвращается посвежевшим — ничего не меняется. Вопросы продолжают висеть.

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

Слово есть — в нейробиологии.

Говорят: “выстраивать процессы”. А откуда они берутся, как это обычно происходит, и вообще, зачем это всё?

Что такое процесс? Это то, как организована повторяющаяся работа, взаимодействие между участниками, ради какого-то общего результата.

Процесс никогда не должен быть самоцелью. И нет никакого универсального процесса на все случаи жизни.

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

В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.

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

Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.