Главная » Хабрахабр » Оценка сроков на разработку и тестирование задачи (не нужна)

Оценка сроков на разработку и тестирование задачи (не нужна)

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Слушаем SID-музыку через OPL3 на современных ПК

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

Пользователь в Docker

В новой статье он рассказывает, как создать пользователей в Docker. Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile. Это кажется очень удобно, ведь ...