نتخيل جميعًا تقريبًا كيف تبدو التنمية في شركة كبيرة وكيف يمكن أن تختلف التنمية الصغيرة عنها. ولكن ماذا يحدث إذا تغير حجم الشركة بسرعة وزاد عدد الموظفين عشرة أضعاف على مدى عامين؟ عندما تنمو الشركة الناشئة بسرعة ، وتحتاج إلى التكيف مع الظروف الجديدة أثناء التنقل ، كيف يؤثر ذلك على كل شيء (من العمليات إلى التقنيات)؟
سوف تشارك ManyChat في مؤتمر HolyJS ، وهو بالضبط ما يحدث. لذلك ، طلبنا دعمًا فنيًا لتطوير الواجهة الأمامية لـ
Evgeny Kuvshinov وبشكل خاص حول ManyChat ، وبشكل عام حول ما يشبه القيام بالتطوير (الواجهة الأمامية) في بدء التشغيل.
- أولاً ، أخبرنا بإيجاز بما تفعله في ManyChat وماذا تفعل الشركة نفسها.- لقد جئت إلى الشركة كمطور أمامي فقط ، وبعد ستة أشهر نشأت على رأس فريق الواجهة الأمامية. ثم كان لا يزال لدينا مثل هذه الفرق الوظيفية - الأمامية ، الخلفية ، الاختبار ، المنتج. وبعد إعادة بناء جميع عملياتنا على LeSS ، عدت إلى التطوير ، ولم يكن لدي أي مهام تنظيمية سابقة. إنني منخرط في تجربة المستخدم ، أحاول الارتباط بجزء المنتج ، وأتطور جزئيًا كمدير للمنتج ، ولكن في نفس الوقت أكتب التعليمات البرمجية باستمرار.
كشركة ، نساعد الشركات على استخدام قناة الاتصال الجديدة نسبيًا ، Facebook Messenger. يعد ManyChat نظامًا أساسيًا لإنشاء روبوت للدردشة بسرعة وسهولة لبرنامج Messenger. لا يتعلق هذا بالذكاء الاصطناعي ، وليس بمحاكاة محاكاة التواصل البشري ، ولكن حول سيناريوهات حيث لا يلزم ذلك. بمساعدة الروبوتات الخاصة بنا ، يمكنك فقط عمل رسائل إخبارية ، ويمكنك إعداد أشياء تفاعلية أكثر تعقيدًا مثل الطلبات والحجوزات وبرامج الولاء. يتم ذلك أيضًا بصريًا وواضحًا ، ويمكن القيام بذلك إما من قبل صاحب عمل متقدم إلى حد ما أو مسوق بدون مهارات البرمجة.
يمكنك أن ترى كيف تعمل البوتات في Messenger بشكل عام ، باستخدام مثال محدد: في الوقت المناسب لـ HolyJS ، قمنا بإنشاء
روبوت خاص .
- بالتأكيد تسمع باستمرار الكلمات "لكن روبوتات الدردشة فشلت قبل عامين." هل تُظهر تجربتك ، بشكل عام ، في سياق معين ، أنها مناسبة تمامًا؟- نعم. ربما الأهم من ذلك كله ، لم يثبت النفعية من خلال قضيتنا ، ولكن من خلال منصة WeChat. هذا رسول يستخدمه الجميع تقريبًا في الصين ، وهناك الكثير من الشركات فيه ، وأشياء مثل طلب البيتزا أو سيارة أجرة في الصين تحدث الآن بنشاط من خلال WeChat. وهذا يوضح أن بعض السيناريوهات التفاعلية للتواصل البشري والتجاري تعمل بشكل جيد حقًا ، فهي مناسبة لكلا الطرفين.
وتلك الاستخدامات التي كانت ضجة منذ عامين - مثل يمكنك التواصل مع روبوت كشخص وسيقدم أفضل نسخة من رحلة إلى طائرة - حسنًا ، هذا لا يعمل جيدًا حقًا.
ونقوم بتنفيذ شيء قريب من WeChat ، ولكن في أسواق أخرى: في المقام الأول ، في الولايات المتحدة ، على الرغم من جميع أنحاء العالم أيضًا. لدينا عدد كبير من العملاء من أوروبا ، وفي البلدان القريبة من الصين أيضًا ، يستخدم الكثيرون الآن Facebook Messenger.
- ننتقل إلى موضوع النمو: إلى متى ظهرت الشركة ، وكيف نمت من تلك اللحظة إلى عصرنا؟- ظهرت الشركة عام 2015. بدأ الأمر بحقيقة أن المؤسس المشارك Mikael Jan كان بحاجة إلى عمل رسالة إخبارية على Telegram (ثم لم تكن هناك قنوات بعد). أدرك أن الأمر معقد للغاية ، وأن أداة خاصة ستكون مفيدة. ونتيجة لذلك ، صنع مايكل وأنطون غورين لأول مرة منصة لإنشاء برامج الروبوت في Telegram. بدأت المنصة في النمو بسرعة كافية ، وضربت مسرع بدء التشغيل في الوادي.
وأثناء وجودهم في المسرّع ، فتح Facebook واجهة برمجة التطبيقات لـ Messenger. وكانت تلك هي اللحظة التي قرروا فيها صنع محور حاد ، لعمل منتج جديد خصيصًا لـ Facebook Messenger. يبلغ عدد المشتركين في Messenger شهريًا 1.4 مليار شخص ، وفي الفيسبوك العديد من الشركات لديها تمثيلاتها في شكل صفحات رسمية. وبالنسبة لهذه الصفحات ، يمكنك إنشاء برامج التتبع.
في البداية ، كان هناك ثلاثة موظفين: مايكل وأنطون ومطور آخر قاموا بعمل الإصدار الأول من الواجهة الأمامية. في خريف العام نفسه ، تم تلقي الاستثمارات الأولى وأصبح من الواضح أنه يمكنك البدء في توسيع الفريق. ثم جئت أنا وثلاثة مطورين آخرين إلى الشركة ، لذلك في نهاية عام 2016 كان هناك سبعة منا. والآن ، بعد ذلك بعامين ، هناك بالفعل أكثر من خمسين منا ، ويستمر النمو.
إذا نظرت إلى أرقام المنصة نفسها ، فلدينا بالفعل أكثر من 400000 روبوت متصل. نحن ننمو بشكل جيد من حيث المؤشرات المالية: بالفعل في الوقت الحالي نحن شركة مربحة ، بينما نواصل البحث عن الاستثمارات من أجل النمو بشكل أكثر نشاطًا. في العام المقبل ، نخطط لمضاعفة عدد الأشخاص على الأقل.
- تعد الشركات الناشئة مجالًا تجريبيًا للغاية حيث يتم عمل الكثير عن طريق التجربة والخطأ (مثل المحور المذكور ، عندما بدأنا بمفهوم واحد ، ثم تغيرنا أثناء التنقل). كيف يؤثر ذلك على التنمية؟ هل يعني هذا أنك تحتاج دائمًا إلى الاستعداد للموقف "سيتم التخلص من الميزة التي نفذتها"؟- في الواقع ، هناك شيء يمكنك القيام به بعض الميزات ، ولكن في النهاية لن يكون الطلب مطلوبًا من قبل المستخدمين ، وسيكون اعتماده منخفضًا. أو قد لا تصل إلى الإنتاج على الإطلاق ، لأننا أنفسنا ، بالنظر إلى ما حدث ، سوف نفهم أننا لا نحبه.
لتقليل عدد مثل هذه المواقف ، فإن أول شيء نفكر فيه (ليس حتى أثناء التطوير ، ولكن في بداية تطوير المنتج لميزة) هو التحفيز. لماذا نقوم بذلك ، لمن ، وكم سيؤثر على المستخدمين الحاليين ، وكم نحبه بأنفسنا (هل سنكون سعداء وفخورين بظهور مثل هذا الشيء في منتجنا). بعد تحديد الدافع ، ربما من خلال إجراء استطلاعات في مجتمع المستخدمين لدينا أو بعض المقابلات الأخرى مع مستخدمينا ، نبدأ في التطور. بعد ذلك ، نجهز ميزة العدو ، وتسمى هذه العملية PBR (تحسين المنتج المتراكم): أولاً تنتقل إلى التراكم ، ثم تنتقل إلى هناك في التصنيف ، وفي مرحلة ما ، وقد تم وصفها جيدًا بالفعل ، قد تقع في العدو.
أول شيء نفعله مباشرة في العدو السريع هو أننا إذا لم نفهم كيف سيبدو الأمر ، فإننا نقوم بعمل بعض النماذج والنماذج الأولية. ولكن ، بغض النظر عن مدى غرابة الأمر ، فقد يتم ذلك بالفعل في بعض الأحيان مع التطور. لأنه في بعض الأحيان يكون من الصعب جدًا فهم كيف سيشعر المستخدم بالواجهة ، ببساطة عن طريق عمل نوع من التخطيطات والرسوم التوضيحية.
في كثير من الأحيان ، في الواجهة الأمامية ، نصنع نماذج أولية أو ميزات تفاعلية ، من حيث المبدأ ، تعمل بالفعل ، يمكنك النقر عليها والشعور بها. وبعد ذلك ، من خلال العمل الوثيق مع المصممين ، نأتي بهذه النماذج الأولية إلى خيار سيتم طرحه في الإنتاج. ولكن ، مع ذلك ، عند إنشاء هذه النماذج الأولية هنا ، فإنه ليس من غير المألوف أيضًا عند إنشائها ، والنظر ، وتفهم نفسك "لا ، لن يتوقف ، إنه غير مريح". نحن نحاول استخدام منتجنا الخاص ، ونصنع روبوتات ، حتى قبل أن يكتشف مستخدمونا أين قد تنشأ بعض المشاكل. حسنًا ، بشكل عام ، نحن نركز على تجربة المستخدم ، ونحن نحاول بناء منصة أكثر سهولة في الاستخدام.
- مع النمو السريع للشركة ، ربما تصادف حقيقة أن العمليات التي نجحت للعديد من الأشخاص تتوقف عن العمل عند الانتقال إلى عشرات الأشخاص. كيف تغيرت تطورك من وجهة نظر تنظيمية؟- كانت صعبة. في بداية العام ، واجهنا وضعًا صعبًا إلى حد ما ، عندما قمنا بالعديد من الميزات لعدة أشهر ، كانوا قادرين باستمرار على "إنهاءها قليلاً ولفها إلى الإنتاج" ، لكن هذا "لا يزال قليلاً" لم يأت.
عندما بدأنا لأول مرة ، كان هناك سبعة منا. كان لدينا سكروم ، كانت هناك سباقات سريعة ، تم بناء كل شيء وكان يسير على ما يرام. عندما نشأنا ما يصل إلى 20-30 شخصًا ، ظهرنا ، كما هو الحال في العديد من الشركات ، فرقًا وظيفية: الواجهة الخلفية ، الواجهة الأمامية. مع عملياتها الخاصة ، مع الركض الخاص بها في الداخل ، مع قوائم انتظار المهام الخاصة بها. ولم نقم بمهام تسمى على وجه التحديد "مثل هذه الميزة التي ستجلب مثل هذه ومثل هذه الفائدة لمثل هذا المستخدم". تم استدعاء مهام كل فريق بروح "الواجهة الأمامية: لإعادة ترتيب مثل هذه القطعة من الواجهة ، لذا أضف بعض الأزرار".
وهذا كان سيئا لأسباب عديدة. بادئ ذي بدء ، عندما يكون لدينا العديد من قوائم الانتظار والقطع المختلفة من نفس مهمة العمل ، لديهم أولويات مختلفة ، يصبح من شبه المستحيل فهم متى ستكون المهمة جاهزة تمامًا. ويصبح من الصعب على مطور معين أن يفهم ما يفعله. لأنه يصنع قطعة موصوفة له ، وكيف سيفرح المستخدمون بعد ذلك بالنتيجة ، فهو لا يعرف ، لأنه قد لا يعرف حتى من عدة نواحٍ لماذا كل هذا ضروري.
في مرحلة ما ، أدركنا أن هذا مستحيل بعد ذلك. نعم ، يمكنك توليف القليل ، والتكرار ، ومواصلة تنفيذ الركض والوقوف اليومي (الذي بدأ يستغرق أكثر من نصف ساعة ، لأنهم حضروا من قبل الفريق بأكمله ، ولكن لم يعط أي شيء). لكن هذه إجراءات تجميلية لا تحل المشكلة الرئيسية.
وفي تلك اللحظة ، أخبرنا أحد اللاعبين في الشركة أنه كان هناك شيء يسمى LeSS أو Large-Scale Scrum: سكروم للفرق الكبيرة والمتنامية بالفعل. بعد الجلوس لعدة أمسيات في غرف الاجتماعات ، ومناقشة كل ما كان يجري على الإطلاق ، اتخذ الرئيس التنفيذي و CTO (Mika و Anton) قرارًا تجاريًا صعبًا للغاية: سنقوم بإلقاء عملية التطوير بأكملها (كيف نقوم بتصميم الميزات وتنفيذها ونشرها) في سلة المهملات. سننهي العدو السريع الآن ، ومن ثم سنبني كل شيء من جديد.
كان القرار صعبًا ، وأدركنا أننا كنا نفعل ذلك ، فكرنا لفترة طويلة: "اللعنة ، هل ستنجح أم لا؟" لكننا قررنا أن نجرب كل شيء بنفس الطريقة ، ننتقل إلى الكتاب على LeSS وإلى المدربين المعتمدين. بدأوا بطريقة جديدة ، وأنشأوا فرق متعددة الوظائف - في البداية كان هناك ثلاثة منهم. أطلقنا سباقات أسبوعية قصيرة وفقًا لقواعد LeSS (القواعد بمعنى مجموعة الاجتماعات التي يجب أن تكون على هذه الركض). لن أخبرك بكل التفاصيل ، ولكن في أول سباق أسبوعي للمهام الثماني التي يبدو أنها معلقة علينا والتي لم نتمكن من طرحها لعدة أشهر ، بدأنا في الإنتاج ، إن لم يكن جميعًا ، ثم معظمها. ونحن لم نفهم ما كان يحدث. كيف ذلك؟ لماذا لم نتمكن من فعل ذلك من قبل؟ ولماذا حدث ذلك؟ كان الأمر رائعًا للغاية وبدأنا في المضي قدمًا ، وتولي مهام جديدة ، وحلها في فرق متعددة الوظائف بشكل أسرع.
بالطبع ، كانت هناك بعض الصعوبات وسوء الفهم أيضًا. ولكن على العموم ، على الأرجح ، بالنسبة لمعظم الفريق ، فإن العملية الناشئة تحظى بشعبية كبيرة ، لأن وقت السوق قد انخفض بشكل كبير للميزات ، يمكنك القيام بكل شيء بسرعة كبيرة ، والبدء في الإنتاج. بالإضافة إلى ذلك ، نحاول نقل التعليقات من المستخدمين حتى يتمكن المطورون من معرفة مدى إعجاب الناس بما يفعلونه.
نقطة أخرى مثيرة للاهتمام كانت كيفية طرح الواجهة الأمامية بعد أن انتقلنا إلى LeSS. أدركنا أننا مقسمون الآن إلى فرق منفصلة متعددة الوظائف ، وفي المرة الأولى (على الأقل قبل أن يبدأ مجتمع الواجهة الأمامية في العمل) ، سنتواصل بشكل أقل. وتعلمنا طرح الواجهة الأمامية في أي وقت "بنقرة إصبع" ، عندما نحتاج إليها ... كان لدينا اجتماع واحد قبل بدء سباق جديد ، حيث قلنا أن لدينا فرعنا الرئيسي ، ويمكن طرحه في أي وقت . قبل ذلك ، كانت لدي أفكار مفادها أنه يجب علينا بالتأكيد بناء نظام اختبارات واجهة المستخدم للتكامل من شأنه أن يتحقق من كل تجميع ، وأنه يجب أن تكون هناك نسبة كبيرة من التغطية ، وفقط إذا كان "أخضر" ، يمكننا أن نتدحرج. لكنه كان حلمًا كبيرًا ، لأن المنتج ينمو بسرعة كبيرة ، وفي هذه الحالة ، بغض النظر عن مدى صعوبة المحاولة ، لن تتمكن من الحفاظ على نسبة كبيرة من التغطية. ونتيجة لذلك ، بعد الاتفاق مع جميع المطورين ومنحهم هذه المسؤولية ، تمكنا من جعلها حتى الآن يعمل الرمز من فرعنا الرئيسي دائمًا دائمًا ويمكننا دائمًا أخذ أي تجميع نحتاجه وطرحه من هناك.
- واو ، شكرا للإجابة المفصلة. أود أن أفترض أنه بالإضافة إلى الانتقال الموصوف ، سيتم أيضًا الانتقال من "التراص الكامل" إلى التخصص الضيق: عندما يقوم عدد قليل فقط من الأشخاص بكل شيء في المشروع ، يتعين على willy-nilly القيام بمجموعة متنوعة من الأشياء ، وعندما يكون لدى أكثر من خمسين شخصًا ، يكون لكل شخص دائرة واضحة المهام. هل هذا صحيح؟- عندما كنا قلة ، كان علينا حقًا حل العديد من المشاكل من مجالات مختلفة. على سبيل المثال ، لبعض الوقت كنت منخرطًا في إدارة النظام وقمت بإعداد نظام CI. والآن ، مع الانتقال إلى LeSS ، هذا أقل بكثير.
لكن هذا لا يعني أن الجميع الآن مقيدون بأدوار ضيقة. عندما تأتي إلى الشركة ، يكون لديك الكفاءة الرئيسية (سواء كانت خلفية على الأقل ، أو مصممًا على الأقل) ، ولن يمنعك أحد من ضخ هذا العمودي المحدد في الفضاء ، ولكن في نفس الوقت ، يوفر LeSS فرصة (مجرد فرصة) للتطوير في الاتجاهات ذات الصلة .
نحن مقسمون إلى فرق سكروم قياسية صغيرة يوجد فيها ستة (زائد أو ناقص) ثلاثة أشخاص يتم جمعهم معًا ويجلسون بجوار الجداول المجاورة. وهذا يعني أن الواجهة الأمامية يمكنها دائمًا التواصل مع كل من الواجهة الخلفية والمصمم. إلى جانب حقيقة أن التواصل الرائع مبني بهذه الطريقة ، يمكنك أيضًا التعلم من هؤلاء الرجال. ونرحب إذا كان الشخص الذي يشارك في المقدمة ، على سبيل المثال ، لهذا العدو يريد تولي بعض المهام الخلفية الصغيرة وضخ هذه المنطقة. نظرًا لزيادة معرفتك بالمجالات المختلفة ، زاد تركيزك على المنتج بأكمله ، ومن ثم يمكنك إدارة مشاكلك بشكل أفضل. عندما تبدأ في فهم سبب قيام المصممين بذلك ، ولماذا يقوم خبراء المنتج بذلك ، في بعض الأحيان يمكنك البدء في إنشاء واجهة بنفسك ، والتي يمكنك عندئذٍ عرضها لهم فقط ويقولون "نعم ، رائع". وبالتالي ، يمكنك القيام بعملك بشكل أسرع.
- الشركات الناشئة في طليعة التقدم. هل يعني هذا أنه عند اختيار التقنيات ، يمكنك بسهولة سحب شيء جديد تمامًا إلى الإنتاج؟ وهل هناك أي احتياطات حتى لا يتحول ذلك إلى السعي وراء "أشياء جديدة لامعة" يمكن أن تضر بالشركات؟- الإجابة المختصرة هي نعم ، مستعر أعظم ، رائع ومثير للاهتمام ، ونحن نرحب بهذا بكل طريقة. ولكن ، بالطبع ، هناك معايير معينة لإدخال التقنيات الجديدة.
إذا وجدت أي تكنولوجيا تهمك ، فأنت بحاجة لإحضارها إلى المجتمع. على الرغم من أنه لم يعد لدينا فريق للواجهة الأمامية في شركتنا ، إلا أن هناك مجتمع للواجهة الأمامية نجتمع فيه بشكل دوري ونناقش مثل هذه القضايا. هناك يمكنك أن تخبر الجميع عن سبب كونها رائعة ولماذا سيكون من الأسهل العيش معها في المستقبل. ربما تمتلك بعض الشركات نوعًا من نظام الاختيار المحدد ، وهو جدول معقد مع مقارنات يجب ملؤه. ليس لدينا أي شيء من هذا القبيل ، يتم اتخاذ جميع القرارات على مستوى بعض الأحاسيس الذاتية للغاية ، ولكن في الوقت نفسه ، تظهر التقنيات الجيدة والمثيرة للاهتمام بسرعة كافية.
في بعض الأحيان هناك أشياء لم تصل بعد إلى الإصدار. بدأنا في استخدام المكتبة لإنشاء لوحات في React ، عندما كانت لا تزال خامًا بما فيه الكفاية ، وبقدر ما أتذكر ، تم التبرع بها قليلاً. بدأنا في استخدام Babel 7 مع نوع من بيتا لأنه سمح لنا ببناء المشروع بشكل أسرع قليلاً من المشروع السابق.
وربما لا أحد في الفريق اشتكى من أنه يريد شيئًا جديدًا رائعًا ، لكنهم قالوا له: "لا ، لدينا مثل هذه السياسة ، لن نقوم بذلك." وبينما لا يمكنني أن أتذكر مشكلة واحدة من شأنها أن تسبب مثل هذا النهج ، ترحب بالتقنيات الجديدة المثيرة للاهتمام. إنه أمر غريب للغاية بالنسبة لي ، لأنه في تجربتي السابقة ، اتخذت العديد من القرارات الخاطئة على هذا المستوى. ولكن في ManyChat ، ربما فقط بمساعدة المجتمع ، ربما لسبب آخر ، لم يكن لدينا هذه الملفات عندما اخترنا شيئًا ، ثم اضطررنا إلى إعادة كتابة نصف قاعدة الشفرة إلى تقنية أخرى وإعادة كتابتها ، لأن هذا لم يدخل.
- المزيد عن "نصيحة التقدم": أريد أن أفترض أن الشركة الناشئة تسمح لك بالتنفس بهدوء "ليس عليك التعامل مع رمز قديم". هل هذا صحيح؟- حسنًا ، يفهم الجميع كلمة "الإرث" بطريقتهم الخاصة. إذا كنا نعني بذلك ، على سبيل المثال ، رمز أقدم من ثلاث سنوات ، فعندئذٍ في شركة أقل من ثلاث سنوات ، بالطبع ، ليس كذلك. ولكن يمكنك تشديد هذا المفهوم ، ثم سيكون لدينا بعض النسبة المئوية من التعليمات البرمجية القديمة. من وجهة نظر أنه لم يكتب منذ ثلاث سنوات ، ولكن قبل بضعة أشهر فقط ، ولكن بعد ذلك لم نكن نعرف كيف نفعل شيئًا صحيحًا ، لكننا تعلمنا الآن ، يمكننا القيام بمئة سطر بدلاً من ألف ، وسوف يفعلون نفس الشيء أكثر موثوقية. هذه المدونة ، بالطبع ، لا مفر منها. ولكن لا يوجد شيء نحتاج إليه للبحث عن بعض "المطورين الملتحين" ، لأنهم يعرفون فقط لغة البرمجة هذه ، ولا يمكننا رفضها.
- ما مدى مساهمة تطوير الشركات الناشئة في "بناء الدراجات"؟ بينما تقوم الشركات العملاقة بكل شيء في الداخل ، أليس كذلك؟ أم أن الشركة الناشئة هي مجرد مكان حيث يقوم الجميع بعمله الخاص؟- بالنسبة لنا ، تأتي قيمة الأعمال أولاً. نحن بالفعل مربحون ، ولكن إذا تباطأنا وبدأنا بالخسارة لشخص ما ، فسيكون ذلك مؤلمًا للغاية. لذلك ، إذا كان تطوير الطرف الثالث متسقًا مع متطلبات العمل ، وحل مشاكل العمل ، ولم يكن لديه أي مشاكل كبيرة ، فيمكننا أخذها واستخدامها بأمان. - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. ManyChat React, Baobab. , React . view React, store Baobab. , , .
2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .
— , , , . -, «» ?— c , Flow, — Flow Builder. , :
, , 2D-. Flow Builder PixiJS — WebGL/Canvas.
. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .
, , -, - , - , , , . 2D-.
— «»? , , ?— , , , , , … , HTML, Canvas WebGL , . Pixi, .
: , Canvas, - WebGL. Pixi , , . , - . , issue,
GitHub , , , .
, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.
, . , Pixi - , , Flow Chart . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
