أليست كتابة ملخّص أبطأ من مجرّد سحب الأرقام؟

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

ماذا لو لم يكن الطالب يعرف فعلًا ما يريده؟

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

كيف يختلف هذا عن playbook قاموس الـ metrics؟

قاموس الـ metrics يعرّف ما تعنيه الـ metrics مرة واحدة، للفريق كله. أما الملخّص التحليلي فيحدّد نطاق طلب واحد — أيًّا من تلك الـ metrics يحتاجه، ولأي شريحة، ولخدمة أي قرار. الملخّص يستشهد بالقاموس؛ لا يعيد تعريف الـ metrics. وإن احتاج ملخّص إلى metric لا يملكه القاموس، فتلك إشارة للذهاب وتعريفه هناك أولًا، لا لابتكار تعريف لمرة واحدة هنا.

هل أرسل الملخّص إلى صاحب المصلحة أم أحتفظ به لنفسي؟

أرسله — فذلك بيت القصيد. ملخّص تحتفظ به لنفسك مجرّد ملاحظات؛ أما ملخّص يوافق عليه الطالب فهو عقد خفيف. موافقته السريعة («نعم» أو «أضِف X أيضًا») هي ما يتيح لك البناء بثقة وما يحوّل «هذا ليس ما طلبته» لاحقًا إلى محادثة حول نطاق متّفق عليه بدل إعادة بناء غير مدفوعة.

حوّل طلبًا غامضًا إلى ملخّص تحليلي قابل للإجابة

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

«هل يمكنك سحب بعض الأرقام عن الـ churn؟» ليس سؤالًا — إنه بداية ثلاث جولات من إعادة العمل. تبني شيئًا، فيقولون «ليس تمامًا ما قصدته»، فتعيد البناء، ويتأخّر الموعد النهائي بينما الجميع متضايق. الحل ليس أن تكتب الـ query أسرع؛ بل أن تنفق عشرين دقيقة في تحويل الطلب الغامض إلى ملخّص قابل للإجابة قبل أن تلمس البيانات — القرار الذي يخدمه، والأسئلة الدقيقة، والـ metrics والمصادر بالضبط، والشرائح، وما هو خارج النطاق صراحةً. تثبيت السؤال هو أعلى حركة تحليلية مردودًا على الإطلاق: إنه الفرق بين أن تجيب عمّا طلبوه وأن تجيب عمّا قصدوه.

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

الطلب الأصلي كما وصل — رسالة الـ Slack، أو الـ email، أو السطر من الاجتماع. لا تُعِد صياغته؛ أنت تريد الكلمات الفعلية لترى ما هو الغامض فيها.
من يطلب وأي قرار سيتّخذه بالإجابة — رقم يغيّر قرارًا ورقم لمجرّد الفضول يُحدَّد نطاقهما بطريقتين مختلفتين تمامًا.
الموعد النهائي والصيغة التي يحتاجونها، وقاموس الـ metrics لديك (metrics.md) حتى تشير تعريفات الملخّص إلى المتّفق عليها، لا إلى تعريفات مبتكَرة للتو.

الـ workflow

ثبّت القرار الكامن خلف الطلب

افتح المجلد الذي يحوي الطلب وملف metrics.md لديك في Claude Desktop واسأل في المحادثة — دون الحاجة إلى terminal. قبل أي أسئلة أو queries، أجبر الهدف الحقيقي على الظهور: ماذا سيفعل هذا الشخص بشكل مختلف تبعًا للإجابة؟ كل ما يأتي بعد ذلك — أي الأسئلة يهم، ومدى الدقة المطلوبة — يتعلّق بهذا.

أنت تطلب

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

ما تحصل عليه قراءة دقيقة للقرار الكامن إضافة إلى 3–4 أسئلة توضيحية لإعادتها: «هل تقرّر ما إذا كنت ستموّل حملة retention، أم تبلّغ مجلس الإدارة بالـ churn؟ أي شريحة — كل العملاء، أم الـ enterprise؟ وبحلول متى؟». تعرف ما قصدوه قبل أن تبني لما قالوه.

القرار هو المرساة. «انظر في الـ churn» لـ تقرير ميزانية retention و«انظر في الـ churn» لـ وضع رقم في عرض لمجلس الإدارة تحليلان مختلفان — لا تبدأ حتى تعرف أيهما.
حوّل الطلب الغامض إلى أسئلة دقيقة قابلة للإجابة

الطلب المبهم يخفي عدة أسئلة دقيقة. فكّكه إلى الأسئلة المحدّدة القابلة للإجابة — كلٌّ منها مصاغ بحيث تعرف الإجابة حين تراها.

أنت تطلب

بناءً على ذلك القرار، فكّك الطلب إلى قائمة قصيرة من الأسئلة الدقيقة القابلة للإجابة — كلٌّ منها محدّد بما يكفي لأتعرّف على الإجابة («ما هو الـ logo churn الشهري لحسابات الـ enterprise خلال آخر 4 أرباع؟» لا «كيف حال الـ churn؟»). رتّبها حسب مقدار تأثير كلٍّ منها فعليًا على القرار، واحذف تلك التي يُستحسن معرفتها لكنها لن تغيّر شيئًا.

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

الآن اجعله قابلًا للبناء. لكل سؤال، سمِّ الـ metric بالضبط (من القاموس)، ومصدر البيانات، والتقسيم — حتى لا يبقى أي غموض في التعريف لتكتشفه في منتصف الطريق.

أنت تطلب

لكل سؤال، حدّد ما يلزم للإجابة عنه: الـ metric بالضبط وتعريفه من metrics.md (نبّهني على أي metric لم نعرّفه بعد — فهذا عائق يجب حلّه أولًا)، ومصدر البيانات أو الملف، والشرائح/التقسيم المطلوب، والنافذة الزمنية وخط الأساس للمقارنة. أخبرني أين ينقصني تعريف أو مصدر بيانات.

ما تحصل عليه خطة لكل سؤال — metric، مصدر، شريحة، نافذة — مع إبراز الفجوات: «'churn' معرّف في metrics.md؛ لكن 'engaged account' غير معرّف — عرّفه قبل البناء. المصدر: جدول الـ subscriptions؛ يحتاج تقسيمًا حسب region». المجاهيل تظهر الآن، لا في منتصف البناء.

الـ metric غير المعرّف هو السبب الأكثر شيوعًا لإعادة العمل. إن احتاج سؤال إلى metric لا يملكه القاموس، فاحسمه في ابنِ قاموس الـ metrics الذي ترثه كل query وكل report أولًا — لا تبتكر بهدوء تعريفًا يناقض تعريف الجميع.
حدّد النطاق — واكتب ما هو خارجه

نصف إعادة العمل هو scope creep لم يسمّه أحد. صرّح بوضوح بما يدخل في الـ v1، وما هو خارج النطاق عمدًا، وأي افتراضات تتبنّاها — حتى لا يفاجئك توقّع غير معلَن عند التسليم.

أنت تطلب

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

ما تحصل عليه قائمة صريحة بما يدخل وما يخرج من النطاق إضافة إلى إبراز الافتراضات الحاملة للتأكيد: «داخل النطاق: الـ logo churn الفصلي، الـ enterprise، 4 أرباع، حسب region. خارج النطاق: الـ revenue churn، تحليل الجذور. أفترض أن 'enterprise' = وسم الشريحة في الـ CRM — أكّد ذلك». التخمينات الخاطئة المكلفة تُمسَك قبل أن تكلّف أي شيء.
اجمع الملخّص في صفحة واحدة واتّفق عليه قبل أن تكتب الـ query

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

أنت تطلب

اجمعه في ملخّص تحليلي من صفحة واحدة: القرار، والجمهور والموعد النهائي، والأسئلة المرتّبة، والـ metrics والمصادر لكلٍّ منها، وقائمة ما يدخل وما يخرج من النطاق، والافتراضات للتأكيد. أبقِه في صفحة واحدة. اكتبه بحيث ألصقه للطالب وأحصل على موافقة سريعة أو تعديل قبل أن أبدأ.

ما تحصل عليه ملخّص من صفحة واحدة جاهز للّصق ترسله للحصول على الموافقة. حالما يردّون «نعم» (أو «في الواقع، أضِف X أيضًا»)، تبني بثقة — وإن تغيّر لاحقًا، تشير إلى النطاق المتّفق عليه بدل امتصاص التغيير بصمت.

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

اجعله ملكك

مباشرة إلى الـ query: حالما يُتّفق على الملخّص، سلّمه إلى اكتب الـ query وتعلّم الـ SQL — فالأسئلة الدقيقة والـ metrics المرتبطة هي بالضبط مدخلاته، لتتجاوز خطوة 'ماذا تقصد فعلًا' بالكامل.
طلب متكرّر يصير قالبًا: إن وصل النوع نفسه من الطلب كثيرًا («الأرقام الشهرية»، «نظرة على الـ churn»)، احفظ الملخّص كقالب قابل لإعادة الاستخدام أو كـ /brief command (انظر تبويب Features) حتى يستغرق تحديد نطاق التالي خمس دقائق.
أصحاب مصلحة ثنائيو اللغة: إن كان الطالب يعمل بالعربية، فاكتب الملخّص بالعربية حتى يكون النطاق واضحًا له بلا لبس — وضوح الاتفاق أهم من اللغة التي صُغته بها أنت شخصيًا.
إنه dashboard، لا طلب لمرة واحدة: إن كان القرار متكرّرًا («أحتاج إلى مراقبة هذا»)، فيصير الملخّص هو المواصفة لعرض دائم — احمله إلى ابنِ تقرير تحليل متكرّر بدل أن تجيب مرة وتُسأل ثانية الشهر القادم.

انتبه إلى

الملخّص اتفاق، لا بيروقراطية. العشرون دقيقة ليست عملية لذاتها — إنها أرخص نقطة مراجعة ممكنة، وتجاوزها هو ما يحوّل تحليلًا من نصف يوم إلى ثلاثة أيام. إن لم يتفاعل الطالب مع صفحة واحدة، فذلك بحدّ ذاته يخبرك أن الطلب لم يكن حقيقيًا بعد.
لا تدع Claude يبتكر القرار. يستطيع أن يقترح ما يريده الطالب على الأرجح، لكن الطالب وحده من يستطيع تأكيد القرار الفعلي — عامِل قراءة الخطوة الأولى كفرضية تتحقّق منها معهم، لا كحقيقة تبني عليها.
metric غير معرّف في الملخّص هو إعادة عمل قادمة لا محالة. إن اعتمد سؤال على metric لا يملكه قاموسك، فحلّ التعريف عائق، لا تفصيل — احسمه قبل أن تكتب الـ query، لا بعد أن يشكّك صاحب المصلحة في الرقم.
النطاق المكتوب هو نطاق تستطيع الدفاع عنه؛ والنطاق في رأسك هو نطاق يتسلّل ويتمدّد. قائمة ما هو خارج النطاق هي أثمن سطر في الملخّص — إنها ما يتيح لك قول 'هذا للـ v2' بدل إعادة البناء بصمت.

ستحصل في النهاية على ملخّص تحليلي من صفحة واحدة — القرار، والأسئلة المرتّبة، والـ metrics والمصادر بالضبط، ونطاق صريح — متّفق عليه مع الطالب قبل أن تكتب الـ query، لتبني التحليل الصحيح مرة واحدة ويكون لديك عقد موثّق إن انحرف الطلب لاحقًا.

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

أليست كتابة ملخّص أبطأ من مجرّد سحب الأرقام؟: إنها أسرع من البداية إلى النهاية، في كل مرة تقريبًا. العشرون دقيقة المنفقة في تحديد النطاق هي ما يمنع اليومين من إعادة العمل حين تصل «هذا ليس ما قصدته» عند التسليم. الملخّص يقدّم الخلاف إلى وقت يكون فيه حلّه رخيصًا — ردّ من سطرين — بدلًا من بعد أن تكون قد بنيت الشيء الخطأ. الحالة الوحيدة التي يفوز فيها التجاوز هي طلب تافه فعلًا وواضح لا لبس فيه.
ماذا لو لم يكن الطالب يعرف فعلًا ما يريده؟: تلك هي الحالة الأكثر قيمة لهذا الـ playbook، لا الاستثناء. الأسئلة التوضيحية في الخطوة الأولى مصمَّمة لمساعدة الطالب على اكتشاف قراره — «هل تموّل حملة retention أم تبلّغ مجلس الإدارة؟» تجبر الهدف على التبلور. وإن ظلّ عاجزًا عن قول ما سيفعله بالإجابة، فتلك نتيجة بحدّ ذاتها: الطلب ليس جاهزًا للبناء بعد، والملخّص قد أنقذك للتو من التخمين.
كيف يختلف هذا عن playbook قاموس الـ metrics؟: قاموس الـ metrics يعرّف ما *تعنيه* الـ metrics مرة واحدة، للفريق كله. أما الملخّص التحليلي فيحدّد نطاق طلب واحد — أيًّا من تلك الـ metrics يحتاجه، ولأي شريحة، ولخدمة أي قرار. الملخّص *يستشهد* بالقاموس؛ لا يعيد تعريف الـ metrics. وإن احتاج ملخّص إلى metric لا يملكه القاموس، فتلك إشارة للذهاب وتعريفه هناك أولًا، لا لابتكار تعريف لمرة واحدة هنا.
هل أرسل الملخّص إلى صاحب المصلحة أم أحتفظ به لنفسي؟: أرسله — فذلك بيت القصيد. ملخّص تحتفظ به لنفسك مجرّد ملاحظات؛ أما ملخّص يوافق عليه الطالب فهو عقد خفيف. موافقته السريعة («نعم» أو «أضِف X أيضًا») هي ما يتيح لك البناء بثقة وما يحوّل «هذا ليس ما طلبته» لاحقًا إلى محادثة حول نطاق متّفق عليه بدل إعادة بناء غير مدفوعة.