باختصار - تعد مخططات Gantt مفيدة عندما تكون التبعيات هي العامل الرئيسي في تكوين الجدول ، في حين يمكن استخدام لوحات Kanban للأعمال التي لا تحتوي على تبعيات فيما بينها.
بالإضافة إلى ذلك ، تعد مخططات Gantt مناسبة عندما تكون هناك خطة أولية للمحتوى الكامل للمشروع (على الأقل رفيع المستوى) ، في حين تعد لوحات Kanban أكثر ملاءمة للحالات التي تنشأ فيها الخطة بأكملها ويتم الانتهاء منها مع تطور المشروع.
تعد لوحات Kanban أكثر ملاءمة للعمل المتكرر (العمل مع خطوات مماثلة) ، وتعد مخططات Gantt هي الأفضل لدمج أنواع مختلفة من العمل.
أخيرًا ، تتضمن هذه الأدوات وجهات نظر مختلفة حول العمل ، والتي يجب أن تتوافق مع نهجك في العمل ونهجك في التنمية (رشيقة أو تنبؤية).
الآن لنأخذ بضع دقائق إضافية لمعرفة التفاصيل.
هذه أكثر من مجرد طرق مختلفة لتصور البيانات.
تبدو مخططات جانت ولوحات كانبان مختلفة تمامًا ، أليس كذلك؟
يقدم كل من مخطط جانت ولوحة كانبان افتراضيًا طرقهما الخاصة لتصور البيانات. على الرغم من أن طريقة التصور قد تكون مهمة ولها آثار عملية ، إلا أن المفاهيم والأساليب التي تقوم عليها هي أكثر أهمية ، لذلك دعونا نلقي نظرة سريعة عليها.
المفاهيم الكامنة وراء لوحات كانبان
أولاً ، من المهم ملاحظة أن Kanban Board يختلف عن Kanban ، وهي طريقة ، وأيضًا تختلف عن Kanban Development ، التي تعد بديلاً عن Scrum (وهي مستوحاة إلى حد كبير من Scrum).
تم استخدام طريقة Kanban في الإنتاج لبعض الوقت. تحتوي الطريقة على عدة قواعد ، أحدها هو تصور العمل. ويتم هذا التصور على لوحات kanban.
في طريقة Kanban ، نحدد المراحل في العمل وننشئ أعمدة لها على السبورة.
في كل مرحلة ، يعمل العديد من الناس. دعونا إضافتها إلى اللوحة أيضا.
هناك قاعدة أساسية أخرى في Kanban (بالإضافة إلى التصور) وهي أن كل مرحلة من مراحل العمل يجب أن يكون لها حد على العمل غير المكتمل حتى تتمكن من التركيز على إكمال المهام.
لا توجد صيغة لحساب الحد المثالي للعمل الجاري لكل مرحلة. كقاعدة عامة ، يقوم الأشخاص بتعيين القيمة الأولية على أساس تجربتهم الخاصة ، ثم يبحثون عن الحد الأقصى من خلال التجربة والخطأ.
لذلك ، دعونا نضيف العمل في حدود التقدم إلى المجلس.
دعونا نتخيل أنهم يعملون بالفعل على عدة عناصر.
عادة في مثل هذه الحالات ، نرسل العنصر إلى المرحلة التالية ، أي "دفع". تقدم شركة Kanban حلاً آخر: إنه نظام "سحب" ، أي أنه لا يمكننا إرسال العمل إلى المرحلة التالية ؛ يبقى هناك حتى تتطلب الخطوة التالية عنصر عمل آخر ولن "يسحبه" إلى العمود الخاص به.
يبدو غريبا؟ هل فكرت في الاختلافات العملية بين النهج؟ سأتحدث عنها في غضون دقيقة واحدة ، لكن أولاً ، دعنا نقوم بتحديث مجلسنا لتصوره بشكل أفضل عن طريق تقسيم كل عمود إلى قسمين: أحدهما للعناصر في هذا العمود التي لا تزال بحاجة إلى عمل ، والآخر للعناصر التي تم الانتهاء منها.
الآن ، بدلاً من الانتقال (F) إلى العمود التالي ، نضعه على الجانب الأيمن من نفس العمود.
لذا ، سألت عن الفرق العملي ، وهنا: تخيل أنه تم الانتهاء من (G) و (H) و (I) و (C).
ماذا ستفعل إذا كنت في المرحلة 2؟
عادةً ما تكون الإجابة هي: تأخذ العنصر (I) من العمود السابق وتبدأ في العمل عليه. لكن انتظر - عملك في حدود التقدم هو ثلاثة ، لديك بالفعل ثلاثة عناصر! نعم - (F) و (G) و (H) ، والتي تقع على الجانب الأيمن من العمود ، لا تزال تحسب. إنه أيضًا نظام سحب ، وتحتاج إلى الانتظار حتى يمتد الأشخاص في الخطوة 3 (F) ، بدلاً من دفعه إلى العمود الخاص بهم.
تكمن المشكلة في أنه لا يُسمح لك بأخذ عنصر عمل جديد ، ولكن لا يوجد شيء عليك القيام به ؛ ماذا يحدث الآن؟
هذا التقييد أمر بالغ الأهمية في كانبان. في هذه المرحلة ، لا يمكن للأشخاص في المرحلة 2 البدء في العمل على عنصر جديد وعليهم الذهاب ومساعدة الأشخاص الذين يتعاملون مع عنق الزجاجة - المرحلة 3 في مثالنا:
يمكن أن يمتد هذا إلى أعمدة أخرى: عندما يتم تنفيذ (J) في المرحلتين 1 و (A) و (B) في المرحلة 4 ، ينبغي أيضًا الانضمام إلى المرحلة 3 ومحاولة حل المشكلة معًا.
هذه هي فكرة طريقة Kanban: الجميع يركز على العملية برمتها ، وليس على واحدة من مراحلها ، وتُعطى الأولوية القصوى للإكمال السريع لعناصر العمل ، بدلاً من إكمال عدد كبير من المهام وإنشاء عمل غير مكتمل.
لذا ، إذن ، فإن لوحة Kanban هي الطريقة التي نتصور بها خيار العمل هذا. عادة ما أؤكد ذلك لأن معظم الناس يستخدمون ألواح الكتابة ، مثل Trello ، كطريقة تصورية مجانية بسيطة لمهامهم ، بغض النظر عن طريقة Kanban. (يجب أن أعترف ، وأحيانًا أفعل ذلك أيضًا!)
لذلك ، دعونا الآن نلقي نظرة على المفاهيم الأساسية لمخططات جانت ، وبعد ذلك يمكننا مقارنتها.
مفاهيم مخطط جانت
هنا هو مخطط جانت نموذجي:
كما ترون ، يتم عرض تواريخ البدء والانتهاء للعمليات هنا ، هناك تاريخ الانتهاء من المشروع ككل. من أين تأتي التواريخ؟
يعتمد مخطط جانت الطبيعي تمامًا على التبعيات بين العمليات. على سبيل المثال ، لا يمكن بدء العملية A 'للنتيجة B حتى إتمام العملية A للنتيجة A.
لذلك ، لإنشاء مخطط جانت ، نقوم أولاً بإنشاء SRI ، وهو ما يعني "الهيكل الهرمي للعمل" ، على الرغم من أنه في الواقع لا يتعلق بالعمل ، بل يتعلق بالتسلسل الهرمي للنتائج / المنتجات. (على الأقل ينبغي أن يكون.)
ثم نتحقق من العمليات التي يجب إجراؤها للحصول على كل نتيجة وإضافتها إلى القائمة. تشبه هذه الإجراءات إلى حد ما الأعمدة الموجودة على لوحة Kanban ، باستثناء أننا لسنا مقصورين على مجموعة ثابتة من الخطوات ، وقد تختلف كل نتيجة.
ثم نقوم بتقييم مدة العمليات.
ثم نحدد التبعيات بين العمليات ، والتي بدورها ستؤثر على تاريخ بدء ونهاية العمليات. عادةً ما يتم حساب التواريخ باستخدام طريقة المسار الحرج (CPM).
وفويلا ، لدينا جدول زمني!
حسنًا ، هذا هو أبسط أشكال الجدول الزمني ، ويمكنك أيضًا مراعاة الموارد والقيود وساعات العمل المختلفة لمختلف العمليات والموارد ، إلخ.
لذا ، فإن النتيجة الأولى لاستخدام مجموعة CPM / Gantt هذه هي أنه سيكون لدينا حساب من القاعدة إلى القمة يمنحنا تاريخ الانتهاء من المشروع. لكن هذا ليس كل شيء ... يمكننا معرفة المزيد.
فيما يلي بعض الأمثلة:
يمكننا التحقق من سيناريوهات مختلفة
لنفترض أننا قلقون من أن أحد الموردين قد يكمل العمل بعد 30 يومًا. كيف سيؤثر هذا على المشروع؟ ليس من السهل تحديد ذلك في نظام غير خطي ، ولكن عندما يكون لدينا نموذج الجدول الزمني الصحيح ، يمكننا ببساطة تغيير مدة هذا العنصر ومعرفة كيف يؤثر على كل شيء آخر.
يمكننا تحليل التأخير
لنفترض أننا أكملنا مشروعنا بعد ثلاثة أشهر مما يجب. ومع ذلك ، تم تأخير بعض أجزاء المشروع بسبب العميل ، والآن نحن بحاجة إلى تحليل التأخير ومعرفة أي جزء من التأخير هو مسؤوليتنا. في هذه الحالة ، يمكننا إضافة تأخيرات العميل إلى عناصر المخطط ، ومعرفة التأخير الذي يخلقونه للمشروع بأكمله ، وبعد ذلك سيكون الفرق بين هذا التأخير الفعلي هو مسؤوليتنا.
يمكننا أن نجد أهم العمليات
ليست كل العمليات متكافئة. يمكن تأخير بعضها لفترة زمنية معقولة دون تأخير المشروع بأكمله ، بينما يكون للبعض الآخر تأثير أكبر ، مما يعني أن كل يوم تأخير في هذه العمليات سيضيف يومًا واحدًا من التأخير إلى المشروع بأكمله. ألا يجدر بنا معرفة أي العمليات مهمة ، وبالتالي كن أكثر حذراً معها؟ تساعدنا طريقة المسار الحرج في العثور على هذه الإجراءات.
لذلك ، درسنا المفاهيم والأساليب التي تكمن وراء مخططات جانت وكانبان للوحات. الآن يمكننا مقارنتها حقًا.
الاختلافات في السياق
مخططات Gantt مخصصة للمشروعات ، وليس للإنتاج وأنواع أخرى من الأنشطة اليومية (أي ، الأعمال العادية أو أنظمة تشغيل). لقد رأيت الكثير من الناس ينظرون إلى شؤونهم اليومية كمشاريع ويحاولون استخدام الأدوات والأساليب مثل مخطط جانت و CPM ، لكن هذا لا يعمل بشكل جيد للغاية. رأيت أيضًا أشخاصًا يدعون أن كل شيء هو مشروع (والذي يشجعني عادة على بدء مناقشة طويلة معهم ؛)
كانبان ، من ناحية أخرى ، كان في الأصل (وربما بشكل أساسي) مخصصًا للإنتاج ، لكن الناس استخدموه لفترة طويلة في المشروعات.
الاختلافات في أنواع عناصر العمل
يتم إصلاح الأعمدة على لوحة Kanban ، مما يجعله مفيدًا عندما يكون لدى العناصر مراحل متشابهة جدًا من العمل عليها. ليس هذا هو الحال دائمًا ، مما يحد من استخدام كانبان. يمكننا دائمًا أن نجبر أنفسنا على جعل الأعمدة عامة قدر الإمكان ، قابلة للتطبيق على كل عنصر ، ولكن هذا يجعل نظام Kanban غير فعال.
وبالتالي ، إذا كانت العناصر الموجودة في مشروعك مختلفة تمامًا عن بعضها البعض (على سبيل المثال ، في مشروع إنشاء) ، فقد لا تعمل لوحة Kanban.
الاختلافات التبعية
مخطط جانت لا معنى له تقريبًا بدون تبعيات. ما زلت أتذكر أحد إصدارات Microsoft Project منذ سنوات عديدة عندما قدمت لأول مرة "التخطيط اليدوي" وكان من الممكن إنشاء مخططات دون تبعية. اعتبر الكثيرون هذا التجديف!
على الرغم من ذلك ، يمكنك اعتبار CPM / Gantt كأداة لإدارة التبعيات ، ولكن هذا لا ينطبق على لوحة Kanban ، والتي يتم استخدامها عندما لا يكون للعناصر نفسها أي ترابط ، وتكون التبعية الوحيدة هي مراحل العمل ، التي يتم تصورها في شكل أعمدة على مجلس.
بالنسبة للمشاريع ، فإن مفهوم التبعيات مثير للجدل بعض الشيء. التفسير العام هو أن هناك تبعية في المشاريع التنبؤية (يطلق بعض الناس على هذا اسم "الشلال" ، والذي لا يعجبني) ، وبالتالي فإن مخطط جانت يعد خيارًا جيدًا ؛ بينما في مشاريع Agile لا توجد تبعيات ، ومن هنا اقتراح استخدام لوحات Kanban.
حتى أنني سمعت بعض الأشخاص الذين ليسوا من كبار المعجبين ببرنامج Agile ، يتساءل Agile لأنه "لا يأخذ الإدمان في الاعتبار". والحقيقة هي أن Agile لا يتجاهل التبعيات ، ولكن الفكرة هي التعامل مع المشروع وتكوين عناصر بطريقة لا يتم إنشاء التبعيات بها. إذا تم ذلك بشكل صحيح ، فلن يكون هناك (أو على الأقل ليس كثيرًا) تبعيات.
الاختلافات في أساليب التخطيط
يعمل مخطط جانت عندما يكون هناك خطة أولية تغطي كامل نطاق المشروع ، وتعمل بشكل أفضل عندما تكون الخطة مفصلة نسبياً. ويرجع ذلك إلى حقيقة أنه في حالة وجود عناصر ذات مستوى عالٍ للغاية فقط في الخطة ، فإن التبعيات بينها ستكون غير دقيقة وتعسفية للغاية ، حيث يتم تكوين التبعيات الحقيقية على أساس عمليات صغيرة نسبيًا ، ثم تنعكس على مستويات أعلى من الخطة.
وبالتالي ، إذا لم تكن هناك خطة كاملة في بداية المشروع ، فلن يعمل مخطط جانت. من ناحية أخرى ، لا توجد مثل هذه القيود في طريقة كانبان. يمكنك دائمًا إضافة عناصر جديدة إلى العمود الأول وترتيب العمود مرة أخرى ؛ ثم تذهب وإضافة المزيد من العناصر كما تظهر. لفهم هذا بشكل أفضل ، تخيل فريقًا يدعم تطبيقًا مباشرًا للبرنامج ، وإصلاح الأخطاء وإضافة ميزات ثانوية (وهو روتين يومي ، وليس مشروعًا).
لهذا السبب ، فإن مخطط جانت غير مناسب لمشاريع أجيل النموذجية التي لا توجد فيها خطط أولية. ومع ذلك ، فإن بعض المشاريع Agile (مثل DSDM) لديها خطة أولية رفيعة المستوى.
عند استخدام لوحات كانبان
نظرًا لأن مشاريع Agile يمكن أن تحتوي على عناصر بدون تبعيات ، يمكنك استخدام لوحات Kanban فيها. يمكن أن يكون إما لوحة Kanban فقط للتصور ، كما هو الحال عادة في معظم مشاريع Scrum ، أو تقنية Kanban مع لوحة خاصة به ، والتي توجد غالبًا في طريقة تطوير Kanban.
من ناحية أخرى ، قد لا يحتوي مشروع Agile النموذجي في البداية على محتوى واضح ، ولكنه يسمح له بالظهور والتطور خلال المشروع بأكمله. يتم الحفاظ عليها بشكل جيد من قبل Kanban.
في الواقع ، لا يمكن إزالة التبعيات في المشاريع التنبؤية ، ولا إطلاق مشروع بدون محتوى محدد. على الرغم من أنه يمكنك دائمًا بدء مشروع دون خطة ، إلا أنه لن يصبح مشروعًا تنبؤيًا أو تكيفيًا ؛ سيكون مجرد فوضى. وبالتالي ، ولهذين السببين بالفعل ، لن يكون Kanban حلاً جيدًا للمشاريع التنبؤية.
متى يجب استخدام مخططات جانت
يحتوي المشروع التنبئي على العديد من التبعيات ومحتوى معين ، والذي يتم تحديده مسبقًا. تم تصميم مخطط جانت خصيصًا لدعم هذا النوع من المشاريع - إنه أمر بسيط!
نظرًا لأن مشاريع Agile ليس لها تبعيات (أو على الأقل لا ينبغي أن يكون لها) ، فلن يكون مخطط Gantt مفيدًا لهم. على الرغم من أن بعض مشاريع Agile (مثل DSDM) لديها خطة أولية عالية المستوى يمكن إدارتها باستخدام مخطط Gantt ، فإن معظم مشاريع Agile التي تستخدم Scrum أو أشكالها الأخرى ليس لديها بالضرورة أي خطة أولية ، مما يجعل استخدام مخطط Gantt عمليًا من المستحيل.
مجموعة
ثم ماذا عن الجمع بين أداتين؟
كل واحد منهم هو أكثر فائدة لأحد النهج. لذلك لن يساعد ذلك إذا حاولنا خلط الأدوات بين مستوى المشروع. ومع ذلك ، ربما يكون السيناريو المفيد هو الحصول على مخطط جانت للمشروع ككل (مشروع تنبؤي) واستخدام لوحات كانبان لمراحل المشروع عند الاقتضاء. على سبيل المثال ، في مشروع البناء ، يمكننا استخدام لوحات Kanban لمراحل العمل التي تحتوي على عدد أقل من التبعيات ونتائج مماثلة. بعض خطوات التصميم مناسبة لهذا الغرض.
ومن المثير للاهتمام ، أن بعض أدوات التخطيط تدعم كلا العرضين لنفس مجموعة البيانات ، مما يعني أنه يمكنك تخطيط مشروعك معهم وتصورهما كمخطط جانت ولوحة كانبان. فهي مفيدة جدا لمثل هذا المزيج.