Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - страница 6

7 гораздо дороже.

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

– — – — – — – — – — – — – — – — – — – —

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

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

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

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

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

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

– — – — – — – — – — – — – — – — – — – —

Кейс: тестировщик или разработчик – кто первый?

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