Логично :)
Но пока что получается что кризис менеджер = любой человек с полным карт-бланшем от владельцев бизнеса на любые действия по своему усмотрению.
Есть кар-тбланш = кризис менеджер начался, нет карт-бланша = ешьте коллеги кактус и пытайтесь договориться как-нибудь сами пока ситуация не усугубится достаточно сильно.

угу, так и есть)))

Я могу рассказать, по каким принципам я исправлял почту в Рамблере и в МВД. Здесь нет ничего сложного с точки зрения принципов.

не любой, а тот, кому реально доверились

расскажи :)
интересно же)

брат)) обычно тож все чиню, но в процессах))

доверие я включил в полный карт-бланш)

я скорее пытаюсь развернуть тезис в сторону того, что у человека должен быть релевантный опыт за который ему позволят этим заниматьсч

классика: СТО as a service -> вы же не возьмете просто парня с улицы?

кто сказал?

я сказал) особенно если мы говорим не про свою контору, а про чужую

Ну, или он должен уметь трендеть о своем опыте, тоже работает.

да, такой риск всегда есть 🙂

Ну, обычно именно так и получается (
Ще тут как раз редкое исключение

ну мы же с тобой знаем, что чаще всего не в технике проблема, а в коммуникациях. А таких людей вобще единицы

🙈ну ясно=понятно

+

Вот тут и начинаются нюансы :)
Возьмём абстрактного топ-менеджера завода, который создал крутое производство и заскучал, потому что всё хорошо работает.
Его опыт вроде как релевантен к опыты топ-менеджера из ретейла, или банка.
Он меняет свой завод, на допустим банк.
И тут сюрприз банк это не завод :)
И магия не происходит.
И делал человек по накатанной применяя свой опыт, и с головой вроде дружил, и даже вечеровал на работе, но результата всё не было :)

Сначала  — аудит системы, который надо провести самостоятельно. Из этого немедленно следует, что для проекта с продажными проблемами менеджер должен уметь в продажи. С продуктовыми — в продукт. С техническими — в технику. Если проблема сочетанная, нужно несколько разных людей, которые должны получить по направлению и работать вместе. Для чего написать общий план, что делается и в какую очередь. Всё вместе сделать не получится, поэтому надо договориться о компромиссе.

После аудита — план работ. Выкинуть всё, что не является необходимым. Например, если сервис работает нестабильно и через раз показывает 500, надо остановить разработку всех без исключения дополнительных фич и сфокусироваться на стабилизации сервиса.

Распространённая ошибка — слушать рассказы технической команды о том, что через 2-3-4-5 недель у команды будет релиз и он всё ну уащеффсё пофиксит. Не будет. Не пофиксит. Переезд на новую технологию даст лишь вторую головную боль.

Может оказаться так, что Уважаемый Гуру Проекта категорически против каких-либо действий. Тогда с Гуру прощаемся. Надо быть готовым и к тому, что с Гуру уйдут ещё 1-2 человека. Стараемся попрощаться без скандала и даже с бонусом, но если нет — идём до конца.

После того как сервис будет стабилизирован, пишем самый простой план работ на квартал и пытаемся научиться не продалбывать его.

В Рамблере весь план на полгода состоял в том, что мы научились релизиться раз в неделю и откатываться. В МВД суть плана — не падать по 12 раз на день, а довести максимум до одной аварии в сутки.

Вообще, чем планы проще и доступнее, тем лучше они воспринимаются и командой, и руководством. Да, может оказаться, что руководство хочет побед и свершений сразу. У меня такое было в VIP-service, когда просранный дизайн-проект надо было перерисовать и переверстать за 4 недели. Ну так чудес не бывает, и я оттуда уволился под вопли о том, что "мы тебя взяли всё исправить, а ты!..".

👍