Зачем фиксировать дефекты ч.4

Привет 🫂

Я дописала часть статьи, касающуюся мотивации и страхов при изменении подхода с “не фиксируем дефекты” на “фиксируем все дефекты”. Постаралась подробно, но без лишней “воды” описать с чем связаны страхи и что имеет смысл делать. 🤗 К основным страхам данного изменения я отнесла: 1️⃣ страх перегруза (уменьшение времени на отдых); 2️⃣ страх выговора или лишения премии/увольнения из-за большого количества дефектов; 3️⃣ восприятие дефектов как критики (неодобрения) лично кого-то; 4️⃣ страх ухудшения взаимоотношений; 5️⃣ страх потери уважения.

При фиксации всех дефектов, первые 4 страха вполне решаются походом к работе с дефектами, если руководствоваться простыми правилами. ❗️ При переходе к практике фиксации всех дефектов, разговор надо начинать с того, что новые правила: ✅ не сильно увеличат нагрузку и даже, возможно, снизят её; ✅ нет никаких KPI по дефектам, никто никого наказывать не собирается и не будет; ✅ дефект - это не жалоба на разработчика, а шанс увидеть картину качества и иметь возможность улучшать не только качество продукта, но и собственной работы; ✅ обязательно проводить анализ обнаруженных дефектов на предмет их причины появления и с фокусом на то, как избежать в будущем.

Последний страх… Ну что могу сказать… Если человек незаслуженно пользуется авторитетом/уважением, то лучше иметь этому подтверждение, чем жить “в розовых очках”. Так будет шанс подтянуть компетенции и пользоваться авторитетом/уважением заслуженно.

Как обычно, комментарии приветствуются 💬