يمكن مشاهدة النسخة الكاملة لمدة ساعتين على قناة Hexlet على YouTube .
جدول المحتويات:
المنتج وتاريخ الشركة
كيف يعمل تطوير المنتج
اختيار التكنولوجيا وتطورها
العمليات قيد التطوير
تاريخ الشركة والمنتج
ميرو هي منصة السبورة البيضاء التعاونية عبر الإنترنت للتعاون المرئي. الكلمة الأساسية هي التعاون ، التعاون ، على التوالي ، المقاييس الرئيسية التي نقيس بها فعاليتنا هي عدد لوحات التعاون والجلسات التعاونية التي تحدث في المنتج.
نحن نطلق على أنفسنا منصة لأننا تجاوزنا بالفعل مجرد منتج: لدينا واجهة برمجة تطبيقات مفتوحة ، وسوق ، ومكتب مطور ، لذا يمكن لأي شركة توسيع المنتج بنفسها.
جمهورنا المستهدف هو فرق المنتجات التي تعمل من نفس المكاتب أو من مكاتب مختلفة. في أغلب الأحيان ، يتم استخدام ميرو لإجراء ورش العمل ، والجلسات الاستراتيجية ، والعصف الذهني ، والممارسات الرشيقة (التخطيط ، والاستعراضات السابقة).
أنا أقود التطوير في ميرو. لقد نشأت في بيرم وما زلت أعيش هنا. تاريخياً ، ظهرت الشركة في بيرم ، حيث جاء مؤسسو الشركة. يوجد معظم قسم التطوير لدينا هنا ، وفي عام 2019 أطلقنا ونعمل بنشاط على تطوير مكتب هندسي ثانٍ في أمستردام.
عملت سابقًا في مجال التطوير المخصص ، بدءًا من بناء مستودعات بيانات تحليلية كمطور ، ثم تصميمها ، ثم قيادة مشاريع كبيرة. انضم إلى ميرو في عام 2016 عندما كانت الشركة توظف 30 شخصًا. منذ ذلك الحين ، حققنا نموًا كبيرًا: الآن لدينا خمسة مكاتب ، 400 شخص ، من بينهم 140 مهندسًا.
تأسست الشركة عام 2011. كانت وظيفتنا الأكبر ولا تزال تطوير المنتجات ، والتي تمثل اليوم حوالي نصف الشركة.
تغيير الاسم
فكرنا في تغيير علامتنا التجارية مرة أخرى في عام 2015 ، ولكن انتهى بنا الأمر في عام 2018. اسمنا السابق RealtimeBoard طويل ومعقد. غالبًا ما كان مخطئًا ، واختصر إلى RTB ، أو الأسوأ من ذلك كله ، تم نسيانه تمامًا. علاوة على ذلك ، فهو غير عاطفي ، ولا توجد قصة وراءه. أردنا أن نجعل الاسم الجديد قصيرًا وواسعًا ومتحدثًا ولا يُنسى.
نتيجة لذلك ، استلهمتنا أعمال الفنان جوان ميرو واخترنا اسمه الأخير كعنوان. استغرق البحث نفسه واختيار الاسم عدة أشهر ، وبعد ذلك لبضعة أشهر أخرى أطلقنا علامة تجارية جديدة. في أعقاب هذا المشروع ، هناك سلسلة من المقالات حول كيفية ترتيب العمل في المشروع ، ومقال منفصل حول مهمة فنية صغيرة ولكنها غير تافهة للترحيل السلس للمستخدمين المصرح لهم من المجال القديم إلى المجال الجديد.
اعتدنا نحن والمستخدمون بسرعة على الاسم الجديد. نحن ننمو بسرعة ، لذا فإن عدة ملايين من المستخدمين الجدد لا يعرفون حتى أنه تم استدعاءنا بشكل مختلف. كانت المكافأة الرائعة لإعادة تسمية العلامة التجارية هي الجوائز من جوائز التصميم الأوروبية للهوية ، والتي طورناها كجزء من إعادة التسمية مع الوكالة الأوروبية Vruchtvlees .
كيف يعمل تطوير المنتجات في ميرو
يقع فريق تطوير المنتجات بالكامل المكون من 170 شخصًا في بيرم وأمستردام: مهندسين ومنتجات ومصممي منتجات وأساتذة سكرم.
في وقت سابق ، كان من الصعب بالنسبة لي أن أتخيل أن العديد من الأشخاص يمكنهم العمل على منتج واحد. لكني أعلم اليوم أن هناك آلاف المهندسين يعملون على نفس المنتج في Uber و Slack و Atlassian. نستمر في النمو ونفهم أنه من الواضح أننا لسنا كافيين الآن ، والنقطة المستهدفة التالية في رأسي هي 300 شخص قيد التطوير ، وبعد ذلك سنواصل النمو أكثر. إنه ليس مجرد رقم من رأسك. لدينا تخطيط استراتيجي ، ونفهم أين نريد أن نكون في غضون عامين ، وخمس سنوات ، وما يتعين علينا القيام به من أجل ذلك.
من حيث الهيكل التنظيمي ، هناك نقابات: الواجهة الأمامية والخلفية وضمان الجودة وما إلى ذلك. للعمل في المشاريع ، يتم دمجهم في فرق متعددة الوظائف.
يتم توزيع الفرق في المجالات الرئيسية:
- المنتج الأفقي هو الوظيفة الرئيسية للمنتج التي يراها جميع المستخدمين: الملصقات والنصوص والأشكال والإطارات وما إلى ذلك.
- اتجاه الأنظمة - مسؤول عن النظام الأساسي والبنية التحتية الأساسية.
- يدور النمو حول زيادة عدد المستخدمين: التنشيط ، والمشاركة ، والعائد ، وتحقيق الدخل.
- Enterprise — , . -, Miro, . -, SaaS-, . , , .
- — 2019 . API, , marketplace, — , , .
- — , . , , , Miro, : Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.
: , , . , . , : - .
البرنامج الرئيسي للمهندسين: IntelliJ Idea ، Jira ، Slack ، Zoom ، Miro ، Confluence. يعمل معظم الموظفين على أجهزة MacBooks ، ويعمل معظم المهندسين على MacBook Pro ، وبالنسبة للبعض نشتري آلات أكثر قوة عند الحاجة.
نستخدم منتجنا الخاص كل يوم: اجتماعات داخلية وورش عمل وجلسات عصف ذهني وتخطيط.يسمح لك هذا باختبار جميع الابتكارات في المنتج بسرعة ويبسط بشكل كبير تكيف المطورين الجدد الذين يعملون مع المنتج منذ اليوم الأول ليس فقط من حيث الكود ، ولكن أيضًا كمستخدمين. هذا جزء مهم من ثقافتنا - نحن نصنع منتجًا يجب أن نكون مرتاحين وممتعين للاستخدام.
كومة ، متراصة
الجزء الأمامي هو نسخة مطبوعة وفاعلية و AngularJS. الواجهة الخلفية هي Java. قواعد البيانات - Redis ، Postgres ، للاتصالات العنقودية - Hazelcast و ActiveMQ. نستضيف في أمازون ، في نفس مركز البيانات. هناك حوالي 400 خادم قيد الإنتاج. يمكن أن تصل خوادم التطبيقات التي تعالج لوحات المستخدم إلى 100 ، ويتم تنظيم كل شيء تلقائيًا.
نحن نستخدم مكدسًا من Atlassian: Jira و Bitbucket و Bamboo ونصوصنا الخاصة التي تم تثبيتها على Bamboo وتسمح بنشر كل شيء على الخوادم. حتى الآن ، جميع الإصدارات عبارة عن إصدار أمامي كبير وإصدار خلفي كبير. الآن نحن نفكر في كيفية تحقيق المزيد من هذه الإصدارات.
تطبيقنا الرئيسي هو وحدة متراصة معيارية: هناك وحدة مسؤولة عن واجهة برمجة التطبيقات (API) واللوحة ووظيفة الخدمة. يتم نشر monolith في وحدات على الخوادم المطلوبة ، وليس في قطعة واحدة كبيرة لجميع الخوادم على التوالي ، أي لدينا أيضًا خوادم بأدوار مختلفة.
داخل التطبيق ، هناك العديد من عمليات الدمج والخدمات الإضافية التي قمنا بها على الفور بشكل منفصل والتي تصدرها الفرق بشكل منفصل عن بقية الأجزاء الأمامية والخلفية.
عندما يكون لديك شركة صغيرة ، يكون من الأسهل بكثير أن تبدأ بوحدة متراصة وليس تسييج البنية التحتية للخدمات. لكننا توصلنا الآن إلى أن نفهم أن وحدة متجانسة واحدة لا تمنحنا القدرة على قياس الاتجاهات الفردية (منتج أفقي ، ومنصة ، ومؤسسة ، وما إلى ذلك) ، لذلك نحن نطور نهجًا لترك كتلة واحدة.
إطلاق
يستغرق التجميع نفسه من 15 إلى 20 دقيقة ، بما في ذلك تنفيذ اختبارات الوحدة. يمكن أن تستغرق الاختبارات الشاملة ما يصل إلى 40 دقيقة. تستغرق العملية برمتها من ساعة ونصف إلى ساعتين لإطلاق سراح السيد. هذه فترة طويلة ، ولا يزال لدينا شيء نعمل عليه هنا.
ربما يكون من المثالي إطلاق سراحه كل خمس دقائق. لكن لهذا الغرض ، ليس لدينا فريق كبير ولا جمهور يومي كبير. الجمهور الكبير مهم للإصدارات المتكررة ، لأنه يسمح لك بالتأكد بسرعة من أن كل شيء على ما يرام عن طريق طرح التغييرات على نسبة صغيرة من المستخدمين.
اختيار التكنولوجيا وتطورها
أعتقد أنه يجب التعامل مع اختيار التكنولوجيا على النحو التالي: بغض النظر عما تختاره ، فلا يزال يتعين عليك تغييره يومًا ما ، خاصة إذا كانت الشركة والمنتج تنموان. لذلك ، فإن عملية تغيير التقنيات أمر طبيعي. التكنولوجيا مهمة ، لكنها تحتاج إلى التعامل معها بشكل مختلف في مراحل مختلفة من تطور الشركة.
الشركات الصغيرة التي بدأت للتو وتبحث عن منتج مناسب للسوق تعمل بسرعة ، وتبني أفضل اللاعبين المحترفين بسرعة ، وتتخلص منهم بسرعة. يعد العثور على سوق أكثر أهمية بالنسبة لهم ، بدلاً من إنشاء حلول تقنية معقدة. ولكن عندما يتم العثور على السوق ، تظهر الحلول التقنية في المقدمة ، لأنها تتيح لك إنشاء هامش أمان للنمو والأمن.
نحاول أولاً فهم المشكلة التي نريد حلها عن طريق تغيير التقنيات. ثم نقوم بالكثير من البحث ، واستكشاف البدائل ، واختبار الأداء. يتم ذلك مع أي حلول تقنية سنقوم بتنفيذها: "لا تأخذ أول شيء سمعته لأول مرة في السوق ، ولكن ابحث ودرس ما هو الأنسب لحل المشكلة".
في منتج كبير وفريق كبير ، يعد التغيير في التكنولوجيا قرارًا استراتيجيًا مهمًا ؛ يمكن أن يؤدي إلى توقف جزئي أو كامل في تطوير المنتج ، وتحويل الفرق إلى مهام جديدة ، وما إلى ذلك. إنها طويلة ومكلفة ، ولكن إذا لم يتم ذلك في الوقت المناسب ، فإن المشاكل التي ظهرت يمكن أن تجلب المزيد من الصعوبات.
لقد أجرينا بعض التحولات التقنية الكبيرة ، في الأمام والخلف. وهنا بعض الأمثلة.
فلاش → قماش
حتى عام 2015 ، كانت الواجهة بالكامل تعمل على Flash ، ثم بدأ Flash في الاختفاء وتحولنا إلى HTML و Canvas. كان لتغيير المكدس تأثير جيد على أداء المنتج وإمكانية استخدامه ، وأدى إلى زيادة ملحوظة في الجمهور. استغرق الانتقال حوالي عام ، وكان مشروعًا كبيرًا ومعقدًا. مقال عن تفاصيل هذا المشروع .
نحن ندرس حاليًا الانتقال إلى WebGL ، ولكن لا يوجد دليل واضح حتى الآن على أن الأمر يستحق ذلك.
الزاوي → رد فعل
على مدار العامين الماضيين ، انتقلنا تدريجياً من Angular JS إلى React. الأسباب الأساسية:
- تسمح React بكتابة أفضل ، وتسمح لاحقًا بإعادة هيكلة الكود بشكل أفضل وتضمن عدم سقوط أي شيء.
- React . «» , Angular . Angular, React, .
- React , Angular JS .
في عام 2015 ، انتقلنا من خوادم Hetzner المؤجرة إلى استضافة أمازون. منذ أكثر من عام ، كان هناك مشروع لترحيل قاعدة البيانات الرئيسية من Redis إلى PostgreSQL. لدينا مقالات حول هذا: إدارة مشروع ترحيل البيانات ، وإنشاء كتلة تجاوز الفشل .
إن حالتنا معقدة بسبب حقيقة أنه من القيمة الأساسية للتخزين ، ننتقل إلى قاعدة بيانات SQL. هناك الكثير من إعادة البناء. من المهم أن تفعل كل شيء حتى لا يتوقف التطبيق. يشبه تغيير عجلة السيارة المتحركة ، لأن قاعدة البيانات هي الأساس الذي يقوم عليه التطبيق. بالنسبة لمحتوى اللوحات ، فعلنا كل شيء في الواقع بدون صيانة. نعم ، تم تأخير عملية النقل ، لكن المستخدمين لم يلاحظوا أي شيء ، فقد نجح المنتج.
استقرار المنتج هو التركيز الرئيسي. يقوم المستخدمون بتخزين الكثير من المحتوى في ميرو. وفقًا لذلك ، إذا قام المستخدم بجدولة جلسة أو اجتماع ، وقام بإعداد لوحة محتوى له ، ولم يكن المنتج متاحًا في هذه اللحظة ، فهذا يعد إخفاقًا ، ولا يمكن استخدام المحتوى. بينما يمكن استبدال التكبير المشروط بسرعة بـ Hangouts ، لا يمكن استبدال المحتوى بسرعة. لذلك ، تتمثل إحدى مهامنا الرئيسية في ضمان إتاحة المحتوى للمستخدمين دائمًا.
جافا
تساعدنا Java بشكل كبير من حيث الإنتاجية وموارد المطور التي يمكننا العثور عليها. أعلم أن Booking تتحول من Pearl إلى Java لأنهم سئموا من إعادة تدريب مهندسيهم.
يأتي المهندسون من C ++ و .Net إلينا ويتكيفون بشكل طبيعي. إذا كنت مطورًا متمرسًا ، وقد جربت تقنيات مختلفة وتعرف كيفية بناء النظام ، فليس من الصعب الغوص في لغة جديدة. الشيء الرئيسي هو أن المهندس يأتي بالحلول الصحيحة ، وسيكون بالتأكيد قادرًا على دفن نفسه باللغة ، وأنا أؤمن بهذا.
تطور الاختبار
في البداية ، كان لدينا اختبار يدوي فقط. تم طرح الإصدارات كل أسبوعين إلى ثلاثة أسابيع ، واستغرق التحضير للإصدار أسبوعًا: يمكنك إجراء اختبار الانحدار في غضون أيام قليلة ← العثور على الأخطاء الحرجة ← التصحيح ← الاختبار اليدوي مرة أخرى. عندما كان هناك عدة فرق ، نجحت ، ولكن مع عشرين فريقًا ، من المستحيل اختبار كل شيء يدويًا.
لذلك بدأنا التفكير في الأتمتة. بادئ ذي بدء ، كتبنا اختبارات تلقائية للتخلص تمامًا من اختبار الانحدار. نحن نعمل الآن على إعداد عمليات إدارة الجودة الصحيحة طوال دورة التطوير بأكملها. وكلما أسرعنا في التفكير في الجودة ، كلما وجدنا في وقت مبكر حالات متطورة ، وفهمنا كيفية اختبارها - سيؤدي ذلك في النهاية إلى تقليل التكلفة وتسريع عملية التطوير. الخطأ الذي تجده معروض للبيع لا يستحق الوقت والموارد فقط للتراجع عن الإصدار وإصلاحه. يؤثر الخطأ على تجربة المستخدم الإجمالية للمنتج ، وهو مكلف للغاية لإصلاح هذه التجربة.
لدينا نقابة ضمان الجودة ، حيث يتخذ المهندسون قرارات بشأن العمليات التي نحتاج إلى تنفيذها الآن ، وتطوير إستراتيجية الجودة ، ثم يساعد كل مهندس ضمان الجودة فرقه على تنفيذ هذه العمليات بأنفسهم:
- QA- -, . QA , . .
- QA , .
- QA , , .
إصدارات Canary هي أيضًا طريقة للاختبار ، عندما نطرح ميزة لجمهور صغير ونتحقق مما إذا فاتنا شيئًا ما. نطلق ميزات جديدة كبيرة من خلال مربعات الاختيار ، ونطرحها لمستخدمي الإصدار التجريبي الذين أعربوا عن رغبتهم في المشاركة في الاختبار التجريبي (سيتعرف مديرو منتجاتنا على هذا الأمر أثناء المقابلات البحثية). يشتمل عدد مستخدمي الإصدار بيتا وألفا بالضرورة على فرقنا ، ونحن نطرح جميع الوظائف الجديدة تمامًا لأنفسنا في المقام الأول.
وصف مفصل لجميع مراحل عملية ضمان الجودة لدينا .
نمو الأحمال وإعادة بناء ديون
نظرًا للتحول الهائل إلى العمل عن بُعد في عام 2020 ، فقد ارتفعت قاعدة المستخدمين لدينا ، ونفدت بنيتنا التحتية السنوية ومرونة التطبيقات في غضون أسابيع قليلة. في الأسبوع الأول من الزيادة الحادة في الحمل ، أوقفنا تطوير جميع المنتجات وأعدنا توجيه الفرق للعمل على تحمل الأخطاء والأداء.
كان هامش الأمان مطلوبًا ليس فقط على الواجهة الخلفية ، ولكن أيضًا على الواجهة الأمامية والعميل ، حيث زاد عدد الوظائف المتزامنة في المنتج. إذا كان بإمكان 20 شخصًا في وقت سابق العمل على لوحة واحدة في نفس الوقت ، أصبح الآن 300 شخصًا. لقد فعل مهندسو الواجهة الأمامية الكثير ولا يزالون يتعاملون مع أداء الحمل. على سبيل المثال ، نجعل لوحة القيادة مع قائمة اللوحات يتم تحميلها بشكل منفصل عن أي شيء آخر ونقوم بذلك بشكل أسرع من ذي قبل. وإذا ذهب المستخدم مباشرة إلى اللوحة ، وليس من خلال لوحة القيادة ، فيجب تحميل كود ومحتوى اللوحة ، دون أي شيء آخر.
سنقوم بإعادة البناء كثيرًا حتى يحصل المستخدم على ردود الفعل والمحتوى من اللوحة بشكل أسرع ، وبعد ذلك يتم تشغيل جميع الوظائف الرئيسية - البرامج النصية ، والواجهة - ببطء. للقيام بذلك ، انتقلنا إلى تقسيم الكود إلى وحدات "كسول". بفضل هذا ، تسارعنا بنحو الثلث ، وفي الشهر المقبل نخطط لتسريع التحميل مرتين أكثر.
الأمر نفسه من حيث الأداء على السبورة - هناك حرب تدور حول سرعة وموارد الكمبيوتر الذي يعمل عليه المستخدم.لم يدخل الجميع على الإنترنت بآلات جيدة ؛ قام شخص ما بسحب جهاز كمبيوتر محمول منزلي قديم منخفض الأداء من الرف. لكن يجب أن يعمل منتجنا جيدًا على أي كمبيوتر محمول. هذه خدعة كبيرة أخرى نعمل عليها كثيرًا في الوقت الحالي.
العمليات قيد التطوير
الحل التقني ومراجعة الكود
تبدأ أي مهمة بإعداد حل المنتج. حل المنتج هو إجابة على السؤال "ماذا سنفعل؟". يقوم مدير المنتج استنادًا إلى استراتيجية المنتج و OKRs بإجراء الكثير من الأبحاث لمعرفة ما يفتقده المستخدمون في منتجنا في الوقت الحالي. بناءً على البحث ، يصف المنتج الحل. تناقش نقابة الطعام الحل وتراجعه إذا لزم الأمر.
على أساس حل المنتج ، يتم تشكيل حل تقني يجيب على السؤال "كيف سنفعل هذا؟" تم تطويره من قبل مهندسي الفريق الذي سيقوم بتنفيذ الوظيفة. يمر الحل التقني بعدة عمليات مراجعة:
- مع فرق بها تقاطعات في الوظائف ؛
- المراجعة الأمنية للمكونات التي سنتطرق إليها في الهيكل ؛
- كيف سننشر النتيجة.
بعد ذلك ، يبدأ التطوير نفسه. من المهم ألا تؤدي مراجعة الكود إلى إبطاء التطوير ، لذا مؤخرًا ، بدلاً من الاضطرار إلى تلقي مراجعتين للتعليمات البرمجية ، قدمنا المسؤولية الشخصية على مستوى المكون. الآن ، على مستوى الكود ، نعرف دائمًا من المسؤول عن هذه القطعة ، مما يسهل الاتصال بشكل كبير أثناء التطوير. وفقًا لذلك ، بمجرد إجراء التغييرات على الرمز ، يتم تعيين المراجع تلقائيًا ، مالك هذا الرمز. إذا كان الرمز ملكًا لك ، فسيتم إجراء المراجعة بواسطة أحد أعضاء فريقك.
لماذا قدمنا المسؤولية الشخصية؟ كان هناك عدد قليل من الأشخاص "القدامى" الذين يعرفون كيفية عمل المنتج بأكمله ويمكنهم التحقق من أي جزء من التعليمات البرمجية. ولكن مع نمو المنتج ، بدأت قدرات هؤلاء الأشخاص مفقودة ، ولم يعد بإمكانهم معرفة كل ما كان يحدث في التطوير.بدأت عملية مراجعة الكود في إبطاء بقية العملية ، ولم يكن من الواضح من الذي يجب الذهاب إليه لمراجعة الكود. ثم بدأنا في نقل جميع الكفاءات اللازمة لمجموعات منتجات معينة إلى الفريق الذي يعمل عليها. لذلك كانت الفرق قادرة على إجراء مراجعات الكود من تلقاء نفسها. في وقت من الأوقات ، ساعدنا هذا في الإسراع كثيرًا.
مراجعة الأداء
حصلت الشركة على درجات ، وبفضلها نفهم من لديه الكفاءات ، والدرجة التي تتوافق معها ، والأهم من ذلك ، ما يجب على الجميع القيام به للمضي قدمًا. تتم مراجعة الأداء مرتين في السنة ، وتساعد في التقاط صورة لمكان وجود كل شخص الآن ، وتلقي ملاحظات شخصية.
بناءً على هذه الصورة ، يشكل قائد الفريق خطط تطوير شخصية مع كل عضو في الفريق: يقول الموظف نفسه أين يريد تطويره ، ويبرز استعراض الأداء نقاط قوته وثغراته.
بعد ذلك ، وبشكل منتظم ، مرة كل أسبوع إلى أسبوعين ، يعقد قائد الفريق مع الموظف اجتماعات 1: 1 ، حيث ، من بين أمور أخرى ، يناقشون ويتتبعون الحركة في الاتجاه المخطط. بعد عام ونصف ، بناءً على نتائج هذه الحركة ، هناك زيادة في الرتبة والراتب.
كل شيء هو نفسه تمامًا مع قادة الفريق ، بالإضافة إلى وجود تدريب خارجي وتوجيه خارجي لهم.
لسوء الحظ ، غالبًا لا ينمو الأشخاص بنفس سرعة نمو الشركة - لا بأس بذلك. نحن مستعدون لاستثمار الكثير في التدريب ، لأن نمو الشركة يعتمد بشكل مباشر على نمو الموظفين. لدينا تعويض عن الدورات الخارجية ، وقد أوصينا بالدورات والموجهين. نحن نعوض عن التدريب الإجباري بنسبة 100٪ (على سبيل المثال ، اللغة الإنجليزية) ، نحاول تعويض الباقي من 50 إلى 50 ، بحيث تكون هناك مسؤولية متبادلة عن النتائج.
نادرا ما نذهب إلى المؤتمرات. نحاول اختيار أولئك الذين يتحدثون عن التقنيات والحالات ذات الصلة بنا في الوقت الحالي والتي لا نملك المعرفة الكافية بشأنها.
كيف يعمل مهندسو التوظيف
سلسلة التوظيف لدينا هي المعيار لروسيا وأوروبا. في روسيا ، مسار التوظيف ضيق بالفعل ، لذا لا يمكن إجراء المقابلة الأولى بواسطة المجند ، ولكن على الفور بواسطة مدير التوظيف (عادةً ما يكون قائد الفريق للفريق الذي نوظف فيه شخصًا) بعد أن يقوم المجند بمعالجة السيرة الذاتية واستبعاد الوظائف الشاغرة التي لا تتناسب مع المتطلبات.
لدي شعور بأن المهندسين في روسيا يبحثون بنشاط عن عمل ، مقارنة بأوروبا ، لأنهم لا يريدون المجازفة. وعندما دخلت العديد من الشركات منطقة المخاطر بسبب العزلة ، أصبح الناس أقل ميلًا إلى المخاطرة وتغيير الوظائف.
في كلتا الحالتين ، تبدأ سلسلة التوظيف بمقابلة عبر الهاتف مع مرشح ، والتي يتم إجراؤها من قبل مسؤول التوظيف أو مدير التوظيف. الغرض من الفحص هو فهم سريع لكيفية ملاءمة المرشح للمتطلبات الرئيسية للوظيفة الشاغرة.
بعد الفحص ، مهمة اختبار ، ثم مقابلة فنية ، والتي تشمل ، من بين أمور أخرى ، مناقشة مهمة الاختبار. ثم - لقاء مع الفريق الذي سيعمل فيه المرشح. بالنسبة لنا ، هذه خطوة إلزامية ، لأنها تساعد أولاً وقبل كل شيء على فهم الثقافة الملائمة للمرشح ، وليس مهاراته الفنية.
بعد كل المقابلات ، نقوم بجمع التعليقات من المشاركين ، وتقديم عرض.
لتقييم مهام الاختبار ، نستخدم نظام النقاط ، ثم نصنف النتائج ونرى أفضل النتائج. في المناصب العليا ، نقوم أحيانًا بإلغاء مهمة اختبار إذا كان لدى المرشح مستودع عام جيد.
مناصب صغيرة
قبل الانتقال إلى العمل عن بُعد ، بدأنا العمل مع متخصصين مبتدئين: لقد وظفنا Juns ، خريجين ، ولكن ليس بنشاط كبير. الآن قمنا بتجميد هذه القصة تمامًا ، لأنه من الصعب جدًا ضمهم في مكان بعيد ، ولدينا خبرة قليلة جدًا في هذا الأمر حتى الآن. لذلك ، نحن نركز على الوسطاء الذين لديهم خبرة لا تقل عن 3-4 سنوات.
ولكن حتى عندما عملنا مع Juns ، كان من المهم بالنسبة لنا أن يتمكنوا من النمو إلى المستوى المتوسط في غضون عام ، حتى يتعلموا ويتكيفوا بسرعة كبيرة.
متطلبات توظيف عالية
هناك أسطورة أنه من الصعب جدًا علينا الحصول على وظيفة بسبب المتطلبات العالية جدًا. هذا ليس صحيحا تماما
غالبًا ما يأتي المرشحون الذين يشغلون منصب قائد الفريق إلينا لإجراء المقابلات ، والذين يكونون في الوسط وفقًا لمعاييرنا الداخلية. هذا لأنهم ، سعياً وراء الوظائف ، يأتون إلى شركات مستعدة لمنح وظائف أعلى من كفاءاتهم الحالية من خلال عدة خطوات ، فقط لتوظيف شخص. نتيجة لذلك ، تكون النتيجة ضررًا: فالشخص لم يضخ بعد إلى المستوى المطلوب ، لكنه يشغل بالفعل منصبًا مرتفعًا ؛ عندها سيكون بالكاد قادرًا على ترك الشركة ، لأنه لن يتم تعيينه لنفس المنصب في شركات أخرى.
أكبر مانع في التوظيف هو اللغة الإنجليزية. في السابق ، كان بإمكاننا التوظيف دون معرفة اللغة الإنجليزية ، ولكن هذا مستحيل الآن ، ومن المستحيل ضخه في غضون بضعة أشهر: سيحتاج مهندس من الأسابيع الأولى من العمل إلى قراءة الوثائق باللغة الإنجليزية ، والتوافق باللغة الإنجليزية مع الزملاء ، وحضور الاجتماعات العامة ، والتي تُعقد معظمها باللغة الإنجليزية لغة.
المنتج ينمو ، تظهر مهام جديدة مثيرة للاهتمام ، لذلك لدينا دائمًا الكثير من الوظائف المفتوحة في الهندسة في كل من بيرم وأمستردام.