Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd ^[1].

Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи. Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.

Сейчас объясню, как это работает.

О трудах классиков

Максим Дорофеев — Эффект выпрямления сроков

Цитирую по книжке «Джедайские техники ^[2]», хотя можно было и закон Паркинсона ^[3] процитировать:

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

Вместо того чтобы сразу же приступить к выполнению задачи, мы «разбираемся со срочным», так как «эта задача пока не горит» — у нас же есть вышеупомянутый запас.

Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.

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

Человек как выпрямитель (и диод) — иллюстрация из «Джедайских техник». Видео ^[4] тоже есть.

Том Демарко — Человеческий фактор ^[5]

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

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40 %.

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

Деминг и Нив — Эксперимент с красными бусинами ^[6]

За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».

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

Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и невыполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.

О заказчиках, которые требуют сроки

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

Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.

Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.

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

• MVP
• декомпозиция задачи
• ограничение недоделанной работы (программист не берёт новые задачи, пока не вышли старые)
• раздельные релизы рафакторинга и последующих фич
• раздельный релиз бэкенда, фронтенда и других частей продукта
• канареечные релизы ^[7]
• использование фича-флагов ^[8]
• умение тестировщиков отделять важные дефекты от неважных
• умение команды релизить с неважными дефектами

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

О некомпетентных менеджерах

Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.

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

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

Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?

То есть разница между «я потрачу на эту задачу день» и «задача будет готова через день» многократна и принципиальна.

Ты учишь жизни, а чего добился сам?

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

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

Оценку сроков на тестирование мы делаем так. Делим задачи на мелкие, большие и остальные. Мелких задач примерно половина, их делает дежурный тестировщик в свободное время. Мелкая задача помечена в YouTrack тегом «на час» и делается за один подход (от получаса до двух часов), если не возникли осложнения.

Большие задачи помечены тегом «проект», и по ним сразу понятно, что просто не будет. У каждой большой задачи есть фича-лид, задача которого — сделать так, чтоб были проделаны упражнения из списка выше.

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

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

В последний раз я задерживался на работе по просьбе менеджера, чтобы выпустить срочную задачу, больше двух лет назад. До этого пару раз, в 2015 и в 2016 году.

P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.

(Подпишитесь на наш канал в Телеграме ^[9], там неплохо.)

Автор: Wolonter

Источник ^[10]