Lead IT Project Manager
Параллельные структуры с одинаковыми задачами в крупных компаниях - не ошибка планирования, а штатный механизм селекции. Руководство специально создает внутреннюю конкуренцию, чтобы выявить наиболее живучие блоки.
Хорошие метрики сами по себе не защищают проект от закрытия. Бюджеты и штат часто перераспределяют в пользу тех подразделений, кот…
Многие сеньор-менеджеры засыпают в операционке. Если спустя годы вы все так же тушите пожары в спринтах и «выравниваете ожидания», то никакого роста нет. Вы просто очень дорогой диспетчер.
Рынку нужны те, кто масштабирует результат и урезает системные потери.
В больших структурах бессмысленно воевать с регламентами. 10 подписей для закупки железа или три месяца на комплаенс - такая же константа, как и налоги. Эти барьеры защищают бизнес от случайных решений, и они никуда не денутся.
Проекты в финтехе и гостехе вязнут не из-за «медленных юристов», а из-за того, что их инерция не заложена в архитект…
Считать «загрузку ресурсов» в часах - ошибка. В IT-системах время цикла (Cycle Time) нелинейно зависит от процента утилизации.
При приближении загрузки к 90% время ожидания задачи в очер…
В Amazon принцип Single-Threaded Leadership (STL) - это не про «одного ответственного», а про физическое отсечение альтернативных издержек.
Проблема большинства компаний: один лидер (или…
В Amazon ограничение WIP работает не на уровне задач в спринте, а на уровне запуска самих инициатив (сверху вниз, а не как привыкло большинство).
Для этого используют формат 6-pager и принцип Single-Threaded Leadership.
Когда в проекте отвечают на вопрос «когда будет готово», чаще всего называют средний срок. Но lead time почти всегда распределен с длинным хвостом: несколько задач живут намного дольше остальных и именно они как раз и создают риск. Среднее значение этот риск скрывает. Оно хорошо описывает прошлое, но плохо помогает прогнозировать будущее. Две коман…
Когда в проекте начинаются проблемы со сроками, то чаще всего смотрят на скорость или кол-во задач в работе.
Оба показателя полезны, но они плохо отвечают на главный вопрос: где именно поток начинает ломаться.
Когда в проекте отвечают на вопрос «когда будет готово», чаще всего называют средний срок. Но lead time почти всегда распределен с длинным хвостом: несколько задач живут намного дольше остальных и именно они как раз и создают риск.
Среднее значение этот риск скрывает.
Во многих проектах деградация сроков начинается не в delivery, а в upstream - в зоне формирования спроса и принятия решений. Запрос существует, обсуждается, учитывается в планировании, но до явного commitment point не доходит. В результате растет decision latency: решения откладываются, приоритеты размываются, а система начинает неявно резервироват…
В какой-то момент почти каждый PM открывает для себя закон Литтла и пытается понять, почему он не дает внятных сроков.
Команды любят говорить:
«Мы быстро закрываем задачи»