من الناحية العملية ، يحدث أنك قمت بتطوير منتج ، وبعد الإطلاق ، لا يستخدمه العملاء على النحو المنشود. ثم اتضح أن مهام المستخدم مختلفة ، وهي تتعارض مع تطوير المنتج المخطط ورؤيتك للمشروع. لماذا؟
في الواقع ، أنت تعمل مع مهمة مستخدم غير مفهومة تمامًا وتتغير تحت تأثير المنتج. هذا يشير إلى أن المنتج يحتاج إلى وضع اللمسات الأخيرة ، بالإضافة إلى إقرانه مع العميل. لذا فأنت تحمي نفسك على الفور من إنشاء حلول غير ضرورية تستند فقط إلى الفرضيات.
أعتقد أنه من الأفضل بناء التواصل مع المستخدم وفقًا لمبدأ التصميم المستمر ، والذي سيتم مناقشته في المقالة.
عزيزي وفوضى تكنولوجيا المعلومات المريبة
لا تجد معظم المنتجات والوظائف التي توفرها تكنولوجيا المعلومات تطبيقًا عمليًا. الموارد والتطبيقات والبرمجيات لا تزال دون مطالبة. لا تفكر جميع الشركات فيما إذا كانت منتجاتها مطلوبة حقًا.
والدليل الحيوي هو سوق تطوير الهاتف المحمول ، الذي يحتوي على مؤشرات قابلة للقياس. على الرغم من أن أفضل الممارسات تتركز هنا ، إلا أن الإحصائيات تترك الكثير مما هو مرغوب فيه: في عام 2017 ، نشرت شركة التحليلات Localytics دراسة Sql ، والتي تستتبع أن 24٪ من التطبيقات يتم فتحها مرة واحدة فقط من قبل المستخدمين.
هذا مع الأخذ في الاعتبار حقيقة أن النسبة المئوية للمستخدمين الذين فتحوا التطبيق أقل من 10 مرات لا تتجاوز 63٪ . إذا أخذنا في الاعتبار "استقرار" الإحصاءات ، يصبح من الواضح أنه لم يتم استخلاص نتائج منها. يعرف الناس كيف يتطورون ، لكنهم يفتقدون جانب كيفية دخول المنتج لحياة الشخص ، أي أنهم لا يستخدمون النموذج الذي يركز على الإنسان. ينطوي الأخير على تفاعل طويل الأمد مع العميل ؛ عادة لعدة سنوات.
هذا يقودنا إلى الاستنتاج: في نهج يركز على العميل ، تحتاج إلى التحول إلى ممارسات التطوير الحالية مثل DevOps أو رشيقة أو سكروم ، والتي يتم تطبيقها بشكل منفصل. ولكن إذا دمجناها ، نحصل على شيء يسمى التصميم المستمر. وهو يتألف من المبادئ الكلاسيكية لـ DevOps والتفكير التصميمي. نقترح النظر فيه واعتماده ، ولكن من أجل تنفيذ المبدأ في التنمية ، تحتاج إلى إعادة النظر في العلاقة بين المكونين: التصميم والعمليات.
مقدمة من العمليات والتصميم
العمليات هي ما يحدث الآن. يمكن أن يكون هذا إدارة النظام ، ودعم المستخدم ، والعمليات التجارية. يتم بناء العمليات على نماذج مختلفة ، على سبيل المثال ، باستخدام DevOps المذكور. يوفر عملية تغذية مرتدة مستمرة وتحسينات وتقديم الحلول. يتم إنشاء "حلقة" من التغذية الراجعة والتخطيط والبحث عن الحلول وتقديمها. ولكل مرحلة من المراحل ، هناك أدوات تساعد في العمل وأتمتة العمليات وتوفير تبادل مستمر للمعلومات والحلول.
التصميم هو كل ما ينطوي عليه تحديد الإجراءات وطرق البناء وطرق تعبئة المنتج للمستهلك. عادة نقترب من التصميم كحل لمشكلة. إذا فهمنا جوهر المشكلة ، فيمكننا تقديم الحل الصحيح.
هذا نهج تقليدي.
4 الظروف التي لا يأخذها النهج التقليدي بعين الاعتبار
ولكن عند الجمع بين التصميم والعمليات ، تظهر أربعة عوامل ظهرت بشكل منفصل سابقًا للفرق. لهذه الجوانب ، يصبح التصميم المستمر هو الحل:
رقم 1 لا يمكن فهم المشكلة بالكامل.بمساعدة التحليلات والأبحاث ، نفترض كيف سيستخدم الأشخاص المنتج ، لكنهم يقدمون فكرة غير مكتملة عن المشكلة ، حيث لا يمكننا تغطية جميع جوانبها. فقط عندما يقع المنتج في أيدي المستهلك ، نرى مدى فائدة ذلك بالنسبة للمستهلك ، أو المهام التي ساعد في حلها أو ما قام بتغييره.
مثال بسيط: على الجينز هناك جيب صغير للساعة. تم اختراعه من قبل ليفي شتراوس في عام 1873. ومنذ ذلك الحين ، لم يستخدم أحد الجيب للغرض المقصود منه. حتى أن الشركة أصدرت فيديو كاملًا مخصصًا لذلك.
# 2 المنتج يتغير المستهلكالخبرة النشطة في التفاعل مع المنتج تغير المستخدم. وهذا يحول المشكلة التي يحلها المنتج ، مما يخلق صعوبات جديدة لك وللعميل.
تذكر كيف طلبنا سيارة أجرة منذ 5-6 سنوات: قبل عامل الهاتف على الطرف الآخر من السلك الأمر وقال إن السيارة ستقدم في غضون 20-30 دقيقة. وكنا مستعدين للانتظار. مع إطلاق خدمات مثل Uber و Gett و Yandex.Taxi ، تغير تصورنا: في عام 2018 ، الوقت الأمثل لتسليم السيارة هو 2-3 دقائق بالنسبة لنا. إذا انتظرنا لفترة أطول ، فإنه يبدأ في الإزعاج. والنقطة ليست في الرقمنة أو التحلل ، ولكن في تغيير نموذج الاستهلاك.
# 3 القيمة هي شيء تم إنشاؤه معًالا يمكن تخيل قيمة المنتج وقت إنشائه. بعد الإطلاق ، تبدأ الخدمة في أن تعيش حياتها الخاصة وتكسب قيمة جديدة ، والتي يتم تشكيلها أثناء الاستخدام. بعض الوظائف ستكون مطلوبة ، بينما البعض الآخر لن يكون كذلك. والقيمة التي أنشأتها أنت والمستهلك تنضج. لذلك ، غالبًا ما تظل المنفعة غير واضحة حتى يتم استخدام سلعة أو خدمة.
أذكر AppStore ، الذي بدا مخالفًا لتصور Apple للقيمة. في عام 2007 ، قدم ستيف جوبز جهاز iPhone بكلمات: "لست بحاجة إلى كتابة برامج. إنه غير مجدي: لديك html5 ". هذا لم يمنع المستخدمين: لقد اخترقوا الأجهزة وكتبوا برامجهم ، وزعت من خلال تطبيق برنامج Cydia. تم إطلاقه في مارس 2008 ، وبالفعل في 10 يونيو من ذلك العام ، اعتمد لاعبو كوبرتينو التجربة الناجحة وأطلقوا AppStore ، وتغيير الوضع لصالحهم وأصبح اللاعب رقم 1 في سوق الهاتف المحمول.
تقودنا هذه الرسالة إلى استنتاج مفاده أن المطور والمستهلك جزء من المشكلة والحل.
# 4 الصعوبة تزيل التحكمنحن ننشئ باستمرار أنظمة معقدة لا يمكن التحكم فيها بالكامل. وهذا يؤدي إلى فشل وأخطاء لا مفر منها. إحدى المشاكل الرئيسية للعمل مع هذه الأنظمة هي محاولات التحكم على مستويات كثيرة جدًا ، عندما تفكر بعناية في ما سيحدث أو يمكن أن يحدث.
أنا متأكد من أننا جميعًا اتصلنا بخدمة دعم العملاء ، حيث تمت إعادة توجيهنا في كثير من الأحيان إلى مشغلين مختلفين. مرارا وتكرارا وصفنا المشكلة وانتظرنا الرد على موسيقى الخلفية للشركة. هذه هي الحالات التي يتم فيها التفكير بعناية في الخدمة - المشغلون. الموظفين لديهم خوارزميات اتصالات العملاء التي يتم مراسلتها وتفصيلها باستمرار. فبدلاً من خدمة مصالح المستخدمين ، فإنها تعقد النظام وتربكه فقط. نظرًا لسياسة الشركة ، لا يمكن لمشغل واحد حل مشكلتك ، حتى لو كانت بسيطة. عليه ببساطة أن يعيد توجيهك إلى شخص آخر.
برمجيات الرقمنة
انظر إلى تطور iPodلا تؤثر هذه العوامل غير المحسوبة على العالم الرقمي فحسب ، بل تؤثر أيضًا على العالم المادي. لقد أصبح من الصعب اكتساب خبرة لا تتضمن مكون برنامج وسيط. يتم التحقق من البيئة التي نعيش فيها من خلال البرامج ، وهذا يغير تصور الأشياء وطريقة استخدامها.
على سبيل المثال ، أصدرت Tesla تحديثًا لبرامج يزيد من عمر بطارية السيارة. في الوقت نفسه ، تم تحسين خصائصه الجسدية: الآن يمكنك الذهاب ليس فقط إلى السوبر ماركت أو العمل ، ولكن أيضًا إلى المدينة المجاورة. لم يتغير عدد الرحلات وليس طول الرحلة ، ولكن جودة السيارة ، ومعهم فهم مهام وأغراض استخدامها. الآن لا تحتاج إلى إنفاق المال على سيارة أجرة أو وضع قيود أخرى ، لأن البطارية تدوم مرتين أطول. آلة واحدة تغلق جميع مهام صاحبها.
العلامة التجارية تبتعد عن الوعد بالحوار
إذا أصبح كل شيء أكثر وضوحًا مع العمليات والتصميم ، فسيظل هناك مفهوم أكبر وأكثر تجريدية للعلامة التجارية. كما يعمل في مجموعة من التصميم المستمر.
كنا نعتبر العلامة التجارية وعدًا. على سبيل المثال ، الاستقرار أو الثبات. ولكن الآن تحول أساسها نحو الحوار ، لأننا نعيش في نموذج من القيم المتغيرة. ولا يجب أن يكون الحوار مع المستخدم أحادي الجانب ، فهو مرتبط بالاتصال المستمر ، حيث أن تكنولوجيا المعلومات هي البيئة التي يتم فيها ذلك بسرعة أكبر. بعد كل شيء ، لدينا أدوات لتقديم ملاحظات مستمرة على مستويات مختلفة: من الخدمات التحليلية الخارجية إلى طرق DevOps.
تصبح تكنولوجيا المعلومات بيئة للحوار المستمر
نبدأ في تغيير المنتج دون توقف بفضل تعليقات العملاء ، التي نلاحظها ونحلل إجراءاتها. لذا فإن حلقة DevOps تقترب من اللانهاية عندما تشارك العمليات والتطوير والتصميم والتسويق في هذه العملية: نختار حلًا واحدًا من حلول عديدة وننفذه ونرى كيف تتصرف عمليًا. في هذا الشكل يعمل التصميم المستمر.
نموذج التصميم المستمر
ومن أجل أن يصبح التصميم حوارًا رائعًا ، هناك 4 توصيات:
رقم 1 تصميم التفاعلات بين العملاء والموظفين في نقاط الاتصالصمم تجربة مستخدم قبل طرح المنتج. ومن الضروري دراستها ليس فقط في الظروف المثالية عندما يتم استخدام المنتج أو الخدمة بشكل صحيح ، ولكن أيضًا حيث يتلامس العميل مع العمليات التجارية: مكتب خلفي أو هندسة تكنولوجيا المعلومات. يساعد تصميم التجربة بناءً على البيئة الخارجية وأسلوب حياة المستخدم على تحديد مدى ملاءمة المنتج والموظفين الذين يتفاعلون معهم لحياة الشخص. كما سيوضح ما هي الأرضية المشتركة مع أقسام الشركة وتحت أي ظروف. يمكنك استخدام CJM والعملاء وزملاء العمل الواجب القيام به لهذا الغرض.
# 2 التقليل من التأخير ، تكبير الملاحظاتتوفر منهجيات التطوير المرنة مثل ممارسة رشيقة و DevOps أكثر من سرعة وتسليم التحديثات أو الإصدارات التجريبية. باستخدامها ، يمكننا الحصول بسرعة على التعليقات واختبار الفرضيات وضبط الإجراءات لتحسين المنتج بشكل أكبر. نتعلم من كل سباق عمل أو تحديث المنتج ونستخرج المعرفة منه طوال دورة حياة الخدمة.
# 3 تصميم البق. هل للدراسةحوّل الانخفاضات إلى معلومات تخدم اهتماماتك ومصالح المستخدم. أخطاء لا مفر منها في جميع المراحل ، سواء تصميم الوظائف أو تطوير حملة تسويقية. ولكن يجب أن تكون مستعدًا لهم وأن تبني تصميمًا مستمرًا حتى تتمكن من ملاحظة الخطأ في الوقت المناسب واستخلاص النتائج. من المهم استخدام ممارسات Lean UX مثل اختبارات UX ، واختبارات AV ، والفرضيات ، وما إلى ذلك.
في النهاية ، يتم تشكيل ثقافة العمل مع البق والأدوات التي يخلقها: مثل Chaos Monkey أو Blameless post dead.
# 4 مفهوم "تم" غير موجودنحن في وضع لا يمكن فيه فهم المشكلة بالكامل ، والحل في نفس الوقت يغيرها. لذلك ، لا يمكن للفريق ببساطة اتباع الفرضيات المتعلقة بقيمة المنتج ومواصلة تصميم بنية تكنولوجيا المعلومات والخدمات. بدلاً من ذلك ، تحتاج إلى مشاهدة كيفية عمل المنتجات والخدمات عندما تكون خارجة عن السيطرة. التعليقات في حلقة DevOps لا معنى لها حتى تؤثر العمليات والعالم الخارجي على عملية تحسين المنتج. وفي هذه الحالة يتم استبعاد مفهوم "تم". أنت تغير المنتج باستمرار. وهذا يعني أن العملية تستمر أكثر في نظام DevOps والتفكير التصميمي.
يعلمك العمل في نموذج التصميم المستمر الاستجابة بسرعة للأخطاء ، ومن الأسهل الارتباط بها وعدم القيام بعمل غير مفيد. ميزته هي أنه خطوة بخطوة ، يتم إغلاق المزيد والمزيد من مهام العميل ، مما يجلب ربحًا إضافيًا وله تأثير مفيد على الأعمال.
ملحوظة: تأثر كتابة هذه المادة بأداء جيف ساسنا.