تحويل المنتج في Delivery Club Tech

صورة



مرحبا هبر! كما وعدت في المنشور السابق ، أواصل تقديمك إلى Delivery Club Tech. اليوم سنتحدث عن تحول المنتج.



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



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



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



ميزات الفريق



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



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



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



صورة



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



  1. مستهلك
  2. الخدمات اللوجستية
  3. بائع
  4. داخلي


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



نتيجة لذلك ، حصلنا على الخلية التالية: "مدير المنتج - قائد الفريق - التطوير - ضمان الجودة". نقوم بتضمين مطوري الواجهة الخلفية والخلفية كمطورين ، ولكن هناك أيضًا فرق بدون واجهات. الواجهة الأمامية هي إما Web Angular و JS ، أو iOS / Android.



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



لفترة من الوقت جربنا الأدوار داخل الفريق ، كان لدينا قادة فريق تطوير الأجهزة المحمولة (iOS / Android) وقائد فريق الخلفية. لكن انتهى بنا الأمر ببنية مصفوفة:



  • يقود فريق واحد (عادة ما يكون شخصًا من الواجهة الخلفية) ، وهو يقدم تقاريره مباشرة إلى سؤال وجواب ، والخلفية والواجهة الأمامية.
  • product- « — — QA».
  • — . . , QA- , CI/CD, QA- .
  • - , .
  • .


صورة



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



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



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



تطوير وتخطيط Sprint





مرحلة ما قبل التخطيط



قبل أسبوع من بدء السباق ، يجلب مدير المنتج الحالات والتصميم ، ويجيب على السؤال "ما الذي يجب عمله؟" يقرر الفريق الفني كيف سيفعل ذلك ومتى يكون كل شيء جاهزًا.



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



التخطيط



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



يتم التغلب على مهام أخرى في دلاء ، لا يوجد سوى ثلاثة منهم:



  1. المنتج 60٪
  2. ديون التكنولوجيا 20٪
  3. دعم 20٪.








اسمحوا لي أن أقدم لكم مثالا. لدينا فريق من 3 مؤيدين. هذا 80 * 3 * 0.8 = 192 ساعة مفيدة. سنقضي 116 ساعة (60٪) في تطوير المنتج ، و 38 ساعة على الدين التقني (20٪) ، و 38 ساعة على الدعم (20٪).



الاستدراج



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



تجريبي



الاستنتاج المنطقي للسباق هو العرض التوضيحي ، حيث ندعو جميع فرق التطوير وأصحاب المصلحة وزملاء العمل وحتى رئيس نادي Delivery.



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



هذا يوم مهم للفريق بأكمله!



ريترو



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



على سبيل المثال ، في المنتج ، أخذنا 20 مشكلة وانتهينا من 17. لذلك ، فإن معدل النجاح لهذه المجموعة هو 85٪. يعتبر التقدم الجيد في تطوير المنتجات بالنسبة لنا مؤشرًا بنسبة 90٪ أو أكثر. إذا كان أقل ، فإننا نحلل في Retro كيف يمكن تحسين هذا المقياس.



عمل سبرينت



غالبًا ما يُسألون عن مراجعة الكود وكيفية عمل الاختبار. كل شيء قياسي هنا.



يبدأ اليوم بوقفة. لمدة 15 دقيقة ، يناقش الفريق ما فعلوه بالأمس وما سيفعلونه اليوم.



نستخدم Jira Flow و Git Flow للعمل على المهام ، لدينا مكدس Atlassian. هناك أيضًا لوحة Scrum بها أعمدة للقيام بها - قيد التنفيذ - جاهزة لمراجعة التعليمات البرمجية - جاهزة لضمان الجودة - جاهزة للحياة - تم تنفيذها.



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



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



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



اتجاهات التطوير وهيكل قسم تكنولوجيا المعلومات



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



  • المستهلك هو كل شيء عن المنتجات المخصصة: مواقع الويب وتطبيقات الأجهزة المحمولة.
  • الخدمات اللوجستية - حول اللوجيستيين والسعاة والتسليم.
  • البائع - حول التكامل مع شركائنا (مطاعم / محلات).
  • داخلي - مركز الاتصال والدعم.
  • البحث والتطوير - حل المهام العلمية المكثفة.
  • المنصة - تحسين البنية والمنصة ككل.


لكل اتجاه مجموعة مهامه الخاصة وصعوباته الخاصة.



مستهلك



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



المنتجات الرئيسية هي موقع ويب ، بما في ذلك إصدار الهاتف المحمول ، بالإضافة إلى تطبيقات لنظامي التشغيل iOS و Android. المساران الرئيسيان هما توصيل البقالة وتوصيل المطاعم. المكدس التكنولوجي زائد أو ناقص مثل أي مكان آخر: PHP و Go و Postgres و Redis و Memcache للتخزين المؤقت ، كافكا للتواصل غير المتزامن.



الخدمات اللوجستية



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



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



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



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



أحد التطبيقات الرئيسية التي يتم العمل عليها في مجال الخدمات اللوجستية هو تطبيق Rider. إنه تطبيق Android حيث يرى السعاة مكان استلام الطلب ومكان تسليمه.



بائع



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



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



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



داخلي



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



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



بحث وتطوير



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



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



منصة



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



نتائج التحول والتحديات الجديدة



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



بعد إجراء تحويل المنتج وتحسين عملية التطوير ، توصلنا إلى استنتاج مفاده أن كل إصدار من إصداراتنا أصبح متوقعًا. في البداية ، عرفنا بدقة 80٪ متى وفي أي تكوين سيتم إصدار الإصدارات. الآن ، نما متوسط ​​مؤشر الأداء عبر جميع الفرق داخل القسم إلى 90٪. لقد زادت مشاركة الفرق ، أي دافع الرجال ، بشكل كبير ، فهم يفهمون ما يفعلونه ولماذا ، ولمن هو مهم.



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



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



شكرا للقراءة!



All Articles