Ситуацию эту я понимаю, но принять ее не могу (и это притом, что лично мне переквалифицироваться не приходилось - я лишь наблюдал этот процесс со стороны). Чтобы определиться со своим отношением к этому вопросу, я решил рассмотреть, как трактуют кроссфункциональность за пределами нашей уютной компании.
В общем смысле под кроссфункциональной командой подразумевается объединение (объединение и только) в одной команде людей разных специализаций - в противовес гомогенным командам, объединяющим людей одной специальности (отдельно программисты, отдельно тестеры и т. д.)
Agile-методологии пропагандируют создание кроссфункциональных команд. И это, на мой взгляд, прекрасно (хотя и не дается даром). Однако интересно, что в agile к кроссфункциональности неназвязчиво примешивается взаимозаменямость. Здесь я позволю себе процитировать Хенрика *наше все* Книберга:
Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.
Выходит, в контексте agile кроссфункциональной должна быть не только команда в целом, но и каждый ее член (до определенной степени). Причем, как мне кажется, кроссфункциональность/взаимозаменямость членов команды вытекает не только из кроссфункциональности команды, но и из других принципов agile вроде team committment и общего codebase. Хотя, очевидно, есть некоторая грань (редкий тестер сможет выполнять работу пиарщика), которая индивидуальна для каждой команды и от которой зависит вердикт по исходному кейсу.
Интереса ради, я решил узнать мнение о рассматриваемом кейсе на programmers.stachexchange.com. Ожидаемо, мнения разделились: от
Yes, it is normal for developers to become testers if it is required to get the work done for an iteration
до
I don't think developers being testers fits the cross-functional definition. That seems more like a jack-of-all-trades type scenario where developers also test, take sales calls, go out and buy coffee to restock the office, etc, which may be typical in a startup. A cross-functional scenario seems more like a situation where, for instance, you might be a developer, and I might be in marketing, but we're working together as a team to build and market the product.
Подводя итоги, могу сказать, что несмотря на проведенный самоликбез, качественно мое мнение не изменилось: при всей рациональности кейса, в гробу я видал такую кроссфункциональность :) Нет, я бы пошел на это ради команды, но если каждая минута, проведенная за программированием, делает меня чуточку счастливее, - рутинное тестирование по тестпланам будет вгонять меня в уныние (стоит ли говорить, что это влияет на эффективность и качество?).
6 комментариев:
Вот этот топик отхватил бы на хабре комментариев, в отличие от предыдущего :)
"Кросс-функциональность" - она ведь разная бывает. Меня вот, например, используют как админа временами, я и не против. В случая тестинга просто это явный "даунгрейд".
Ну и отношение к сабжу очень зависит от природы конкретного случая.
Одно дело, когда это внезапно и краткосрочно (надо хорошо оттестить небольшую область) - тогда это воспринимается нормально. Обычно в этих случаях и тестплана нет, так что "творчества" больше, ну и занимать это должно день - максимум.
А другое - когда это происходит под планируемую и долгосрочную операцию (собственно, квали). В таком случае это выглядит менеджерским факапом и забиванием гвоздей микроскопом. Типа - планировали бы заранее, набирали людей (внештатников привлекайте на такие случаи итп) и было бы всё нормально.
Насчет Хабра ты прав - здесь есть, что обсудить. Но прежде чем идти на Хабр, нужно доработать статью.
В целом, с твоими мыслями согласен. Единственное, я бы не сказал, что ситуация в случае квали - однозначный факап. Все-таки в этом есть смысл, ведь брать на квали внештатных тестеров - довольно проблематично.
Да факап, факап.
Все квали более-менее одинаковые. Значит, ситуация что в одной конкретной квали проблемы с персоналом - факап.
Если же проблемы во всех квали, и их всегда решают переквалификацией прогеров - это забивание гвоздей микроскопом, а таковое забивание априори должно быть компании невыгодно (прогеры дороже тестеров). Если менеджеры делают что-то невыгодное для компании - это факап.
Ну и собственно - почему внештатные тестеры на квали - проблематично? Если договариваться с одними и теми же людьми, но не на постоянную, а на временную периодическую работу. Они и в продукте будут разбираться тогда. Ну и особо выдающихся - в штат.
Насчет стоимости тут тоже тонкий момент. Мы с Shaddix'ом коллеги, но для тебя, мой дорогой читатель, я поясню ситуацию. Мы работаем в томском филиале немецкой компании. Основной тестовый отдел находится в Германии. И ввиду разницы в уровнях жизни томские программисты стоят дешевле немецких тестеров. А значит временно переквалифицировать томского программиста в тестера дешевле, чем нанять временного немецкого тестера. К тому же временные работники в Германии оплачиваются по более высоким рейтам. Так что аргумент насчет дешевизны тестеров по отношению к программистам в нашем случае не актуален. Хотя я точно помню, что как-то в тестеров переквалифицировали немецких менеджеров проектов, а вот это уже дороговато, да.
Теперь насчет второго абзаца. Фишка в том, что очень сложно брать на временную работу одних и тех же людей. А брать же новых на время квалификации опасно и не очень-то целесообразно: входной порог неслабый.
Так вот мы и приходим к источнику проблемы - проблема не в том, что ты не хочешь быть кроссфункциональным, а в том, что ты не хочешь делать менее квалифицированную с твоей точки зрения работу. Книберг при рассказе о кроссфункциональности, конечно, приводит в пример "тестирование", но, как ты понимаешь, в каждой компании под "тестированием" понимаются очень, очень разные вещи, совершенно необязательно предполагающие более низкую квалификацию тестировщика (поэтому, кстати, на хабре топик бы превратился в бесполезный холивар, т.к. каждый судил бы со своей колокольни). Тот же Книберг в некоторых примерах рассматривает кроссфункциональность на примере dba<>кодер, типа вполне возможно, что в команде есть четкая специализация, но кодер должен при случае быть в состоянии подбашить. Представь, у нас бы была специализация vb.net<>vb6?
ну и пара замечаний по поводу именно нашей компании :)
1. временный тестер в Германии возможно дешевле тебя в Томске (студентам платят очень мало).
Т.е. это (томский программист дешевле немецкого тестера)- не аргумент, я тебя уверяю.
2. немецкие менеджеры тестили скорее для расширения кругозора и вникания в предметную область ну и просто от нефиг делать.
bip, согласен, все так.
Разве что насчет цены поспорю. Все-таки в общем случае временным работникам платят гораздо больше, чем постоянным (оно и понятно). Другое дело студенты, да. Но много ли от них толку в квалификации? Во-первых, их нужно сперва обучить, а, во-вторых, на полную ставку они работать не смогут.
Отправить комментарий