Всем привет! 👋 С пятницей... 🥳 Начинаем чтение 📚 с проработкой книги "Не усложняй! Управление проектами по методу P3.express". Сегодня знакомимся с оглавлением, введением, заключением. Пытаемся понять общую идею. Поехали...

Оглавление я, кстати, не нашёл. 😅 Может это прикол электронной версии этой книги? Кто читает или читал бумажную подскажите есть ли у вас оглавление?

Из изучения остального какие выводы я сделал... 1. Книга свежая, новьё, 2026 год. 2. Сам метод тоже молодой, но уже успел получить опробацию на практике, в том числе на наших просторах. 3. Автор практик с большим опытом преподавания, плюс подтвердил свои навыки и знания сертификацией. Что внушает доверие. 4. Сам метод рассчитан на то, чтобы любой желающий мог ознакомиться, разобраться и начать применять. Краткий итог... Желание прочитать у меня только увеличилось. Дальше больше... #P3_express@SYNC_club

Почему Fix Price — это ловушка По данным PMI (Project Management Institute), средний большой IT-проект превышает бюджет на 45%, сроки на 7%, а выхлоп даёт на 56% меньше ожидаемого. В исследовании Harvard Business Review говорится, каждый шестой IT-проект обошёлся более чем на 200% дороже и вышел за сроки более чем на 70%. Люди плохо оценивают трудозатраты. Не учтены все внешние факторы, слишком оптимистично оценивается время и ресурсы. В процессе работы с проектом приходит более глубокое понимание предметной области и деталей. Заказная разработка такая странная отрасль, где многие подрядчики берут на себя риски, которыми не управляют. Студии кажется, что в этот раз точно получится уложиться в бюджет и сроки. И на фиксированной цене очень настаивает клиент. Чем это заканчивается: - Клиент недоволен, что сроки не соблюдены. Прогноз всегда ошибочен, но клиенту пообещали эксперты. - Не попадаем в оценку трудозатрат. Не редки случаи, когда студия уходит в минус просто чтобы довести проект до конца. - На проекте тлеет, а затем разгорается пожар конфликта. Может дойти до суда. - Все недовольны и демотивированы. Проекты по модели Fix Price можно брать, но если есть ряд условий: 🔵 Вы уверены, что в проекте нет рисков. 🔵 В проекте очень мало неопределенности. Например, у вас уже почти всё готово, осталось прилепить логотип заказчика сверху стандартной заготовки. 🔵 У вас наценка от 500% на качественно просчитанную себестомость. Точная оценка нового проекта — иллюзия. Большой проект с неопределённостью нельзя брать по фиксированной цене. Каждый раз, когда вы берёте большой проект по Fix Price в надежде, что получится заработать, вы играете в рулетку. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Песочница Наверное, каждый из нас хотя бы раз в жизни игрался в песочнице. У кого-то при этом была гора песка, лопаточки, ведёрки, формочки — в общем, полный "жир", а у другого и песка особо не было. Часто песочница выглядела как обрамленный деревянными досками квадрат, но и гора песка без всяких барьеров — это не редкий случай, особенно в регионах 😍. Песочница — масштаб небольшой, тем не менее, обычно среди всей детворы выделялся явно один лидер, у которого было "видение", как из всего имеющегося сделать "конфетку". Примечательно, что явных ресурсов у него не было, но особо талантливые могли организовать и постройку мини-замка. Из моих личных наблюдений (а возможно и снов) такие ребята могли чудом выпросить новый инструмент для дальнейшей работы, не всегда получалось, но за спрос не осудят 🤨. Если оторваться от конкретной песочницы, можно заметить, что их много. И вообще, за границами этого "квадрата" много чего происходит, что не подвластно нашему начинающему лидеру: у него за рамками нет ни ресурсов, ни влияния (хотя со временем, если не зазнается, составит себе "банду" уже не только в песочнице, но и во всём дворе). Всё, что у него есть, досталось ему либо потому что хорошо попросил, либо как-то оно материализовалось само. Вообще, к чему это я. Песочница — это интересная метафора к управлению IT-проектами в организациях 😃. Эти "горы песка" могут быть большими и маленькими, в рамках них руководители вольны делать много вещей, желательно позитивно влияющих на бизнес-метрики. Но это всё ещё "песочница", а серьезные риски, "взрослое" управление ресурсами скрыты за ней. В моей картине мира, уровень "песочниц" заканчивается на этапе, когда ты начинаешь отвечать за реальные деньги. Т.е. в тот момент, когда у тебя на руках условные $50 млн, а дальше твоя задача приумножить этот капитал за счёт новых исследований/IT-продуктов. А может, я всё это придумал и во "взрослом" мире всё немного по-другому. Есть тут кто из взрослых? Расскажите, а то очень интересно 😍.

Ошибка, которая стоила команде месяцев работы 👾 В рубрике «Ошибки на миллион» — история Дмитрия Ильенкова, соавтора книги «Не усложняй: управление проектами по методу P3.express», и разбор ошибки, в которую легко попасть любой компании, стремящейся принимать решения «на основе данных». В 2024 году команда онлайн-школы @pmclub решила внедрить систему сквозной аналитики. Идея казалась безупречной: собрать все данные в одном месте, чтобы управлять бизнесом эффективнее. Несколько месяцев команда строила систему, настраивала отчеты и разбиралась в десятках метрик. Но в какой-то момент стало очевидно: полученную информацию никто не использует. Почему произошел провал: разбор ловушек 🩵 Процесс стал важнее результата Команда настолько увлеклась внедрением аналитики, что перестала задавать себе главный вопрос: какую проблему она должна решить? Работа над системой превратилась в самоцель. 🩵 Попытка измерить абсолютно всё Пять социальных сетей, три сайта, две CRM-системы, почтовые рассылки, LMS, отчеты для разных направлений бизнеса — вместо поиска действительно важных показателей команда пыталась собрать максимум данных. В итоге информации стало слишком много, а пользы — слишком мало. 🩵Ресурсы уходили на обслуживание системы На создание отчетов и проверку данных ежемесячно тратили несколько рабочих дней. Добавились расходы на консультанта и постоянная вовлеченность команды. Аналитика начала забирать ресурсы, которые можно было направить на развитие продукта и маркетинга. 🩵Данные не превращались в действия Главное открытие произошло спустя несколько месяцев: собранные показатели никак не влияли на решения. Они не помогали корректировать стратегию, улучшать продукты или повышать эффективность бизнеса. 🩵 Не была определена конечная цель Совет «принимайте решения на основе данных» сам по себе правильный. Но прежде чем строить сложную систему аналитики, важно понять, какие именно решения вы собираетесь принимать с ее помощью. Без ответа на этот вопрос даже самые точные цифры остаются просто цифрами. Выводы ✨ Любой проект должен начинаться с четкой цели, а не с выбора инструмента. ✨ Собирайте только те данные, которые помогут принять конкретное решение. ✨Регулярно спрашивайте себя: «Как мы используем эту информацию?» ✨Если аналитика не влияет на действия, значит, ее нужно пересмотреть. ✨ Иногда лучший способ повысить эффективность — не усложнять процессы, а отказаться от лишнего. Эта история вошла в книгу Дмитрия и Валерия Ильенковых «Не усложняй: управление проектами по методу P3.express» как напоминание о простом, но важном принципе: прежде чем что-то внедрять, ответьте на вопрос «Зачем?». Именно он помогает не потерять время, деньги и фокус команды.

Я принес. Простой, самый базовый совет, как выглядеть крутым менеджером Есть у меня знакомый опытный менеджер, который через прикол выдал чистую правду. Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043 Я бы еще добавил умение отвечать на такие вопросы: 1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать. 2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться. 3. Какие мы уже видим риски? Сюрприз, но если на старте проекта, где все вроде бы уже кивнули и сказали «изян, сделаем», явно спросить, кто какие риски уже видит прямо сейчас, то откроется портал в ад много всего интересного. 4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а как накостылить вовремя оптимизировать работу.

Закон Брукса⏰ Пошел учиться на системное мышление наконец-то. Откладывал эту часть 2 года и вот оно наконец-то случилось. Кайфую. Сейчас копаю основные законы, которые работают в различных системах, один из них называется закон Брукса. Встречал его кучу раз на практике, но не знал, что так называется. Суть Добавляя больше людей на поздних стадиях проекта, чтобы спасти сроки, вы еще сильнее в них не попадете. Фредерик Брукс сформулировал этот закон еще в 1975 году в своей культовой книге «Мифический человеко-месяц». Казалось бы, математика начальной школы: если 2 копают яму за 4 часа, то 4 выкопают за 2. Почему в IT это не работает? Потому что Проект — это не просто сумма людей, это система связей. Когда мы добавляем в нее новые элементы на поздних этапах, происходит следующее: 1.Коллапс коммуникации Количество связей в команде растет не линейно, а экспоненциально по формуле N(N-1)/2 Команда из 5 человек — это 10 каналов связи. Команда из 10 человек — уже 45. Больше людей = больше митингов, согласований, конфликтов при слиянии кода и потери контекста. 2. Стоимость онбординга Новый человек на проекте не начнет приносить пользу в первые дни. Его нужно ввести в курс дела, показать архитектуру, выдать доступы. Кто это делает? Ваши самые опытные сеньоры, которые вместо спасения релиза теперь работают няньками. Скорость команды в моменте упадет. 3.Неделимость задач Это про «Девять женщин, которые не смогут выносить ребенка за один месяц»*. Некоторые задачи строго последовательны. Вы не можете ускорить процесс компиляции, тестирование сложного флоу или продумывание архитектуры просто посадив за это больше людей. Пара примеров закона Брукса Разработка. Делаете сложную интеграцию с платежным шлюзом, дедлайн через неделю, не успеваете. Если добавите в команду еще одного бэкендера, текущему лиду придется потратить 3 дня на то, чтобы объяснить ему легаси и бизнес-логику. В итоге потеряете время лида и не получите выхлопа от новичка. QA. Перед релизом накопилась гора багов. Перекидываете на проект трех тестировщиков из соседней команды. Они не знают ваш продукт, заводят дубликаты багов, дергают разработчиков доп.вопросами, парализуя процесс фикса критов. Мой пример Помню как тащили гигантский проект и вышли на финал, где последние 3 месяца нужно было просто фигачить и дотаскивать. Тревожность менеджмента повышалась, все хотели заглянуть глубже в команду. Мы понимали, что если не защитить ребят от митингов и разговоров точно вылетим за сроки. В итоге, взяли удар на себя по паре раз в неделю устраивали чеки, синки и давали актуальный статус. Команда работала, никто не отвлекал, затащили💪 Нюансы закона Закон Брукса часто понимают слишком буквально и совершают ошибки. Моменты, о которых важно помнить: 1. Закон применим к *отстающим* проектам на *поздних* стадиях. Если вы только стартовали или находитесь на раннем этапе, масштабирование команды работает отлично. 2. Исключение закона - идеально изолированные задачи. Если вы можете выделить кусок работы, который вообще не пересекается с основным функционалом (например, ручная разметка датасета, перевод текстов интерфейса на другой язык), добавление людей реально ускорит процесс. 3. Ловушка «никогда не нанимай». Иногда добавить людей в горящий проект *нужно*. Да, краткосрочно сроки сдвинутся еще сильнее, и вы должны открыто сказать об этом стейкхолдерам. Но стратегически, если проект долгий, через пару месяцев эти новички втянутся и вытащат вас из ямы. Главное — не ждать от них чуда «здесь и сейчас». Итого Думайте, когда добавляете людей на поздних этапах проектах. Точно ли оно того стоит! P.S. Напишите в комментариях ловили ли на себе закон Брукса? #рекомендуетсяизучить