المعرفة والكفاءات في الفريق: البحث ، انظر ، ضخ

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



يعمل Aleksey Troshin ( morroz ) في هذه المهنة منذ ما يقرب من 20 عامًا ، وهو يعمل كمدير للمشروع والمنتجات منذ عام 2002. خلال هذا الوقت ، عمل في العديد من الشركات ، وقاد فرق من 2 إلى 150 شخصًا ، ويدير الآن التطوير في FINAM. هنا ، صمم أليكس نظامًا لا يساعد فقط على نشر المعرفة ، ولكن أيضًا على تحفيز المطورين على النمو في اتجاه العمل وتوجيه الفريق المناسب. ومع ذلك ، لا يتم استخدام النظام في جميع الفرق. لماذا؟ نتعرف على هذا ، وكذلك الأساليب المستخدمة ، في إطار الخفض.

يستند المقال إلى تقرير من أليكسي تروشين حول Saint TeamLead Conf ، والذي يروي كيف يتم نشر المعرفة في FINAM: كيف تنمو قوة Jedi ومهاراته ، وكيف يتم تدريب Padawans وما يحدث على الجانب المظلم من القوة (أين ستكون بدونه).

المنتجات و FINAM IT Team

أولاً ، سأتحدث عن بعض منتجاتنا لتحديد سياق الشركة.

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

منصة التداول FinamTrade ، والتي لديها أيضًا معدل عمولة صفري للمبتدئين.

Comon.ru - نظام التكرار التلقائي لمعاملات المتداولين المحترفين - حل للمستثمرين المبتدئين وأولئك الذين ليس لديهم وقت فراغ كاف لإنشاء محفظة استثمارية خاصة بهم.

شبكة اجتماعية للتجار وأكثر من ذلك بكثير .

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

في التطوير ، نحن نستخدم كدسات تقنية مختلفة:

• الواجهة الأمامية: React.js ، VUE.js.
• اللغات: C # ، PHP ، C ++ ، Java ، mobile.
• قواعد البيانات: MSSQL ، PostgreSQL ، Oracle.
• المنصات: SharePoint و 1 C و Diasoft و MS CRM والمزيد.

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



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

سأقود قصتي على أمثلة فريقين ، وسأتصل بهم مشروطًا بالفريق 1 والفريق 2.

الفريق 1

طور الفريق الأول نظام معلومات داخلي. في البداية ، بدا الأمر كما يلي:

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

الفريق 2

طور الفريق الثاني عدة أنظمة داخلية:

• موظف واحد هو خبير في نظام واحد.
• موظف آخر هو خبير في النظم الأخرى.
• وقد تم تطوير بعض النظم من قبل كلا الموظفين معا.

عن الخبراء

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

أتصور أنه خبير مثل Jedi Master من فيلم "Star Wars" - يمكنه فعل أي شيء (جيدًا ، أو كل شيء تقريبًا).


لكن خبير جيدي لديه عيوبه:

• إنه بحاجة إلى "رفع" لفترة طويلة حتى يقبل هذه القوة.
• عندما يذهب في إجازة ، يكون دائمًا ما يلي: "ما الذي سنفعله جميعًا؟"

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

كان صداعنا الرئيسي هو السؤال "ماذا يحدث إذا حدث شيء للخبير ، كما في Master Yoda في الصورة أدناه؟"



وربما سمعت أيضا عن مفهوم عامل الحافلات.

عامل الحافلة

عامل الحافلة هو مقياس لتركيز المعلومات بين أعضاء المشروع الفرديين.

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

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

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

كما تعلمون ، في الفريقين 1 و 2 ، لم يكن الخبراء قابلين للتبادل ، وهذا خلق مشاكل محتملة. كان من الضروري القيام بشيء ما لزيادة عامل الحافلات ، وتوسيع كفاءات خبراء جدي. لقد اتخذنا الخطوات التالية.

الخطوة 1. زيادة عامل الحافلة

يجب أن لا يكون جدي وحده. لذلك ، من الضروري تدريب وتدريب الجدي ، حتى يكون هناك المزيد منهم.



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

عندما نقرر من سيصبح Jedi ، فإننا نتفق على Padawans ، ونوزع الأدوار ونتصورها في جدول الإدارة:



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

هناك بعض القواعد التي اتفقنا عليها لبدء التوزيع.

قواعد التوزيع ، الجزء 1:

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

يبدو أن كل شيء تم توزيعه بشكل منطقي ، واتضح كما يلي:



في أول فريق يعمل على منتج واحد ، عمل شخص واحد على المنتج القديم (Sunset) ، والآخر على المنتج الجديد (Sunset 2.0). في الإصدار "الخاص" من المنتج ، كان الموظف يعتبر جديًا ، في الإصدار "الأجنبي" - Padawan ، طالب موظف آخر.



في الفريق الثاني ، تم تسجيل الموظفين الذين وصلوا حديثًا في Padawans ، لأنهم ما زالوا لا يعرفون شيئًا عنهم. ثم تشبه لعبة Sudoku - نحاول الحصول على نفس العدد تقريباً من Jedi و Padawans في الصفوف والأعمدة.

الخطوة 2. السيطرة على تبادل المعرفة

ولكن كيف يمكن التحقق من أن Padawan سينمو ليصبح جديًا ، ويمتلك كل قوة المعرفة؟

نصلح المعرفة

للقيام بذلك ، نقوم بإصلاح معرفة منتجاتنا: قم بعمل قائمة بكل المعرفة ووضعها في جدول. لكل منتج من المنتجات على صفحة التقاء منفصلة ، نكتب ببساطة المعرفة التي يتكون منها المنتج ويتحللها. يمكن أن يتم تحليل المعرفة بطرق مختلفة ، وأذكر أن هذه الجداول يتم رسمها أسفل الصفحة مع توزيع Jedi و Padawans. على سبيل المثال ، بالنسبة للفريق 1 ، صفحة واحدة للمعرفة Sunset ، صفحة أخرى للمعرفة Sunset 2.0.

مزيد من لقطات من التقاء لدينا مع أمثلة من التحلل.

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



حسب الوظيفة. هنا قمنا برسم وحدات المعرفة على صفحات وأقسام النظام.



للمعرفة التقنية. وضعنا بعض المنتجات ببساطة وفقا للمعرفة التقنية للفريق.



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

إضافة الوثائق

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

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

إضافة تصنيفات

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



سوف فك رموز التصنيفات:

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

في الإصدار الأول ، حصلنا على خمس درجات - علمتنا المدرسة أن نحسب من 1 إلى 5. ولكن بعد ذلك تبين أن نظام النقاط الأربع يكفي ، لقد توقفنا عن ذلك.

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

الخطوة 3. تصور ذلك

في الخطوة الثالثة ، نشأ السؤال - كيف يمكنني ، كمدير ، أن أرى على الفور وبوضوح كيف يحدث تراكم المعرفة داخل الفريق؟

لقد تصورنا الحالة الراهنة من خلال رسم مربعي جدي وبادوان بألوان مختلفة: الأخضر - اكتمل التدريب ، والرمادي - في عملية التعلم ، الأحمر - لم تبدأ الدراسة. في البداية ، عادة ما يكون هناك الكثير من اللون الأحمر ، ولكن في النهاية يجب أن يتحول الجميع إلى اللون الأخضر.

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



بعد ذلك ، صقلنا قواعدنا أكثر.

قواعد التوزيع ، الجزء 2:

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

تفريق الاحتياجات

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

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



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

والآن يتم رسم لوحاتنا وأصبح كل شيء أكثر إثارة للاهتمام ومفهومة:



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

عندما أضفنا وظائف جديدة ، ظهرت النرد الأحمر. ثم في اجتماع Timlid التالي ، فحصنا ما إذا كانت تظل حمراء. إذا كان الأمر كذلك ، فقد بدأوا في معرفة سبب عدم تقدم التدريب خلال أسبوعين. في حالة اختفاء اللون الأحمر ، تبقى المربعات الرمادية ، نقوم بفحصها بشكل دوري. تم تسجيل نتائج اجتماع الفريق في Confluence على قوائم الشيكات ، حيث تمت الإشارة إلى الحالة. على سبيل المثال: "الموظف 1 - المستوى 10 من 20". إذا لم تتغير هذه القيم خلال أسبوعين ، فقد بدوا السبب.

كل موظف جديد موجود دائمًا في المنطقة الحمراء ، يجب تدريبه وضخه في أسرع وقت ممكن. لكن كيف؟

الخطوة 4. ضخ المعرفة والمهارات

ملء: ملء الوثائق

لقد توصلنا إلى أننا يجب أن نسعى جاهدين لضمان توافق صف واحد من الجدول المتحلل للمنتج مع معرفة واحدة (صفحة واحدة من الوثائق).



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

نحن نستخدم طريقتين ملء:

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

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

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

لذلك ، قمنا بتوثيق كل ما نحتاجه. الخطوة التالية هي التحديث.

تحديث

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

إذا كان فريقك الموجود في مساحة التقاءك مشتركًا في هذه التغييرات ، فسيتلقى إعلامات حول ما تمت إضافته أو تغييره أو تحسينه ، لأنه يوجد في Atlassian Confluence:

• محفوظات تغييرات الصفحة - يمكنك دائمًا رؤية ما ومتى تغير.
• الاشتراك في تحديثات الصفحة الإخطارات.
• حذف من خلال القمامة.

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

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

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

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

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

استخدام

?



. . , 4 , . , , - . , , . , , . , .

, . : « , . , ».

, — , . «», , . , : « , . ».



. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .

« »

KPI, : « - KPI , - - , ». , , , , . — .

— , , .

Bus factor

: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».

, , . () . , , . ( ). . , — . .


. , , . , . , . .

النتائج

, , , .

« ! ». . !

TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !