Записки тимлида
с 2024
Рассказываю про опыт применения собственных практик, а также практик, которые были реализованы в других командах.
1 подписчик
1 подписка
Закину и свой ТГ канал, в котором рассказываю про свой тимлидовский опыт и делюсь интересными практиками :)
https://t.me/teamlead_stories
M-shaped специалистов редко встретишь, и как правило, такие люди должны занимать руководящие должности. Каждый специалист важен, и команду надо собирать из специалистов разного калибра.
Данные принципы существуют для оценки своего текущего положения в этой структуре и понятию того, в каком ключе дальше развиваться. L - shaped специалисты тоже очень полезны, так как знают про свою специфику больше других.
Согласен, но частично.
Ваш пример доказывает факт того, что на самом деле все завист от ситуации и контекста:)
Если на проекте нужен пахарь и дока есть, то сиди и делай. С правильной архитектурой, с нормальным кодом и т.д. и т.п. Такой сотрудник гораздо полезнее человека с софтами и более слабыми хардами.
Но есть и другие ситуации. Когда софты важны не только аналитикам, тестерам и манагерам, но еще и разработчикам.
Когда доки раскиданы непонятно где, когда проекта не на 10-12 человек, а на 50+ (и это только со стороны разработки) и сложно найти центральную фигуру, которая ответит на все вопросы.
В таких ситуациях очень нужны сотрудники у которых хорошие софты, так как им придется общаться и очень много.
Возвращаясь к вашему примеру, то можно нанять крутого стажера, который копает по 2км в день, но в момент проверки, оказывается, что копал он не в ту сторону:) Ну или кидал землю в левую сторону, а там копает другой, из-за чего мешал остальным.
Ведь достаточно же было просто пообщаться с коллегами, правда?:)