سأصفها باستخدام مثال مطور الملخص توم. حصل توم على وظيفة في Internetmagazinzaden كمطور PHP متوسط. تقوم الشركة بإنشاء متاجر عبر الإنترنت من النماذج إلى المتاجر المعقدة باستخدام مجموعة من عمليات الدمج. تمتلك الشركة أفضل Agile و SCRUM و Stand-ups و retro. لقد عمل توم لمدة 3 أشهر وكل شيء يسير على ما يرام بالنسبة له ، وقد أطلق عدة رسائل فورية ، بل إنهم يعملون ويعملون ويسعدهم.
هنا تأتي مهمة جديدة لتطوير IM ، ولكن مع التكامل مع CRM. يبدأ توم بمهمة التكامل وفي مرحلة ما لا ينجح ويمتد المصطلح لمدة أسبوع. في الوقت نفسه ، في المسيرة العامة ، يقول توم إنه "يتفهم المشكلة" ، على أمل أن يكون بالفعل على وشك التوصل إلى حل. يلجأ توم إلى كبير المطورين مايك (الذي ليس معلمه ويجلس ليس بعيدًا عن توم) ، ويوجهه إلى الكتيبات ويشرح بإيجاز ما يجب القيام به.
يغادر توم لقراءة الدروس والتعامل مع المشكلة. بعد يومين ، عاد إلى مايك بأسئلة حول الاندماج وقاموا بفرزها معًا.
يغادر توم لفرزها لبضعة أيام ، وبعد ذلك يعود إلى مايك مرة أخرى ويعطيه الحل النهائي. يتحقق مايك من المهمة ويشير إلى بعض الأخطاء الطفيفة التي سيصححها توم قريبًا.
تبدو صورة عملية تمامًا ، ولكن هناك عدة نقاط توضح لنا أن توم لم يعد مطورًا متوسطًا كما كنا نظن من قبل ، بل يونيو.
- قضى توم وقتًا طويلاً جدًا (في هذه الحالة ، أسبوعًا) في التعامل مع المشكلة ولم يشر إلى المشكلة في الوقت المناسب.
- لم أتمكن من معرفة ذلك من خلال البرنامج التعليمي بنفسي وبدلاً من البحث عن بعض اللحظات غير المفهومة على Google ، ذهبت إلى مايك.
- قضى توم وقت مطور آخر بدلاً من استخدام وضع الوقوف ومناقشة مشاكله هناك.
في بعض الأحيان في المقابلات الشخصية لمنصب قائد الفريق ، يسألون السؤال "كيف تقسم المطورين إلى يونيو ، متوسط ، كبير؟" وإجابتي هي شيء من هذا القبيل:
- , ;
- , ;
- - .
في حالة توم ، حصل للتو على البرنامج التعليمي ووصف التنفيذ من مايك ، لكنه لم يستطع معرفة ذلك وعاد إلى مايك. كانت هذه بالنسبة لي أول "دعوة" مهمة لسنا في الوسط. النداء الثاني المهم هو أن مهارة "الإشارة إلى مشكلة" مهمة للغاية بالنسبة للوسط ، وإذا لم يكن يمتلكها ، فمن حيث المهارات الناعمة ، فإن هذا يعيده إلى الصغار. "الجرس" الثالث هو الموقف المتهور تجاه وقت مطور آخر متأصل في جونيورز ، والذي لا يفهم أحيانًا أهمية اتباع العملية والتوجه إلى أكثر المطورين "نوعًا" بدلاً من الذهاب إلى الصدارة والحصول على معلم من خلاله. هذا مهم لأنه ربما المطور مايك مشغول في مشروع فائق المسؤولية أو أن مهمته تتطلب تركيزاً عالياً لكن المبرمج جون حرفياً جالس على الطاولة التالية ،الذي أنهى للتو مشروعًا ولم يتح له الوقت بعد لبدء الغوص في مشروع جديد.
لننظر في حالة أخرى. يعمل المطور الرئيسي Vasya لصالح الشركة لفترة طويلة. فازيا بقيادة فريق ، بيتيا. وقد حدث أن بيتيا هو قائد مدروس للغاية ولا يحدد مهمة فحسب ، بل يعمل جنبًا إلى جنب مع محلل نظام في كل جانب من جوانبها وعندها فقط يعطيها للعمل. يعمل Vasya و Petya في الشركة منذ 4 سنوات وهذا المخطط موجود بالفعل في ترتيب الأشياء. في الوقت نفسه ، ينفذ Vasya المهام بشكل مثالي وفقًا للمواصفات الفنية المكتوبة ، ويوثق الكود ويسعده أن كل شيء "جميل ورائع" معه.
ولكن هذا هو الحظ السيئ ، بعد فترة من الوقت تغلق الشركة ويتعين على Vasya البحث عن وظيفة ولسبب ما بدأوا في تأهيل Vasya أثناء المقابلات ليس ككبير ، ولكن كمتوسط. "كيف حدث هذا؟ أين وقعت؟ " يسأل نفسه.
كل شيء بسيط مرة أخرى ، فقد Vasya مهارة إيجاد الحل الأمثل للمشكلة ، في غضون 4 سنوات ، خفف محلل النظام وفريق الرعاية فاسيلي كثيرًا بحيث لم تعد هناك حاجة لهذه المهارة.
ماذا تفعل في هذه الحالة؟ في أغلب الأحيان ، بعد أن وجدت هذا في شركة ، يجب ألا تأخذ الروبل من المطورين وتخفض رواتبهم (حتى لو كان ذلك بشكل غير مباشر) ، ولكن عليك أن تشعر بالحيرة من السؤال "هل يمكن إصلاح ذلك؟" وإذا كانت الإجابة "لا" ، فمن الأفضل توديع الموظف "بلطف" ، لأنه في وقت ما سيكون غير راضٍ عن حقيقة أن راتبه لا ينمو ، وقد يواجه بقية الفريق مشاكل مع هذا. إذا كانت الإجابة بنعم ، فستحتاج إلى عمل مدروس للغاية لكل من قسم تدريب الموظفين وقائد الفريق. في الواقع ، في هذه الحالة ، سيتعين عليك زيادة مهارة الموظف والقيام بذلك بلطف قدر الإمكان حتى لا تؤذي كبريائه وتعطيه الدافع للتطور.