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

Разработчик, или тестировщик, или кто угодно, думает: “так, вот это бы не забыть, как будет свободное время тогда сделаем” и заводит тикет. Возможно, даже пишет туда какие-то детали. Оптимист может даже создать задачу типа “переехать на специализированное решение для поиска” или что-то вроде “система не масштабируется на 1 000 000 пользователей” (пока у нас и десяти нет). Тестировщик может найти хитрый кейс “не нажимается кнопка посмотреть детали профиля в IE7 под Windows XP в режиме совместимости”.

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

Правда жизни заключается в том, что все эти тикеты никогда не делаются. Прошло пол-года, продукт пивотнулся, и функциональность уже не нужна. IE7 использует 0.0005% пользователей. Масштабироваться не нужно, потому что взрывного роста не случилось. AWS выпустил новый продукт и ваша жалкая кучка скриптов уже не нуждается в допиле и рефакторинге (тру стори).

Один из продуктов которые я разрабатываю и поддерживаю — это виджет который встраивается на сайты партнеров. Технически это просто кусок js кода, который вставляешь на страницу и все работает. Первая его версия была написана в 2017 на es5 и использовала jQuery. Примерно в то же время один из разработчиков завел тикет “переписать на es2017, использовать полифиллы, отказаться от jQuery” и перечислил несколько библиотек которые могли бы в этом помочь. Прошло два года. Виджет работал как часы. Понадобилось добавить туда новую функциональность и я решил переписать все с нуля. Глянув в старый тикет я обнаружил, что библиотеки, которые там были упомянуты, уже давно устарели и не поддерживаются.

В итоге я просто переписал все, и старый тикет мне никак не помог. Более того, триггером для переписывания стал вовсе не очередной запланированный разбор технического долга, а свежие требования от бизнеса.

Однако все эти два года тикет, который сидел в беклоге среди своих, таких же грустных коллег, уже отрастивших бороды и переживших не один переход из спринта в спринт, занимал мое время и захламлял пространство. Ведь каждый раз при планировании ты пробегаешь глазами по названиям и решаешь — может быть стоит взять это в работу? Дальше смотришь что “а, ну это да, сделать конечно же нужно, но не сейчас”. Если посчитать все время, потраченное на вот такую постоянную перепроверку а нужно ли это вообще, то за пару лет может насобираться довольно приличное количество времени.

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

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

Естественно, я не говорю, что не нужно разгребать технический долг. Просто нужно подбирать правильный момент и говорить “смотрите, эта функциональность уже просто так сюда не влезет, нам нужно переписать это и вот это, придется потратить больше времени”. И уже под нужды конкретной задачи допиливать продукт до нужной кондиции. Оптимизацию нужно проводить строго в то время, когда необходимость начинает маячить на горизонте. А не за горизонтом, на соседнем континенте, на Луне или вообще на другой планете.

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

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

Иногда тикеты создаются “на потом”. Типа когда будет затишье на проекте, то можно будет разгрести техдолг. На самом деле нет ничего худшего, чем бесполезная работа, продукт которой, по-большому счету, не нужен прямо сейчас. Лучше просто дать людям отдохнуть, нежели заставлять их ковырять древнее говно мамонта, писать тесты на давно уже не меняющуюся функциональность или рефакторить код. А на серьезную, исследовательскую работу и так времени не хватит, я гарантирую это. Сколько раз я садил людей делать какие-то задачи из беклога, когда не было важных вещей — никогда ничего хорошего из этого не получалось.

Поэтому, некоторое время назад, утомившись от большого количества таких вот тикетов, я собрал волю в кулак и легким движением руки закрыл их все, после чего сделал себе установку не создавать бесполезных тикетов-улучшалок в стиле “переехать с ECS на k8s”, “прикрутить мониторинг” или “переписать ядро компонента с ruby на java”. Когда придет время мы об этом точно узнаем, и тогда и переедем. И перепишем.

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

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