☀️ 😙 🍱 كيفية جعل الجيران يعملون على مشروعهم ، أو InnerSource لأحد البنوك 🏀 📍 💪🏼

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

ما هو المصدر الداخلي؟

في عام 2000 ، وصف Tim O'Reilly مصطلح المصدر الداخلي بأنه خطوة محتملة نحو شركة مغلقة تدخل عالم مفتوح المصدر جميل. هذا هو تطبيق أفضل الممارسات من المصادر المفتوحة داخل الشركة: من الانفتاح العام والمساعدة المتبادلة الاستباقية إلى تشكيل سوق لأفضل الحلول. تستمر الشركة في كتابة رمز الملكية ، ولكن كل موظف لديه الفرصة لتحسين أي نظام داخلي.

يمكن سرد مزايا InnerSource لفترة طويلة: تقليل الوقت اللازم للتسويق ، وتحسين جودة التعليمات البرمجية ، واستبدال التوظيف الخارجي بداخل العمل ، وتحسين التفاعل بين الفرق ، وما إلى ذلك.

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

بالطبع ، Sberbank ليست الشركة الوحيدة التي حدثت للقيام بشيء من هذا القبيل. في عام 2015 ، تم إنشاء مجتمع InnerSource Commons ، مما أدى إلى تعميم النهج وإزالة الفجوة من المصطلح لتسهيل العثور عليه في محركات البحث. جمع هذا المجتمع تجربة عشرات الشركات وقدم توصيات فعالة لتطبيق InnerSource في شركتك ، وعقد مؤتمر تبادل الخبرات مرتين في السنة. لا يزال هناك العديد من شركات التكنولوجيا المعروفة التي تقوم بذلك ~~منذ Pechenegs و Polovtsy~~ قبل أن تصبح سائدة.

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

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

لماذا أجمعها؟

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

في نهاية الاستطلاع حول ما آلم المهندسين ، في نهاية 2018 في Sber ، تقرر إنشاء SberWorks قبلية ، والتي تولت كل ما يتعلق بعمليات وأدوات إنتاج البرامج في البنك. اتبعت مهام وأهداف الوحدة بشكل كامل تقريبًا من قائمة آلام المطورين المجمعة.

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

ماذا تفعل بكل هذا؟

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

اثنان. قم بإنشاء نوع من "المظلة" مع محرك بحث واحد على جميع الأدوات الهندسية (JIRA ، Confluence ، Bitbucket ، Nexus) ، مع الجمع بين القطاعات الداخلية والخارجية (نعم ، ألفا سيجما سيجما).

ثلاثة. يجب أن تكون التعليمات البرمجية والتراكم والتحف ، باستثناء تلك التي تمنع صراحةً فتح الأمان ، مفتوحة لجميع موظفي الشركة.

ما تم اقتراحه؟

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

"انتظر"

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

التسويات

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

"كعب دائم مؤقت"

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

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

InnerSource

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

طريقنا

في البداية ، بدا لنا أننا بحاجة إلى العثور على الأماكن التي سيكون فيها InnerSource في الطلب الأقصى في الوقت الحالي. بينما كنا نفكر في كيفية القيام بذلك ، دون الوقوع في دائرة من الاستطلاعات التي لا نهاية لها ، قدرت القيادة الحكيمة الفكرة واقترحت ضمان استعداد مائة بالمائة من مائة بالمائة من أنظمة Sberbank بحلول نهاية العام. سئمنا ، سأل مديرنا "ما هو مائة بالمائة؟" ، وتم تخفيض عدد الأنظمة بنحو 20 مرة إلى الحديثة و / أو الحرجة للأعمال.

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

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

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

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

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

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

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

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

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

خاتمة

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

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

نحن نعتقد أن الفوائد الناتجة تثبط تمامًا الجهد المستثمر ، والانفتاح في حد ذاته له مزايا لا حصر لها. نحن مستعدون لإخبار مسارنا بمزيد من التفاصيل وتبادل الخبرات ، وكتابة مكالمة - innersource@sberbank.ru . القبلات ، سبيربانك.