مقاييس هندسية بدون Jira
لا تحتاج إلى Jira لقياس ما يهم. إليك كيفية تتبع الصحة الهندسية من Git وCI والأدوات التي يستخدمها فريقك بالفعل.
By Chris Calo · 2026-03-23
الفرق الصغيرة التي تحصل على أفضل وضوح هندسي غالباً هي تلك التي توقفت عن مطاردة المقاييس التي تريد Jira منها تتبّعها.
أعرف أن هذا يبدو كأنه معارضة لمجرد المعارضة، وبصراحة ربما فيه شيء من ذلك – لكنني قضيت ما يقارب ثلاث سنوات وأنا أحافظ بإخلاص على لوحات السبرنت، وأرتّب قوائم المهام المتراكمة، وأحدّث تقديرات التذاكر التي كان العمل عليها قد وصل لمنتصف الطريق قبل أن يفتح أحد Jira ذلك الصباح. كل أسبوعين، كنا نجلس في غرفة واحدة (حسناً، على Zoom – كان ذلك في 2023) ونحدّق في مخطط velocity لا يخبرنا بأي شيء لا نعرفه أصلاً من حديثنا مع بعضنا. المقاييس الهندسية بدون Jira لم تكن شيئاً بحثت عنه. هي ما حدث عندما توقفت عن التظاهر بأن مخططات velocity تخبرني بشيء مفيد.
إذا كان فريقك صغيراً بما يكفي ليجلس حول طاولة واحدة، فغالباً لا تحتاج Jira لتعرف كيف تسير الأمور. ما تحتاجه هو إشارات أفضل من الأدوات التي تستخدمها بالفعل.
هذا ليس مقالاً من نوع "Jira سيئة". Jira أداة جيدة للمؤسسات التي تحتاج تتبعاً على شكل Jira (وعند حجم معيّن، تحتاج ذلك فعلاً). لكن إذا كنت مديراً هندسياً في شركة ناشئة فيها من 10 إلى 40 شخصاً، فالدفع مقابل Jira فقط لإنتاج مخططات velocity يشبه شراء فرن صناعي لإعادة تسخين غدائك.
"الدفع مقابل Jira فقط لإنتاج مخططات velocity يشبه شراء فرن صناعي لإعادة تسخين غدائك." – Chris Calo
ما الذي تقيسه مقاييس Jira فعلاً
دعني أكون مباشراً: معظم مقاييس Jira تقيس استخدام Jira، لا الناتج الهندسي. نقاط القصة تقيس قدرة الفريق على تقدير نقاط القصة. velocity تقيس مدى ثبات الفريق في ملء السبرنتات إلى سعة متقاربة. ومخططات burndown تقيس ما إذا كان أحدهم تذكر سحب التذاكر عبر اللوحة عصر الخميس.
ليست هذه المقاييس بلا فائدة تماماً. لكنها مقاييس عملية متنكرة في هيئة مقاييس إنتاجية المطورين، والفجوة بين الاثنين هي المكان الذي يفقد فيه المديرون الهندسيون التركيز.
كنت المدير الهندسي الذي يقضي قرابة ساعة قبل اجتماع أصحاب المصلحة في تهذيب بيانات Jira داخل عرض شرائح يقول "نحن على المسار الصحيح". يهز صاحب المصلحة رأسه، ويسأل سؤالاً واحداً عن خلل تسجيل الدخول من الثلاثاء الماضي، ثم ينتهي الاجتماع. الساعة ذهبت للعرض. أما الإجابة الحقيقية فكانت "اسأل المهندس".
إذا كانت مقاييسك تحتاج صيانة أكثر من العمل الذي تقيسه، فالمشكلة في المقاييس.
زمن الدورة من Git لا من لوحات التذاكر
بالنسبة لفرق المنتج الصغيرة، يكون زمن الدورة غالباً أعلى مقياس من حيث الإشارة يمكنك تتبّعه. هو يقيس المدة من أول commit حتى النشر للإنتاج، ويمكنك اشتقاقه بالكامل من سجل Git وخط CI لديك – من دون أي لوحة تذاكر.
المكوّنات:
- الطابع الزمني لأول commit على branch أو PR
- الطابع الزمني لدمج PR
- الطابع الزمني للنشر (من CI/CD لديك – GitHub Actions أو CircleCI أو غيره)
الفارق بين 1 و3 هو زمن الدورة. قسّمه إلى مراحل – وقت البرمجة (من 1 حتى فتح PR)، ووقت المراجعة (من فتح PR حتى الدمج)، وطابور النشر (من الدمج حتى الإنتاج) – وستحصل على تشخيص يخبرك أين يتعطل العمل فعلاً.
عندما فعلت ذلك لأول مرة لفريقنا، كانت الأرقام مفاجئة فعلاً. كنت أفترض أن وقت المراجعة هو عنق الزجاجة لدينا (الجميع يفترض ذلك دائماً، أليس كذلك؟). اتضح أن مرحلة البرمجة حتى PR كانت جيدة، والمراجعات كانت جيدة، وكنا نخسر في المتوسط قرابة يومين بين الدمج والنشر لأن بيئة staging كانت غير مستقرة ولم يكن أحد قد أعطى إصلاحها أولوية. مخطط velocity لم يكن ليكشف هذا أبداً.
كيف تقيسه
إذا كنت على GitHub، يمكنك سحب ذلك عبر CLI:
```bash
اجلب PRs المدمجة خلال آخر 30 يوماً
gh pr list --state merged --limit 50 --json number,createdAt,mergedAt,headRefName ```
أما الطوابع الزمنية للنشر، فمعظم أنظمة CI تكشفها عبر API أو webhook. اربط SHAs الخاصة بدمج PR مع أحداث النشر، وستحصل على زمن دورة مقسّم حسب المرحلة.
نصيحة: إذا لم يكشف CI لديك طوابع زمنية للنشر بشكل نظيف، فحل بسيط جداً هو بوت Slack ينشر في قناة #deploys مع commit SHA. ستحصل على طوابع زمنية، وسجل سهل القراءة، وكأثر جانبي – قناة تخبرك كم مرة تشحن.
إنتاجية مراجعة الكود
إنتاجية المراجعة – عدد PRs التي يراجعها كل مهندس أسبوعياً، والوقت الوسيط من فتح PR حتى أول مراجعة – تخبرك عن صحة الفريق أكثر من أي مقياس سبرنت. وهي أقل تقديراً مما تستحق.
لماذا؟ لأن سلوك المراجعة مؤشر مبكر. عندما يبدأ وقت المراجعة بالارتفاع، فهذا يعني عادة أن المهندسين تحت ضغط زائد، أو يقومون بـتبديل السياق بشكل مفرط، أو (وهذا الجزء غير المريح) يتجنبون كود بعضهم. أي من هذه الحالات تستحق أن تعرفها قبل أن تظهر كموعد نهائي فائت بعد أسبوعين.
GitHub يعطيك هذه البيانات عبر API. الحقول الأساسية هي createdAt في PR وsubmittedAt في أول حدث مراجعة.
الرقم الذي أراقبه هو العدد الوسيط لساعات الوصول إلى أول مراجعة. وفق تجربتنا عبر عدة فرق صغيرة، الإيقاع الصحي للمراجعة يكون غالباً تحت 8 ساعات تقريباً. عندما يتجاوز يوماً كاملاً بشكل ثابت، فهذا يعني أن شيئاً بنيوياً تغيّر – وأياً كان هذا الشيء، فهو غير مرئي في Jira.
نسبة الاجتماعات إلى القرارات
هذا ليس مقياساً هندسياً تقليدياً، ويجب أن أكون واضحاً: هو مؤشر تقريبي، وليس KPI. لكن بالنسبة للفرق الصغيرة، وجدته كاشفاً بشكل مفاجئ.
احسب اجتماعات فريقك هذا الأسبوع. ثم احسب القرارات الفعلية التي خرجت منها (ليس "يجب أن ننظر في X" – بل قرارات حقيقية لها مالكون وخطوات تالية). اقسم الثاني على الأول.
إذا كانت أقل من نصف الاجتماعات تنتج قراراً، فمن المفيد أن تسأل: هل هذه الاجتماعات تستحق وقتها؟ بعض الاجتماعات موجودة لتقليل المخاطر أو مشاركة السياق، وهذا مشروع – ليس كل شيء يجب أن ينتهي بحسم. لكن عندما تبدأ بتتبّع هذا حتى بشكل غير رسمي (أنا حرفياً كنت أضع عداداً في دفتري)، تتكوّن لديك حساسية تجاه الاجتماعات المنتجة وتلك التي أصبحت مجرد طقوس لم يشكك فيها أحد.
تتبّعت هذا لشهر تقريباً، وغيّر طريقة جدولتي للاجتماعات أكثر من أي مقال إنتاجية قرأته. عندما ترى أن اجتماع المتابعة يوم الاثنين أنتج صفر قرارات بالضبط لثلاثة أسابيع متتالية، يصبح إلغاؤه أقل راديكالية.
بناء مقاييس هندسية بدون Jira: لوحة خفيفة
لا تحتاج أداة BI لهذا. صفحة في Notion، أو Google Sheet، أو منشور أسبوعي في Slack بأربعة أرقام يكفي:
- الوسيط لزمن الدورة (من Git وCI) – هل نشحن أسرع أم أبطأ؟
- الوسيط للوقت حتى أول مراجعة (من GitHub) – هل يراجع الفريق بسرعة مناسبة؟
- تكرار النشر (من CI أو قناة #deploys) – كم مرة نشحن؟
- نسبة الاجتماعات إلى القرارات (تسجيل يدوي) – هل اجتماعاتنا تستحق وقتها؟
أربعة أرقام، كلها قابلة للاشتقاق من أدوات لديك أصلاً، ولا واحد منها يحتاج صيانة لوحة Jira. حدّثها أسبوعياً. إذا تحرك رقم في الاتجاه الخاطئ لأسبوعين متتاليين، حقّق في السبب. إذا ظل ثابتاً، اتركه كما هو.
الفكرة ليست بناء نظام مراقبة (رجاءً لا تفعل ذلك – مهندسوك سيكرهونك وسيكونون محقين). وضوح الفريق الهندسي يجب أن يأتي من العمل نفسه، لا من مطالبة الناس برفع تقارير عن العمل. That’s the principle behind a single view of what the team is doing: the signals already exist in your tools, and how managers see team progress without asking for status reports is really about connecting those signals, as is task visibility across Linear, GitHub, Slack, and Notion.
أفضل المقاييس الهندسية منخفضة الكلفة في الجمع، صعبة التلاعب، وتمنحك رؤية قابلة للتنفيذ. نقاط القصة تفشل في الثلاثة.
متى تحتاج فعلاً إلى لوحة تذاكر
قلت إن هذا ليس مقال "Jira سيئة"، وأنا أقصد ذلك. توجد حالات مشروعة يصبح فيها تتبع المقاييس من دون أداة إدارة مشاريع تصرفاً غير مسؤول فعلاً:
- قطاعات عالية الامتثال حيث تكون سجلات تدقيق حالة المهام مطلوبة قانونياً
- مؤسسات هندسية أكبر حيث تجعل الاعتماديات بين الفرق التنسيق غير الرسمي غير قابل للاستمرار
- مؤسسات لديها وظائف إدارة مشاريع مخصصة وتحتاج مصدر حقيقة موحّداً عبر الفرق
إذا كانت هذه حالتك، فاختيار Jira (أو Linear أو Shortcut) هو القرار الصحيح. ما أجادل به هو أنه بالنسبة للفرق الصغيرة، الإبقاء على أداة ثقيلة فقط من أجل المقاييس صفقة سيئة. ستجد نفسك تحسّن لأجل نموذج الأداة في العمل بدل عمل فريقك الحقيقي.
وبصراحة؟ حتى الفرق التي تستخدم Jira ستستفيد من إضافة المقاييس المستخرجة من Git أعلاه إلى بيانات لوحاتها. Jira تخبرك بما يقول الناس إنهم يفعلونه. Git يخبرك بما يفعلونه فعلاً. الاثنان مفيدان، لكن واحداً فقط محصّن ضد مسرح تحديث الحالة.
إذا ظل سؤال المقاييس يتكرر في شركتك الناشئة، جرّب لوحة الأرقام الأربعة لمدة شهر. قد تبدو المقاييس الهندسية بدون Jira كأنك تعمل بدون شبكة أمان – لكن عندما ترى كم إشارة موجودة في سجل Git وخط CI لديك، ستتساءل عمّا كانت تضيفه لوحة التذاكر أساساً.
اعرض زمن الدورة، وPRs المتوقفة، واختناقات المراجعة تلقائياً – من دون سكربتات مخصصة أو لوحة Jira.
س: هل يمكن الحصول على مقاييس هندسية مفيدة بدون أداة إدارة مشاريع؟ ج: نعم. زمن الدورة (من أول commit حتى النشر)، وإنتاجية المراجعة، وتكرار النشر كلها موجودة في سجل Git وخط CI لديك. للفرق التي يقل حجمها عن 40 مهندساً، تميل هذه إلى أن تكون أدق وأصعب في التلاعب من أي شيء تنتجه لوحة تذاكر – ولا تتطلب من أحد سحب البطاقات عبر لوحة حتى تبقى دقيقة.
س: هل يعرض Sugarbug المقاييس الهندسية تلقائياً؟ ج: يتصل Sugarbug بـ GitHub وLinear وSlack والتقويمات لبناء رسم بياني معرفي لنشاط فريقك. يحدد أنماطاً مثل PRs المتوقفة، واختناقات المراجعة، والقرارات التي ظلت بلا حل – وهذا يغطي كثيراً من الإشارات المذكورة هنا دون أن تحتاج إلى كتابة وصيانة سكربتات مخصصة على GitHub API.
س: كيف أحصل على موافقة الفريق للتوقف عن استخدام Jira للمقاييس؟ ج: قدّمها كتجربة لا كتمرد. شغّل المقاييس المستخرجة من Git بالتوازي مع لوحات Jira الحالية لمدة أربعة أسابيع، ثم قارن أي الأرقام دفع إلى تغييرات فعلية. إذا أثبتت مقاييس Git أنها أكثر قابلية للتنفيذ (وفي تجربتنا غالباً يحدث هذا)، فالحجة ستثبت نفسها.
س: ما الفرق بين مقاييس العملية ومقاييس الأداء؟ ج: مقاييس العملية (نقاط القصة، السرعة، مخططات التوقف) تقيس مدى ثبات التزام الفريق بسير العمل. مقاييس الأداء (زمن الدورة، تكرار النشر، إنتاجية المراجعة) تقيس ما يشحنه الفريق فعلياً وبأي سرعة. الفرق الصغيرة تحصل دائماً تقريباً على إشارة أكبر من النوع الثاني، لأن مقاييس الأداء تُشتق من العمل نفسه لا من تحديثات الحالة اليدوية.