إذا كان عليك قيادة تطوير منتج برمجي ، فربما تساءلت - كيف تساعد الفريق على التحرك بشكل أسرع؟ وكيف تعرف مدى سرعتك في الحركة؟
يبدو من المنطقي استخدام المقاييس للإجابة على هذه الأسئلة. بعد كل شيء ، لقد استخدمناها لفترة طويلة وبنجاح لمنتجات البرامج نفسها. هناك مقاييس الأداء ، تحميل خادم الإنتاج ، الجهوزية. هناك أيضًا مقاييس للمنتج تستند إلى سلوك المستخدم مثل التحويل والاحتفاظ. لا تقتصر فائدة المقاييس على فهم أوضح للوضع الحالي فحسب ، بل تكمن الأهم في توفير التعليقات. يمكنك إجراء تغيير لتحسين شيء ما ، ويمكنك أن ترى من خلال المقاييس مقدار التحسن (أو التدهور) الذي تحصل عليه. تقول حكمة البرمجة الشائعة: يجب أن يبدأ كل تحسين لأداء البرنامج بالقياس ، وهذا أمر منطقي للغاية.
نظرًا لأنه يمكننا تطبيق المقاييس بنجاح على منتجات البرامج نفسها ، فلماذا لا نطبقها على سرعة تطوير تلك المنتجات؟ في هذه الحالة ، يمكننا تجربة بعض التحسينات في العمليات ومعرفة ما إذا كانت تساعد في التحرك بشكل أسرع. كما سيتم تبسيط مشكلة تحديد الراتب العادل للمبرمجين. ما هي المقاييس التي يمكنك استخدامها؟
ليس لدينا مقاييس جيدة لهذا.
سرعة التطوير هي مقدار العمل المنجز لكل وحدة زمنية. يمكننا قياس الوقت ، كل شيء بسيط هنا. لكن كيف تقيس مقدار العمل المنجز؟ بدأت محاولات القيام بذلك منذ عدة عقود ، مع ولادة صناعة البرمجة نفسها. ومع ذلك ، في كل مرة يتم فيها استخدام المقياس كهدف للتحسين ، لا بد أن يحدث خطأ ما. على سبيل المثال:
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
يتمتع المطورون بالذكاء والإبداع ، وهم متخصصون في حل المشكلات المعقدة. مهما كان المقياس الذي تقدمه لهم ، سيجدون أسهل طريقة لتحسين أدائهم ، ولكن على الأرجح لن يكون له علاقة بالحجم الفعلي للعمل المنجز وجودته. هل سيستخدمون أساليب "الغش" هذه؟ ليس بالضرورة ، فهذا يعتمد على وضعك الخاص ، بما في ذلك مدى قوة الحافز الذي تخلقه. لكنهم سيدركون بالتأكيد أن تقييم إنتاجيتهم لا علاقة له بالقيمة. هذا لا يثبط العزيمة فحسب ، بل يصرف الانتباه أيضًا عن القيام بعمل حقيقي.
لكن لماذا؟
لماذا تعمل المقاييس بشكل رائع لتحسين خصائص منتجات البرامج ، ولكن ليس لقياس العمل الذي يقوم به المبرمجون؟ ربما هذا نوع من مؤامرة المبرمجين؟ في الواقع ، إذا نظرنا إلى ما هو أبعد من تطوير البرمجيات ، فإننا نرى أمثلة أخرى ، في بعضها تعمل المقاييس بشكل جيد وفي حالات أخرى لا تعمل.
أمثلة على الأماكن التي تعمل فيها المقاييس بشكل جيد هي التصنيع الشامل أو المبيعات. يجب ألا يكون هناك إنتاج وبيع أكواب. يمكنك قياس حجم الإنتاج - عدد الأكواب لكل وحدة زمنية ، وجودتها (نسبة الخردة) ، تكلفة الكوب الواحد. في المبيعات - حجم المبيعات ، الهامش. يتم استخدام هذه المقاييس بنجاح كبير في الإدارة. على سبيل المثال ، يمكن تكليف مدير الإنتاج بمهمة تقليل معدل الخردة مع الحفاظ على سعر التكلفة ، ومدير المبيعات - زيادة المبيعات مع الحفاظ على السعر. ستفيد التحسينات في هذه المقاييس الأعمال التجارية ، بحيث يمكن اعتبارها مؤشرات لأداء الأشخاص المسؤولين.
مثال على عندما لا تعمل المقاييس هو تقييم الأداء العلمي. يجري العلماء أبحاثًا تُنشر بعد ذلك كأوراق علمية. تحتوي هذه المنطقة أيضًا على مقاييسها العددية - عدد الأوراق ، عدد الاستشهادات ، الأهمية الإحصائية للنتائج ، وما إلى ذلك. هل يمكن القول أن العالم الذي أصدر 10 أوراق علمية حقق للعالم ضعف فائدة العالم الذي أصدر 5 أوراق؟ هذا غير محتمل ، لأن قيمة عملهم يمكن أن تكون مختلفة تمامًا ، وفي نفس الوقت ، حتى على المستوى الذاتي ، قد يكون من الصعب فهم العمل الأكثر قيمة. مشكلة الاستشهادات والمنشورات "الغش" معروفة على نطاق واسع في المجتمع العلمي ، لذلك ، للأسف ، لا تعتبر مؤشرات موثوقة للقيمة. هناك أيضًا مشكلة التلاعب بالدلالة الإحصائية .
معياران رئيسيان
بغض النظر عن السياق ، فإن المقاييس التي تعمل بشكل جيد تشترك في شيئين:
- علاقة مباشرة (غير مباشرة) بالقيمة ؛
- الدقة ، أي أن المقياس يعتمد على قياس عدد بعض وحدات القيمة وهذه الوحدات متساوية مع بعضها البعض ؛
دعنا ننظر مرة أخرى إلى الأمثلة التي نظرنا إليها أعلاه:
مقاييس الإنتاج الضخم والمبيعات تفي بكلا المعيارين. في إنتاج الأكواب ، القيمة هي المنتج - الأكواب نفسها. الاتصال مباشر ، تحتاج الشركة إلى إنتاج أكواب. وبما أن الإنتاج كبير ، فإن وحدات القيمة (الدوائر) تساوي بعضها البعض. إذا كنا نتحدث عن المبيعات ، فإن وحدات القيمة هي المال. الغرض من المشروع هو تحقيق ربح ، وبالتالي ، فإن العلاقة مع القيمة ، مرة أخرى ، مباشرة. وبما أن كل دولار يتم ربحه يساوي آخر ، يمكننا بناء مقاييس دقيقة.
في تقييم الأعمال العلمية ، لا يمكن تلبية هذه المعايير. لا يمكننا إيجاد وحدة قياس تحدد بشكل مباشر قيمة العمل العلمي ، لأن جميع الأعمال العلمية فريدة من نوعها. لا يمكن أن يكون الأمر خلاف ذلك ، مجرد انطلاق من جوهر العلم - لاكتشاف معرفة جديدة. ليس من المنطقي للعالم أن يكتب عملاً علميًا آخر يكرر تمامًا آخر. يجب أن يأتي كل عمل علمي بشيء جديد.
نظرًا لأنه لا يمكننا العثور على مقاييس تقيس بشكل مباشر قيمة العمل العلمي ، لم يتبق لنا سوى المقاييس غير المباشرة - على سبيل المثال ، عدد المنشورات والاستشهادات. تكمن مشكلة المقاييس غير المباشرة في أنها ترتبط ارتباطًا ضعيفًا بالقيمة وتميل إلى الغش بسهولة. إذا بدأت في استخدام مثل هذا المقياس كهدف ، فأنت نفسك تنشئ حافزًا لتلغيه بشكل مصطنع.
العودة إلى قياس إنتاجية المبرمج
ماذا لدينا هناك؟ سطور التعليمات البرمجية ، وعدد الالتزامات ، والمهام ، ودرجة المهام بالساعات ، أو نقاط القصة ... إذا حاولت التحقق من هذه المقاييس مقابل معيارين رئيسيين ، فسترى أن أيا منها لا يلبيها:
- لا توجد علاقة مباشرة بالقيمة. نحن لا نزود عملائنا بأسطر من التعليمات البرمجية أو ساعات العمل أو نقاط القصة. لا يهتم المستخدمون بعدد الالتزامات التي قمنا بها أو عدد المهام التي أغلقناها ؛
- ليست دقيقة. الالتزام بالالتزام مختلف ، سطر واحد من التعليمات البرمجية لا يساوي الآخر ، المهام مختلفة أيضًا ، ويتم تقدير ساعات العمل ونقاط القصة بشكل شخصي ، لذلك ستختلف أيضًا.
لذلك ليس من المستغرب ألا يعمل أي من هذه المقاييس - فجميعها غير مباشرة وغير دقيقة.
لماذا لا توجد مقاييس من شأنها أن ترتبط مباشرة بقيمة عمل المبرمج؟ لنفس الأسباب التي تجعل العلماء لا يمتلكونها. المبرمجون ، مثل العلماء ، يبدعون باستمرار أشياء جديدة. إنهم لا يكتبون نفس الكود بالضبط مرارًا وتكرارًا - هذا غير منطقي. يمكن إعادة استخدام التعليمات البرمجية المكتوبة سابقًا بطرق مختلفة ، أو فصلها إلى وحدة أو مكتبة منفصلة ، أو نسخها فقط ، في أسوأ الأحوال. لذلك ، كل يوم عمل للمبرمجين فريد من نوعه. حتى لو قاموا بحل مشاكل مماثلة ، فإنهم يحلونها في كل مرة في سياق مختلف ، في ظروف جديدة.
عمل المبرمجين هو إنتاج قطعة ، وليس إنتاجًا ضخمًا. لا ينتج عنها نفس النتائج القابلة للتكرار ، لذلك لا يوجد خط أساس للقياس. المقاييس التي تعمل بشكل جيد في الإنتاج الضخم أو المبيعات لا تعمل هنا.
ألا يوجد شيء أكثر حداثة يعتمد على البحث؟
بالطبع ، اليوم لا أحد يتحدث بجدية عن قياس عمل المبرمج من خلال سطور التعليمات البرمجية. يجب أن يكون هناك بعض المقاييس الحديثة المبنية على البحث ، أليس كذلك؟
هناك بعض. في كتابهم الصادر عام 2018 بعنوان "Accelerate" ، يستشهد المؤلفون بنتائج دراسة أجريت على 2000 مؤسسة من مختلف الصناعات. حاول المؤلفون معرفة المقاييس التي ستقيس الأداء:
المصدر: نيكول فورسغرين وجيز هامبل وجين كيم ، "قياس الأداء" ، في تسريع: العلم وراء DevOps: بناء وتطوير مؤسسات التكنولوجيا عالية الأداء ، فيما
يلي أربعة مقاييس. دعونا نرى أي منها يرتبط بالقيمة ويمكن قياسه بدقة:
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
الخلاصة: لا يوجد أي من هذه المقاييس الأربعة دقيق ، وليس لديهم دائمًا علاقة واضحة بقيمة العميل. هل هناك فرصة "للغش" في هذه الحالة؟ بالتأكيد. قدم تغييرات تافهة منخفضة المخاطر قدر الإمكان ، وستبدو جميع المقاييس ، باستثناء مهلة الانتظار ، رائعة.
بالنسبة إلى المهلة الزمنية - حتى لو أهملنا الحقيقة (المهمة) بأنها غير دقيقة ، فإن التركيز عليها سيؤدي إلى تحديد أولويات أبسط رغبات العميل والدفع إلى الزاوية البعيدة لكل شيء لم يطلبه العميل بوضوح - عادةً ما تكون هذه عمليات إعادة بناء واختبارات و فقط أي تحسينات لم يفكر بها في نفسه.
لذلك ، لا أوصي باستخدام هذه المقاييس كأهداف.
لكن ربما سنجد مقاييس جديدة؟
بالطبع ، يمكنك أن تقول: "انتظر ، إذا لم يتم العثور على مقاييس مناسبة حتى الآن ، فهذا لا يعني أنه لا يمكن وجود أي مقاييس على الإطلاق! نحن أناس أذكياء ، سنجهد أنفسنا ونفكر في شيء ما ". للأسف ، أخشى أنه لن يحدث. هناك سبب أساسي لعدم وجود مقاييس جيدة في هذا المجال. كما قلنا أعلاه ، فإن الأشياء الجيدة تفي بمعيارين رئيسيين:
- علاقة مباشرة (غير مباشرة) بالقيمة ؛
- الدقة ، أي أن المقياس يعتمد على قياس عدد بعض وحدات القيمة ، وهذه الوحدات متساوية مع بعضها البعض.
لا يمكننا قياس القيمة المباشرة بدقة ، لأن جميع نتائج عمل المبرمجين مختلفة ، فهم لا ينتجون أي شيء متماثل تمامًا. هذا إنتاج قطعة لمهام فريدة غير متكررة. وبما أنه لا يوجد شيء متكرر ، فلا يوجد أساس للمقارنة والقياس أيضًا. لم يتبق لنا سوى وكلاء ، ولكن نظرًا لسوء ارتباطهم بالقيمة وعرضة للغش ، فإن الاعتماد عليهم ضار.
هل يمكنك تحسين المناطق التي لا توجد بها مقاييس جيدة؟
المقاييس رائعة لأنها تقدم ملاحظات. يمكنك إجراء بعض التغييرات في العملية ويمكنك أن ترى بوضوح ما إذا كانت أدت إلى تحسينات أم لا. إذا لم تكن هناك مقاييس ، فستصبح التعليقات أقل وضوحًا وقد تشعر أنك تتحرك بشكل أعمى. هناك مقولة شهيرة منسوبة لبيتر دراكر:
لا يمكنك التحكم في ما لا يمكنك قياسه.
فقط هذا ليس صحيحا. وفقًا لمعهد دراكر ، لم يكن بيتر دراكر في الحقيقة متوهمًا أنه يمكن العثور على مقياس لأي نشاط ، ولم يقل مثل هذه الكلمات مطلقًا . لا يمكن قياس كل ما هو ذي قيمة ، وليس كل ما يمكن قياسه ذا قيمة.
لا يعني التعقيد في المقاييس أنه لا يمكن تحسين أي شيء. تقوم بعض الشركات بإصدار برامج أسرع من غيرها ، ودون التضحية بالجودة. هذا يعني أن هناك بعض الاختلافات المهمة ، وبالتالي ، يجب أن تكون التحسينات ممكنة.
ملخص
من الممكن والضروري تحسين منتج البرنامج باستخدام المقاييس. مقاييس الأداء أو التحميل أو الجهوزية أو المنتج مثل التحويل والاحتفاظ بالعملاء هم أصدقاؤك.
ومع ذلك ، يجب ألا تحاول تسريع عملية التطوير بمساعدة المقاييس ، بسبب نقص المقاييس المناسبة. تم اختراع العديد من المؤشرات في هذا المجال ، لكنها للأسف كلها غير مباشرة أو غير دقيقة ، وغالبًا ما تكون كلاهما في وقت واحد ، لذلك عند محاولة استخدامها كأهداف ، يتم الحصول على الضرر فقط
لكن لا تثبط عزيمتك - فهناك أمل! إن عدم وجود مقاييس جيدة لسرعة التطوير أمر محزن ، لكن هذا لا يعني أن تحسين السرعة أمر مستحيل. كيف ممكن. نعم ، لدينا فقط تقييمات نوعية ذاتية للتغذية الراجعة. ومع ذلك ، هناك ما يكفي منها لتنفيذ التحسينات وفهم ما إذا كان هناك تأثير منها. على سبيل المثال ، أحد الأشياء التي يمكن تحسينها هو التواصل بين المطورين والإدارة . يقدم الرابط أعلاه أمثلة على كيفية تحسين الاتصال ، ولماذا يستحق التركيز عليه.
هذا كل شيء ، اكتب في التعليقات ما تعتقده. عمليات نشر سعيدة ، حتى في أيام الجمعة.