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

playbook

اختبر فكرة تحت الضغط إلى spec للـ v1

حوّل فكرة feature غامضة إلى spec واضح للـ v1 — user stories، والـ edge cases التي لا تفكّر فيها، وسطر out-of-scope صريح — قبل أن يبني أحد.

سهل ~20 دقيقة

متى تلجأ إلى هذا

تبدو الفكرة بسيطة في رأسك — «دع المستخدمين يحفظون المقالات لاحقًا» — وبعد ثلاثة أسابيع لا تزال الهندسة تفكّك ما قصدته فعلًا. المفاجآت المكلفة (المقال نفسه محفوظًا مرتين، ماذا يحدث عند حذفه، هل يتزامن عبر الأجهزة) هي تلك التي تكتشفها في منتصف البناء، حين تكون مكلفة. هذا النظام يُنفق 20 دقيقة مقدّمًا في تحويل فكرة من سطر واحد إلى spec حادٍّ بما يكفي للتقدير عليه: stories، وedge cases، وسطر يقول ما الذي *لن* تفعله عمدًا في الـ v1.

جهّز هذا أولًا

  • الفكرة الخام بكلماتك أنت — لصق بريد العميل الإلكتروني، أو خيط Slack، أو ملف idea.md بفقرة أو فقرتين.
  • لمن هي تقريبًا والمهمة الواحدة التي عليها أداؤها — «قارئ، على قائمة المقالات، يريد العودة إلى هذا لاحقًا».
  • أي قيود صارمة تعرفها سلفًا — موعد نهائي، «web فقط حاليًا»، «يجب أن يعمل بدون حساب».

الـ workflow

  1. اطلب من Claude أن يقرأ الفكرة لك قبل أن يكتب أي spec

    لا تطلب spec من البداية الباردة. اجعل Claude يعيد صياغة الفكرة والمستخدم بكلماته أولًا — إن أساء فهم الهدف، تلتقطه الآن، لا بعد أن يكتب عشر stories للـ feature الخطأ.

    أنت تطلب 
    هذه فكرة خام: [الصق بريد العميل الإلكتروني / فقرتك]. قبل أن تكتب أي spec، اقرأها لي: لمن هذه، ما المهمة الواحدة التي تؤدّيها لهم، وما أبسط نسخة لا تزال مفيدة؟ لا تكتب user stories بعد.

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

    حركة «اقرأها لي أولًا» هذه هي أرخص التقاط لخطأ ستفعله على الإطلاق — تكلّف prompt واحدًا وتوفّر إعادة كتابة.

  2. احصل على الـ user stories

    الـ stories تجبر الفكرة على وحدات ملموسة «بصفتي [مستخدم] أستطيع [فعل]» يمكنك بناؤها فعلًا والتأشير عليها — أصعب على التهرّب من فقرة.

    أنت تطلب 
    الآن اكتب 4-6 user stories للـ v1، كلٌ بصيغة «بصفتي [مستخدم] أستطيع [فعل] كي [نتيجة]». أبقها على التدفّق الأساسي — الحفظ، العثور على المحفوظ، وإزالة الحفظ. لا nice-to-haves بعد.

    ما تحصل عليه stories محكمة قابلة للبناء — «بصفتي قارئًا أستطيع حفظ مقال من عرض القائمة كي أقرأه لاحقًا»، «بصفتي قارئًا أستطيع رؤية كل مقالاتي المحفوظة في مكان واحد»، «بصفتي قارئًا أستطيع إزالة الحفظ». كلٌ منها شيء تستطيع الهندسة تقديره وتستطيع أنت اختباره.

  3. أَظهِر الـ edge cases التي لا تفكّر فيها

    هنا يكسب Claude قُوته. الـ happy path بديهي؛ الـ spec الذي يفجّر التقدير هو ذاك الذي لم يُدرِج إلا الـ happy path.

    أنت تطلب 
    ما الـ edge cases وأنماط الفشل التي أفوّتها؟ فكّر في: حفظ المقال نفسه مرتين، الحفظ ثم يُحذف المقال أو يتغيّر، مستخدم خارج تسجيل الدخول يحاول الحفظ، بلوغ حدٍ ما، وما الذي ينبغي أن تُظهره قائمة Saved فارغة. لكلٍ، اقترح أبسط سلوك معقول.

    ما تحصل عليه قائمة بالمفاجآت — «الحفظ مرتين ينبغي أن يكون no-op، لا تكرارًا؛ مقال محذوف ينبغي أن يظهر كـ'لم يعد متاحًا' في Saved بدل أن يختفي بصمت؛ الحفظ خارج تسجيل الدخول ينبغي أن يطلب تسجيل الدخول». هذه القرارات التي كنت ستتخذها تحت الضغط في منتصف البناء.

    تصفّح هذه القائمة واتخذ القرارات الآن وهي رخيصة — edge case محسوم هو إجابة من سطر واحد؛ ومُكتشَف هو اجتماع.

  4. ارسم سطر الـ out-of-scope واجمع الـ spec

    سطر «ليس في الـ v1» الصريح هو ما يمنع بناء أسبوعين من أن يصبح بهدوء بناء شهرين. تسمية ما *لن* تفعله بأهمية ما ستفعله.

    أنت تطلب 
    اجمع spec للـ v1 من صفحة واحدة: ملخص من سطر واحد، الـ user stories، قرارات الـ edge cases، وقسم OUT OF SCOPE صريح (مثلًا لا مجلدات، لا مزامنة عبر الأجهزة، لا مشاركة بعد) مع سبب من سطر واحد لكل استبعاد. اختم بـ 3 أسئلة مفتوحة ما زلت أحتاج للإجابة عنها.

    ما تحصل عليه spec نظيف قابل للمشاركة بحدّ نطاق صارم — «خارج النطاق للـ v1: المجلدات/الوسوم، مزامنة المحفوظات عبر الأجهزة، مشاركة قائمة محفوظة. لماذا: كلٌ يضيف data model لا نحتاجه للتحقق من الفكرة الأساسية». إضافةً إلى بضعة أسئلة مفتوحة صادقة.

اجعله ملكك

  • **فكرة أكبر:** لشيء أكثر ضبابية من feature واحدة، شغّل هذا مرتين — مرة لكتابة spec لأصغر شريحة قابلة للتعلّم، ثم غذِّ ذلك الـ spec إلى **ابنِ prototype قابلًا للنقر كي تقرر** لتجعله حقيقيًا قبل أن تلتزم.
  • **لديك feedback سلفًا:** إن جاءت الفكرة من إشارة عميل، شغّل **اخلُص الـ feedback إلى إشارة roadmap** أولًا كي يكون الـ spec راسخًا في نمط حقيقي، لا طلبًا واحدًا عالي الصوت.
  • **احفظ الحركة:** بمجرد أن يعمل تسلسل الـ prompts، خزّنه كأمر مخصّص /spec (انظر تبويب *Features* في الـ Playbook) كي تكون الفكرة التالية أمرًا واحدًا، لا أربعة prompts.

انتبه إلى

  • Claude يسوّد الـ spec؛ أنت تمتلك النطاق. سطر الـ out-of-scope قرار منتج — يستطيع Claude اقتراح الاستبعادات، لكن تقرير ما *لن* يفعله الـ v1 قرارك للدفاع عنه، لا قراره.
  • spec بلا قسم edge-case هو ذاك الذي يفجّر التقدير. إن بدت قائمة edge-case من Claude قصيرة، فادفعها: «ما الذي يتكسّر أيضًا؟»
  • إن جاءت الفكرة من عميل، فلا تلصق اسمه أو بريده أو تفاصيل حسابه في الـ prompt — صِف الطلب، استبدل التفاصيل بـ [customer]، وأبقِ الـ spec عن الـ feature، لا عن الشخص.

ستحصل في النهاية على spec للـ v1 من صفحة واحدة — stories، edge cases محسومة، وسطر out-of-scope صريح — يمكنك تسليمه للهندسة لتقدير، في نحو الوقت الذي كان سيستغرقه خيط Slack غامض على أي حال.