Problem Solving: 7 факторів для визначення і правильного аналізу проблеми

A problem : a difference between the actual situation and the desired situation.

Думаю, багатьом попадався друг або колега, який або яка може все. До них можна прийти з будь-якою проблемою — і вони знайдуть рішення. Причому часто таке, про яке ти не підозрював, хоча вивчив вже все вздовж і впоперек. Мені вони завжди здавалися суперлюдьми. І є певні способи, якими ці суперлюди користуються.

Хоча «problem solving» перекладається як «рішення завдань», я залишу термін «проблема» замість більш вузького —«завдання».

Фактично все, що ми робимо кожен день на роботі, це problem solving. Велику частину часу у нас традиційно займає рішення: ми любимо свої рішення, оптимізуємо їх, довго обдумуємо. Ми раді, коли придумуємо рішення, і нам подобається приводити його в життя крок за кроком. Для програміста це може бути алгоритм, для менеджера — стратегія, для рекрутера — план дій. Ми так захоплюємося рішенням, що часто забуваємо, яку проблему він вирішує.

Проблема, яку ми зайняті, може здаватися очевидною, але часто, коли з'являється контекст або думка стейкхолдерів, з'ясовується, що ми вирішували проблему, яку більше ніхто не бачив, чи наше рішення працює тільки для «сферичного коня».

Я хочу поділитися простим фреймворком аналізу проблем, який допомагає ідентифікувати потрібну проблему і знайти її оптимальне рішення.

Малюнок автора

Аналіз проблеми

Для визначення проблеми і натхнення ідеями потрібно мати повний контекст ситуації, куди входить:

Що вирішуєте?
Чому виникає проблема? (т. зв. root cause, використовуйте 5 whys при необхідності)
Навіщо це потрібно?
Для кого вирішуєте?
Як часто виникає проблема?
При яких умовах?
Який бюджет/строк на вирішення?

Не всі з цих семи параметрів кожен раз будуть однаково допомагати виявити справжню проблему: іноді це один параметр, іноді — п'ять, і складно відсортувати їх по пріоритету. Фреймворк не строгий. Але відштовхуйтеся від реальної задачі, яку потрібно вирішити .

З боку менеджменту важливо об'єктивно описати проблему, а команді потрібно переконатися, що вона зрозуміла її вірно. Якщо щось з контексту не зрозуміло або бракує інформації, запитуйте. Можете цими питаннями поставити менеджмент в незручне становище, і їм теж доведеться задуматися і роздобути вам дані.

Часта помилка: сфокусуватися на самому описі проблеми, зробити її абстрактній і опрацювати універсальне рішення на противагу конкретного.

Обмеженість ресурсів

Багато хто з нас перфекціоністи, і ми хочемо, щоб наше рішення було самим міцним, надійним і взагалі ідеальним за своєю красою. Але рішення, красиві у реалізації і враховують всіляке кількість деталей, зазвичай дуже довгі і дорогі. Тому рішення, яке ми пропонуємо, має бути good enough, щоб вирішити саме ту проблему, яка стоїть перед нами, а не ще потенційні десять.

У будь-якого бізнесу ресурси обмежені, це частина контексту, яку потрібно мати на увазі.

Так в чому проблема

Мій улюблений приклад — про аеропорт Х'юстона, який часто розбирають на семінарах з тематикою «Чого хоче кастомер?». Пасажири почали скаржитися, що дуже довго чекають багаж. Вони прилетіли, пройшли паспортний контроль, прийшли до багажних стрічок і довго чекають. З'ясували, що час очікування — в середньому 10 хвилин, наприклад. Аеропорт виділив бюджет на те, щоб прискорити доставку багажу, і після декількох місяців оптимізації вдалося скоротити час очікування з 10 до 8 хвилин. Скарги не пропали.

Тоді було прийнято рішення змінити маршрут пасажирів і зробити його на 8 хвилин довше, щоб, коли вони приходили до багажних стрічок, багаж уже був там. Скарги припинилися. Тобто спочатку компанія взялася вирішувати не ту проблему, і для другої проблеми було більш просте і дешеве рішення — пустити пасажирів через більш довгий коридор.

Проаналізуємо контекст за допомогою нашого фреймворку:

Питання	?	?
Що вирішуєте?	Зменшити кількість скарг від клієнтів	Низька швидкість доставки багажу
Чому виникає проблема?	Коли пасажири приходять до стрічки, багажу ще немає. Чому? Пасажири приходять до місця швидше, ніж багаж. Чому? Їм потрібно пройти один коридор, а машині з багажем треба зробити об'їзд	Машині з багажем потрібно зробити об'їзд
Навіщо це потрібно?	Поліпшити імідж компанії і знизити навантаження на саппорт	Прискорити доставку багажу на стрічку
Для кого вирішуєте?	Всі пасажири внутрішніх рейсів (це питання важливе, щоб зрозуміти відсоток порушених кастомеров)
Як часто виникає проблема?	Кожний раз (це питання важливе, щоб зрозуміти частоту виникнення проблеми)
При яких умовах?	При будь-яких (тут важливо зрозуміти, це звичайні умови або екзотичні, а також отримати будь-які дані, які допоможуть дебаггингу)
Бюджет/термін	2 тижні	3 місяці

Видно, що замість того, щоб зосередитися на рівні виникнення проблеми, тобто кастомерских скаргах, зосередилися рівнем нижче, на одному з можливих рішень.

Основні складності

Найбільша помилка, звичайно — не аналізувати проблему взагалі. Але навіть коли беремося за аналіз, ми скрізь стикаємося з труднощами.

При визначенні, що вирішуєте	Некоректна постановка задачі; відхід від problem space solution space (не врахувати, звідки прийшла проблема; сконцентруватися на одному можливе рішення).
При визначенні root cause	Пошук root cause не тієї проблеми; зупинитися на поверхневому факторі/симптомі; брак debugging-скілів/інфи.
При визначенні, навіщо потрібне рішення	Забути про кастомерах; сфокусуватися не на тій проблемі; не врахувати мотивацію залучених сторін; не врахувати позиції продукту на ринку (наприклад, шукає product market fit або вже необхідно наростити стабільність).
При визначенні, для кого потрібно рішення	Шукати рішення для менеджменту замість рішення для кастомера; не врахувати, для якого сегмента користувачів і який розмір цього сегмента.
При визначенні частоти виникнення проблеми	Брак статистики; невірна оцінка. (як наслідок, переоцінка або недооцінка серйозності проблеми)
При визначенні умов виникнення проблеми	Брак статистики; брак debugging-скілів/інфи. (як наслідок, переоцінка або недооцінка серйозності проблеми)
При визначенні вартості рішення	Не враховувати, які ресурси є для рішення; не оцінювати і не зважувати кілька можливих рішень.

Приклади аналізу

Давайте розберемо ще кілька проблем з допомогою цього фреймворку і помилки в їх аналізі.

Визначення сегменту

Пише кастомер в саппорт, що не може завантажити свій CSV. При розгляді файлу з'ясовується, що формат трохи відрізняється від того, який підтримує система. Яке рішення здається очевидним? Проапдейтить систему і почати підтримувати цей формат. Але додамо контекст:

Питання	?	?
Що вирішуєте?	Неможливість завантажити файл певного формату
Чому виникає проблема?	У файлу інше кодування. Чому? Кастомер згенерував його за допомогою старої версії системної програми.
Навіщо це потрібно?	Новий кастомер хоче спробувати продукт, для цього йому потрібно свої завантажити дані з CSV	Підтримувати файли, згенеровані в старій версії
Для кого вирішуєте?	Конкретно для цієї людини, більше таких прохань не було	Для всіх, хто генерує файли старої версії
Як часто виникає проблема?	Дані потрібно завантажити тільки один раз, для того щоб далі користуватися фичей	При кожному завантаженні

Коли бачимо контекст, з'являється інше рішення — сконвертувати своїми силами кастомерский файл в один з підтримуваних форматів і завантажити його вручну. Це дасть можливість кастомеру відразу ж спробувати продукт. Звичайно, це рішення не масштабоване (якщо завтра буде 50 таких запитів, ми не впораємося), не абстрактне (працює тільки для цього файлу, а не для всіх такого формату) і зовсім неизящное з точки зору інженерії. Але воно швидке, не ускладнює систему і вирішує реальну проблему , а не ту, що може виникнути завтра.

Інший приклад: на сервіс пішла підвищене навантаження, і всі процеси починають падати, тому що їм не вистачає пам'яті. Сталося це тому, що прийшов один кастомер, який додав дуже багато даних на обробку. Варіант рішення: оптимізація продуктивності. Займе тиждень і запобігає повторення, якщо прийде ще один такий кастомер (в чому немає впевненості). Повертаючись до проблеми, варіант другий — обмежити кількість пам'яті, що один процес може собі забрати. Це сповільнить швидкість обробки даних для всіх кастомеров, але рішення моментальне, повертає працездатність сервісу, і «важкий» кастомер отримає свій результат вже через добу.

Питання	?	?
Що вирішуєте?	Процеси падають	Поточна імплементація їсть багато ресурсів
Чому виникає проблема?	Багато навантаження. Чому? Кастомер у своєму акаунті додав багато завдань. Чому? Опрацьовує дуже складне замовлення	Всі завдання відразу додаються в пам'ять
Навіщо це потрібно?	Щоб всі процеси всіх кастомеров коректно відпрацювали	Щоб складні замовлення швидко оброблялися
Для кого вирішуєте?	Для всіх кастомеров	Для будь-якого кастомера, який додасть багато завдань
Як часто виникає проблема?	Поодинокий випадок	Кожен раз
При яких умовах?	Якщо хтось додав багато завдань

Фокусування на одному рішенні

Кастомер скаржиться, що у нього підвисає інтерфейс. Інтуїтивне рішення — оптимізація продуктивності. Якщо таких кастомеров мало, а бюджет невеликий, то додавання лоадерів вирішить проблему. Часто в таких випадках проблема не в швидкості, а в тому, що інтерфейс не відповідає, і користувач не розуміє, що відбувається. В такому випадку втрачається відчуття контролю над ситуацією і з'являється дискомфорт. При наявності лодера кастомер буде знати, що треба почекати; система стає для нього передбачуваною.

Питання	?	?
Що вирішуєте?	Скарга від клієнта на повисла інтерфейс	Гальма на фронтенде
Чому виникає проблема?	При певних діях інтерфейс завмирає, і користувач не розуміє: все в порядку або ж дані загубилися. Чому? Приходить багато даних, і фронт не встигає їх обробляти. Чому? Стара js-ліба стала погано працювати в нових версіях FF
Навіщо це потрібно?	Зберегти клієнта	Поліпшити продуктивність
Для кого вирішуєте?	Користувачі FF, у яких включена певна фіча і є більше 20 записів
Як часто виникає проблема?	Кожен раз при відкритті фічі
При яких умовах?	FF, доступ до фиче, понад 20 записів

Або, приміром, програмісту потрібно отримати SSH-доступ до сервера, для того щоб виконати певну команду, а у хостера цього доступу з коробки немає. Можна піти шляхом читання документації, заглибитися в неї на день, нічого не знайти і відзвітувати про те, що документація прочитана. Яку проблему вирішили? Ознайомлення з документацією. Менеджмент таку задачу поверне назад, тому що споконвічна проблема не вирішена. Якщо документація не допомогла, можна написати в саппорт або запитати в community.

Питання	?	?
Що вирішуєте?	Виконати команду на сервері	Отримати SSH-доступ до сервера

Рішення, не зважений по вартості

У систему кожен місяць потрібно додавати 200 IP, отриманих з третього джерела. Для цього їх потрібно перетворити у відповідний формат і скопіювати в спеціальну форму, видаливши попередньо попередні 200 IP. Можна це автоматизувати? Так. Піде два дні (16 годин), щоб запрограмувати, протестувати і задеплоить. Копі-пейст вручну з виправленням формату на потрібний займає 10 хвилин кожен місяць, тобто 2 години на рік. За 8 років вартість автоматизації зрівняється з вартістю ручної роботи. Щоб автоматизація стала вигідніше ручного рішення, потрібно, щоб продукт і ця фіча проіснували понад 8 років . Якщо ви не впевнені, то не варто вкладатися в автоматизацію.

Питання	?	?
Як часто виникає проблема?	1 раз в місяць	Кожен раз
Який бюджет/строк на вирішення?	10 хвилин	16 годин

Інше рішення при тому ж бюджеті

Потрібно знайти фуллстек-розробника на проект. Рекрутер з ніг збився — нікого немає. Фуллстек потрібен, щоб робити роботу по фронту і беку. Знаючи бюджет (10 000) і передбачуване завантаження, можна відкрити дві вакансії (по 5 000): на фронт і бек, можливо, парт-тайм.

Питання	?	?
Що вирішуєте?	Знайти людей для делівері проекту	Знайти фуллстека
Який бюджет/строк на вирішення?	10 000	10 000

Некоректна мета

Є паралельно запущені процеси, і кожного перед стартом треба взяти проксі з фіксованого списку. Бізнес хоче подивитися, як зміняться повернуті результати, якщо процеси будуть ходити під проксі.

Базове рішення зрозуміло, але в процесі до нього додається фіча балансування і ротації проксі; тобто, якщо одну проксі використовували 10 разів, а другу — 5, наступного разу треба брати ту, яку використовували менше, тобто другу. Дуже гарне рішення, якщо є проблеми з баном або необхідністю рівномірно розподіляти трафік. Фактично воно вирішує проблему, якої немає.

Питання	?	?
Що вирішуєте?	Отримати більш точні результати з використанням проксі	Рівномірний розподіл навантаження між проксями
Чому виникає проблема?	При використанні одного і того ж IP сервіс за своїм причин віддавав невірні дані	Базова реалізація бере першу-ліпшу проксі
Навіщо це потрібно?	Перевірити, чи готові кастомеры платити за такої точності	Рівномірно розподілити трафік і мінімізувати ймовірність бана

Межа між проблемою та рішенням

Так теоретично можна розділити сфери, де закінчується проблема і починається рішення. І чим довше ми засиджуємося в області рішення, тим менше у нас залишається ресурсів на область проблеми.

Можна уявити ситуацію і так: завжди залишаючись в problem space, перебрати, зважити і знайти краще solution.

Є відмінна міська легенда , яку на митапах люблять використовувати як вступ до теми overengineering. Треба було розробити рішення, ніж писати в умовах космосу. І поки одна група інженерів вирішувала, як адаптувати кулькову ручку до умов невагомості (кроки з розробкою чорнила і поршня), друга група запропонувала використовувати олівець.

Чим далі ми заглиблюємося в деталі нашої реалізації, тим далі ми від самої проблеми. Тому на момент вибору рішення потрібно переконатися, що ми точно розуміємо проблему й перебрали всі можливі рішення.

Неправильне напрям: ніхто не щасливий в кінці

Якщо спочатку взялися вирішувати не ту проблему або куди-то сильно відхилилися в процесі рішення, в результаті не буде задоволений ніхто. Бізнес не отримає, що хотів, менеджмент буде рахувати збитки, а інженерам ніхто не скаже спасибі.

Не всі проблеми — проблеми

Чому ще важливо мати рішення «в точку» і найшвидше? Тому що не всі проблеми виявляються проблемами, і чим швидше це стане ясно, тим вигідніше. Мені подобається історія , як аргентинська компанія запускала свій додаток в Бразилії. У багатьох ресторанах є жива черга, то є ти приходиш, просиш столик на двох і тебе просять 40 хвилин почекати. Компанія вирішила зробити бронювання через додаток: тобі дається список ресторанів, ти вибираєш, який, скільки, і приходиш без черги. Відмінна ідея. Аппку довго полірували, укладали контракти з ресторанами, і в підсумку ідея провалилася. Як з'ясувалося, для бразильців стояння в черзі не було проблемою \_(?)_/

Виконання інструкцій — це не вирішення проблем

Детально розписані вимоги, іноді аж до if-else, рідко призводять до хорошого результату. Дотримання таких вказівок — це не вирішення проблем. Виходить, що людина, які такі вимоги просить/отримує, не хоче/не може бачити, що він вирішує насправді. Звідси беруться і воркэраунды для corner cases, які ніколи в реальному житті не відбудуться, закладається фундамент для потенційних фичей, яких ніколи не буде і оптимізується те, що ніхто не оцінить. У моїй практиці кращі рішення виходили, коли максимально описували контекст і те, що вирішуємо. Тоді команда створює найкраще рішення, тому що це якраз їх компетенція.

Наступні кроки

Ну і після того, як ми правильно визначили вирішувану проблему, справа залишається за рішенням і комунікацією:

Визначте проблему та інтереси всіх сторін.
Перелічіть можливі рішення.
Оцініть варіанти.
Виберіть варіант.
Задокументуйте угоду про вибраному варіанті.
Домовтеся, як моніторити і оцінити результат і що робити у випадку непередбачених обставин.

На завершення

Тема вирішення проблем дуже складна, і торкається вона не тільки IT. Сьогодні немає загального фреймворку і навіть якогось загального підходу з-за унікальності проблем, з якими ми стикаємося. Я думаю, це та сфера, куди ІІ добереться в останню чергу, тому що в процесі аналізу зачіпається дуже багато асоціативних зв'язків. Але я знаю, що в нашій індустрії ми вже дуже добре справляємося з рішеннями, і хотілося б, щоб ми стали краще у визначенні того, навіщо ми це робимо.

Опубліковано: 09/04/20 @ 07:00
Розділ Різне

SEO Блог