Agile: розшифровка
У Agile є проблема зі словником. Не тому що терміни незрозумілі — більшість людей у сучасних організаціях їх чули. А тому що це знайомі слова, що використовуються в зовсім іншому контексті, і без цього контексту люди співвідносять їх з тим, що вже знають.
Коли хтось вперше зустрічає поняття «Scrum Master», найближчим доступним концептом виявляється «менеджер проекту». Така відповідність здається природною — майже очевидною. Контекст зовсім інший.
Ніхто не збудував достатньо чіткого мосту між ними. А проблема посилилась, коли добросовісні практики — люди, що щиро прагнули допомогти організаціям рухатися вперед — почали описувати Agile як «краще управління проектами». Почали писати книги під назвою «Методологія Agile». Коли ви називаєте свій підхід методологією, його оцінюють за стандартами методології: артефакти планування, фазові шлюзи, структура результатів. Коли Agile не продукує цього — бо так і не задумувався — він не відповідає цим стандартам, і цілком обґрунтовано. Проблема не в тому, що Agile — погана методологія. Проблема в тому, що Agile взагалі не є методологією. Називати його так гарантувало розчарування всіх, хто шукав методологію, і те, що всі, хто його прийняв, будували щось, що Waterfall давно описав.
Стендап перетворюється на статусний звіт. Sprint перетворюється на дедлайн. Backlog перетворюється на список завдань. «Методологія Agile» стає стандартним позначенням того, що автори Маніфесту не впізнали б як опис того, що вони створили. І коли слова означають не те, що треба, практики, побудовані на них, дають хибні результати — точно, добросовісно і у масштабі.
Цей розділ — виправлення концепт за концептом. Не посібник зі стилю — функціональний довідник. Кожна публікація бере одне слово або фразу, що стали ключовими в тому, як організації розуміють Agile, досліджує, що вони насправді означають, і пояснює, що втрачається, коли скорочення замінює суть. Це не просто термінологічні розбіжності. «Бажаний результат» — не більш витончене слово для «специфікації»: це зовсім інша річ, з зовсім іншої моделі того, як робиться робота. Термін — це поверхня. Концепт під ним — ось що важливо.
Той самий паттерн проявляється, коли організації звертаються до ШІ, — і концептуальний розрив тут ширший. У випадку з Agile базові концепти були принаймні сформульовані, хоча й погано донесені. У випадку зі ШІ самі концепти ще лише формуються, а в масовому розумінні ледве починають вимальовуватися. Словник випереджає осмислення: ШІ як «автоматизація», ШІ як «інструмент», «ШІ-трансформація» як проект із датою завершення. Кожне з цих визначень закріплює ментальну модель раніше, ніж хтось встигає перевірити, чи вона підходить. Те, як ми називаємо речі, визначає, що і як ми будуємо. Правильні слова — необхідна умова для правильної роботи.
Тут діє один принцип: ментальні моделі первинні. Мова їх виражає. Дії слідують. Коли ментальна модель не відповідає роботі, словник, що її виражає, несе цю невідповідність — і дії, побудовані на цьому словнику, добросовісно виконуватимуть викривлене розуміння у масштабі, з повною відданістю. Зміна словника без зміни мислення дає в кращому випадку таблицю перекладу: таблицю відповідностей, де «sprint» відповідає чомусь на кшталт «короткого дедлайну». Таблиці перекладу дозволяють людям працювати через розрив. Вони його не усувають. Публікації цього розділу цілять у більше, ніж переклад. Вони цілять у зміну ментальної моделі.
Чому термінологія має принципове значення
- Якщо стендап проводиться як звіт про статус, що насправді втрачає команда?
- Коли «Методологія Agile» стала стандартним виразом, як це вплинуло на підхід організацій до трансформації?
- Які витрати команди, яка може назвати кожну практику Agile, але не розуміє призначення жодної з них?
У цій темі
За вашим запитом нічого не знайдено.
