🚀 Спочатку зрозумій, який це хаосЄ знайомий інженерний рефлекс: прилітає мутна задача - і всередині одразу вмикається “ну окей, зараз розрулю”. Тикет кривий? Уточнимо. Scope поплив? Підріжемо. Бізнес-сенс загубився? Знайдемо. Хтось написав “треба просто швидко зробити”? Ага, тільки спочатку розберемося, що саме.Цей режим реально рятує. Без нього команда швидко починає якісно робити не ту роботу. Але саме тому він небезпечний: коли щось багато разів допомагало, рука тягнеться застосовувати це всюди. І в якийсь момент ownership стає не силою, а способом мовчки забрати чужу нечіткість собі.Бо є два різні типи хаосу. Перший - туман: тикет описує симптом, рішення неочевидне, зв’язок з результатом слабкий. Тут треба копати, ставити незручні питання, сперечатися зі scope і, можливо, зупиняти імплементацію. Другий - розсинхрон: проблема вже більш-менш зрозуміла, але люди не домовилися, хто вирішує, що входить у роботу, що точно не входить і що робимо, якщо план знову поїде.Ось тут “я зараз розрулю” часто робить гірше. Домовленостей не стає більше, зате з’являється людина, яка тримає їхню відсутність на собі. Начебто допомагаєш команді, а на практиці закриваєш нечіткість власною увагою і зайвими ітераціями.Тому перед тим як рятувати задачу, варто поставити дуже нудне, але корисне питання: це туман чи розсинхрон? Якщо після розмови стало зрозуміліше, що саме треба зробити, це був туман. Якщо всі й далі “плюс-мінус згодні”, але рішення, межі й відповідальність не зафіксовані, це розсинхрон.Туман лікується ініціативою: сформулювати проблему, результат і ризики. Розсинхрон лікується ясністю: зафіксувати межі, людину за рішенням і що зміниться, якщо scope поїде.І це не про “працювати по ТЗ і не думати”. Іноді найкорисніше, що можна зробити для задачі, - не тягнути її сильніше, а спитати: “ми зараз шукаємо відповідь чи просто ще не домовилися?”---🌱 Keep calm and grow | 💬 Обговорити 1-на-1