كيفية الحفاظ على الجودة على نطاق واسع

إذا كنت تعمل في شركة ناشئة سريعة النمو ، فإن الحفاظ على منتج خالٍ من العيوب بمرور الوقت يكون أمرًا صعبًا للغاية. يتطلب الأمر التصميم والنية - لكن الخبر السار هو أنه ليس في الواقع معقدًا للغاية. يشرح برايان كولر ، مدير الهندسة لدينا ، كيف نفعل ذلك هنا في SalesLoft.

دورة حياة نموذجية من بدء التشغيل - وكيف يحدث خطأ

عندما تنظر إلى المراحل المختلفة التي يمر بها منتجك ، يبدو دائمًا أن هناك أولوية أعلى من إصلاح بعض الأخطاء. في المراحل المبكرة جدًا ، عندما تحاول فقط العثور على ملاءمة سوق المنتجات ، يجب أن تنفق كل ثانية على الحصول بسرعة على ميزات MVP من الباب لترى ما هي العصي. ثم إذا كنت محظوظًا بما يكفي لكسب الاهتمام ، فستبدأ في إغراق طلبات الميزات الجديدة ، إلا أنه يأتي الآن من كل من الإمكانات التي تقيم أنت والعملاء الحاليين الذين يحتاجون إلى المزيد من الوظائف.

بمجرد أن تصبح الأمور جدية ، تأتي مشكلات التوسع - فك ارتباط تطبيق MVP الخاص بك إلى خدمات ، والانتقال إلى بنية قابلة للتطوير ، وإعادة تكوين المكونات غير المؤهلة لمعالجة حمل المستخدم المتزايد باستمرار.

ثم إذا كنت محظوظًا حقًا وتعثرت في مساحة ناشئة من البرامج تؤدي إلى حل مشكلة جديدة ، فمن المرجح أن شخصًا آخر تعثر فيها معك. هذا يعني أن لديك واحد أو اثنين من المنافسين الرئيسيين الذين يحاولون تناول طعام الغداء. إنها عملية استيلاء على الأرض ، لذا يجب عليك الآن مواكبة تكافؤ الميزات عبر مساحة مبتكرة سريعة الحركة.

أنت تتحرك بسرعة ، أنت تكسر بعض الأشياء ، لكن ماذا في ذلك؟ تستمر المبيعات في العمل ويعمل معظمها. أي من المتسابقين الذين تهتم بهم على الأرجح ، تتم كتابة بقية الأخطاء في الحافة (ربما) ووضعها في تراكم في مكان ما. سنصل إليهم في يوم من الأيام عندما تهدأ الأمور ولدينا وقت. في الوقت الحالي ، لدينا 3 ميزات رئيسية يجب أن تخرج من الباب ونحتاج إلى إعادة بناء نظام الدخول الموحد الخاص بنا للتعامل مع العملاء الأكبر حجمًا.

من المحتمل أن يبدأ فريق دعم العملاء الخاص بك صغيرًا وهزيلًا ، ولكن بعد ذلك ، لسبب غير مفهوم ، يكونون مرهقين باستمرار ويتعين عليهم الاستمرار في التوظيف. تذاكر الدعم تستمر في النمو. الأخطاء التي تحصل على الكثير من التذاكر تنجح في تحديد أولوياتها على خريطة طريقك المزدحمة للغاية ، ولكن فقط إذا كان الناس يشكون حقًا.

ينمو تراكم العيب. تؤثر كل مشكلة جديدة على المزيد والمزيد من الأشخاص نظرًا لوجود المزيد والمزيد من العملاء. يبدأ فريق الدعم الخاص بك في طرحه أسبوعيًا - المشكلات التي لا يوجد لديك وقت لإصلاحها هي الاحتفاظ بتذاكر أكثر وأكثر وقبل أن تعرف ذلك ، فقد فات الأوان. لقد حفرت نفسك في حفرة لن تخرج منها أبدًا. ليس لديك تراكم للأخطاء ، لديك قاعدة بيانات للأخطاء. ليس هناك طريقة ممكنة من قبل أن يبتلع الفريق التنفيذي فجوة مدتها 3 أشهر لتصحيح السفينة ، وفي الوقت نفسه ، فإن كل ميزة جديدة تظهر تثير الانحدارات في كل مكان.

الزبائن يحصلون على التعيس. يتركون مراجعات سلبية NPS تفيد "عربات التي تجرها الدواب جدا ، لا شيء على الإطلاق يحصل ثابت!" تزداد صعوبة الاحتفاظ بالمطورين الجيدين لأن كود الشفرة أصبح صعبًا للغاية. كل شيء على النار ، في كل وقت. تبدأ في خسارة حصتها في السوق. زبد معدلات ترتفع. أنت لا تفهم كيف يتمكن منافسيك من التحرك بشكل أسرع منك ، على الرغم من أن لديهم فريقًا أصغر.

صوت فظيع؟ أنه. وسوف تقتل شركتك.

إليك كيفية التأكد من عدم حدوث ذلك.

انها ليست معقدة. إنه عمل شاق رغم ذلك. يجب عليك ، بأي ثمن ، مع كل ألياف كيانك ، التأكد من عدم خروج السيطرة المتراكمة عن العيوب. إذا لم تقم بمشاهدته ، وإذا لم تقم بتنفيذ عمليات لإدارته ، فستنمو بنسبة 100٪. عليك أن تكون متعمدا حول هذا الموضوع.

في SalesLoft تمكنا من القيام بذلك حتى الآن. ليس لدينا أي عيوب معروفة من قبل العميل في تراكمنا والتي لم يتم تحديد أولوياتها أو العمل عليها. كل شركة مختلفة ، لذلك قم بتعديل المتغيرات أدناه لما يناسب منتجك وشركتك. عليك أن تأخذ بعين الاعتبار مساحتك (هل أنت بنك أم أنك تكتب تطبيقًا اجتماعيًا لتبادل الرموز التعبيرية؟) ما الذي سيتحمله عملاؤك؟ كم مرة تقوم بالإفراج؟ هل يقوم المستخدمون بتسجيل الدخول مرة واحدة في اليوم أم أن خبراتهم أكثر معاملات؟ كل هذا يجب أن يدخل في صنع القرار الخاص بك ، ولكن إليك كيفية القيام بذلك:

البقاء على مقربة من الدعم.

أعضاء فريق دعم العملاء هم عينيك وآذانك. سوف يعرفون متى يكون هناك خطأ ما بشكل أسرع مما سوف يحدث في بعض الأحيان. سيعرفون ما هي نقاط الألم الحقيقية. سيعرفون التذاكر التي يجيبون عليها بنفس الطريقة مرارًا وتكرارًا. يعد توصيل فريق الدعم الخاص بك فعليًا إلى فريق الهندسة خطوة أولى مهمة.

خلال أسبوعي الأول هنا ، بعد مجرد معرفة كيفية عمل كل شيء ، جلست مع المهندسين وتعرفت على كيفية عمل التطبيق. أين كانت الاختناقات؟ ما الذي يحصل على أكبر قدر من الاهتمام؟ ما هي الأولوية القصوى؟

وأخيرا - كم عدد الأخطاء البارزة التي لدينا؟ الجواب: "حسنًا ، لا شيء. لا نعرف ذلك على أي حال. نصلح الأمور بسرعة كبيرة. "لطيف.

قمت بعجلة الكرسي إلى الغرفة المجاورة حيث جلس الدعم. طرحت نفس السؤال على المجموعة بشكل عام - "يا الجميع ، هل هناك أي أخطاء موجودة تعرفونها جميعًا؟ تقول الهندسة إنه لا يوجد ".

الضحك يمكن أن يسمع 3 طوابق بعيدا.

تبين أن عملية تصعيد الخلل من الدعم إلى الهندسة لم تكن موجودة. أفضل ما حصل هو أنه إذا حدث شيء ما حقًا ، فقد كان أحدهم يدق على الزجاج بين الغرف ويصرخ به. إلى جانب ذلك ، قد يذكر الدعم الأشياء المكسورة للمهندس أثناء تناول القهوة أو في اجتماع عشوائي.

يجب عليك الحصول على دعم يتحدث إلى الهندسة وعليك استخدام البرنامج للقيام بذلك. مهما كان نظام التذاكر الذي يستخدمه الدعم (نحن في Zendesk) ، فقم بالتوصيل عبر تكامل مباشر في نظام إدارة العمليات (JIRA ، Pivotal ، إلخ). علم فريق الدعم كيفية كتابة العيوب. قم بتضمين المكون المتأثر ، خطوات الاستنساخ وعدد العملاء المتأثرين. دعهم يضعون مستوى شدة. تأكد من أن تكاملك يدعم التحديثات ثنائية الاتجاه ، لذلك عندما تنتقل المشكلة عبر نظام إدارة العمليات ، يتم تحديث جميع بطاقات الدعم تلقائيًا بالحالة والدقة. يتيح لنا لنا التعليق مباشرة على جميع تذاكر الدعم مباشرة من نظام إدارة العمليات لدينا (JIRA ، في حالتنا). هذا الجزء يحتاج إلى أن يكون سهل وسهل الاستخدام قدر الإمكان. لا تريد إنشاء النفقات العامة من مجرد تتبع وإدارة قائمة العيوب الخاصة بك.

تحديد اتفاقية مستوى الخدمة الخاصة بك.

جيش تحرير السودان ، في هذه الحالة ، هو مجرد وسيلة خيالية لقول "نحن نعد للقيام بأشياء معينة في فترة زمنية معينة". لدينا جيش تحرير السودان مع فريق الدعم الخاص بنا ، حيث جلسنا كفريق واحد واتخذنا قرارًا بشأنه. وعدت الهندسة بإصلاح جميع العيوب خلال فترة زمنية محددة. لقد توصلنا إلى 3 مستويات شدة مختلفة - قد تكون هذه مختلفة عن احتياجات شركتك أو منتجك ، ولكن بمستوى عالٍ:

درجة الخطورة 1 تعني بشكل أساسي أن التطبيق قيد التشغيل. كل شيء على سطح السفينة ونحن نصلحها على الفور.

درجة الخطورة 2 تعني أن شيئًا ما سيئ للغاية - لا يمكنك استيراد البيانات إلى النظام ، أو لا يتم حفظ تسجيلات المكالمات الهاتفية. ما زلنا نرد على Sev 2s على الفور تقريبًا ، ولكن عادةً ما يكون مجرد شخص واحد في فريق يسقط ما يفعله لبدء إصلاح. لقد حددنا يومين كحد أقصى لإصلاحه ، على الرغم من أنه في الواقع ، عادة ما تنتهي الإصلاحات في غضون ساعات قليلة.

شدة 3s هي الغالبية العظمى من العيوب التي يتم الإبلاغ عنها لنا. هناك شيء ما مكسور تقنيًا ولكنه ليس أداة عرض ، يمكنك العمل حوله بطريقة أو بأخرى ، إلخ.

المفتاح الحاسم لجميع الثلاثة هو أنها محددة زمنيا. فوري ، يومين ، أو 14 يومًا ، لا يهم كثيرًا تقريبًا - ولكن بدون ذلك ، فإن وظيفة الإجبار القائمة على ذلك لن تنجح. مما يؤدي بعد ذلك إلى القطعة النهائية من الحل ...

احصل على الاشتراك والتمسك به!

عندما تتوصل إلى اتفاقية مستوى الخدمة الخاصة بك ، قم بإشراك الجميع في الغرفة. ابدأ بفرضية أن الجودة مهمة ، واجعل الفريق يوافق على أنها مهمة ، وأن الجميع سوف يتبعون الاتفاقية. احصل على فريق المنتج على متن الطائرة ، وفريق الدعم الخاص بك ، والجميع. لا يهم كم هي عملية كبيرة إذا لم يأخذها أحد على محمل الجد.

وأخيرا - خذها على محمل الجد. إذا كان لديك 14 يومًا كحد أقصى ، وكان هناك عيب يصل إلى 14 يومًا ، فعليك حرفيًا العثور على المهندس الذي تم تكليفه به وإسقاطهم لأي عمل مميز يقومون به والقفز على الخلل. هذا يأخذ الانضباط. لا تتمثل الفكرة في السماح لكل عيب بالوصول إلى 14 يومًا أيضًا ، ولكنه وقت طويل بما يكفي للتأكد من أن الفريق لديه المرونة في اتخاذ القرارات ذات الأولوية. لديك ميزة ضخمة على وشك الخروج؟ حسنًا ، ادفع العيب لبضعة أيام. فقط اعلم أنه عندما يبدأ عمر 10 أو 11 يومًا ، فمن المؤكد أنك ستنظر إليه.

لدينا في الواقع مقياس هندسة لهذا الغرض ، يسمى "عيوب الشيخوخة" والذي يتتبع أسبوعيًا عدد الأخطاء التي يبلغ عنها العملاء والتي يزيد عمرها عن 14 يومًا. هدفنا هو أن تكون صفرا ، كل أسبوع ، أسبوع بعد أسبوع. هذا هو مدى أهمية هذا.

بمجرد أن تسمح لها بالابتعاد عنك ، يكون من الصعب للغاية استعادتها. إذا قمت بذلك بشكل صحيح وأخذت على محمل الجد الجودة ، فإن ما تبقى لك هو منصة خالية من الإحباط لعملائك ، وقاعدة بيانات جديرة بالثقة لفريق تطوير المنتجات الخاص بك ، وأوامر بحجم أقل تصل إلى فريق الدعم لديك. في النهاية ، يتيح لك الوقت الكافي لإصلاح الأشياء التي تنكسر - عندما تنكسر - التحرك بشكل أسرع على المدى الطويل.