من الفكرة إلى الإصدار. تجربة السوق مفصل

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

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

الفريق

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

يوظف Yandex.Market الآن 40 مطورًا أماميًا ، ويتزايد عددهم. نعم ، 40 شخصًا - هذه هي الواجهة الأمامية للسوق فقط ، وهناك أيضًا جبهات لمشروعينا الآخرين - أسواق Beru و Bringly. في عام 2005 ، كان هناك فقط 5 مطورين في السوق ، تخيلوا؟

تولد الأفكار في دوائرنا. لذلك نحن ندعو فرق تتكون من مختلف المتخصصين. عادةً ما تتضمن الدائرة: مشروعًا (يُعرف أيضًا باسم تقني المنتج) والواجهة الخلفية والواجهة الأمامية والمحللين والمصممين والمُختبرين. يمكن لمثل هذا الفريق تطوير شيء ما في الخدمة بشكل مستقل وحل المشكلات بأي تعقيد. علاوة على ذلك ، لكل دائرة محيط واضح من المسؤولية - "دائرة وظيفية" معينة في المنتج الذي تعمل عليه.

لدينا ، على سبيل المثال:
- حلقة التحويل - تتعامل مع أدوات UX والبحث والترشيح والفرز ؛
- دائرة الاتصالات - يعمل على النشرات الإخبارية والترقيات لمستخدمينا.
- فائدة كفاف - يتعامل مع الخصومات ، استرداد النقود ، الرموز الترويجية ؛
- دائرة المجتمع - مسؤولة عن الاستعراضات والتعليقات والمناقشات والإنجازات وميكانيكا اللعبة وغيرها من UGC.

أفكار

يمكن لأي عضو في الدائرة تقديم فكرة. نرحب بجميع الخيارات ، حتى تافهة أو مجنون تماما. عادةً ما يولد الشباب الأفكار في الاجتماعات العامة - وهذا يفرض على الفريق بأكمله العمل.

حتى لا نفقد أي شيء ، نضع كل أفكارنا في منعطف منفصل في Tracker - بنك الأفكار لدينا. يتم تقييم الأفكار المجمعة وفقًا لإطار GIST + ICE. نقوم بتقييم إمكانات كل فكرة وتكاليف العمالة للتنفيذ لتقرير ما يستحق القيام به في المقام الأول. أخبر زميلي المزيد من التفاصيل حول هذه الطريقة.

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

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

هذه العملية

لنفترض أننا قررنا تطوير مجموعة من السلع للمستخدم ، مع مراعاة اهتماماته.

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



يبقى القيام بالعمل على الواجهة الأمامية وتسليم دائري لدينا للمستخدم.

The Frontend of the Market هو عميل ويب وخادم NodeJS عديم الجنسية ، يوجد خلفه العشرات من العناصر الخلفية الأخرى: البحث والخدمات الاستشارية والتحليلات ومحتوى UGC والمزيد. الواجهة الأمامية تعيش في السحب ياندكس في العديد من البلدان النامية. يتم تنفيذ تطبيق NodeJS في حاويات ، وبسبب طبيعته عديمة الجنسية ، يمكن تحجيمه أفقياً كما نحتاج:



يقوم مطورو السوق الأماميون بتطوير جانب الخادم على NodeJS والعميل على React + Redux. تطوير بلغة واحدة وفي نظام بيئي واحد هو فعال جدا. إذا كنت لا تزال تفكر في توحيد مكدس التكنولوجيا الخاص بك بين الخادم والعميل ، فجرّب - الأمر المنطقي.

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

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

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

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



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

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

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

لذلك ، لدينا مجموعة مرح من المنتجات الموصى بها يذهب إلى الإفراج. كيف الحال؟

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



يرى مهندس ضمان الجودة جميع المراحل ، بنظرة واحدة يمكنه تقييم نتائج كتلة الشيكات. في بيئة الاختبار في الحامل مع الإصدار الجديد ، تخضع QA أيضًا للاختبار اليدوي. غالبًا ما نجري اختبار A / B للوظائف الجديدة ولا نكتب اختبارات E2E عليه.

هذه هي الطريقة التي يبدو بها خط أنابيب الإصدار (قابل للنقر):



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

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

يتم مراقبة صحة السوق بعد الإصدار من خلال ضمان الجودة في الخدمة. لديه عدد كبير من الرسوم البيانية تحت تصرفه - نحن نستخدم Graphit و Grafana. تحتوي الرسوم البيانية على كل شيء: من الخلفية العامة 500 كيلو إلى أخطاء تطبيق NodeJS عند الاتصال بالعديد من الواجهات الخلفية المقسمة حسب DC. لدينا أيضًا مجموعة منفصلة من الأشخاص - مجموعة Market Market. انها تراقب مقاييس السوق 24/7.

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

في هذه اللحظة ، يرى المستخدمون لدينا بالفعل المنتجات المحددة لهم ، وتعمل الدائرة على فكرة جديدة.

هنا لدينا دائري على الخدمة:

بدلا من الاستنتاج

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

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

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