جایگزینی پرسونای فرضی با محرک‌های موقعیتی؛ بازتعریف نیازمندی‌های نرم‌افزار با جاب استوری

در سال ۲۰۱۳، تیم طراحی محصول در اینترکام (Intercom) به رهبری پل آدامز متوجه شد نیازمندی‌های ثبت‌شده نرم‌افزاری دلیل واقعی استفاده مشتریان از ابزارهایشان را بازتاب نمی‌دهد. این شرکت که اکنون به بیش از ۲۵ هزار کسب‌وکار خدمات می‌دهد، در تبدیل بازخورد کاربران به قابلیت‌های کاربردی و قابل اتکا دچار چالش شده بود.[1]

آن‌ها از فرمت استاندارد یوزر استوری (User Story) استفاده می‌کردند که با تعریف یک پرسونا شروع می‌شد. اما دانستن اینکه یک کاربر، مدیر بازاریابی ۳۵ ساله است، توضیح نمی‌داد چرا او باید دقیقاً ساعت ۴ بعدازظهر روز جمعه لیست مشتریان را فیلتر کند.[1]

برای حل این مشکل، آدامز و تیمش مفهوم پرسونا را به طور کامل کنار گذاشتند. آدامز در تحلیل اولیه این چارچوب نوشت: «ما هر مسئله طراحی را در قالب یک 'شغل' یا وظیفه (Job) صورت‌بندی می‌کنیم و روی رویداد یا موقعیت آغازگر، انگیزه و هدف، و در نهایت نتیجه مورد نظر تمرکز می‌کنیم.»[1]

نقص‌های ساختاری پرسونای فرضی

برای دهه‌ها، متدولوژی توسعه چابک بر یوزر استوری تکیه کرده تا نیازمندی‌های نرم‌افزاری را تعریف کند. این ساختار در تمام صنعت شناخته‌شده است و هر ویژگی را در این الگو می‌گنجاند: «به عنوان [نقش]، می‌خواهم [اقدام]، تا [نتیجه].»[4]

نقص اصلی این ساختار سنتی در بند ابتدایی آن نهفته است. پیوند زدن نیازمندی نرم‌افزار به یک نقش یا پرسونای جمعیتی، ناخودآگاه این فرض اشتباه را ایجاد می‌کند که هویت فردی یا جمعیت‌شناختی کاربر تعیین‌کننده رفتار اوست.[2]

آلن کلمنت، طراح محصولی که به استانداردسازی این رویکرد جایگزین کمک کرد، در سال ۲۰۱۳ یادآور شد که پرسونای فرضی یک شکاف علیتی عمیق بر جای می‌گذارد. مشخصات جمعیتی دلیلی برای چرایی خرید یک محصول ارائه نمی‌دهد؛ بلکه شرایط و موقعیت‌های خاص هستند که تصمیم‌گیری را هدایت می‌کنند.[2]

اگر تیمی فیچری را برای یک «فرد میانسال با تحصیلات دانشگاهی» توسعه دهد، در حقیقت انگیزه او را حدس می‌زند. این نوع پرسونا حس کاذبی از همدلی ایجاد می‌کند اما در عمل مشکل واقعی کاربر را پنهان می‌سازد.[5]

جاب استوری چگونه کار می‌کند؟

اینترکام برای پر کردن این شکاف، نظریه «کارهایی که باید انجام شوند» (Jobs-to-be-Done) از کلایتون کریستنسن، استاد مدرسه کسب‌وکار هاروارد، را به یک ساختار زبانی کاربردی برای تیم‌های نرم‌افزاری تبدیل کرد. کریستنسن مطرح کرده بود که مشتریان محصولی را نمی‌خرند، بلکه آن را «استخدام» می‌کنند تا در یک موقعیت خاص به پیشرفت برسند.

فرمت حاصل که «جاب استوری» (Job Story) نام گرفت، معادله تعریف نیازمندی را به کلی دگرگون کرد. این قالب پیرو یک ساختار سه‌بخشی سخت‌گیرانه است که پرسونا را کاملاً حذف می‌کند: «وقتی [موقعیت رخ می‌دهد]، می‌خواهم [انگیزه محرک]، تا بتوانم [نتیجه مورد انتظار].»[1]

تغییر ایجاد شده شاید جزئی به نظر برسد، اما تأثیری بنیادین دارد. تیم فنی به جای تمرکز بر هویت کاربر، ملزم می‌شود دقیقاً شرایط محیطی یا محرک عاطفی پشت تصمیم او را مشخص کند.[5]

به عنوان نمونه، یک یوزر استوری سنتی می‌گوید: «به عنوان راننده، می‌خواهم هشدارهای ترافیکی را ببینم تا از تاخیر جلوگیری کنم.» جاب استوری همین را به فرمی دقیق‌تر تبدیل می‌کند: «وقتی در مسیر رسیدن به محل کار ناگهان در ترافیک سنگین گیر می‌کنم، می‌خواهم یک مسیر جایگزین بیابم تا سر وقت برسم.»[5]

طراحی مبتنی بر علیت رفتاری

جاب استوری با وادار ساختن تیم‌های چابک به تعیین دقیق موقعیت، نیازمندی نرم‌افزار را بر پایه علیت رفتاری محکم بنا می‌کند. محرک مشخص محیطی، دلیل انگیزه کاربر را توضیح می‌دهد و همین انگیزه است که خروجی فنی مورد نیاز سیستم را تعیین می‌کند.[5]

این ساختار از پرش عجولانه تیم توسعه به سمت راه‌حل رابط کاربری جلوگیری می‌کند. در یوزر استوری سنتی، بخش «اقدام» معمولاً ظاهر یا المان خاصی را دیکته می‌کند؛ برای نمونه می‌نویسند: «می‌خواهم یک منوی کشویی داشته باشم.»[4]

جاب استوری عامدانه جزئیات رابط کاربری را از صورت مسئله حذف می‌کند. تمرکز محض روی انگیزه زمینه‌ای، دست طراحان را باز می‌گذارد تا راه‌حل‌های متعددی را ارزیابی کنند که شاید کارایی بسیار بالاتری داشته باشند.[5]

کلمنت بعداً این چارچوب را با اضافه کردن مفهوم «نیروهای پیشرفت» بسط داد؛ بر این مبنا که انگیزه‌ها توسط دو عامل فشار (Push) و کشش (Pull) شکل می‌گیرند. عامل فشار ناشی از ناکارآمدی ابزار فعلی است و عامل کشش، جذابیت دستیابی به خروجی بهتر است.[2]

دگرگونی در فرایندهای چابک

به‌کارگیری جاب استوری شیوه تحقیقات کاربری تیم‌های محصول را دگرگون می‌کند. به جای پرس‌وجو از ویژگی‌های جمعیت‌شناختی یا علاقه‌مندی به فیچرهای مشخص، تیم‌ها باید دقیقاً لحظات چالش و اصطکاک کاربران را مستند کنند.[5]

تونی اولویک، از پیشگامان متدولوژی کارهایی که باید انجام شوند، نوآوری نتیجه‌محور (Outcome-Driven Innovation) را برای ترسیم این موانع پایه‌گذاری کرد. رویکرد او فرایند اقدام مشتری را به ۱۰ تا ۱۵ گام متمایز تجزیه کرده و اهمیت و میزان رضایت را در نمونه‌هایی بین ۲۰۰ تا ۵۰۰ کاربر می‌سنجد.[3]

انطباق این تحقیقات با جاب استوری، محرک‌های موقعیتی فوق‌العاده دقیقی تولید می‌کند. تیمی که یک نرم‌افزار مالی می‌سازد دیگر محصول را صرفاً برای «یک حسابدار» توسعه نمی‌دهد، بلکه فیچر را برای لحظه‌ای می‌سازد که تطبیق حساب‌های پایان ماه با اختلاف عددی مواجه شده است.[3]

چنین دقتی ریسک ساخت ابزارهای بلااستفاده را کاهش می‌دهد. تحقیقات کریستنسن نشان داد ۹۵ درصد محصولات جدید به این دلیل شکست می‌خورند که بر پایه همبستگی‌های آماری در تحقیقات بازار طراحی شده‌اند، نه محرک‌های علیتی.

چالش‌ها و خطاهای رایج پیاده‌سازی

با وجود تمام مزایا، جاب استوری راه‌حلی جادویی نیست و انتقال به این ساختار با سختی‌هایی همراه است. یک مطالعه در سال ۲۰۱۷ توسط ماکسیم وان دی کوکن نشان داد برداشت‌های تیم‌ها از نحو نگارش این قالب بسیار متفاوت است و این امر به خطاهای مکرر منجر می‌شود.[5]

رایج‌ترین اشتباه، ثبت موقعیت‌های بیش از حد کلی است؛ مثل «وقتی از اپلیکیشن استفاده می‌کنم». یک محرک موقعیتی استاندارد باید حاوی بافت، فضا، محدودیت‌ها و شرایط پیرامونی کافی باشد تا چرایی انگیزه را شرح دهد.[5]

افزون بر این، جاب استوری مفهوم نقش‌های کاربری را در سیستم‌های پیچیده کاملاً منسوخ نمی‌کند. در سامانه‌های سازمانی با سطوح دسترسی سفت‌وسخت، تفکیک دسترسی مدیر از کاربر مهمان همچنان یک ضرورت فنی اجتناب‌ناپذیر است.[5]

با این حال، حتی در چنین محیط‌هایی نقش کاربری فقط یک محدودیت سیستمی است، نه محرک رفتار کاربر. جاب استوری اطمینان حاصل می‌کند که تمرکز اصلی تیم روی هدفی باشد که کاربر در پی تحقق آن است.[5]

آینده تعریف نیازمندی در محصول

در بازار فشرده و اشباع نرم‌افزارهای مدرن، ضریب خطا برای تیم‌های محصول به‌شدت محدود شده است. صرف هزینه روی فیچرهای اشتباه، خطایی است که دیگر تیم‌های چابک توان جبران آن را ندارند.[5]

تا سال ۲۰۲۳، این چارچوب از یک رویکرد فرعی به یکی از متدهای تثبیت‌شده و رایج در توسعه چابک بدل شد و هزاران تیم در سراسر جهان آن را به کار گرفتند. جایگزینی پرسونای سنتی با محرک‌های موقعیتی، مسیر مطمئن‌تری به سمت تناسب محصول با بازار (PMF) ترسیم می‌کند.[5]

این قالب تیم‌ها را با چرایی و واقعیت پشت استفاده کاربر روبه‌رو می‌کند. جاب استوری به مهندسان گوشزد می‌کند که هیچ‌کس صرفاً برای لذت بردن از کدنویسی یا زیبایی سیستم، از محصول استفاده نمی‌کند.[5]

کاربران تنها به نتیجه‌ای اهمیت می‌دهند که در یک موقعیت واقعی به دست می‌آورند. جاب استوری تضمین می‌کند هر خط کد برای رفع یک نیاز عینی توسعه یابد و کل فرآیند بر پایه علیت رفتاری بدون ابهام مستقر شود.[5]