الجزء الأخير يدور حول كيفية تغيير مفهوم Jobs-to-Done إلى مبادئ إنشاء وتحسين منتج تكنولوجيا المعلومات. الجزء الثالث من ترجمة كتاب "إنتركوم حول الوظائف إلى أن يتم". الفصول من سبعة إلى تسعة.
الجزء الاولالجزء الثانيالفصل 7. رفض الأشخاص: قصة عمل
بواسطة: بول آدمزفي إنتركوم ، نقوم باستمرار بإعادة التفكير في العمليات الداخلية لإنشاء منتج متميز. لذلك ، نطرح على أنفسنا السؤال التالي: كيف نبني عملية إنشاء منتج بحيث يعتبره الناس قيمة ومناسبة ، وأيضًا يحبونه. ركزنا على الأبحاث ، التي قمنا بتوظيف أشخاص لديهم خبرة بحثية. في الوقت نفسه ، يتواصل كل عضو في فريق المنتج شخصيًا مع العملاء: مديري المنتجات والمصممين والباحثين بالطبع. كما قمنا بتعيين مدير أبحاث ، وفعلنا ذلك في وقت أبكر بكثير من معظم الشركات الناشئة الأخرى. أصبح سيان تاونسيند ، رئيس فريق أبحاث خرائط Google.
من الواضح أنك تحتاج إلى التواصل مع العملاء بانتظام لفهم أنفسهم واحتياجاتهم. ومع ذلك ، فإنه ليس من الواضح على الإطلاق الأداة المناسبة لهذا الغرض. لقد فكرنا باستمرار في الأفكار من
المبادئ الأولى وطبقناها مبكرًا على عملية التواصل مع العملاء.
كنا من المعجبين الكبار بـ Jobs-to-be-Done ، لكن كل ما كتبناه كان يطبق بشكل رئيسي على اللبن المخفوق وشيكولاتة. كانت هناك دراسة صغيرة واحدة فقط تتعلق باستخدام Jobs-to-be-Done لتطوير البرمجيات. لذلك أنشأنا عمليتنا الخاصة بناءً على ما عرفناه بالفعل.
خلال معظم حياتي المهنية ، استخدمت الأشخاص والبرامج النصية لفهم العملاء. أصبحت هذه الأدوات ، التي شاعها آلان كوبر في كتاب "مستشفى للأمراض العقلية في أيدي المرضى" ، واحدة من أكثر الأدوات المستخدمة على نطاق واسع من قبل الباحثين والمصممين. كتب آلان كوبر أيضًا كتابًا رائعًا بعنوان "حول الواجهة" أوصي به جميع المصممين الذين انضموا إلى فريقنا. لكنني أطلب منهم تخطي القسم الخاص بالأشخاص.
أثناء العمل في Googl ، خلقت مئات ، إن لم يكن الآلاف ، من الأشخاص للعديد من المشاريع. لقد اتبعنا طريقة كوبر بعناية ، لكن في النهاية توصلت إلى استنتاج حول القيمة المحدودة للأشخاص. عادة ما يساعدون في التعاطف مع الموظفين الذين لا يزالون بعيدًا عن التواصل مع المستخدمين ، ولكن نادرًا ما يؤدي إلى أفكار خلاقة أو نظرة جديدة على المشكلة.
ونحن في إنتركوم لم نستخدم الناس مرة أخرى.
في المرة الأولى التي سألت فيها عن قيمة الأشخاص عندما انتقلت من Google إلى Facebook. لقد جمعوا كمية لا تصدق من المعلومات حول كيفية تفاعل المستخدمين فعليًا مع منتجاتهم. والتواصل مع البيانات لم يتوقف العلماء عن تدريس أشياء جديدة.
كان من أكثر الأشياء المذهلة التي تعلمتها السلوك المتشابه بشكل لا يصدق لأشخاص مختلفين. لقد جعلني الأشخاص يعتقدون أن الناس مختلفون تمامًا عن بعضهم البعض ، وأن لديهم أهدافًا مختلفة حقًا. لكن أوجه التشابه كانت أكبر بشكل غير متناسب ، على الرغم من العوامل المختلفة: العرق ، العمر ، الجنس ، إلخ.
على سبيل المثال ، دوافع أم لثلاثة أطفال من الولايات المتحدة ، نشر صور من نزهة عائلية ، هي في الأساس نفس دوافع مراهق كوري ينشر صورًا من موعد الأمس. قد تكون الأهداف والتفاصيل مختلفة تمامًا ، ولكن الدافع هو نفسه. لن يؤدي الأشخاص أبدًا إلى إنشاء نفس المنتج لجماهير مختلفة تمامًا. الأفضل من نوعه ، يركز الناس على الإنجازات ، "ما الذي يدفع سلوك الناس" ، وعلى السمات. ولكن في الممارسة العملية ، يركز معظم الناس فقط على السمات.
الأشخاص يقسمون الجمهور بشكل مصطنع. والأهم من ذلك ، الحد من جمهور منتجك بشكل مصطنع من خلال التركيز على السمات ، بدلاً من التركيز على الدوافع والنتائج المرجوة. بمجرد أن أدركت هذا ، شعرت بخيبة أمل في الشخص.
التصميم من الدافع أفضل بكثير من التصميم من خلال السمات. هذا هو الفرق الرئيسي بين الأشخاص من Jobs-to-be-Done. الأشخاص - حول الأدوار والسمات ، والوظائف التي يتعين القيام بها - حول المواقف والدوافع. يشرح الأشخاص ما هو نوع الأشخاص ، وماذا يفعلون وماذا يفعلون ، لكنهم لا يفسرون أبدًا سبب قيام الأشخاص بعمل شيء ما ، على الرغم من أن هذا الأمر أكثر أهمية.
لذلك في منتصف 2013 في Intercom ، أدركنا أننا نبحث عن أداة من شأنها أن تساعد على الكشف عن أسباب قيام العملاء بشيء ما. لقد تحدثنا مع العديد من العملاء كل أسبوع ، وتحدث فريق دعم العملاء لدينا بشكل متكرر أكثر ، حيث أنشأ تذاكر تطوير مع مراعاة المشكلات والقيود المفروضة على منتجاتنا. لا يمكن المبالغة في تقدير هذه العلاقة المباشرة مع العملاء ، ولكن كان هناك اثنين من التحديات التي كان علينا التغلب عليها:
- يفهم الناس مشاكلهم ، لكن ليس الحل. علاوة على ذلك ، من الطبيعي أن يقترحوا حلاً في شكل طلب لتطوير الميزات. وصف الحل المقترح أسهل بكثير من المشكلة. لهذا السبب ، يجب عليك العودة إلى العملاء لطرح الأسئلة وفهم مشكلتهم حقًا.
- عند الإجابة ، يتحدث الناس في البداية عن ما يريدون بلغة السمات ، لكنهم لا يعطون سببًا مهمًا لهم. لذلك ، عليك أن تواصل التنقيب في فهم دوافعهم. الشيء الرئيسي هو فهم نوع المشكلة التي يحاول العملاء حلها بالفعل ولماذا يحتاجون إلى حل.
عندما تكون مشكلة العميل واضحة بالفعل ، كيف يمكن تحويل هذه الأفكار إلى شيء ملموس لفريق التصميم؟ في شيء بسيط يمكن مناقشته وتذكره. لا أتذكر عدد الحالات التي حدثت أثناء عملي في Google ، عندما جذبنا الزملاء إلى البحث والمشاركة في إنشاء أشخاص ، وبالتالي فإننا لن نستخدمها لاحقًا. هذا لأن الناس يصعب تذكرهم ، فهم مفصلون للغاية بحيث يتعذر عليهم فهمهم بسهولة. الأشخاص ليسوا موجزين بدرجة كافية لفرق الوجبات السريعة.
بالإضافة إلى الأشخاص ، هناك أداة شائعة أخرى - قصص المستخدم التي يروج لها مجتمع Agile. لم نستخدم قصص المستخدم أبدًا ، نظرًا لأنه لا يبدو أنها مشروطة بالبحث. هم الهندسة ، وبالتأكيد ليس سببها العميل. وهي مصممة لوصف الوظيفة ، وليس الدافع الذي يمتلكه الناس.
بعد التفكير في هذه المشكلة والبدء من المبادئ الأولى ، اخترعنا قصص الوظيفة. ثم هذه القطعة لم يكن لها اسم. وفي وقت لاحق ، جاء آلان كليمنت باسم لنا. لكن العملية كانت جاهزة ومناسبة لنا تمامًا. لقد اختبرنا قصص الوظيفة لأول مرة ، عبرنا عن أسفنا في منشور للمدونة حول تصميم "
المراوغة ". لقد فكرنا طويلًا وشاقًا في "الوظائف التي ينبغي القيام بها" ، وأدى ذلك إلى إنشاء عمليتنا الخاصة ، والتي ركزت على المواقف والدوافع والنتائج:
[عندما ______] [أريد ______] [أستطيع ______]
"عندما ..." - حول الموقف ، "أريد ..." - حول الدافع ، "يمكنني ..." - حول النتيجة. إذا فهمنا الموقف الذي يواجه فيه الأشخاص مشكلة ما ، والحافز لحلها ، وكيف تبدو النتيجة النهائية ، عندئذٍ لدينا الفرصة لصنع منتج قيم لعملائنا.
قصص العمل هي الآن أداتنا الرئيسية ، والتي تضمن الشرطية من خلال البحث ، وفهم المشكلة والتمثيل في شكل موجز. هذا يعني أن نتيجة دراستنا للمشكلة مناسبة لكل من فرق التصميم والهندسة.
قبل البدء في أي مشروع ، نقوم في Intercom بإنشاء موجز بسيط من صفحة واحدة يمكن
تنزيله . انها بسيطة جدا وينبغي أن تشغل 1 صفحة A4. يتضمن قسم قصص الوظائف ، الذي يساعدنا على عدم نسيان المشكلة والفرص التي نتصدى لها ، كما يتيح لنا الفرصة للتركيز في جميع مراحل المشروع.
الأشخاص بالتأكيد لديهم مكان ليكون. أجدها مفيدة لكسب الدعم في اللعبة السياسية ، عندما يحل الناس لفظيًا احتياجات العملاء الحقيقية فقط. يمكن للأشخاص أيضًا إنشاء اتصالات أقوى مع المستخدمين الحاليين للمنتج. لكن القيام بها بشكل جيد هو عملية تستغرق وقتًا طويلاً. يركز الأشخاص على الاختلافات بين الأشخاص ويصعب تذكرهم والإشارة إليهم. اتضح أن العديد من الأشخاص ذوي السمات المختلفة لديهم دوافع متشابهة للغاية. من السهل أن نفهم ، فضلاً عن حقيقة أن كل ما تحاول تصفيته يمكن شرحه في سلسلة من الجمل القصيرة التي لا تنسى. إذا لم يقنعك ذلك ، فتذكر أن الأشخاص يخفضون بشكل مصطنع حجم السوق لمنتجك. هذا هو السبب في أننا نغرق في قصص الوظيفة.
الفصل 8. تصميم الميزات مع قصص الوظيفة
بواسطة: آلان كليمنتعندما طلبت مني Des الكتابة في مدونة Inside Intercom ، قدمت للتو وظائف إلى شركائي من Aim ، سوق إعلانات للعقارات.
كانت عملية رسم التصميم الخاصة بنا مختلطة بسبب عدم وجود توافق في الآراء. كل واحد منا - أنا ، بصفتي المدير العام والمدير الفني ورئيس مجموعة التصميم - اقترح ما يجب تصميمه. لأننا لم يكن لدينا عملية فعالة للموافقة على فكرة واحدة ورفض الآخرين.
وبعد ذلك بزغ فجر علي. بدون أي إشارة إلى Jobs-to-Done ، بدأت في الانتباه إلى أنجح المقترحات المقدمة من المؤسسين. تحدثت عن ما يعاني منه عملاؤنا ووصفت كيف ستكون حياتهم أفضل عندما نصلحها. ثم أظهر كيف أن مقترحاتهم جيدة لمهمة تصميم محددة. نتيجة لذلك ، قمت بوصف العمل الذي يحتاج العميل إلى القيام به والنتيجة عند الانتهاء من العمل.
باستخدام لغة Jobs-to-Done في الاتصالات ، تمكنا من التحقق من صحة التصميم الأول في بضع دقائق فقط. لم يكن هناك عودة الى الوراء.
***
يكون للأفراد وقصص المستخدم مكان يكون فيه العملاء وفرق المنتجات متباعدة جدًا. ولكن هذه لم تعد مشكلة.
تقليديا ، الإجابة على الأسئلة "من هو عميلنا؟" و "ماذا يحتاج العملاء؟" يضع على التسويق ، وإدارة الأعمال أو حتى قسم المبيعات. عند جمع المعلومات ، ينبغي تشكيلها بتنسيق يفهمه الجميع ، ثم يتم إسقاطه في فريق تطوير المنتج.
خلال عملية الشلال هذه ، يتم التضحية بالفروق الدقيقة اللازمة لإنتاج منتجات جيدة: الأسباب والقلق والدوافع. وظائف إلى أن يتم هو فلسفة التركيز على هذه الفروق الدقيقة. لنقل هذا المفهوم إلى المنتج النهائي ، يجب استخدام قصص الوظيفة أثناء تصميم الميزات و UI و UX.
فشل شخص
كما قال ديس سابقًا ، يتم تعريف الأشخاص عادةً من خلال سمات لا ترتبط بعلاقات السبب والنتيجة. على سبيل المثال ، لا يفسر تفضيلات الجنس والعمر والعرق وتفضيلات نهاية الأسبوع لماذا يحب سنيكرز. ولكن الموقف الذي لا يوجد فيه سوى 30 ثانية لشراء وأكل شيء لإرضاء الجوع لمدة 30 دقيقة القادمة يفسر كل شيء.
فشل قصص المستخدم
"كمستخدم ، يمكنني وضع علامة على المجلدات بحيث لا يتم نسخها احتياطيًا ، وبالتالي لن يتم ملء قرص النسخ الاحتياطي الخاص بي بما هو غير ضروري." قصة المستخدم هذه لها ثلاث مشاكل كبيرة:
- المستخدمة من قبل شخص.
- تحقيق يجمع بين الدافع والتوقعات.
- تجاهل السياق والإعداد والمخاوف.
الميزات غالبا ما تفشل. إذا تم تحديد ميزة باستخدام قصة المستخدم ، فلن يكون من السهل فهم سبب فشلها. يحدث هذا عندما يتم الجمع بين الدافع والتوقعات في القرار. بسبب هذا الارتباط ، من المستحيل فهم ما الخطأ بالضبط - المشكلة في التنفيذ أو في افتراض الدافع.
مقدمة في قصص العمل
قصص العمل ، التي ذكرها لأول مرة بول آدمز
على مدونة إنتركوم والتي تم
تطويرها هنا ، هي طريقة مختلفة تمامًا لتطوير الميزات. لكن كيف تقوم الفرق بدمجهم في سير العمل الخاص بهم؟
إليك طريقة واحدة:
- نبدأ مع العمل الرفيع المستوى.
- نحدد الأعمال الأصغر التي تساعد على أداء أعمال عالية المستوى.
- نحن نراقب كيف يحل الناس المشكلة الآن. هذا هو العمل الذي يقومون به.
- نستخدم قصة الوظيفة لتحديد العلاقات بين السبب والقلق والقلق والدوافع لما يفعله الناس الآن.
- نخلق حلا يحل قصة الوظيفة هذه.
على سبيل المثال ، فكر في عملية تصميم الملف الشخصي للبائع من قبل فريق المنتج كجزء من منتج يساعد تجار السيارات في الحصول على قرض للعملاء.
تصميم الملف الشخصي
في المرحلة المبكرة من إنشاء التصميم ، يناقش الفريق الشكل الذي ينبغي أن يبدو عليه ملف تعريف المستخدم والميزات التي ينبغي ملؤها بها. للبدء ، تستيقظ سارة ، وهي عضو في الفريق ، وترسم تخطيطًا بسيطًا على السبورة. مشيرة إليه ، تقول: "هذا هو ملف تعريف البائع".
الفريق غير معجب بقراره. يتم طرح سلسلة من الأسئلة "لماذا" حول كل جزء من التخطيط. حتى بعد كل هذه الأسئلة ، فإن الفريق لا يقبل أو يرفض هذه الفكرة. هذه الأسئلة هي: "لماذا يحتاج المنتج إلى هذا الملف الشخصي؟" ، "لماذا يجب أن يكون الملف الشخصي هنا وليس في أي مكان آخر؟" ، "ما هي المعلومات التي ينبغي أن تظهر؟" ، "في أي حالات تكون مفيدة؟" ، "ما نوع العمل الذي يقوم به هذا؟ الملف الشخصي؟ "
للإجابة على هذه الأسئلة ، تمت إعادة تصميم وصف الميزة باستخدام قصة الوظيفة.
الشروع في العمل رفيع المستوى
العمل رفيع المستوى للمنتج هو مساعدة تاجر السيارات في الحصول على قرض لعميل محتمل. يتعين على العميل والبائع ملء الكثير من الأوراق المعقدة.
نحدد وظائف أصغر من شأنها أن تساعد في أداء عمل رفيع المستوى.
لملء طلب قرض دون أخطاء ، يضطر البائع والعميل إلى إدخال كمية كبيرة من المعلومات حول السيارة وشروط القرض. نظرًا لأن المعلومات حساسة ، يحتاج العميل إلى الشعور بأن نقل البيانات إلى البائع آمن.
نحن نراقب كيف يحل الناس المشكلة الآن. هذا هو العمل الذي يقومون به.
عند إرسال هذه المعلومات ، يفحص المشترون عادةً ، كقاعدة عامة ، البائع والبائع ، ويستنتجون ما إذا كانوا يستحقون الثقة. عادة ما يقوم العملاء بملء المعلومات المالية الحساسة عن طريق الجلوس بالقرب من البائع. هذا يساعدهم على الشعور بالثقة من أن المعلومات سيتم ملؤها بشكل صحيح وفي الوقت نفسه لن تكون متاحة للأشخاص الذين لا ينبغي أن نرى ذلك.
نستخدم قصة الوظيفة لتحديد علاقات السبب والقلق والدوافع لما يفعله الناس الآن:
- عندما يتفاعل تجار السيارات وعملائهم من خلال منتج ...
- ... يريد العملاء أن يثقوا في الشركة والعملية والبائع.
- يريد البائعون التأكد من أن العملية مريحة للعميل ...
- ... ويمكنه إدخال معلوماته المالية بأمان.
هو مكتوب في قصة الوظيفة. يمكنك تحديد ذلك عن طريق إضافة المزيد من السياق الظرفي: متى وأين يتم ملؤه بالكامل ، في المنزل أو في الوكالة. وكذلك مخاوف كل طرف من الأطراف المرتبطة بالملف الشخصي وإتمامه.
قم بإنشاء حل يلبي قصة الوظيفة هذه
يقرر الفريق التصميم الذي يجب أن يكون عليه الملف الشخصي حتى يتمكن العميل من إكمال عمله. إن عرض معلومات قليلة جدًا في الملف الشخصي لن يحل العمل الأولي ، ويمكن أن تؤدي صفحته الكبيرة إلى عواقب سلبية. نتيجة لذلك ، يقرر الفريق:
- أثناء استخدام المنتج ، سيكون ملف تعريف البائع مرئيًا دائمًا على الشاشة حتى لا يخشى المشتري أنه ليس بالقرب من البائع.
- يجب أن يحتوي ملف التعريف على صورة للبائع وموقعه وعدد السيارات المباعة وطول مدة الخدمة في الشركة بحيث لا يكون هناك شك في موثوقية البائع وتجربته.
- يجب أن يشير ملف التعريف إلى كيفية الاتصال بالبائع: رقم الهاتف والبريد الإلكتروني وزر "طرح سؤال" حتى لا يخاف العميل من ملء النموذج بشكل غير صحيح.
فيما يلي مثال للحل:
فيما يلي تفاصيل لواجهة المستخدم: العمل الذي يقوم به كل عنصر من عناصر ملف التعريف ، والمواقف التي يحلها.
الآن لدينا منتج يمكن فيه العثور على جذور كل حل للوظيفة: لإعطاء شعور بالأمان أثناء نقل البيانات الشخصية من قبل العميل.
تصميم الصوت للناس
يعني إنشاء منتجات ناجحة مراقبة الأشخاص الحقيقيين الذين يقومون بحل مشكلاتهم ، والبحث في سياق الحالة التي يواجهونها ، وفهم العلاقة السببية والمخاوف والدوافع.
سمات مجردة ، ومزيج من الإدراك مع الدافع والتوقعات يدفع الفرق مجنون. إذا قام الفريق بالتنقيب بعمق ودراسة عمل العميل ، فسيخلق حلولًا بشكل أكثر كفاءة. قصص العمل هي الأنسب لتصميم المنتج.
الفصل 9. اسأل "لماذا" - صحيح
بواسطة: دان ريتزنتالرإلى أن وصلت إلى Jobs-to-be-Done ، بالكاد عرفت المشكلة الجذرية بحيث وصلت إلى عبارة بسيطة. كيف يمكنني التعبير عنها بكل وضوح أمام أعضاء الفريق؟ من الضروري النظر في المشكلة من زوايا مختلفة لفهمها بشكل أفضل. واطرح السؤال "لماذا؟" - واحدة من أفضل الطرق للتعمق في ما يحاول العملاء القيام به.
هناك العديد من النصائح والدراسات المجردة حول كيفية اكتشاف العلاقات بين السبب والنتيجة. على سبيل المثال ، تقنية خمسة لماذا. في هذا الفصل ، سنتحدث عن السعي للوصول إلى حل وسط ، حول كيفية التنقل داخليًا عبر مستويات المحادثة ، ولكن ليس بسرعة كبيرة حتى لا تفقد الأفكار القيمة. الشيء الرئيسي هو العثور على رؤى فريدة من نوعها في كل مستوى "لماذا" قبل الانتقال.
***
لا أستطيع التوقف عن طرح السؤال "لماذا؟" لكل عبارة من بياناتك ، ثم ... مرة أخرى ، سأطلب "لماذا؟". هذا هو تشوه المهنية.
هنا ، على سبيل المثال ، اشتريت مثقاب كهربائي. لماذا؟ نعم ، لأنك تريد تعليق صورتين في إطار. لماذا تريد تعليق الصور؟ ربما لجعل منزلك أكثر بالسكان. لماذا هذا مهم بالنسبة لك؟
أما بالنسبة لتصميم المنتج ، فغالبًا ما يكون السبب الرئيسي سريعًا. ولكن قيمة طرح "لماذا؟" الأسئلة عادة لا تتكون في الوصول إلى الوجهة ، ولكن في الحركة تجاهها.
هذا صحيح بشكل خاص للمقابلات مع العملاء. خذ وقتك وخصص الوقت لكل مستوى "لماذا؟" ، واختبر العديد من الأفكار المختلفة. ثم يصبح الوقت الذي تقضيه مع العميل أكثر إنتاجية - ستكون الرؤى المستلمة أكثر إثارة للاهتمام ومفيدة.
مستويات النقاش المنتجة
يمكنك دائما حفر عميقة كما تريد. , . «?».
, . , , :
- -, : ? , .
- -, : ? , .
- -, : , ? .
. , : « ?», .
, , — . , .
— . , .
? ? ? ? : ?
? , , ? , ? ? , , ?
, . , , .
— . , , .
, ? ? , ? , - ? , , ?
? , , ? , , ? , ?
. , , .
— . , , , .
, , ? , ? ?
? -, ? , ? , ?
, . , .
, , . . . , , . , .
استنتاج
Intercom Jobs-to-be-Done . . . , , , .
, Jobs-to-be-Done. , , . , Intercom, .
, , . , ,
Intercom . , .
Jobs-to-be-Done . — , . , . , .
, . des@intercom.com
شكرا للقراءة.