أصبح SCRUM شائعًا للغاية لدرجة أنهم يحاولون الآن تنفيذه في كل مكان تقريبًا. في الشركات الكبيرة ، يتبين أحيانًا أن SCRUM يتم تنفيذه من أجل إعداد التقارير ، أو من أجل أن يكون "تقدميًا" و "عصريًا". ونتيجة لذلك ، يبدو أن الموقف هو أن المدير المسؤول وضع علامة الاختيار التالية ، كما يقولون ، كان من الضروري تنفيذ المنهجية - لقد فعلها ، أحسنت ، ولكن بدلاً من بعض التحسينات النوعية ، يظهر ما يسمى "Zombie SCRUM" في الإخراج. هذا هو عندما يتم تنفيذ الإطار رسميا ، ولكن لا أحد يعمل بشكل طبيعي على ذلك. ومن هنا الاسم.
اسمي Oleg Egorkin ، أنا مدرب رشيق في Rostelecom ، وسأخبرك في هذا المنشور عن سبب ظهور "zombie scrum" بشكل عام ، وكيفية تجنب ذلك وكيفية التأكد من أن كل شيء جاهز للشركة لبدء فريق scrum.
المناهج الحالية لتشغيل الأوامر
في بعض الأحيان يحاولون إطلاق فريق سكروم في تكنولوجيا المعلومات ، أي من أسفل إلى أعلى. هذا عندما يدرك المطورون أنفسهم ورؤساء الأقسام أن الوقت قد حان ، لهذا المنتج نحتاج إلى ندبة. الإضافة هي أن المبادرة تأتي من الأشخاص في هذا الموضوع. ناقص - مع هذا النهج ، لا تشارك الأعمال. وإذا لم يكن العمل متورطًا ، فإن الهيكل التنظيمي نفسه مع هذا النهج إما يتغير قليلاً جدًا أو (في كثير من الأحيان) لا يتغير على الإطلاق. نتيجة لذلك ، فإن احتمال تحول مثل هذا الطبل إلى "سكروم غيبوبة" مرتفع للغاية. بالطبع ، لن يكون الأمر كذلك في اليوم الأول ، سيكون كل شيء على ما يرام كما يود المرء. ولكن بعد حوالي ستة أشهر ، سوف يدرك الناس أن جميع السلبيات التي كانت عند بدء التشغيل لم تذهب إلى أي مكان. ومن هنا الإحباط الذي يؤثر دائما للأسف المنتج.
هناك قصة عكسية - من الأعلى إلى الأسفل. أيضا ليس الشيء الذي نسعى جاهدين من أجله. على سبيل المثال ، تذكر ، قبل عدة سنوات ، في فجر Agile ، تم إطلاق 50 فريقًا جديدًا في بنك أخضر بناءً على تعليمات من السلطات العليا "بحلول الصيف" ، وبحلول نهاية العام - 5000. هذا هو النهج المتبع في التملص من أجل scrum. ماذا يحدث في هذه الحالة؟ يهرع الناس لتشغيل المهمات. تحت الشاشة ، كل شيء غير مشدود يبدأ بالصف. سكروم في هذه القصة ليس أبدًا تحسينًا في التطوير ومنهجيات جديدة ، إنه مجرد علامة في مؤشر KPI للمدير. والنتيجة هي "سكروم غيبوبة".
وهناك مقاربة ثالثة - المبادرة من أعلى وأسفل بشكل مباشر. كنا محظوظين ، وفي Rostelecom الآن فقط. شيء في ما. على مستوى الإدارة العليا ، هناك مساعدة مستمرة لجميع النهج التحويلية في فرق. في الوقت نفسه ، لا أحد يضع خطط "طموحة".
بالنسبة للشركات الكبيرة والكبيرة جدًا ، هذا ليس مألوفًا تمامًا. إنه يعمل مثل هذا: مرة واحدة كل شهر أقدم تدريب أساسي ليوم واحد على Agile. يأتي كل من موظفي تكنولوجيا المعلومات والأفراد من رجال الأعمال إلى الدورات التدريبية ، و 25 شخصًا في المجموعة. أحاول التحدث عنها على أوسع نطاق ممكن وعلى نطاق واسع. بعد مرور بعض الوقت (قد يستغرق الأمر من أسبوع إلى عدة أشهر) ، يعود الزملاء ، وهضم المعرفة المكتسبة ، مع طلب مفهوم لإنشاء فريق scrum.
حول القائمة المرجعية
هناك نوعان من الطلبات بالنسبة لي - إما لبدء فريق كجزء من تحويل منتج موجود ، أو إلى فريق لمنتج جديد. لمعالجة هذه الطلبات ، كتبت قائمة مراجعة خاصة ، وبمساعدتي أتحقق من كل الشروط اللازمة للتشغيل. إذا لم يمر التطبيق بأي نقطة واحدة ولم يستوف المتطلبات الأولية ، فإننا لا ندير الفريق. هذه حاجة معترف بها - إذا سجلت بصراحة واحدة على الأقل من النقاط وتدير الفريق بدونها ، فإنها لن تحقق نتائج. حسنًا ، إلى جانب حقيقة أن الضعف لا يثبط جميع المشاركين.
إذا جاء لي شخص ما من قسم تكنولوجيا المعلومات مع أحد التطبيقات ، أطلب منه التحدث إلى الشركة والعودة معًا. لأن العمل في Agile عنصر أساسي. من هنا لدينا عنصر القائمة الأولى:
1. فريق رشيق يجب أن ترغب في إنشاء الأعمال التجارية
هنا ، كما هو الحال مع مصاصي الدماء - لا يمكنهم فقط دخول المنزل ودخوله ، يجب دعوتهم. مع المدربين رشيق ، نفس الشيء ، بمعنى أنه يجب طلب التغيير.
يلاحظ الأشخاص من قطاع الأعمال ومن تكنولوجيا المعلومات أن بعض المنتجات تعمل في ظروف السوق الصعبة ، ويتصلون بي بأنفسهم ويقولون - يجب تغيير النهج. وهنا ، إذا كنت محظوظًا للغاية ، فإن الطلب يصل في البداية ، حيث لا يوجد فريق بعد ، ولكن هناك فكرة يمكن بمقتضاها أن يبدأ الناس في التجمع. في الوقت نفسه ، يدرك الجميع أنه لا يمكن تكوين مواصفات واضحة للمنتج ، وسوف تتغير وفقًا لنموذج العمل ، وليس من الواضح أي من النماذج سوف ينجح وأي منها لا يعمل.
بشكل عام ، من المهم للغاية أن تشارك الأعمال.
من المهم أيضًا أن يكون محرك هذه المشاركة أمرًا ملموسًا وليس مجرد ضجيج. لذلك ، أتحقق من أن دوافع العمل تندرج تقريبًا في ما يلي:
- تقليل الوقت اللازم للتسويق إذا كان هذا المؤشر كبيرًا جدًا ؛
- زيادة كفاءة العمل الجماعي ؛
- زيادة الإدارة في مواجهة الأولويات المتغيرة.
إذا كانت أي من هذه النقاط الثلاث صحيحة ، فكل شيء على ما يرام ، هذه علامة أكيدة على أن الفريق يبدأ بتوقعات كافية.
2. يجب أن يكون هناك منتج للإطلاق
أولاً ، هذا منطقي. من السخف تشغيل فريق منتج لمنتج عندما لا يكون لديك منتج. ولا يهم ما نبدأ به جميعًا حوله - حول منتج أو خدمة.
3. يجب أن يكون لدى صاحب المنتج رؤية وخريطة طريق للتطوير
علاوة على ذلك ، فإن خارطة الطريق لمدة عام مقدما هي الحد الأدنى ، في شكل فهم أعلى مستوى لما يجب القيام به بشكل عام. حتى لو كان لدى الشخص 3-5 فرضيات حول نماذج العمل التي سيطبقها ، فما الذي يريد استكشافه. إذا رأيت أن هناك خريطة طريق ، فتابع.
4. يجب أن يكون العمل المال
وهي ميزانية فريق متعدد الوظائف. نظرًا لأنه يجب تعيين المنتج لفريق متفرغ ، ويجب أن يكون العمل جاهزًا لدفع ثمنه في الأفق لمدة عام تقريبًا. أتأكد من أن كل هذا قد تم ، وأنظر إلى أي مركز للمسؤولية المالية يشارك في ذلك ، بحيث لا ينجح وجود فكرة ، وهناك رغبة في إنشاء فريق ، لكن لا يوجد مال.
5. يجب أن يكون صاحب المنتج في العمل
المالك. ليس أصحابها. مالك واحد.
شخص مخلص 100٪ لهذا المنتج المعين. كانت هناك حالة عندما جاء مديران وقالا - نريد إنشاء منتج تحفيزي وتعليمي (مثل هذا الشيء الداخلي للموظفين). أقول لهم - رائع ، ولكن هل لديك مالك منتج؟ يجيبون - نعم ، بالطبع ، مالك واحد للمنتج هو للتدريب ، والآخر - للتحفيز. المنتج تحفيزي وتعليمي.
في ذلك الوقت طلبت التفكير والاتفاق على من سيكون المسؤول عن المنتج بأكمله. تبين أن هذه مسألة صعبة للغاية وتمكن الفريق من إطلاقها بعد ستة أشهر فقط.
منتج واحد - مالك منتج واحد. هذا مهم.
6. يجب أيضًا تخصيص 100٪ للمشاركين في فريق التطوير للمنتج.
إذا كان شخص ما من فريق التطوير يعمل بنسبة 50 ٪ ، 30 ٪ ، 10 ٪ - هذا ليس على الفور. يجب على المرء أن يكون تماما في المنتج. لكن في الوقت نفسه ، لا أطلب حضور فرق مشتركة. في ظروفنا ، هذا أمر نادر الحدوث ، Rostelecom كبير جدًا ، لدينا الكثير من الشركات التابعة والشركات التابعة (الشركات التابعة الفرعية) ، حيث يعمل المطورون المدرجون في الفرق. ويمكن أن تنتشر في جميع أنحاء موسكو وبيتر وكراسنودار وغيرها من المدن في وطننا الهائل. في بعض الأحيان يكون من الصعب واستنفاد الوقت تجميع فريق في موسكو بسرعة ، ولكن في كثير من الأحيان لا يعمل على الإطلاق.
لذلك ، أذهب إلى الأمام ، ولكن هناك مطلب مضاد - وهو أن يجتمع الفريق لليومين الأولين عندما يكون التدريب قيد التقدم ، ثم كل ستة أشهر للحفاظ على الاتصالات الشخصية ومناقشة القضايا الحالية.
7. طريقة الدفع المنتج
هذا أيضًا شيء مهم ، بالإضافة إلى الكثير الذي يرتبط بالمال. عندما يكون لصاحب المنتج ميزانية ، يتم إنفاقه عند الطلب. أي أن المعارف التقليدية مكتوبة بالترتيب ، ويتم إجراء تقييم لتنفيذها ، ثم يتم تخصيص أموال في الميزانية لهذه الحالة. هذا يبدو سهلا. ولكن هناك فروق دقيقة.
عند التبديل إلى العمل المخصص ، في نهاية تنفيذ الطلبات ، يجب أن تكون هناك إجراءات لقبول المنتج ونقله إلى التشغيل. وبما أن المعارف التقليدية قد تمت الموافقة عليها بالفعل ، فمن الصعب للغاية إجراء تغييرات عليها. يجب إعادة التفاوض على أي تعديلات أو الموافقة عليها. هذه عملية معقدة وبطيئة للغاية ، وتتعارض مع رد الفعل السريع للتغييرات.
ماذا فعلنا حتى لا ندفن أنفسنا في هذا وألا نضيع.
يمكنك العمل على Time & Materials عند إبرام العقد ودفع وقت الفريق بأكمله. هذا هو ، هناك فريق يعمل لمالك المنتج. يتم دفع خدماتها شهريًا أو ربع سنوي. لكن في بلدنا لا يمكن القيام بذلك بشكله النقي ، لأن هناك قيود بيروقراطية.
لذلك ، بدأنا العمل كجزء من التطوير المخصص على مستوى الطلبات الفصلية مع تحديد خرائط الطريق (وليس المعارف التقليدية) ، في حين أن الطلب لا يوضح بالتفصيل كيفية تنفيذ خريطة الطريق. صاحب المنتج لديه مرونة توليد تراكم. وعندما ينتهي الربع ، نفرغ من النظام الغذائي قائمة بالمهام المنجزة ، وعلى أساسها نقوم بتشكيل أفعال موقعة ومدفوعة. اتضح نفس الوقت والمواد.
وهنا ليس من الضروري الالتزام بوضوح بالمعارف التقليدية ، لأنه لا يوجد معارف تقليدية. إن المتطلبات التي لم تعد منطقية بعد اختبار الفرضيات لا يمكن أن يتم ببساطة.
8. لا ينبغي أن يكون لدى الفريق أي مؤشر KPI ، باستثناء تلك المرتبطة بالمنتج
إنها مهمة على وجه التحديد لأن المطورين يتم تعيينهم من قبل الشركات التابعة ، حيث يتم استخدام مؤشرات الأداء الرئيسية للإعداد لإعادة التدوير (وهذا هو الوقت الذي يجب أن يكون فيه المطور مشغولًا باستمرار بشيء ما). في الواقع ، يعمل جميع الدمجين تقريبًا مثل هذا - في ظروف النقص في مشروع (أو مشاريع منافسة) للمطور نفسه ، يرسمون على عدة مشاريع. وبعد ذلك ، لكي تكون الشركة في اللون الأسود ، وضعوا المطور في KPI بأنه يجب أن يكون دائمًا 85٪ على الأقل مشغول. بمعنى أنه لديه بالفعل مؤشر KPI معين ، مما يحفزه على أن يتناسب مع الحد الأقصى لعدد المشاريع من أجل تكييف تصرفه مع الأرقام المطلوبة.
لحسن الحظ ، فإن فريق scrum ليس لديه مثل هذه الحاجة (في الواقع هو 100 ٪). أتأكد من أن الفرق ليس لديها مؤشرات أداء رئيسية إلى جانب البقالة.
في المجموع
هذه هي قائمتي المرجعية. وفقًا لذلك ، أتحقق من جميع الفرق قبل البدء ، ولأننا نتبع اتجاهًا مشتركًا ، يمكنني المطالبة بتغيير الظروف إذا لم يمر الفريق بواحدة من هذه النقاط على الأقل. لذلك ، الإخراج هو فقط تلك الفرق التي هي على استعداد لتنفيذ قيم النهج رشيقة.
إذا مر تطبيق الفريق بكل هذه النقاط ، تبدأ المرحلة التالية - تدريب الفريق وإطلاقه.
الذي سأتحدث عنه في المنشور التالي =)