كيف نتغلب على عدم اليقين في Delivery Club

أيها الأصدقاء ، مرحبا بالجميع! اسمي Kolya Arkhipov ، أنا مسؤول عن البحث والتطوير في Delivery Club.



يقوم فريقنا بحل المهام العلمية المكثفة داخل منصة FoodTech: نقوم بتطوير المكونات بناءً على الخوارزميات والبيانات ، والتي يوجد الكثير منها في منصة DC. في عملية الحل ، نواجه العديد من أوجه عدم اليقين من جانب الأعمال التجارية والتنمية.



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



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

ظهر المقال بعد التقرير في مؤتمر RIT ++ 2020 . بالنسبة لأولئك الذين يحبون الفيديو ، ابحث عنه في نهاية المقال.

هل الغلاية تغلي بالفعل؟ ممتاز! إذن ، ما الذي سيتم مناقشته اليوم:

1. البحث والتطوير وعدم اليقين. ما واجهناه.
2. التجارب. كيف ولماذا نديرهم في المعركة.
3. القابلية للقياس. دعونا نناقش اختيار المقاييس والعمل مع المخاطر.
4. الحكم الذاتي. كيف قمنا في DC Tech بتكييف إطار عمل GIST ونهج Inner Source.

الضوء الأخضر ، القابض ، أولاً - دعنا نذهب.

البحث والتطوير وعدم اليقين

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



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



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





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



كيف نحقق الهدف



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



بالضبط ما يستحق القيام به



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



عندما نتمكن من الوصول إلى هدفنا ،



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



لماذا يحتاج أي شخص إلى رمز بلدي على الإطلاق



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



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

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

بشكل تخطيطي في الصورة أدناه.



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



نحن لا نتوقف. القابض ، الترس الثاني ، نكتسب الزخم بسرعة.

التجارب

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



يبدو واضحًا ومباشرًا ، وهنا يمكنك القول - نظرية كافية! حان الوقت للانتقال إلى عمليات الإطلاق الحقيقية.



أنا أتفق معك ، لكن دعنا نتحدث قليلاً عن عملية التجارب. لنلق نظرة على الصورة كاملة.

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

دعنا نلقي نظرة فاحصة على العملية التي تتم تحت غطاء زيادة المنتج.







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



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



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



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



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



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

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

تجربة حقيقية

حان الوقت أخيرًا لنرى كيف يعمل هذا مع مثال من العالم الحقيقي. هل تعبت بعد؟ يبدأ المرح.



العودة إلى منصة التخصيص التلقائي. قبل ذلك ، اقترحنا أن نهج Just In Time سيكون رائعًا جدًا بالنسبة لنا لتقليل وقت التسليم. سنقارنها باستراتيجية التخصيص الحالية ، والتي نشير إليها على أنها خوارزمية جشعة.



أولاً ، دعنا ندعم الفرضية.

خوارزمية الجشع

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





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

في الوقت المناسب

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

• سيقضي الساعي وقتًا أقل في المطعم ؛
• سوف نختار البريد السريع على النحو الأمثل.

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







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



في رأيي ، الفرضية مبررة ، ونحن نأخذها في مرحلة التطوير. كما هو متفق عليه ، لن نفكر في عملية التطوير بالتفصيل.

دعنا ننتقل إلى تحضير التجربة

ما الذي يجب تحضيره في حالتنا؟ ليس كثيرًا: فترة اختبار A / B ، وجغرافية التجربة وتلك التي سنقارن بها. توقفنا في مدينة معينة ، واخترنا الظروف لتقليل تأثير استراتيجية موعد واحد على الثانية.



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



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



حسنًا ، دعنا ننتقل. أعد تجربة وأجرها وحصلت على النتائج. وهنا يأتي الجزء الممتع - التحليل.

تحليل التجربة

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



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

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

نتيجة لذلك ، لدينا انخفاض في المقياس الرئيسي (1) ، انخفاض في مقياس مهم جدًا (2) ، قيم ثابتة للمقياسين الرئيسيين الآخرين (3 ، 4) ، العلامات الحمراء غير مضاءة. هذا يسمح لنا باستنتاج نجاح التجربة وصحة الفرضية قيد الاختبار.



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

1. يطرح
2. التراجع
3. استمر

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

تجارب العالم الحقيقي

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



لماذا اخترنا النهج الأول لأنفسنا؟ سببان.

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  يجدر بنا أن نكون صادقين هنا في أن هذا نهج محفوف بالمخاطر إلى حد ما. خطر خيبة أمل الجمهور والعملاء والأعمال. هذه المقالة مخصصة إلى حد كبير لكيفية تقليل مثل هذه المخاطر: اختر المقاييس بعناية ودقة (عدة) وراقبها في الوقت الفعلي. في حالة حدوث خطأ ما ، نقوم فقط بإيقاف التجربة على الفور.

• والثاني بالطبع هو السرعة. ستظهر التجارب في ظروف القتال نتائج أكثر دقة وأسرع.

قبل أن نركض أبعد من ذلك ، دعونا نحقق انتصارات صغيرة





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



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

القابلية للقياس

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

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

تُظهر تجربتنا أن الوصفة الجيدة هي عندما يكون هناك العديد من المقاييس. مقياس هدف واحد - تحسينه ؛ وعدد قليل من العناصر الرئيسية - يجب ألا نتخلى عنها.



تقديم مساحة مراقبة موحدة ينظر فيها كل من الأعمال والتنمية. ليس من الضروري أن تكون أداة واحدة ، فنحن نستخدم اثنتين: Metabase و Grafana ، لكننا نخطط في المستقبل لاختيار واحدة منهما. الشيء الأكثر أهمية هو أنه يجب أن تكون هناك مساحة واحدة حيث سيبحث الزملاء من كل من الأعمال والتطوير. وتأكد من تحديد العلامات الحمراء.

الأعلام الحمراء

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



ونصرًا صغيرًا آخر: أجبنا على السؤال "لماذا يحتاج أي شخص إلى الكود الخاص بي على الإطلاق". دعونا لا ننسى لها!





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



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

الحكم الذاتي

كل ما سبق يعمل بشكل جيد قدر الإمكان فقط عندما نصبح مستقلين من جانبي الأعمال والتنمية.

جوهر

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





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



إذن كيف يساعدك هذا النهج في تحقيق الاستقلالية؟ عندما نقترح إنشاء هذه الميزة (في الوقت المناسب) ، يرى العمل بشفافية:

1. حجم وتكلفة تنفيذ الميزة.
2. ما هي الفكرة التي ينفذها.
3. ما هو الهدف المحدد للشركة (الأثر).

ثم نحتاج فقط إلى مقارنته مع مشروع Step المجاور وفقًا لنفس المعايير: التكلفة والتأثير. نعقد اجتماعًا (هم منتظمون معنا) ، ونناقش ، ونحدد الأولويات ونتخذ قرارًا.



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

المصدر الداخلي

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

1. ضع تحسينات على الأعمال المتراكمة للفرق الأخرى ، واتفق على أن اللاعبين سيقومون بها.
2. افعلها بنفسك.

في التكيف لدينا ، العملية تعمل على النحو التالي. هناك ميزة كبيرة في الوقت المناسب ، وهي تؤثر على ثلاث مجموعات من الخدمات:

• نظام أساسي للتخصيص التلقائي يكون البحث والتطوير مسؤولاً عنه ،
• منصة لوجستية ،
• مكونات التفاعل مع الشركاء (مطاعم ومحلات تجارية).

نحن نفعل هذا:

1. جمع جميع المهام في تراكم فريق البحث والتطوير ؛
2. نحن نعطي الأولوية ونوزع داخل الفريق أيًا من اللاعبين سيعمل على تحسين أي من المكونات ؛
3. نتفق مع القادة الفنيين لفرق الخدمات اللوجستية والمناطق الشريكة على الفروق الدقيقة في التنفيذ ؛
4. نقوم بتطوير أنفسنا ، يقوم الزملاء بإجراء مراجعة ؛
5. ثم نختبر أنفسنا.
6. نحن نمنح أصحاب الخدمة بالفعل لبدء الإنتاج.

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



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



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



لذا ، تهانينا - انتهى ، انتصار!





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

الاستنتاجات

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

تسجيل فيديو لتقرير مؤتمر RIT ++ 2020 .





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