لماذا يعمل Kanban - وكيف تعرف ما إذا كان فريقك مستعداً
معظم الفرق تتبنى Kanban لأن شخص ما قرأ مقالة مدونة. السؤال الأذكى هو ما إذا كانت المشاكل التي يحلها Kanban هي فعلاً المشاكل التي يواجهها فريقك.
هناك لحظة تعترف بها معظم الفرق، عادة حول الوقت الذي يكون لديهم أكثر من ثمانية أو تسعة أشخاص. يتم إنجاز العمل - يتم إرسال رسائل البريد الإلكتروني، والميزات الشحن، والعملاء يتم إدارتهم - لكن لا أحد لديه فهم واضح لما يعمل عليه الجميع الآخر. المشاريع تراكم. يتم وعد الأشياء ثم نسيانها بصمت. تقضي عشرين دقيقة قبل كل اجتماع معرفة أين يوجد قطعة العمل فعلاً. الإجابة، عادة، هي "في مكان ما."
هذه هي المشكلة التي صمم Kanban لحلها. ليس المشكلة المتعلقة بوضع الإستراتيجية، أو توظيف الناس المناسبين، أو بناء الثقافة - لكن المشكلة التشغيلية المحددة والمحاكاة المتكررة في معرفة ما يعمل عليه فريقك وما يعيق الطريق.
إنها أداة متواضعة بشكل مثير للدهشة لشيء جذب الكثير من الاهتمام. لا يدعي Kanban إصلاح منظمتك. إنه يجعل العمل مرئياً. وتبين أن الرؤية، عند تطبيقها باستمرار، تغير عدداً ملحوظاً من الأشياء لاحقاً.
أين جاء Kanban في الواقع
الكلمة يابانية - تعني "لافتة" أو "لوحة إعلانات" - والنظام تم تطويره بواسطة Toyota في أواخر الأربعينيات كطريقة لإدارة المخزون في مصانعهم. كانت الفكرة بسيطة: بدلاً من إنتاج الأجزاء على جدول زمني محدد، كان المصنع ينتجها فقط عندما تشير محطة لاحقة إلى أنها تحتاجها. كارت فعلي - kanban - سيسافر مرة أخرى على الخط كطلب. لم يتم صنع شيء المضاربة. لم يتراكم شيء بدون داع.
الرؤية التي توصلت إليها Toyota، والتي استعارتها فرق البرمجيات لاحقاً، هي أن معظم عدم الكفاءة في النظام لا تأتي من الناس يعملون ببطء، بل من العمل الخاطئ يتم في الوقت الخاطئ. بدأ الكثير من الأشياء في وقت واحد. الاختناقات التي لا أحد يلاحظها حتى يتأخر الأوان. العمل الذي ينتهي في مكان ما بينما الخطوة التالية مرهقة في مكان آخر.
بدأ مطورو البرمجيات، خاصة في الشركات مثل Microsoft في أوائل الألفية الثالثة، بتكييف هذه الأفكار للعمل في المعرفة. أصبحت البطاقات مهام. أصبحت محطات المصنع مراحل في سير عمل. واللوحة أصبحت لوحة - جسدية في البداية، ثم رقمية - حيث يمكن لأي شخص في الفريق أن يرى، في نظرة واحدة، ما يجري، ما ينتظر، وما تم.
اللوحة ليست النظام. اللوحة هي التي تجعل النظام مرئياً. النظام هو كيفية عمل فريقك فعلاً - وما إذا كان يعمل لصالحك.
ما تظهره لوحة Kanban الفعلية
لوحة Kanban الأساسية لها ثلاثة أعمدة: للقيام به، قيد التنفيذ، و تم. هذا كافٍ للعديد من الفرق الصغيرة ومكان جيد للبدء. لكن القيمة الحقيقية تظهر عندما تبدأ في تخصيص تلك المراحل لمطابقة كيفية تدفق عملك بالفعل - وليس كيف تتمنى أن يتدفق.
قد تستخدم فريق المحتوى: الفكرة، الملخص، في المسودة، قيد المراجعة، مجدولة، منشورة. قد يقسم فريق البرمجيات "قيد الإجراء" إلى أعمدة منفصلة للتطوير ومراجعة الأكواد والضمان. قد يتابع فريق الاستشارة الاكتشاف والاقتراح والنشط والانتظار من جانب العميل والمغلق. يجب أن تعكس المراحل تسليمات حقيقية وأوقات انتظار حقيقية - أماكن يتغير فيها العمل، أو حيث يجلس حتى يحدث شيء آخر.
لاحظ البطاقة في العمود الأوسط - تقرير تدقيق المستودع، بعد ثمانية أيام، معلمة كمحجوب. في نظام بدون لوحة، قد تجلس هذه المهمة أسبوعين أكثر قبل أن يدرك أي شخص أنها لا تتحرك. شخص ما ينتظر طرفاً ثالثاً. أو هناك حاجة إلى قرار من مدير لا يعرف أنهم المحجوب. تجعل اللوحة الحجب مرئياً. هذا معظم العمل.
القاعدة التي تجعلها تعمل: حدود WIP
إذا كان هناك مفهوم واحد يفصل الفرق التي تستخدم Kanban بشكل صحيح عن الفرق التي تملك قائمة مهام أجمل، فهو حدود العمل الجارية - حدود WIP للاختصار. الفكرة هي أن كل عمود لديه الحد الأقصى لعدد العناصر المسموحة به هناك في وقت واحد. عندما يكون العمود ممتلئاً، لا يمكنك إضافة المزيد من العمل حتى يتحرك شيء ما.
هذا يشعر بأنه معاكس للحدس. بالتأكيد القدرة على وضع المزيد من المهام قيد التنفيذ يعني أن المزيد يحصل؟ لا يفعل. ما يحدث فعلاً عندما يعمل الناس على أشياء كثيرة في وقت واحد هو أن كل شيء يستغرق وقتاً أطول. تبديل السياق مكلف. العمل غير المكتمل ينشئ حملاً تنسيقياً. وعندما يكون هناك عشرة أشياء "قيد الإجراء"، من الصعب جداً معرفة أي منها يتحرك بالفعل وأي منها عالق فقط لكن غير محدد.
حد WIP من ثلاثة في عمود "قيد الإجراء" يعني أنه عندما يصل الشيء الرابع إلى مكتب شخص ما، يجب على شخص ما في الفريق اتخاذ قرار: أي مهمة موجودة يتم إكمالها أولاً؟ إنه يفرض الأولويات. إنه يفرض المحادثة. وهو يميل إلى إنتاج إكمال أسرع للعناصر الفردية، حتى لو كان معدل بدء العناصر الجديدة بطيء.
الدراسات المتعلقة بتعدد المهام تظهر باستمرار أن التبديل بين المهام يكلف تقريباً 20-40 ٪ من الوقت المنتج. المطور الذي يتنقل بين ثلاث ميزات ليس واحد ثالث من حيث الإنتاجية في كل منهما - فمن المحتمل أن يكونوا أقرب إلى الخمس، بمجرد أن تأخذ في الاعتبار الحمل العقلي لاستعادة السياق. حدود WIP لـ Kanban هي، جزئياً، حل هيكلي لهذا.
Kanban مقابل Scrum: السؤال الذي تطرحه الفرق دائماً
إذا أمضيت أي وقت حول فرق البرمجيات أو تفكير العمليات الحديثة، فربما واجهت Scrum - الإطار الذي ينظم العمل إلى رش ثابتة لمدة أسبوعين، مع جلسات التخطيط والاستعادات والأدوار المحددة مثل Scrum Master وصاحب المنتج. تعامل العديد من الفرق Scrum و Kanban كمنهجيات متنافسة وتشعر أنها يجب أن تختار. التمييز يكون في الواقع أبسط من ذلك.
العديد من الفرق - خاصة تلك التي ليست فرق هندسة البرمجيات النقية - تجد حفل Scrum الثقيل وهيكله ذو السباق الثابت محرجاً لتطبيقه على العمل التشغيلي الجاري. تجد فرق التسويق وفرق نجاح العملاء وفرق العمليات والمؤسسون الذين يديرون كل شيء نادراً ما أن العمل يناسب بشكل أنيق في دورات أسبوعين. نموذج التدفق المستمر لـ Kanban يميل إلى أن يناسبهم بشكل أفضل.
ومع ذلك، تجمع العديد من الفرق بين كليهما. يستخدمون دورات التخطيط على طراز السباق لتطوير المنتج بينما يديرون لوحة Kanban للعمل التشغيلي والدعم الذي يتدفق بغض النظر عن السباق الذي تكون فيه. هذا هجين معقول تماماً.
الأسئلة الثلاثة التي يجب أن تجيب عليها لوحتك في ثلاثين ثانية
لوحة Kanban مفيدة جداً عندما تنظر إليها وبدون الحديث مع أي شخص، تجيب على هذه الأسئلة الثلاثة بسرعة: ما الذي يعمل عليه الفريق الآن؟ أين يتعثر العمل؟ هل هناك شيء يجب القيام به لم يتم البدء فيه؟
إذا لم تتمكن من الإجابة على الثلاثة جميعاً في غضون ثلاثين ثانية من النظر إلى اللوحة، فمن المحتمل أنها لا يتم صيانتها بشكل صحيح. أكثر الأنماط الفشل شيوعاً هي لوحة يتم إنشاء المهام فيها لكن لا تتحرك أبداً - تصبح مقبرة للنوايا الحسنة بدلاً من خريطة حية للعمل الفعلي. لوحة لم تكن حالية أسوأ من عدم وجود لوحة، لأنها تخلق انطباعاً كاذباً بالرؤية.
الانضباط المطلوب للحفاظ على لوحة حقيقي. يجب أن تتحرك المهام عندما يتحرك العمل. العناصر المحجوب يجب أن تكون معلمة في اللحظة التي تتوقف فيها، وليس بعد أسبوعين. يجب أن يكون لدى البطاقات مالكون واضحون، ويجب على الملاك تحديث بطاقاتهم. لا شيء من هذا يتطلب الكثير من الوقت - قد تأخذ ممارسة Kanban البسيطة من خمس إلى عشر دقائق لكل شخص يومياً - لكنها تتطلب الاتساق. الفرق التي تستفيد أكثر من Kanban هي تلك التي تعامل اللوحة كمصدر الحقيقة، وليس كممارسة إبقاء السجل الإضافية.
تم بناء عرض لوحة FabricLoop حول هذا بالضبط: مساحة عمل حية حيث تجلس المهام والرسائل والملاحظات معاً، بحيث لا يعني تحديث البطاقة التبديل إلى أداة منفصلة. عندما يحدد شخص ما مهمة محجوب أو ينقلها إلى تم، يبقى هذا السياق مرفقاً - المحادثة التي توضح لماذا توقفت شيء ما، الملف الذي كان التسليم النهائي، الملاحظة التي تلتقط ما تقرر. تبقى اللوحة حالية لأن تحديثها يستغرق نفس جهد ترك تعليق.
ما لا يفعله Kanban
Kanban ليست أداة إستراتيجية. لن تساعدك على معرفة ما يجب العمل عليه - فقط ساعدتك على إدارة ما قررت بالفعل العمل عليه. إذا كانت منظمتك تواجه مشكلة الأولويات، أو مشكلة التفويض غير الواضحة، أو مشكلة "ننفذ الكثير من المشاريع قبل إنهاء الأشياء القديمة" متجذرة في السلوك القيادي وليس العملية، فستكشف لوحة Kanban عن تلك المشاكل ولكن لن تحلها.
كما أنها ليست بديلاً عن الإدارة الجيدة. اللوحة لا تحل محل الواحد على واحد، أو التفويض المدروس، أو التواصل الواضح حول سبب أهمية عمل معين. تتبنى الفرق أحياناً أدوات العملية آملة أن تقوم العملية بالعمل العلائقي والتنظيمي الذي هو في الواقع وظيفة المدير. لن يفعل.
ما سيفعله هو تقليل الغموض المحيط الذي يبطئ معظم الفرق. أسئلة "من يعمل على ماذا" و "هل تم ذلك" و "ماذا يجب أن أختار بعد ذلك" توليد كميات ضخمة من الاتصالات منخفضة القيمة في المنظمات التي لا تملك نظام مشترك ومرئي. Kanban يقضي على معظم هذا الضوضاء. وللفرق حيث تلك الضوضاء هي المشكلة السائدة، الفرق كبيرة.
كيفية البدء - بدون ورشة عمل مدتها ثلاثة أيام
أفضل تطبيقات Kanban التي رأيتها بدأت بحجم صغير وتطورت. أسوأها تضمنت مستشار ورحلة خارج الموقع لمدة يومين ولوحة مصممة بجميل أن لا أحد استخدمها بحلول الأسبوع الثالث.
ابدأ مع فريقك كما هو بالفعل، مع العمل الذي لديك فعلاً. إنشاء ثلاثة أعمدة: المراجع، قيد الإجراء، تم. اقضي ثلاثين دقيقة مع فريقك بوضع كل عنصر عمل حالي على بطاقة. وافق على قاعدة واحدة: عندما تبدأ شيء، يصعد على اللوحة. عندما يتحرك، تحرك البطاقة. لا تفعل شيء آخر لمدة أسبوعين.
بعد أسبوعين، انظر إلى اللوحة معاً. حيث هل أشياء تراكم؟ ما الذي بقي في المراجع التي قال الجميع إنها أولوية؟ ما الذي تحرك أسرع من المتوقع؟ ماذا عالق ولماذا؟ استخدم ما تلاحظه لتحسين الأعمدة وإضافة الخصوصية. ربما "قيد الإجراء" يجب أن ينقسم إلى "قيد الإجراء" و "انتظار الخارجية". ربما تحتاج إلى عمود يسمى "قيد المراجعة" لأن تلك الخطوة تستمر في التضييع. دع اللوحة تتطور استجابة لما يكشفه عملك الفعلي، وليس استجابة لما تقول كتاب المنهجية يجب أن تبدو عليه.
لا تضيف المزيد من الأعمدة لجعل اللوحة تبدو متطورة. كل عمود هو تسليم - وكل تسليم هو مكان حيث يمكن للعمل أن يتعثر. ابدأ بسيط. أضف التعقيد فقط عندما تظهر النسخة البسيطة لك حيث تحتاجه.
اللعبة الأطول: مقاييس التدفق
بمجرد تشغيل نظام Kanban، فإنه يولد البيانات التي معظم الفرق لا تستخدمها أبداً. وقت الرصاص - الوقت الإجمالي من إنشاء المهمة حتى الانتهاء - هو الأهم. إذا كان متوسط وقت الرصاص لديك لمهمة نموذجية اثني عشر يوماً، وتريده أن يكون خمسة، فلديك الآن رقم للعمل ضده ولوحة ستوضح لك أين هذه الأيام السبعة الإضافية تذهب.
يقيس وقت الدورة فقط فترة العمل النشطة، مستبعداً الوقت الذي تجلس فيه المهمة في المراجع. يقيس الإنتاجية كم عدد العناصر التي ينهيها فريقك أسبوعياً. لا يتطلب أي من هذه المقاييس برامج خاصة إذا كنت منضبطاً بشأن ملاحظة عند إنشاء البطاقات وعند إغلاقها. وجميعاً، تعطيك صورة أكثر صراحة عن قدرة فريقك من أي عملية تخطيط قائمة على التقدير يمكن.
معظم الفرق الصغيرة والمتوسطة الحجم لا تصل هنا أبداً. يستخدمون Kanban كأداة رؤية - وهو أمر قيم بحد ذاته - ولا يذهبون أبعد من ذلك. هذا يمين. لكن إذا وجدت نفسك تريد تقديم التزامات لأصحاب المصلحة بشأن متى سيتم القيام بشيء ما، أو تريد فهم لماذا يستغرق بعض العمل ثلاث مرات أطول من المتوقع، البيانات موجودة عندما تحتاجها.
في FabricLoop، تحمل كل بطاقة تاريخها - عند إنشاؤها، عند الانتقال بين المراحل، عند انتهائها. تلك البيانات موجودة سواء استخدمتها الآن أم لا. الفرق التي تبدأ بسيطة غالباً ما تعود إليها بعد ستة أشهر، عندما يريدون فهم لماذا شعر ربع بالفوضى، واكتشف أن اللوحة سجلت كل شيء يحتاجون إلى معرفته.