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

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



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

دعنا نبدأ!



عن المتحدث: يعمل نيكولاي كرابفني (@ cyberklin ) في Badoo منذ ثماني سنوات ، خمسة منهم يشاركون في إدارة الفريق وعمليات تطوير البناء.


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

الاتصالات

بادئ ذي بدء ، دعنا نتحدث قليلاً نظريًا عما يحدث للاتصالات عندما تنمو الشركة.

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

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

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

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

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

الشركة تنمو - الاتصالات "ممزقة".

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



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

لقد كان جزءًا نظريًا تمهيديًا صغيرًا.

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

الاختصاصات

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



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

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

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

عميل الخادم

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

التوثيق

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

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

الافراج لا يعود

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



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

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



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

• من فريق المنتج يتلقى مهمة تطوير المعارف التقليدية (PRD) ؛
• يقوم فريق تصميم البروتوكول بإعداد الوثائق ؛
• يبدأ تطوير أجزاء العميل والخادم وفقًا للتوثيق.

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

مشكلة الإحصائيات

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

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

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

يجب إضفاء الطابع الرسمي على عملية جمع الإحصاءات وتحليلها.



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

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



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

مشاركة التحميل

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



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

من المعتقد أن قائدًا واحدًا أو فريقًا أو قائدًا فنيًا يجب أن يقود فريقًا يصل إلى 7-9 أشخاص. هذا هو عدد مثبت تجريبيا لعدد كاف من المرؤوسين.

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



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

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

في هذا الخيار ، نحن نعمل الآن. يتألف الفريق من 30 شخصًا و 5 مجموعات و 22 مكونًا نتشاركها فيما بينهم. في حين أننا لا نرى حدًا لمزيد من النمو في هذا الشكل ، فإننا سنلتزم به على نطاق معين.



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

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



صنعنا لأنفسنا أداة تسمى WTF. هذه أداة واحدة تجمع في حد ذاتها من جميع أنواع النظم الفرعية وأجزاء الإنتاج شيء يمكن أن يؤثر بطريقة ما على المقاييس. , . , (, ), ( ).



: — , - . .

:

• . .
• , .
• , , — .
• .

:

• .
• BI, ;
• MAPI .
• , — .

200 . , , . , :)

السرعة

. , , .



Time-to-marker . .



. , , , - . , , .



: . , , . - . . : — . . , , . , .

-, , . - .

• . - . .
• . 10 , . : . . .
  
• - . bus- , . , , , .
  

, ( — ), . , OX . . OY .

, .



. - — . - , time-to-market , . - , , - , - , . , , . .



. - . , , . . , workflow. (, ) . - . , , .



, . , , , . , — . . — 2 , . , . , , . - - , - , .

. , , .



70–80 . , , . , . , - , .



.

— , - — .

, . , , - , , — - . , , — . .

—

, , . , . , .



. , . , , , . , - , , , server-side , . , , - , . , server-side, , . 14 , . - , server-side. , server-side 50/50. , , , . , , , - , , . , , .



.

— , . , , - , , .

. , , , , . « ».

. , — , , , . 50/50 10- .



, — . , . , 3 . - , 12 . 3 — , . , , , , , , , - , . — . . 11:00, — 9:00. , .

, — , 2 , , . , — , , - , -, , . , - , .



, , « ». - , , - . :

• : — , ..
• — , , , : « ». , .

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



لا أحد يلغي حقيقة أنك تحتاج فقط للقاء أكثر في كثير من الأحيان . كل شيء قياسي هنا:

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

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

هكذا نعيش في Badoo.

ندعوك للتجسس على جزء جديد من التجارب التنظيمية لشخص آخر في Saint TeamLead Conf . يتضمن البرنامج كلمات من شركات مشهورة جدا: Sberbank-Technologies، Avito، JetBrains، Spotify ... نعم ، كلها رائعة!

هذا التقرير هو واحد من عشرات التقارير ، إذا كنت لا تريد الانتظار حتى نحصل على أيدينا لفك تشفيرها ونشرها على حبري ، فقم بمشاهدة قائمة تشغيل المؤتمر على قناتنا على YouTube .

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