ما هي القياسات التي تستخدمها لتحسين عملياتك؟[مغلق]

Question

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

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

بالنظر إلى كل هذا، كيف يمكنك معرفة ما إذا كانت تحسينات عملياتك لها تأثير إيجابي؟إذا كانت هذه مؤشرات الأداء الرئيسية, أو [الأهداف الذكية](http://en.wikipedia.org/wiki/SMART_(project_management) يرجى تقديم مؤشرات الأداء الرئيسية/الأهداف الذكية الفردية أو الجماعية التي وجدت أنها فعالة.إذا كانت هناك آلية أخرى يرجى توضيح ما هي.أخيرًا، أعتقد أنه إذا كنت لا تعتقد أن تحسين العمليات أمر مفيد، أعتقد أنه يمكنك شرح ذلك أيضًا.

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

ملاحظات توضيحية:

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

لا ينبغي الخلط بين استخدام التدابير لتحديد ما إذا كان قد تم تحقيق تحسين العملية، وبين التحسين المستمر للعملية.(هذا أمر جيد، ولكن ليس هذا هو موضوع السؤال!)

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

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

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

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

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

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

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

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

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

Answer 1

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

التدابير الأخرى المعتادة، مثل SLOC، SLOC - ساعة الموظفين، إلخ، بسبب قانون الإدارة في تشارلي للإدارة، وهو:

سيقوم الناس بتسليم ما يجري مكافأتهم به.

قم بإعداد التدابير الخاصة بك كسلوك، وستحصل على الكثير من SLOC. استخدم SLOC / HR، ستحصل على الكثير من SLOC / HT. امنحهم مكافآت للعمل الإضافي، ستحصل على الكثير من العمل الإضافي.

أوه، وتذكر الارتباطية أيضا:

ما يفعله الناس هو ما يعتقدون أنه سيتم مكافأته في تقديمه.

إذا كنت لا تحصل على ما تريد، فاطلب لماذا يكافئ من القيام بالأشياء التي يتم القيام بها.

Answer 2

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

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

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

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

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

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

تحديث لمحاولة معالجة السؤال المنقح

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

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

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

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

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

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

أما بالنسبة للمرونة، فلا يمكنني حتى المخاطرة بتخمين كيفية قياس شيء غير ملموس.

فيما يتعلق بالقياس الوحيد الذي يمكنني التفكير فيه والذي له قيمة هذا الجانب من محفظة العميل سرعة المشروع - ما هو مقدار تقديرنا الذي سنقوم به في التكرار/الدورة/الإصدار الأخير وما مقدار ما أنجزناه بالفعل؟ثم أدخل هذا الرقم في الوقت المتاح للتكرار/الدورة/الإصدار التالي لتقدير مقدار ما يمكنك إنجازه هذه المرة.يمكنك عرض الوقت المتبقي في حرق الرسم البياني أو ما شابه ذلك أثناء التكرار.

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

لسوء الحظ، لا أعتقد أن هناك أي مؤشرات أداء رئيسية سحرية مثلك (ولكن لا تتجاهل أهمية الحصول على المال من العملاء كمؤشر أداء رئيسي).

Answer 3

بينو، أنا أجيب على تعليقك ولكن ليس لدي ما يكفي من الأحرف للإجابة.

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

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

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

Answer 4

بناء KPIS الخاص بك حول التكلفة والجودة والجدول سيكون بداية جيدة. فكر في السمات لكل من أولئك الذين تريد قياسهم.

القدرة على تقسيم كل من هذه التدابير لإظهار تكلفة الأخطاء ستكون مفيدة - الكثير من جهد إصلاح الأخطاء في وقت متأخر من المشروع يعني التكلفة / الجدول الفتحة. القدرة على الملف الشخصي الذي يمكن أن تساعد أجزاء من CodeBase تساعد في استهداف اختبار إضافي وإعادة تكوين التعليمات البرمجية المحتملة - عادة 80٪ من الأخطاء ستأتي من 20٪ من التعليمات البرمجية. معرفة أين سيسمح فريقك بالتركيز بشكل أفضل.

تعديل: انظر إلى تدابير مثل تكلفة الجودة (COQ) وتكلفة الجودة الرديئة (COPQ).

من الصعب دائما تحديد تدابير مثل الإنتاجية - على سبيل المثال، باستخدام LOC / DAY يؤدي إلى نقاش حول ما هو بالضبط خط التعليمات البرمجية؟ يمكن أن يؤدي أيضا إلى تنسيق رمز سخيف إلى "تعزيز" الإنتاجية إذا لم يفهم المطورون سبب تعقبهم هذه الأشياء أو إدراكها كقياسات شخصية. حتى إذا لم يتم قياس Loc / Day على مستوى المطور، فلا يزال بإمكانك الحصول على تنافس فريق يؤدي إلى نفس النتيجة.

تحرير: هناك بعض المناقشات الجيدة التي يمكن العثور عليها على Steve McConnell's Construx. موقع الكتروني. [نعم، هذا هو ستيف McConnell of Code Fame الكامل

Answer 5

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

نعم، لا تزال بحاجة بالتأكيد إلى شخص ينظر إلى مستوى ماكرو. إذا نظرت إلى مؤسسة مثل تويوتا، يكون لديهم مهندس كبير يتدلى بهذا الخط بين الأعمال والإنتاج (للحصول على تفسير جيد، انظر Scott Bellware مشاركة مدونة). في منظمتنا، لدينا شخص مشابه - كان مدرب بلدي أحد المطورين الأوليين لمنتجنا قبل ما يقرب من 20 عاما، ويبقى نشطا للغاية في الجانب التكنولوجي، ولكنه استثمر بشدة في جانب العملاء أيضا. وظيفتي هي أيضا أن ننظر إلى الفرق ككل لاقتراح التحسينات.

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

أفضل استخدام لمؤشرات الأداء الرئيسية هو القيادة (أو التوجيه، إذا كنت تفضل ذلك).ل تصحيحات المسار في الوقت الحقيقي.

(يرى لوحات المعلومات مخصصة للقيادة لمزيد من الثرثرة حول هذا الموضوع الفرعي.تنبيه قضائي:أنا كاتب المقال الثرثار.)

لذا يعود السؤال إليك:هل تحاول تقييم الأداء بعد الحقيقة, ، عندما يكون فات الأوان لفعل أي شيء حيال ذلك, أو هل تحاول العثور على مؤشرات أداء رئيسية يمكن أن تساعدك البقاء على المسار الصحيح?

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

إذا كان الأخير، فاختر سرعة.بافتراض أنك تستخدم التطوير القائم على الاختبار (TDD) بالطبع.

يحرر:لذلك هو السابق.حسنًا، لهذا السبب ربما لم يحالفك الحظ:

لنفترض أنك قررت أنه من الأفضل قياس "الجودة" من خلال قياس عدد الأخطاء التي أبلغ عنها العملاء كمؤشر أداء رئيسي لمرحلة ما بعد العملية.لنفترض أنك تستخدم TDD، ولنفترض أن فريقك يسلم المنتج رقم 1 خلال 6 أشهر، وبعد 6 أشهر في الميدان تجد أن لديك 10 أخطاء أبلغ عنها العملاء.والآن، ما الذي ستفعله بالضبط لتحسين عمليتك؟اختبار أكثر؟اختبار على وجه التحديد لمزيد من الأشياء مثل أسباب الأخطاء التي تم الإبلاغ عنها؟يبدو لي أنك ستجري الاختبار بالفعل، وعندما يتم اكتشاف الأخطاء - سواء من قبل العميل أم لا - فإنك تضيف اختبار الانحدار للخلل المحدد واختبارات الوحدة الإضافية للتأكد من عدم وجود أخطاء مماثلة.بعبارة أخرى، لن تختلف استجابة التحسين بعد العملية عن استجابة التحسين أثناء العملية, ، لذا فإن مؤشر الأداء الرئيسي هذا لا يقدم أي مساعدة كبيرة في تحسين عمليتك.النقطة المهمة هي أن الطريقة التي تعمل بها على تحسين عمليتك تظل كما هي بغض النظر عما إذا تم اكتشاف الأخطاء بعد 6 أشهر من الإصدار أو بعد يومين من البرمجة.لذلك، على الرغم من أن هذا قد يكون مؤشر أداء رئيسيًا لامعًا لوضعه على حائط المدير أو النشرة الإخبارية للإدارة، إلا أنه في الواقع لن يغير آليات تحسين العملية لديك.(واحذر من وضع الكثير من المخزون في مؤشر الأداء الرئيسي هذا لأنه يمكن أن يتأثر بشكل كبير بعوامل خارجة عن إرادتك!).باختصار، معرفة عدد الأخطاء لا يساعدك على التحسن.

(هناك خطر آخر هنا، وهو خطر شائع ليس فقط في مجال الأعمال التجارية ولكن أيضًا في المؤسسة العسكرية، وهو الوهم بأن تحليل ما بعد الوفاة كشف عن معلومات قيمة، وبالتالي فإن الدروس المستفادة بعد الوفاة يتم تطبيقها بقوة على المشروع التالي، والذي ربما لا يكون هو نفس المشروع الأخير.يُعرف هذا باسم "خوض الحرب الأخيرة".)

لنفترض أن عدد مرتجعات/استردادات العملاء هو مؤشر الأداء الرئيسي الذي تختاره لـ "الجودة" - إذا كان هذا الرقم هو 5، فماذا يخبرك هذا؟قد تكون الأسباب المحددة التي تجعل العملاء يطلبون استرداد الأموال بمثابة إشارة إلى مشاكل في الجودة ("بطيئة جدًا"، "لا تتفاعل مع نظام XYZ"، وما إلى ذلك)، ولكن مجرد رقم من مثل هذه الحوادث لا أقول لك شيئا.قد يخبرك التباين مقابل نسبة العائد المتوقعة ما إذا كانت الجودة تتحسن، ولكن مرة أخرى الرقم لا يساعدك على التحسن.أنت بحاجة إلى معلومات أكثر مما يمكن أن يوفره لك الرقم.

لذا، بالنسبة لـ "توقيت النشرات" ما هو المقياس المناسب؟عدد أيام انزلاق تاريخ الشحن؟تجاوز النسبة المئوية بناءً على التقديرات الأصلية؟ لا يهم, لأنه مرة أخرى الأرقام لا تساعدك على التحسن.

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

ليس لدي أي فكرة عن كيفية قياس "المرونة"، والتي تبدو مثل المصطلحات التسويقية؛-)

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

Answer 9

يمكنك الحصول على الكثير من الأفكار حول KPIS وأمثلة لوحات المعلومات في http://www.dashboardzone.com.

لديها KPIs حسب الصناعة والمناطق الوظيفية.