Всем привет!
Сразу хочу извиниться за некий "поток сознания" на тему, но действительно очень хочется разобраться и разложить все по полочкам с вашей помощью.

Итак, есть два распространенных мнения на этот счет:

1. Тестировщики являются полностью независимым подразделением в организации или, в лучшем случае, подчинены непосредственно менеджеру проекта в обход тимлида
   
2. Тестировщики являются неотемлимой частью проектной команды и подчинены тимлиду (в понимании этой роли, описанной Gaperton'ом
   Автор: Jonathan
   Дата: 01.06.08
   )

Приверженцы первого подхода аргументируют его тем, что, таким образом, обеспечивается полная независимость тестирования от давления менеджмента проекта ("сроки горят, давайте забъем на тестирование и зарелизим, что есть"). С другой стороны, при таком подходе не приходится говорить о кросс-функциональной команде, т.к. команда, по сути, разделена на два "лагеря" — разработчики и тестировщики, с сопутствующими конфликтами, перебрасыванием дерьма через стену и т.п., что отнюдь не в положительную сторону влияет на продуктивность и мотивацию в команде.

В случае же второго подхода получается полноценная кросс-функциональная команда, но остается риск давления на тестировщиков, особенно — в случае незрелого тим лида, только недавно выросшего из разработчиков.

Я являюсь ярым приверженцем кросс-функциональных команд в НЕортодоксальном смысле (т.е. обязательно содержащих представителей всех дисциплин разработки ПО, но без жесткого требования "все должны уметь делать все") и, поэтому, для меня подход №2 гораздо предпочтительнее. Но — пока не получается найти убедительные аргументы для высшего руководства. Высшее руководство, в свою очередь, склоняется к первому подходу по следующим причинам:

1. "Работает — не трогай" — т.е. в прошлом были проекты, которые вполне успешно делались по "классической" схеме. Хотя, были и очень показательные примеры недостатков такого подхода, вплоть до конфликтов, когда девелопмент лид и тест лид разговаривали между собой только через посредника
   
2. По моим личным ощущениям, высшее руководство, при всем моем к ним уважении, не совсем в курсе современных тендеций к формированию проектных команд (само-организация, отсутствие иерархии внутри команды). И если на само-организации я особо не настаиваю, т.к. не каждая команда к ней, увы, способна, то как минимум на "плоской" структуре команды (пм->тимлид -> все остальные представители всех дисциплин) настаиваю даже очень.
   
3. По моим личным ощущениям, предпочтение первому подходу отдается еще и из-за дефицита по-настоящему зрелых тим лидов, которые бы понимали, что на программировании разработка ПО не заканчивается.

Может быть, сообщество что-то подскажет? Возможно, существует какая-то третья, гибридная модель, о которой я не подозреваю, и которая хорошо зарекомендовала себя на практике?