منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · ترجمه: ۶ شهریور ۱۴۰۵ · زمان مطالعه: حدود ۹ دقیقه

تحلیل سلسله‌مراتبی وظیفه (Hierarchical Task Analysis) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

«کاربر سفارش ثبت می‌کند.» این یک جمله است و در واقعیت هفده قدم دارد — و بیشترشان هرگز نوشته نمی‌شوند.

تحلیل سلسله‌مراتبی وظیفه ابزاری است برای نوشتنشان.

تعریف

تحلیل سلسله‌مراتبی وظیفه رویکردی است که طراح با آن، وظیفه‌های کاربر را در قالب هدف و زیرهدف و گام سازمان می‌دهد و سلسله‌مراتب روشنی از وظیفه می‌سازد.

و بیان دقیق‌ترش این است: «تحلیل سلسله‌مراتبی وظیفه، فعالیت‌های پیچیدهٔ کاربر را به لایه‌های ساختاریافته می‌شکند — یعنی هدف، زیرهدف، عملیات، و برنامه.»

و این چهار واژه، دقیقاً واژگان این روش‌اند:

• - هدف — سطح صفر. آنچه کاربر می‌خواهد به آن برسد.
• - زیرهدف — سطح یک به بعد. بخش‌های تشکیل‌دهندهٔ هدف.
• - عملیات — کنش‌های اتمی، که دیگر شکسته نمی‌شوند.
• - برنامه — قاعده‌ای که ترتیب را توصیف می‌کند: پیاپی، موازی، یا شرطی.

و «برنامه» همان چیزی است که این روش را از یک فهرست ساده جدا می‌کند. فهرست می‌گوید چه کارهایی هست؛ برنامه می‌گوید به چه ترتیبی و تحت چه شرطی.

از کجا آمد

این روش در مهندسی عوامل انسانی پدید آمد، برای بهینه‌کردن عملکرد در محیط‌های پیچیده مثل هوانوردی و تولید صنعتی.

و در اوایل دههٔ ۲۰۰۰ برای رابط‌های دیجیتال بازآرایی شد. و از منابع مرجعش، استنتون در ۲۰۰۶ است.

و خاستگاهش نکته‌ای دربارهٔ کاربردش می‌گوید. این روش جایی ساخته شد که خطا کشنده بود — و همین توضیح می‌دهد چرا این‌قدر دقیق است و چرا در بسیاری از پروژه‌های نرم‌افزاری بیش از حد به‌نظر می‌رسد.

هفت گام

• - هدف و دامنه را تعریف کنید.
• - داده جمع کنید — با پرس‌وجوی زمینه‌ای، پروتکل بلندفکری، و ضبط صفحه.
• - وظیفه را بشکنید. سطح صفر هدف است، و سطح یک به بعد زیرهدف‌ها و عملیات.
• - برنامه‌ها و مسیرهای جایگزین را نقشه کنید — مسیرهای شرطی، اختیاری، و موازی.
• - با کاربر یا ذی‌نفع اعتبارسنجی کنید.
• - به طراحی ترجمه‌اش کنید.
• - و تکرار و اندازه‌گیری کنید.

و گام دوم از همه بیشتر حذف می‌شود، و حذفش کل کار را بی‌اعتبار می‌کند. تحلیل وظیفه‌ای که از حافظهٔ تیم نوشته شده، نقشهٔ کاری است که فکر می‌کنیم انجام می‌شود — نه کاری که انجام می‌شود.

قاعدهٔ توقف

و رایج‌ترین پرسش این روش این است که تا کجا بشکنیم. و دو پاسخ داده شده:

«وقتی بینش روشنی به‌دست آوردید متوقف شوید.» و «وقتی متوقف شوید که هر گام مستقیم به یک کنش یا تصمیم کاربر نگاشت شود.»

و عدد عملی‌اش هم گفته شده: معمولاً دو تا پنج سطح عمق، بسته به هدف.

و قاعدهٔ دوم دقیق‌تر است و آزمون‌پذیر. اگر یک گام را نمی‌شود به یک کلیک، یک تایپ، یا یک تصمیم ترجمه کرد، هنوز زیرهدف است، نه عملیات.

نمادگذاری

ساختارش عددی و سلسله‌مراتبی است: ۰، ۱، ۱٫۱، ۱٫۲ و به همین ترتیب.

و لری مارین رویکرد حاشیه‌نویسی رنگی‌ای پیشنهاد کرده که در عمل خیلی مفید است:

• - سبز — کنش‌های کاربر.
• - زرد — کنش‌های سیستم.
• - بنفش — ابزار یا دانش لازم.
• - نارنجی — پرسش‌های بی‌پاسخ.

و ارزش این رنگ‌بندی در دستهٔ سوم و چهارم است. بنفش نشان می‌دهد کاربر چه چیزی را باید از قبل بداند — و همان‌ها معمولاً جاهایی هستند که آموزش لازم می‌شود یا کاربر تازه گیر می‌کند.

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

کجا به کار می‌آید

• - کشف اولیهٔ پروژه، در گام‌های همدلی و تعریف.
• - بهینه‌کردن یا به‌روزکردن یک قابلیت.
• - سامانه‌های حیاتی و سازمانی که انطباق ایمنی می‌خواهند.
• - آموزش و مستندسازی.
• - و یافتن گام‌های خطاخیز.

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

فایده و محدودیت

فایده‌هایش:

• - ساختار و وابستگی‌های پیچیده را آشکار می‌کند.
• - نقاط درد و کارهای زائد را پیدا می‌کند.
• - چند مسیر کاربر را مقایسه می‌کند.
• - مستندسازی را هدایت می‌کند.
• - و پیچیدگی پنهان جریان کار را آشکار می‌کند.

و محدودیت‌هایش:

• - خطر ریزدانگی بیش از حد، که بینش را گل‌آلود می‌کند.
• - اعتبارسنجی با کاربر واقعی حذف‌شدنی نیست.
• - برای وظیفه‌های بسیار خلاقانه یا مبهم که ساختار قابل‌پیش‌بینی ندارند مناسب نیست.
• - و بدون چند منبع داده، ضعیف می‌شود.

و مورد سوم مرز واقعی این روش است. تحلیل سلسله‌مراتبی وظیفه فرض می‌گیرد کاری که کاربر می‌کند، ساختار دارد. برای «نوشتن یک ایمیل» یا «طراحی یک پوستر»، این فرض غلط است.

و یک تشخیص کمکی هم دارد: اگر دو کاربر باتجربه همان کار را به دو ترتیب کاملاً متفاوت انجام دهند و هر دو درست باشد، این وظیفه ساختار ندارد.

در چنین حالتی، تحلیل سلسله‌مراتبی وظیفه یکی از آن دو ترتیب را رسمی می‌کند و دیگری را نادیده می‌گیرد — و بعد طراحی روی همان یکی بنا می‌شود.

و روش درست در آن حالت چیز دیگری است: مشاهدهٔ میدانی برای فهمیدن اینکه چرا ترتیب‌ها فرق می‌کنند، به‌جای انتخاب یکی از آن‌ها.

یک نمونهٔ کوچک

و برای اینکه انتزاعی نماند، یک نمونهٔ کوتاه — «لغو سفارش».

۰ — لغو سفارش. برنامه: ۱ سپس ۲ سپس ۳.

۱ — پیداکردن سفارش. برنامه: ۱٫۱ یا ۱٫۲.

۱٫۱ — از فهرست سفارش‌ها انتخاب کن. · ۱٫۲ — با کد پیگیری جست‌وجو کن.

۲ — تأیید لغو. برنامه: ۲٫۱ سپس ۲٫۲؛ اگر سفارش ارسال شده، ۲٫۳.

۲٫۱ — دلیل لغو را انتخاب کن. · ۲٫۲ — دکمهٔ تأیید را بزن. · ۲٫۳ — با پشتیبانی تماس بگیر.

۳ — دریافت تأییدیه. برنامه: ۳٫۱ و ۳٫۲ به‌طور موازی.

۳٫۱ — پیام روی صفحه. · ۳٫۲ — پیامک تأیید.

و همین نمونهٔ کوچک، سه چیز را آشکار می‌کند که در جملهٔ «کاربر سفارش را لغو می‌کند» دیده نمی‌شدند.

یک: دو مسیر ورودی متفاوت در گام ۱، که هر کدام طراحی جدا لازم دارند.

دو: یک شاخهٔ شرطی در گام ۲، که کاربر را کاملاً از محصول بیرون می‌برد.

و سه: یک وابستگی بیرونی در گام ۳٫۲، که ممکن است نرسد — و اگر کاربر فقط به آن تکیه کند، فکر می‌کند لغو نشده.

و هیچ‌کدام از این سه، در نمونهٔ اولیه دیده نمی‌شدند. در نوشتن دیده شدند.

ترکیب با روش‌های دیگر

و می‌شود با پرسونا و نقشهٔ سفر و تحلیل شناختی وظیفه ترکیبش کرد.

و تفکیکشان مفید است: نقشهٔ سفر می‌گوید کاربر چه حسی دارد، تحلیل سلسله‌مراتبی می‌گوید چه می‌کند، و تحلیل شناختی می‌گوید در حین انجامش به چه فکر می‌کند.

و در چابک هم جا دارد: در اسپرینت‌های کشف استفاده کنید، و به‌عنوان سندی زنده نگهش دارید که هر اسپرینت به‌روز می‌شود.

و «سند زنده» بودنش شرط عملی دارد. سندی که در فایل کسی می‌ماند، در اسپرینت دوم به‌روز نمی‌شود.

پس یک قاعدهٔ ساده کمک می‌کند: هر بار که رفتار محصول عوض شد، همان کارت کار باید تحلیل را هم به‌روز کند. اگر این در تعریف «انجام‌شده» نباشد، اتفاق نمی‌افتد.

و اگر نگه‌داشتنش ممکن نیست، صادقانه‌تر است که تاریخ آخرین به‌روزرسانی را روی سند بنویسید — تا کسی سه ماه بعد به یک نقشهٔ منقضی اعتماد نکند.

در بافت فارسی

یک: بخشی از وظیفه بیرون از محصول انجام می‌شود. کاربر ایرانی وسط یک جریان، به پیام‌رسان می‌رود، به پشتیبانی زنگ می‌زند، یا از کسی می‌پرسد.

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

دو: «دانش لازم» — همان دستهٔ بنفش — اینجا بزرگ‌تر است. شماره شبا، کد ملی، رمز دوم، نوع درگاه، و قاعده‌های بانکی، همه چیزهایی هستند که کاربر باید از قبل بداند.

و هر کدامشان یک نقطهٔ ریزش است. پس دستهٔ بنفش را جدی بگیرید و برای هر موردش بپرسید: اگر کاربر این را نداند، چه اتفاقی می‌افتد؟

سه: مسیرهای شرطی اینجا بیشترند. بانک‌های مختلف، درگاه‌های مختلف، و قاعده‌هایی که برای هر کدام فرق می‌کند.

و همان‌طور که در فلوچارت نوشتم، شاخهٔ کشیده‌نشده همان جایی است که کاربر گیر می‌کند. در تحلیل وظیفه، این یعنی «برنامه» را جدی‌تر از «زیرهدف» بنویسید.

چهار: مستندسازی اینجا کم است و همین این روش را ارزشمندتر می‌کند. در بسیاری از تیم‌های ما، دانش جریان کار در سر چند نفر است.

و یک تحلیل سلسله‌مراتبی وظیفه، حتی اگر برای طراحی هم استفاده نشود، همان دانش را از حافظهٔ افراد بیرون می‌آورد و در سند می‌گذارد — که خودش به‌تنهایی ارزش کار را می‌دهد.

جمع‌بندی

• - تحلیل سلسله‌مراتبی وظیفه، وظیفه‌های کاربر را در قالب هدف و زیرهدف و گام سازمان می‌دهد
• - چهار واژهٔ کلیدی: هدف · زیرهدف · عملیات · و برنامه — و برنامه همان چیزی است که این روش را از یک فهرست ساده جدا می‌کند
• - خاستگاهش مهندسی عوامل انسانی در هوانوردی و تولید بود · و در اوایل دههٔ ۲۰۰۰ برای رابط دیجیتال بازآرایی شد
• - هفت گام: تعریف هدف · جمع داده · شکستن وظیفه · نقشهٔ برنامه‌ها · اعتبارسنجی · ترجمه به طراحی · و تکرار
• - قاعدهٔ توقف: وقتی هر گام به یک کنش یا تصمیم کاربر نگاشت شود · معمولاً دو تا پنج سطح
• - رنگ‌بندی مارین: سبز کنش کاربر · زرد کنش سیستم · بنفش دانش لازم · نارنجی پرسش بی‌پاسخ
• - محدودیت: ریزدانگی بیش از حد · حذف‌نشدنی بودن اعتبارسنجی · نامناسب برای وظیفهٔ خلاقانه یا مبهم · و ضعف بدون چند منبع داده
• - نقشهٔ سفر می‌گوید چه حسی دارد، این روش می‌گوید چه می‌کند، و تحلیل شناختی می‌گوید به چه فکر می‌کند
• - و در فارسی: گام‌های بیرون از محصول را هم بنویسید · دستهٔ «دانش لازم» بزرگ‌تر است · «برنامه» را جدی‌تر از «زیرهدف» بنویسید · و همین سند، دانش را از حافظهٔ افراد بیرون می‌آورد