Почему-то постоянно встречаю такое мнение, что если специалист T-Shaped, то это бедный человек-оркестр, которого использует работодатель. Например, в стартапе, когда мало инвестиций, вместо большой команды один человек исполняет роль разработчика, тестировщика и аналитика.
Также и в крупных, уже развитых проектах, например, из-за нехватки узконаправленных спецов, задачи на себя берут другие члены команды.
Почему-то мало кто это рассматривает с другой стороны. Я как бывший разработчик, например, четко понимаю, что для того, чтобы настроить гарантированную доставку на очереди, необходимо установить такие-то конкретные параметры в конфиге очереди. Будучи исключительно аналитиком я бы мог добраться до этих знаний, но что-то сомневаюсь. Для чего это нужно? Чтобы, например, сэкономить время разработчику на поиск и разбор что вообще нужно сделать.
Наверное, пример выше не лучший, но вот пример интереснее. На прошлой своей работе, я как-то ставил задачи фронт-разрабам. Там были не очень заинтересованные в наших задачах коллеги, поэтому каждый раз они выдавали какие-то конские сроки на каждую задачку/доработку. Я же, как бывший фронт-разраб, четко осознавая необходимый пласт работ, сокращал сроки иногда с недели до 4ч.
Про более крутое понимание того, как работает код со всеми его распределениями на потоки и тд, как непосредственно работает REST/очереди/обращение в бд не на словах или теории, а на практике – я вообще молчу.
Рекомендую всем аналитикам попробовать сделать какой-нибудь простой pet-проект, затестить все используемые(и не только) технологии. Как минимум для вас это будет интересный опыт.
Это я все к чему? Смотрите шире, быть T-Shaped полезно далеко не только вашему работодателю, а еще и вам самим. Расширение компетенций вне вашего профиля позволяет видеть многие задачи и процессы под другим углом, повышая эффективность и погруженность в них.