كتابة منقوشة:
يقول الزوج وهو ينظر إلى الأطفال المتسخين لزوجته: حسنًا، هل نغسلهم أم نلد أطفالًا جددًا؟
يوجد أسفل المقطع الجزء الثاني من مقالة كتبها قائد فريقنا، وكذلك مدير تطوير المنتجات في RAS، إيجور مارنات، حول خصوصيات تحفيز المبرمجين. الجزء الأول من المقال تجده هنا -
تطرقت في الجزء الأول من المقال إلى المستويين الأدنى لهرم ماسلو: الحاجات الفسيولوجية، والحاجة إلى الأمان والراحة والثبات، ثم انتقل إلى المستوى الثالث التالي، وهو:
الثالث - الحاجة إلى الانتماء والحب
كنت أعلم أن المافيا الإيطالية تسمى "كوزا نوسترا"، لكنني تأثرت كثيرًا عندما اكتشفت كيفية ترجمة "كوزا نوسترا". "Cosa Nostra" المترجمة من الإيطالية تعني "أعمالنا". يعد اختيار الاسم ناجحًا جدًا للتحفيز (دعونا نترك المهنة جانبًا، ففي هذه الحالة نحن مهتمون فقط بالتحفيز). عادةً ما يرغب الشخص في أن يكون جزءًا من فريق للقيام ببعض أعمالنا الكبيرة والمشتركة.
يتم إيلاء أهمية كبيرة لتلبية الحاجة إلى الانتماء والحب في الجيش والبحرية وأي تشكيلات شبه عسكرية كبيرة. وكما نرى في المافيا. هذا أمر مفهوم، لأنك تحتاج إلى إجبار الأشخاص الذين لديهم القليل من القواسم المشتركة، والذين في البداية لا يشكلون فريقًا من الأشخاص ذوي التفكير المماثل، والذين يتم جمعهم معًا عن طريق التجنيد الإجباري (وليس طوعًا)، والذين لديهم مستويات مختلفة من التعليم، وقيم شخصية مختلفة ، لتكريس حياتهم حرفيًا، في خطر مميت، لبعض القضايا المشتركة، أو عهد بحياتك إلى رفيق في السلاح.
وهذا دافع قوي للغاية؛ بالنسبة لمعظم الناس، من المهم للغاية أن يشعروا بأنهم ينتمون إلى شيء أكبر، وأن يعرفوا أنك جزء من عائلة، أو بلد، أو فريق. في الجيش، يخدم هذه الأغراض الزي الرسمي والطقوس المختلفة والمسيرات والمسيرات واللافتات وما إلى ذلك. تقريبا نفس العوامل مهمة لأي فريق. تعتبر الرموز والعلامات التجارية للشركات وألوان الشركات والأدوات والهدايا التذكارية مهمة.
من المهم أن يكون للأحداث المهمة تجسيدها المرئي الذي يمكن ربطها به. في الوقت الحاضر، أصبح من المعتاد أن تمتلك الشركة بضائعها الخاصة، والسترات، والقمصان، وما إلى ذلك. ولكن من المهم أيضًا تسليط الضوء على الفريق داخل الشركة. غالبًا ما نقوم بإصدار قمصان بناءً على نتائج الإصدار، والتي يتم منحها لجميع المشاركين في الإصدار. تعد بعض الأحداث أو الاحتفالات المشتركة أو الأنشطة مع الفريق بأكمله عاملاً مهمًا آخر للتحفيز.
بالإضافة إلى السمات الخارجية، هناك عدة عوامل أخرى تؤثر على الشعور بالانتماء للفريق.
أولا، وجود هدف مشترك يفهمه الجميع ويشارك في تقييم أهميته. عادةً ما يريد المبرمجون أن يفهموا أنهم يفعلون شيئًا رائعًا، وأنهم يفعلون هذا الشيء الرائع معًا، كفريق واحد.
ثانيًا، يجب أن يكون لدى الفريق مساحة اتصال يتواجد فيها الفريق بأكمله وينتمي إليه فقط (على سبيل المثال، الدردشة في برنامج المراسلة، والمزامنة الدورية للفريق). بالإضافة إلى قضايا العمل، والتواصل غير الرسمي، وأحيانًا مناقشة الأحداث الخارجية، والضوء خارج السطح - كل هذا يخلق إحساسًا بالمجتمع والفريق.
ثالثا، أود أن أسلط الضوء على إدخال الممارسات الهندسية الجيدة داخل الفريق، والرغبة في رفع المعايير مقارنة بتلك المقبولة في الشركة. إن تنفيذ أفضل الأساليب المقبولة في الصناعة، أولاً في الفريق، ثم في الشركة ككل، يمنح الفريق الفرصة للشعور بأنه متقدم على الآخرين بطريقة ما، ويقود الطريق، وهذا يخلق شعوراً بالانتماء. لفريق بارد.
ويتأثر الشعور بالانتماء أيضًا بمشاركة الفريق في التخطيط والإدارة. عندما يشارك أعضاء الفريق في مناقشة أهداف المشروع وخطط العمل ومعايير الفريق والممارسات الهندسية وإجراء مقابلات مع الموظفين الجدد، فإنهم يطورون شعورًا بالمشاركة والملكية المشتركة والتأثير على العمل. يكون الناس أكثر استعدادًا لتنفيذ القرارات التي يتخذونها ويعبرون عنها بأنفسهم مقارنة بتلك التي يقترحها الآخرون، حتى لو كانوا متناغمين عمليًا.
أعياد الميلاد واحتفالات الذكرى السنوية والأحداث المهمة في حياة الزملاء - بيتزا مشتركة وهدية صغيرة من الفريق تعطي شعورًا دافئًا بالمشاركة والامتنان. من المعتاد في بعض الشركات إعطاء علامات تذكارية صغيرة لمدة 5، 10، 15 سنة من العمل في الشركة. من ناحية، لا أعتقد أن هذا يحفزني كثيرًا لتحقيق إنجازات جديدة. ولكن من الواضح أن أي شخص تقريبًا سيكون سعيدًا لأنه لم ينساه. هذه إحدى الحالات التي يكون فيها غياب الحقيقة مثبطًا بدلاً من أن يكون وجودها هو الحافز. أوافق، قد يكون من العار أن يذكرك LinkedIn في الصباح ويهنئك بالذكرى السنوية العاشرة لتأسيسك في مكان عملك، ولكن لم يهنئك أو يتذكرك أي زميل من الشركة.
بالطبع، النقطة المهمة هي التغيير في تكوين الفريق. من الواضح أنه حتى لو تم الإعلان عن وصول أو مغادرة شخص ما من الفريق مسبقًا (على سبيل المثال، في النشرة الإخبارية للشركة أو الفريق، أو في اجتماع الفريق)، فإن هذا لا يحفز أي شخص بشكل خاص على تحقيق إنجازات جديدة. ولكن إذا رأيت في أحد الأيام شخصًا جديدًا بجوارك، أو لم ترَ شخصًا قديمًا، فقد يكون ذلك مفاجأة، وإذا غادرت، فسيكون الأمر مزعجًا تمامًا. لا ينبغي للناس أن يختفوا بهدوء. خاصة في فريق موزع. خاصة إذا كان عملك يعتمد على زميل من مكتب آخر ظهر فجأة واختفى. من المؤكد أن مثل هذه اللحظات تستحق إبلاغ الفريق بشكل منفصل مسبقًا.
عامل مهم يسمى باللغة الإنجليزية ملكية (الترجمة الحرفية لكلمة "حيازة" لا تعكس معناها بالكامل). هذا ليس شعورًا بالملكية، بل هو شعور بالمسؤولية تجاه مشروعك، ذلك الشعور عندما تربط نفسك عاطفيًا بالمنتج والمنتج بنفسك. وهذا يتوافق تقريبًا مع دعاء جندي البحرية في فيلم "Full Metal Jacket": "هذه بندقيتي هناك العديد من هذه البنادق، ولكن هذه هي لي. بندقيتي هي أفضل صديق لي. هي حياتي. يجب أن أتعلم كيف أمتلكها بنفس الطريقة التي أمتلك بها حياتي. بدوني بندقيتي لا يوجد لها إستعمال. أنا عديمة الفائدة بدون بندقيتي. لا بد لي من إطلاق النار على بندقيتي مباشرة. لا بد لي من إطلاق النار بدقة أكبر من العدو الذي يحاول قتلي. يجب أن أطلق النار عليه قبل أن يطلق النار علي. فليكن كذلك... ".
عندما يعمل شخص ما على منتج ما لفترة طويلة، تتاح له الفرصة لتحمل المسؤولية الكاملة عن إنشائه وتطويره، لمعرفة كيف ينشأ شيء عامل من "لا شيء"، وكيف يستخدمه الناس، ينشأ هذا الشعور القوي. عادةً ما تكون فرق الإنتاج التي تعمل معًا لفترة طويلة في مشروع واحد أكثر تحفيزًا وتماسكًا من الفرق التي يتم تجميعها لفترة قصيرة من الوقت وتعمل في وضع خط التجميع، وتنتقل من مشروع إلى آخر، دون تحمل المسؤولية الكاملة عن المنتج بأكمله ، من البداية إلى النهاية.
رابعا. الحاجة إلى الاعتراف
الكلمة الطيبة ترضي القطة أيضًا. يحفز الجميع الاعتراف بأهمية العمل الذي قاموا به وتقييمه الإيجابي. تحدث إلى المبرمجين، وقدم لهم تعليقات دورية، واحتفل بالعمل الجيد الذي تم إنجازه. إذا كان لديك فريق كبير وموزع، فإن الاجتماعات الدورية (ما يسمى واحد لواحد) مثالية لهذا الغرض؛ إذا كان الفريق صغيرًا جدًا ويعمل معًا محليًا، يتم توفير هذه الفرصة عادةً دون اجتماعات خاصة في التقويم (على الرغم من أنها دورية) إلى واحد هو كل ما لا تزال هناك حاجة إليه، يمكنك القيام بذلك بشكل أقل). تمت تغطية هذا الموضوع جيدًا في ملفات podcast للمديرين على manager-tools.com.
ومع ذلك، فمن المفيد أن نأخذ الاختلافات الثقافية في الاعتبار. بعض الأساليب المألوفة لدى الزملاء الأمريكيين لن تنجح دائمًا مع الأساليب الروسية. يبدو مستوى المداراة المقبول في التواصل اليومي في فرق الدول الغربية في البداية مفرطًا بالنسبة للمبرمجين من روسيا. قد يُنظر إلى بعض الصراحة التي يتميز بها الزملاء الروس على أنها وقاحة من قبل زملائهم من البلدان الأخرى. هذا مهم جدًا في التواصل في فريق متعدد الأعراق، وقد كتب الكثير حول هذا الموضوع، ويجب أن يتذكر مدير هذا الفريق ذلك.
تعتبر العروض التوضيحية للميزات، حيث يعرض المبرمجون الميزات التي تم تطويرها أثناء العدو، ممارسة جيدة لتحقيق هذه الحاجة. بالإضافة إلى أن هذه فرصة ممتازة لمسح قنوات الاتصال بين الفرق، وتعريف مديري المنتجات والمختبرين بالميزات الجديدة، فهي أيضًا فرصة جيدة للمطورين لعرض نتائج عملهم والإشارة إلى تأليفهم. حسنًا، قم بصقل مهاراتك في التحدث أمام الجمهور، بالطبع، وهو أمر غير ضار أبدًا.
ستكون فكرة جيدة الاحتفال بالمساهمة الكبيرة للزملاء المتميزين بشكل خاص من خلال الشهادات والعلامات التذكارية (كلمة طيبة على الأقل) في لقاءات الفريق المشترك. عادة ما يقدر الناس هذه الشهادات واللافتات التذكارية كثيرًا، ويأخذونها معهم عند التحرك، ويعتنون بها بكل الطرق الممكنة بشكل عام.
للإشارة إلى مساهمة أكثر أهمية وطويلة المدى في عمل الفريق، والخبرة والخبرة المتراكمة، غالبًا ما يتم استخدام نظام الدرجات (مرة أخرى، يمكن إجراء تشبيه مع نظام الرتب العسكرية في الجيش، والذي بالإضافة إلى ذلك لضمان التبعية، يخدم هذا الغرض أيضًا). في كثير من الأحيان، يعمل المطورون الشباب بجهد مضاعف للحصول على نجوم جدد (أي الانتقال من مطور مبتدئ إلى مطور بدوام كامل، وما إلى ذلك).
معرفة توقعات شعبك أمر بالغ الأهمية. من المرجح أن يكون الدافع لدى البعض هو الدرجة العالية، وفرصة أن يُطلق عليهم، على سبيل المثال، مهندس معماري، بينما البعض الآخر، على العكس من ذلك، غير مبالين بالدرجات والألقاب وسيعتبرون زيادة الراتب علامة اعتراف من الشركة . التواصل مع الناس لفهم ما يريدون وما هي توقعاتهم.
يمكن تقديم إظهار الاعتراف ومستوى أعلى من الثقة من جانب الفريق من خلال منح المزيد من حرية العمل أو المشاركة في مجالات عمل جديدة. على سبيل المثال، بعد اكتساب خبرة معينة وتحقيق نتائج معينة، يستطيع المبرمج، بالإضافة إلى تنفيذ ميزاته وفقًا للمواصفات، العمل على هندسة أشياء جديدة. أو شارك في مجالات جديدة قد لا تكون مرتبطة بشكل مباشر بالتطوير - أتمتة الاختبار، وتنفيذ أفضل الممارسات الهندسية، والمساعدة في إدارة الإصدارات، والتحدث في المؤتمرات، وما إلى ذلك.
خامسا: الحاجة إلى الإدراك وتحقيق الذات.
يركز العديد من المبرمجين على أنواع مختلفة من أنشطة البرمجة في مراحل مختلفة من حياتهم. يحب بعض الأشخاص القيام بالتعلم الآلي، وتطوير نماذج بيانات جديدة، وقراءة الكثير من الأدبيات العلمية للعمل، وإنشاء شيء جديد من الصفر. هناك طريقة أخرى أقرب إلى تصحيح الأخطاء ودعم تطبيق موجود، حيث تحتاج إلى التعمق في التعليمات البرمجية الموجودة، ودراسة السجلات، وتتبع المكدس ورموز التحقق من الشبكة لأيام وأسابيع، وعدم كتابة أي تعليمات برمجية جديدة تقريبًا.
تتطلب كلتا العمليتين جهدًا فكريًا كبيرًا، لكن نتاجهما العملي مختلف. ويعتقد أن المبرمجين يترددون في دعم الحلول الحالية، بل إنهم متحمسون لتطوير حلول جديدة. هناك ذرة من الحكمة في هذا. من ناحية أخرى، كان الفريق الأكثر حماسًا واتحادًا الذي عملت معه على الإطلاق مكرسًا لدعم منتج موجود، والعثور على الأخطاء وإصلاحها بعد أن اتصل بهم فريق الدعم. لقد عاش الرجال حرفيًا من أجل هذا العمل وكانوا مستعدين للخروج يومي السبت والأحد. لقد تعاملنا ذات مرة بشغف مع مشكلة ملحة ومعقدة أخرى، إما مساء يوم 31 ديسمبر أو بعد ظهر يوم 1 يناير.
هناك عدة عوامل أثرت على هذا الدافع العالي. أولاً، كانت شركة ذات اسم كبير في الصناعة، وقد ارتبط فريق العمل بها (انظر "الحاجة إلى الانتساب"). ثانيًا، كانوا الحدود الأخيرة، ولم يكن هناك أحد خلفهم، ولم يكن هناك فريق منتج في ذلك الوقت. بينهم وبين العملاء كان هناك مستويان من الدعم، لكن إذا وصلت المشكلة إليهم، لم يكن هناك مكان للتراجع، ولم يكن أحد خلفهم، كانت الشركة بأكملها عليهم (أربعة مبرمجين شباب). ثالثًا، كان لدى هذه الشركة الكبيرة عدد كبير جدًا من العملاء (حكومات الدول، وشركات السيارات والطيران، وما إلى ذلك) ومنشآت واسعة النطاق في العديد من البلدان. ونتيجة لذلك، كانت المشكلات المعقدة والمثيرة للاهتمام دائمًا، وتم حل المشكلات البسيطة من خلال دعم المستويات السابقة. رابعا، تأثر تحفيز الفريق بشكل كبير بالمستوى المهني لفريق الدعم الذي تفاعلوا معه (كان هناك مهندسين ذوي خبرة كبيرة وقدرة فنية)، وكنا دائما واثقين من جودة البيانات التي أعدوها، والتحليل الذي أجروه ، إلخ. خامسًا، وأعتقد أن هذه هي النقطة الأكثر أهمية - كان الفريق صغيرًا جدًا، وكان جميع اللاعبين في بداية حياتهم المهنية. لقد كانوا مهتمين بدراسة منتج كبير ومعقد، وحل المشكلات الخطيرة التي كانت جديدة عليهم في بيئة جديدة، وسعوا إلى التوفيق بشكل احترافي مع مستوى الفرق والمشاكل والعملاء المحيطين بهم. تحول المشروع إلى مدرسة ممتازة، حيث حقق الجميع فيما بعد مهنة جيدة في الشركة وأصبحوا قادة تقنيين وكبار المديرين، أحد الرجال هو الآن مدير فني في Amazon Web Services، والآخر انتقل في النهاية إلى Google، وكل شيء منهم ما زالوا يتذكرون هذا المشروع بكل دفء.
إذا كان هذا الفريق يتكون من مبرمجين يتمتعون بخبرة تتراوح بين 15 إلى 20 عامًا، فسيكون الدافع مختلفًا. وبطبيعة الحال، فإن العمر والخبرة ليسا من العوامل المحددة بنسبة 100٪؛ كل هذا يتوقف على بنية الحافز. في هذه الحالة بالذات، أدت الرغبة في المعرفة ونمو المبرمجين الشباب إلى نتائج ممتازة.
بشكل عام، وكما ذكرنا عدة مرات، يجب عليك معرفة توقعات المبرمجين لديك، وفهم أي منهم يرغب في توسيع أو تغيير مجال نشاطه، وأخذ هذه التوقعات بعين الاعتبار.
ما وراء هرم ماسلو: رؤية النتائج، واللعب، والمنافسة، لا هراء
هناك ثلاث نقاط أكثر أهمية فيما يتعلق بدوافع المبرمجين والتي يجب ذكرها بالتأكيد، ولكن جذبهم إلى نموذج احتياجات ماسلو سيكون مصطنعًا للغاية.
الأول هو وضوح النتيجة وقربها.
عادة ما يكون تطوير البرمجيات بمثابة سباق الماراثون. تصبح نتائج جهود البحث والتطوير مرئية بعد أشهر، وأحيانًا سنوات. من الصعب الذهاب إلى هدف أبعد من الأفق، حجم العمل مرعب، الهدف بعيد، غير واضح وغير مرئي، “الليل مظلم ومليء بالأهوال”. من الأفضل تقسيم الطريق إليها إلى أجزاء، وجعل الطريق إلى أقرب شجرة مرئية، ويمكن الوصول إليها، والخطوط العريضة واضحة، وهي ليست بعيدة عنا - والذهاب إلى هذا الهدف القريب. نريد أن نبذل جهدًا لعدة أيام أو أسابيع، ونحصل على النتيجة ونقيمها، ثم نمضي قدمًا. لذلك، فإن الأمر يستحق تقسيم العمل إلى أجزاء صغيرة (سباقات السرعة في Agile تخدم هذا الغرض جيدًا). لقد أكملنا جزءًا من العمل - سجلناه، وزفرناه، وناقشناه، وعاقبنا المذنب، وكافئنا الأبرياء - يمكننا أن نبدأ الدورة التالية.
يشبه هذا الدافع إلى حد ما ما يختبره اللاعبون عند إكمال ألعاب الكمبيوتر: فهم يحصلون بشكل دوري على ميداليات ونقاط ومكافآت عند إكمال كل مستوى، ويمكن أن يسمى هذا "دافع الدوبامين".
في الوقت نفسه، فإن رؤية النتيجة مهمة حرفيًا. يجب أن يتحول العنصر المغلق في القائمة إلى اللون الأخضر. إذا تمت كتابة الكود واختباره وإصداره، ولكن لم يكن هناك تغيير في الحالة المرئية للمبرمج، فسوف يشعر بأنه غير مكتمل، ولن يكون هناك أي إحساس بالاكتمال. في أحد الفرق في نظام التحكم في الإصدار الخاص بنا، مر كل تصحيح بثلاث مراحل متتالية - تم تجميع البناء واجتياز الاختبارات، واجتاز التصحيح مراجعة التعليمات البرمجية، وتم دمج التصحيح. تم تمييز كل مرحلة بصريًا بعلامة خضراء أو صليب أحمر. بمجرد أن اشتكى أحد المطورين من أن مراجعة التعليمات البرمجية استغرقت وقتًا طويلاً، كان على الزملاء الإسراع، وكانت التصحيحات معلقة لعدة أيام. سألته، ما الذي تغير بالفعل بالنسبة له؟ بعد كل شيء، عند كتابة التعليمات البرمجية، يتم تجميع البناء وتم اجتياز الاختبارات، ولا يحتاج إلى الانتباه إلى التصحيح المرسل إذا لم تكن هناك تعليقات. سيقوم الزملاء أنفسهم بمراجعته والموافقة عليه (في حالة عدم وجود تعليقات مرة أخرى). فأجاب: "إيجور، أريد الحصول على علاماتي الخضراء الثلاث في أسرع وقت ممكن."
النقطة الثانية هي اللعب والمنافسة.
عند تطوير أحد المنتجات، كان لدى فريقنا الهندسي هدف أن يحتل مكانة بارزة في مجتمع أحد المنتجات مفتوحة المصدر، ليدخل ضمن المراكز الثلاثة الأولى. في ذلك الوقت، لم تكن هناك طريقة موضوعية لتقييم ظهور شخص ما في المجتمع؛ كان بإمكان كل شركة من الشركات الكبرى المشاركة أن تدعي (وتزعم بشكل دوري) أنها كانت المساهم الأول، ولكن لم تكن هناك طريقة حقيقية لمقارنة مساهمات المشاركين فيما بينهم، لتقييم ديناميكياتها في الوقت المناسب. وعليه، لم تكن هناك طريقة لتحديد هدف للفريق يمكن قياسه عند بعض الببغاوات وتقييم درجة تحقيقه وغير ذلك. لحل هذه المشكلة، قام فريقنا بتطوير أداة لقياس وتصور مساهمة الشركات والمساهمين الأفراد . من وجهة نظر تحفيزية، اتضح أنها مجرد قنبلة. لم يكن المهندسون وفرق العمل وحدهم هم الذين يراقبون تقدمهم وتقدم زملائهم ومنافسيهم باستمرار. كما بدأت الإدارة العليا لشركتنا وجميع المنافسين الرئيسيين يومهم باستخدام تقنية Stackalytics. أصبح كل شيء شفافًا ومرئيًا للغاية، ويمكن للجميع مراقبة تقدمهم بعناية، والمقارنة مع زملائهم، وما إلى ذلك. لقد أصبح من السهل والسهل على المهندسين والمديرين والفرق تحديد الأهداف.
من النقاط المهمة التي تنشأ عند تنفيذ أي نظام للمقاييس الكمية هو أنه بمجرد تنفيذها، يسعى النظام تلقائيًا إلى إعطاء الأولوية لتحقيق هذه المقاييس الكمية، على حساب المقاييس النوعية. على سبيل المثال، يتم استخدام عدد مراجعات التعليمات البرمجية المكتملة كأحد المقاييس. من الواضح أنه يمكن إجراء مراجعة التعليمات البرمجية بطرق مختلفة، يمكنك قضاء عدة ساعات في مراجعة شاملة والتحقق من التصحيح المعقد من خلال اختبارات التحقق، وتشغيله على مقعدك، والتحقق من الوثائق، والحصول على مراجعة إضافية في الكارما الخاصة بك، أو انقر بشكل أعمى على بضع عشرات من التصحيحات في بضع دقائق، وامنح كل واحدة +1 واحصل على عشرين في الكارما. كانت هناك حالات مضحكة عندما قام المهندسون بالنقر فوق التصحيحات بسرعة كبيرة لدرجة أنهم أعطوا +1 للتصحيحات التلقائية من نظام CI. وكما مزحنا لاحقًا، "اذهب، اذهب يا جينكينز". في حالة الالتزامات، كان هناك أيضًا العديد من الأشخاص الذين مروا على الكود باستخدام أدوات تنسيق الكود، وقاموا بتحرير التعليقات، وتغيير النقاط إلى فواصل، وبالتالي زيادة الكارما الخاصة بهم. إن التعامل مع هذا أمر بسيط للغاية: فنحن نستخدم المنطق السليم، وبالإضافة إلى المقاييس الكمية، نستخدم أيضًا المقاييس النوعية الأساسية. درجة استخدام نتائج عمل الفريق، عدد المساهمين الخارجيين، مستوى تغطية الاختبار، استقرار الوحدات والمنتج بأكمله، نتائج اختبار الحجم والأداء، عدد المهندسين الذين حصلوا على كتف المراجع الأساسي الأشرطة، وحقيقة قبول المشاريع في مجتمع المشاريع الأساسية، والامتثال لمعايير المراحل المختلفة للعملية الهندسية - كل هذه العوامل والعديد من العوامل الأخرى يجب تقييمها جنبًا إلى جنب مع مقاييس كمية بسيطة.
وأخيرا، النقطة الثالثة - لا هراء.
المطورون أشخاص أذكياء للغاية ومنطقيون للغاية في مجال عملهم. إنهم يقضون ما بين 8 إلى 10 ساعات يوميًا في بناء سلاسل منطقية طويلة ومعقدة، لذلك يرون نقاط الضعف فيها بسرعة. عند القيام بشيء ما، فإنهم، مثل أي شخص آخر، يريدون أن يفهموا سبب قيامهم بذلك، وما الذي سيتغير نحو الأفضل. من المهم للغاية أن تكون الأهداف التي حددتها لفريقك صادقة وواقعية. إن محاولة بيع فكرة سيئة لفريق برمجة هي فكرة سيئة. تكون الفكرة سيئة إذا لم تؤمن بها بنفسك، أو، في الحالات القصوى، لم تكن لديك حالة داخلية من عدم الموافقة والالتزام (أنا لا أوافق، لكنني سأفعل ذلك). لقد قمنا ذات مرة بتطبيق نظام تحفيز في إحدى الشركات، وكان أحد عناصره هو النظام الإلكتروني لتقديم الملاحظات. لقد استثمروا الكثير من المال، وأخذوا الناس إلى أمريكا للتدريب، بشكل عام، استثمروا على أكمل وجه. ذات مرة، في محادثة بعد التدريب، قال أحد المديرين لمرؤوسيه: "الفكرة ليست سيئة، يبدو أنها ستنجح. لن أعطيك ردودًا إلكترونية بنفسي، لكنك تعطيها لشعبك وتطلبها منهم”. هذا كل شيء، لا يمكن تنفيذ أي شيء أكثر من ذلك. الفكرة بالطبع انتهت بلا شيء.
المصدر: www.habr.com