Тестовые (технические) задания = говно

Технические задания (ТЗ) — та самая штука, от которой у многих IT-специалистов случается фрустрация. Кто хоть раз сталкивался с таким заданием, знает, что оно редко составлено должным образом и лишь отдаленно напоминает реальные рабочие задачи. И проблема не в том, что кто-то плохо пишет ТЗ. Скорее дело в том, что не существует универсальных правил, по которым можно составить качественное техническое задание.

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

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

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

Кстати мы офигенно помогаем с прохождением абсурдных тестовых. Выбирайте профессию и регистрируйтесь, с нас вводный call и первичное решение вашего кейса.

Вопрос в том, почему компании до сих пор следуют этому подходу? Во-первых, это рутинная практика, которую никто не пытается менять. Во-вторых, сами HR зачастую не знают, как правильно провести интервью.

Давайте честно: большинство технических заданий при найме не имеют никакого отношения к реальной работе, которую предстоит выполнять кандидату. Это задания, придуманные «на коленке», непонятно кем и непонятно зачем.

Задумайтесь, как часто на интервью вам предлагали решить задачу, не связанную ни с бизнесом компании, ни с ее продуктами? А потом вам давали фидбек, основанный на том, насколько «креативно» вы подошли к выполнению задания, а не на том, насколько ваши решения применимы в реальной работе.

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

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

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