Насколько большие были команды в проектах
Что проверяют
Впишетесь ли вы в их процесс. За вопросом стоит вполне конкретное: сколько команд разработки вы обслуживали как аналитик, был ли рядом второй аналитик или вы были единственной точкой знания, с кем согласовывали требования и насколько формально это делалось.
Как отвечать
Отвечайте фактами, а не оценками. Назовите состав: сколько разработчиков, тестировщиков и дизайнеров было в команде, сколько команд приходилось на вас одного, кто был владельцем продукта, был ли архитектор. Дайте два или три примера от самого маленького состава к самому большому.
Главное дальше: покажите, как размер менял вашу работу.
- маленькая команда: требования живут в задаче, договорённости устные, аналитик часто сам и тестирует, и общается с заказчиком;
- средняя: появляются регламент постановки, критерии приёмки, единый глоссарий, груминги;
- большая или несколько команд: требования делятся по потокам, растёт цена расхождений в терминах, нужны схемы интеграций, описание контрактов и процедура изменения уже согласованного.
Полезно закончить своим выводом: где вам работалось продуктивнее и почему. И задайте встречный вопрос про их состав, это ровно тот случай, когда он уместен и ожидаем.
Где спотыкаются
Отвечают заготовкой по схеме «ситуация, задача, действия, результат» с готовыми процентами: сэкономили часть бюджета, закрыли проект раньше срока. Спрашивали простой факт о размере команд, а получили презентацию, и цифры, которые невозможно проверить, только усиливают недоверие.
Завышают масштаб. Сказать «команда двести человек», имея в виду весь департамент, легко, но следом идёт уточнение про роли и ежедневные взаимодействия, и легенда рассыпается за два вопроса.
Не разделяют круги. Продуктовая команда, с которой вы каждый день на созвоне, смежные команды и вся программа целиком это три разных числа. Называйте их отдельно и говорите, с кем именно взаимодействовали вы, а не ваша компания.