نستمر في الفروق الدقيقة للتنمية رشيقة التي تحدث في الممارسة. كيف نفهم ما إذا كان يتم تطبيق Agile بشكل صحيح ، ما هي الممارسة المناسبة لأي مهمة والصناعة ، فمن الذي يجب على الشركة نقل العمل إلى "Agile-rails"؟
يواصل فاسيلي سافونوف ، مدرب Agile Coach ScrumTrek ، مشاركة تجربته مع محرري
مدونة Mail.Ru Cloud Solutions .
في آخر مرة ، تحدث فاسيلي عن ماهية أجيل ، والمنهجيات التي يتضمنها ، والقوالب النمطية التي تشكلت حوله. الآن دعنا نتحدث عن تنفيذه.
عن شركات رشيقة
- هل هناك "تفضيلات الصناعة" في منهجيات مرنة؟كما تشير
دراسة Agile Russia ، التي أجريناها للسنة الثانية على التوالي ، إلى أن Scrum يستخدم بشكل رئيسي في تطوير البرمجيات ، و Kanban في المؤسسات المالية ، وكلاهما في صناعة الاتصالات.
باعتباري شخصًا قام بتحليل البيانات التي تم جمعها مباشرةً ، وعمل مع العديد من المشاركين ، أعتقد أن حالة الأشياء هذه ترجع إلى سببين:
- معدل التغير في تكنولوجيا المعلومات أعلى بكثير منه في التمويل. لذلك ، يفضل Scrum هناك كنهج يسمح ، نظرًا للتجارب السريعة ، بالتحكم المرن في الأولويات وتغيير الاتجاه اعتمادًا على التغييرات في البيئة الخارجية والظروف عند المدخل. التمويل أكثر محافظة.
- تكلفة خطأ في التمويل أعلى بكثير من تطوير تكنولوجيا المعلومات. لذلك ، فهي أكثر قيمة Kanban ، استنادا إلى الرياضيات ، بدلا من التجريب ، والسماح من خلال تغييرات صغيرة ولكن ثابتة لتحسين سير العمل ككل.
الاتصالات Kanban مناسبة أيضا. إذا كان ذلك فقط لأن ناقل تطوير الصناعة هو الرقمنة. ومع ذلك ، قليل من الناس يفهمون كيف ينبغي أن يبدو بالضبط. بالإضافة إلى ذلك ، في مجال الاتصالات ، يقع الجزء "السريع" من العمل (تطوير البرمجيات) بجوار الجزء "البطيء" (دعم وتطوير البنية الأساسية للأجهزة). لذلك ، إلى جانب التجارب التي أجريت على Scrum ، من المنطقي تسريع العمليات الحالية باستخدام Kanban.
ممارسات التنمية رشيقة المعتمدة في مختلف الصناعات. المبالغ لا تساوي 100 ٪ لأنه يمكن اختيار أكثر من عنصر واحد. صورة / سكروم تريك- وماذا عن مطوري الأجهزة المحمولة؟ هل لدى أجيل تفاصيل في تطوير الأجهزة المحمولة؟من وجهة نظري ، تتمثل الصعوبة الرئيسية في تطوير تطبيقات الهاتف المحمول في تحديد متطلبات التطبيق ، لأنه قد يكون من الصعب تحديد أصحاب المصلحة. يمكن التغلب على هذه الصعوبات باستخدام تطوير العملاء للبحث عن احتياجات العملاء و Scrum لاختبار فرضيات المنتج بسرعة.
تنمية العملاءتنمية العملاء ، custdev ، والعرف ، وتنمية العملاء (مثيرة للاهتمام ، هل يقول أي شخص ذلك؟) - هذا هو نهج لإنشاء منتج من خلال الاختبارات المستمرة في السوق الحقيقي والتحسين على أساس نتائج هذه التجارب. وبذلك يرتفع العرف إلى الأسلوب العلمي ، مما يجعل المنتج "سليمة علميا".
يعد CustDev واحدًا من عناصر منهجية Lean Startup ، والتي ، بدورها ، تعد واحدة من مقاربات Agile لتصنيع المنتجات.
بشكل عام ، تتوافق Agile بشكل جيد مع تطوير الأجهزة المحمولة: فهي تتطلب رد فعل سريع ومشاركة وعمل منسق من مختلف المتخصصين ، والقدرة على تقديم النتيجة بسرعة وتغييرها إذا لزم الأمر.
بالإضافة إلى Scrum ، يمكنك هنا التركيز بشكل مباشر على أساليب تطوير الأجهزة المحمولة. على سبيل المثال ، يعتمد Mobile-D على XP و Crystal و RUP - تعتبر الأساليب قديمة جدًا ومتينة. الفرق الرئيسي بين Mobile-D و Scrum: وجود مراحل واضحة والتركيز الرئيسي على الجانب الهندسي لتطوير المنتج. بينما تولي Scrum المزيد من الاهتمام لإدارة المنتج وتسليمه ، تركز Mobile-D على عملية التصنيع وتتضمن ممارسات XP التي تعمل على تحسين جودة المنتج النهائي بشكل كبير. في الوقت نفسه ، يؤثر تأثير RUP ، وبالتالي فإن العملية رسمية تمامًا.
ومن الأساليب الأخرى الأكثر حداثة لتطوير الهواتف المحمولة
SLeSS ، حيث تجمع بين Scrum و
Lean Six Sigma . أولاً ، ينفذ إعداد سير عمل Scrum ، ثم يطبق نهج Lean Six Sigma لإدارة الجودة الإحصائية. يبدو لي أن SLeSS يجمع بين المرونة اللازمة وآليات اتخاذ القرارات المستنيرة على أساس الإحصاءات.
في الوقت نفسه ، لا يحظر دليل Scrum مبدئيًا تضمين أي نُهج وأدوات أخرى في سير عمل Scrum قد تكون مفيدة لتطوير المنتج. لذلك ، كل ما سبق يمكن تنفيذه في إطار Scrum "الكلاسيكي".
- ما مدى مرونة منهجيات التعديل في ظل ظروف معينة؟ينبغي النظر بشكل منفصل سكروم و كانبان.
Scrum هو إطار عمل ، أي إطار عمل ، وكل عناصره مطلوبة: الأحداث والأدوار والتحف. لا شيء يمكن أن يلقى بعيدا. ولكن لا توجد متطلبات صارمة بشأن كيفية تنفيذ هذه العناصر بدقة - كما تفعل. لا يحظر Scrum إضافة عناصر جديدة: الاجتماعات والتحف والأدوار التي تحتاجها للعمل والمساعدة في تسريع العملية.
كانبان هي مجموعة من الأدوات والمقاييس. لا يقدم إعدادات صارمة حول الأدوات والأدوات التي يجب استخدامها بالضبط ، حيث إنها مصممة من أجل تغيير تطوري طويل في النظام الحالي. ولكن في الوقت نفسه ، يتم تحديد نجاح Kanban من خلال جمع البيانات حول عملية العمل وتحليلها المنتظم. إذا لم يتم ذلك ، فمع مرور الوقت سوف ينتهي كل شيء ولن تحدث أي تحسينات أخرى. لكن لا بأس بذلك: كما قال إدوارد ديمينج ، لست مضطرًا إلى التغيير ؛ فالبقاء على قيد الحياة أمر تطوعي.
- ما هي الأخطاء النموذجية في التكيف سكروم يجعل الأعمال التجارية؟الخطأ الرئيسي في تنفيذ المنهجيات المرنة هو استخدام الأدوات دون فهم سبب استخدامها على وجه التحديد.
على سبيل المثال ، في المؤسسات الكبيرة ، عند تنفيذ Scrum ، غالبًا ما يعيدون تسمية مدير المشروع كمالك للمنتج ، وفريق المشروع في فريق Scrum ويبدأون في المطالبة بإعطاء النتيجة النهائية في غضون أسبوعين. لكن هذا لا يعمل ، ولسبب بسيط للغاية: الشروط لم يتم الوفاء بها والتي بموجبها
يمكن لـ Scrum
العمل .
- على الرغم من أن مدير المشروع أطلق عليه اسم مالك المنتج ، إلا أنه لم يحصل على السلطة اللازمة وبالتالي لا يحق له صياغة رؤية المنتج أو تغيير أولويات التنفيذ. كما كان من قبل ، فهو مضطر لتنسيق كل خطوة له مع القيادة ويتم تثبيته في إطار متطلبات توقيت وحجم العمل. لذلك ، ظلت سرعة صنع القرار كما هي. لا تسارع أو التكيف مع الظروف المتغيرة.
- على الرغم من أن فريق المشروع كان يسمى فريق Scrum ، إلا أنه لا يزال من الممكن إدراج الأشخاص المشمولين فيه في كل قسم وتقديم تقارير مباشرة إلى المديرين التنفيذيين. وفقًا لذلك ، يقوم كل عضو في الفريق أولاً وقبل كل شيء بما يعهده إليه مديره المباشر ، وليس مالك المنتج. نتيجةً لذلك ، ستكون مهام المنتج أقل أولوية دائمًا ، مما يعني أن سرعة تنفيذ المنتج ، والتي "تم تجميع" فريق Scrum من أجلها ، لن تزيد على الإطلاق.
- على الأرجح ، كما كان من قبل ، سيكون أعضاء الفريق مشغولين في المشاريع الأخرى. بينما ينص Scrum مباشرة: يجب تخصيص أعضاء الفريق لفريق Scrum بنسبة 100٪ من وقت عملهم ، والتعامل فقط مع المنتج الذي يؤديه مالك المنتج الخاص بهم. إذا كان الناس "مقسومين على النسب المئوية" بين المشاريع / المنتجات ، فسوف يقومون بالتبديل بينها ، مما يقلل بشكل كبير من المشاركة وكفاءة العمل في كل مشروع / منتج محدد.
هذا "التنفيذ" غير الكفء له العديد من النتائج السلبية ، لكنه يبدأ بمحاولة لإعادة إنتاج الميكانيكا ، ولكن ليس جوهر سكروم. تم وصف الأخطاء الرئيسية في تنفيذ Scrum بالتفصيل في تقريري "
Stop Signals for Agile " في مؤتمر CodeFest 2017.
- كيفية تقييم كيفية تطبيق منهجيات مرنة مرنة في الشركة؟يوجد اختبار
Scrum Open ، لكنه يعد بمثابة اختبار للمعرفة النظرية. ما يحدث في الممارسة العملية ، وقال انه لا يسمح لفهم. بالنظر إلى أن أساس Scrum هو العمل الجماعي ، وأولويته هي سرعة تسليم المنتج والقيمة للمستهلك ، فإن
360 دراسة استقصائية هي الأنسب. لذلك فمن الأكثر موثوقية تحديد درجة نضج الفريق ورضا العملاء.
نستخدم المنهجية الخاصة بنا ، والتي تم تنفيذها في
خدمة أداة تشخيص ScrumTrek . إنها تعمل من هذا القبيل. يُطرح على الفريق والأطراف المهتمة بالخارج سلسلة من الأسئلة حول كيفية تقييم مستوى تفاعل الفريق ، والتخطيط لعملهم ، وقيمة النتيجة المقدمة للعميل ، والتفاعل مع الفرق الأخرى ، وما إلى ذلك. لكل معلمة ، يتم حساب متوسط الآراء وبناء مخطط دائري معقد - الرادار ، الذي يعرض الشكل من داخل الفريق ومن الخارج.
رادار ScrumTrek. نحن ننظر إلى مبعثر التصنيفات
رادار ScrumTrek. نحن ننظر إلى المتوسطاتيحتوي الرسم على الكثير من المعلومات المفيدة.
- تعد التقديرات الذرية للأفراد ومتوسطاتها مثيرة للاهتمام في حد ذاتها ، وليست هناك حاجة إلى تفسيرات هنا.
- مبعثر التصنيفات في فريق هو شيء مثير للاهتمام. عندما يكون الحجم كبيرًا جدًا ، هناك سبب للاتفاق على ما نعنيه كفريق واحد من جانب واحد أو آخر من جوانب عملنا. ماذا نعني بـ "قيمة العميل" ، على سبيل المثال؟ وماذا عن "سرعة التسليم"؟ يشير الفرق الكبير إلى أن الفريق لم يشكل موقفًا واحدًا في عدد من المشكلات.
انتشار صغير يشير إلى توافق الآراء والعمل الجماعي الجيد.
- يتم تصنيف التقييمات. يمكنك أن ترى أن كل شيء على ما يرام مع الثقافة ، ولكن الإنتاجية تغرق في بعض الأماكن. فمن الواضح أين "حفر".
- يعد الفرق بين التقييم داخل وخارج الفريق أحد أهم المؤشرات ، فهو يُظهر الفروق بين توقعات العملاء والأطراف المعنية الأخرى من الفريق وكيف يدرك الفريق نفسه. تدور Agile حول التفاعل الوثيق بين رجال الأعمال وأولئك الذين يبيعون المنتج ، وبالتالي فإن هذه التناقضات هي سبب ممتاز "للتحقق من عقارب الساعة" بين هذين المجالين والاتفاق على كيفية إعادة هيكلة الفريق.
بعد جمع البيانات ، يتم إجراء تحليل للمخطط بالضرورة بمشاركة الفريق بأكمله وأصحاب المصلحة. كل شيء لنوضح لهم كيف يبدو عمل الفريق من زوايا مختلفة ، ومعالجة نتائج التحليل في خطوات ملموسة لتحسين العمل.
حول سكروم فرق التنفيذ
- من الذي ينبغي أن تبدأ الشركة في تنفيذ منهجيات التطوير الرشيقة؟تنفيذ Scrum يأتي دائمًا من هدف العمل. لذلك ، يجب أن يكون العميل أول من يفكر في التسارع - داخليًا أو خارجيًا. ثم تحتاج إلى معرفة مفهوم المنتج بحيث يمكن القيام به بشكل متكرر. وعندها فقط تشكيل فريق. سكروم من أجل سكروم لا يعمل. علاوة على ذلك ، قد يكون حل مشكلات معينة باهظ التكلفة.
من سيكون "دليل الرشيق" في الشركة هو السؤال دون الإجابة الصحيحة الوحيدة. رأيت المدير الفني يصبح "المحرض" على التغيير. كانت هناك حالات عندما جاءت المبادرة من العمل ، وحتى رأيت كيف نشأت هذه المبادرة "من الأسفل". كل هذا يتوقف على طاقة ودوافع الشخص ، على ما إذا كان سيتمكن من تضمين رؤيته للتنمية باستخدام مناهج مرنة في سياق الأعمال التجارية للمنتج أو الوحدة.
مثالية عندما تأتي المبادرة من الإدارة العليا. التقدم في هذا الاتجاه ملحوظ في السوق الروسية.
- ما الأدوار والوظائف الجديدة التي تنشأ في منظمة أو فريق مع إدخال منهجيات مرنة؟ أي منهم مطلوب ، والتي هي اختيارية؟في حالة سكروم ، هذه هي أدوار سكروم ومالك المنتج وفريق التطوير. كل منهم مطلوب. يعتبر فريق التطوير أيضًا "دورًا" ، لأنه لا يجمع بين المطورين فحسب ، بل أيضًا كل من يحتاج إلى ظهور المنتج من حيث المبدأ: المحللين والمصممين وما إلى ذلك.
قد يكون لدى Scrum-master ومالك المنتج مساعدين يتولون جزءًا من واجباتهم ، بينما تظل المسؤولية عن النتيجة على Scrum-master أو مالك المنتج.
غالبًا ما يكون
مالك المنتج شخصًا من الشركة. ولكن ليس بالضرورة: دعنا نقول ، إذا قمنا بإنشاء نوع من الحلول الهندسية للإنتاج ، يمكن أن يؤدي هذا الدور كبير المهندسين. في النهاية ، هذا هو الشخص الذي يفهم أفضل شيء بالنسبة للمستهلك الذي نصنع المنتج منه ، والمشاكل التي يحلها في المقام الأول ، وكيف ينبغي بناء الأولويات عند إنشائه. من المهم جدًا أن يتمتع مالك المنتج بسلطة تحديد تركيبة المنتج بشكل مستقل بناءً على بيانات من السوق ومن المستهلك. يجب أن يكون له الحق في قول لا للأطراف المعنية التي يتفاعل معها. هذا ضروري حتى يتم الاتفاق على الأولويات واتخاذ القرارات على الفور.
Scrum-master هو الشخص الذي تتمثل مهمته في إنشاء فريق قوي وموحد ومسؤول ومنظم بشكل مثالي. المهم
ليس قائد الفريق ، وليس قائد. لا يُسمح لـ Scrum-master بتقديم التوجيه أو التدخل مباشرة في تطوير المنتج. وهو المنظم والميسّر والمدرب والممارس الرشيق. في تجربتي ، يأتي أفضل أساتذة Scrum من مديري المشاريع - بشرط أن يكونوا قد تدربوا وتمكنوا من الانتقال من تنسيق التوجيه إلى تنسيق التدريب.
تدريب أسلوب التواصلأسلوب التدريب في التواصل هو عندما نتواصل مع الناس على قدم المساواة. نحن لا نعتبر أن الأشخاص المستقلين الكبار بدوريًا هم الأجنحة التي يجب الإشراف عليها ، لكن نحاول تشجيعهم على البحث بشكل مستقل عن حل للمشكلة. وفقط إذا وصلوا إلى طريق مسدود - فإننا نتدخل ونساعد في خبرتنا. بمعنى آخر ، في أسلوب التدريب في التواصل ، يتم استبدال نهج التوجيه بأسلوب التفويض.
مثال يأتي المرؤوس إلى القائد ، ويقول: "لا يمكنني اختيار واحد من الأفضل من خياري التطبيق. أنت تقرر! "
إذا كنت تستخدم أسلوب التدريب ، فسيبدأ المدير في طرح الأسئلة: لماذا اخترت هذين الخيارين؟ ماذا بدأت من؟ ما هي الصعوبة بالنسبة لك في الاختيار بينهما؟ من آخر يمكنه مساعدتك؟ و هكذا. من خلال الأسئلة ، يساعد المدرب الأول الشخص على استكشاف الخيارات الممكنة. نتيجة لذلك ، يفهم الشخص بالفعل ما هو أفضل من فعله ، وسيكون على القائد الاتفاق فقط على المواعيد التي سيأتي فيها المرؤوس ويخبره بما حدث.
الخطوة التالية بعد الوفد هي البصر. في نهج المصادقة ، يصل الموظف أو الفريق إلى هذا المستوى من النضج والمسؤولية ، بحيث لا يقدم الرئيس سوى بيان المستوى الأعلى للمشكلة من وجهة نظر العمل. موظف أو فريق ينظر بشكل مستقل في الحلول ، ويقيم المواعيد النهائية ، ويحدد المخاطر. المدير ببساطة يؤيد كل هذا ، ربما - يضيف شيئًا من وجهة نظر خبراته ويقوم ببعض التعديلات. ثم يتفقون على المعالم عندما يكون من الضروري إظهار النتائج. علاوة على ذلك ، يتحمل الموظف أو الفريق المسؤولية الكاملة عن تنفيذ النتائج وعرضها. في نهج المصادقة ، يعمل الرئيس فقط كمنسق ومساعد لموظف أو فريق كجزء من تنفيذها لمهمة العمل.
الحديث عن أسلوب التدريب في التواصل. هناك أيضا
مدرب رشيق . تتمثل مهمته في إعداد سير العمل ، وتثقيف الناس ومنحهم الأدوات اللازمة للأنشطة اليومية داخل Agile. بما في ذلك أدوات حل الصراع. كل شيء آخر هو خارج نطاق اختصاصها. من الناحية المثالية ، ينبغي أن ينشئ مدرب Agile فريقًا أو إدارة حتى يعمل كل شيء بمفرده ولا يلزم وجود مدرب Agile.
ترتبط الفترة الانتقالية دائمًا بعدم الراحة. تم تصميم Agile-coach لمساعدة الفريق على المضي قدماً في هذه الفترة بأقل قدر من الاحتكاك وتطوير أساليب عمل جديدة مريحة وملائمة.
عند القياس ، يمكن تقديم أدوار إضافية ، كما هو موصوف ، على سبيل المثال ، في
إطار عمل SAFe ، لكنها لا تزال تستند إلى شروط ومبادئ عمل Scrum-master أو مالك المنتج: تظهر مستويات التسلسل الهرمي المتعلقة بالمنتج ببساطة.
آمنيعد SAFe ، أو إطار
Scaled Agile Framework ، هو إطار استخدام Agile في فرق تطوير البرمجيات الكبيرة. في أبسط عملية تنفيذ ، يتضمن النهج مستويين: الفريق والبرنامج (الفريق والبرنامج ، على التوالي) ؛ نظرًا لأن الهيكل التنظيمي والمنتج يصبحان أكثر تعقيدًا ، تتم إضافة الحافظة والحلول الكبيرة إليهما. يعتمد العمل على SAFe على كيان مثل ART (قطار الإصدار الرشيق) - "قطار الإصدار". وكقاعدة عامة ، فإنه يوحد العديد من الفرق والأطراف المهتمة في هيكل يقوم معًا لفترة طويلة بإنشاء منتج أو جزء من منتج ذي قيمة للعميل.
- كيف يتم التمييز بين وظائف مالك المنتج و Scrum-master "في عالم مثالي"؟على جانب واحد من المقياس ، تكمن اهتمامات العمل الذي يمثله مالك المنتج ، من ناحية أخرى ، حيوية وفعالية الفريق الذي يتحمل مسؤول Scrum المسؤولية عنه. لكي يحقق الفريق النتائج بسرعة ، يجب أن يكون النظام متوازنًا. إذا كان مالك المنتج "يقرص" ، فسوف يعمل الفريق ليال وعطلة نهاية الأسبوع ، وسيواجه قريباً حفنة من الأشخاص الذين ينشطون في الحركة ، وليسوا منخرطين بدلاً من فريق جيد التنسيق. إذا قام Scrum-master بسحب البطانية فوق نفسه ، فلن يكون التطوير مهتزًا ولا مسطحًا ، مع نزاعات مستمرة وأطول من اللازم.
مثالحتى لا يكون هذا مجرّدًا ، فهناك مجهر ميكرويالوغ داخلي داخل الفريق. انظر ماذا يقول كل من أدوارها:
مالك المنتج : هكذا! سنحتاج إلى جعل هذه الميزة! لقد قمت بعمل رائع في سباق العدو الأخير ، لذلك أعتقد أنه يمكنك فعل كل شيء!
سكروم ماستر : لكن في السباق الأخير ، وهو سمة من التعقيد الذي قدمه الفريق إلى الحد الأقصى ، اضطررت للذهاب في عطلة نهاية الأسبوع ، وعمل البعض في الليل. سباق آخر من هذا القبيل - وسيبدأ الناس في المرض ، والحروق ، وربما تبدأ النتيجة. دعونا لا نجلبه إلى هذا؟
مالك المنتج : هل هو حقًا شديد الخطورة؟ إذا كان الأمر كذلك ، فلنناقش مع الفريق ما الذي يمكن عمله للسباق دون إحراق الناس. تحتوي هذه الميزة على جزء يجب القيام به ، ولا يبدو معقدًا للغاية.
سكروم ماستر : دعونا نناقش مع الفريق. أنت تعرف أنها فقط يمكنها أن تقول ما إذا كان الأمر "صعبًا" أم لا.
مالك المنتج : هيا.
- ما هي المنهجيات والنماذج الإدارية التي تستحق إتقانها لأولئك الذين سيضطلعون بأحد الأدوار الموصوفة سابقًا؟فيما يتعلق بالكفاءات التجارية ، كل شيء "وفقًا للكلاسيكيات" ، كما هو الحال مع الإدارة العادية ، باستثناء الحاجة إلى تحديد الأولويات على مراحل والتفاعل بشكل أوثق مع الفريق.
يجب أن يتعلم
مالك المنتج " بدء التشغيل اللين" وتطوير العملاء والنُهج الحديثة الأخرى لإنشاء المنتجات.
بالنسبة إلى
Scrum-master ، فإن نطاق الكفاءات أوسع: التيسير ، وإدارة النزاعات ، وديناميات المجموعة ، والتدريب ، وبالطبع الممارسة الرشيقة. بدلاً من ذلك ، فهذه مهارات من مجال علم النفس ، وبالتالي فإن افتقادهم يتم الشعور به عند تدريب المديرين.
- هل الملكية الجماعية للرمز تقلل حقًا من اعتماد الشركة على مطوري "النجوم"؟ هو الدافع السقوط؟ملكية الشفرة الجماعية ممكنة بدون منهجيات مرنة. ما يكفي من اتفاقيات مراجعة التعليمات البرمجية والقواعد الرسمية الأخرى ، ويمكن للمطورين التصرف بشكل تلقائي.
غالبًا ما تثير الشركة نفسها سلوك "ممتاز" للمهندسين: للوهلة الأولى ، من المربح لها أن تتفوق على اختصاصي فائق وتكلفه بتوجيه كامل مع المسؤولية الكاملة عن النتيجة بدلاً من تجميع فريق من الفلاحين المتوسطين ، وتقليل المخاطر الناتجة عن الأخطاء بشكل منهجي.
هذه معضلة: إما نجاح قصير الأجل أو طويل الأجل. يبدو أن توظيف "نجم" مفيد للأعمال. ولكن ماذا سيحدث في ثلاث سنوات ، خمس ، سبع سنوات بعد انضمام هذا المؤيد للشركة؟ سوف يصبح لا غنى عنه. ومع ما لا يقل عن ثلاثة عواقب سلبية.
أولاً ، ليس لدى هذا الشخص
وقت فراغ تقريبًا ، ولا تهتم الشركة إلى حد كبير. منطقها: "نحن لا ندفع لك راتبًا كبيرًا حتى تتمكن من الراحة". الانخراط في موقف مشابه ، يحترق الناس بسرعة ، ويسقطون في السخرية ويحاولون الاستفادة القصوى من وضعهم.
-, . , , , .
: , , , , . , .
-,
«» . , : , «», «» . : , , .
— , - ?- , «»: . .
- . , , .
- «» , , , , . . . , , .
- «». «» , «- ». Scrum-, «», , «» , , . , , «».
, , . , « ». , , « » . , «
. - ».
Mail.Ru Cloud Solutions .