InOdinWeTrust

1) Для начала необходимо выяснить как можно больше деталей о будущем проекте (веб-сайт).
2) (Важно!) Записать все требования на бумаге, согласовать с вышестоящим начальством.
3) Примерно прикинуть, сколько людей нужно будет, чтоб покрыть большую часть требований.
4) Расписать роли без привязки к конкретным людям - кто за какую часть требований отвечает.
Обязательно указать роль, которая выставляет требования к проекту.
(по ролям, чаще всего нужен один тех лид, который полностью закроет техническую часть требований - выбор архитектуры, софта; тим лид - закроет организационные и управленческие вопросы, набор в команду, методологию разработки. Ну и обычные роли для разработки веб-сайта - сисадмины, разработчики, тестировщики. Ну и продакт менеджеры, аналитики, если нужно).

4) Оценить бюджет команды, внести коррективы в роли, состав.
5) Согласовать с вышестоящим руководством, при необходимости вернуться к пункту 1.

Вы подняли сложный вопрос, на который нет одного ответа. Тут нужно в первую очередь смотреть на:
1. Ценности компании.
2. Архитектуру проекта/проекта.
3. Процессы - менеджмент, разработка, тестирование,
4 . Ресурсы - команда, документация, знания, навыки, время и тд.

1. Есть, грубо говоря, набор ценностей, которые приносят компании доход.
Например - показ каталога товаров. Чем лучше показан каталог, тем больше пользователей зависает на странице, тем больше покупают/хотят/выходят на связь/ppc - неважно, что именно, но это приносит компании деньги. Поломка каталога товаров грозит потерей денег/репутации/времени/рынка. Поломка где-нибудь в личном кабинете, рассылке или другом месте, не несет таких угроз. Собственно, исходя из имеющихся ценностей и оценки рисков, должен быть список "важного" функционала. Того, который не должен ломаться.

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

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

4. Ресурс - с учетом вышеперечисленного, выдвигаются требования к ресурсу. Если для тестирования критически важных мест системы нудно 100 человекочасов и специалисты уровня "синьор" - нужно выделять эти ресурсы. В противном случае, выделять больше времени, или перераспределять больше специалистов, вычислительных ресурсов на автотесты.