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

Каждый пятый менеджер говорит, что поставил одному из тестировщиков такую цель:

Научиться оценивать сроки на тестирование задач

Уверен, такие же цели ставятся и другим ролям в разработке.

Укладывается в самостоятельно сделанные оценки сроков по задаче

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

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

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

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

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

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

Голосом с 23 минуты.

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

В пятой части первой главы есть ссылки и объяснения исследований.

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40%. Рекомендую прочесть. Все факторы, перечисленные в книге, релевантны до сих пор.

Деминг и Нив, статистика и вариации

За последний год в двух командах слышал следующее:

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

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

Упомянутые в заголовке авторы говорят, что верный способ оценки сроков — статистический. Оценивается пакет типовых задач.

У нас все задачи разные.

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

Что делать, заказчик же требует сроки?

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

Как правило, ответом на вопрос успеем ли мы к заданному сроку? является аналитика и mvp, качественная инфраструктура разработки и размер техдолга: скорость рефакторинга, наличие автоматической регрессии. Ещё раз, оценка сроков мешает исполнителю успеть к дедлайну.

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

• MVP.
• Декомпозиция задачи.
• Раздельный релиз фронта и бекенда.
• Канареечные релизы.
• Фича-флаги.
• Умение тестировщиков отделять важные дефекты от неважных и умение релизить с неважными
• Pull стратегия работы над задачами (я говорю о том, что программисту не должны совать новые задачи, пока не вышли старые, даже если над задачей пока работает не он).
• Много раз слышал о такой стратегии: сперва релиз рефакторинга, который готовит код к появлению новой фичи, затем релиз самой функциональности. По сути, та же декомпозиция.

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

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

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

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

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

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

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

P.S. 

Речь идет о продуктовой разработке.