ازاي تقيس انتاجيتك وكفائتك في الشغل حتى لو شركتك/الفريق/مديرك مش مهتمين انهم يوضحوا ده أو مش مهتمين يعرفوا؟ الأرقام اللي من نوع "كام ticket خلصتها في أسبوع" وغيرها من الأرقام المشتقة من مبادئ الـagile بيتم استخدامها بشكل غلط طيب ازاي أحدد انا باشتغل صح وبشكل فعال ولا لأ؟

في البداية محتاجين نوضح انه مش من الصح اننا نقيس كفاءة وإنتاجية الفرد لوحده وبغض النظر عن الفريق بشكل كامل، علشان فيه عوامل كتير هتخلي الموضوع مش دقيق أو مفيد وكمان هيكون بيشجع على شوية عادات سيئة بين الفريق وبعضه .. اللي هاكتبه هنا المفروض يتقاس على مستوى التيم ككل وليس كأفراد ..

نفترض انك شغال على application بيستخدمه آلاف المستخدمين كل يوم ومطلوب منكم كل فترة تنزلوا نسخ جديدة فيها تعديلات، ومتوقع منكم كل أسبوع تكون عندكم أهداف تشتغلوا عليها .. كل أسبوع أنت بتخلص تاسكات كتير، أكتر وأسرع واحد .. بس ممكن تكون أقل واحد فيهم كفاءة، ليه؟

لو هنقول انك خلصت ٣ حاجات جديدة الأسبوع ده ونزل تحديث للـapp وهما موجودين فيه .. ٢ منهم طلع فيهم مشاكل واضطرينا نرجع النسخة القديمة وبعدها قعدت أسبوع كمان لحد ما صلحت المشاكل ونزلوا تاني، بس زميلك خلص حاجة واحدة بس ونزلت للمستخدمين بدون مشاكل تمامًا .. مين تأثيره أحسن؟

الموضوع مش مجرد انك اخدت اسبوعين في ٣ حاجات وهو أسبوع في حاجة واحدة بافتراض نفس الصعوبة او المجهود، ولكن التأثير السلبي على الـapp وانه يظهر للمستخدمين مشاكل تشككهم في المنتج أو تخلي فرق زي الدعم الفني تعيش أوقات صعبة وترد على الشكاوي .. فا زميلك هو أفيد للشركة عمومًا ..

هنتكلم على كام حاجة النهاردة:

١- جودة الشغل اللي بيطلع منك - Escaped Defects Rate:

مش مهم كمية الشغل، بس المهم فيه كام issue بترجع على شغلك، وكل ما تطلع مشكلة على production environment كل ما السكور بتاعك هيقل .. مفيش مدير هيبقى عاوز شخص يخليه يحط ايده على قلبه كل مرة يسلّم شغل

٢- وقت تنفيذ الشغل اللي معاك - Task Cycle Time:

كل ما الوقت يقل في التنفيذ كل ما ده معناه انك قسمت الشغل كويس لحاجات صغيرة واضحة وعارف هتعمل فيها ايه، وكل ما الوقت يكبر كل ما هتلاقي ان الموضوع بيوسع والجبهات بتزيد واللي هيعملك review هيعاني انه يراجع ويفهم ..

٣- الوقت من بداية التنفيذ الى الوصول للمستخدمين - Time to Deliver:

عارف انت لما بنقول احنا خلصنا بس ناقص كذا؟ هنا الرقم المهم بيكون المدة اللي بتاخدها الـtask من أول ما تبدأ شغل فيها لحد ما توصل للمستخدم، عوامل التأخير ممكن تكون سيناريو انت نسيته او مشكلة ماعملتش حسابها وهكذا

٤- تقدير وقت التنفيذ - Task Estimation:

عارفين ان احنا مش أشطر ناس بتعرف تحسب هتخلص امتى لأسباب كتير، بس للأسف الموضوع ده مهم علشان فيه ناس تانية بتحضر لشغلها بعدها زي حملات اعلانية وكده، الطبيعي انه يكون فيه نسبة خطأ معينة بس ماينفعش انك تقدّر task انها أسبوع وتخلص في ٣ ..

٥- تسليم الشغل بطريقة واضحة - Task Deliverables:

راجع كده الشغل اللي سلمته اخر ٣ شهور، فيه كام مشروع او تاسك أنت بس اللي عارف عملتهم ازاي وملهمش documentation ولا diagram ولو انت مشيت بكرا الناس هتتعب بعدك؟ لو الرقم عالي ده يبقى معناه انك محتاج تراجع النقطة دي كويس

٦- القدرة على قياس ومتابعة الشغل - Task Observability and Monitoring:

نفس التلات شهور، هل تقدر تقول هل المشاريع اللي اشتغلت عليها بتوفر تجربة سريعة للمستخدم؟ تقدر تعرف بترد في كام ثانية او مللي ثانية في المتوسط؟ طيب لو فيه جزء حصل فيه مشكلة هل هتعرف لوحدك ولا الناس هتشتكي؟

٧- الشغل في مرحلة التنفيذ - Work in Progress Rate:

مش حاجة حلوة انك تكون شغال في ٥ حاجات في نفس الوقت، ده اسمه وهم الإنتاجية، لأنك هتخلص الخمسة في وقت طويل جدًا ويمكن بكواليتي ضعيفة .. كل ما الحاجات اللي in progress تزيد كل ما ده معناه انك مش بتعرف (تقفّل) شغلك صح أو تخطط بوضوح

٨- نسبة إعادة الشغل - Rework Rate:

أي كود بتكتبه وبتعدل فيه بعنف خلال شهر من بعد ما كتبته ده يبقى مؤشر خطير، لأنه معناه انك يا اما كنت فاهم المتطلبات غلط أو مش مركز أو لما حد راجع على شغلك قالك على أخطاء كبيرة .. غالبًا الناتج النهائي هيبقى سيئ وهيحتاج يتعاد كله بعد فترة

فيه معايير تانية كتير، وفيه جزء تاني هنتكلم فيه على metrics لها علاقة بسرعة حل المشاكل وتحديدها زي MTTD and MTTR ومثلاً SLOs مرة كمان حابب أقول انه كل اللي فات بيتحسبوا على مستوى الفريق ككل، بس بتبقى خطوة كويسة انك تاخد الموضوع كتحدي شخصي انك تراقب جودة شغلك وتطورك .. شكرًا

أتمنى يكون الكلام مفيد وشكرًا انك وصلت لحد هنا - تفاصيل أكتر ممكن تلاقيها على تويتر هنا.