Комментарии 20
Последнее время тенденция бизнеса схлопнуть пару, а то и тройку должностей в одного сотрудника.
Все это под соусом: Повышение эффективности команды (уже тошнотный рефлекс на эти слова).
Такое ощущение, что бизнес пересмотрел мульт Головоломка, и их воображаемые сотрудники стали Бинго-Бонго (помесь кота, слона и немного дельфина).
Почему в одного человека? В одну команду. Ну то есть ты можешь быть T shape специалистом с глубокой экспертизой в тестировании
T-shape специалист - это оксюморон и ахинея. По-сути, как правильно сказал stackjava, это стремление владельца бизнеса навесить на специалиста еще парочку обязанностей.
По-факту - вредительство. Спец либо развивается в одном направлении, либо развивается во множестве. Человек ограничен в способностях. При этом он в основной специальности не будет развиваться, а в смежных специальностях он все-равно не разовьется до уровня, приносящего пользу делу и прибыль владельцу. Но, поскольку жадный буржуй навесит на него еще пару обязанностей, специалист гарантированно завалит задачи, сорвет сроки, подведет команду, принесет убытки компании и навредит своей карьере.
Правильное поведение, к примеру java-разработчику на попытку навесить на него devops - "Я не знаю девопс (и знать не хочу), и не смогу гарантировать выполнение задач. Ищите девопсину.".
Выглядит как безапелляционное заявление, а не обсуждение. Если я все же ошибаюсь, то:
Конкретно в моем проекте T-Shape не работает. Но работает в соседнем https://habr.com/ru/company/qiwi/blog/699696/ - там не было буржуя который всех уволил и команды сверху. Мотивация была от самой команды
Если чел хочет сам что-то изучать - ради бога.
Но когда тебе говорят, у нас нет девопса, аналитика, тестера...
Да и зачем они нам ? Ты же разработчик.
Тебе проще без прослойки (аналитика) разговоривать с бизнесом и ставить себе задачи.
Тебе проще код вывести в прод, так как ты знаешь куда, по каким портам и зачем ходит твой сервис... Зачем тебе лишние вопросы от девопса?
Ты же сам проанализировал задачу и написал код, кто лучше тебя сможет протестировать? Зачем тебе лишние вопросы от тестера?
Да и вообще, представляешь, ты отвечаешь теперь не тупо за код, теперь ты отвечаешь за продукт от сбора и анализа до поддержки, мониторинга и масштабирования. Круто же!!!
Теперь ты не кодер, а разработчик продукта и несешь ценность нашим клиентам!!!
В моем продукте внешних тестов не очень много так как наружу торчит только API. Предположим что мы не пишем через BDD а для этого есть отдельный человек. 98% времени он будет заниматься ничем в продукте. При этом совсем без внешних тестов нельзя. А шарить одного тестера на 5-10 продуктов - он не будет хорошо разбираться сразу во всех продуктах чтобы прийти и написать нам сразу в спринт пару тестов
Аналогичная ситуация в моем продукте с фронтом - его очень мало. Пару платежных страниц и админок в которых редко кто мало что правит
"Я не знаю девопс (и знать не хочу), и не смогу гарантировать выполнение задач. Ищите девопсину.".
за такое можно словить клеймо токсика, нелояльного члена команды и человека, который не хочет развиваться.
.
Претенциозное название статьи, а по факту просто переименовали тестеров в разработчиков.
Скрам-Сектанты выходят в мир и понимают, что он другой!
У вас тестировщик не готов писать код? Ай-яй-яй ... А Java Backend не готов делать в frontend? Ужас-ужас ... Так зачем вы тогда в скрам пошли?
Вы сначала всех попытались подравнять в одну гребёнку (скрам-скрам), а потом решили, что будут все равны, но один будет равен в Java, другой в DevOps, третий в тестировании и т.д. На мой скромный взгляд, это есть возврат в команду с разными компетенциями: вот Java Backend разработчик (и он немного знает devops и аналитики), вот тестировщик и т.д.
По мне эта статья из разряда: мы знали слово "скрам", но слово нам не помогло и мы решили его изменить. И создали слово павлино-утко-ёж спирально-rad-инкрементный "другое". Во как! Ну что сказать: молодцы. То, что допилили модель разработки под себя - это отлично! Серьёзно, это ОТЛИЧНО!
Немного сарказма вдогонку: у вас реально одна из целей
Поставлять всё возрастающее количество качественных инкрементов
т.е. нам главное бежать всё быстрее и быстрее?
Идея, наверное, хорошая, и сделали, наверное, что-то неплохое, но донести мысли не смогли. Статья смазанная, понять что происходит и отследить логику сложно.
А где грань T-Shape? Front умеющий в инфраструктуру? Сетевой админ умеющий во фронт? А может быть системный аналитик умеющий в бек?
Обычно мы выбираем одну core компетенцию и еще 1-2 дополнительных для развития. Core компетенции определяются продуктом, а дополнительные уже командой с точки зрения повышения эффективности команды
T-shape == "Тот в шляпе". В общем, граней много, отсюда такое загадочное название этого ценного специалиста.
Интересная статья, спасибо, что опубликовали. А разработчики у вас пишут "простые кейсы и автотесты" или T-shape только в 1 сторону работает?
И ещё один вопрос возник: а почему когда билд не стартует - это проблема тестировщика, это тестировщик отвлекает глупыми вопросами команду, делая её менее эффективной? Вы не считаете, что девелоперы должны нести хотя бы такую ответственность за качество передаваемого кода, что могли бы гарантировать, что билд рабочий? По трудовым затратам это было бы более эффективно, чем кто-то, кто потом дебажит чужой код, потому что ничего не работает.
Если код прошол автотесты, довольно странно если билд совсем не рабочий. А то что прошол должно быть частью паплайна разработки и CI/CD. Но если не работает, то надо дополнять новыми тестами, в этом и есть ответственность разработчика.
Скорее простые автотесты, так как от тест кейсов в большинстве команд уже ушли. Сложные Е2Е кейсы все еще разрабатываются в паре с экспертом по качеству.
Про "про билд не стартует" это скорее история к локальной разработке, ведь на тестовом стенде все работает :-) Но в ситуациях, когда хочется "поднять локально", например для написания нативных тестов Playwright, могут вдруг выяснится "сюрпризы" и, согласитесь, классно когда человек догадается сперва открыть README и пройтись по шагам ;-)
Как работать с качеством в командах, где нет тестировщиков?