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

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

وما الذي يجب أن تفعله التنانين به ، سنشرح تحت القص.



هذه المقالة مبنية على مقالنا مع قسطنطين قفطان على TeamLead Conf . كونستانتين تيمليد ، قسم الدعم الفني في IPONWEB ، وأنا الكاتب التقني لفريق التطوير في IPONWEB ، المنخرط في إدارة المعرفة.

القصة مبنية على حالات عملية IPONWEB ، لذلك تعرف أولاً على الشركة قليلاً حتى تتمكن من فهم ما إذا كانت هذه المواد قريبة منك أم لا.

لدينا الموارد البشرية ، بناء على طلب للحصول على صورة تسويقية باردة من شأنها أن تخبرنا عن مجالنا ، أعطى هذا:


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

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

لماذا اخترنا اسم "Dragons Live Here" ، ماذا يعني هذا؟ حتى في وقت مبكر على خرائط القرون الوسطى أماكن مخصصة حيث من غير المعروف ما يحدث - مثل تيرا Incognita. هناك قصتان حول هذا الموضوع. الأول يدور حول هيكل المهارات والمهارات التي يمتلكها الفريق ، وكلما زاد حجم الفريق ، زاد تيرا المتخفي ؛ والحديث عن الثانية في وقت لاحق قليلا.

كيف وصلنا إلى هنا

لقد حدث أن نحن (سفيتلانا وكونستانتين) لا نتداخل في كثير من الأحيان في العمل ، وأننا قدمنا ​​طلبات فقط بشأن نفس الموضوع من موقع المؤتمر فقط. ثم قررنا أن نتحد - بدا لنا أن هذا سيكون أكثر إثارة للاهتمام للجميع.

ملامح الفريق

فريق الدعم الفني في كونستانتين:

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

فريق تطوير Lua :

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

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

الأهداف والمشغلات

في فريق الدعم الفني:

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

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

في فريق ديف كان من الضروري:

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

كان هناك أيضًا هدف جانبي - وهو جعل عملية مراجعة الأداء أكثر شفافية ومفهومة ، من أجل صياغة الأهداف في نظام إحداثي واحد.

مراجعة الأداء

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

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

لماذا تحتاج إلى مصفوفة الكفاءة

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

لماذا تحتاج كل هذا؟ سوف تتعلم عن حالاتنا العملية ، لكن قد يكون لديك سؤال معقول - كيف تفهم أنني بحاجة إليه؟

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

من أين تبدأ

من أين نبدأ سنقول بمثالنا.

في فريق الدعم الفني ، قمنا بما يلي: تحديد المهام التي نشارك فيها ؛ المهام المتحللة في عمليات منفصلة ؛ اكتشفت الأدوات التي يجب على الموظف معرفتها للعمل في قطاع معين.

أدناه مثال مبسط قليلاً.


الفريق لديه موظفين باتمان وجوكر وفلاش وإيفانوف ، ومهام قياسية:

• تشخيص حركة المرور العامة.
• تشخيص حركة المرور الصفقة ؛
• مراقبة النشر ؛
• اختبار تكامل الشركاء الجدد ، DSP و SSP ، المشترين والبائعين على حد سواء.

من الأدوات لدينا:

• uSIicer يسمح لك بالحصول على أرقام تداول مفصلة للغاية ؛
• يوفر الجرافيت بيانات حالة النظام في الوقت الفعلي ؛
• Google BigQuery (BQ) - سجلاتنا حية هناك ؛
• Grafana ، الذي يسمح لك بتجميع المقاييس من الجرافيت ، من المناسب وضع تنبيهات عليه إذا لزم الأمر ؛
• عمليات الضبط Ul في واجهة المشرف ، والتي تتيح لك تغيير معلمات حركة المرور لشريك معين أو زوج تداول أو مركز بيانات ، إلخ.

ثم اكتشفنا من يعرف ماذا وإلى أي مدى.


2 - خبير يستطيع أن يعلم ؛ 1 - يعني أن الشخص يعرف أكثر أو أقل ؛ خلايا فارغة بدلا من ذلك ، حتى لا يسيء أي شخص.

نلخص في جدول واحد:


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

Nezhdanchiki (الدعم)

ظهر العديد من الأشخاص غير المتوقعين الذين ساعدوا في فهم:

• أي من الزملاء ما المهارات التي يجب سحبها لجذبهم إلى مهام جديدة؟ (تشير إلى اتجاه التنمية) ؛
• أين يمكن أن تنشأ مشاكل في حالة فقدان الموظف؟
• ما مدى كفاية راتب الموظف إلى مجموعة المهام الخاصة به؟
• ما مدى جودة الفريق وتدريبه؟

سوف نتطرق إلى كل نقطة من النقاط لاحقًا.

دعنا نعود إلى الطاولة.



رسميا ، باتمان مشغول بالتشخيصات العامة. يوضح الجدول أن Joker ، إذا لزم الأمر ، سيحل محله جيدًا ، نظرًا لحقيقة أنه لا يزال خبيرًا في واجهة المستخدم - لم لا؟ وهذا هو ، باتمان قابلة للاستبدال هنا.

يتم إجراء المهرج بشكل جيد عمومًا - فهو ذكي في كل مكان تقريبًا ، باستثناء ربما نشر المراقبة ، ولكن يمكن تعليم ذلك.



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

ليس ذلك فحسب ، ليس لدينا خبير في BQ! وهذا هو ، هناك حاجة ملحة لسحب شخص ما ، لتدريب. على سبيل المثال ، يمكنك تعليم Batman BQ ، و Ivanov - Graphite.



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

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

من المهم في هذه الحالة أن تكون أداة قيادة فريق لا تظهر للموظفين ، لأن التقييمات ذاتية.

فريق ديف

كل شيء أكثر ديمقراطية قليلاً في Dev Team ، أو ربما قمنا بتعقيد مهمتنا. قائمة المهارات في فريق التطوير أكبر ، على الرغم من أن توحيد المهام ربما يكون أعلى.

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

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

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

لم نقم بتضمين كل هذه المهارات على الفور ، لأننا لم نفهم كيفية تقييمها بدقة.

في التكرار الثاني ، دخلوا نظام التقييم:

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

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

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

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

ثم قمنا بتقييم المطورين على مقياس من 1 إلى 3 لكل مهارة.

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

هذه المصفوفة تبدو شيء من هذا القبيل.



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

الألوان تتفق مع الصف. تم استنباط نفس المقاييس كما هو الحال في فريق الدعم - متوسط ​​ومختلف في المهارات.

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

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

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

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

تحتاج إلى تحديد هذا الأمر ونقله إلى الجميع بشكل واضح ، على سبيل المثال ، في علم Lua أن النتيجة هي:

• 1 - يعني أن المطور يعرف جميع المشغلين الأساسيين ، ويعرف كيفية التعامل مع هياكل البيانات وكتابة فئات الوظائف ؛
• 2 - يعرف كيفية تنظيم التعليمات البرمجية في المكتبات ، ويعمل باستمرار معهم طوال المشروع ويعرف ما هي metatables ؛
• 3 - يعرف تفاصيل الشركة والمشروعات ، على سبيل المثال ، ما هي coroutines (تفاصيل كيفية عمل خادمنا مع Lua) ، وكيف يعمل رمز C ++ مع رمز Lua ، وما هي القيود التي يفرضها ، وكيف يتم تفسيرها ، ورمز مترجم ، وكيف يعمل برنامج التحويل البرمجي JIT الخاص بنا.

حتى تتمكن من تحليل كل مهارة ، لأنه في مكان ما على مستوى الحدس لديك بالفعل.

ملاحظة إلى النفس:

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

كيفية التنفيذ

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

بالإضافة إلى تقييم المهارات الفردية ، كنا بحاجة إلى المطورين الصف. حصلنا على الدرجات A و B و C - مثل المبتدئين والمتوسطة والكبار. في IT junior، middle، senior ، هو بالفعل مليء بالمعنى ، والتي ، من بين أمور أخرى ، يتم استثمار الخبرة في العمل. , . A, B C — . « » .

— .

, . , , , , .

, - , , . , , . , - — , , , .

, . , , . , . .

performance review . , 1 2, ( ) .

— performance review , .

(Dev Team)

. , , . , , , . . 5-6 2-3. . -, , . ( ) .

, , . . , , , . , , . , , playground, .

, , . , , , , . . . -, .

. , - : « ? ?».

, , , — , , , . .

الحالات

, . - , , .



, CI, . , . , 8.



, , , , , -. .

, — -. .


:

• 4 , .. ;
• 1 , ;
• 0,5 HR-, , , .

وهذا كل شيء! 30 . , , , , , , .

Dev Team

. : ( ) 3-4 . , :

• , — 3-4 ( 4 ) — , .
• , , , , — 6 .
• . . , senior'. 2 knowledge- 2 .
• — ( 3-4 ). , 100 , .
• — 2 . , .

, - , - . .

, .

— , .

, - , . , , , , . : , , ..


Support - easy medium, Dev Team — medium.

, , . , . , , , .

.

• , , .

, , . ( ), . performance review, .

, , — . .

• . , , , , .
• , - — . . , , .

, HR, , -, , -, , , -, HR - . HR , , .

• , .

-. . , , . , . — - , — . .

• Don't try this at home — - , :)

, .

, , KnowledgeConf 2019 26 .

, ( , , , , ) ( ).

. , , , . .