Microservices والهيكل التنظيمي. ما هي أنواع الفرق التي ستضمن النجاح؟

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

النهج التقليدي


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

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

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

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

الأوامر الوظيفية المتقاطعة


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


الشكل 1. فرق وظيفية وعبر وظائف.

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

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

وفقًا للدراسات الاستقصائية التي أجراها معهد ماساتشوستس للتكنولوجيا و Deloitte Global Human Capital Trend ، تعتمد الشركات التي تتمتع بمستوى عالٍ من رقمنة العمليات في تطوير ابتكاراتها اعتمادًا كبيرًا على وجود فرق متعددة الوظائف. 83٪ من الشركات الناضجة تعترف بأنها تستخدم فرقًا متعددة الوظائف. على الرغم من زيادة التعقيد التشغيلي (تكاليف إضافية تصل إلى 16 ٪) ، تلقت الشركات تحسينات كبيرة في مؤشرات التشغيل (تصل إلى 53 ٪) ، وتحسين الوصول إلى الموارد والأصول (تصل إلى 37 ٪) ، وزيادة المرونة (تصل إلى 12 ٪) وانخفاض في مستوى البيروقراطية المفرطة بسبب الحد من التسلسل الهرمي للهيكل التنظيمي (ما يصل إلى 11 ٪).


الشكل 2. فوائد تكييف فرق متعددة الوظائف. الإحصاءات.

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


الشكل 3. الانتقال إلى فريق متعدد الوظائف.

ظهور فرق منصة


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

  • تزامن (اتساق) البيانات ؛
  • تقادم البيانات
  • الأمن؛
  • التواصل بين الخدمات
  • اكتشاف الخدمة ؛
  • قطع الأشجار والمراقبة الموزعة ؛
  • التبعيات الدورية بين الخدمات وتصحيح الأخطاء ؛
  • اختبار.
  • الموثوقية والتسامح مع الخطأ ؛
  • الأداء.

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

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

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

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

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

فريق تطوير المنصة (يُشار إليه اختصارًا باسم فريق المنصة) هو فريق متخصص متعدد الوظائف يدير المنصة الرقمية - الأساس لتشكيل واجهات برمجة التطبيقات (API) والأدوات والخدمات ، ويتم تنظيم معرفتها ودعمها في منتج داخلي مستقل.

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

  • البنية التحتية للتوصيل
  • بنية API وإصلاح.
  • بيانات الخدمة الذاتية
  • البنية التحتية التجريبية والقياس عن بعد ؛
  • التفاعل مع العميل.


الشكل 4: إستراتيجية المنصة الرقمية

تتاح لفرق الخدمة المصغرة القائمة بذاتها الفرصة لاستخدام المنصة لتسريع الدعم لوظائف منتجاتها وفي نفس الوقت تقليل درجة التنسيق الضروري بين الفرق.

لا شك أن مفهوم فرق المنصات المتخصصة المخصصة له مزايا وعيوب:

وتشمل الفوائد:

  • توحيد وتسلسل قنوات الاتصال ؛
  • توفير التحكم مع الحفاظ على مرونة فرق التطوير الفردية.

العيوب تشمل:

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

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

تآزر التفاعل


لذا ، كيف يمكن أن يحدث التفاعل مع فريق المنصة؟ هناك العديد من الطرق الممكنة ، والتي يمكن تمييز اثنين منها:

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


الشكل 5: التفاعل مع فريق تطوير المنصة: على اليسار هي المنصة كمنتج ، وعلى اليمين تغلغل في الفرق.

استنتاج


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

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

Source: https://habr.com/ru/post/ar477634/


All Articles