EN
ابدأ هنا المواضيع الفِرَق المرجع المستجدّات المحفوظات
playbook

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

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

متقدّم ~نصف يوم
متى تلجأ إلى هذا

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

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

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

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

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

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

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

  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 الخاص بك بالإنجليزية البسيطة

    اربط البناء بالواقع. افتح مجلد الـ repo في Claude Desktop واسأل بالإنجليزية البسيطة — قراءة الكود لتحديد نطاقه لا تحتاج Terminal ولا مهندسًا في الغرفة. سؤال أين ستعيش الميزة فعلًا يحوّل تخمينًا عن الجهد إلى نطاق تستطيع الدفاع عنه أمام الهندسة.

    أنت تطلب
    افتح الـ 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 الخاص بك بالإنجليزية البسيطة بـ«كبير»، فرّع الخطوة الأخيرة إلى حوّل الخيارات إلى قرار تستطيع الدفاع عنه كامل يقارن البناء مقابل خيار جاهز.
  • اجعلها عملية قائمة (مسار `Power Track`): اربط السلسلة في أمر مخصّص /feature-intake (انظر تبويب Capabilities) كي يمرّ كل طلب عميل عبر سلسلة الاختبارات نفسها المبنية على الأدلة، لا فقط من يصرخون بأعلى صوت. الأوامر المخصّصة خطوة اختيارية في مسار Power Track — على Claude Desktop يمكنك إبقاء prompts السلسلة في ملاحظة وتشغيلها تباعًا بدلًا من ذلك.
انتبه إلى
  • تحقّق من الحقائق الحاملة عند كل تسليم — عدد العملاء المتمايزين، تقدير الجهد الهندسي، الاقتباسات. رقم خاطئ واثق يتراكم عبر خمس خطوات؛ المذكّرة صادقة بقدر الأرقام التي تغذّيها فقط، فراجعها مقابل المصدر، لا مقابل ما يستذكره Claude.
  • هذه بيانات عملاء حقيقية وكودك المملوك. أزل هوية الـ feedback ([customer-n]) قبل أي prompt، وعامل الـ codebase على أنه سري، وتذكّر أن المذكّرة هي بالضبط نوع المستند الذي يُعاد توجيهه — أبقِ التفاصيل خارج أي شيء لا تُريه للشركة بأكملها.
  • Claude يخوض سلسلة الاختبارات؛ أنت تلتزم بالموارد. هو يخلُص ويكتب الـ spec ويصنع الـ prototype ويحدّد النطاق ويسوّد المذكّرة — لكن وضع ميزة على الـ roadmap قرار بشري تمتلكه وتدافع عنه. الغاية كلها أن تتخذ هذا القرار على أساس الأدلة، لا أن تُزيل حُكمك منه.

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

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

كم يستغرق هذا التدفّق الكامل فعلًا؟
نحو نصف يوم في المرة الأولى — ما يقارب 40 دقيقة لخلاصة الـ feedback، و20 دقيقة للـ spec، و30 دقيقة للـ prototype، و30 دقيقة لتحديد نطاق الـ codebase، و30 دقيقة للمذكّرة. الوقت الأكبر يذهب في جمع المدخلات؛ بمجرد أن تكون جاهزة، يتولّى Claude التجميع في كل خطوة.
ما الذي أحتاج تجهيزه قبل البدء؟
تحتاج الطلب المُطلِق إضافةً إلى ملفات الـ feedback الأوسع (support export وملاحظات المبيعات والـ transcripts مع استبدال الأسماء بـ [customer-n])، والـ codebase مفتوحًا كمجلد في Claude Desktop، ومستند عمل `roadmap-feature.md`. القوس كله يجري في Claude Desktop — بلا حاجة إلى Terminal. معايير قرارك للربع — ما الذي تُحسِّن لأجله — ضرورية أيضًا كي تكون المذكّرة النهائية مُوزَّنة على طريقتك.
هل من الآمن تغذية الـ codebase وبيانات العملاء في هذا التدفّق؟
أبقِ كليهما في بيئتك المُعتمَدة — لا تلصق مقتطفات كود مملوكة أو support exports خامة في أدوات عامة. أزل هوية كل feedback باستخدام تسميات `[customer-n]` قبل أن يدخل أي prompt، وعامل المذكّرة الناتجة كمستند داخلي فقط، لأنها تلخّص كلا المصدرين.
ماذا يحدث إذا مات التدفّق في الخطوة الأولى لأن الطلب ليس حقيقيًا؟
هذه نتيجة ناجحة، لا فشل. قرار «ليس الآن» موثَّق ومبني على الأدلة يمكنك إرساله للعميل الطالب هو تحديدًا ما صُمِّمت هذه الخطوة لإنتاجه — التوقّف مبكرًا يعني أنك وفّرت بقية بعد الظهر، وهو أرخص ربح في التدفّق كله.