Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.
После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.
Оценка сроков в 95 % случаев. Спасибо, xkcd.
Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи. Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.
Сейчас объясню, как это работает.
О трудах классиков
Максим Дорофеев — Эффект выпрямления сроков
Цитирую по книжке «Джедайские техники», хотя можно было и закон Паркинсона процитировать:
К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
Вместо того чтобы сразу же приступить к выполнению задачи, мы «разбираемся со срочным», так как «эта задача пока не горит» — у нас же есть вышеупомянутый запас.
Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.
Человек как выпрямитель (и диод) — иллюстрация из «Джедайских техник». Видео тоже есть.
Том Демарко — Человеческий фактор
В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.
Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40 %.
Рекомендую прочесть. Все факторы, перечисленные в пятой главе, релевантны до сих пор.
Деминг и Нив — Эксперимент с красными бусинами
За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру. В мире присутствуют вариации и ненарушение оценок конкретных задач означает, что оценка такого человека всегда правее кривой распределения фактического срока работы.
Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и невыполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.
О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.
Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.
Во-вторых, есть серия упражнений в разработке. Не все из них простые. Они напрямую не дают ответ на вопрос «когда фича будет готова». Однако они уменьшают размер поставки, снижают сложность разработки и тестирования и в итоге уменьшают вариативность сроков.
- MVP
- декомпозиция задачи
- ограничение недоделанной работы (программист не берёт новые задачи, пока не вышли старые)
- раздельные релизы рафакторинга и последующих фич
- раздельный релиз бэкенда, фронтенда и других частей продукта
- канареечные релизы
- использование фича-флагов
- умение тестировщиков отделять важные дефекты от неважных
- умение команды релизить с неважными дефектами
Если команда выполняет эти упражнения, а менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок. Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.
О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.
Необходимость назвать срок, когда задача будет сделана, заставляет делать перечисленные выше полезные упражнения: главным образом, декомпозицию этой задачи.
Но надо помнить, что оценка трудозатрат в команде с некомпетентным менеджером очень легко превращается в оценку сроков. Тут замешан миллион когнитивных искажений и непонимание, как устроены цепочки производства.
Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?
То есть разница между «я потрачу на эту задачу день» и «задача будет готова через день» многократна и принципиальна.
Ты учишь жизни, а чего добился сам?
Да, давайте поговорим обо мне и моей команде. Некоторые из перечисленных упражнений мы успешно делаем, какие-то учимся делать. Какие-то нет, и это печально.
Думаю, что мы научились ограничивать недоделанную работу, делать предварительные релизы рефакторинга и отделять важные баги от неважных.
Оценку сроков на тестирование мы делаем так. Делим задачи на мелкие, большие и остальные. Мелких задач примерно половина, их делает дежурный тестировщик в свободное время. Мелкая задача помечена в YouTrack тегом «на час» и делается за один подход (от получаса до двух часов), если не возникли осложнения.
Большие задачи помечены тегом «проект», и по ним сразу понятно, что просто не будет. У каждой большой задачи есть фича-лид, задача которого — сделать так, чтоб были проделаны упражнения из списка выше.
Остальные задачи никак не помечены. Упражнения из списка начинают проделываться, если время работы над ней превышает произвольно выбранную и варьируемую границу в 2 недели.
Если в очередь попала срочная задача, надо всё бросить и делать её. Оценивать не нужно. Впрочем, будет полезно уточнить дедлайн, чтобы понять, с какими дефектами и недоработками можно будет выпустить. Таких срочных задач — меньше десяти процентов.
В последний раз я задерживался на работе по просьбе менеджера, чтобы выпустить срочную задачу, больше двух лет назад. До этого пару раз, в 2015 и в 2016 году.
P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.
(Подпишитесь на наш канал в Телеграме, там неплохо.)
Автор: Wolonter
