لدى فريقك بالفعل الـ playbooks الخاصّة بـ idea-to-spec وprototype-to-decide — الوصفات المُجرَّبة لتحويل فكرة غامضة إلى spec للـ v1، وspec إلى شيء قابل للنقر. كلٌّ منها خطوة جيّدة، تُنجَز مرة واحدة، على فكرة واحدة. وهذه الوحدة هي الطبقة التي تحوّل تلك الخطوات المنفصلة إلى محرّك تحقّق: specs حادّة بما يكفي للتقدير عليها، وprototypes تكسب قرار بناء حقيقي أو عدمه قبل أن يُستدعى مهندس واحد.
إنها الوحدة الثانية من مسار Founders & PMs المؤهِّل للاعتماد، وترث كل ما بنيته في الوحدة الأولى. ملفّك product-context.md ليس قراءة خلفية هنا — إنه العقد الذي تُقيَّم مقابله specs هذه الوحدة: كل سطر out-of-scope ينبغي أن يتتبّع إلى anti-focus الحقيقي لديك، لا إلى تخمين جديد لما ينبغي أن يتخطّاه الـ v1. أتقنت الوحدة الأولى ماذا تبني ولمن؛ وتبني الوحدة الثانية المحرّك الذي يحوّل طلبًا إلى ميزة محسومة ومحدَّدة النطاق فوق ذلك الأساس — وتُقيّم المحرّك نفسه، لا قرارًا واحدًا حالفه الحظّ.
الـ spec ليس مجرّد قائمة ميزات — إنه رهان على ما يستحق البناء. «احفظ المقالات لوقت لاحق، v1: حفظ، وعثور، وإزالة» جملة تكلّف ثلاثة أسابيع من الوقت الهندسي إن كانت خاطئة. الـ playbooks المجانية تعلّمك أن تكتب spec لفكرة واحدة وprototype لتدفّق واحد بإتقان. وهذه الوحدة هي حيث يصير ذلك المعيار الذي يجتازه كل طلب — لأن صاحب الطلب لا يستطيع تمييز ميزة محدَّدة النطاق جيّدًا من ميزة غامضة، وليست تلك مهمّته.
المحرّك، لا الميزة لمرة واحدة
يستخدم معظم المؤسّسين Claude ككاتب spec أسرع: يلصقون فكرة، ويحصلون على user stories، وينتقلون إلى الشيء التالي. وهذا ليس نظامًا — إنه طريقة أسرع لشحن ميزة ناقصة النطاق. الـ spec الذي نجح مع طلب الشهر الماضي يُنسخ ويُلصق لطلب هذا الشهر دون إعادة فحص الـ edge cases، والـ prototype «يبدو صحيحًا» دون أن ينقره أحد كمبتدئ، وأول مرة يُربك فيها التدفّق مستخدمًا حقيقيًا، لا يستطيع أحد الإشارة إلى ما اختُبر فعلًا.
محرّك التحقّق خطوتان مُسمّاتان تجريان بالطريقة نفسها كل مرة، على كل طلب حقيقي:
- Spec — اقرأ الفكرة مرتدّةً قبل أن تكتب spec لأي شيء، واكتب user stories محكمة للتدفّق الأساسي، وأظهِر الـ edge cases التي يفوّتها spec الـ happy path، وارسم سطر out-of-scope صريحًا.
- Prototype — سمِّ القرار الواحد الذي على الـ prototype حسمه، وابنِ صفحة واحدة قابلة للفتح تُظهر ذلك فقط، وانقرها كمبتدئ مرتبك، واكتب ملاحظة القرار من خمسة أسطر التي هي المُخرَج الفعلي.
لكل خطوة مهمّة واحدة ومُخرَج واحد، وهذا ما يتيح لك تسمية ما تعطّل حين تُشحَن ميزة خاطئة: مشكلة spec (edge case لم يحسمه أحد، سطر نطاق تسلّل) أو مشكلة prototype (التدفّق لم يُنقَر فعلًا قط، ملاحظة القرار لم تُكتَب أبدًا). نظامٌ تستطيع تشخيص خلله خيرٌ من كومة specs لا تملك إلا الأمل بأنها كانت شاملة.
تُدير كلتا الخطوتين في المحادثة. افتح الـ spec الخاص بك وملف product-context.md في Claude Desktop، واعمل خطوة واحدة تلو الأخرى — لا حاجة إلى terminal في المسار الرئيسي.
Idea-to-spec — الانضباط الذي لا تستطيع الوصفة تعليمه
الـ playbook يعطيك الخطوات: اقرأ الفكرة مرتدّةً، واكتب الـ stories، وأظهِر الـ edge cases، وارسم الخط. أمّا الإتقان فهو الحُكم داخل تلك الخطوات — القرارات التي تفصل spec يصمد أمام صاحب مصلحة يعترض عن آخر يبدو شاملًا فحسب.
- القراءة المرتدّة هي أرخص التقاط لخطأ ستفعله على الإطلاق. إن أعاد Claude صياغة الفكرة وأخطأ في تحديد المستخدم أو المهمّة، فذلك إصلاح بـ prompt واحد الآن وإعادة كتابة لاحقًا. والقفز مباشرةً إلى user stories يعني أنك قد تكتب spec لأربع stories لميزة خاطئة قبل أن يلاحظ أحد.
- الـ edge cases المحسومة الآن رخيصة؛ والمُكتشَفة في منتصف البناء اجتماع. «ماذا يحدث إن حُفظ العنصر نفسه مرّتين» إجابة من سطر واحد في spec، وخيط Slack مليء بالآراء بعد ثلاثة أسابيع من البناء. ادفع نفسك إلى ما بعد stories الـ happy path الواضحة — هنا يكسب Claude قيمته، وهنا تتوقّف معظم الـ specs مبكّرًا جدًا.
- سطر out-of-scope قرار منتج، لا اقتراحًا تقبله. يستطيع Claude اقتراح ما يُستبعد من الـ v1 بتبريرات جيّدة؛ أمّا تقرير ما لن تفعله النسخة الأولى فعلًا، والدفاع عن ذلك أمام فريقك، فلك أنت. spec بلا قسم out-of-scope ليس محكمًا، بل ناقصًا — وهو ذاك الذي ينمو بهدوء إلى بناء شهرين.
- جرّد طلب العميل الحقيقي من هويته قبل أن يصير مُدخَل spec. إن جاءت الفكرة من بريد عميل، فينبغي أن يكون الـ spec عن الميزة ومستخدميها بصورة مجرّدة — لا مرتبطًا ببريد وارد لشخص بعينه.
الـ spec الذي يتجاوز هذا المستوى يُقرأ كوثيقة من صفحة واحدة يستطيع شخص غريب تسليمها للهندسة من أجل تقدير: 4-6 user stories محكمة على التدفّق الأساسي، والـ edge cases محسومة (لا مُدرَجة فحسب)، وقسم out-of-scope صريح بسبب من سطر واحد لكل استبعاد، وقائمة قصيرة بأسئلة مفتوحة فعلًا.
Prototype-to-decide — مبني للإجابة عن سؤال واحد، لا للإبهار
الـ prototype الذي يحاول إظهار كل شيء لا يثبت شيئًا، والـ prototype الذي لا ينقره أحد فعلًا كمستخدم مرتبك هو بعد ظهر ضائع يرتدي زيّ التحقّق.
- سمِّ القرار قبل أن تُبنى أي شاشة. «هل يبدو الحفظ-ثم-العثور بديهيًا لقارئ لأول مرة؟» سؤال يحصر الـ prototype في أقل عدد من الشاشات التي تجيب عنه. والـ prototype المبني دون قرار مُسمّى يميل إلى أن ينمو إلى شيء يُظهر كل شيء ولا يحسم شيئًا.
- ملف واحد مكتفٍ بذاته هو ما يجعله قابلًا للرمي، لا بداية مسبقة. الـ prototype الذي يحتاج خطوة install أو build process يكفّ عن أن يكون شيئًا تستطيع تسليمه لأي أحد في ثلاثين ثانية — وكلّما سهُل فتحه، زاد احتمال أن يُنقَر فعلًا بدلاً من أن يُوصَف فقط في اجتماع.
- انقره كالمبتدئ المرتبك الذي بُني من أجله، لا كالشخص الذي صمّمه. الاحتكاك الذي تصطدم به وأنت تنقر حوله — «مهلًا، أين تبويب Saved؟» — هو بالضبط الإشارة التي جئت لأجلها. وتصفّح الـ prototype بالطريقة التي تتصفّح بها عملك أنت يُفسد الغاية.
- ملاحظة القرار هي المُخرَج؛ ملف HTML ليس كذلك. بمجرّد أن تكتب ملاحظة الخمسة أسطر — هل يعمل، وما الذي يحتاج تغييرًا، وهل يستحق وقتًا هندسيًا — يكون الـ prototype قد أدّى مهمّته. وتسليم ملف HTML ببيانات وهمية للهندسة كبداية مسبقة يُطلق بالضبط الاختصارات التي أخذتها للتحرك بسرعة.
زوج الـ prototype وملاحظة القرار الذي يتجاوز هذا المستوى يسمّي السؤال الواحد الذي اختبره، ويُشحَن كملف واحد قابل للفتح ببيانات وهمية واقعية، وينتهي بملاحظة قرار من خمسة أسطر صادقة حين تكون الإجابة «ليس بعد».
ملاحظة عن الـ specs العربية
معظم انضباط هذه الوحدة مستقل عن اللغة — الـ edge case هو edge case بأي لغة. لكن شيئين يتغيّران فعلًا في منتج ثنائي اللغة. أولًا، إن كان النص الذي يراه المستخدم في الـ spec سيُشحَن بالعربية، فألِّف النصوص العربية مباشرةً بدلاً من ترجمة النص الإنجليزي المؤقّت في الـ spec — الترجمة الحرفية لـ”Save for later” نادرًا ما تُقرأ بالطريقة التي ينبغي أن يُقرأ بها نص منتج عربي أصيل. ثانيًا، إن كنت تبني prototype لينقره عميل خليجي، فابنِه باللغة التي سيستخدم بها المنتج فعلًا؛ فـ prototype بلغة خاطئة يختبر ردّ فعل خاطئ.
تكليفك
ابنِ محرّك التحقّق لـ طلب حقيقي واحد — طلبك أنت (المُوصى به: المُخرَج ميزة يحدّد فريقك نطاقها ويقرّر بشأنها فعلًا) أو العلامة النموذجية ميزان، أداة مسك الدفاتر السحابية لدول الخليج التي تظهر شريكتها المؤسِّسة ورئيسة المنتج، دانا القاسمي، طوال هذا المسار. كل ما هنا يرث ملفّات الأساس من الوحدة الأولى؛ وإن لم يكن لديك ملف product-context.md بعد، فأنجِز الوحدة الأولى أولًا. افتح المحادثة في Claude Desktop مع وثيقة السياق والطلب — لا حاجة إلى terminal.
مُخرَج الوحدة الثانية — محرّك التحقّق
يرث من الوحدة الأولى: product-context.md
1. spec.md (مُخرَج idea-to-spec)
- القراءة المرتدّة: لمن هذا والمهمّة الواحدة التي يؤدّيها، مؤكَّدة
قبل أن تُكتَب أي story
- 4-6 user stories للتدفّق الأساسي فقط
- الـ edge cases، كلٌّ بسلوك محسوم (لا متروكًا مفتوحًا)
- قسم OUT OF SCOPE صريح، كل استبعاد بسبب من سطر واحد،
مُدقَّق مقابل anti-focus الحقيقي في product-context.md
- 3 أسئلة مفتوحة فعلًا
2. prototype.html + decision-note.md (مُخرَج prototype-to-decide)
- القرار الواحد الذي بُني هذا الـ prototype للإجابة عنه
- ملف واحد مكتفٍ بذاته وقابل للفتح ببيانات وهمية واقعية
- ملاحظة قرار من 5 أسطر: هل يعمل التدفّق، وما الذي يجب أن يتغيّر،
وهل يستحق وقتًا هندسيًا — صادقة إن كانت الإجابة "ليس بعد"
PII: إن جاء الطلب من عميل حقيقي، فاسمه وبريده الإلكتروني وتفاصيل
حسابه تبقى خارج كل ملف. صِف الطلب، واستبدل التفاصيل بـ [customer].حقيبة أدوات الأساس تحوي قالب product-context.md الذي تُختبَر specs هذه الوحدة تحت الضغط مقابله.
كيف يُقيَّم — سُلّم التقييم
هذا هو الجزء الذي لا تملكه الـ playbooks المجانية، والجزء الذي يجعل للاعتماد معنى. يُقيَّم مُخرَجاك مقابل خمسة معايير. كلٌّ منها بدرجة مستوفٍ / قريب / ليس بعد — و«قريب» في أيٍّ منها يعني إعادةً، لا اجتيازًا.
سُلّم تقييم محرّك التحقّق
1. الـ spec مؤسَّس على القراءة المرتدّة الحقيقية
المستخدم والمهمّة مؤكَّدان قبل أن تُكتَب أي story، والـ stories تتتبّع
إلى تلك القراءة المرتدّة المؤكَّدة، لا إلى تخمين جديد.
2. الـ edge cases محسومة، لا مُدرَجة فحسب
كل edge case مُسمّى له حلّ مذكور. "استخدم حُكمك" ليس edge case
محسومًا.
3. سطر out-of-scope حقيقي ومُدقَّق
كل استبعاد له سبب من سطر واحد، وواحد منها على الأقل يرتبط صراحةً
بـ anti-focus في product-context.md — لا مُختلَقًا من جديد.
4. الـ prototype يجيب عن سؤال واحد مُسمّى
الشاشات المبنية هي الحدّ الأدنى اللازم لاختبار القرار المذكور —
لا جولة في الميزة كاملةً.
5. ملاحظة القرار صادقة
"ليس بعد" أو "يحتاج وقتًا هندسيًا لا نملكه الآن" الصادقة تُقيَّم
مثل "ابنِه" تمامًا — المعيار هو الصدق، لا التفاؤل.الانضباط هو عمدًا ما سيطلبه قائد هندسة متشكّك: edge case تُرك دون حسم، أو prototype لم ينقره أحد فعلًا، يفشل بصمت بعد ثلاثة أسابيع من البناء — فوجب التقاطه هنا.
المعيار، مرئيًّا — نموذج إجابة محلول (ميزان)
لست مضطرًّا لتخمين شكل «مستوفٍ». إليك مقتطفًا ناجحًا للعلامة النموذجية — نسختك لا تحتاج أن تبدو هكذا، بل تحتاج أن تتجاوز المعيار نفسه. هذه وثائق دانا القاسمي، بُنيت في الأسبوع الذي كان فريق ميزان يقرّر فيه كيف يستجيب لحادثة فوترة.
spec.md — ميزان: «وضع علامة على رسم» (مقتطف)
القراءة المرتدّة، مؤكَّدة قبل كتابة أي story: هذا لعميل في ميزان يرى على
حسابه رسمًا لا يعرفه أو يظنّه خاطئًا — وعلى نحو أكثر إلحاحًا، أي شخص
تأثّر بحادثة الفوترة المزدوجة في 1 مارس. أبسط نسخة مفيدة: زر على أي
رسم يضع عليه علامة للمراجعة، ومكان يرى فيه الدعم ما وُضعت عليه علامة.
User stories (v1، التدفّق الأساسي فقط):
بصفتي عميلًا، أستطيع وضع علامة نزاع على رسم في فاتورتي، كي يعرف
الدعم أن عليه مراجعته دون أن أفتح تذكرة.
بصفتي عميلًا، أستطيع رؤية الرسوم التي وضعتُ عليها علامة بالفعل، كي
لا أضع علامة على الرسم نفسه مرّتين.
بصفتي موظّف دعم، أستطيع رؤية كل الرسوم المُعلَّمة في مكان واحد مع
اسم العميل والمبلغ، كي أُرتّب الأولويات دون البحث في التذاكر.
Edge cases، محسومة:
وضع علامة على الرسم نفسه مرّتين ← no-op، الزر يعرض حالة "Flagged"،
ولا يُنشئ علامة مكرّرة.
رسم مُسترَدّ بالفعل ← العلامة تُقبَل لكنها تُحسَم تلقائيًا بملاحظة
("مُسترَدّ بالفعل في [date]")، لا تُترَك مفتوحة.
رسم وُضعت عليه علامة بعد أن أُغلقت الفاتورة في دفاتر المالية ← يُقبَل
رغم ذلك؛ وتحمل العلامة وسم "مُغلَق بالفعل في المالية" كي يعرف الدعم
أن عليه التنسيق قبل عكس أي شيء.
OUT OF SCOPE للـ v1 (مُدقَّق مقابل product-context.md):
لا استرداد تلقائي — إنسان يراجع كل علامة قبل أن يتحرّك أي مال.
لماذا: رهان الثقة في الفوترة في product-context.md هو "كل رسم صحيح
ومُثبَت أنه كذلك" — والاسترداد التلقائي يُزيل الجزء المُثبَت
والمُراجَع.
لا معالجة نزاعات متعدّدة العملات — product-context.md يستبعد بالفعل
تعدّد العملات بما يتجاوز AED/SAR/QAR في هذه المرحلة.
أسئلة مفتوحة: هل يحتاج الدعم SLA على الرسوم المُعلَّمة؟ هل ينبغي أن
توقِف العلامة التجديد التالي لذلك الاشتراك؟ من يملك تنسيق "مُغلَق
بالفعل في المالية"؟decision-note.md — ميزان: prototype «وضع علامة على رسم» (مقتطف)
القرار الذي اختبره هذا الـ prototype: هل وضع علامة على رسم يبدو فعلًا
إجراءً واضحًا وسهلًا من عرض الفاتورة — لا مدفونًا في صفحة إعدادات لا
يجدها أحد أثناء نزاع فوترة فعلي؟
ما نقرته: فتحتُ قائمة الفواتير الوهمية، ووجدتُ زر العلامة من أوّل
محاولة دون أن يُقال لي أين أنظر، ووضعتُ علامة على رسم، واستطعتُ رؤيته
مُعلَّمًا فورًا حين عدتُ إلى القائمة.
ما بدا خاطئًا: استخدمت حالة "مُعلَّم" اللونَ الرمادي نفسه المستخدَم
لفاتورة مدفوعة — يسهل تفويته عند نظرة سريعة. حدّثتُ الـ prototype
ليستخدم معالجة بصرية مختلفة بوضوح لحالة "مُعلَّم".
ملاحظة الخمسة أسطر: التدفّق يعمل بمجرّد أن تصير حالة "مُعلَّم" مميَّزة
بصريًا؛ يستحق البناء، بتقدير صغير-متوسّط مقابل نطاق codebase-map.md؛
أكبر مخاطرة مفتوحة هي edge case التنسيق مع المالية، لا واجهة
المستخدم — أوصي بمزامنة سريعة مع المالية قبل أن يذهب هذا إلى الهندسة.ما الذي أثبتّه — وما التالي
اجتَز سُلّم التقييم وتكون قد أثبتّ ما لا تستطيع الـ playbooks المجانية وحدها اعتماده: أنك تستطيع تحويل طلب غامض إلى spec يستطيع شخص غريب التقدير منه، وprototype إلى قرار بناء حقيقي وقابل للدفاع عنه. تلك هي مرحلة محرّك التحقّق من «Founders & PMs المعتمَدون مع Claude».
من هنا يحوّل المسار فكرة مُتحقَّقًا منها إلى عملية منتج كاملة، وتُقيَّم كل وحدة بالطريقة نفسها:
- الوحدة الثالثة — من الإشارة إلى القرار: تجميع feedback متناثر في إشارة roadmap قابلة للدفاع عنها، وتحويل الخيارات إلى قرار تستطيع الدفاع عنه.
- الوحدة الرابعة — خط أنابيب الـ roadmap: تشغيل نظام أصحاب المصلحة الأسبوعي، وربط القوس كاملًا من الطلب إلى الجهوزية لـ roadmap.
- الوحدة الخامسة — التخطيط والمجلس: تشغيل التخطيط الربعي بقائمة استبعادات حقيقية، ثم المشروع الختامي — Roadmap-in-a-Box، نظام المنتج الكامل من الأساس إلى الشهادة.
أوّلًا، اجعل هذا قابلًا لإعادة الاستخدام: بنية الـ spec وصيغة ملاحظة القرار في الـ prototype هما الأثران الدائمان — احفظهما كملاحظة تعيد استخدامها لكل طلب، كي تبدأ فكرة الشهر القادم من بنية جاهزة، لا من صفحة فارغة. وإن كنت تطرح هذا عبر فريق، فإن دليل التشغيل هو طبقة القرار وأمان البيانات التي تتموضع تحت النظام كاملًا.