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

playbook

من طلب العميل إلى الجاهزية للـ roadmap، من البداية للنهاية

خذ طلبًا من صندوق الوارد إلى الجاهزية للـ roadmap — اخلُص الطلب، حوّله إلى spec، اصنع له prototype، حدّد نطاقه مقابل الكود، واكتب مذكّرة القرار — كي تلتزم بالوقت الهندسي على أساس الأدلة، وهي اللعبة الكبرى التي تربط المجموعة معًا.

متقدّم ~نصف يوم

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

يصل طلب — «هل يمكنك إضافة طريقة لحفظ المقالات لاحقًا؟» — والمساران الكسولان سيّئان بالقدر نفسه: أن تبنيه على حدس، أو أن تدفنه لأنك غير متأكد. هذه هي اللعبة الختامية التي تمشي القوس كاملًا في عصر واحد: أثبت أن الطلب حقيقي، اشحذه إلى spec، ابنِ شيئًا قابلًا للنقر كي تقرر، اقرأ الكود لتحديد نطاقه، واكتب المذكّرة التي تلتزم بالموارد. تربط هذه الـ playbooks الخمس الأخرى لقسم Founders & PMs في تدفّق واحد، فبحلول وصول الـ feature إلى الـ roadmap، يكون كل ادّعاء وراءه — أن العملاء يريدونه، أنه مُعرَّف جيدًا، أن التدفّق يعمل، أننا نستطيع بناءه، أنه يستحق — مدعومًا بشيء حقيقي.

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

  • الطلب المُطلِق *إضافةً إلى* كومة الـ feedback الأوسع — support-export.csv وsales-notes.md والـ transcripts — كي تختبر ما إذا كان بريد إلكتروني واحد نمطًا فعلًا.
  • الـ codebase الخاص بك، قابلًا للفتح في Claude Code، ومعايير قرارك للربع (ما الذي تُحسّن لأجله: السرعة، التكلفة، الـ retention).
  • مستند عمل roadmap-feature.md لتجميع الـ spec وملاحظة القرار والنطاق والمذكّرة وأنت تتقدّم — الخيط الناظم الذي يربط الخطوات معًا.

الـ workflow

  1. أثبت أن الطلب حقيقي — اخلُص الـ feedback إلى إشارة roadmap

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

    أنت تطلب 
    شغّل خلاصة الـ feedback على الملفات المرفقة (الأسماء مُستبدَلة سلفًا بـ [customer-n]): هل «حفظ المقالات لاحقًا» نمط حقيقي؟ كم عميلًا متمايزًا (DISTINCT) أثاره، عبر أي segments، واسحب الاقتباسات الحرفية وراءه. كن صادقًا إن كان حقًا مجرد حساب واحد عالي الصوت.

    ما تحصل عليه حُكم راسخ مع إيصالات — «نمط حقيقي: 6 من 14 عميلًا متمايزًا عبر اثنين من الـ segments؛ الاقتباسات مرفقة». أو النسخة الصادقة — «حساب enterprise واحد، ذُكر 5 مرات — عالٍ، لا واسع». إن كان ضجيجًا، فقد وفّرت العصر كله؛ وإن كان حقيقيًا، تحمل الاقتباسات قُدمًا كأدلة.

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

  2. اشحذه إلى spec — اختبر فكرة تحت الضغط إلى spec للـ v1

    حوّل الطلب الذي تم التحقق منه إلى v1 واضح، مستخدمًا اقتباسات العملاء مصدرًا للـ user stories كي يبقى الـ spec مربوطًا بما طلبه الناس فعلًا.

    أنت تطلب 
    باستخدام اقتباسات العملاء تلك مصدرًا، اكتب spec للـ v1 لميزة «حفظ المقالات لاحقًا»: 4-6 user stories مستمدّة من الاقتباسات، الـ edge cases التي لا أفكّر فيها، وسطر out-of-scope صريح للـ v1. ألحقه بـ roadmap-feature.md.

    ما تحصل عليه spec من صفحة واحدة، تتعقّب فيه الـ stories اقتباسات حقيقية، والـ edge cases محسومة (الحفظ مرتين ← لا عملية؛ مقال محذوف ← «لم يعد متاحًا»)، والـ v1 يستبعد صراحةً المجلدات والمزامنة عبر الأجهزة. الطلب صار الآن تعريفًا قابلًا للبناء.

  3. ابنِه كي تقرر — ابنِ prototype قابلًا للنقر كي تقرر

    اجعل الـ spec قابلًا للنقر قبل أن تلتزم بالوقت الهندسي. التفاعل مع تدفّق حقيقي يلتقط مشكلات «آه، تبويب Saved ينبغي أن يكون في المستوى الأعلى» وهي ما تزال مجانية الإصلاح.

    أنت تطلب 
    من الـ spec، ابنِ ملف prototype.html واحدًا مكتفيًا بذاته (HTML/CSS/JS مضمّنًا، قابلًا للفتح بنقرة مزدوجة) مع 5 مقالات وهمية، وزر Save، وتبويب Saved. سأنقر عليه وأخبرك بما يبدو خاطئًا. ثم اكتب ملاحظة القرار من 5 أسطر: هل يعمل التدفّق، ما الذي يجب أن يتغير، هل يستحق الوقت الهندسي؟

    ما تحصل عليه ملف prototype.html قابل للفتح تنقر فيه، ثم ملاحظة قرار قصيرة — «التدفّق يعمل بمجرد أن يُظهر Save حالة مؤكَّدة وأن يكون تبويب Saved في المستوى الأعلى؛ يستحق البناء؛ مخاطرة مفتوحة: المقالات غير المنشورة». الـ prototype شيء قابل للرمي بنيته كي تقرر؛ الملاحظة هي ما تحتفظ به.

    الـ prototype للقرار، لا للإطلاق — بمجرد كتابة ملاحظة القرار، يكون قد أدّى دوره. لا تُسلّم الـ HTML ذا البيانات الوهمية للهندسة كبداية مسبقة.

  4. حدّد نطاقه مقابل الكود — اقرأ codebase الخاص بك بالإنجليزية البسيطة

    اربط البناء بالواقع. سؤال أين ستعيش الـ feature فعلًا يحوّل تخمينًا عن الجهد إلى نطاق تستطيع الدفاع عنه أمام الهندسة.

    أنت تطلب 
    افتح الـ codebase الخاص بنا. لميزة المقالات المحفوظة هذه، أي ملفات موجودة سيمسّها مهندس على الأرجح، وما الملفات/الجداول الجديدة التي ستلزم، وكم حجم العمل تقريبًا (صغير/متوسط/كبير)؟ أنا أحدّد نطاق محادثة الهندسة، لا أكتب الكود.

    ما تحصل عليه نطاق راسخ — «يمسّ component قائمة المقالات وطبقة البيانات؛ يحتاج جدول saved_articles جديدًا، وعرض Saved، وAPI route للحفظ/إلغاء الحفظ؛ جهد متوسط». التقدير الآن مرتبط بما يمسّه فعلًا، لا رقمًا اختلقته.

  5. التزم بالموارد — حوّل الخيارات إلى قرار تستطيع الدفاع عنه

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

    أنت تطلب 
    اجمع مذكّرة قرار / PRD من صفحة واحدة من roadmap-feature.md: المشكلة ولمن هي، دليل الطلب (عدد العملاء المتمايزين + الاقتباسات)، الـ spec للـ v1 وسطر النطاق، ملاحظة قرار الـ prototype، النطاق الهندسي والجهد، توصية واضحة بالبناء/التأجيل مع تبريرها، أكبر مخاطرة، والأسئلة المفتوحة. ثم اختبره بأسلوب الـ red-team كتنفيذي متشكّك.

    ما تحصل عليه مذكّرة جاهزة للـ roadmap — «ابنِ المقالات المحفوظة في الـ v1: يريدها 6 عملاء متمايزون (اقتباسات)، جهد هندسي متوسط، تدفّق مُتحقَّق منه بالـ prototype؛ أوصي بهذا الربع؛ أكبر مخاطرة: معالجة المقالات غير المنشورة؛ سؤال مفتوح: أثر الـ retention غير مُقاس» — إضافة إلى تمريرة red-team. قرار تستطيع الدفاع عنه سطرًا سطرًا.

اجعله ملكك

  • **يموت عند الخطوة 1:** إن قالت **اخلُص الـ feedback إلى إشارة roadmap** إن الطلب ليس حقيقيًا، فهذا *هو* المُخرَج — قرار «ليس الآن» موثَّق ومبني على الأدلة يمكنك إرساله للعميل الطالب، بلا حاجة لخطوات أخرى.
  • **مفترق build مقابل buy:** إن عاد النطاق من **اقرأ codebase الخاص بك بالإنجليزية البسيطة** بـ«كبير»، فرّع الخطوة الأخيرة إلى **حوّل الخيارات إلى قرار تستطيع الدفاع عنه** كامل يقارن البناء مقابل خيار جاهز.
  • **اجعلها عملية قائمة:** اربط السلسلة في أمر مخصّص /feature-intake (انظر تبويب *Features*) كي يمرّ كل طلب عميل عبر سباق الأدلة نفسه، لا فقط من يصرخون بأعلى صوت.

انتبه إلى

  • تحقّق من الحقائق الحاملة عند كل تسليم — عدد العملاء المتمايزين، تقدير الجهد الهندسي، الاقتباسات. رقم خاطئ واثق يتراكم عبر خمس خطوات؛ المذكّرة صادقة بقدر الأرقام التي تغذّيها فقط، فراجعها مقابل المصدر، لا مقابل ما يستذكره Claude.
  • هذه بيانات عملاء حقيقية وكودك المملوك. أزل هوية الـ feedback ([customer-n]) قبل أي prompt، وعامل الـ codebase على أنه سري، وتذكّر أن المذكّرة هي بالضبط نوع المستند الذي يُعاد توجيهه — أبقِ التفاصيل خارج أي شيء لا تُريه للشركة بأكملها.
  • Claude يخوض السباق؛ أنت تلتزم بالموارد. هو يخلُص ويكتب الـ spec ويصنع الـ prototype ويحدّد النطاق ويسوّد المذكّرة — لكن وضع feature على الـ roadmap قرار بشري تمتلكه وتدافع عنه. الغاية كلها أن تتخذ هذا القرار على أساس الأدلة، لا أن تُزيل حُكمك منه.

ستحصل في النهاية على مذكّرة قرار / PRD جاهزة للـ roadmap، حيث كل ادّعاء — أن العملاء يريدونه، أنه مُعرَّف جيدًا، أن التدفّق يعمل، أنك تستطيع بناءه، أنه يستحق — مدعوم بأثرٍ حقيقي من الـ playbooks الخمس التي تربطها، كي تلتزم بالوقت الهندسي على أساس الأدلة بدل حدس.