Команда скаржиться на затримки, і на обговоренні одразу з’являється пропозиція: потрібна нова система обліку завдань. Інший учасник радить додати людей, третій – посилити контроль. Варіантів уже багато, але учасники ще не погодили, що саме заважає роботі.
Щоб сформулювати проблему, потрібно описати розрив між фактичним і потрібним станом, перевірити спостереження та визначити межі дослідження. Після цього можна шукати рішення, яке відповідає конкретній ситуації. Інакше є ризик витратити ресурс на зміну, яка залишить головну перешкоду на місці.
Опишіть те, що спостерігаєте
Почніть із прояву проблеми: що відбувається, де, коли та кого це стосується? «Процес не працює» майже не дає напрямку для перевірки. «Заявки повертаються на уточнення після першого перегляду» вже вказує на події, які можна дослідити.
Зберіть кілька конкретних випадків і подивіться на їхні відмінності. Чи повертаються всі заявки? На якому етапі виникає затримка? Чи залежить вона від типу запиту? Важливо помічати і ситуації, у яких проблема не виникає: вони можуть допомогти перевірити пояснення.
Уточніть також, як фіксують саму подію. Якщо різні учасники по-різному визначають початок роботи або момент готовності, порівняння їхніх оцінок може вводити в оману.
Погодьте, якого стану потрібно досягти
Проблема стає зрозумілішою, коли є обґрунтоване очікування. Який результат потрібний і кому? Звідки взявся бажаний строк? Чи справді він погоджений із людьми, які виконують роботу та отримують її результат?
Окремо назвіть, що важливо зберегти. Наприклад, скорочення часу розгляду не має призвести до пропуску потрібної перевірки. Це допоможе уникнути рішення, яке покращить один показник ціною іншої важливої частини процесу.
Такий опис пов’язує дослідження з результатом роботи керівника. Ви з’ясовуєте, яка зміна потрібна спільній роботі та за якими ознаками згодом можна буде оцінити її користь.
Відокремте факт від пояснення причини
Спостереження «заявка чекала додаткової інформації» ще не доводить, чому ця інформація була відсутня. Можливо, вимогу не пояснили, потрібні дані з’являються пізніше або учасники користуються різними версіями форми.
Складіть короткий перелік можливих пояснень і для кожного визначте, що допоможе його перевірити. Наприклад, порівняти інструкцію з фактичними запитаннями, пройти шлях заявки з виконавцем або зіставити випадки із затримкою та без неї.
Якщо перевірити припущення зараз неможливо, позначте його як невизначеність. Не перетворюйте найбільш переконливу версію на підтверджену причину лише тому, що вона добре пояснює ваш попередній досвід.
Уточніть межі та учасників
З’ясуйте, яку ділянку ви досліджуєте та де починаються залежності від інших людей або процесів. Надто широке формулювання може зробити роботу безмежною. Надто вузьке – залишити поза увагою важливу причину.
Поговоріть із тими, хто подає запит, перевіряє його й використовує результат. Попросіть описати конкретний випадок. Різні учасники можуть бачити різні прояви тієї самої ситуації, тому корисно застосовувати уточнювальні запитання та перевіряти спільне розуміння.
Назвіть, хто має повноваження погоджувати зміни. Якщо причина перебуває за межами вашої відповідальності, це вплине на наступні дії. Водночас сам факт зовнішньої залежності ще не означає, що у своїй ділянці нічого не можна покращити.
Умовний приклад: заявки, які повертаються на уточнення
Уявімо невелику команду, яка обробляє внутрішні запити. Спочатку керівник описує проблему як «нам бракує автоматизації». Але після перегляду кількох заявок бачить, що затримки часто пов’язані з відсутніми вихідними даними.
Подальша розмова з учасниками показує: інструкція не пояснює, хто має надати ці дані та на якому етапі. При цьому не всі повернення мають однакову причину. Частина випадків потребує окремого дослідження.
Робоче формулювання стає конкретнішим: «На першому перегляді частину запитів повертають через відсутність потрібних даних; потрібно встановити, для яких типів запитів це відбувається та як має організовуватися їх підготовка». Це вигаданий приклад. Він ще не доводить, що зміни інструкції вистачить для розв’язання всієї проблеми.
Не вбудовуйте у формулювання готове рішення
Фрази «нам потрібен новий інструмент», «потрібно більше контролю» або «треба провести навчання» вже описують можливі дії. Щоб перевірити їхню доречність, поверніться до питання: яку підтверджену невідповідність кожна дія має усунути?
Спробуйте записати проблему без назви бажаного засобу. Наприклад: «Учасники не отримують підтвердження передачі запиту й повторно звертаються за його статусом». Так залишаються відкритими різні способи покращення, які можна буде порівняти пізніше.
Після аналізу переходьте до порівняння варіантів за критеріями. Якщо під час вибору з’являться нові факти, формулювання проблеми можна переглянути. Дослідження не обов’язково рухається лише вперед.
Коли можна завершити початкове дослідження
Не потрібно збирати всю можливу інформацію. Для початку визначте, які відомості можуть суттєво змінити рішення. Зважайте на доступний час, наслідки помилки й можливість виправити дію. У знайомій ситуації може вистачити перевірки, що стандартний порядок справді застосовний.
Для практики заповніть короткий опис: що спостерігаємо, чого очікуємо, кого це стосується, що підтверджено та що потрібно перевірити. Попросіть іншого учасника процесу прочитати його й указати, де ви додали припущення або пропустили важливу межу.
Результат цієї роботи – погоджений предмет подальшого рішення та перелік ключових невизначеностей. Він дає команді основу для вибору дії, яку згодом можна буде перевірити за змінами в реальному процесі.