Всем привет!

Вчера меня добавили в подборку с классными тг-каналами. Её подготовил Счастливый тимлид.

Делюсь ссылкой на папку:
https://news.1rj.ru/str/addlist/eZP_QhLugbszZWVi

В основном, они про IT, очень много фронт-энда, что-то про управление.

Эскалация

Дело было в декабре прошлого года. Пришел ко мне релиз-менеджер Егор из соседнего микро-сервиса, просит отдать тестировщика Анвара в его команду. Мол, в сентябре шла речь о том, что переход состоится, когда у нас загрузка пойдет на спад.

Загрузка, естественно, и не думала спадать. Тем более в декабре.

Егор объясняет, что ему позарез нужен тестировщик, чтобы можно было протестировать и отдать функционал бизнесу. Но и я понимаю, что его уход очень больно ударит по производительности команды. Да и вообще у нас роман с Анваром: я влюблен в то, как он круто делает работу, он кайфует от того, что у нас и дока всегда есть, и разработчики пишут хороший код.

- Егор, я не могу тебе отдать Анвара, - отвечаю я ему, - поскольку без него мы не сможем качественно делать свою работу. Как твой коллега, я отлично тебя понимаю и мне очень жаль. Но добровольно отдавать его я не буду. Однако, вот тебе мой совет: сходи к нашему с тобой +1 и попробуй через него решить этот вопрос. Если он придет ко мне и скажет, Саша, отдавай Анвара, то я отдам в ту же минуту.

Так я лишился своего лучшего тестировщика в команде.

А как я мог иначе поступить? Обрекать свою команду на работу без хорошего тестировщика? Но и кидать Егора посчитал некрасивым.

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

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

А как вы относитесь к эскалации? Когда приходилось применять? Что вы чувствуете при этом?

#кейсы #советы

Сильные стороны слабых

У моего самого первого руководителя проекта Сан Саныча было множество талантов.

Один из них - способность видеть сильные стороны сотрудников и находить им наилучшее применение.

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

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

Мы ему сказали: "Сан Саныч, Игорь же откровенно слабый инженер. Зачем вы тащите его в команду?"

На что мудрый Сан Саныч говорил: "Да, он не ахти какой инженер, но он - идеальный чекер"

"Он же не умеет делать расчеты!- спорили мы с ним, - Как он может что-то проверять?"

"Вы ни черта не понимаете!, - спокойно улыбался Сан Саныч и объяснял нам, - У Игоря есть талант: если ему дать эталонный образец и сказать сравнивать задачи с ним, то он это сделает лучше вас всех. Да, он не поймет, почему возникло расхождение. Но зато он отловит все несоотвествия и всех блох."

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

Для меня это было уроком, усвоенным на всю жизнь: сильные стороны бывают разные и не всегда в прямом функционале. И в дальнейшем я много раз видел, как люди, которых считали "слабыми сотрудниками" в одной команде или проекте, раскрывались с лучшей стороны, когда им находили правильное применение в другой команде или проекте.

А как вас приятно удивляли другие люди?

#кейсы #прошлое_авиатора