تحديد نطاق مهمة Claude Code: من طلبات غامضة إلى التزامات

لماذا تضيّع طلبات الميزات الغامضة الوقت

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

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

يمكنك عادةً اكتشاف المهمة الغامضة مبكرًا:

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

المهمة محددة النطاق تعطي الفريق خط نهاية: معايير قبول واضحة، خطة واجهة مستخدم وAPI الحد الأدنى، وحدود صريحة لما لا يدخل في النطاق. هذا الفرق بين «تحسين البحث» وتغيير صغير سهل البناء والمراجعة.

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

ابدأ بالنتيجة، لا بالحل

الطلبات الغامضة تبدأ غالبًا كاقتراحات إصلاح: «أضف زرًا»، «حوّل إلى سير جديد»، «استخدم نموذجًا مختلفًا». قف لترجم الاقتراح إلى نتيجة أولًا.

تنسيق بسيط يساعد: «بصفتي [مستخدم]، أريد [فعل شيء]، لكي [أصل لهدف].» اجعلها واضحة. إذا لم تستطع قولها في نفس النفس، فهي لا تزال غامضة.

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

اكتب أيضًا ما يبقى كما هو. غير الأهداف تحمي نطاقك. إذا كان الطلب «تحسين تجربة الانضمام»، قد يكون من غير الأهداف «لا إعادة تصميم لوحة القيادة» أو «لا تغييرات في منطق فئات الأسعار».

أخيرًا، اختر مسارًا رئيسيًا واحدًا لتدعمه أولًا: الشريحة الطرفية الوحيدة التي تثبت أن الميزة تعمل.

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

اطرح الأسئلة القليلة التي تزيل الغموض

الطلب الغامض نادرًا ما يفتقد الجهد. هو يفتقد القرارات.

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

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

حالات الحافة هي حيث يتضخم النطاق، لذا سمِّ الكبيرة مبكرًا: البيانات الفارغة، أخطاء التحقق، الاتصالات البطيئة أو الفاشلة، وماذا يعني «التراجع» فعليًا.

أخيرًا، قرر كيف ستتحقق من النجاح. بدون نتيجة قابلة للاختبار، تتحول المهمة إلى آراء.

هذه الأسئلة الخمسة تزيل معظم الغموض عادةً:

• من يحصل على الوصول (الخطط والأدوار)؟
• ما الموعد النهائي، وما أصغر نسخة مقبولة؟
• ما مثال واحد للسلوك المتوقع؟
• ماذا يحدث في الحالات الفارغة، الأخطاء، والاتصالات البطيئة؟
• كيف سنتأكد أنه يعمل (معيار محدد أو مقياس)؟

مثال: «إضافة نطاقات مخصصة للعملاء» تصبح أوضح عندما تقرر أي مستوى تنتمي إليه، من يستطيع إعدادها، هل مكان الاستضافة يؤثر على الامتثال، ما الخطأ المعروض عند DNS غير صالح، وماذا يعني «تم» (النطاق مُثبت، HTTPS مفعل، وخطة استرجاع آمنة).

حوّل الملاحظات الفوضوية إلى معايير قبول

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

نمط بسيط يحافظ على الوضوح. يمكنك استخدام Given/When/Then، أو نقاط قصيرة تعني الشيء نفسه.

قالب سريع لمعايير القبول

اكتب كل معيار كاختبار واحد يمكن لشخص تشغيله:

• معطى حالة بداية، عندما يفعل المستخدم X، فإن يحدث Y.
• أدرج قواعد التحقق (ما المدخلات المسموح بها).
• أدرج حالة فشل واحدة على الأقل (ما الخطأ الذي يراه المستخدم).
• عرّف «إشارة الإنجاز» (ما الذي يفحصه QA وما يتوقعه المراجعون).

طبقها الآن. افترض أن الملاحظة تقول: «اجعل اللقطات أسهل. أريد أن أستعيد إذا أحدث التغيير الأخير كسرًا.» حوّلها إلى عبارات قابلة للاختبار:

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

إذا قدر QA تشغيل هذه الفحوص والمراجعون التحقق منها في واجهة المستخدم والسجلات، فأنت جاهز لتخطيط عمل واجهة المستخدم وAPI وتقسيمه إلى التزامات صغيرة.

ضع خطة واجهة مستخدم الحد الأدنى

خطة واجهة المستخدم الحد الأدنى وعد: أصغر تغيير مرئي يثبت أن الميزة تعمل.

ابدأ بتسمية الشاشات التي ستتغير وما الذي يلاحظه الشخص خلال 10 ثوانٍ. إذا كان الطلب «اجعلها أسهل» أو «نظفها»، ترجم ذلك إلى تغيير ملموس واحد يمكنك الإشارة إليه.

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

عرّف حالات واجهة المستخدم الرئيسية

معظم تغييرات الواجهة تحتاج بعض الحالات المتوقعة. اذكر فقط الحالات التي تنطبق:

• التحميل
• الفارغ
• الخطأ (وإن وُجد إعادة المحاولة)
• النجاح (تنبيه، رسالة داخلية، قائمة محدثة)

أكد الكلمات التي سيرىها المستخدمون

نسخ واجهة المستخدم جزء من النطاق. التقط التسميات والرسائل التي يجب الموافقة عليها: نص الزر، تسميات الحقول، نص المساعدة، ورسائل الخطأ. إذا كانت الصياغة لا تزال مفتوحة، ضعها كمحتوى مؤقت واذكر من سيؤكدها.

حافظ على ملاحظة صغيرة «ليس الآن» لأي شيء غير مطلوب لاستخدام الميزة (تحسينات الاستجابة، الفرز المتقدم، الرسوم المتحركة، الأيقونات الجديدة).

ضع خطة API وبيانات الحد الأدنى

المهمة محددة النطاق تحتاج عقدًا صغيرًا وواضحًا بين الواجهة، الخادم، والبيانات. الهدف ليس تصميم النظام بأكمله؛ بل تحديد أصغر مجموعة من الطلبات والحقول تثبت أن الميزة تعمل.

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

حافظ على سطح API صغيرًا. للعديد من الميزات، طلب قراءة واحد وطلب كتابة واحد يكفيان:

• GET /items/{id} يعيد الحالة اللازمة لعرض الشاشة
• POST /items/{id}/update يقبل فقط ما يمكن للمستخدم تغييره ويعيد الحالة المحدثة

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

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

أخيرًا، قرر ما يجب تخزينه وما يمكن حسابه. قاعدة بسيطة: خزّن الحقائق، واحسب وجهات العرض.

استخدم Claude Code لإنتاج مهمة محددة النطاق

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

1. إعادة صياغة بسيطة للنطاق وقائمة مختصرة لمعايير القبول.
2. تسلسل صغير من الالتزامات (هدف من 3 إلى 7)، كل منها بنتيجة واضحة.
3. الملفات أو المجلدات المحتمل تعديلها لكل التزام، وما الذي يتغير بداخلها.
4. خطة اختبار سريعة لكل التزام (مسار سعيد وحالة حافة واحدة).
5. ملاحظات صريحة بما هو خارج النطاق.

بعد أن يرد، اقرأها كمراجع. إذا رأيت عبارات مثل «تحسين الأداء» أو «اجعلها أنظف»، اطلب صياغة قابلة للقياس.

مثال مصغر (كيف يبدو “الجيد”)

الطلب: «أضف طريقة لإيقاف الاشتراك مؤقتًا.»

نسخة محددة النطاق قد تقول: «يمكن للمستخدم إيقاف الاشتراك لمدة 1 إلى 3 أشهر؛ تاريخ الفاتورة التالي يتحدّث؛ يمكن للمسؤول رؤية حالة الإيقاف»، وما هو خارج النطاق: «لا تغييرات في التسويات المالية».

من هناك، تخطيط الالتزامات يصبح عمليًا: التزام واحد لشكل قاعدة البيانات وAPI، التزام لواجهة المستخدم، التزام للتحقق وحالات الخطأ، التزام للاختبارات الشاملة.

قسم العمل إلى التزامات صغيرة قابلة للمراجعة

التغييرات الكبيرة تخفي الأخطاء. الالتزامات الصغيرة تجعل المراجعات أسرع، تسهّل التراجع، وتساعدك على ملاحظة خروجك عن معايير القبول.

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

تسلسل شائع يبدو هكذا:

• نموذج البيانات أو الترحيل (إذا لزم) مع الاختبارات
• سلوك API والتحقق
• ربط واجهة المستخدم مع الحالات الفارغة/الخطأ
• التسجيل أو التحليلات فقط إذا لزم، ثم لمسات صغيرة

حافظ على تركيز كل التزام. تجنّب «بينما أنا هنا» عمليات إعادة الهيكلة. اجعل التطبيق يعمل من النهاية إلى النهاية، حتى لو كانت الواجهة أساسية. لا تدمج الترحيلات، السلوك، والواجهة في التزام واحد إلا إذا كان لديك سبب قوي.

مثال توضيحي: «تصدير التقارير»

يقول صاحب مصلحة: «هل يمكننا إضافة تصدير التقارير؟» هذا يخفي الكثير من الخيارات: أي تقرير، أي صيغة، من يمكنه التصدير، وكيفية التسليم.

اطرح فقط الأسئلة التي تغيّر التصميم:

• أي أنواع التقارير ضمن النطاق للنسخة الأولى؟
• أي صيغة مطلوبة للنسخة الأولى (CSV، PDF)؟
• من يستطيع التصدير (المسؤولون، أدوار معينة)؟
• هل هو تنزيل مباشر أم تصدير بالبريد؟
• أي حدود (نطاق زمني أقصى، حد صفوف، مهلات)؟

افترض الأجوبة: «تقرير ملخّص المبيعات، CSV فقط، دور المدير، تنزيل مباشر، آخر 90 يومًا كحد أقصى.» الآن تصبح معايير القبول للنسخة الأولى ملموسة: يمكن للمدراء النقر على تصدير في صفحة ملخص المبيعات؛ يتطابق CSV مع أعمدة الجدول المعروض؛ يحترم التصدير المرشحات الحالية؛ يظهر خطأ واضح عند محاولة تصدير أكثر من 90 يومًا؛ يكتمل التنزيل خلال 30 ثانية لما يصل إلى 50k صف.

خطة واجهة المستخدم الحد الأدنى: زر Export بجانب إجراءات الجدول، حالة تحميل أثناء الإنشاء، ورسالة خطأ توضح للمستخدم كيف يصلح المشكلة (مثل «اختر 90 يومًا أو أقل»).

خطة API الحد الأدنى: نقطة نهاية واحدة تقبل المرشحات وتعيد CSV كاستجابة ملف، معاد استخدام نفس استعلام الجدول مع فرض قاعدة 90 يومًا جانب الخادم.

ثم اشحنها في بضعة التزامات محكمة: أولًا نقطة النهاية لمسار سعيدة ثابت، ثم ربط الواجهة، ثم التحقق ورسائل الخطأ للمستخدم، ثم الاختبارات والوثائق.

أخطاء شائعة في تحديد النطاق (وكيف تتجنبها)

تسلل متطلبات مخفية

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

اختلاط تحسين الواجهة بالسلوك الأساسي

تفقد الفرق أيامًا عندما تتضمن المهمة كلاً من «اجعلها تعمل» و«اجعلها جميلة». اجعل المهمة الأولى مركزة على السلوك والبيانات. ضع التنسيق والرسوم المتحركة في مهمة متابعة ما لم تكن مطلوبة لاستخدام الميزة.

محاولة حل كل حالات الحافة في v1

حالات الحافة مهمة، لكن ليس كلها تحتاج الحل فورًا. عالج القليل الذي يكسر الثقة (إرسال مزدوج، تعديلات متعارضة) وأجّل الباقي مع ملاحظات واضحة.

تأجيل حالات الخطأ والأذونات إلى «لاحقًا»

إذا لم تكتبها، ستفقدها. أدرج على الأقل مسار تعيس واحد وقاعدة أذونات واحدة في معايير القبول.

معايير لا يمكنك التحقق منها

تجنب كلمات مثل «سريع» أو «بديهي» ما لم تربطها برقم أو فحص ملموس. استبدلها بشيء يمكن إثباته في المراجعة.

قائمة تحقق سريعة قبل البدء بالبرمجة

ثبّت المهمة بحيث يتمكن زميل من المراجعة والاختبار دون قراءة الأفكار:

• النتيجة وغير الأهداف: جملة واحدة للنتيجة، بالإضافة إلى 1–3 أهداف مستبعدة.
• معايير القبول: 5 إلى 10 فحوص قابلة للاختبار بلغة بسيطة.
• حالات واجهة المستخدم: الحد الأدنى من التحميل، الفارغ، الخطأ، والنجاح.
• ملاحظات API والبيانات: أصغر شكل نقطة نهاية وأي تغييرات بيانات، بالإضافة إلى من يقرأ ويكتب.
• خطة الالتزامات مع الاختبارات: 3 إلى 7 التزامات، كل منها بدليل سريع.

مثال: «إضافة البحث المحفوظ» تصبح «يمكن للمستخدمين حفظ مرشح وإعادة تطبيقه لاحقًا»، مع استثناءات مثل «لا مشاركة» و«لا تغييرات في الفرز».

الخطوات التالية: حافظ على استقرار النطاق أثناء البناء

بمجرد أن تحصل على مهمة محددة النطاق، احمها. قبل البرمجة، قم بمراجعة سريعة مع من طلب التغيير:

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

ثم خزّن المعايير حيث يحدث العمل: في التذكرة، في وصف طلب السحب، وأينما ينظر فريقك فعلاً.

إذا كنت تبني في Koder.ai (koder.ai)، فالمساعدة تكون في قفل الخطة أولًا ثم توليد الشيفرة منها. وضع التخطيط يناسب هذا سير العمل، واللقطات والاسترجاع تحافظ على التجارب آمنة عندما تحتاج لتجربة نهج ثم التراجع عنه.

عندما تظهر أفكار جديدة أثناء التنفيذ، حافظ على استقرار النطاق: اكتبها في قائمة متابعة، أوقف العمل لإعادة تحديد النطاق إذا غيرت معايير القبول، واجعل الالتزامات مربوطة بمعيار واحد في كل مرة.