Орієнтація на клієнта замість безповоротних витрат – Як уникнути пастки безповоротних витрат
Що спільного між гравцями онлайн-ігри Farmville та членами проектної команди? На перший погляд, небагато – одні будують віртуальну ферму, інші розробляють продукт. Але якщо придивитися, то можна побачити спільне: і ті, й інші інвестують час і зусилля в досягнення цілей.
Sunk costs - незворотні витрати
Що відбувається, коли гравець у Farmville в якийсь момент перестає відчувати бажання грати? Тяжко зароблений прогрес у грі знову зникає. І тут починається проблема: рішення про продовження гри приймається нераціонально. Замість того, щоб подумати про майбутні витрати і вигоди, люди думають про те, скільки часу вже було витрачено на гру. Цей інвестований час не можна повернути. Однак, щоб він не став “втраченим часом”, гравець вирішує витратити більше ресурсів.
Тож, хоча раціонально було б правильним рішенням закінчити гру, оскільки було б більше користі від використання часу по-іншому, ви продовжуєте грати. Хороша концепція, яку придумали розробники Farmville.
Приклад “безповоротних витрат
Наступний приклад показує, як це пов’язано з проектною командою: Після тривалого етапу розробки продукту, готовий продукт нарешті готовий. Команда задоволена; зрештою, вона вклала багато ресурсів (як часових, так і когнітивних та фінансових) у розробку. Наступний крок - презентація замовнику.
Команда заходить оптимістично налаштована, а виходить приголомшена: замовник інакше уявляв собі готовий продукт, змінилися вимоги. Тепер команда стоїть перед вибором: або вони починають з нуля і розробляють новий продукт, або залишають продукт, який вже розроблений (але не відповідає потребам замовника) і змінюють кілька дрібних речей.
Раціонально було б, щоб команда обрала розробку нового продукту, який відповідає вимогам і побажанням клієнта. Якби ж то не ті численні ресурси, які вже були інвестовані в розробку - ці кляті незворотні витрати.
Чому ми не можемо відпустити?
У “The Помилка безповоротних витрат описує саме цей випадок, коли подальші ресурси вкладаються в те, що виявилося нецільовим або навіть помилковим (Arkes & Blumer, 1985). Люди або команди, які схильні до цієї помилки прийняття рішень, зазвичай мають три спільні риси (Брокнер, 1992):
- Ви вже вклали багато часу, грошей, праці тощо.
- Вкладені ресурси не привели до успіху.
- Вони можуть вирішити, що робити далі: інвестувати в проект більше ресурсів чи скасувати проект.
Залишається питання, чому ми намагаємося врятувати корабель, який вже затонув. Психолог і нобелівський лауреат з економіки Деніел Канеман тримає в руках Теорія перспективи має готове пояснення: Люди бояться втрат (Канеман і Тверський, 1979). Цей страх заходить так далеко, що вони радше інвестуватимуть у малоймовірну можливість успішного завершення приреченого проекту, ніж змиряться з неминучою поразкою.
Sunk Costs vs. Клієнтоорієнтованість - Scrum як рішення?
Очевидно, що команди, які тримаються за провалені проекти, не приносять користі клієнтам. Але що можуть зробити команди, щоб не перетворитися на Помилка безповоротних витрат піддатися? Одна з відповідей полягає в гнучкій роботі. Орієнтація на клієнта є одним з найважливіших принципів. Завдяки такому визначенню пріоритетності цінності клієнта можна запобігти інвестуванню ще більших ресурсів.
Коли працюють Scrum-команди, замовник залучений до всього процесу розробки, щоб швидко реагувати на зміни потреб клієнта. Постійний обмін інформацією гарантує, що в кінці фази розробки не буде шокового моменту, коли стане зрозуміло, що клієнт очікував іншого продукту.
Ми готові відмовитися від уже виконаної роботи, якщо цього вимагає нове розуміння потреб клієнта. (Артикул Echometer)
Конкретно це означає, що команди повинні працювати в стислі терміни Спринти робота. На початку визначається, над чим працюватимемо впродовж наступних кількох тижнів. Наприкінці спринту перевіряється, чи були досягнуті поставлені цілі. Історії користувачів - важливий інструмент, який повинні використовувати Scrum-команди. Вони перетворюють вимоги замовника на орієнтоване на користувача твердження про продукт відповідно до формату:
Як Рулон. Я б хотіла Мета/бажанняЯ знаю, що це не так. Вигода.
Після створення користувацькі історії переносяться до беклогу продукту і забезпечують змістовну основу для роботи команди розробників. Як і багато концепцій в Scrum, історії користувачів не є статичними: якщо вимоги замовника змінюються, історія користувача також змінюється.
Це забезпечує надзвичайно високий рівень клієнтоорієнтованості. Оскільки Scrum-команди працюють самоорганізовано, важливо проаналізувати історії користувачів останнього спринту в ретро-спринті. Наприклад, можна зібрати причини, чому та чи інша історія пройшла добре чи погано, щоб забезпечити постійне вдосконалення.
Хочете розвиватися як команда? І враховувати останні психологічні дослідження? Тоді рекомендуємо наш командний воркшоп Retro Tool. Ось досвід Хольгера, який його пройшов:
Звіт Хольгера про використання інструменту командного воркшопуIn a nutshell…
Ітеративний підхід Scrum-команд та постійний аналіз потреб клієнтів допомагає уникнути безповоротних витрат. Інкременти продукту, що розробляються в спринтах, оптимально не повинні бути занадто ресурсоємними. Це призводить до того, що команда готова до нових цілей, коли вимоги змінюються. Чи стикалися ви з проблемою незворотних витрат у вашій команді? Спробуйте розглянути проблему в ретроспективі та розробити рішення разом!
А якщо вас цікавить ще більше методів підвищення ефективності роботи в команді, ви можете, наприклад, почитати про них у нашому Стаття про дивовижну правду, що стоїть за гнучким мисленням Поглянь.
Джерела
Аркес, Х. Р. та Блюмер, К. (1985). Психологія незворотних витрат. Організаційна поведінка та процеси прийняття рішень, 35124–140.
Брокнер, Дж. (1992). Ескалація прихильності до невдалого курсу дій: до теоретичного прогресу. Академія менеджменту Огляд, 17(1), 39-61.
Канеман, Д. та Тверскі, А. (1979). Теорія перспектив: аналіз рішень в умовах ризику. Econometrica, 47262–291.
