Привет! Меня зовут Гульдар Ахунзянова, и я тестировщик в Яндекс Смене. В статье хочу рассказать о теме, которая может показаться банальной: как превратить рабочий хаос в управляемый порядок. Но за этой банальностью скрывается важная мысль: если вы тестировщик, у вас есть реальный инструмент, чтобы сделать жизнь (и свою, и команды) проще, понятнее и предсказуемее. И этот инструмент — процессы.

Когда процессы прозрачные, команде легче работать, бизнесу — принимать решения, а вам — сохранять здравый рассудок в условиях постоянных изменений. Меньше неясностей — меньше хаоса.

Одна из ключевых зон ответственности в нашей профессии — раннее тестирование. Чем раньше мы начинаем задавать вопросы и проверять гипотезы, тем меньше хаоса ждёт нас в конце. Ошибки, замеченные на старте, обходятся дешевле, исправляются быстрее и предотвращают лавину проблем на поздних этапах.

Эта статья будет полезна всем, кто так или иначе сталкивается с тестированием в процессе продуктовой разработки: ведь грамотная коммуникация внутри команды и ясное распределение зон ответственности напрямую влияют на успех продукта. В первую очередь она помогает заглянуть внутрь рабочего процесса тестирования — понять, как он устроен изнутри. Особенно, я думаю, текст откликнется тем, кто уже вышел из‑под крыла наставника и перешёл к самостоятельному ведению крупных задач и проектов — или только планирует взять на себя больше ответственности.

Мы разберёмся, почему стоит тестировщику вникать в задачи в момент проектирования и как раннее тестирование помогает минимизировать риски прорастания критических багов на продовую среду и сокращать время самих проверок.

Классические модели тестирования

У каждой команды, даже внутри одной компании, могут быть свои договорённости и процессы. Разные жизненные циклы разработки, разные подходы — и, казалось бы, универсальных решений не существует.

Каждый начинающий тестировщик знает о классических моделях жизненного цикла разработки ПО: каскадной, инкрементной, итеративной и их адаптациях. Давайте освежим их в памяти.

Рассмотрим каскадную модель. По учебникам, в ней невозможно раннее тестирование: оно начинается только после завершения разработки, что создаёт серьёзные риски. На этапе планирования нельзя предусмотреть всё, а значит, ошибки обнаруживаются поздно, когда их исправление обходится дорого.

Сейчас в разработке чаще используют итеративную (разработка идёт спринтами) и инкрементную (продукт создаётся частями) модели. Они гибче, но даже здесь не всегда понятно, когда тестировщикам лучше всего включаться в процесс.

Современное тестирование — это уже не просто проверка функциональности по одной конкретной задаче. Оно начинается гораздо раньше: с изучения архитектуры проекта, анализа требований, понимания ограничений и возможностей реализации, а затем — с непосредственного тестирования и документирования. В разных моделях жизненного цикла ПО анализ требований может начинаться на разных этапах. Так когда же подключаться к процессу, чтобы это действительно было вовремя и приносило наибольшую пользу? В этой статье я хочу сосредоточиться на понятии «раннее тестирование» и показать, как такой подход помогает продукту быстрее и качественнее доходить до пользователей.

Что такое раннее тестирование

Раннее тестирование — это не просто проверка кода на первых этапах. Это участие тестировщиков в анализе требований, проработке сценариев, создании тест‑кейсов ещё до написания кода. Это позволяет находить потенциальные ошибки до их появления, предотвращать дорогостоящие доработки и улучшать качество продукта с самого начала.

Из своего опыта я бы сформулировала понятие раннего тестирования так: это возможность подключаться к задаче с момента рождения идеи. Под этим я понимаю участие в грумингах, планировании, технических созвонах, вычитке тикетов и ознакомлении с дизайном — ещё до того, как задача передаётся в тест.

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

Кроме того, тестировщик может на этом этапе подсветить риски реализации всего релизного бэклога: оценить совместимость задач в спринте, их влияние на систему в целом и предложить приоритизацию — от сложных к более простым в реализации.

Технические встречи — это точка самого плотного взаимодействия между разработкой и тестированием. Здесь тестировщик работает напрямую с разработчиком, а при необходимости подключается продакт‑менеджер — особенно если возникают сомнения в едином понимании ожидаемого результата. Основная задача тестировщика в этом контексте — убедиться, что техническая реализация соответствует продуктовой идее и остаётся оптимальной с точки зрения качества.

Если с техническими обсуждениями и планированием всё более‑менее понятно, то груминг, на мой взгляд, остаётся самым недооценённым инструментом. А зря — он действительно упрощает разработку и сокращает время доставки фичи. Именно через груминги на практике раскрывается суть раннего тестирования.

Груминг — это этап, на котором новая идея начинает обретать технические очертания. На таких встречах обсуждаются общая логика, возможная архитектура, потенциальные сложности. В разных моделях жизненного цикла ПО груминг может выглядеть по‑разному: например, в итерационной модели его проводят раз в спринт, обсуждая список бизнес‑идей, а в инкрементной — по мере поступления задач, вне зависимости от спринтов.

Как правило, на груминге обязательно присутствуют продакт‑менеджер и разработчик: один приносит бизнес‑контекст, другой — технические детали. И тут возникает вопрос: зачем на этих встречах тестировщик?

Ответ — в его особом фокусе внимания. Разработчик видит реализацию, продакт — ценность, а тестировщик — риски, уязвимости и граничные случаи. Чем раньше он подключается, тем меньше шансов, что на финальном этапе появятся баги из‑за недопонимания. А значит — меньше правок, быстрее релиз и спокойнее команда. По моему опыту, именно в грумингах заключена настоящая сила раннего тестирования.

Применительно к нашим моделям разработки схема будет выглядеть так:

В гибких моделях разработки старт тестирования зависит от договорённостей внутри команды: он может происходить как на самых ранних этапах, так и непосредственно перед началом ручной проверки. В этой статье я хочу отдельно остановиться на том, почему имеет смысл начинать тестирование уже с этапа грумингов.

Это особенно важно для тех, кто развивается в профессии тестировщика. Груминги — это встречи с ограниченным кругом участников: обычно от команды разработки присутствуют один‑два человека из разных направлений, от тестирования — кто‑то из старших специалистов. Именно поэтому груминги становятся отличной возможностью для роста. Здесь можно проявить инициативу, взять на себя больше ответственности, поработать с требованиями и рисками на раннем этапе — и тем самым прокачать как технические, так и коммуникативные навыки, которые необходимы на более высоком грейде.

Зачем нужен тестировщик на грумингах, или Почему без него страдает деливери 

Из собственного опыта могу сказать: как только тестирование исключают из обсуждения новых задач, деливери начинает сбоить. Не сразу и не катастрофически, но устойчиво. Появляются баги, задержки, лишние итерации. Качество проседает, а команда делает шаг назад. Причина простая — на этапе зарождения идей пропадает критический взгляд.

На грумингах зона ответственности тестировщика — это далеко не только тест‑кейсы и покрытия. Это трезвая оценка самой идеи: насколько она реализуема, как она впишется в текущую архитектуру, где потенциальные риски и какие подводные камни можно обнаружить заранее.

Вот несколько причин, почему участие тестировщика в грумингах — не дополнительная опция, а стратегически важная часть процесса:

  1. Тестировщик знает о продукте больше, чем кажется. Парадоксально, но часто тестировщик лучше ориентируется в поведении продукта, чем разработчик. Не в коде, а в сценариях: как пользователь проходит путь от логина до результата. Разработчики поделены на фронт и бэк, каждый в своей зоне. Тестировщик же видит всё целиком, особенно если продукт реализован на разных платформах: веб и мобильная версии.

Тестировщик знает, где начинаются реальные проблемы, с чем сталкивается поддержка, какие инструкции пишутся бизнесу. И именно на груминге может сказать: «Эта фича ломает привычный путь» или «Здесь уже были боли — будьте осторожны».

  1. Когда команды изолированы, тестировщик видит систему целиком. В изолированной разработке тестировщик становится живым интегратором. К примеру, одни правят корзину, другие — авторизацию, и никто не видит, что их изменения конфликтуют до влития в основной код. А тестировщик видит. Он скажет: «Если здесь включите фичу, там всё отвалится». Это экономит недели.

  2. Баги из прошлого оживают снова. Бэклог багов — это живой архив продукта. Тестировщик знает, что уже чинили и почему. А значит, может сразу предупредить: «Эта задача столкнётся с багом #1873». Это сэкономит время, ресурсы и поможет сразу заложить правки в спринт.

  3. Усложняется передача контекста. Самое сложное — работать без контекста. В тикет попадает только крошка от задачи. А на груминге обсуждается суть: зачем делаем, кому это нужно, какой ожидаем результат. Именно здесь у тестирования появляются первые идеи сценариев, тестов, потенциальных уязвимостей.

Без этих знаний тестирование становится догоняющим. А значит, и всё деливери — тоже.

Что будет, если исключить тестирование из грумингов

Начнём с простого. Допустим, команда договорилась, как будет реализована новая фича. На словах, по джентельменскому соглашению. В задаче это, как водится, не отражено. Тестированию прилетает тикет с пометкой «протестировать». Что происходит дальше?

Тестировщик открывает задачу — и видит: реализация есть, а смысла нет. Цель не обозначена, ценность не объяснена, пользовательский сценарий не описан. Начинаются «походы за контекстом». Сначала — к продакт‑менеджеру, чтобы выяснить бизнес‑цель и понять, что вообще должно было получиться. Потрачено время — и продакта, и тестировщика.

Далее — к бэкенду: уточнить, где лежит логика, какие есть доступы, как взаимодействуют сервисы. Ещё минус время у всех. Потом — к фронту: свериться с макетами, уточнить, как связаны компоненты, где расхождения. И снова минус.

Вся эта воронка коммуникации отнимает огромное количество времени ещё до начала тестирования. И это в лучшем случае. В худшем — что‑то упущено, что‑то недосказано, и тестировщик работает вслепую.

Да, формализовать все договорённости в задаче — отличная идея. Но в реальности это редкость. Всегда что‑то висит в воздухе: часть логики, уточнение, нюанс. А если к этому добавляется задержка на предыдущих этапах, то у тестирования вообще не остаётся времени на нормальную работу до релиза.

Чаще всего в таких ситуациях проверки идут не на основании контекста, а на основе пользовательских паттернов и личного опыта. Уже на первом круге выявляются баги, которых можно было бы избежать — если бы всё это обсудили на груминге.

Процесс затягивается на неопределённый срок, временные рамки так или иначе сдвигаются. Именно тут происходит задержка в деливери. Тестирование без контекста невозможно, а сбор информации — один из важных составляющих профессии. Тестировщик нацелен на качественное деливери для бизнеса с учётом технических особенностей и возможностей продукта, являясь своеобразным мостиком между бизнесом и разработкой. Без присутствия тестировщика на груминге сложнее наверстать время для нахождения этого баланса.

Что будет, если добавить тестирование в груминги

Первое, что меняется при раннем подключении тестировщика — это сокращение времени на сбор информации. А ведь работа с информацией — один из краеугольных камней в тестировании. Если мы получаем ключевые сведения уже на ранних этапах, то к моменту непосредственной проверки подходим максимально подготовленными.

Чтобы сформировать качественные сценарии тестирования, нужно понимать цель задачи, ожидаемый результат, пользовательский сценарий (happy path) и контекст согласованности всей системы. Всё это — не просто детали, а основа, на которую опирается проверка. И именно на груминге закладывается архитектура задачи. Это даёт возможность повлиять на неё в реальном времени: обратить внимание на потенциальные логические несостыковки в связке действие — результат, подсветить пользовательский опыт, внести предложения по улучшению юзабилити.

На поздних стадиях изменить что‑либо уже реализованное значительно сложнее, а иногда и вовсе невозможно. Намного проще адаптировать идею под реальные ограничения заранее, чем потом переделывать готовую фичу.

Кроме того, на груминге часто обозначается предварительный технический план. Это позволяет ещё до старта тестирования набросать чек‑листы, заготовить корневые тест‑кейсы и даже начать оформление документации по новой функциональности. Всё это снижает затраты времени в дальнейшем.

Но, пожалуй, самое важное — это синхронизация всей команды. На груминге участники вырабатывают общее понимание задачи, устраняют разночтения и договариваются о целях. Как показывает практика, большинство критичных вопросов удаётся закрыть именно на этом этапе. Ведь даже в простой фразе вроде «Казнить нельзя помиловать» смысл полностью зависит от расстановки акцентов — а в разработке это особенно чувствительно.

Из всего вышесказанного становится очевидно: груминги — критически важный этап не только для тестирования, но и для стабильного деливери в целом. В теории этот процесс известен как встреча трёх амигос — разработчика, продакта и тестировщика. Когда‑то я прочитала отличную статью о практике этой методологии, и с тех пор её принципы стали для меня чем‑то вроде профессиональных ориентиров.

По моему опыту, важнее не сокращать встречи, а работать над их качеством. Один полноформатный продуктовый груминг даёт для тестирования больше ценности, чем пять коротких и утомительных созвонов в попытке собрать по кусочкам контекст. Он помогает команде договориться на берегу, обсудить сложные моменты и увидеть общую цель, прежде чем будет написана первая строчка кода.

Да, это не отменяет будущих обсуждений — командные синки и уточнения всё равно будут. Но после хорошего груминга эти обсуждения уже не разрушают процесс, а поддерживают его.

По моим наблюдениям, в таких командах меньше споров, меньше затяжек, и никто не гонится за дедлайном, как за уходящим поездом. Это делает разработку устойчивой. А устойчивость — это то, что даёт силу двигаться дальше, даже в плотном спринте.

Выводы

Разработка продукта часто напоминает мне оркестр. В каждой команде — даже внутри одной компании — процессы могут отличаться, но суть остаётся той же: у каждого участника есть своя важная роль. И чем слаженнее играет этот оркестр, тем чище и мощнее звучание.

Открытая коммуникация внутри команды — это надёжная основа для общего результата. Раннее тестирование, включая планирование, технические созвоны и особенно груминги — это область ответственности тестировщика, которая напрямую влияет на прозрачность разработки для бизнеса. Через свою работу тестировщик «переводит» сложные системы на понятный язык, делая продукт доступным для оценки и управления.

Участие в раннем тестировании даёт тестировщику актуальную и полную картину состояния продукта. Это позволяет не просто проверять задачи, а осознанно нести ответственность за итоговое качество. Именно поэтому важно участвовать в обсуждениях и доносить ценность таких форматов для всей команды.

Груминг как ключевой этап раннего тестирования помогает поддерживать постоянную коммуникацию, влиять на формирование идеи с точки зрения пользовательских паттернов, получать полный контекст, сокращать время на разработку тест‑кейсов и ведение документации. Кроме того, именно на грумингах у тестировщика происходит рост: от точечного взгляда на отдельную задачу — к пониманию всей системы целиком.

Коммуникация — один из важнейших факторов успеха любого проекта. Даже такая сложная, непрерывная и подвижная штука, как процесс разработки, становится понятной и управляемой через простые действия внутри команды и чёткое понимание ролей. Я искренне верю, что сила тестировщика — в способности коммуницировать. А раннее тестирование — неотъемлемая часть этой силы.

Комментарии (11)


  1. Appleprofi
    08.07.2025 10:26

    Собсна в своей команде так же сдвинул подключение тестировщика на ранние этапы, но скорее не "по-учебнику", а чисто по пройденным самими же граблям. Сейчас без команды тестеров вообще не начинается проработка большинства проектов. Естессно, что мелкие таски порой попадают на борду тестирования и без груминга, но это скоре одиночные мелкие таски или фиксы багов


    1. Dara_dara Автор
      08.07.2025 10:26

      Вполне согласна, иногда грабли — это самый быстрый и эффективный учитель. Главное — сделать выводы и превратить их в ценный опыт. Здорово, что ваша команда не только прошла через это, но и выстроила рабочий процесс, который действительно приносит пользу


  1. vlad4kr7
    08.07.2025 10:26

    тема интересная! но извините, где про TDD? - это в чистом виде раннее тестирование.

    Или ваше раннее тестирование, это про Stress Test на dev env?

    Или unit test coverage ->99% до релиза? или functional test, integration, e2e?

    Или ваше раннее тестирование, это "развертывание окружения (всех серверов, баз, итд) для изолированного тестирования фича бранча до PR merge"?

    Кстати, а познее тестирование? т.н. canary deploy.

    или personalized feature toggle на проде. Тоже своего рода тесты.


    1. Dara_dara Автор
      08.07.2025 10:26

      Как много интересных и важных инструментов вы перечислили. Это очень здорово! Я попытаюсь разобрать их в контексте статьи. TDD и сами юнит-тесты могут в командах лежать в зоне ответственности у разных специалистов. В тех командах, которых я была, как правило, они были в руках разработки, не тестирования. Я была бы рада, если бы вы поделились своим опытом в задаче делегировании этой области в тестирование. Сами эти подходы требуют оформленной и проработанной документации с ясными требованиями, по которым возможно составить тесты. В этом как раз помогают груминги, чтобы спецификация обрела ясные контуры. Как по мне, груминги, это как раз тот этап, когда бизнес идея превращается в стабильные требования.

      Что касается функциональных тестов руками, как и автотестов (ui, e2e, интеграционные, api), по моему мнению, они больше относятся не к раннему тестированию, а к самому этапу тестирования, когда тестировщик непосредственно смотрит задачу. Хотя, например, написание документации, структуры тест-кейсов, пользовательских сценариев, даже подготовка на моках, можно вынести за рамки "до отдачи кода", чтобы при проверки сократить время на подготовку. Но это так же возможно только в рамках, когда тестировщик получил ранний контекст.

      Моя цель была сосредоточиться на "серых", как мне показалось, этапах в раннем тестировании, где можно сократить время и оптимизировать его для дальнейшего процесса. То есть от появления идеи до старта самого тестирования.

      Если говорить о практике, на грумингах полезно сразу формировать критерии DoD, делать акцент на сценариях BDD, а также заранее обсуждать требования, связанные с переходами состояний. Это помогает команде быть на одной волне уже до старта активного тестирования


      1. vlad4kr7
        08.07.2025 10:26

        для меня раннее тестирование это: от ТДД, до развертывания окружения (всех серверов, баз, итд) для изолированного end_to_end тестирования фича бранча до PR merge. Вот здесь есть тема: разверывать под каждую фичу т.е. бранч=env, или использовать готовые Х_feature_env, вместо одного "dev" для параллельной разработки несколько фича бранчей?

        извините, но у вас этого нет, совсем.

        Зато у вас есть планирование, которое вы упорно называете груминг, который вообще, причесывание (дословный перевод) баклога по сложности реализации (или, "о, а мы это уже сделали"), не анализ, и даже не изменение приоритета, ибо это делает PO/PM по бизнес требованию.

        требуют оформленной и проработанной документации

        вы с аджайлом знакомы? это, как-бы прямое противоречие.

        Как много интересных и важных инструментов вы перечислили. 

        это сарказм? ни одного инструмента я не называл


        1. Dara_dara Автор
          08.07.2025 10:26

          Согласна, что в разных командах подход к грумингу, документации и тестовым окружениям может отличаться. Мы тоже сталкивались с разными вариантами: где-то груминг - это только оценка задач, а где-то это полноценная площадка для обсуждения деталей и критериев качества. Здесь многое зависит от терминологии и внутренних процессов в команде.

          Темы выделенных сред под каждую фичу (branch=env или пул тестовых окружений) действительно важны - такой подход ускоряет обратную связь и снижает зависимости между задачами. На мой взгляд, это отлично вписывается в agile-принципы: быстрее проверять результаты и не мешать работе других. Развёртывание изолированных сред - отдельная тема, причём тут многое зависит еще и от возможностей инфраструктуры.

          Agile, действительно, не делает упор на тяжёлую документацию, чтобы не замедлять процессы. Но на практике приходится искать баланс между минимальными описаниями и прозрачностью требований, и для многих команд это вопрос рано или поздно становится актуальным.

          По инструментам - я действительно имела в виду процессы и подходы, а не конкретные тулзы, возможно, стоило это уточнить.

          Благодарю, что обратили внимание на эти аспекты!


  1. Lissaris
    08.07.2025 10:26

    Спасибо за отличную статью! У нас сейчас похожий переход, и возник вопрос: если в команде несколько тестировщиков, кто ходит на груминги - один, по очереди или все вместе? И дальше тот же человек сопровождает задачу до конца, или на тест может взять кто-то другой?


    1. Dara_dara Автор
      08.07.2025 10:26

      Во многом это зависит от самой команды и её возможностей.

      У меня в разных командах, где был опыт проведения грумингов, как правило задачи передавались из рук в руки, то есть необязательно участвовавший человек дальше смотрел задачи, которые обсуждал.

      По поводу состава, я могу поделиться тремя кейсами:

      1. Когда команда небольшая, и уровень тестировщиков примерно одинаковый, полезно, чтобы на встречи ходили все участники. Это помогает не только набраться опыта в техническом понимании продукта, но и способствует профессиональному росту внутри команды: появляется практический взгляд и насмотренность.

      2. Когда команда большая, но уровень тестировщиков всё так же примерно одинаковый, можно ходить на груминги по очереди. Но для этого нужно заранее сформировать инструменты передачи информации - это может быть документация по шаблону, регулярные тестировочные синки или другие подходящие способы. Такой подход позволяет учиться работать с информацией и делиться ею внутри команды.

      3. Когда команда большая, и уровень тестировщиков разный, участие в грумингах можно делегировать разным грейдам специалистов в зависимости от целей. Если на начальных этапах важно быстро запустить процесс, имеет смысл привлекать к обсуждению более опытных коллег, чтобы запустить процесс. Если приоритет - развитие и рост команды, стоит вовлекать в такие активности менее опытных тестировщиков, чтобы они получили необходимые знания и навыки на практике.

      Что бы вы ни решили, удобнее всего пользоваться одним шаблоном для всех — так данные не теряются и все в курсе. Из моего опыта: когда я только начала участвовать на грумингах, от отдела тестирования на встречи приходили два человека — старший и младший тестировщик. Такой подход позволял не только расширять экспертизу команды, но и способствовал профессиональному росту менее опытных коллег

      Надеюсь, мой опыт будет вам полезным! Буду рада, если один из кейсов подойдет вам.


  1. mrozov
    08.07.2025 10:26

    Собираясь в команды, люди занимают определённые должности и принимают на себя определённые роли.

    Для того, чтобы закрепить в процессах подобные практики, нужно подбирать на определённые должности людей, способных эффективно брать на себя определённые роли. К сожалению, это далеко не всегда и далеко не везде возможно.

    В каждой команде, безусловно, должен быть человек, исполняющий роль Критика, который критически разбирает любую идею, проверяя её на слабые места. Безусловно, такой человек должен быть ориентирован на результат, а не на процесс, и быть глубоко погружённым в пользовательские сценарии, иначе его критика не будет конструктивной.

    Эта роль идеально сочетается с позицией QA. Увы, не всегда и не всем удаётся найти именно такого человека, сочетающего соответствующие компетенции с соответствующим образом мысли и интеллектом.

    Собственно примерно поэтому, строго говоря, 3 Amigo это история про трёх друзей, а не про PM, Dev и QA. Если этот момент игнорировать (просто станьте ёжиками, мышки), то получается очередной (100 500) случай процесса, который мешает достигать результата, а не помогает это сделать.

    А так да, ППКС.


    1. Dara_dara Автор
      08.07.2025 10:26

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

      Что касается найма на определённые позиции, я больше выступаю в роли оптимиста и верю в то, что нужного специалиста часто можно вырастить внутри команды. При наличии энтузиазма и желания развиваться, груминги могут стать отличной площадкой для реализации такого потенциала. С небольшим менторством у специалиста появляется возможность "натренировать взгляд" и научиться конструктивной критике. Дополнительным плюсом станет расширение экспертизы и развитие культуры обмена знаниями внутри коллектива, как максимум, и расширение технической базы знаний у такого специалиста, как минимум.


      1. mrozov
        08.07.2025 10:26

        Я несколько о другом. В командной работе выделяют разные роли (генератор идей, зануда и т.п., их много и классификаций тоже много).

        Главное - люди, как правило, имеют хорошие способности только к части этих ролей, а в других будут в лучшем случае посредственны. По сути, некоторые из них требуют противоположных личных качеств.

        Для эффективной работы команде требуются носители всех или большинства ролей. Но роли и позиции в команде в общем случае не совпадают.