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

playbook

ابنِ تقرير تحليل متكرّرًا، من البداية إلى النهاية

حلّل البيانات، واكتب الـ queries واشرحها، وراجع كل نتيجة، وارسم العروض الأساسية، ولُفّها في سردٍ بلغة واضحة مع تحفّظات — تقرير تعيد تشغيله بالطريقة نفسها كل شهر فتتراكم المقارنات.

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

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

يحتاج أحدهم الأرقام الشهرية — مراجعة الـ metrics، تحديث مجلس الإدارة، الـ ops dashboard — وهو الآن جلبة من نصف يوم من queries هشّة وعرض تعيد بناءه من الصفر كل مرة، باختلاف طفيف، فلا تقارَن أرقام هذا الشهر حتى بأرقام الشهر الماضي. هذا هو الـ capstone: يضمّ بقية Data playbooks في pipeline واحد قابل للتكرار — profile، query، مراجعة، chart، سرد — حتى يخرج التقرير بالطريقة نفسها كل شهر. المكافأة ليست فقط توفير نصف اليوم؛ بل أنه لأن المنهج ثابت، صارت مقارنات الشهر-عن-شهر جديرةً بالثقة أخيرًا.

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

  • البيانات المصدر كملفات أو table — events.csv، sales.csv، customers.csv — ونسخة الشهر الماضي من هذا التقرير، حتى تبني للمقارنة من البداية.
  • القائمة المثبّتة بالـ metrics التي يجب أن يحملها التقرير وكيف يُعرَّف كلٌّ منها بالضبط (ماذا يعني 'active'، وأين تقع حدود الشهر) — لا يجوز أن تنحرف التعريفات بين الأشهر وإلا فالمقارنة بلا معنى.
  • إجماليات معروفة لتراجع عليها — أرقام الشهر الماضي، عدد صفوف، رقم من المالية — والجمهور والصيغة (صفحة تنفيذية واحدة تُقرأ على نحو مختلف تمامًا عن ملحق محلّل).

الـ workflow

  1. حلّل كل مصدر بالطريقة نفسها (استجوب الـ dataset قبل أن تلمسه)

    ابدأ بتشغيل playbook الـ profiling على كل مُدخَل حتى تعرف أن ملفات هذا الشهر بنفس شكل ملفات الشهر الماضي. تغييرٌ صامت — column فارغ جديد، مدى تواريخ منزاح — هو ما يجعل تقريرَي شهرين غير قابلين للمقارنة سرًّا.

    أنت تطلب 
    اعمل profile لكل مصدر في تقرير هذا الشهر — events.csv وsales.csv وcustomers.csv — تمامًا كاستجواب dataset: عدد الصفوف، ومعاني الـ columns، والمدى الزمني، والقيم الفارغة، والمكرّرات. ثم قارن كلًّا منها بملف الشهر الماضي ونبّهني على أي شيء تغيّر: column جديد، أو قفزة في القيم الفارغة، أو صيغة تاريخ مختلفة. لا تحسب أي metrics بعد.

    ما تحصل عليه profile لكل ملف إضافة إلى تقرير تغييرات: «events.csv هذا الشهر 1.1M صف مقابل 980K الشهر الماضي؛ column جديد experiment_id؛ معدّل القيم الفارغة على region مستقرّ. sales.csv بلا تغيير». تصطاد تغييرًا في الـ schema قبل أن يكسر المقارنة بهدوء.

    فحص 'هل البيانات بنفس شكل المرة الماضية' هذا هو ما يجعل أرقام الشهر-عن-شهر قابلة للمقارنة. تخطَّه وتكون تقارن شيئين مختلفين قليلًا وتسمّيه اتجاهًا.

  2. اكتب واشرح query كل metric (اكتب الـ query وتعلّم الـ SQL)

    ابنِ كل metric كـ query مشروح وقابل لإعادة الاستخدام — مثبّت على التعريفات المتّفق عليها — حتى يحسب التقرير الشيء *نفسه* كل شهر وتستطيع الدفاع عن كل رقم حين يُسأل عنه.

    أنت تطلب 
    لكل metric في القائمة المثبّتة — المستخدمون النشطون حسب الـ plan، والإيرادات حسب الـ region، والعملاء الجدد مقابل العائدين — اكتب الـ query، واشرح لي كل clause بلغة واضحة، واستخدم التعريفات الدقيقة التي اتفقنا عليها (active = login داخل الشهر، حدود الأشهر بتوقيت UTC). احفظ كلًّا منها كملف .sql مُسمّى ومعلَّق عليه كي يعيد الشهر القادم تشغيل المنطق نفسه تمامًا.

    ما تحصل عليه ملف .sql معلَّق عليه لكل metric إضافة إلى شرح لكلٍّ منها، كلها مثبّتة على التعريفات نفسها — active-users.sql، revenue-by-region.sql — حتى يُحسب التقرير على نحو متطابق كل شهر، لا ارتجالًا.

  3. راجع كل نتيجة وحلّ المفاجآت (اكتشف لماذا تحرّك الرقم)

    اربط كل metric بإجمالي معروف، ثم لأي شيء تحرّك على نحو ذي معنى، شغّل انضباط السبب الجذري — baseline، استبعاد artifact في البيانات، تفصيل حسب الـ dimension — حتى يشرح السرد تغييرات حقيقية، لا bugs في الـ queries.

    أنت تطلب 
    راجِع كل metric مقابل الشهر الماضي ومقابل أعداد الصفوف الخام — هل تتوافق الإجماليات؟ ولأي metric تحرّك أكثر من 10%، قبل أن نُبلغ عنه: استبعد artifact في البيانات (أيام مفقودة، تغيير في الـ tracking)، ثم فصّله حسب الـ dimension الصحيح لتجد ما الذي تحرّك فعلًا. أخبرني أي التغييرات حقيقية وأيها مجرد شذوذ في البيانات.

    ما تحصل عليه جدول مراجعة («المستخدمون النشطون 14,210، يتوافق مع العدّ الخام؛ الإيرادات +18% شهرًا عن شهر») و، لكل متحرّك كبير، سببٌ مُتحقَّق منه: «قفزة الإيرادات حقيقية، بقيادة region الغرب؛ 'ارتفاع' الـ churn artifact في البيانات — ملف الشهر الماضي كان ينقصه يومان». التغييرات الحقيقية مفصولة عن الضجيج.

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

  4. ارسم العروض الأساسية (من CSV خام إلى chart تلصقه في شريحة)

    ارسم الحفنة من العروض التي تحمل القصة كملفات صور مُسمّاة، مستخدمًا اختيارات الـ charts نفسها كالشهر الماضي حتى تكون المرئيّات قابلة للمقارنة بلمحة — وتحقّق من أرقام كل chart مقابل الجداول المُراجَعة.

    أنت تطلب 
    ارسم العروض الأساسية كـ PNGs بدقّة شريحة، مطابقًا أنواع charts الشهر الماضي تمامًا: line للإيرادات-حسب-الشهر، وbars للمستخدمين-النشطين-حسب-الـ plan، وline لنمو MoM. عنون وسمِّ كلًّا منها بالوحدات، وأكّد أن أرقام كل chart تطابق الجداول المُراجَعة قبل الحفظ. ثم اجمعها في report-dashboard.png واحد بعنوان رئيسي يحمل الخلاصة.

    ما تحصل عليه مجموعة متّسقة من PNGs مُسمّاة وملف report-dashboard.png يبدو كالشهر الماضي حتى يستطيع القارئ المقارنة فورًا — أرقام كل chart مؤكَّدة أصلًا مقابل النتائج المُراجَعة، لا مُعاد رسمها من الصفر.

  5. لُفّه في سرد مع تحفّظات — واحفظ الـ runbook

    حوّل الأرقام والـ charts المُراجَعة إلى قصة بلغة واضحة يقرؤها مسؤول تنفيذي في دقيقتين، مع قسم تحفّظات صريح — ثم التقط الـ pipeline بأكمله كـ runbook (أو command) حتى يكون الشهر القادم إعادة تشغيل، لا إعادة بناء.

    أنت تطلب 
    اكتب التقرير كسرد بلغة واضحة للمسؤولين التنفيذيين: الخلاصات الثلاث الرئيسية، وما الذي تحرّك والسبب المُتحقَّق منه، وقسم صادق بعنوان 'تحفّظات وحدود البيانات' (artifact الـ churn، والأيام المفقودة، وأي شيء استبعدناه). ثم اكتب runbook يسرد كل خطوة وملف وquery كي أتمكّن — أو أي أحد — من إعادة تشغيل هذا التقرير نفسه بالضبط الشهر القادم والحصول على نتيجة قابلة للمقارنة.

    ما تحصل عليه تقرير سردي من دقيقتين («الإيرادات صعدت 18% شهرًا عن شهر، بقيادة الغرب؛ المستخدمون النشطون مستقرّون؛ ملاحظة: الـ churn مُقدَّر بأقل من حقيقته هذا الشهر بسبب فجوة بيانات») إضافة إلى ملف report-runbook.md يحوّل pipeline نصف اليوم إلى قائمة تحقّق قابلة للتكرار.

    قسم التحفّظات هو ما يجعل التقرير جديرًا بالثقة — تقرير واثق يُخفي فجوات بياناته أسوأ من تقرير يسمّيها. اذكر ما لست متيقّنًا منه.

اجعله ملكك

  • **مصدر جديد يحتاج join أولًا:** إن كان تقرير هذا الشهر يجمع ملفين (CRM + الفوترة)، شغّل *حوّل ملفين فوضويين إلى dataset واحد جدير بالثقة* قبل الخطوة 2، وغذِّ الملف المدموج المُراجَع داخل الـ queries — انضباط الـ match_status والإجماليات نفسه يُبقي المُدخَل المدموج جديرًا بالثقة.
  • **اجعله متكرّرًا فعلًا:** بمجرد استقرار الـ runbook، لُفّ الـ pipeline كـ /monthly-report custom command أو سلّمه إلى scheduled agent (انظر تبويب *Features*) يحلّل البيانات الجديدة، ويعيد تشغيل الـ queries المحفوظة، ويصوغ السرد لتراجعه أنت — محوّلًا نصف يوم إلى جولة مراجعة من 30 دقيقة.
  • **إيقاع أو جمهور مختلف:** اختصره إلى صفحة أسبوعية واحدة (profile ← أعلى 3 metrics ← مراجعة ← chart واحد ← ثلاث جمل) لاجتماع standup، أو وسّعه بملحق محلّل كامل من الـ queries المشروحة — العمود الفقري من خمس خطوات هو نفسه عند أي حجم.

انتبه إلى

  • القيمة كلها هي *القابلية للمقارنة عبر الزمن*، فالتهديد هو الانحراف الصامت — metric أُعيد تعريفه، نوع chart تغيّر، ملف جديد لم يُحلَّل. أبقِ التعريفات والمنهج ثابتين عبر الأشهر؛ وإن اضطُررت لتغيير أحدها، قل ذلك صراحةً في التحفّظات حتى يبقى خطّ الاتجاه صادقًا.
  • التقارير المتكرّرة تحمل بيانات حسّاسة بطبيعتها — الإيرادات، العملاء، عدد الموظّفين. جمّع قبل الرسم، وأبقِ الملفات الخام محلية، ولا تلصق صفوفًا تُعرّف الهوية في prompt أبدًا، واجعل إنسانًا يؤكّد الأرقام قبل توزيع التقرير.
  • يشغّل Claude الـ pipeline؛ وإنسانٌ يملك التقرير. كل رقم رئيسي يُراجَع، وكل متحرّك كبير يحصل على سبب مُتحقَّق منه، وشخصٌ يوقّع قبل أن يخرج — يأخذك Claude من ملفات خام إلى مسوّدة قابلة للدفاع عنها بسرعة، لكنه لا يزيل حُكم ما تدّعيه وما تُبرزه.

ستحصل في النهاية على تقرير شهري كامل وقابل للتكرار — مصادر مُحلَّلة، queries مشروحة ومُراجَعة، charts قابلة للمقارنة، سرد بلغة واضحة مع تحفّظات صادقة، وrunbook يتيح لك إعادة تشغيله على نحو متطابق — حتى تقارَن أرقام كل شهر بحقٍّ بأرقام الذي قبله.