Кнопкове мислення проти цілісного IT-продукту

Ця стаття — вираз моєї особистої болю. Кнопкові рішення псують мені життя, я витрачаю час на суперечки і обгрунтування.

Коли ми спілкуємося з колегами, клієнтами або користувачами, я використовую фразу «кнопкове мислення». Що я маю на увазі під цим терміном? Поточна стаття — розгорнуту відповідь на це питання.

Синонімами кнопкового мислення я вважаю «екранне мислення» або передчасну концептуалізацію. Я розкрию мислення кнопками на десятки прикладів з практики. А тут для початку історія, яка, напевно, траплялася з кожним. Уявіть до вас приходять і розповідають про падіння конверсії на сайті. А ви йому відразу: «Давайте кнопку покупки зробимо більше і яскравіше!». Що сталося? У бізнесі виникла проблема. Замість занурення в деталі, замість дослідження причин, ви граєте з розмірами кнопки. Ось в таких випадках я кажу про кнопковому мисленні.

Для тих, хто любить дивитися, а не читати, є відео та слайди.



Хто генерує кнопкові ідеї

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

1. Торопыги
Уявіть ситуацію, у якій замовник приносить проблему. Він ділиться цією проблемою з Торопыгой. Що робить Торопыга у відповідь? Відчуває тиск, як ніби замовник чекає відповіді, причому негайної. Після запитання замовника висить пауза, а відповіді в голові не з'явилося, напруга зростає. В своїй уяві Торопыга вже бачить, як замовник звинувачує бідолаху в некомпетентності. Тому замовнику видається рішення передчасне і необдумане.

Як бути, якщо помітили за собою недуг торопыжничества? По-перше, усвідомте, що неможливо знати всі відповіді. Придумування нальоту не ознака професіоналізму. По-друге, брати паузи в переговорах і нарадах — норма. Берете паузу, йдете думати. Приносьте з собою варіанти рішень, ризики по кожному, плюси і мінуси.

2. Рішали
Рішали — хлопці профі, які в IT собаку з'їли. Запитай — відразу дадуть відповідь. Хоча й не факт, що за плечима у них серйозні проекти і десятки років досвіду.

Для Рішали входять проблеми і завдання бачаться типовими, вже вирішеними. По фреймворку Cynefin Framework Рішали бачать світ в квадратику Obvious, ну максимум в Complicated. Тобто у них рішення вже готове, треба тільки вибрати категорію проблеми.

Рішали позбавляють себе шансу піднести замовнику пророблене рішення і вирости на нове завдання.

Замовник-вирішувала страшніше розробника-рішали, тому що любить проштовхувати Pet Features в продукт.

3. Рятівники

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

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

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

Я — могутній генератор кнопок

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

Напевно, у світі живуть айтішники зі сталевою волею. Вони здатні тримати себе в жорстких рамках, не вываливатся в роль Рішали або Спасителя. Я до таких не належу і періодично скатываюсь до однієї з ролей, а іноді в їх комбінацію.

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

Мимикрирующие User Story і хитрі Product Owner's

З джерелами кнопкового мислення розібралися. Тепер давайте розбиратися, що з ними робити. Чому ми даємо Решалам покерувати? Чому не відкидаємо поверхневі ідеї? Що убезпечить від власного решательства?

User Story як фільтр

Коли я думав про фільтри, що не пропускають кнопкові ідеї, згадалися User Story. Ми використовуємо історії для формування завдань проекту в повсякденній практиці. Сила User Story в тому, що вони змушують описувати цінність. Немає цінності в історії — немає зайвої кнопки в інтерфейсі.

Робота будуватися наступним чином. Вносиш в роботу ідею → опиши у вигляді User Story. Відповідай на питання «що?».

Хочеш кнопку вивантаження звіту в Excel. Ок, щоб що? Щоб було на всякий випадок? В смітник, не беремо в роботу.

Бухгалтер Оля сказала, що їй так подобається? В смітник, не беремо в роботу.

Ви порадилися всередині відділу економістів, намалювали кнопку в інтерфейс і тепер хочете, щоб ми її додали? Щоб що? Тому що це ваша ідея і вона вам подобається? В смітник, не беремо в роботу.

Ви замовник і ви так бачите? Іншого «аби що» немає? В смітник, не беремо в роботу. (хоча Pet Feature іноді ми реалізуємо, але для початку проговорюємо ризики і показуємо марність цієї затії).

Хитрі Product Owner's

User Story жорстко відсіває кнопкові ідеї. Перевірено на практиці. Але тут з'являється зворотний бік проблеми. Product Owner'и і stakeholder'и зрозуміли, що через User Story не пройти, тому що доводиться шукати відповідь на питання «що?». А це складно, якщо ти прийшов з Pet Feature. Складно, але сильно хочеться.

Product Owner'и підлаштуватися під нову модель постановки завдань. Вони навчилися грати в цю гру.

Я корпоративний клієнт
Хочу скачувати звіт про рух грошових коштів
бачити, що баланс став негативним


Недосвідчений розробник або дизайнер приймуть таку історію за правильну. Але придивіться до неї уважно. Перечитайте цю історію і спробуйте прикинути, які питання у вас виникнути до Product Owner'у.

Я б для початку поцікавився про подальшу жизниь скачаного звіту. Про життя користувача, який завантажить цей звіт. Що він знайде в звіті? З допомогою чого знайде потрібне? Як він відділить потрібне від непотрібного?

Мимикрирующие User Story

Хоч і формат User Story дотриманий, але без занурення і додаткових питань в роботу не приймаємо. Копаємо, шукаємо корені проблеми. Ставимо відкриті питання, використовуємо 5 Why. З часом дізнаємося корінь проблеми і записуємо в User Story:

Я корпоративний клієнт
Не розумію в якому стані рахунок і з-за цього йду в мінус
Хочу



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

Наступний крок — зрозуміти як ми змінимо життя корпоративного клієнта, щоб він вирішив цю проблему. Gojko Adzic в книзі Quick Ideas To Improve Your User Stories вказує на те, що краще прописувати в User Story дельту між тим, як користувач жив до релізу і тим, як він заживе після релізу. Отримуємо таку історію:

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


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

В останній версії User Story кнопкове рішення прибрано. Розкопана коренева проблема. Запропоновано рішення, яке закриє кореневу проблему. З'явився шанс нанести користь після релізу, а не додати ще одну кнопку для скачування ще одного звіту.

Передчасні рішення

Деяким людям кортить випалити рішення. Вони ніби грають в Свою Гру або Брейн Ринг. Чекають на питання і на швидкість пропонують рішення.



При поспішних рішеннях між проблемою і ідеєю виникає сліпа зона. Ланцюжок міркувань і висновків залишається за кадром:



Ми не приймаємо рішення, копаємо корінь проблеми, визначаємо дійових осіб. Після прокладання колії з мети, дійових осіб і кореня проблеми кнопкове рішення втрачає колишню міцність:



Побачивши кореневу проблему або потребу, ми накидаємо багато можливих рішень:



Зверніть увагу, що тепер видно вибір, але сам вибір зробити складніше. У мене є припущення, що люди навмисне зупиняються на першому рішенні, яке видається слушним. Адже якщо йти далі, то доведеться вибирати, оцінювати ризики кожного рішення, плюси і мінуси, роботи додається. Крім того, чим ширше вибір, тим менше радість підсумкового рішення.

Глибоке буріння проблеми затратно, ніхто не прагне в це болото. Але якщо ми створюємо корисне рішення, то пересиливаем себе і розкриваємо сліпу зону.

Історії з життя:

  • Кейс: Звуження бачення
    Йде планування релізу. Product Owner закінчує фразу словами: «… можна надіслати поштою». Я відразу зупиняю обговорення, тому що однією фразою відбулося звуження проблематики до одного рішення. Останавились і розкопали корінь потреби. Чому відправляти? Чому поштою? У світі ж придумано багато способів донесення інформації до користувачів. У підсумку запропонували 5 способів розповісти клієнтам про оновлення. Порада: Не допускайте звуження проблеми до одного рішення.
  • Кейс: Рішення без проблеми
    Новий замовник обговорює з нами модернізацію ІТ-продукту. Поки розповідає про продукт, згадує про проблему — клієнти йдуть в мінус і перерасходуют ресурси без оплати. Сервіс бере гроші у міру здійснення операції, але передбачити витрати заздалегідь не можна. У міру розповіді замовника відвідує ідея — обрубувати доступ і залишати клієнта без результату.
    Обговорення перервали, розкопали проблему користувачів. З'ясувалося, що користувачі не розуміють скільки грошей залишається в кожен момент часу, тому не можуть оперативно приймати рішення. Ми запропонували показувати їм витрати і поточний баланс, що змінюються в онлайн режимі. Замовник здивувався і сказав: А що так можна?


Скільки коштують 1000 рядків коду?

Уявіть сцену в магазині. Ви набрали продуктів в кошик і підійшли до каси. Касир пробив товари, зважив фрукти і овочі, назвав вартість. Типова ситуація для покупки продуктів.



Сцена один в один при створенні IT-продукту. Ви сидите на касі, приходить замовник з кошиком фіч і рішень. Ви оцінюєте, зважуєте, говорите йому вартість.

Давайте повернемося в магазин і переиграем ситуацію. Ви підходите до каси, викладаєте покупки. Продавець вам каже: «Даремно ви взяли помідори Шеди Леді для рагу з кролика. Цей сорт дуже солодкий, для рагу не підійде. Візьміть сорт Маленький принц, рагу з ними відмінне».

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

Тепер повернемося до IT. Для виявлення цілей, розуміння шляху досягнення цілей, формування вибору рішень я рекомендую Impact Mapping:



Техніка вивчається за пару днів. З допомогою Impact Mapping ми прокладаємо шлях з рішень до мети, приоритизируем рішення і шляхи, відсікаємо Pet Feature, які йдуть з боку бізнесу і з боку команди. Єдина складність — процес створення Impact Mapping, він вимагає навичок фасилітації.

Історії з життя:

  • Кейс: Потрібно більше спливаючих вікон
    Уявіть собі IT-відділ всередині компанії. Керівники відділу маркетингу, економіки та інших ставлять завдання ІТ-відділу. Приходить начальник, що відповідає за точки продажів і ставить завдання — додати спливаюче повідомлення раз в 10 хвилин на робочому місці. Працівників і на місцях зобов'яжуть натискати ОК у модальному вікні кожні 10 хвилин, щоб зрозуміти на місці працівник чи ні. Завдання як завдання, IT-відділ взяв та й зробив. Минув час. Працівники на місцях зжилися з нововведенням.

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

    На місцях це вилилося в суперечливий сценарій. Працівнику спливає повідомлення, що треба йти на вулицю і роздавати листівки. Він виходить і роздає, а в цей час спливає повідомлення: «Ти на місці?».

    Чому так сталося? Ніхто не конролировал цілісність системи. Багатоголовий Product Owner приносив завдання, розробники брали завдання без питань.
  • Кейс: Навіщо робимо?
    Замовник прийшов до нас з ідеєю зробити додаток для кур'єрів. Замовник — федеральна компанія, сотні філій по країні. Мета продукту — оптимізації роботи кур'єрів.

    До роботи з нами у проекту накопичилася піврічна історія. Замовнику зробили ТЗ, реалізували частину мобільного клієнта, але не зробили серверну частину. З цією історією замовник прийшов до нас. Ми почали проект нашому процесу і вже до кінця Customer Journey Mapping замовника осінило. Вони поміняли бізнес-модель, запустили ряд експериментів в бізнесі і обіцяли повернутися до нас через 3 місяці. Ми вважаємо це успіхом, т. к. не дозволили витратити час на даремний продукт.


Рух без мети

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

Коли ми беремо завдання, то зіставляємо вартість задачі з ефектом, який завдання матиме на досягнення мети. А якщо цілі немає? Значить і порівнювати не з чим. Звідси народжується стиль роботи, коли завдання реалізуються, тому що прикольно ці завдання реалізувати. У таких відділах розробки кипить життя, фічі додаються, йдуть безперервні релізи. При цьому бурхливому русі, результат не змінюється.

Історії з життя:

  • Кейс: Покажемо тому що можемо
    Продукт — SaaS-інструмент для партнерів топової e-commerce Росії. Діалог з ІТ-підрозділом замовника:
    — Давайте виведемо договори в інтерфейсі, – говорить розробник з боку замовника.
      Щоб що? – відповідаємо ми.
    — Вони вже лежать в БД, можна легко вивести.
    — це допоможе досягти цілей продукту?
    — Без договорів неможливо заплатити!
      Щоб заплатити, потрібно почати користуватися продуктом, а він ще не існує.

    В таких випадках допомагає тільки повернення до цілей проекту і фільтрація за допомогою Impact Mapping.


Саморефлексія і душевний спокій

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

  1. Коли до вас прийшли до кнопкової ідеєю, запитайте себе чому вони принесли таке рішення, чому воно не подобається вам, які питання виявлять корінь проблеми. Тільки після цього починайте говорити.
  2. Зрозумійте, що колеги не зі зла лізуть з кнопковими ідеями. Ніхто не хоче нашкодити або саботувати. Всі намагаються принести користь.
  3. Керуйте на рівні досягнення бізнес-цілей, а не завдань
  4. Ставите перед командою проблеми, а не приходьте з рішеннями
  5. Робіть короткі ітерації (1 тиждень або коротше), постійно збирати зворотний связьи з команди і клієнтів
  6. Валідація ідей як можна раніше, вбивайте ідеї до етапу реалізації


Рекомендації однаково банальні і дієві. Мені в роботі допомагає.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.