Компании, возглавляемые инженерами vs Компании, возглавляемые бизнесменами
“На конференции Plato’s Elevate 2024 я присутствовал на мероприятии под названием «Качество без QA: Создание отличного ПО с помощью проактивной методологии», в основном из чистого любопытства (естественно). Ведущий представил подход, которого они придерживаются как инженерная организация, где все тесты разрабатываются и автоматизируются инженерами, поэтому нет необходимости в QA, или команде QA.
Я спросил: «А что, если продакт или бизнес спросит, можете ли вы отправить продукт на месяц раньше плана, предоставленного инженерами?»
«Мы скажем, что не готовы к этому времени» — был ответ.
«Хорошо, тогда продукт или бизнес вернутся и скажут, что нужно успеть к этой дате, чтобы капитализировать потребности клиента»
«Мы скажем, что не идем на компромисс с нашим инженерным процессом. Мы не будем идти на компромисс с качеством разработки только для того, чтобы удовлетворить потребности бизнеса»
«Хорошо, тогда бизнес/продукт вернется и скажет, что, возможно, это не та команда инженеров, которая нужна этой компании. Нам нужно инженерное лидерство, чтобы удовлетворить потребности бизнеса»
«Но вы потеряете свои лучшие инженерные таланты, вы потеряете экспертизу в домене».
Они могут вернуться: “Что мы можем вычеркнуть из плана? Что это за задачи, в которых говорится об автоматизации тестирования? Нам просто нужен человек, который будет тестировать функции, да? Почему мы не можем нанять временных подрядчиков для тестирования?»
Ведущий покинул панель с пониманием того, что есть компании, возглавляемые инженерами, где инженеры определяют все и имеют более сильную позицию на переговорах о сроках поставки продукта. И есть компании, возглавляемые бизнесом или продуктом, где у инженеров меньше рычагов влияния.
Не заблуждайтесь, я не против систем, где нет QA, это работает для некоторых команд (и это здорово! подумайте, сколько вы экономите на численности персонала и на координации), но как вам, как CTO или VPE, понять, когда вам нужно создать QA-команду (или нанять первого тестировщика)?
Истощение разработчиков
Эта ситуация возникает, когда у команды разработчиков слишком много работы и происходит слишком частое переключение контекста, например, фулстек-инженеры переходят от FE к BE в течение спринта или между спринтами. Им нужен партнер (или партнеры) по тестированию, который (а) поможет устранить ошибки первого уровня, (б) подумает, как тестировать фичи, и возьмет на себя часть нагрузки по тестированию и/или автоматизации тестирования.
Наша команда пыталась увеличить охват модульных и E2E-тестов, но потребности бизнеса требуют, чтобы они сосредоточились на создании фич.
Истощение службы поддержки клиентов
В такой ситуации почти все релизы вызывают проблемы у клиентов, обрушивая на службу поддержки шквал жалоб. Устаревшие подходы оказываются неадекватными для решения проблем с качеством релиза, либо просто слишком велика потребность бизнеса в выпуске фич — даже ценой недовольства клиентов.
Слишком много задач по организации тестирования
Задачи подобного уровня действительно требуют от технического директора/VPE тратить время на организацию тестирования. Это может отвлекать внимание от более важных задач, связанных с бизнес-целями. Вы можете поручить это разработчику-сеньору или продакту, но это не является их основной компетенцией. Если делегировать эту задачу менее опытному разработчику или PM, у них может не хватить влияния, чтобы остановить релиз.
Плохое качество продукта препятствует достижению бизнес-целей
Это, пожалуй, самая важная причина для того, чтобы нанять специалиста-тестировщика или QA-команду. Например команда не может выделить ресурсы для достижения высокого покрытия юнит-тестами. Или код находится в такой плохой форме (пресловутое high coupling, low cohesion) из-за сжатых циклов разработки и/или работы с легаси-кодом. К которому приложили руку несколько разработчиков, которые приходили и уходили, и написание юнит-тестов просто слишком болезненно. Или компания не может добиться достаточной скорости внедрения продукта, или клиенты настолько недовольны, что бизнес не может развиваться.
Почему так сложно создать команду тест-инженеров в стартапе
Владельцы vs сотрудники
Есть владельцы, и есть сотрудники. Человек с мышлением сотрудника смотрит на работу как на просто работу. Он не вкладывается в компанию эмоционально (и финансово), как CTO/VPE или даже сотрудники, которые работают давно. Он использует только свое рабочее время, и не видит, что, будучи стартапом, компания находится в гонке со временем, чтобы реализовать запланированное основателями.
По моему опыту найма тестировщиков в стартапы, до 50% кандидатов имеют мышление наемного сотрудника.
С другой стороны, основатель / технический директор / VPE может знать кого-то, кому он доверяет и знает, что у него мышление владельца продукта, но у него нет опыта развития тестирования в команде. Это подводит к следующему пункту.
Опыт vs карьерный рост
Это, пожалуй, самый сложный аспект создания QA-команды в стартапе. В отличие от разработки, где у вас есть CTO/VPE, имеющий опыт управления командой разработчиков и карьерный рост в течение 5-10 лет, очень непросто найти человека, обладающего знаниями в QA и при этом способного за 5 лет пройти путь от тестировщика до директора по QA. Опытные тестировщики могут не захотеть выполнять работу более низкого уровня или находятся на том этапе жизни, когда им просто хочется провести отпуск с детьми. Менее опытные тестировщики находятся на том этапе жизни, когда они хотят сделать карьеру, но нуждаются в руководстве и наставничестве.
Создание роли QA
Обычный путь
В большинстве команд я наблюдал, как технический директор/VPE получает бюджет, нанимает кучу QA и управляет ими сам, либо делегирует эту функцию сеньору, либо прикрепляет тестировщиков к каждому подразделению или команде. Часто боль бывает настолько острой, что технический директор/ VPE нанимает слишком много людей (это сродни совету не ходить за продуктами, когда вы голодны). Потом технический директор осознает, что он, или лиды, не могут обеспечить адекватное руководство/коучинг для этой группы в отношении карьерного роста, а также разработать план развития группы в тандеме с остальными командами продукта. Затем он получает еще бюджет, чтобы нанять более опытного QA-лида для наведения порядка. Лид выходит на работу и понимает, что некоторые из тех, кто был нанят ранее, не смогут выйти на новый уровень развития компании, и их приходится заменить. Это создает проблемы, и в процессе теряется часть информации о структуре и истории продукта.
Лучший путь
Вот как, на мой взгляд, лучше подойти к решению этой проблемы:
- Привлекайте QA-консультанта или так называемого Fractional QA Leader, чтобы он помог определить направление роста.
- Этот консультант должен оценить ситуацию (включая размер QA-команды), помочь настроить процессы тестирования, а затем, опираясь на свою сеть, найти и нанять правильных тестировщиков.
- Эти тестировщики должны быть относительно молодыми людьми, обладающими потенциалом и желанием расти. По идее один из них в конечном итоге возглавит QA-команду, под общим руководством CTO/VPE.
- Этот консультант или лид должен работать в течение нескольких лет и менторить тестировщиков, чтобы в конечном итоге один из них возглавил свою команду.
Такой подход обеспечивает преемственность. Сотрудники, пришедшие в компанию в период ее роста, остаются и занимают руководящие должности в компании. У них есть понимание истории организации (я люблю говорить, что «они знают, где лежат все трупы»). Привлекая консультанта, вы используете их связи и опыт, что снижает нагрузку на HR-ов.
Что такое Fractional leader?
Информация с сайта Fractional First: «Это опытный руководитель, который предлагает своему работодателю услуги лида на неполный рабочий день. Это позволяет компаниям использовать его опыт и знания без необходимости нанимать его на полный рабочий день. Как правило, они возглавляют стратегические направления и контролируют операционные команды».
Как эта роль соотносится с ролью консультанта или коуча:
Каким должен быть тестировщик в стартапе
Вкратце, кандидат должен обладать:
- Мышлением инженера
- Интеллектуальным любопытством, а также:
- Находчивость
- Упорство
- Техническая компетентность
- Достоинство
Майндсет
Мы ищем кандидатов с мышлением владельца, но самое главное — с упорством. Стартапы — это тяжело. Это тяжкий труд как минимум на несколько лет, и никаких гарантий стабильного дохода. Идеальный кандидат должен обладать стоицизмом, поскольку на этом пути будет много трудностей. И наконец, кандидат должен обладать мышлением роста, поскольку ему предстоит пройти путь от создания и выполнения тестов до разработки стратегии качества.
И наконец
Роль CTO/VPE заключается в продвижении бизнес-целей компании. Нужно многое делать, и хотя в любой момент вопрос качества релизов стоит остро, это не единственная задача, требующая внимания. Возможно, иногда стоит привлечь консультанта или Fractional Leader, который поможет наладить и запустить эти процессы.”
