Get best of the week

طريقة كانبان: فهم عمليتك كعملية تعلم جماعي

مقدمة


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

فهم عمليتك كعملية تعلم جماعي


والمقال الأول في السلسلة حول كيفية بناء تصور أكثر كفاءة لعمليات عملك وإدراك لوحة. مؤلف المقال الأصلي هو Alexei Zheglov ويمكن العثور عليه هنا ،

هناك اتجاه عام ورغبة في جعل العمل أكثر جماعية. ومع ذلك ، عندما أطلب من الأشخاص في المكتب رسم عملية عملهم ، غالبًا ما يقدمون شيئًا مثل هذا (أبسط):


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

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

يحاول البعض تصور هذه العملية على لوحة يسمونها "كانبان":


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

هل هناك طريقة أفضل؟


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

في مثال تقديم وظائف جديدة لمنتج برنامج ، يمكن إنشاء المعرفة التالية (ليس بالضرورة في هذا الترتيب):

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

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

إذا حاولنا تصور عملية تجميع هذه المعرفة ، فقد تبدو النتيجة كما يلي:


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

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

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

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

لاحظ أن النقاط الثلاث في الرسم البياني للعملية الجديدة ليست تحويلات بين المتخصصين أو الأقسام الوظيفية. هذه هي التغييرات في النشاط السائد والتغيرات المقابلة في نمط التفاعل.

استنتاج


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

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

ماذا بعد؟


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

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

شكرا جزيلا لأليكسي بيمينوف وستيبيف.

More articles:


All Articles