Как стать автором
Обновить
77.25
Рейтинг
Контур
Делаем веб-сервисы для бизнеса

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

Блог компании Контур Тестирование веб-сервисов *Управление разработкой *Управление проектами *Управление продуктом *

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


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



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


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

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


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


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


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


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

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

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

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


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


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


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



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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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

Теги:
Хабы:
Всего голосов 87: ↑76 и ↓11 +65
Просмотры 59K
Комментарии 186
Комментарии Комментарии 186

Информация

Дата основания
Местоположение
Россия
Сайт
tech.kontur.ru
Численность
5 001–10 000 человек
Дата регистрации