لماذا لا تحتاج إلى تصحيح جميع الأخطاء لجعل منتج تكنولوجيا المعلومات أفضل

تم إعداد هذه المواد من قبل شريكنا Equio .



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

لكن جودة المنتج النهائي تعتمد إلى حد كبير على الطريقة التي ينظم بها المطور عملية اختبار وتحديد وإصلاح الأخطاء ، بين المطورين المعروفين باسم "الأخطاء" (من الأخطاء الإنجليزية - خطأ ، أي حشرة أو فيروس أو كلمة عامية تعني عادةً وجود خطأ في البرنامج). تم طرح هذا السؤال من قِبل عدد قليل جدًا من عملاء الأعمال الفرديين.

نريد أن نخبرك بكيفية قيام المطورين بتحديد الأخطاء وإصلاحها ، وهي مناسبة للاختبار. تستند إحدى الطرق إلى سياسة الأخطاء الصفرية. المفسد! سنخبرك بما يقضيه المطورون بالفعل من وقت ولماذا لا يصلح كل الخلل.

سبعة مربيات

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

هذا ملحوظ بشكل خاص عندما يعمل عدد كبير من المطورين أو حتى فرق المشروع على منتج برمجي ، على قاعدة شفرة واحدة. من الصعب جدًا مزامنة جهودهم والحصول على رمز خالٍ من الأخطاء في الإخراج تمامًا. على سبيل المثال ، قام فريق واحد بحفظ التغييرات في الفرع الرئيسي ، أي في الإصدار الرئيسي من الكود في المستودع (المستودع). بدوره ، يواجه الفريق الآخر عددًا كبيرًا من الصراعات ويحاول حلها. نتيجة لذلك ، يتم إطلاق كل هذا ، أي في الإصدار النهائي للمنتج ، ومناسب للمستخدمين العاديين ، وهنا يظهر عدد لا يصدق من الأخطاء. وهذا محفوف بخسارة المال والعملاء والأهم من ذلك تهديد لسمعة المطور.

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

بعيدا عن الأنظار ، تراكم الخروج

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

جوهرها هو على النحو التالي. عندما يعثر المختبرون أو المستخدمون على أي خلل في المنتج ويخبرون المطورين به ، يقرر الأخير ما إذا كان سيتم إصلاح هذا الخطأ أو لا يؤثر على أداء المنتج ، وبالتالي قد يتأخر تصحيحه أو يستبعد تمامًا من تراكم (قائمة المهام). يتم تعيين هذا الخطأ في حالة Won't Fix ، وبعد ذلك يختفي إلى الأبد من مجال رؤية المطورين. في بعض الحالات ، يتم وضع الأخطاء مع هذه الحالة في نهاية التراكم. هذا يعني أن المطورين "سيحققون أيديهم" لإصلاحهم فقط عندما يتم حل جميع المهام الأخرى.

ولكن العودة إلى شركة تكنولوجيا المعلومات المذكورة بالفعل. قام موظفوها بتحليل القائمة الكاملة للأخطاء المكتشفة وحل المشكلات الموجودة. تم تحديد ما يقرب من نصف الأخطاء في المستقبل القريب ، وتم تعيين أكثر من نصفهم على حالة Won't Fix. استغرق كل هذا العمل حوالي شهرين ، وبعد ذلك قررت الشركة اعتماد سياسة الشوائب على أساس مستمر. حتى الآن ، لا يوجد لدى هذه الشركة أكثر من 10 مهام مفتوحة في الأعمال المتراكمة. هذا يتيح لك التركيز على تنفيذ ميزات جديدة.

خبراء علة

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

سنخبرك بكيفية تنظيم هذه العملية باستخدام مفهوم الإدارة المرنة للمشروعات (Agile). يعلم الجميع أن رشيق يتضمن العديد من التقنيات. سوف نأخذ أحدهم كمثال ، وهو SCRUM ، لأنه يستخدم غالبًا في عالم تطوير البرمجيات.

مالك المنتج أو Scrum Product Owner هو أحد الأعضاء الرئيسيين في فريق المشروع. هو الذي يمثل مصالح المستخدمين النهائيين ويبذل كل جهد ممكن لزيادة قيمة المنتج. وهو مسؤول أيضًا من البداية إلى النهاية عن تراكم المنتجات. يشارك فريق التطوير بأكمله في فرز الأخطاء ، ولكن الكلمة الأخيرة هي دائمًا لمالك المنتج. يحدد الخطأ الذي سيتم إصلاحه والذي تم تحديده على أنه "لن يتم إصلاح".

في الواقع ، كل شيء هو المال. على سبيل المثال ، إذا كان إصلاح الخلل لن يحقق أي عائد مالي للشركة ، ولكن في الوقت نفسه سيستغرق الكثير من الوقت والموارد ، سيكون من الأفضل لمثل هذا الخطأ تعيين حالة Won't Fix وتأجيل إصلاحها حتى أوقات أفضل. في الواقع ، فإن "مالك المنتج" مسؤول عن تحديد الأولويات وحالة الأخطاء التي تم العثور عليها.
بمعنى آخر ، كل شخص لديه "هياكل عظمية في الخزانة". ولكن إذا لم يكن لها أي تأثير على أداء المنتج ، أو لا تعرقل إجراءات المستخدم ، أو تعيق عمليات التكامل ، فيمكن تجاهلها تمامًا.

معايير الاختيار

هذه الأخطاء "الثانوية" موجودة في منتجات أي مطور.

على سبيل المثال ، في واجهة المشرف لنظام إدارة المحتوى ، من المستحيل إدخال عنوان طويل جدًا لقسم أو مقالة أو ما إلى ذلك. يقرر المطورون عدم إصلاح هذا الخطأ. بعد كل شيء ، يستغرق التصحيح الوقت والموارد ، ويمكنك فقط أخذ الاسم وتقليله إلى عدد معين من الأحرف. يكفي أن نحذر المستخدم من أن الأسماء التي يزيد طولها عن 30 حرفًا غير مدعومة.

يكون الزر في اللون الخاطئ قليلاً ، وتقع عناصر الواجهة على بكسلين على يسار ما هو مطلوب - كل هذه الأخطاء لا تؤثر على قابلية الاستخدام أو أداء التطبيق. لذلك ، يمكن أن يُنسب ذلك إلى Won't Fix.

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

العقل الجماعي

غالبًا ما ترتبط سياسة الخطأ الصفري باتفاقية مستوى الخدمة (SLA). عادةً ما يكون للمطورين العديد من خطوط الدعم الفني.

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

خطوط الدعم الفني الأول والثاني ، وكذلك المطورين ، لديهم اتفاقيات مستوى الخدمة. وكلما كان هذا الخطأ أكثر أهمية ، كانت معايير SLA أكثر صرامة لإصلاحه. هناك أيضًا SLA عام لاستكشاف الأخطاء وإصلاحها: من جهة اتصال العميل إلى الحصول على الكود الصحيح في الإنتاج. يتم اتخاذ قرار بشأن تعيين حالة خطأ إلى Won't Fix أو عدم التعيين بواسطة السطر الثاني من الدعم الفني. ومع ذلك ، فإن حكمها ليس نهائيًا. بادئ ذي بدء ، يسترشد موظفوها بمبادئ وقواعد السباق الحالي. بالإضافة إلى ذلك ، هناك مجموعة من التوقعات من المطورين ، من العملاء ، من قسم تطوير الأعمال.

إذا نشأ موقف مثير للجدل عندما يتم أخذ كل هذه العوامل في الاعتبار ، فستكون الكلمة الأخيرة بالضبط وراء السطر الثاني من الدعم ، وبالطبع مالك المنتج.

راض يعني الإنتاجية

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

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

هذا كل شيء. يمكن العثور على مزيد من المعلومات حول شركة "Equio" على موقع الويب الرسمي الخاص بها.

وعلى موقع Otus ، يمكنك التعرف على دوراتنا وحضور ندوات الويب المجانية التي تهمك.