التفكير التصميمي أم Lean أم Agile أم سباق التصميم: أيها ومتى؟

اختر التفكير التصميمي (Design Thinking) حين لا تفهم المشكلة بعد. واختر الشركات الناشئة الرشيقة (Lean Startup) حين تكون لديك فكرة وتريد أن تعرف، بأقل تكلفة، هل ستنجح. واختر المنهجية الرشيقة (Agile) حين تعرف ما الذي ستبنيه وتحتاج أن تسلّمه على دفعات تعمل. واختر سباق التصميم (Design Sprint) حين تحتاج مشكلة واضحة ومهمة إلى جواب مختبَر خلال أسبوع. هذه المنهجيات ليست متنافسة: كل واحدة تجيب عن سؤال مختلف، وأغلب المشاريع الحقيقية تستخدم أكثر من واحدة بالتتابع.

الالتباس سببه أن الأربع تتحدث عن المستفيد والتكرار والتعلم. لكن الفرق الحقيقي في ما تفترض كل منها أنك تعرفه حين تبدأ. وللسؤال الأوسع عن اختيار الأداة المفردة، اقرأ أي أداة ابتكار أستخدم؟.

من أين جاءت كل منهجية

لمحة تاريخية قصيرة تفيد هنا، لأن كل منهجية ما زالت تحمل أثر المشكلة التي صُممت لها.

• التفكير التصميمي نشأ من ممارسة التصميم، وانتشر كطريقة عامة لحل المشكلات على يد شركة التصميم IDEO ومدرسة التصميم في جامعة ستانفورد (d.school) التي تأسست عام 2005. و«الماسة المزدوجة» التي وضعها مجلس التصميم البريطاني عام 2003 تصف شكلاً مشابهاً. صُمم للمشكلات التي تكون فيها الحاجة نفسها غير واضحة.
• Lean Startup قدّمها إريك ريس في كتابه «الشركة الناشئة الرشيقة» عام 2011، مستنداً إلى منهجية «تطوير العملاء» لستيف بلانك وإلى مبادئ التصنيع الرشيق. صُممت لرواد أعمال قد يقضون سنوات في بناء شيء لا يريده أحد.
• Agile تعود إلى «بيان تطوير البرمجيات الرشيق» (Agile Manifesto) الذي كتبه 17 من ممارسي البرمجيات في سنوبيرد بولاية يوتا الأمريكية في فبراير 2001. وأشهر أطرها «سكرم» (Scrum) الذي وضعه كين شوابر وجيف ساذرلاند. صُممت لمشاريع برمجية كانت تفشل تحت خطط طويلة وثابتة.
• سباق التصميم طوّره جيك ناب في Google وGoogle Ventures، ووصفه كتاب «Sprint» عام 2016 لناب وجون زيراتسكي وبرادن كوفيتز. صُمم لينقل الفريق من سؤال صعب إلى نموذج أولي مختبَر في خمسة أيام.

مقارنة جنباً إلى جنب

متى تناسب كل منهجية

التفكير التصميمي: حين تكون المشكلة غير واضحة

تسمع أوصافاً مختلفة للمشكلة من أشخاص مختلفين. الشكاوى موجودة، لكن لا أحد يعرف سببها. أو تحتاج خدمة جديدة لفئة لم تدرسها من قبل. في هذه الحالات، البدء بالأفكار أو بالتنفيذ يتجاوز أثمن جزء في العمل. ابدأ بـمقابلات أصحاب المصلحة، وأكمل الصياغة بـبيان وجهة النظر وأسئلة «كيف يمكننا». المنهجية كاملة في التفكير التصميمي خطوة بخطوة.

ولا تستخدمه حين تكون المشكلة مفهومة جيداً والجهة تحتاج تنفيذاً. مرحلة استكشاف لمشكلة يفهمها الجميع تختبر صبر الناس، لا الأفكار.

Lean Startup: حين تكون لديك فكرة والخطر أن لا يريدها أحد

لديك مفهوم وراعٍ وحماس، لكن لا دليل على أن الناس سيستخدمونه أو يدفعون مقابله أو يغيرون سلوكهم من أجله. التفكير الرشيق يطلب منك أن تحدد أخطر افتراض بـخريطة الافتراضات، وتكتب اختبار فرضية، ثم تجري أصغر تجربة يمكن أن تثبت أنك مخطئ، مثل اختبار الخدمة اليدوية (Concierge). المزيد في كيف تختبر فكرة قبل أن تبنيها.

وتضعف حين تكون المشكلة نفسها غير واضحة (ستختبر أجوبة عن السؤال الخطأ)، وفي الخدمات العامة التي لا يصح فيها إجراء تجارب على المواطنين دون عناية. في الجهات الحكومية، كثير من التجارب يحتاج نقاشاً مختلفاً حول الموافقة والمخاطر عمّا تحتاجه شركة ناشئة.

Agile: حين تعرف ما الذي ستبنيه

المفهوم ثبتت جدواه، والعمل الباقي أغلبه تنفيذ: بناء النظام أو الإجراء أو الخدمة. تقسم المنهجية الرشيقة العمل إلى أجزاء صغيرة تُكتب على شكل قصص مستخدم (User Stories)، وتسلّم أجزاء تعمل في دورات قصيرة، وتعدّل المسار عبر جلسات مراجعة (Retrospective) منتظمة.

لكن Agile لا تخبرك ماذا تبني. الفرق التي تستخدمها للاستكشاف كثيراً ما تنتهي بتسليم سريع لميزات لم يحتجها أحد. ولا تناسب جيداً العقود والمشتريات التي تثبّت النطاق مسبقاً، إلا إذا صيغت لتسمح بالتغيير، وهذه نقطة تستحق نقاشاً مبكراً مع إدارة المشتريات.

سباق التصميم: حين يحتاج سؤال مهم جواباً هذا الأسبوع

يناسب سباق التصميم حين يكون التحدي محدداً، والرهان كبيراً بما يبرر خمسة أيام من وقت صاحب القرار، والفريق عالقاً بين خيارات. الشكل الكلاسيكي: الأحد (أو اليوم الأول) رسم خريطة المشكلة واختيار الهدف؛ اليوم الثاني يرسم كل شخص حلوله منفرداً؛ اليوم الثالث القرار والقصة المصورة؛ اليوم الرابع بناء نموذج واقعي؛ اليوم الخامس اختباره مع خمسة مستفيدين.

ولا يناسب حين لم يبحث أحد في المستفيدين (سيعتمد السباق على الافتراضات)، أو حين لا يستطيع صاحب القرار الحضور، أو حين تكون المشكلة أكبر من أن تُختبر في نموذج يُبنى في يوم.

الجمع بينها: الترتيب المعتاد

تعمل هذه المنهجيات أفضل حين تُرتب بحسب نوع الغموض.

1. التفكير التصميمي للفهم والصياغة. بحث، وبيان مشكلة معتمد.
2. سباق التصميم للحسم. استخدم نتائج البحث لتجعل اليوم الأول أسرع وأكثر واقعية، واخرج بمفهوم مختبَر.
3. تجارب Lean لتقليل المخاطر. اختبر الافتراضات التي لم يحسمها السباق، مثل: هل سيستمر الناس في استخدام الخدمة بعد الأسبوع الأول؟
4. Agile للتنفيذ. ابنِ وأطلق على دفعات، واستمر في الاختبار مع المستفيدين.

ليس كل مشروع يحتاج الأربع. تحسين إجراء داخلي صغير قد يحتاج أسبوع استكشاف ثم تنفيذاً مباشراً. ومنتج رقمي جديد قد يبدأ بسباق تصميم مباشرة إن كان البحث موجوداً. القاعدة العملية: حدد أكبر مجهول لديك، واستخدم المنهجية التي صُممت لذلك المجهول.

مثال تطبيقي

مثال توضيحي. بنك في الرياض يريد تقديم خدمة جديدة لأصحاب المتاجر الإلكترونية الصغيرة من عملائه.

التفكير التصميمي (ستة أسابيع). يقابل الفريق عشرين صاحب متجر، ويزور عدداً منهم في مستودعاتهم الصغيرة أو بيوتهم حيث يجهزون الطلبات. كان المتوقع أن المشكلة في رسوم التحويل. لكن المشكلة الحقيقية: أصحاب المتاجر يقضون ساعات كل أسبوع في مطابقة المدفوعات الواردة من أكثر من بوابة دفع وتطبيق توصيل مع الطلبات، يدوياً في جداول. يُعتمد بيان المشكلة: «كيف يمكننا أن نجعل مطابقة المدفوعات تلقائية لأصحاب المتاجر الذين تقل طلباتهم عن مئة طلب أسبوعياً؟».

سباق التصميم (خمسة أيام). بحضور مدير قطاع المنشآت الصغيرة في اليوم الأول والثالث، يرسم الفريق ويختار وينمذج كشفاً يومياً يجمع المدفوعات من كل المصادر ويطابقها مع أرقام الطلبات. يختبره خمسة أصحاب متاجر في اليوم الخامس. أربعة يريدونه فوراً، والخمسة يسألون: هل يعمل مع منصة المتجر التي أستخدمها؟

تجربة Lean (أربعة أسابيع). أخطر افتراض متبقٍّ: أن أصحاب المتاجر سيثقون بالكشف دون أن يعيدوا المطابقة يدوياً. يجري الفريق نسخة يدوية (Concierge) مع عشرة عملاء: موظف يعدّ الكشف يدوياً ويرسله كل صباح. بعد الأسبوع الثاني، يتوقف معظمهم عن المراجعة اليدوية.

التنفيذ بـAgile (مستمر). يبني فريق تقني النظام الحقيقي في دورات من أسبوعين، يبدأ بربط بوابتي دفع وكشف يومي واحد، ويختبر كل إصدار مع العملاء.

كل منهجية أدت العمل الذي صُممت له. لو بدأ البنك بـAgile لخرج بأداة سريعة لتخفيض الرسوم. ولو بدأ بسباق التصميم لفاتته مشكلة المطابقة كلياً.

افعل ولا تفعل

افعل

• سمِّ أكبر مجهول لديك أولاً، ثم اختر المنهجية المصممة له.
• غذِّ سباق التصميم بنتائج البحث. السباق المبني على فهم حقيقي للمستفيد أقوى بكثير من سباق مبني على التخمين.
• استمر في الاختبار مع المستفيدين بعد أن يبدأ التنفيذ بـAgile.
• اتفق مسبقاً على من يملك التسليم بين المراحل، خصوصاً من السباق إلى فريق التنفيذ.

لا تفعل

• لا تعامل الأربع كعلامات تجارية متنافسة ولا تسأل أيها «الأفضل». هذا كأن تسأل: هل الخريطة أفضل من المطرقة؟
• لا تستخدم Agile للاستكشاف. الدورات القصيرة لا تغني عن فهم المشكلة.
• لا تُجرِ سباق تصميم دون صاحب القرار. ستحصل على نموذج جيد ولا قرار.
• لا تسمِّ كل ورشة «سباق تصميم». خمسة أيام بالبنية المعروفة شيء، وجلسة أفكار لساعتين شيء آخر.
• لا تترك كل منهجية تعيش في إدارة مختلفة بمفرداتها الخاصة. التعلم يضيع في نقاط التسليم بين الإدارات.

أسئلة يطرحها الناس

هل سباق التصميم هو نفسه التفكير التصميمي؟ لا. سباق التصميم عملية ثابتة من خمسة أيام تستخدم عدة أدوات من التفكير التصميمي للإجابة عن سؤال واحد محدد. أما التفكير التصميمي فهو المنهجية الأوسع، وعمل الاستكشاف فيه يأتي عادة قبل السباق.

هل يمكن الجمع بين التفكير التصميمي وAgile؟ نعم، وهذا هو الأفضل. التفكير التصميمي يحدد ماذا نبني ولمن، وAgile يبنيه على دفعات. النمط الشائع: فترة استكشاف، ثم تنفيذ رشيق يحافظ على إيقاع منتظم من الاختبار مع المستفيدين.

أي منهجية أنسب للجهات الحكومية؟ يعتمد ذلك على المجهول. التفكير التصميمي يناسب الخدمات التي لم تتضح فيها احتياجات المستفيدين، وAgile يناسب التنفيذ الرقمي بعد أن تتضح، وتجارب Lean تحتاج عناية إضافية بالموافقة والمخاطر حين يكون الجمهور طرفاً فيها.

إلى أين بعد هذا

للاستكشاف، ابدأ بـمقابلات أصحاب المصلحة. ولتقليل مخاطر فكرة، استخدم خريطة الافتراضات. وليوم النموذج في سباق التصميم، اقرأ دليل النموذج الورقي، وللتنفيذ، قصص المستخدم. كل أدلة الأدوات في فهرس الأدلة.