Примітка: Сайт перекладено автоматично. Переключіться на англійську для кращого читання.

one_way

Орієнтація на клієнта замість безповоротних витрат – Як уникнути пастки безповоротних витрат

Що спільного між гравцями онлайн-гри Farmville та членами проектної команди? На перший погляд, не так багато – Один будує віртуальну ферму, інший розробляє продукт. Але якщо придивитися уважніше, їх об'єднує те, що вони обидва вкладають час і зусилля в досягнення цілей.

Безповоротні витрати – безповоротні витрати

Що відбувається, коли гравець у Farmville в якийсь момент перестає відчувати бажання грати? Тяжко зароблений прогрес у грі знову зникає. І тут починається проблема: рішення про продовження гри приймається нераціонально. Замість того, щоб подумати про майбутні витрати і вигоди, люди думають про те, скільки часу вже було витрачено на гру. Цей інвестований час не можна повернути. Однак, щоб він не став "втраченим часом", гравець вирішує витратити більше ресурсів. 

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

Приклад "безповоротних витрат

Наступний приклад показує, як це пов'язано з проектною командою: Після тривалого етапу розробки продукту, готовий продукт нарешті готовий. Команда задоволена; зрештою, вона вклала багато ресурсів (як часових, так і когнітивних та фінансових) у розробку. Наступний крок - презентація замовнику. 

Команда заходить оптимістично налаштована, а виходить приголомшена: замовник інакше уявляв собі готовий продукт, змінилися вимоги. Тепер команда стоїть перед вибором: або вони починають з нуля і розробляють новий продукт, або залишають продукт, який вже розроблений (але не відповідає потребам замовника) і змінюють кілька дрібних речей. 

Раціонально, команда мала б прийняти рішення про розробку нового продукту, який відповідає вимогам і побажанням замовника. Якби тільки не всі ті ресурси, які вона вже вклала в розробку –, не ті дурні безповоротні витрати.

Чому ми не можемо відпустити? 

У "The Помилка безповоротних витрат описує саме цей випадок, коли подальші ресурси вкладаються в те, що виявилося нецільовим або навіть помилковим (Arkes & Blumer, 1985). Люди або команди, які схильні до цієї помилки прийняття рішень, зазвичай мають три спільні риси (Брокнер, 1992): 

  1. Ви вже вклали багато часу, грошей, праці тощо.
  2. Вкладені ресурси не привели до успіху. 
  3. Вони можуть вирішити, що робити далі: інвестувати в проект більше ресурсів чи скасувати проект. 

Залишається питання, чому ми намагаємося врятувати корабель, який вже затонув. Психолог і нобелівський лауреат з економіки Деніел Канеман тримає в руках Теорія перспективи має готове пояснення: Люди бояться втрат (Канеман і Тверський, 1979). Цей страх заходить так далеко, що вони радше інвестуватимуть у малоймовірну можливість успішного завершення приреченого проекту, ніж змиряться з неминучою поразкою.

Безповоротні витрати проти клієнтоорієнтованості – Скрам як рішення?

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

Коли працюють Scrum-команди, замовник залучений до всього процесу розробки, щоб швидко реагувати на зміни потреб клієнта. Постійний обмін інформацією гарантує, що в кінці фази розробки не буде шокового моменту, коли стане зрозуміло, що клієнт очікував іншого продукту. 

Ми готові відмовитися від уже виконаної роботи, якщо цього вимагає нове розуміння потреб клієнта. (Артикул Echometer)

Конкретно це означає, що команди повинні працювати в стислі терміни Спринти робота. На початку визначається, над чим працюватимемо впродовж наступних кількох тижнів. Наприкінці спринту перевіряється, чи були досягнуті поставлені цілі. Історії користувачів - важливий інструмент, який повинні використовувати Scrum-команди. Вони перетворюють вимоги замовника на орієнтоване на користувача твердження про продукт відповідно до формату:

Як Рулон.  Я б хотіла  Мета/бажанняЯ знаю, що це не так. Вигода.

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

Це забезпечує надзвичайно високий рівень клієнтоорієнтованості. Оскільки Scrum-команди працюють самоорганізовано, важливо проаналізувати історії користувачів останнього спринту в ретро-спринті. Наприклад, можна зібрати причини, чому та чи інша історія пройшла добре чи погано, щоб забезпечити постійне вдосконалення.

Хочете розвиватися як команда? І враховувати останні психологічні дослідження? Тоді рекомендуємо наш командний воркшоп Retro Tool. Ось досвід Хольгера, який його пройшов:

У двох словах...

Ітеративний підхід Scrum-команд та постійний аналіз потреб клієнтів допомагає уникнути безповоротних витрат. Інкременти продукту, що розробляються в спринтах, оптимально не повинні бути занадто ресурсоємними. Це призводить до того, що команда готова до нових цілей, коли вимоги змінюються. Чи стикалися ви з проблемою незворотних витрат у вашій команді? Спробуйте розглянути проблему в ретроспективі та розробити рішення разом!

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

Джерела

Аркес, Х. Р. та Блюмер, К. (1985). Психологія незворотних витрат. Організаційна поведінка та процеси прийняття рішень, 35124–140.

Брокнер, Дж. (1992). Ескалація прихильності до невдалого курсу дій: до теоретичного прогресу. Академія менеджменту Огляд, 17(1), 39-61.

Канеман, Д. та Тверскі, А. (1979). Теорія перспектив: аналіз рішень в умовах ризику. Econometrica, 47262–291.

Поділіться цією статтею зі своїми знайомими

Потрібен командний поштовх? Ось що вам потрібно зробити: Ретроспектива Spotify Health Check!

Перше питання про здоров'я: "😍 Ми із задоволенням ходимо на роботу і отримуємо задоволення від спільної праці".

Хочете ще? Спробуйте наш Retro Tool зараз.

Більше статей

Оцінка ефективності роботи розробника програмного забезпечення: інструкції та шаблон

Письмові оцінки ефективності для розробників програмного забезпечення у 2025 році? У сучасному робочому середовищі, яке наголошує на культурі зворотного зв'язку та безперервному розвитку, письмові відгуки про роботу

Читати далі "

Інформаційний бюлетень Echometer

Не пропустіть жодного оновлення на Echometer та отримайте натхнення для гнучкої роботи