إدارة فريق من المبرمجين: كيف وكيف تحفزهم بشكل صحيح؟ الجزء الثاني

شعار:
الزوج ، عند النظر إلى الأطفال القاتمين ، يقول لزوجته: حسنًا ، ماذا ، نغسل هؤلاء أو الأطفال الجدد؟

تحت القص ، الجزء الثاني من مقالة قائد فريقنا ، وكذلك مدير تطوير منتجات RAS - إيجور مارنات حول ميزات الدافع المبرمج. يمكن العثور على الجزء الأول من المقالة هنا - habr.com/ar/company/parallels/blog/452598




في الجزء الأول من المقال ، تطرقت إلى المستويين السفليين على هرم ماسلو: الاحتياجات الفسيولوجية ، والسلامة ، واحتياجات الراحة والثبات والانتقال إلى المستوى التالي ، وهو:

ثالثا - الحاجة إلى الانتماء والحب



كنت أعرف أن المافيا الإيطالية تدعى "Cosa Nostra" ، لكني تأثرت كثيراً عندما تعلمت كيفية ترجمة "Cosa Nostra". "Cosa Nostra" في الترجمة من الإيطالية - "أعمالنا". يعد اختيار الاسم ناجحًا جدًا في التحفيز (دعنا نتخلى عن المهنة ، وفي هذه الحالة نحن مهتمون فقط بالتحفيز). يريد الشخص عادةً أن يكون جزءًا من فريق ، للقيام ببعض أعمالنا التجارية الكبيرة والمشتركة.

يتم إعطاء أهمية كبيرة لتلبية الحاجة إلى الانتماء والمحبة في الجيش ، في البحرية ، في أي تشكيلات عسكرية كبيرة. وكما نرى ، في المافيا. هذا أمر مفهوم ، لأنك تحتاج إلى إجبار الأشخاص الذين لديهم القليل من القواسم المشتركة ، والذين لم يشكلوا في البداية فريقًا من الأشخاص المتشابهين في التفكير ، الذين تجمعوا معًا عند الاستئناف (وليس طوعًا) ، على مستويات مختلفة من التعليم ، وقيم شخصية مختلفة ، وتكريس حياتهم حرفيًا ، مع خطر مميت ، لسبب مشترك. ، يعهد الحياة إلى رفيق في السلاح.

هذا دافع قوي للغاية ، بالنسبة لمعظم الناس ، من المهم للغاية أن تشعر بأنك تنتمي إلى شيء أكثر ، لمعرفة أنك جزء من عائلة أو بلد أو فريق. في الجيش ، هذه الأهداف هي الشكل والطقوس المختلفة والمسيرات والمسيرات واللافتات ، وما إلى ذلك. حول نفس العوامل مهمة لأي فريق. تعد الرموز والعلامات التجارية للشركات والألوان والسمات والهدايا التذكارية مهمة.

من المهم أن تشتمل الأحداث الهامة على تجسيد مرئي يمكن أن ترتبط به. الآن للشركة أن يكون لها سماتها الخاصة ، والسترات ، والقمصان ، وما إلى ذلك - بدلا من القاعدة. لكن من المهم أيضًا إبراز فريق داخل الشركة. غالبًا ما نصدر قمصانًا بناءً على نتائج الإصدار ، والتي يتم إصدارها لجميع المشاركين في هذا الإصدار. أي أحداث أو احتفالات أو أحداث مشتركة من قبل الفريق بأكمله هي عامل تحفيز مهم آخر.

بالإضافة إلى السمات الخارجية ، هناك عدد قليل من العوامل التي تؤثر على الشعور بالانتماء إلى فريق.
أولاً ، يتم مشاركة وجود هدف مشترك يفهمه الجميع من خلال تقييم أهميته. عادةً ما يريد المبرمجون فهم ما يقومون به بطريقة رائعة ، ويفعلون هذا الشيء الرائع معًا كفريق واحد.
ثانياً ، يجب أن يكون لدى الفريق مساحة اتصال بها فريق كامل ، وينتمي إليها فقط (على سبيل المثال ، محادثة في برنامج المراسلة ، مزامنة فريق دورية). بالإضافة إلى مشكلات العمل ، والتواصل غير الرسمي ، ومناقشة الأحداث الخارجية في بعض الأحيان ، وعلى ضوء ذلك - كل هذا يشكل إحساسًا بالمجتمع وفريق العمل.
ثالثًا ، أود أن أحدد تقديم الممارسات الهندسية الجيدة داخل الفريق ، والرغبة في رفع المعايير مقارنة بالمعايير التي تتبناها الشركة. إن تنفيذ أفضل الأساليب المتبعة في الصناعة ، أولاً في الفريق ، ثم في الشركة ككل ، يمنح الفريق الفرصة للشعور بأنه متقدم على الآخرين بطرق ما ، ويذهب في المقدمة ، وهذا يخلق شعورًا بالانتماء إلى فريق رائع.

تؤثر ملكية الفريق في التخطيط والإدارة أيضًا على الإحساس بالملكية. عندما يشارك أعضاء الفريق في مناقشة أهداف المشروع ، وخطة العمل ، والمعايير والممارسات الهندسية للفريق ، وإجراء مقابلات مع موظفين جدد ، لديهم شعور بالمشاركة ، والملكية المشتركة ، والتأثير على العمل. الناس أكثر استعدادًا لتنفيذ القرارات التي يتم إجراؤها والتعبير عنها بأنفسهم من القرارات التي يقترحها الآخرون ، حتى لو كانت متوافقة عملياً.

أعياد الميلاد والذكرى السنوية والأحداث الهامة في حياة الزملاء - بيتزا مشتركة ، هدية صغيرة من الفريق تعطي شعورًا دافئًا بالمشاركة والتقدير. في بعض الشركات ، من المعتاد إعطاء علامات تذكارية صغيرة لمدة 5 ، 10 ، 15 عامًا من العمل في الشركة. من ناحية ، لا أعتقد أنه محفز للغاية لإنجازات جديدة. لكن من الواضح أن أي شخص تقريبا سيكون سعيدًا لأنهم لم ينسوه. هذه واحدة من الحالات التي يحفز فيها غياب الحقيقة بدلاً من وجودها. توافق ، يمكن أن يكون مؤسفًا إذا قام لينكين في الصباح بتذكيرك وتهنئتك في الذكرى العاشرة لمكان عملك ، وليس زميلًا واحدًا من الشركة قد هنأه أو تذكره.

بالطبع ، هناك نقطة مهمة هي التغيير في تكوين الفريق. من الواضح أنه حتى إذا تم الإعلان عن وصول أو مغادرة شخص ما من الفريق مسبقًا (على سبيل المثال ، في قائمة بريدية لشركة أو فريق ، أو في اجتماع فريق) ، فإن هذا لا يحفز أي شخص بشكل خاص على تحقيق إنجازات جديدة. لكن إذا شاهدت يومًا ما شخصًا جديدًا بجوارك ، أو لم تر شخصًا قديمًا ، فقد يكون ذلك بمثابة مفاجأة ، وإذا غادرت ، فهذا أمر غير سارة حقًا. يجب ألا يختفي الناس بهدوء. خاصة في فريق موزع. خاصة إذا كان عملك يعتمد على زميل من مكتب آخر قام فجأة بالتقاطه واختفى فجأة. من الواضح أن مثل هذه اللحظات تستحق التواصل المنفصل داخل الفريق مقدمًا.

عامل مهم ، والذي يسمى الملكية باللغة الإنجليزية (الترجمة الحرفية "الملكية" لا تعكس معناها بالكامل). هذا ليس شعورًا بالملكية ، ولكنه شعور بالمسؤولية عن مشروعك ، وهو شعور عندما تربط نفسك عاطفياً بالمنتج والمنتج مع نفسك. يتوافق هذا تقريبًا مع صلاة البحرية من فيلم "Full Metal Shell": " هذه بندقيتي. هناك العديد من هذه البنادق ، ولكن هذا واحد هو لي. بندقية بلدي هو أفضل صديق لي. هي حياتي. يجب أن أتعلم امتلاكها بالطريقة التي أملك بها حياتي. بندقيتي عديمة الفائدة بدوني. أنا عديمة الفائدة دون بندقية بلدي. لا بد لي من اطلاق النار بندقية بلدي باقتدار. لا بد لي من إطلاق النار بدقة أكبر من العدو الذي يحاول قتلي. لا بد لي من اطلاق النار عليه قبل أن يطلق النار علي. فليكن ... ".

عندما يعمل شخص ما على منتج ما لفترة طويلة ، تتاح له الفرصة لتحمل المسؤولية الكاملة عن إنشائه وتطويره ، لمعرفة كيف ينشأ شيء عملي من "لا شيء" ، وكيف يستخدمه الناس ، ينشأ هذا الشعور القوي. عادة ما تكون فرق المنتجات التي تعمل معًا لفترة طويلة في مشروع ما أكثر تحمسًا وتوحيدًا من الفرق التي تم تجميعها لفترة قصيرة وتعمل في وضع خط التجميع مع التبديل من مشروع إلى آخر دون المسؤولية الكاملة عن المنتج بأكمله ، من البداية إلى النهاية.

IV. الحاجة الاعتراف

كلمة طيبة ولطيفة على القطة. يحفز الجميع على إدراك أهمية عمله وتقييمه الإيجابي. التحدث مع المبرمجين ، ومنحهم ردود فعل دورية ، ووضع علامة على وظيفة أحسنت. إذا كان لديك فريق كبير وموزع ، فإن الاجتماعات الدورية (ما يسمى بواحد إلى واحد) تعد كبيرة بالنسبة لهذا ، إذا كان الفريق صغيرًا للغاية ويعمل معًا محليًا ، فعادةً ما يتم توفير هذه الميزة دون مواعيد تقويم خاصة (على الرغم من أن الدوري الدوري واحد إلى الكل هناك حاجة متساوية ، يمكنك فقط إنفاقها في كثير من الأحيان). تمت تغطية هذا الموضوع جيدًا في ملفات podcast الخاصة بالمدير على manager-tools.com.

في الوقت نفسه ، يجدر مراعاة الاختلافات الثقافية. بعض الأساليب المألوفة لدى الزملاء الأميركيين لن تعمل دائمًا مع الطرق الروسية. يبدو أن مستوى الأدب المقبول في التواصل اليومي في فرق في الدول الغربية في البداية مفرط بالنسبة للمبرمجين من روسيا. يمكن اعتبار بعض خصائص الاستقامة من الزملاء الروس وقاحة من قبل زملائهم من البلدان الأخرى. هذا مهم جدا في التواصل في فريق دولي ، لقد كتب الكثير حول هذا الموضوع ، مدير مثل هذا الفريق يجب أن يتذكر هذا بالتأكيد.

يعد عرض الميزات التي يبرمج عليها المبرمجون الميزات التي تم تطويرها من أجل الركض ممارسة جيدة لتحقيق هذه الحاجة. إلى جانب حقيقة أن هذه فرصة رائعة لمسح قنوات الاتصال بين الفرق ، لتزويد مديري المنتجات واختبارها بميزات جديدة ، فهي أيضًا فرصة جيدة للمطورين لعرض نتائج عملهم ، للإشارة إلى تأليفهم. حسنًا ، وصقل مهارات الخطابة ، بالطبع ، والتي ليست دائمًا ضارة.

سيكون من الجيد الإشارة إلى المساهمة الملحوظة لزملاء متميزين بشكل خاص مع رسائل وتذكارات (على الأقل بكلمة لطيفة) في الحفلات المشتركة للفريق. عادة ما يقدّر الناس هذه الرسائل والعلامات التذكارية ، ويحملونها معهم أثناء التنقل ، ويعتنون بها عمومًا بكل طريقة ممكنة.

للاحتفال بمساهمة أكثر أهمية وطويلة الأجل في عمل الفريق ، والخبرة والخبرات المتراكمة ، يستخدمون غالبًا نظامًا لتصنيف الدرجات (مرة أخرى يمكنك استخلاص تشبيه مع نظام الرتب العسكرية في الجيش ، والذي ، بالإضافة إلى ضمان التبعية ، يخدم أيضًا لهذا الغرض). غالبًا ما يضخ المطورون الصغار الثأر للحصول على نجوم جديدة على أحزمة الكتف (أي الانتقال من المطور الصغير إلى المطور المتفرغ ، إلخ).

لا بد من معرفة توقعات شعبك. شخص ما بدافع من درجة عالية ، والقدرة على استدعاء ، مثلا ، مهندس ، في حين أن شخص ما ، على العكس من ذلك ، غير مبال الدرجات والألقاب ، وسوف تنظر في زيادة الرواتب لتكون علامة على الاعتراف من قبل الشركة. تواصل مع الناس لفهم ما يريدون وما هي توقعاتهم.

إن عرضًا تقديريًا للاعتراف ومظهرًا لمستوى أعلى من الثقة من جانب الفريق يمكن أن يعمل على توفير قدر أكبر من حرية العمل أو المشاركة في مجالات عمل جديدة. على سبيل المثال ، مع تراكم تجربة معينة ، يمكن أن يحقق المبرمج ، بالإضافة إلى تنفيذ ميزاته وفقًا للمواصفات ، العمل على بنية أشياء جديدة. أو شارك في العمل في مجالات جديدة قد لا تكون ذات صلة مباشرة بالتطوير - أتمتة الاختبار ، وتنفيذ أفضل الممارسات الهندسية ، والمساعدة في إدارة الإصدارات ، والتحدث في المؤتمرات ، إلخ.

خامسا - الحاجة إلى المعرفة وتحقيق الذات.

يتم توجيه العديد من المبرمجين في مراحل مختلفة من حياتهم إلى أنواع مختلفة من الأنشطة في البرمجة. شخص ما يحب المشاركة في التعلم الآلي ، وتطوير نماذج بيانات جديدة ، أثناء قراءة الكثير من الأدبيات العلمية للعمل ، وإنشاء نماذج جديدة من نقطة الصفر. تصحيح الأخطاء ودعم تطبيق موجود أقرب إلى تطبيق آخر ، حيث تحتاج إلى البحث بعمق في التعليمات البرمجية الموجودة ، وسجلات الدراسة ، ومسارات مكدس ، و captcha الشبكة لعدة أيام ، ويكاد يكتب رمز جديد.

تتطلب كلتا العمليتين بذل جهود فكرية كبيرة ، لكن المخرج العملي مختلف. من المعتقد أن المبرمجين يحجمون عن دعم الحلول الحالية ، فمن المرجح أن يكون لديهم الدافع لتطوير حلول جديدة. هناك حبة صحية في ذلك. من ناحية أخرى ، كان الفريق الأكثر تحمسًا وترابطًا الذي عملت معه على الإطلاق هو دعم المنتج الحالي ، والعثور على الأخطاء وإصلاحها بعد الاتصال بفريق الدعم. الرجال حرفيا عاش هذا العمل ، كانوا على استعداد للذهاب يومي السبت والأحد. لقد تعاملنا مرة واحدة عن طيب خاطر مع مشكلة أخرى عاجلة ومعقدة ، إما مساء يوم 31 ديسمبر ، أو بعد ظهر يوم 1 يناير.

تأثر هذا الدافع العالي بعدة عوامل. أولاً ، كانت شركة لها اسم كبير في الصناعة ، انضم الفريق إليها (انظر "Need for Affiliation"). ثانياً ، لقد كانت الحدود الأخيرة ، ولم يكن هناك من يقف خلفهم ، وكان فريق المنتج قد ذهب بالفعل في ذلك الوقت. كان هناك مستوى من الدعم بينهم وبين العملاء ، لكن إذا وصلت المشكلة إليهم ، فلن يكون هناك مكان للتراجع ، حيث لا يوجد أحد وراءهم ، فالمؤسسة بأكملها تقع عليهم (أربعة مبرمجين شباب). ثالثًا ، كان لهذه الشركة الكبيرة عملاء كبيرون جدًا (الحكومات الوطنية ، مخاوف السيارات والطيران ، إلخ) ومنشآت كبيرة جدًا في العديد من البلدان. نتيجة لذلك ، دائمًا ما تكون المشاكل معقدة ومثيرة للاهتمام ، تم حل المشكلات البسيطة من خلال دعم المستويات السابقة. رابعا ، تأثرت دوافع الفريق إلى حد كبير بالمستوى المهني لفريق الدعم الذي تعاملوا معه (كان هناك مهندسون ذوو خبرة كبيرة ورائعة تقنيًا) ، وكنا دائمًا متأكدين من جودة البيانات التي قاموا بإعدادها ، والتحليل الذي قاموا به ، وما إلى ذلك. خامسًا ، وأعتقد أن هذه هي اللحظة الأكثر أهمية - كان الفريق صغيرًا للغاية ، وكان جميع اللاعبين في بداية حياتهم المهنية. لقد كان من المثير للاهتمام بالنسبة لهم أن يدرسوا منتجًا كبيرًا ومعقدًا ، وأن يحلوا مشاكل جديدة وخطيرة لهم في بيئة جديدة لهم ، وقد سعوا إلى تلبية مستوى الفرق والمشاكل والعملاء المحيطين باحتراف. تحول المشروع إلى مدرسة ممتازة ، ثم حقق الجميع مهنة جيدة في الشركة وأصبحوا قادة فنيين وكبار المديرين ، وأصبح أحدهم الآن مديرًا تقنيًا في Amazon Web Services ، والآخر انتقل إلى Google بمرور الوقت ، ولا يزال جميعهم يتذكرون هذا المشروع بحرارة .

إذا كان هذا الفريق يتكون من مبرمجين يتمتعون بخبرة تتراوح بين 15 و 20 عامًا ، فسيكون الدافع مختلفًا. لا يمثل العمر والخبرة ، بطبيعة الحال ، عوامل حاسمة بنسبة 100 ٪ ، كل هذا يتوقف على بنية الدافع. في هذه الحالة بالذات ، أعطت الرغبة في المعرفة ونمو المبرمجين الشباب نتيجة ممتازة.

بشكل عام ، كما ذكرنا مرارًا وتكرارًا ، يجب أن تعرف توقعات المبرمجين لديك ، وأن تفهم أي منهم يرغب في توسيع نطاق الأنشطة أو تغييرها ومراعاة هذه التوقعات.

خارج هرم ماسلو: الرؤية والجيم والمنافسة ، لا هراء

هناك ثلاث نقاط مهمة أخرى تتعلق بدوافع المبرمجين التي ينبغي ذكرها ، ولكن جذبهم إلى نموذج احتياجات ماسلو سيكون مصطنعًا جدًا.

الأول هو وضوح وقرب النتيجة.

تطوير البرمجيات عادة ما يكون ماراثون. تصبح نتائج الجهود المبذولة في مجال البحث والتطوير مرئية بعد شهور وأحيانًا سنوات. من الصعب الوصول إلى هدف أبعد من الأفق ، ومقدار العمل مرعب ، والهدف بعيد ، وغير واضح وغير مرئي ، "الليلة مظلمة ومليئة بالأهوال". من الأفضل تقسيم الطريق إلى أجزاء ، وتمهيد الطريق إلى أقرب شجرة ، تكون مرئية وقابلة للتحقيق ، والشكل واضح ، وهو ليس بعيدًا عنا - والانتقال إلى هذا الهدف القريب. نريد أن نبذل جهداً لبضعة أيام أو أسابيع ، والحصول على النتيجة وتقييمها ، ثم المضي قدمًا. لذلك ، يجب أن يتم تقسيم العمل إلى أجزاء صغيرة (تخدم الأشباح المتحركة بسرعة هذا الغرض جيدًا). لقد قاموا بجزء من العمل - تم تسجيله وزفيره ومناقشته ومعاقبتهم بالذنب ومنحهم الدعوة - ​​يمكنك البدء في الدورة التالية.

يشبه هذا الدافع إلى حد ما الدافع الذي يختبره اللاعبون عند لعب ألعاب الكمبيوتر: فهم يحصلون على ميداليات ونقاط ومكافآت بشكل دوري عند اجتياز كل مستوى ، ويمكن تسمية هذا باسم "دافع الدوبامين".

علاوة على ذلك ، فإن رؤية النتيجة مهمة حرفيا. يجب أن تتحول ميزة مغلقة في القائمة إلى اللون الأخضر. إذا كانت الشفرة مكتوبة ، تم اختبارها ، ملوثة ، لكن لم يحدث أي تغيير في الوضع المرئي المرئي للمبرمج ، فسيشعر بأنه غير مكتمل ، لن يكون هناك شعور بالإنجاز. في أحد الفرق في نظام التحكم في الإصدار الخاص بنا ، مر كل تصحيح بثلاث مراحل متتالية - تم تجميع البنية واجتياز الاختبارات ، وتمرير التصحيح على رمز المراجعة ، واستنفاد التصحيح. تميزت كل مرحلة بصريا بعلامة خضراء أو صليب أحمر. مرة واحدة ، اشتكى أحد المطورين من أن رمز المراجعة يستمر لفترة طويلة ، يحتاج الزملاء إلى الإسراع ، وتعليق البقع لعدة أيام. سألت ، في جوهره ، ما الذي يتغير بالنسبة له؟ بعد كل شيء ، عندما يتم كتابة الكود ، يتم تجميع البنية وتمرير الاختبارات ، لا تحتاج إلى الانتباه إلى التصحيح المرسل في حالة عدم وجود تعليقات. سيقوم الزملاء بإجراء المراجعة بأنفسهم وإبقائهم في حالة انخفاض (إذا لم تكن هناك تعليقات مرة أخرى). أجاب - "إيغور ، أريد الحصول على علاماتي الخضراء الثلاثة في أسرع وقت ممكن."

النقطة الثانية هي التلاعب والمنافسة.

عند تطوير أحد المنتجات ، كان هدف فريقنا الهندسي هو الحصول على مكانة بارزة في مجتمع أحد المنتجات مفتوحة المصدر ، وهو الدخول إلى أعلى 3. في ذلك الوقت ، لم تكن هناك طريقة موضوعية لتقييم وضوح شخص ما في المجتمع ، يمكن لكل شركة كبيرة من الشركات المشاركة أن تعلن (وذكرت بشكل دوري) أنها المساهم الأول ، ولكن لم تكن هناك طريقة حقيقية لمقارنة مساهمة المشاركين مع بعضهم البعض ، لتقييم ديناميكياتها في الوقت. وفقًا لذلك ، لم يكن هناك طريقة لتحديد هدف للفريق ، والذي يمكن قياسه في بعض الببغاوات ، وتقييم درجة الإنجاز ، إلخ. لحل هذه المشكلة ، قام فريقنا بتطوير أداة لقياس وتصور مساهمة الشركات والمساهمين الأفراد www.stackalytics.com . من حيث الدافع ، اتضح أنها مجرد قنبلة. ليس فقط المهندسين والفرق تراقب باستمرار تقدمهم وتقدم الزملاء والمنافسين. كما بدأت الإدارة العليا لشركتنا وجميع المنافسين الرئيسيين يومهم مع stackalytics. أصبح كل شيء شفافًا وواضحًا جدًا ، ويمكن للجميع مراقبة تقدمهم بعناية ، مقارنة مع الزملاء ، إلخ. أصبح من السهل والسهل تحديد الأهداف للمهندسين والمديرين والفرق.

النقطة المهمة التي تنشأ عند تقديم أي نظام من المقاييس الكمية هي أنه بمجرد تطبيقك لها ، يسعى النظام تلقائيًا إلى تحديد أولويات تحقيق هذه المقاييس الكمية ، على حساب المقاييس النوعية. , . , -, , , , , , +1 . , , +1 CI . , “go, go, jenkins”. , , , . : , . , , , , scale performance , , core reviewer, core projects , — .

, — No bullshit.

— , . 8-10 , . -, , , , , . , , , . — . , , , , disagree and commit ( , ). - , . , , , . - : « , , . , , ». , . , , .