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

في ما يلي استمرار لقصة بعنوان " كيفية البقاء على قيد الحياة في إطار قابل للتحجيم والحفاظ على ضبط جودة الكود " حول تحول Agile في IVI. في TeamLead Conf ، شرح المدير التقني للشركة ، Evgeny Rossinsky ( eross ) ، السبب في أنه قد يكون من الضروري التراجع عن إعادة التنظيم بالكامل للفريق ، وكيفية عدم التشاجر مع المطورين ومساعدتهم ، ولكن أيضًا للمحافظة على كفاءة العمل وزيادةها.

سياق الشركة

ivi - أكبر سينما إنترنت قانونية يبلغ جمهورها 48 مليون مستخدم ، الذين يقضون جماعيًا 70 مليون ساعة شهريًا. يحتوي Ivi على 62 ألف وحدة محتوى ، وهو متاح من أجهزة مختلفة ودائماً بجودة ممتازة.

لقد حدث أنه في نفس اليوم الذي تحدث فيه يوجين في TeamLead Conf مع هذا التقرير ، كان عيد ميلاد الشركة. منذ 9 سنوات ، حدث الإصدار الأول من إصدار الويب للمشروع ، وبعد يومين ، جلبت قوة القناة الأولى عددًا كبيرًا من المستخدمين إلى iiv. حتى أن الشركة اعتقدت أنه كان DDoS ، لكنها كانت قادرة على الصمود بكرامة.

هذه المقالة تدور حول إطلاق منتج جديد - إعادة تشغيل كاملة لجميع التطبيقات.

شاهد الفيديو لسماع الإصدار غير الخاضع للرقابة أو اقرأ نسخة التقرير في الشخص الأول.



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

الكفاءات:

• Backend (Python، Golang، Java)؛
• Web (JavaScript ، Node.js) ؛
• Android (جافا)
• iOS (الهدف- C ، سويفت) ؛
• SmartTV (JavaScript) ؛
• Windows / XBox (C #) ؛
• سوني PS (جافا سكريبت).

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

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

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

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

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

سرد قصير للتحول

في عام 2017 ، قدمنا ​​مفهوم Value Stream - فهذه فرق متعددة الوظائف مسؤولة عن مهام أعمال محددة. لفهم نوع الأعمال المحددة التي نتبعها في أعمالنا ، جمعنا ما بين 25 إلى 30 شخصًا من الشركة بأكملها ، والمدربين المدعوين الذين يشاركون في منهجيات مرنة ، وفي يومين قمنا بصياغة ما يجب أن تكون عليه القيمة - اتجاهات التطوير.

حصلت على 5-6 تدفقات القيمة. لقد زرعوا هؤلاء الأشخاص معًا ، وأعطوا كل واحد مالكًا للمنتج ، والذي سيكون غارقًا في هذا الاتجاه المحدد (مزيد من التفاصيل هنا ).

عرفنا الألم والدم والدموع والفرح وتوصلنا إلى مؤشرات جيدة للغاية:

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

لقد نجينا من العام جيدًا - في عام 2017 ، تضاعفت الإيرادات تقريبًا .

لكن هذا لم يكن كافيًا ، وكانت الحياة في أواخر عام 2017 - أوائل عام 2018 بمثابة مفاجأة لنا.

لماذا تحتاج إلى منتج جديد

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

لا يقول المساهمون كيف يقومون بذلك ، بل يقولون ما يريدون تحقيقه. كيف - يجب أن يقرر الفريق.

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

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

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

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

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

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

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

أهداف

أردنا أن:

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

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

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

تساعد الأدوات الأصلية في تقديم تطبيقات جيدة وجيدة وسريعة. في حالة الفيديو ، هذا ضروري ببساطة.

البحث عن حلول الإدارة

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

يبدو أن لدينا نظامًا اعتدنا عليه للناس لبعض الوقت ، والآن تغيرت قواعد اللعبة.

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

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

كان من الصعب للغاية التمييز بين مجال مسؤولية Value Stream ، الذي يقوم بدور ما عندما يجلس الناس في طوابق مختلفة ، في غرف مختلفة.

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

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

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

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

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

كل ما هو جديد قديم طي النسيان.

سنعود كل شيء كما كان

بعد تحول Agile المظلم ، قررنا أن نفعل كل شيء كما كان في عام 2016 ، لأنه يجب الحصول على الحق في الديمقراطية.

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

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

فعلت ما يلي:

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

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

لن تنجح ، مرة أخرى مشاكل في المنظمة

المشاكل الرئيسية قبل عامين كانت: المركزية واتخاذ القرارات.

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

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

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

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

ماذا فعلت

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

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

دعم للتطبيق القديم . لا يمكن التخلي عن الخدمة التي يبلغ جمهورها ملايين الدولارات. بالتوازي مع كتابة منتج جديد ، يجب القيام بشيء ما مع المنتج القديم. هذا مزعج بشكل رهيب!

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

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

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

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

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

اتضح حقيقة مثيرة للاهتمام - اتضح أن تحمل المسؤولية غير سارة.

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

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

كيفية إصلاح الوضع

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

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

لقد حددنا المهام التالية لضمان الجودة:

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

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

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

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

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

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

حقق مشروع "The Flying Squads of Retribution" التوقعات ، ودخلنا خط الإصدار دون قتل بعضنا البعض.

ما التالي؟

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

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

: , , , . . .

برنامج St. Petersburg TeamLead Conf جاهز تقريبًا. لنقم ببعض عمليات التشغيل ، وأضف اللمسات الأخيرة للكشف عن جميع الموضوعات المخططة ، وابدأ الحديث عن التقارير في الكتل. في الوقت الحالي ، يمكنك بشكل مستقل تقييم قائمة التقارير وحجز يومي 23 و 24 سبتمبر لضخ مهارات زملائه في الفريق.