🔥 Интересные публикации по управлению проектами за 23-31 октября (1)

🍑 Черный октябрь "Яндекса": анатомия архитектурной и управленческой катастрофы, которую списали на форс-мажор Да, куда же без этого. За четверо суток в октябре из строя вышли три дата-центра "Яндекса", облако легло, финтех-подразделение провело 11 дней в ручной сверке балансов. Удобно списать всё на форс-мажор, мол, ни одна архитектура такого не выдержит. Но вот автор препарирует поминутную хронику и показывает: между потерей первой и второй зоны доступности прошло 74,5 часа, то есть время на спасение системы было, но им не воспользовались. Физическое поражение площадок стало лишь триггером, а масштаб катастрофы- следствием просчётов в управлении мощностями и оценке рисков на уровне высшего руководства. В общем, если у вас есть план на случай аварии, который никто не репетировал и не проверял на реальном сценарии,- это ерунда, а не план.

👀 Метрики команды врут поодиночке или почему теперь я смотрю их парами Автор начинает с прекрасного результата: время до первой проверки изменений сократилось с 6 часов до 36 минут. Только потом выяснилось, что дефектов после выпуска- в 2,6 раза больше. Отсюда идея: почти любой показатель команды опасно читать отдельно. Скорость проверки нужно смотреть вместе с размером изменений и качеством, время выполнения- с количеством одновременно начатой работы, процент успешных выпусков- с самим числом выпусков. Хороший пример, когда рост ошибок на 65% сначала хотелось лечить ужесточением проверки кода, а настоящая причина оказалась... ну конечно же, в плохо подготовленных требованиях и нереалистичном планировании.

😮 Первые 30 минут руководителя проекта, или как обнаружить проблемы до того, как они сорвут сроки Про полезную привычку РП не начинать день с разгребания почты (или чатов, что там у вас). Сначала полчасика подремать посмотреть на проект целиком: какие задержки действительно способны сдвинуть конечный срок, не исчез ли запас времени, где возникает конфликт за дефицитного спеца, где нужно управленческое решение. Проблема обнаруживается не тогда, когда инженер уже нужен двум руководителям одновременно, а когда это противоречие видно в будущем плане. И в целом, менеджер проекта нужен не для того, чтобы быстрее всех отвечать на сообщения (эх, жаль), а чтобы раньше других увидеть последствия.

😐 Первый проект Process Mining: как выбрать процесс для оптимизации, собрать команду и не застрять на этапе пилота Инструкция по первому проекту процессной аналитики. До старта предлагается определить несколько конкретных вопросов к процессу и выбрать участок, где есть и доступные данные, и измеримый эффект, и владелец, готовый потом что-то изменить. Потому что построить красивую картинку as is- еще не результат. Один из показателей успешности опытного запуска у авторов прямо так и сформулирован: принято ли хотя бы по одной найденной проблеме решение об изменении процесса. Если нет, команда просто произвела еще одну презентацию. Еще есть рекомендация заранее проверить качество истории в исходных системах: есть ли даты смены состояний, сквозные идентификаторы и достаточная глубина данных и прочие нужные штуки.

😊 Куда уходит зарплата разработчика: как мы приоритизируем бэклог и связываем задачи с бизнесом Или о том, как перестать выделять место в плане тому, кто громче всех попросил об этом. Коллеги из Аспро сначала сравнивали задачи по единому правилу, но довольно быстро поняли, что это не поможет им куда-то двигаться. Поэтому задачи связывают с направлениями и конкретными показателями, а после выпуска проверяют, произошло ли ожидаемое изменение. Еще хорош кусок про срочные работы. Они выглядят бесплатными (“ну добавили небольшую задачу, всего-то”). На деле она прерывает постановщика, разработчика, проверяющего и вытесняет что-то уже запланированное. Поэтому под такие работы заранее выделяется часть мощности команды, а на очередную срочную просьбу задается прекрасный вопрос: "Хорошо. А какую уже запланированную задачу мы ради этого не сделаем?". По словам автора, после него половина срочного внезапно перестает быть срочной.