رحلة إلى الماضي
أعمل في خدمات ICL منذ أكثر من 4 سنوات ، وبدأت كمتخصص دعم فني في مشروع كبير. الآن أقود مجموعة ITSM في اتجاه مكتب الخدمة - تتركز كفاءاتي في نشر وتكوين أنظمة ITSM ، وإدارة عمليات تكنولوجيا المعلومات (الحوادث ، التغيير ، إدارة المشكلات). في الواقع ، بدون مبالغة ، يمكنني القول: إن أكثر الأشخاص مهارة في مجال التنمية المستدامة يعملون في مجموعتي.
إن خصوصية شركة كبيرة ، التي اكتشفتها بعد العمل فيها لمدة ستة أشهر تقريبًا من لحظة التوظيف ، هي ما يلي: نادرًا ما يشارك الناس أفضل ممارساتهم. ليس لأنهم كانوا جشعين ، ولكن ببساطة لأنهم كانوا كسالى للغاية ليشرحوا لزملائهم ما هي الفائدة. بعد كل شيء ، كما يحدث غالبًا ، كان كل شخص هنا تقنيًا مع علاقات طويلة الأمد.
وبعد ذلك أتيت - وأرى أن أحدهم لديه نصوص رائعة تسمح ببعض العمل تلقائيًا ، والآخر يحتفظ بجدول مناوباته في تطبيق سحابي ولا يخلط أبدًا بين التحولات (وفي تلك الأوقات العصيبة ما زلنا نستخدم Excel) ، كتب الثالث رسالة بسيطة تطبيق ويب يعرض جميع مجالات التطبيق على شاشة واحدة حتى لا يضيع الوقت في تبديل علامات التبويب في نظام ITSM وفتحها عند فحص التطبيقات.
لكن هذه التطورات ظلت فردية ولم تتم مشاركتها مع فريق المشروع بأكمله ، ناهيك عن أي تطبيقات على مشاريع مماثلة. كما قال قائدي ، لقد قمنا دائمًا بإعادة اختراع دراجتنا بمفردنا - وكنت على حق في هذه القضية. بالطبع ، كان هناك أيضًا عامل بشري: على سبيل المثال ، كان هناك شخص أكثر خبرة ، ولا يمكنه استخدام أفضل ممارسات "الشباب". وكلاسيكية خاصة - "لكننا معه صراع شخصي ولن استخدم الادوات التي يستخدمها ".
لقد كان ناجحًا بالنسبة لي ، وبشكل عام بالنسبة لقسمنا بأكمله ، تم تقديم واختبار مناهج جديدة للعمليات. أطنان من الوثائق ، وعواء من المستخدمين ومجموعات الدعم - كل شيء كالمعتاد. تمكنت من دفع التحسينات التي رأيتها ، ولكن الأهم من ذلك ، تمكنت من إشراك جميع اللاعبين تقريبًا في العمل معًا في الخدمة. بعد كل شيء ، هل تعرف ما الذي يمكن أن يفعله الفريق الذي توحد ضد مشكلة؟ المشكلة ليس لها فرصة. قدم العميل مؤشرًا جديدًا - النسبة المئوية للأخطاء عند ملء الطلبات. في البداية ، كانت النسبة حوالي 10٪ لكل فريق ، أي أن حوالي 200 تطبيق بها أخطاء طفيفة وأخرى كبيرة.
قال قادة الخط والمشروع ، "من المستحيل تقليل نسبة الأخطاء بشكل أكبر - فالناس بشر ، وسيكونون على خطأ دائمًا ". قمنا بتكرار تطبيق ويب كتبه متخصصنا الرائد ، وقمنا بتعيين نقاط تحكم وأخذنا معلومات بانتظام عن هذه المؤشرات ، وعملنا على حالات محددة: عندما يستبدل نظام ITSM نفسه الحقول الضرورية من Active Directory ، ما الذي تبحث عنه. لم تكن النتيجة طويلة - في ستة أشهر قمنا برفع النسبة المئوية للأخطاء شهريًا إلى المستوى المنخفض للغاية وهو 0-0.6٪ لكل فريق.
وحول هذه النقطة من مسيرتي المهنية ، أدركت شيئين:
- أريد أن أعمل في فريق رائع ، ونتيجة عمله بالكامل أفضل بكثير مما يمكن أن يفعله حتى أكثر الموظفين ذكاءً. هذا القرار سيقودني بالتأكيد إلى الإدارة لاحقًا.
- أريد أن أجمع إنجازات الرجال الموهوبين والرائعين في نظام واحد أفضل وأكثر موثوقية وأسرع من النظام الذي كان لديك من قبل.
بداية المشروع
في عام 2019 ، عُرض عليّ قيادة مشروع SD الرقمي ، والذي كان علينا من خلاله أن نجعل خدماتنا أكثر تنافسية بمساعدة التقنيات الحديثة: التعلم الآلي ، والعديد من برامج الروبوت الصوتية والنصية ، والأنظمة الأساسية متعددة القنوات ، والتصنيفات التلقائية ، وتطبيقات الحل التلقائي. بعبارة أخرى ، كل تلك الأشياء التي تنقل تجربة العميل إلى مستوى جديد دون زيادة تكاليف العمالة لتقديم الخدمة.
بصراحة ، بعد النظر إلى الضجيج الكامل حول الذكاء الاصطناعي ، في البداية كنت متشككًا جدًا بشأن المهمة. ويبدو أن الاتجاه صحيح ، والهدف جيد ، لكن كان هناك خطأ ما هنا.
والصيد هو أن لا أحد يعرف بالضبط ما الذي يجب تطويره. هناك الكثير من الاتجاهات ، ما الذي يجب الإمساك به؟ عادة في مثل هذه اللحظات في المقالات أو الكتب يكتبون بثقة: "حتى ذلك الحين عرفنا كيف وأين نتحرك". لذا ، هذا لا يتعلق بنا. وقفت مع مالك المنتج وأعدت قائمة بالأسئلة التي احتجنا للإجابة عليها عند تصميم المنتج:
- ما هي الوظائف المفيدة التي نقدمها للمستخدم والعميل؟
- كيف يندمج هذا في الخدمة الحالية؟
- كيف يجب عليك تغيير سير العمل الحالي الخاص بك حتى يعمل هذا ويكون مفيدًا؟
- كيف وبأي تقنيات يجب القيام بذلك؟
- كيف ينبغي بناء نموذج الحل الاقتصادي؟
لكننا فعلنا ذلك بشكل مدروس تمامًا: لقد جمعنا مجموعة من الخبراء من SD من بين مديري المشاريع ، والمديرين المباشرين ، والخبراء التقنيين ، وكتبنا قصص المستخدمين ، ووضعنا خريطة قيمة - إليك جزء صغير منها:
بالتوازي ، مع المطورين ، وصفنا بنية المستوى الأعلى ، وبالتالي الحصول على نقطة انطلاق في المشروع ...
عمل SCRUM
لذا مقدماتنا: Product Owner و PM و Scrum Master و Development Team. سباق سريع يعمل لمدة أسبوعين. المهمة هي تنظيم عملية إطلاق المنتج بطريقة ...
ولكن بجدية ، كان من الضروري مراعاة متطلبات جميع أصحاب المصلحة ، والتعامل مع المتاعب وفهم ما يجب فعله حقًا ، وما يمكن فعله لاحقًا ، وما لا يجب فعله على الإطلاق.
كان لدينا 3 مجالات نشاط كبيرة:
- . , , , .
- . , «» .
- . HR, , IT, . .
تمكنا من تأسيس عمل عادي فقط في السباق الثالث: لقد أدركنا بشكل أو بآخر أننا بحاجة إلى التركيز على المناطق 1 و 2 ، لأن مديري المشاريع يتحدثون عن الألم ، ويتحدث رؤساء خدمات الدعم عن الرغبات.
لن أطيل المقالة وأخبرك بمدى روعة Agile في حد ذاته وكيف أنها تساعد كثيرًا. ولكن إليك ما يمكنني قوله حقًا بعد العمل في هذا الوضع لحوالي 30 سباقًا:
- سكرم هو نهج العمل. أنت تضع الموارد والمنهجية ، وتحصل على الإمدادات.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
لدي خبرة أقل من هذا النوع ، لذلك وقع هذا العبء الكبير والثقيل على عاتق مالك المنتج إلى حد كبير: لمقارنة توقعات أصحاب المصلحة بالواقع ، وفهم قدرات فريقي بوضوح ، والحصول على عين نظيفة ، وفهم حالة السوق ، والتوازن بين توجيه الموارد إلى وظائف مفيدة ، والتجارب و "الشر الضروري" - أمن الحلول ، تنظيم بنية الخدمة ، البيئات ، التوثيق.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
لم نبدأ التطوير من الصفر. كان لدينا الكثير من التطورات في الشركة التي يمكن استخدامها بشكل أو بآخر - كان هناك مصنفان آليان فقط.
شعرت بالديجافو عندما جمعت كل هذا من مختلف المشاريع والأقسام ، حيث جمعت ذات مرة التطورات في مشروعي الأول.
بدأنا في تطوير نظام الحوار مع العديد من المكتبات مفتوحة المصدر - وإحدى هذه المكتبات كانت DeepPavlov. لم تكن لدينا خبرة كبيرة في ذلك ، وفي مهامنا جاءت جودة الاعتراف دون المتوسط. سرعان ما تحولنا إلى Rasa ، وهناك سارت الأمور بشكل أفضل - وبعد تدريب النموذج على بياناتنا المحددة ، حصلنا على اعتراف جيد وواثق من الحوارات.
تم تخطيط الحوارات نفسها يدويًا - في تلك اللحظة كان هناك رجال في SD تولى هذه المهمة. كتب مطور Python الرئيسي لدينا بسرعة برنامج ترميز ، وقمنا بتغذية النموذج بعشرات الآلاف من المحادثات. تم أخذ الأجزاء قصيرة جدًا ، 3 ثوانٍ لكل منها - وبهذه الطريقة جاءت النتيجة أفضل.
في البداية ، كان لدينا جهازان ظاهريان على نظامي التشغيل Windows و Linux ، ويمكن لبعض الخدمات أن تعمل فقط مع Windows. ولكن عندما بدأنا في إدخال التطورات الأولى إلى البرنامج التجريبي ، أدركنا بسرعة أن جهازين افتراضيين لمشروع واحد مكلف للغاية ، وعلينا إعادة ذلك. الآن نستخدم جهازًا افتراضيًا واحدًا على Ubuntu للإنتاج. بالطبع ، كلهم منعزلون وكل مشروع له منطقته الخاصة.
وسرعان ما أدركنا أن إعداد جهازين افتراضيين ورفع جميع الخدمات وتصحيحها وفتح المنافذ والإعدادات الأخرى يستغرق وقتًا غير لائق تمامًا. بعد ذلك قمنا بعمل حل CI / CD يعتمد على Docker - لكل من الكود الرئيسي وجزء ML.
في مكان ما في السباق من 9 إلى 10 ، واجهنا طلبًا من العديد من العملاء لإنشاء نظام التعرف على الكلام الخاص بهم. لم يكن معظم العملاء مستعدين على الإطلاق لنقل معلوماتهم السرية إلى "السحاب" إلى أطراف ثالثة. لذلك ، كتبنا مثل هذا النظام ويمكننا الآن تقديمه حيث من المهم أن يكون لدينا الهيكل بأكمله داخل المحيط الأمني - على سبيل المثال ، للشركات ذات الصلة الوثيقة بالدولة. أو ضعها في بنيتنا التحتية ، مع العلم على وجه اليقين أن البيانات الحساسة لن تصل إلى أطراف ثالثة.
لقد نشرنا نظامًا لمراقبة المكونات وأعدنا فحوصات صحية ودمجنا النظام مع قناة دردشة في Telegram.
وأخيرًا ، سأخبرك عن دقة أخرى قد تكون مفيدة لشخص ما عند تصميم روبوت الدردشة الخاص به. في البداية ، كانت جميع التعليمات البرمجية متجانسة تمامًا وكان إجراء تغييرات عليها شاقًا. لقد قسمنا chatbot إلى جزأين كبيرين: الروبوت الأساسي والتخصيص. كان علينا إعادة كتابة المنطق - ولكن بفضل هذا الفصل ، تمكنا من نشر المكونات الأساسية والمشتركة للروبوت بسرعة وتحرير فقط ما كان مخصصًا لكل مشروع محدد.
نتائج المشروع
لقد فهمنا بوضوح الطبيعة المتخصصة لتاريخنا: لن نكون قادرين على التنافس مع المنتجات المعبأة التي تم تطويرها لعشرات السنين ، ولا داعي لذلك أيضًا. تخصصنا هو توفير أدوات التشغيل الآلي في أي مرحلة من مراحل مشروع الخدمة ، من البيع المسبق إلى انتهاء صلاحية العقد. بعبارة أخرى ، لم يكن لدينا هدف في البداية لإنشاء Google - ولكن كان الهدف إنشاء مصمم يساعد في بيع مكتب الخدمة ، ويساعد في تقليل تكلفة تقديم الخدمة ، ويوفر فرصًا إضافية للعملاء وأعمالهم.
لقد لاحظت أيضًا نقطة مثيرة للاهتمام بالنسبة لي: نادرًا ما يمكن أن يغطي الحل المعبأ في السوق معاناة العميل تمامًا وفي نفس الوقت يرتب السعر. إما أن يدفع العميل مبالغ زائدة مقابل الوظيفة التي لن يستخدمها لاحقًا ، أو أن بعض التحسينات يجب أن يتم إجراؤها بواسطة المتخصصين أو المتخصصين من البائع المحدد ، إذا استلمها.
وهنا لدينا مهمة تكامل مثيرة للاهتمام وصعبة إلى حد ما ، بالإضافة إلى تقديم حلول الأتمتة الخاصة بنا فقط ، لبناء نظام للعميل من تطوراتنا وحلول الطرف الثالث الموجودة بالفعل في السوق ، وتناسب وظائف العميل وتحافظ على مثل هذا النظام كخدمة. ربما سأتحدث عن نتائج هذا العمل في المقالات التالية ، إذا كان هناك اهتمام.
لقد تم بالفعل تنفيذ معظم أدواتنا وتطوراتنا في الخدمات الحالية ، ونقوم بتجربة بعضها ، وسنقوم بتحسين بعضها في جامعة BAU. لا يزال برنامج الدردشة الآلي يشعر بالسوء على الإطلاق ، وهو اليوم أقل فائدة للمشاريع - ربما لأن التوقعات الآن عالية جدًا. يريد الجميع روبوتًا ذكيًا يمكنه إدراك الكلام البشري ، والإجابة بهدوء على جميع أسئلة المستخدم ، والقدرة على التعامل مع المقاطعات ، والتكامل في جميع الأنظمة ، ويتعلم نفسه دون تدخل بشري ، ويتعرف بمرور الوقت على المزيد والمزيد من النوايا.
لكن أي مطور على دراية بالموضوع يدرك مدى صعوبة هذه المهمة - بعد كل شيء ، حتى من خلال زيادة الوظائف وزيادة عدد النوايا التي يمكن أن يتعرف عليها الروبوت ، يمكننا أن نزيد من سوء التعرف على النوايا الحالية. لكن هذا كان انحرافًا - بشكل عام ، يبدو لي أننا مع ذلك تعاملنا مع المهمة الرئيسية للمشروع.
ماذا حدث عند المخرج
1. مساعد صوت ذكي ومنشئ النص لذلك. يغلق الحاجة إلى أتمتة تدفق المكالمات الواردة ، ويتعرف على كلام المستخدم والصوت إلى نص وينقله إلى البريد والدردشة ونظام ITSM ، اعتمادًا على الإعداد. يمكن أن يتكامل مع مجموعة من الأنظمة المختلفة ، إما مع موصلات جاهزة ، أو مع تلك التي كتبناها.
2. طالب مع المحرك من المساعد الصوتي.يغلق الحاجة إلى الاتصال بمجموعة الأرقام المحددة ثم يجمع ردود المستخدمين حسب السيناريو. من الممكن إجراء مكالمات منتظمة ، هناك إعداد لعدد الأسئلة المتكررة لتوضيح عدد المرات وبعد أي وقت لمعاودة الاتصال. يخزن بيانات المكالمات التي تم إجراؤها مع نتائج المكالمات وتسجيل المكالمات. يتم استخدامه الآن لتذكير المهندسين بالتصحيح في مشروع تم تنفيذه لصالح بائع تجزئة دولي كبير للمواد الغذائية ، في قسم الموارد البشرية عند تنظيم المقابلات للمناصب الجماعية ، في خطط لجمع المعلومات حول جودة التطبيقات التي تم حلها في سلسلة مطاعم وجبات سريعة كبيرة.
3. روبوت محادثة لإنشاء تطبيق وإعادة تعيين كلمة مرور ومصمم نصي له.يعرف كيفية طلب المعلومات الأساسية لتسجيل طلب ، وتسجيل طلب في نظام ITSM ، وإرجاع رقم الطلب. بحلول الوقت الذي يتم فيه نشر المقالة ، سيتعلم إظهار قائمة بالتطبيقات المفتوحة مع إمكانية إضافة معلومات إليها أو إغلاقها. يمكنه الاتصال بأنظمة ITSM مختلفة ، مع أو بدون وصول API.
4. أداة لمراقبة الجودة. إنه يعرف القليل حتى الآن: فهو يتتبع المكالمات ، ويتعرف على ما إذا كان المشغل قد استقبل أم لا ، ويحدد الكلمات المولدة للنزاع ، ويتشارك في حوار ، ولديه واجهة كاملة لمراقب الجودة. لقد فعلوا ذلك لأنفسهم ، ولكن يمكن أن يكون مفيدًا في CC.
5. المصنف التلقائي.إنه قادر على تحليل التطبيقات في نظام ITSM ، وملئها وإرسالها إلى مجموعات الحلول اللازمة. قد يأخذ في الاعتبار توافر المهندسين وعبء العمل وتخصصهم. على سبيل المثال ، يمكنك إعداد منطق إرسال جميع تطبيقات EDS إلى المتخصصين الرئيسيين Vasily أو Andrey: إذا لم يكن Vasily في الخدمة ، فسيذهب التطبيق إلى Andrey ، والعكس صحيح. إذا لم يكن كلاهما ، فستتم إضافة التذكرة إلى الخط العام لدعم تطبيقات الأعمال. إذا كان لدى Vasily تطبيقان ، وكان لدى Andrey تطبيق واحد ، فسيتم إرسال طلب جديد إلى Andrey. يمكنك إعادة تدريب النموذج بثقة ، وزيادة الدقة. عيب النظام هو وجهة نظره.يجب ألا تتوقع دقة 100٪ من النموذج أو العمل على الحجم الكامل للتطبيقات. في عينة اختبار ، أجرينا دقة بنسبة 90٪ لـ 50٪ من التطبيقات ببيانات متسقة للغاية ، حيث اعتاد المستخدمون على العمل مع القوالب. العيب الثاني هو حجم الطلبات. ليس من المنطقي تدريب النموذج إذا كان لديك أقل من 1000 طلب في الشهر.
6. أدوات لتطبيقات الحل التلقائي.هذه مجموعة من الأدوات من واجهة المستخدم الرسومية مع نصوص تعمل على أتمتة الإجراءات القياسية لوكيل الدعم الفني: جمع السجلات من الأنظمة ، والتقاط لقطات شاشة ، بما في ذلك في وضع الظل ، وتحديث السياسات والأشياء الأخرى الخاصة بكل مشروع. الأداة الثانية هي أتمتة تلك التطبيقات التي تتطلب الموافقة. تقوم الأداة نفسها بإنشاء خطاب إلى الموافق مع روابط للموافقة / الرفض ، وبناءً على النتائج ، تعطي نفسها أمرًا لمنح حق الوصول ، أو تنشئ خطابًا برفض.
بدلا من الوداع
الشتاء قادم ، ينتهي المشروع في نهاية هذا العام ،
شكرا لاهتمامك ووقتك ، لا تمرض!