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

اسپرینت طراحی (Design Sprint) چیست؟

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

اسپرینت طراحی (Design Sprint) یک قالب پنج‌روزهٔ فشرده است برای رسیدن به پاسخ یک پرسش بزرگ، بدون اینکه ماه‌ها وقت و بودجه صرف ساختن چیزی شود که شاید اصلاً درست نباشد. تیم در این پنج روز مسئله را می‌فهمد، راه‌حل‌ها را روی کاغذ می‌آورد، یکی را انتخاب می‌کند، یک نمونهٔ نمایشی می‌سازد و روز آخر آن را جلوی کاربر واقعی می‌گذارد.

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

از کجا آمد و چه مسئله‌ای را حل می‌کند

این قالب را جیک نپ (Jake Knapp) در سال ۲۰۱۰ در گوگل و بعد در Google Ventures صورت‌بندی کرد. ایده‌اش از دو جا آمده بود: فرهنگ ساخت سریع در گوگل، و کارگاه‌های تفکر طراحی که آیدیو رواج داده بود. نپ متوجه شده بود که بهترین پیشرفت‌ها در پروژه‌ها معمولاً در همان روزهای فشرده‌ای اتفاق می‌افتد که همه دور یک میز جمع می‌شوند و یک ضرب‌الاجل واقعی دارند — و تصمیم گرفت آن شرایط را به‌جای اینکه تصادفی باشد، عمداً بسازد.

مسئله‌ای که حل می‌کند هم مشخص است. در بیشتر سازمان‌ها فاصلهٔ بین «یک ایدهٔ خوب داریم» تا «فهمیدیم این ایده کار می‌کند یا نه» ماه‌ها طول می‌کشد، و در تمام آن مدت تیم دارد بر اساس حدس هزینه می‌کند. اسپرینت این فاصله را به پنج روز فشرده می‌کند. توجه کنید که هدف، ساختن سریع‌تر نیست؛ هدف فهمیدن زودتر است — و این دو اصلاً یکی نیستند.

از این نظر، اسپرینت را می‌شود نسخهٔ فشرده و زمان‌بندی‌شدهٔ همان حلقه‌ای دانست که در لین یو‌ایکس دیدیم: فرضیه، ساخت کمینه، سنجش. تفاوتش این است که اسپرینت یک قالب تقویمی سفت‌وسخت دارد و همین سفتی، بخش زیادی از اثرش را می‌سازد.

پنج روز، پنج کار

ساختار کلاسیک اسپرینت این است:

• - شنبه — فهم: مسئله را از زوایای مختلف می‌بینیم. نقشهٔ ساده‌ای از مسیر کاربر می‌کشیم، از متخصص‌های داخلی (فروش، پشتیبانی، فنی) در جلسه‌های کوتاه می‌پرسیم چه می‌دانند، و در پایان روز یک نقطهٔ هدف روی آن نقشه انتخاب می‌کنیم. انتخاب‌نکردن، شایع‌ترین دلیل شکست کل هفته است.
• - یک‌شنبه — طرح: هر نفر جداگانه راه‌حل‌ها را روی کاغذ می‌آورد. اینجا خبری از طوفان فکری گروهی نیست و این عمدی است — کمی جلوتر توضیح می‌دهم چرا.
• - دوشنبه — تصمیم: طرح‌ها بی‌نام روی دیوار می‌روند، همه در سکوت آنها را می‌بینند، نقاط جالب علامت می‌خورد، و بعد رأی‌گیری می‌شود. طرح برنده به یک استوری‌بورد تبدیل می‌شود که دقیقاً می‌گوید فردا چه چیزی باید ساخته شود.
• - سه‌شنبه — نمونه‌سازی: یک نمونهٔ اولیه ساخته می‌شود که فقط باید به نظر واقعی برسد، نه اینکه واقعاً کار کند.
• - چهارشنبه — آزمون: پنج کاربر واقعی، یکی‌یکی، با نمونه کار می‌کنند و بقیهٔ تیم تماشا می‌کند و یادداشت برمی‌دارد. در پایان روز، تیم جواب پرسشی را دارد که دوشنبهٔ قبل هیچ‌کس جوابش را نمی‌دانست.

نام روزها را با تقویم کاری خودتان تنظیم کنید؛ چیزی که اهمیت دارد ترتیب و پیوستگی است، نه اینکه روز اول دوشنبه باشد. اما یک قید جدی هست: این پنج روز باید پشت سر هم باشند. اسپرینتی که به‌صورت «هر هفته یک جلسه» پخش شود، اسپرینت نیست؛ همان جلسه‌های همیشگی است با اسمی تازه.

چرا طوفان فکری گروهی کنار گذاشته شد

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

در جلسهٔ گروهی، ایدهٔ اولی که مطرح می‌شود مثل لنگر عمل می‌کند و بقیهٔ ایده‌ها ناخودآگاه حول همان می‌چرخند. آدم‌های پرصداتر و ارشدتر سهم بیشتری از فضا می‌گیرند و ایده‌های خوبِ آدم‌های کم‌حرف اصلاً بیرون نمی‌آید. از آن مهم‌تر، در گروه فقط یک نفر در هر لحظه فکر می‌کند و بقیه گوش می‌دهند؛ در حالی که وقتی پنج نفر جداگانه می‌نویسند، پنج مسیر فکری موازی پیش می‌رود.

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

نمونهٔ نمایشی، نه محصول

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

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

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

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

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

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

و یک نکتهٔ مهم دربارهٔ نتیجه: اسپرینتی که به «ایدهٔ ما غلط بود» ختم شود، اسپرینت موفقی است. شما تازه با هزینهٔ یک هفته چیزی را فهمیدید که ممکن بود شش ماه بعد و با هزینهٔ صدبرابر بفهمید.

اسپرینت در تیم‌های ایرانی

این بخش هم در منبع نیست و از اجرای این قالب در تیم‌های فارسی‌زبان می‌آید.

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

ساختار سلسله‌مراتبی. در سازمان‌هایی که فاصلهٔ سِمَتی پررنگ است، رأی‌گیری بی‌نام و مرور خاموش صرفاً یک تکنیک تزئینی نیست؛ شرط بقای اسپرینت است. اگر مدیر ارشد اول نظرش را بگوید، بقیهٔ آرا عملاً بی‌معنا می‌شوند. قاعدهٔ ساده این است: تصمیم‌گیرنده آخر از همه حرف می‌زند.

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

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

نسخهٔ کوتاه‌شده. اگر پنج روز کامل شدنی نیست، نسخهٔ فشردهٔ سه‌روزه (فهم و طرح در یک روز، تصمیم و نمونه در روز دوم، آزمون در روز سوم) بسیار بهتر از اجرا نکردن است. چیزی که به‌هیچ‌وجه نباید حذف شود، روز آزمون است؛ بدون آن، هر چه ساخته‌اید هنوز فقط یک نظر است.

جمع‌بندی

اسپرینت طراحی نه یک روش طراحی تازه است و نه جایگزین پژوهش مستمر. یک ابزار تیزِ تک‌منظوره است برای وقتی که تیم روی یک پرسش بزرگ گیر کرده و بحث بیشتر، دیگر چیزی به آن اضافه نمی‌کند. پنج روز، شش نفر، یک هدف، و در پایان چیزی که هیچ جلسه‌ای نمی‌توانست بدهد: واکنش واقعی آدم واقعی.

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