في هذه المقالة ، أريد أن أشارك القليل من الخبرة فيما يتعلق ببناء فرق في مشاريع تكنولوجيا المعلومات. أريد أن أتحدث عن شيء ليس واضحًا دائمًا باسم "هرم نضج الفريق".
هذا المؤشر ليس مصطلحًا علميًا صارمًا ولا يحتوي على صيغ حسابية دقيقة ، ولكن تم وضع مبدأه جيدًا في الاسم نفسه.
يتكون الفريق النموذجي في المشاريع المتوسطة والكبيرة من عدة مشاركين: مدير المشروع ، محللي الأعمال ، المطورين ، المختبرين ومهندسي العمليات. في كل اتجاه يوجد عادة عملاء متوقعون - كبار الموظفين في الاتجاه ، على سبيل المثال ، مهندس تطوير رائد ، مهندس اختبار رائد ، وما إلى ذلك.
إذا قمنا بتصوير هيكل مثل هذا الفريق في شكل هرم مع انعكاس لتجربة الموظفين وتأثيرهم على صنع القرار ، فسوف نحصل على هذا الهرم:
حصلنا على نوع من "هرم ماسلو للفريق". ولكن لا تنسى أن مشاريع تكنولوجيا المعلومات لا تملك مهندسين فقط. على سبيل المثال ، يمكن تقسيم المطورين إلى Junior / Middle / Senior والله يعرف كيف ، اعتمادًا على خبرة العمل والمعرفة (أو على مخيلة صاحب العمل).
يحدث أن يكون لشخص ما لقب منخفض ، ولكن من خلال الخبرة والمعرفة ، يكون هذا الشخص قادرًا على أداء دور مهندس الحلول (ولكن نظرًا للظروف ، لا يؤدي هذا الدور). من الواضح أن هؤلاء الأشخاص يؤثرون على عملية صنع القرار داخل الفريق ، حتى بدون تولي مناصب رسمية في المشروع. ومثل هؤلاء الناس بحاجة إلى رفع إلى الخطوة الثانية في الهرم لدينا. من المهم عدم وجود أشخاص في المستوى الثاني أكثر من المستوى الثالث.
يمكنك تعيين قدر معين من "المن" لكل عضو في الفريق ، اعتمادًا على الخبرة والتأثير على صنع القرار. على سبيل المثال ، سيتلقى أعضاء الفريق ذو الترتيب والملف نقطة واحدة ، عملاء متوقعين ومدراء 2 نقطة.
تخيل أن لدينا فريقًا مكونًا من 15 شخصًا ، فسيتم اعتبار الهرم النموذجي كما يلي:
1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 ptsوحصلنا على هذا الهرم:
حسنا ، أنت تقول ، هذا هو بالضبط الطريق أو لا في مشروعنا وكل شيء على ما يرام معنا. وما هي النتيجة العملية لهذا؟
يسمح لك تقييم فريق باستخدام هذه الطريقة بفهم شيئين: مدى قابلية الإدارة (مستقرة) لفريق حالي ومدى غرابة مدى راحة الجميع للعمل في مثل هذا الفريق.
في الواقع ، والأهم من ذلك ، ما يحدث عندما يصبح هرم النضج في الفريق رأسا على عقب. أو عندما تصبح مسطحة أو متوازية أو أي شيء آخر. وهذا سيناريو سيء للغاية.
الهرم الصحيح مستقر للغاية ، لكن الهرم المقلوب ليس كذلك. يمكنك أن تتذكر التجربة الخبيثة مع مستعمرة "البجعة البيضاء" حيث كانت بعض السلطات الجنائية تجلس وكيف انتهت بالنسبة لهم.
وإذا لم تحيد عن قطاع تكنولوجيا المعلومات ، فيمكنك تخيل موقفين حقيقيين:
- يقترحون جعل مدير المشروع الفعال رخيصًا ومبهجًا - توظيف 30 "هنديًا" وتقديم المشروع في شهر بدلاً من ستة أشهر ؛
- يقوم عميل مهم جدًا بإجراء المقابلات مع جميع المهندسين باستثناء أولئك الذين يحملون ألقاب كبار أو كبار.
في الحالة الأولى ، نحصل على "لبنة" بدلاً من هرم ومشروع لا يمكن السيطرة عليه بوضوح بنهاية حزينة.
في الحالة الثانية ، نحصل على نفس مستعمرة "البجعة البيضاء" في المشروع. هذا هو عندما يجتمع الأشخاص المحترمون وذوي الخبرة في غرفة واحدة وفي غضون ساعتين لا يمكن التوصل إلى حل بسيط. فقط لأنهم جميعًا يتمتعون بالخبرة والهدوء ، يريد كل منهم التحدث علنًا ويعتقد أن فكرته جيدة. بمعنى مثل هذه المحادثات عادة ما تكون صغيرة جدا. بالإضافة إلى ذلك ، من غير الواضح من يجب أن "يرفع الصابون" ، هذا هو ، من ينبغي أن يرى هذه الميزة؟
في مسيرتي كانت هناك مشاريع مع مجموعة من الناس في فرق وأقول بصراحة إن العمل في الإصدارين الأول والثاني ليس مريحًا للغاية. كل من المدير والموظف العادي. عندما يكون لدى الفريق الكثير من الأشخاص الأذكياء ، يصبح الأمر غبيًا. الهرم يصبح غير مستقر وغالبا ما "يسقط" سحق مهمل.
في الواقع ، كل شيء بسيط ، يجب أن يحتوي مشروع تكنولوجيا المعلومات على عدد كاف من المهندسين الذين يقومون بالعمل ويستفيدون ولا يطرحون أسئلة. بدون وجود عدد كافٍ من هؤلاء الأشخاص ، فإن المشروع ببساطة لا يملك "قوة حصانية" كافية ولا يفرض ضرائب على مستقبل سعيد.
الوضع العكسي هو عندما يكون لديك الكثير من "القدرة الحصانية" وقليل من التحكم ، عندها ستتحطم سيارة السباق الخاصة بك ببساطة على السياج الأول.
العدد المثالي للأشخاص في فريق تكنولوجيا المعلومات هو 5-15 أشخاص. قام أمازون بيزوس بتجميع هذا كمبدأ "فريق بيتزا اثنين". زيادة أخرى في عدد الأشخاص تعقد الاتصال داخل الفريق ولم يعد لها تأثير مضاعف.
التوزيع المثالي لأعضاء الفريق حسب النضج هو لكل عميل من 2 إلى 5 مهندسين من المستوى المتوسط. إذا كنا نتحدث عن مهندسين
مبتدئين أو عن
فاسيلييف - فلا ينبغي أن يكون هناك أكثر من 1-2 لكل عميل (أو الشخص المسؤول عنهم). فقط لأنه غير قادر جسديًا على الانتباه إلى المزيد من الأشخاص. يمكن أن تستغرق مراجعة الكود الابتدائي لـ 5 أشخاص بالفعل نصف وقت العمل. بالإضافة إلى ذلك ، لا يزال القادة يعقدون جميع أنواع الاجتماعات مع الفرق الأخرى والعملاء ، بحيث لا يستطيع القيام بالعمل بنسبة 100 ٪ من الوقت كمهندس منتظم.
أي يمكننا القول أنه داخل هرم نضج الفريق ، يجب أن نبني أهرامات صغيرة من فرق فرعية منفصلة لمزيد من الاستقرار.
بالنسبة للمستوى العلوي من الهرم - ليس من الأهمية بمكان عدد الأشخاص الذين لديك في القمة ، إذا كان لديك مستويين منخفضين مناسبين - فسيقومون بإخراج المشروع بالكامل. الهرم في معظم الحالات لن يكون مثاليا ، لكنه ليس مخيفا. الشيء الرئيسي هو وجود عدد كاف من الناس من أسفل.
لا تأخذ في الاعتبار في هرم المشرفين - أي الأشخاص الذين يقودون اتجاهًا كاملًا ويتحكمون ببساطة في العملية في العديد من المشاريع دون التدخل في الإدارة.
مالك منتج Agile هو جزء من الفريق ، ولكن يجب ألا يتداخل مع عملية الإدارة. إذا بدأ الانخراط في الإدارة المصغرة أو كان لديك على الفور 5 من مالكي المنتجات ، فأنت تواجه مشاكل كبيرة. ولكن هذه هي بالفعل قضايا إدارة المشاريع المختصة وعلاقات العملاء. إذا وقعت في هذا الفخ ، فإن الهرم المقلوب هو بالفعل أصغر مشكلتك.
نقطة أخرى هي عندما يرغب الكثير من الناس في قيادة المشروع ، وأنت ، بصفتك الشخص الوحيد الذي يعمل ، تتذكر عمل Saltykov-Shchedrin ، "كيف قام رجل بإطعام جنديين". أو هذه
القصة . لكن من السهل التنبؤ بمثل هذا الموقف باستخدام "هرم نضج الفريق" وعدم الاستمرار في مثل هذا المشروع.
في شركة مختصة ، ينبغي التخطيط لأشياء مثل تكوين الفريق في وقت مبكر من مرحلة بيع المشروع. ثم يختارون مدير المشروع الذي سيشكل العمود الفقري لفريق العملاء المتوقعين وبمساعدتهم في بناء الأهرامات ومشاريع المنشار والتقاط المجرات.