🔥 Самые интересные (ну или просто норм) публикации по управлению проектами за 11–18 октября (2) ++ ⭐️++ Сколько разработчиков может вести тимлид: 7 ошибок при росте команды Команда выросла с 6 человек до 12, а руководитель продолжает работать так, будто ничего не изменилось (пишет код, проверяет изменения, принимает финальные решения и остается главным носителем знаний). В итоге очередь растет уже не у разработчиков, а у самого начальника. Автор не пытается вывести магическое число типа “руководитель может управлять ровно семью людьми”, ибо всё зависит от зрелости сотрудников, сложности работы и тд. Но после определенного размера команды прежняя модель действительно перестает работать. Главная мысль: при росте команды нужно проектировать заново не только структуру команды, но и собственную должность. То, что было сильной стороной начальника на шести людях, на двенадцати легко становится главным ограничением всей системы.

💪 Самый дорогой источник потерь в проектах, о котором никто не говорит Автор начинает с Mars Climate Orbiter, который NASA потеряла из-за того, что две команды использовали разные единицы измерения. Причем обе считали правильно. Ошибка возникла не внутри работы специалистов, а на стыке между ними. Дальше эта история переносится на обычные проекты: требования передали, но не сверили понимание; проблема обнаружилась, но осталась в переписке; у результата передачи между подразделениями вообще нет владельца. Всё это выглядит как работа, люди заняты, отчеты идут — поэтому потери почти невидимы. А потом появляются ожидание, повторная работа, выгорание, незапланированные подрядчики и сдвиг экономического эффекта. В управлении проектами почти никто системно не считает стоимость плохой координации, хотя именно она регулярно съедает больше всего времени.

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

🚬 Карта автономии AI: как решить, что агенту можно делать без человека Текст предлагает обсуждать не «насколько умна модель», а каждое конкретное действие: прочитать данные, подготовить предложение, изменить запись, отправить сообщение, удалить и тд. Потому что цена ошибки и возможность ее отменить у них совершенно разные. Получается несколько уровней самостоятельности: от простого совета человеку до действия в заранее установленных границах. 90% точности ничего не говорит о допустимости автоматизации, пока мы не знаем цену остальных 10%. До передачи действия машине нужно определить худший реалистичный исход, владельца риска, способ остановки и восстановления.

❓ Внедрение проектного офиса: проектный, управленческий и продуктовый подходы Про создание проектного офиса - с 3 сторон. 1) это обычный проект: есть сроки, ресурсы и конкретный первый результат. 2) новая управленческая функция, а значит, офис должен иметь реальные полномочия влиять на правила принятия решений, иначе получится просто фабрика отчетов. И, наконец, 3) это внутренний продукт для руководителей и команд: его шаблоны, правила и услуги должны кому-то реально помогать, а не существовать потому, что «так положено». Отсюда подход к запуску: не пытаться сразу внедрить идеальную систему из всех возможных процессов и документов, а начать с минимального набора, который решает конкретную проблему бизнеса.