Иногда в интервью я слышу, что перфекционизм позволяет добиться успеха. Я, конечно, не буду утверждать обратное, кто я такой, чтобы это делать. Вот только есть у меня подозрение, что это всего-навсего ошибка выжившего. Ну а возможно это работает в творческих областях, не знаю.
Зато я знаю, точно, что любая сложная система содержит в себе ошибки. И задача команды разработки, не исправить все эти баги, как можно было бы подумать, а выстроить систему таким образом, чтобы появление ошибок могло нивелироваться общей стабильностью системы.
Аналогично ситуация обстоит и с разработкой нового функционала. Ведь по сути новый функционал, это нарушение логики работы предыдущей стабильной версии. А значит это ошибка, если следовать старой логике.
Тут сразу вспоминается мем «Это не баг — это фича».
Возвращаясь к мыли, что не все ошибки надо править. Если команда смиряется с мыслью, что ее продукт не идеален, и принимает тот факт, что не все ошибки надо править, встает вопрос: «Какие ошибки нужно править, а какие нет?» Именно для этого был придуман подход zero bug policy.
Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:
«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».
При этом, человек, который закрывает задачу, должен на что-то опираться и это точно не должно быть его внутреннее ощущение (оно может быть разным у разных членов команда) и уж точно на нежелание чинить баг. Поэтому команда должна договориться о четких правилах приоритизации ошибок. Обычно исходят из количества пользователей, которых затрагивает эта проблема насколько сильно это влияет на основной функционал.
В в своем посте в телеграме я выложу пример такой структуры, с описанием того, что надо делать. И сразу хочу предупредить — это не истина в последней инстанции, можно взять эту структура за основу и модифицировать ее под себя. И вообще можно применить этот фреймворк под любую ситуацию, и самостоятельно решить как реагировать.
Теперь о плюсах данного подхода:
- Всем известно, сколько есть открытых ошибок и это количество достаточно ограничено.
- Меньше времени требуется для нахождения задачи в багтрекинговой системе.
- Нет длительных встреч по сортировке и переприоритизации бэклога ошибок.
- Вам может стать психологически легче, когда на вас не давит раздутый бэклог.
- При исправлении не надо вспоминать, что же там было «сто лет назад», и вновь погружаться в контекст.
А есть минусы? Есть…
- Снижение качества продукта.
- Деградация уровня команды тестирования. (Зачем тратить время на поиск хитрых и сложных багов, если их всё равно не исправят?).
- Теряется полезный источник информации (в виде открытого бэклога) для новых членов команды.
Плюсы и минусы этого подхода взяты из этой статьи на хабре. В целом они имеют место быть, но в одном из следующих постов мне бы хотелось поспорить с ними, и доказать их несостоятельность в некоторых моментах.
Подписывайся на мой телеграм канал, там еще много материалов по IT тематике и продуктивности