إن فلسفة DevOps، عندما يتم دمج التطوير مع صيانة البرامج، لن تفاجئ أحداً. يكتسب الاتجاه الجديد زخمًا - DevOps 2.0 أو BizDevOps. فهو يجمع بين ثلاثة مكونات في كل واحد: الأعمال والتطوير والدعم. وكما هو الحال في DevOps، تشكل الممارسات الهندسية أساس العلاقة بين التطوير والدعم، وفي تطوير الأعمال، تأخذ التحليلات دور "الغراء" الذي يوحد التطوير مع الأعمال.
أريد أن أعترف على الفور: لقد اكتشفنا الآن أن لدينا تطورًا حقيقيًا في الأعمال، بعد قراءة الكتب الذكية. لقد تحقق ذلك بطريقة ما بفضل مبادرة الموظفين وشغف التحسين الذي لا يمكن كبته. أصبحت التحليلات الآن جزءًا من عملية إنتاج التطوير، مما يقلل بشكل كبير من حلقات التعليقات ويقدم رؤى بشكل منتظم. سأخبرك بالتفصيل كيف يعمل كل شيء بالنسبة لنا.
عيوب DevOps الكلاسيكية
عندما يتم تصور منتجات جديدة للعملاء، تقوم الشركة بإنشاء نموذج مثالي لسلوك العملاء وتتوقع تحويلًا جيدًا، على أساسه تبني أهدافها ونتائجها التجارية. يسعى فريق التطوير، من جانبه، إلى إنشاء كود جيد جدًا وعالي الجودة. دعم الآمال في الأتمتة الكاملة للعمليات وسهولة وراحة صيانة منتج جديد.
غالبًا ما يتطور الواقع بطريقة تجعل العملاء يتلقون عملية معقدة إلى حد ما، وتظل الشركة عالقة في تحويلات منخفضة، وتقوم فرق التطوير بإصدار الإصلاح بعد الإصلاح، ويغرق الدعم في تدفق الطلبات من العملاء. تبدو مألوفة؟
يكمن جذر الشر هنا في حلقة ردود الفعل الطويلة والضعيفة المضمنة في العملية. تتواصل الشركات والمطورون، عند جمع المتطلبات وتلقي التعليقات أثناء سباقات السرعة، مع عدد محدود من العملاء الذين يؤثرون بشكل كبير على مصير المنتج. في كثير من الأحيان، ما هو مهم لشخص واحد ليس نموذجيًا على الإطلاق بالنسبة للجمهور المستهدف بأكمله.
إن فهم ما إذا كان المنتج يتحرك في الاتجاه الصحيح يأتي من خلال التقارير المالية ونتائج أبحاث السوق بعد أشهر من إطلاقه. ونظرًا لحجم العينة المحدود، فإنها لا توفر الفرصة لاختبار الفرضيات على عدد كبير من العملاء. بشكل عام، اتضح أنها طويلة وغير دقيقة وغير فعالة.
أداة الكأس
لقد وجدنا طريقة جيدة للهروب من هذا. الأداة التي كانت تساعد المسوقين فقط في السابق وجدت طريقها الآن إلى أيدي الشركات والمطورين. لقد بدأنا في استخدام تحليلات الويب بنشاط من أجل إلقاء نظرة على العملية في الوقت الفعلي، هنا والآن لفهم ما يحدث. وبناءً على ذلك، قم بتخطيط المنتج نفسه وطرحه على عدد كبير من العملاء.
إذا كنت تخطط لنوع ما من تحسين المنتج، فيمكنك على الفور معرفة المقاييس المرتبطة بها، وكيف تؤثر هذه المقاييس على المبيعات والخصائص المهمة للأعمال. بهذه الطريقة يمكنك التخلص فورًا من الفرضيات ذات التأثير المنخفض. أو، على سبيل المثال، طرح ميزة جديدة لعدد كبير من المستخدمين إحصائيًا ومراقبة المقاييس في الوقت الفعلي لفهم ما إذا كان كل شيء يعمل على النحو المنشود. لا تنتظر ردود الفعل في شكل طلبات أو تقارير، ولكن قم بمراقبة عملية إنشاء المنتج وتعديلها بنفسك على الفور. يمكننا طرح ميزة جديدة، وجمع البيانات الصحيحة إحصائيًا في ثلاثة أيام، وإجراء تغييرات في ثلاثة أيام أخرى - وفي غضون أسبوع، يصبح المنتج الجديد الرائع جاهزًا.
يمكنك تتبع مسار التحويل بأكمله، وجميع العملاء الذين اتصلوا بالمنتج الجديد، واكتشاف النقاط التي ضاقت فيها مسار التحويل بشكل حاد، وفهم الأسباب. يراقب كل من المطورين والشركات هذا الأمر الآن كجزء من عملهم اليومي. إنهم يرون نفس رحلة العميل، ويمكنهم معًا توليد أفكار وافتراضات للتحسين.
يتيح هذا التكامل بين الأعمال والتطوير جنبًا إلى جنب مع التحليلات إمكانية إنشاء منتجات بشكل مستمر، وتحسينها باستمرار، والبحث عن الاختناقات ورؤيتها، والعملية بأكملها ككل.
الأمر كله يتعلق بالتعقيد
عندما نقوم بإنشاء منتج جديد، فإننا لا نبدأ من الصفر، بل ندمجه في شبكة الخدمات الموجودة بالفعل. عند تجربة منتج جديد، غالبا ما يتصل العميل بالعديد من الأقسام. يمكنه التواصل مع موظفي مركز الاتصال، أو مع المديرين في المكتب، أو يمكنه الاتصال بالدعم، أو في المحادثات عبر الإنترنت. باستخدام المقاييس، يمكننا أن نرى، على سبيل المثال، ما هو الحمل على مركز الاتصال، وأفضل السبل لمعالجة الطلبات الواردة. يمكننا أن نفهم عدد الأشخاص الذين يصلون إلى المكتب ونقترح كيفية تقديم المزيد من المشورة للعميل.
إنه نفس الشيء تمامًا مع أنظمة المعلومات. لقد كان بنكنا موجودًا منذ أكثر من 20 عامًا، وخلال هذه الفترة تم إنشاء طبقة كبيرة من الأنظمة غير المتجانسة وما زالت تعمل. قد يكون التفاعل بين أنظمة الواجهة الخلفية غير متوقع في بعض الأحيان. على سبيل المثال، في بعض الأنظمة القديمة توجد قيود على عدد الأحرف في حقل معين، وفي بعض الأحيان يؤدي ذلك إلى تعطل الخدمة الجديدة. من الصعب للغاية تتبع الخلل باستخدام الطرق القياسية، ولكن باستخدام تحليلات الويب يكون الأمر سهلاً.
وصلنا إلى النقطة التي بدأنا فيها بجمع وتحليل نصوص الأخطاء التي تظهر للعميل من جميع الأنظمة المعنية. اتضح أن الكثير منهم قد عفا عليهم الزمن، ولم نتمكن حتى من تخيل أنهم شاركوا بطريقة أو بأخرى في عمليتنا.
العمل مع التحليلات
يتواجد محللو الويب وفرق تطوير SCRUM لدينا في نفس الغرفة. يتفاعلون باستمرار مع بعضهم البعض. عند الضرورة، يساعد المتخصصون في إعداد المقاييس أو تنزيل البيانات، ولكن في الغالب يعمل أعضاء الفريق أنفسهم مع خدمة التحليلات، فلا يوجد شيء معقد هناك.
تكون المساعدة مطلوبة، على سبيل المثال، إذا كنت بحاجة إلى بعض التبعيات أو عوامل التصفية الإضافية لنوع محدود من العملاء أو المصادر. لكن في الهندسة المعمارية الحالية نادراً ما نواجه هذا.
ومن المثير للاهتمام أن تنفيذ التحليلات لم يتطلب تركيب نظام جديد لتكنولوجيا المعلومات. نحن نستخدم نفس البرنامج الذي عمل معه المسوقون سابقًا. كان من الضروري فقط الاتفاق على استخدامه وتنفيذه في مجال الأعمال والتنمية. بالطبع، لم يكن بوسعنا أن نأخذ ما قدمه التسويق فحسب، بل كان علينا إعادة تشكيل كل شيء من جديد ومنح التسويق إمكانية الوصول إلى البيئة الجديدة بحيث يكونون في نفس مجال المعلومات معنا.
في المستقبل، نخطط لشراء نسخة محسنة من برنامج تحليلات الويب الذي سيسمح لنا بالتعامل مع الأحجام المتزايدة للجلسات المعالجة.
نحن أيضًا نعمل بنشاط على دمج تحليلات الويب وقواعد البيانات الداخلية من أنظمة إدارة علاقات العملاء والأنظمة المحاسبية. من خلال دمج البيانات، نحصل على صورة كاملة للعميل في جميع الجوانب الضرورية: حسب المصدر ونوع العميل والمنتج. ستصبح خدمات ذكاء الأعمال التي تساعد في تصور البيانات متاحة قريبًا لجميع الأقسام.
ماذا انتهى بنا الأمر؟ في الواقع، لقد جعلنا التحليلات واتخاذ القرار بشأنها جزءًا من عملية الإنتاج، وكان لها تأثير واضح.
التحليلات: لا تخطو على أشعل النار
وأخيرًا، أريد أن أشارككم بعض النصائح التي ستساعدكم على تجنب الوقوع في المشاكل أثناء عملية بناء أعمال تطوير الأعمال.
- إذا لم تتمكن من إجراء التحليلات بسرعة، فأنت تقوم بالتحليلات الخاطئة. أنت بحاجة إلى اتباع مسار بسيط من منتج واحد ثم توسيع نطاقه.
- يجب أن يكون لديك فريق أو شخص لديه فهم جيد لبنية التحليلات المستقبلية. لا تزال بحاجة إلى اتخاذ قرار بشأن كيفية توسيع نطاق التحليلات ودمجها في أنظمة أخرى وإعادة استخدام البيانات.
- لا تقم بإنشاء بيانات غير ضرورية. تعد إحصائيات الويب، بالإضافة إلى المعلومات المفيدة، أيضًا مكبًا ضخمًا للقمامة يحتوي على بيانات منخفضة الجودة وغير ضرورية. وسوف تتداخل هذه القمامة مع عملية صنع القرار والتقييم إذا لم تكن هناك أهداف واضحة.
- لا تقم بالتحليلات من أجل التحليلات. أولاً، الأهداف، واختيار الأداة، وعندها فقط - التحليلات فقط حيث سيكون لها تأثير.
تم إعداد المادة بالاشتراك مع تشيبوتار أولجا ().
المصدر: www.habr.com