مقدمة:
أولًا، حكاية خيالية: كان يا ما كان (في يوليو 2016)، أطلقت مكتبات ويليامز نظامًا متكاملًا جديدًا لإدارة المكتبة (ILS) وطبقة اكتشاف جديدة. وكان النظام الجديد، الذي سُمّي ببساطة «فهرس المكتبة»، أول أداة اكتشاف على نطاق الويب (web-scale discovery) لدينا. وبشّر ظهوره ببداية عهد جديد من الاكتشاف المبسّط. فلن يضطر المستخدمون بعد اليوم إلى تحمّل طريقة البحث العتيقة «ابحث هنا عن المقالات وابحث هنا عن الكتب». بل سيكون بوسعهم تسخير قوة نظام الاكتشاف «من الجيل التالي» للبحث عن أي شيء تقريبًا، والوصول بسلاسة إلى ذلك المقال المحكّم المثالي الذي لم يكونوا يدركون أنهم يبحثون عنه. وحين بدأ تشغيل النظام، مزوّدًا برابط «أخبرنا برأيك!»، توقعنا أن تنهال علينا التقييمات المادحة، ثم نعيش جميعًا في سعادة وهناء إلى الأبد.
حسنًا، تلك هي الرواية الخيالية. أما ما حدث فعلًا فهو أن الملاحظات أخذت تصل شحيحة متقطعة، وكانت معظم المشاركات بلاغات عن مشكلات في الوصول إلى الموارد الإلكترونية ذات النص الكامل. فمع أن كثيرًا من المستخدمين كانوا ينعمون باكتشاف مبسّط ووصول سلس، كان بعضهم يصادف بدلًا من ذلك روابط معطلة، أو جدران دفع (paywalls)، أو رسائل خطأ. وبوصفي الشخص الذي كُلّف حديثًا بمسؤولية الاكتشاف، كان من مهامي تحرّي هذه المشكلات وإصلاحها. ولأنني أعمل في مكتبة ذات ثقافة قائمة على الخدمة السريعة المتمحورة حول المستخدم، كان من مهامي أيضًا الرد بسرعة على المستخدمين إما بحل للمشكلة أو بطريقة بديلة للوصول (كالإعارة بين المكتبات). واحتجت كذلك إلى طريقة لفرز المشكلات المبلَّغ عنها وتوزيعها بيني وبين موظفين في أقسام أخرى، وكانت لديّ مسؤوليات وظيفية أخرى عليّ التوفيق بينها. وبعد عامين وبضعة إصدارات متتالية، صار لدينا الآن مسار عمل فعال لمعالجة مشكلات الموارد الإلكترونية يضع تجربة المستخدم في المقدمة.
الإصدار 1.0: أخبرنا برأيك:
قبل طبقة الاكتشاف، كنا نستخدم محلّل روابط (link resolver) من طرف ثالث لربط الإحالات الواردة من قواعد البيانات بمقتنياتنا ذات النص الكامل. وحين كانت تحدث مشكلات في الوصول إلى النص الكامل، كان موظفو المكتبة يبلغون عنها إلى عنوان بريد إلكتروني يتابعه أمين مكتبة النظم ورئيس قسم المجموعات. ولم يكن عنوان البريد هذا معلنًا للمستخدمين، ولم يكن يُبلَّغ إلا عن مشكلات قليلة كل شهر.
وبعد إطلاق الفهرس الجديد، استمرت الحركة الواردة عبر نموذج الملاحظات «أخبرنا برأيك»، المرتبط في تذييل الصفحة، بالوتيرة نفسها. ففي السنة الأولى تلقينا 70 مشاركة، 90% منها من موظفي المكتبة. غير أنني كنت أسمع، على نحو غير موثق، من زملائي في الخدمات العامة أن المستخدمين يواجهون صعوبة في الوصول إلى الموارد الإلكترونية ذات النص الكامل، لكنهم لا يستخدمون نموذج الملاحظات للإبلاغ عنها.
أجريت بعض اختبارات قابلية الاستخدام (usability testing) المرتجلة مع بعض الطلاب العاملين لدينا، وكان واضحًا أنهم لم يلاحظوا رابط الملاحظات، ولم يدركوا أيضًا أنه يمكن استخدامه للإبلاغ عن مشكلة. فضلًا عن ذلك، حين كانوا يصلون إلى نموذج الملاحظات، كانت الأسئلة كثيرة جدًا، وكانوا يحتاجون إلى العودة إلى تسجيلة الفهرس للحصول على عنوان (URL) للمادة التي بها المشكلة، وهو أمر مرهق. وكان من المرجح أن المستخدمين الذين يستخدمون هذا النموذج يشعرون أصلًا بشيء من الإحباط، ولذا كنا بحاجة إلى جعل عملية الإبلاغ عن المشكلات أسرع وأسهل.
الإصدار 2.0: الإبلاغ عن مشكلة:
في أغسطس 2017، انتقلنا إلى واجهة مستخدم (UI) جديدة يقدمها مورّد نظام الاكتشاف لدينا. ولم تكن النسخة الجاهزة (out-of-the-box, OTB) من هذه الواجهة الجديدة تتضمن تذييلًا افتراضيًا، فاضطررنا إلى نقل رابط نموذج الملاحظات إلى مكان آخر. وكان هذا التغيير الاضطراري فرصة أيضًا: إذ استطعت أن أستخدم بعض البيانات التي جمعتها من الطلاب العاملين لدينا لتحسين تجربة تقديم الملاحظات من جهة المستخدم. وفي الوقت نفسه، كنا بحاجة أيضًا إلى تحديث إضافات مخصصة أخرى لتتوافق مع الواجهة الجديدة، التي بُنيت باستخدام إطار العمل (AngularJS).
وفي أثناء بحثي عما فعلته مكتبات أخرى سبقتنا إلى الانتقال إلى الواجهة الجديدة، اكتشفت «عُدّة أدوات (Primo)» (Primo Toolkit) المتاحة على الإنترنت [1] التي يقدمها تحالف (Orbis Cascade). وفي تدوينة بعنوان «إضافة رابط ‹الإبلاغ عن مشكلة› إلى قائمة الإجراءات في (Primo)» (Add a ‘Report a Problem’ Link in Primo Actions Menu) [2]، وجدت الحل لمعضلة نموذج الملاحظات. فقد شرحت التدوينة، التي صُممت للواجهة الكلاسيكية، كيفية ملء نموذج مسبقًا بالرابط الدائم للتسجيلة. ومع أن نموذج الملاحظات لدى (Orbis Cascade) كان قائمًا على (Drupal)، فإن بحثًا سريعًا في وثائق (Google) [3] أرشدني إلى كيفية ملء الحقول مسبقًا في نموذج (Google).
التغييرات التي أُجريت:
استنادًا إلى ملاحظات الطلاب العاملين لدينا، كنت أعرف أن الإصدار 2.0 يجب أن يكون أقصر. فضلًا عن ذلك، أوضحت لي تجربتي في تلقي ردود النموذج أن نموذجًا يجمع بين مشكلات الوصول والملاحظات العامة على الفهرس مربك ويصعب التعامل معه. وبمدخلات من مجموعتنا الاستشارية للويب، قسمت عملية جمع الملاحظات إلى نموذجين: أحدهما لجمع الملاحظات العامة على الفهرس، والآخر للإبلاغ عن مشكلات الوصول المتعلقة بتسجيلات محددة. واستخدمت جزءًا من النموذج الأصلي «أخبرنا برأيك» لنموذج الملاحظات العامة، المرتبط من الصفحة الرئيسة للفهرس، وأنشأت نموذجًا جديدًا بعنوان «الإبلاغ عن مشكلة» استنادًا إلى تدوينة (Orbis Cascade).
تضمن النموذج الجديد أربعة أسئلة:
- يُرجى إخبارنا بما يحدث لنتمكن من إصلاحه:
- الرابط الدائم (يُملأ مسبقًا من تسجيلة الفهرس)
- بريدك الإلكتروني
- هل أنت من موظفي المكتبة؟
وأدرجت السؤال الأخير لأعرف المهلة المتوقعة للرد على المُبلِّغ. فنحن نحاول عادةً الرد على المستخدمين من خارج المكتبة في غضون يوم واحد. أما موظفو المكتبة فيعرفون أن أحدًا يعمل على المشكلة، ولذا لا يتوقعون ردًا حتى تُحل. وأُضيف هذا النموذج الجديد إلى كل تسجيلة في الفهرس، تحت ما يسميه مورّد الفهرس لدينا «قائمة الإجراءات» (actions menu).
أضفت نصين برمجيين (scripts) مخصصين إلى جدول (Google) (Google Sheet) الذي يحتفظ بمشاركات النموذج. أحدهما يحوّل المشكلة المبلَّغ عنها إلى قائمة البريد الإلكتروني المذكورة آنفًا، وهي من بقايا نظامنا المتكامل القديم، وصار يتابعها الآن أمين مكتبة النظم، ورئيس قسم المجموعات، وأمين الفهرسة المسؤول عن الموارد الإلكترونية. أما النص البرمجي الثاني فينشئ رسالة بريد إلكتروني إلى المُبلِّغ عن المشكلة لإعلامه بحلها. وكان كلا النصين يُشغَّل يدويًا جزءًا من عملية الفرز. وإلى جانب هذه الرسائل شبه المؤتمتة، كنت أراسل أيضًا المبلِّغين من خارج المكتبة في مراحل أخرى: عند تلقي البلاغ، وإذا كان ما أُبلغ عنه خطأً من المستخدم، ولإرسال اقتراحات لهم بما يمكنهم فعله لتلبية حاجتهم الأصلية في أثناء تحرّينا المشكلة وإصلاحها.
النتائج:
أسفر الإطلاق التجريبي الهادئ (soft rollout) لهذه الخدمة عن زيادة كبيرة في الاستخدام. ففي الأيام الثلاثين الأولى تلقينا 35 مشاركة. وكان نحو نصف المشاركات (17/35) من مستخدمين من خارج المكتبة. وكان هذا نجاحًا يطرح تحديًا (فالمستخدمون كانوا يرون الرابط ويستخدمونه)، لكنها ظلت مشكلة. فقد ازداد عبء العمل على المعنيين بمعالجة المشكلات. وشعرت بأن عليّ أن أترك كل شيء حين تصل مشاركة لأتمكن من الرد على المُبلِّغ.
والأكثر إثارة للاهتمام أن تعريف المستخدمين لـ«المشكلة» صار أوسع بكثير من ذي قبل. فقد استخدم الطلاب النموذج حين لم يجدوا كتابًا على الرف. واستخدمه أعضاء هيئة التدريس لطلب تغييرات في طريقة تمثيل كتبهم في الفهرس. وسرّني أن مستخدمينا يستخدمون هذا النموذج. ففي نهاية المطاف، كل ملاحظة هي ملاحظة مفيدة، أليس كذلك؟ ومن ناحية أخرى، كنت في التعامل مع هذا التنوع من المشكلات أؤدي من عمل «الخدمات المرجعية» (reference) أكثر بكثير مما أؤديه من عمل معالجة المشكلات. واحتجت إلى طريقة تضمن العناية بالمستخدمين، وتحررني في الوقت نفسه لأتفرغ لإصلاح المشكلات فعلًا.
الإصدار 2.1: التحويل إلى (LibAnswers):
درست مسار العمل الجديد وأدركت أن هناك أجزاء من العملية لا حاجة إلى مشاركتي فيها. فعلى سبيل المثال، لم أكن بحاجة إلى التواصل مع المبلِّغين من خارج المكتبة لشكرهم على مشاركتهم وعرض طرق بديلة للوصول. كان لا بد أن يتواصل معهم أحد، لكن ذلك الشخص لم يكن بالضرورة أنا. فضلًا عن ذلك، كان لدينا بالفعل نظام قائم للتواصل مع المستخدمين: خدمة «اسأل أمين المكتبة»، التي يعمل بها موظفون كلما كان مكتب المساعدة البحثية مفتوحًا. والأفضل من ذلك أن لهذا النظام، (LibAnswers)، عنوان بريد إلكتروني خاصًا به، وكنت قد كتبت بالفعل نصًا برمجيًا لإنشاء رسائل البريد الإلكتروني. فكل ما كان عليّ فعله هو إجراء بعض التعديلات الطفيفة لأتمتته.
التغييرات التي أُجريت:
نسخت أحد النصوص البرمجية للبريد الإلكتروني التي تُشغَّل يدويًا وعدّلته ليحوّل المشكلات إلى خدمة «اسأل أمين المكتبة». فكل 15 دقيقة يتحقق النص البرمجي مما إذا كانت قد وردت أي بلاغات من مستخدمين من خارج المكتبة منذ آخر مرة شُغّل فيها. وإذا ورد بلاغ، ينشئ رسالة بريد إلكتروني ويرسلها إلى قائمة الانتظار (queue) في (LibAnswers). ويكون موضوع الرسالة «(Catalog Problem Reported)» (أُبلغ عن مشكلة في الفهرس)، ويكون المرسل هو المُبلِّغ الذي قدّم المشكلة. وتتضمن الرسالة وصفًا للمشكلة ورابطًا دائمًا إلى التسجيلة التي بها المشكلة. ويُجري أمين الخدمات المرجعية المناوب على قائمة انتظار البريد الإلكتروني حين يرد البلاغ قليلًا من الاستكشاف، كأن يتحقق مما إذا كان يستطيع إعادة إحداث المشكلة، أو يبحث عن وسيلة بديلة للوصول. ثم يرد على المستخدم بالخطوات التالية المقترحة، ويسجّل المعاملة في (Reference Analytics).
النتائج:
كانت أتمتة جزء التواصل مع المستخدمين في عملية الفرز وتفويضه تحسينًا كبيرًا. فقد صرت أقضي وقتًا أقل بكثير في التواصل المباشر مع المستخدمين، وتمكنت من التركيز على إصلاح المشكلات. وتلقى المستخدمون المساعدة على إنجاز ما شرعوا في فعله قبل أن يواجهوا المشكلة. وصار من الممكن تحويل المشكلات غير المتعلقة بالوصول إلى النص الكامل بسهولة إلى أقسام أخرى في المكتبة. وأخيرًا، لأن نصوص المعاملات تُسجَّل في (Reference Analytics) (الذي كان متاحًا لجميع أمناء الخدمات المرجعية والطلاب العاملين)، صارت لدى الجميع فكرة أفضل عن أنواع المشكلات التي نواجهها، والحلول البديلة الممكنة لها.
وقادني فحص الملخص اليومي لمعاملات الخدمات المرجعية إلى إضافة سؤالين آخرين إلى النموذج لتحسين تجربة المستخدم:
- هل أنت داخل الحرم الجامعي أم خارجه؟
- هل طلبت هذا المقال عبر الإعارة بين المكتبات؟
أُضيف السؤال الأول لمساعدة أمناء الخدمات المرجعية في تحرّيهم الأولي للمشكلة، حين يحاولون إعادة إحداث المشكلة المبلَّغ عنها. أما الغرض من السؤال الثاني فكان مزدوجًا: تذكير المستخدم بوجود خدمة الإعارة بين المكتبات وبأن بوسعه استخدامها لطلب المقالات التي يواجه مشكلات في الوصول إليها، ومنع أمناء المكتبة من تقديم نصائح زائدة عن الحاجة إذا كان المستخدم قد استخدم خدمة الإعارة بين المكتبات بالفعل. وقد منحتني رؤية الاتجاهات في إجابات أمناء المكتبة عن المشكلات المبلَّغ عنها منظورًا مختلفًا عما كنت أراه في مشاركات النموذج، مما مكّنني من إجراء هذه التغييرات الصغيرة المتتالية.
غير أنه كانت لا تزال هناك مشكلة تنبغي معالجتها: جبل رسائل البريد الإلكتروني التي كنت أرسلها وأتلقاها أنا وزملائي في معالجة المشكلات، المعروفين بـ«مجموعة المشكلات الإلكترونية» (e-problems group). ففي كل مرة كنت أحوّل فيها مشكلة من جدول البيانات إلى قائمة بريد المشكلات الإلكترونية، كانت تصل إلى ثلاثة أشخاص. ولم يكن واضحًا أيٌّ من الثلاثة يعمل على المشكلة، وفي مرات كثيرة كان أكثر من شخص يبدأ تحرّي المشكلة نفسها في الوقت نفسه. وبسبب الطريقة التي بنيت بها نص البريد الإلكتروني، كانت لكل الرسائل الموضوع نفسه، فكان من الصعب معرفة أي مشكلة هي أيّها، ولا سيما لمن يستخدمون وضع المحادثات في (Gmail). وكان من الصعب أيضًا تبادل الملاحظات داخل المجموعة بشأن ما جربناه بالفعل. وما كنا نحتاج إليه حقًا هو نظام تذاكر الدعم (ticketing system) أكثر رسمية لإسناد المشكلات، وإضافة الملاحظات، وتتبع الاتجاهات.
الإصدار 2.2: مزيد من التحويل إلى (LibAnswers):
حتى ذلك الحين، كنت قد أنشأت نظامًا للإبلاغ سريعًا وسهل الاستخدام، يقدم تجربة مستخدم تلائم نموذج خدمتنا السريعة والشخصية. وحان الوقت للتركيز على تحسين تجربة الموظفين القائمين على معالجة المشكلات (وأنا منهم)، الذين كانوا يكافحون لإدارة جبل رسائل البريد الإلكتروني الذي يولّده نظام الإبلاغ عن المشكلات. ومرة أخرى، كان (LibAnswers) هو الحل.
فنظام قوائم انتظار البريد الإلكتروني نفسه الذي كان أمناء الخدمات المرجعية يستخدمونه للإجابة عن الاستفسارات المرجعية بالبريد الإلكتروني (والرد على المبلِّغين عن المشكلات) يمكن استخدامه نظامًا للتذاكر لتنظيم المشكلات المبلَّغ عنها. فهو يتيح لنا إسناد التذاكر إلى الأفراد ونقلها بينهم بحسب الخبرة، وتدوين ملاحظات عن المشكلة وما جربناه حتى الآن، وإضافة الوسوم (tags) وجمع البيانات لتحليل الاتجاهات.
وكان تطبيق هذا الحل بسيطًا إلى حد ما من جهتي. فبوصفي مسؤولًا (administrator) في (Springshare)، أضفت قائمة انتظار أخرى للبريد الإلكتروني (بتكلفة 100 دولار). ولكل قائمة انتظار في (LibAnswers) عنوان بريد إلكتروني خاص بها، فلم يكن عليّ إلا تغيير عنوان البريد الإلكتروني في النص البرمجي للإصدار 2.0. ولأنني كنت لا أزال أتولى فرز المشكلات، لم أكن بحاجة إلى ضبط أي مشغّلات (triggers) لأتمتة هذا النص البرمجي. ولم يكن موظفو قائمة المشكلات الإلكترونية قد استخدموا نظام تذاكر الدعم بالبريد الإلكتروني في (LibAnswers) من قبل، فاجتمعت بهم لإعداد قائمة الانتظار وتدريبهم على كيفية استخدامها.
النتائج:
حسّن نقلُ إدارة معالجة المشكلات من البريد الإلكتروني إلى (LibAnswers) كفاءتنا. وكان هناك منحنى تعلم صغير للموظفين غير المعتادين على النظام. وبعد استخدامه لبضعة أسابيع، تمكنا من الاتفاق على ممارسات مشتركة تضمن أننا جميعًا نستخدم النظام بالطريقة نفسها (مثل متى «نغلق» تذكرة أو متى نتركها «معلّقة»). وخلال تلك الفترة، أجريت أيضًا بعض التعديلات الصغيرة على نص تحويل البريد الإلكتروني ليسهل تمييز مشكلة من أخرى في قائمة الانتظار. ولأنه مسار عمل داخلي لا يشارك فيه إلا ثلاثة أشخاص، يمكننا الاستمرار في إجراء تغييرات صغيرة متتالية عند الضرورة.
الخطط المستقبلية:
بعد أكثر من عام من استخدام نظام الملاحظات «الإبلاغ عن مشكلة»، نحن راضون عمومًا عن طريقة عمل النظام: فنحن قادرون على الرد على المستخدمين بسرعة، وتتبع المشكلات بكفاءة، ونبني نظامًا يتيح لنا متابعة اتجاهات المشكلات وحلولها. ومع ذلك، هناك دائمًا مجال للتحسين. فقد اقترح زملائي في الخدمات البحثية أن ننشئ بعض الردود الجاهزة (canned responses) في (LibAnswers) لنتمكن من تقديم حلول سريعة ومتسقة للمشكلات المتكررة. ويمكن أيضًا تحسين المزامنة بين جدول (Google) وقائمة انتظار المشكلات الإلكترونية. فأنا أستخدم حاليًا جدول (Google) لتتبع المشكلات وإنتاج الإحصاءات، لأن ليس كل المشكلات المبلَّغ عنها تُحوَّل إلى مجموعة المشكلات الإلكترونية، لكن ذلك ليس فعالًا جدًا. وأخيرًا، سيكون من الرائع أن نبدأ في اتخاذ نهج استباقي في معالجة المشكلات، وأن نضع جدولًا للاختبار، لنحاول اكتشاف المشكلات وإصلاحها قبل أن يواجهها مستخدمونا.
ما تعلمناه:
لم يعتد المستخدمون تلقي ردود سريعة وشخصية حين يستخدمون نموذجًا على الإنترنت للإبلاغ عن مشكلة. فكثير من مستخدمينا يُفاجَؤون مفاجأة سارة حين نتواصل معهم على الفور، ويشكروننا على سرعة الرد. ومع أن ذلك قد يكون خارج المألوف في الدعم عبر الإنترنت عمومًا، فهو إحدى الطرق الكثيرة التي نُظهر بها لمستخدمينا أننا نقدّرهم. وحين نعتمد على مستخدمينا في مساعدتنا على اكتشاف المشكلات في فهرسنا، علينا أن نجعل ذلك سهلًا عليهم. ومن خلال وضعهم في قلب عملية معالجة المشكلات، يمكننا مواصلة التمسك بمبادئ خدمتنا القائمة على التواصل الشخصي، وضمان أن يواصل المستخدمون مشاركتنا في جعل فهرسنا أفضل ما يمكن أن يكون.
الشفرة البرمجية:
الشفرة البرمجية متاحة على (GitHub): رابط المصدر.
المراجع:
- [1] Primo toolkit. 2016-2019. Eugene, OR: Orbis Cascade Alliance; [accessed 2019 March 8]. https://www.orbiscascade.org/blog/9/.
- [2] Add a “report a problem” link in primo actions menu. 2016. Eugene, OR: Orbis Cascade Alliance; [accessed 2019 March 8]. https://www.orbiscascade.org/blog/9/?bid=119.
- [3] Send your form to people. Google; [accessed 2019 March 8]. https://support.google.com/docs/answer/2839588?hl=en.