🔥 Самые интересные (ну или просто норм) публикации по управлению проектами за 11–18 октября (1)

🤵 10 лет растил команды — и не прохожу фильтр на управленческий опыт Формально это история карьеры руководителя, но внутри получился разбор нескольких управленческих ловушек. Автор строил межфункциональные команды, выращивал руководителей, занимался требованиями, продуктом и поставкой и несколько раз попадал в ситуацию “ответственность за результат есть, а возможности изменить процессы, от которых результат зависит, нет”. Показывает разницу между локально успешным опытом и устойчивым изменением организации: можно собрать отличную команду и доказать, что новый способ работы эффективнее, но если он существует только благодаря договоренности с конкретными руководителями, смена руководства спокойно отменит всё обратно.Важно: изменить процесс и изменить культуру — разные задачи. Если сама организация не хочет обсуждать проблемы, хороший метод и сильный руководитель сами по себе не спасут.

🍻 Ни зарплат, ни отпусков, ни больничных. Зато есть User Story и Merge Request: как AI-агенты работают у меня в Jira Что происходит, когда цифровых исполнителей не просто держат в отдельном чате, а встраивают в обычный рабочий процесс команды. Автор создал для них роли аналитика и разработчиков и назначает им задачи в Jira так же, как людям. “Аналитик” читает документацию, задает уточняющие вопросы и готовит требования; “разработчики” меняют код, запускают проверки и передают результат человеку на просмотр. Если раньше команда получала один результат на проверку в день, а теперь машина способна принести тридцать, так что узким местом становится уже не разработка, а способность людей проверить сделанное.

😭 Почему тимлид не может сказать, сколько команда сделает в следующем спринте, и как я это посчитал Очень практический материал про то, почему план “в прошлый раз сделали 300 баллов — значит, и сейчас сделаем 300” почти бессмыслен. В одном цикле кто-то был в отпуске, в другом появился новичок, в третьем треть времени ушла на ошибки и поддержку. Автор предлагает считать не результат команды за период, а результат на эффективный человеко-день, с учетом отсутствий, загрузки на поддержку и реальной готовности новых сотрудников. Но самая интересная мысль — переработки нельзя записывать в нормальную производительность. Если команда три дня сидела допоздна и благодаря этому выполнила план, а мы используем этот результат для следующего планирования, то просто узакониваем аврал.

🤐 Разработка перестает быть главным дефицитом. За что теперь будут платить в IT? Десятилетиями одной из главных проблем ИТ было то, что хороших идей больше, чем возможностей разработчиков. А теперь производство программ постепенно ускоряется, и внезапно выясняется, что очередь действительно ценных идей вовсе не бесконечна. Значит, узкое место переезжает: уже недостаточно хорошо распределять ограниченный ресурс разработки, всё важнее правильно выбирать, что вообще стоит делать. Причем плохую идею теперь тоже можно реализовать быстрее — и потом столь же бодро тратить деньги на ее поддержку. Хороший текст о том, как удешевление одной части работы меняет ценность всех соседних ролей.

⚠️ Полигон гипотез: как понять, что я не сделаю бесполезную фичу? Три красивые продуктовые гипотезы прошли исследование, выглядели убедительно, затем съели  работу нескольких команд и бюджет на продвижение - и не подтвердились. После этого автор собрал систему, которая еще до запуска ищет слабые места в исходных предположениях: на чем держится гипотеза, можно ли полученными данными вообще ответить на нужный вопрос, не опираются ли несколько предположений друг на друга.