“Да, нужна”, — заявляет автор и хочет реабилитировать проектную документацию после многолетней борьбы с мега-ТЗ, архивами из Excel-файлов и инструкциями, которые никто не читает. Предложение — начинать с минимального набора: цель проекта, участники, ключевые процессы, решения, вопросы, риски и ссылки на источники актуальной информации. Документация здесь нужна прежде всего, чтобы команда не восстанавливала контекст заново при каждом изменении. Еще — принцип постепенного восстановления: если на проекте хаос, не нужно останавливать всю работу ради создания идеальной базы знаний — достаточно документировать наиболее рискованные и часто используемые участки по мере движения. В целом, посыл такой: полезность документа определяется не объемом и красотой шаблона, а тем, помогает ли он кому-то принять решение или выполнить работу.
Кто отвечает за сбой: четыре роли, которые руководителю нельзя путать
Вот возник инцидент — и задача часто автоматом достается или тому, кто первым заметил проблему, или самому компетентному специалисту. Но ведь ни один из них не обязан быть владельцем всей ситуации. И автор предлагает разделять 4 роли: обнаруживший фиксирует сигнал, стабилизатор ограничивает ущерб, эксперт предоставляет знания, а владелец ведет инцидент до закрытия. Совмещать роли можно, но это должно быть осознанным решением, а не, как бывает, “раз уж начал, доведи до конца”. Но выводы шире темы инцидентов: участие в задаче, экспертность и ответственность за конечный результат — разные вещи, а их смешение, увы, перегружает самых активных людей.
Упс! Автоматизация не взлетела((( Как бизнес устраивает охоту на ведьм
Про иллюзию, что достаточно купить новую систему, подключить AI или нанять внедренцев, — и бизнес начнет работать правильно. На практике автоматизация чаще, наоборот, закрепляет проблемы, но в более дорогой и менее гибкой форме. И конечно, после неудачи начинается поиск виноватых: руководство обвиняет исполнителей, те — пользователей, пользователи — неудобную систему. При этом на самом деле проблема могла находиться в отсутствии владельцев процессов и/или согласованных правил работы. Рецепт автора: оценивать готовность компании нужно рано, до выбора инструмента — по качеству процессов, данных, ответственности и способности руководства участвовать в изменениях.
Материал предлагает делать это не по стоимости часа и впечатлению от портфолио, а по способности управлять сложным контекстом (втч интеграциями, безопасностью, архитектурой, требованиями разных подразделений и изменениями после запуска). Хорошим сигналом будет, если подрядчик сначала уточняет исходные данные и границы проекта; плохим — если немедленно обещает точный срок, не называет состав команды и забивает на документацию. Отдельный блок посвящен зависимости от исполнителя: доступ заказчика к репозиториям, инфраструктуре, проектным решениям и документации должен появляться во время работы, а не в момент болезненного расставания. Для крупных проектов автор рекомендует поэтапную поставку с контрольными точками вместо одного длинного контракта, результат которого впервые показывают почти перед запуском.
Чем больше метрик, тем меньше контроля
Delivery-менеджер рассказывает, как компания попыталась сделать проекты прозрачнее с помощью OKR, финансовых показателей и time to market, но получила, хе-хе, еще менее достоверную картину. Менеджера назначили ответственным за сроки, производительность и деньги, не дав ему полноценного доступа к работе команд и достаточных полномочий менять процессы. Когда показатели стали влиять на загрузку, статус и сохранение места в проекте, сотрудники быстро научились показывать безопасные цифры: сильные перестали демонстрировать реальную производительность, а проблемные участки стали скрываться внутри благополучной отчетности.
Трижды в топ-3 финтеха: 6 потерь эффективности, которые мы устранили, чтобы быть среди лучших
Команда ПСБ — о том, что рассматривает разработку как производственную систему и якобы ищет не способы заставить людей работать быстрее, а работу, которую вообще не стоило выполнять (звучит как мечта). И вот от чего они отказались: каскадные изменения зависимых компонентов, переписывание работающего функционала, дублирование решений разными командами, недостаток информации о состоянии системы, стоимость поддержки и лишние коммуникации. Особенно интересен отказ от рефакторинга как безусловного блага: техническое улучшение имеет смысл только тогда, когда решает конкретную проблему и его эффект превышает цену изменений, тестирования и последующей поддержки.
AI против Agile: что изменилось за последние два года
Вопреки ожиданиям, тут не очередной рассказ про смерть аджайла. Аджайл жив. Но автор показывает, какие обслуживающие процессы вокруг него постепенно дешевеют благодаря AI. Модель может собрать статусы и блокеры перед планированием, подготовить черновик user story, расшифровать встречу, выделить договорённости, предложить декомпозицию и найти повторяющиеся причины переноса задач. В результате меньше времени уходит на ручное восстановление истории спринта, а больше — на обсуждение рисков, исключений и решений. Главный вывод — AI может обработать информацию, но не принимает на себя ответственность, не разрешает конфликт интересов и не определяет стратегическое направление продукта.
Почему хороший PM во многом действует как тренер — и наоборот
Такая вот необычная(?) аналогия: руководитель проекта, подобно тренеру, обучает команду и заказчика работать по-новому. Проектные артефакты в таком случае становятся учебными материалами — а значит, их нужно сокращать, снабжать примерами и типичными ошибками, а не превращать в архив нормативных текстов. Команда некоторое время будет следовать нововведениям, а затем начнет возвращаться к старой практике, поэтому нужно организовать повторные касания и сбор обратной связи. Получается такой ритм внедрения: объяснить цель правила, позже напомнить его основные пункты, а затем обсудить на ретроспективе, что помогает и что мешает.
Ловушка для ума разработчика №3: почему самые надёжные инженеры остаются без поддержки
Про парадокс сильного сотрудника: чем реже человек жалуется и чем увереннее говорит “разберусь”, тем меньше внимания руководитель уделяет его загрузке и состоянию. На таких специалистов постепенно всё вешают — сложные участки, срочные проблемы и неформальную ответственность за результат, пока внешняя надёжность не заканчивается неожиданным увольнением. А руководитель при этом может искренне считать, что помогает тем, кто просит о помощи, забывая, что самые самостоятельные сотрудники обычно просят последними. Вывод здесь шире темы выгорания: отсутствие эскалаций не означает отсутствие риска, а стабильный результат может быть следствием скрытого перерасхода ресурса, который нигде не учитывается.
Почему скорость специалиста нельзя переносить на другого исполнителя
В этом кейсе заказчик видел простую аналогию: похожую доработку уже сделали за 40 часов, следовательно, новая должна стоить примерно столько же. Но первый специалист давно знал код, архитектуру, историю решений и людей, у которых можно быстро получить ответы, а второму требовалось сначала восстановить весь этот контекст. Текст хорошо показывает невидимую часть оценки: до первого изменения кода исполнитель изучает связи, права, исключения, соседние процессы и прежние компромиссы — и общий профессиональный опыт не отменяет незнания конкретной системы. И да, на второй и третьей похожей задаче скорость должна расти, а повторное изучение уже найденной информации указывает на другую проблему. В общем, если заказчик предъявляет вам такой аргумент, то нужно не отвергать прошлую цифру, а разобрать условия, при которых она была получена, а потом уже назвать добавившуюся работу.
ссылка на оригинал статьи https://habr.com/ru/articles/1068034/