اسمي فلاديمير. أنا مسؤول عن تطوير الأجهزة المحمولة في Vivid Money.
Vivid Money هي شركة ناشئة في مجال التكنولوجيا المالية في السوق الأوروبية مع مجموعة واسعة من الوظائف - المدفوعات والتحويلات والعملات المتعددة والتحليلات المالية ومشاركة الحسابات والاستثمارات وغير ذلك الكثير. أقرب المنافسين هم Revolut و N26.
تمكنا من إنشاء تطبيق للتكنولوجيا المالية للأجهزة المحمولة وإطلاقه بنجاح في غضون عام. خلال هذا العام ، قمت بجمع الأفكار التي كانت تتشكل في رأسي لمدة 4 سنوات تقريبًا ، بينما كنت رائدة في مشاريع أخرى. في هذه المقالة ، يتم جمع هذه الأفكار في شكل نصائح لمديري / عملاء هندسة البرمجيات الذين يبدأون مشاريع طويلة الأجل وواسعة النطاق من البداية.
المقدمة
منذ أكثر من عام بقليل ، جئت إلى المشروع كرئيسة لفريق Android. لقد واجهت مهمة طموحة ومثيرة للاهتمام - اختيار التقنيات ، وتكوين فريق ، وإعداد العمليات ، والأهم من ذلك ، القيام بكل ذلك بشكل جيد. الجيد هو مفهوم فضفاض ، لكنه بالنسبة لي منتج عالي الجودة من وجهة نظر تقنية ومنتج.
بدء مشروع من الصفر مهمة مثيرة للاهتمام ومثيرة بقدر ما هي صعبة وغير مفهومة. في البداية ، لا تعرف ما الذي يجب عليك الإمساك به ، ثم هناك الكثير من الأشياء التي يمكنك القيام بها بحيث تكون عملية العمل بأكملها مثل إطفاء الحرائق.
لمنع حدوث ذلك ، من الضروري أولاً وقبل كل شيء تحديد أولويات الأنشطة بوضوح .
في رأيي ، يمكن ترتيب الأنشطة الرئيسية للعميل بالترتيب التالي:
- بناء عملية التوظيف ؛
- اختيار مجموعة التكنولوجيا ؛
- تكوين تفاعل الفريق ؛
- بناء عملية التطوير والاختبار.
في هذا الجزء من المقال ، سأركز فقط على النقطة الأولى.
تنويه:
تحتوي هذه المقالة على بلدي الأفكار والاستنتاجات على أساس بلدي خبرة في العمل في مشاريع كبيرة وطويلة الأجل. قد تبدو بعض النصائح مبتذلة ، ولكن كما أظهرت الممارسة ، لا يتم تطبيق جميعها حتى في الشركات والمشاريع الكبيرة.
استئجار مبنى
بالنسبة لي ، هذه النقطة هي في المقام الأول ، لأن العمل الإضافي للفريق يعتمد على "جودة" الأشخاص.
كان لدينا إطار زمني طموح للغاية لإطلاق البنك - سنة واحدة. خلال هذا الوقت ، كان من الضروري إنشاء قدر كبير من الوظائف نوعيًا. ببساطة لم يكن هناك وقت للموظفين المعالين ذوي التدريب السيئ. ومن هنا تأتي النصيحة التالية:
المجلس رقم 1. تذكر أهمية التوظيف
بالإضافة إلى حقيقة أن المطور الضعيف يؤثر بشكل مباشر على جودة الكود وعدد الأخطاء في المنتج ، فمن المستحيل التفويض إليه ، حيث لن تكون هناك ثقة كاملة وستكون هناك حاجة إلى مراقبة مستمرة. لذلك ، سوف تنشأ صعوبات في مشروع سريع النمو.
المجلس رقم 2. تحقق ليس فقط من المهارات الصعبة في المقابلة ، ولكن أيضًا المهارات الشخصية
في كثير من الأحيان ، تتعلق مقابلة المطور في روسيا بأسئلة اللغة / الإطار. في الواقع ، تلعب المهارات الشخصية دورًا مهمًا بنفس القدر ، ويصعب تطويرها. بالإضافة إلى ذلك ، من المرجح أن يكون الشخص الذي لديه عقلية مماثلة جزءًا من الفريق.
لقد حددنا المهارات الشخصية التالية لأنفسنا:
- التفكير المنهجي
- الأناقة والكمال الصحي ؛
- الاعتماد على الخبرة وليس النصيحة ؛ التشكيك في حقائق لم يتم التحقق منها.
وبالطبع ، أساسيات عدم الصراع والقدرة على التواصل مع الناس.
على سبيل المثال ، نسأل أحد المرشحين سؤالاً: "لماذا تترك وظيفتك القديمة وما هي معاييرك لاختيار وظيفة جديدة؟". الإجابة في حد ذاتها ليست مهمة لأن النهج المنهجي مهم - نتوقع أن يكون المرشح مدركًا أنه غير راضٍ ، وأنه كان قادرًا على الوصول إلى هذا بطريقة منطقية ووضع كل شيء على الرفوف في رأسه.
قد تكون أمثلة مثل هذه الأسئلة التي تساعدنا على فهم عقلية ومبادئ المرشح: "كيف يبدو فريقك المثالي؟" أو "كيف تبدو عملية التطوير المثالية؟"
المجلس رقم 3. حسّن مقابلتك
يجب أن يُنظر إلى المقابلة على أنها آلية يمكن تحسينها وتحسينها. أو كبرنامج يمكن إعادة بنائه.
سأقدم أمثلة على التحسينات التي قمنا بها.
مثال 1
- يستغرق مطورو البرامج حوالي 1.5 ساعة لإجراء مقابلة مع كل مرشح. لتحسين هذه المرة وعدم إهدارها على المرشحين الضعفاء بشكل واضح ، قدمنا الفحص. الفحص عبارة عن عدد قليل من الأسئلة البسيطة والمغلقة التي أعدت إجابات. يطرح مسؤولو التوظيف هذه الأسئلة على المرشح ، والتي تستغرق حوالي 10-15 دقيقة.
أرقام قليلة:
من بين 100 مرشح بعد الفرز ، يتم استبعاد حوالي الثلث ، أي حوالي 30. ويقضي المجند حوالي 15 دقيقة في كل فحص ، أي ما يقرب من 8 ساعات من صافي الوقت لـ 30 مرشحًا تم استبعادهم. في مقابلة كلاسيكية مع نفس الثلاثين مرشحًا ، كنا سنقضي حوالي 60 ساعة عمل في السيناريو الأكثر تفاؤلاً.
مثال 2
الغرض من المقابلة هو اختيار المرشح الأكثر صلة. قمنا بتحليل وتحديد المهارات والمهارات الحاسمة للمشروع ، مع الأخذ في الاعتبار مجموعة التقنيات المختارة ، والتي سمحت لنا بإزالة بعض الأسئلة غير ذات الصلة وتقليل وقت المقابلة.
على سبيل المثال ، قمنا بإزالة الأسئلة المتعلقة بأجزاء من Android SDK التي لم يتم استخدامها في مشروعنا - ContentProvider ، JobScheduler ، إلخ. نادرًا ما يتم استخدام حزم SDK.
مثال 3 في
البداية ، أجريت المقابلة الفنية على مرحلتين منفصلتين - أسئلة نظرية ومهام عملية. زاد هذا بشكل كبير من الوقت اللازم لاجتياز جميع مراحل المقابلة للمرشح ، وفقد العديد من المتقدمين ، نظرًا لأن سوق تكنولوجيا المعلومات هو سوق تنافسي للغاية - يتم تقديم عروض للمطورين الجيدين بسرعة.
لتحسين مسار التحويل ، قمنا بتقسيم المقابلة إلى المرحلة 1 - إزالة الأسئلة غير المفيدة وحل المشكلات الخوارزمية. لقد كتبت عن أسئلة غير إعلامية في الفقرة السابقة. لكننا استبدلنا المهام الخوارزمية بمهام عملية للإطار. كما أنهم يختبرون مهاراتك في الترميز ومعرفة SDK.
نتيجة لذلك ، كانت هناك مقابلة فنية واحدة فقط لمدة 1.5 ساعة ، لكنها أصبحت مصقولة قدر الإمكان في المحتوى.
المجلس رقم 4. "الفهم أهم من المعرفة"
كان المعيار الأكثر أهمية لاختيار المطور هو "الفهم". بحيث لا يعرف الشخص فقط كيفية تقديم التعريفات والمعرفة الأكاديمية ، بل يوضح فهمًا لهيكل إطار عمل معين. المطور بدون هذا الفهم ، الذي يواجه مشاكل ، لن يتمكن من إيجاد حل بمفرده أو لن يحل المشكلة بالشكل الأمثل. لذلك ، جعلنا جميع أسئلة المقابلة مفتوحة بحيث لا يعطي المرشح المصطلحات المكتسبة ، بل يناقش موضوعًا معينًا. ونتابع معرفته بالموضوع ومسار منطقه.
على سبيل المثال ، نطرح سؤالاً مفتوحًا: "كيف تصنع كاشف ANR (تطبيق لا يستجيب) في Android؟". يختبر هذا السؤال معرفة كيفية عمل سلاسل العمليات في Android ، ولكنه يتجنب السؤال المباشر حول Looper و Handler. كما يسمح لك بالتبديل بإيجاز إلى موضوع مع تعدد مؤشرات الترابط.
المجلس رقم 5. توزيع وظيفة المقابلات
مع النمو السريع للفريق ، أصبحت المقابلات كثيرة جدًا بحيث تستغرق يومًا كاملاً ، ولا يتبقى وقت للأنشطة الأخرى. لذلك ، من المفيد تفويض وظيفة المقابلة جزئيًا إلى الفريق.
هذا لا يزيل العبء عن زمام المبادرة فحسب ، بل يشمل أيضًا المطور في اختيار زميله المحتمل ، مما يحفزه أيضًا.
بالإضافة إلى ذلك ، يتعرف المرشح على الفريق ويخلق انطباعًا أكثر شمولية لنفسه.
المجلس رقم 6. وازن الفريق
عند التوظيف ، يجب أن تتذكر دائمًا التوازن بين الأشخاص من حيث الكفاءات في الفريق. يمكن أن يقودهم عدد كبير جدًا من كبار المطورين إلى ابتكار حلول جديدة ، لكن المطورين لن يصنعوا ميزات. لكن في بداية المشروع ، عندما يتم إرساء القاعدة الفنية لسنوات قادمة ، يكون ذلك ضروريًا. علاوة على ذلك ، من أجل كتابة الكود المعتاد للسمات ، فإن الإشارة ستكون باهظة الثمن بشكل غير معقول. الكثير من المبتدئين ، بدورهم ، سيؤثرون على قاعدة الكود ، ونتيجة لذلك ، سيغرقون المشروع على المدى الطويل. ومع ذلك ، فإن المبتدئين الأذكياء ينمون بسرعة إلى وسطاء ويصبحون أكثر ولاءً للشركة والفريق من الوسطاء من السوق. في رأيي ، يختلف هذا الرصيد لكل مشروع وحالة محددة ، لذلك لن أعطي نسبًا معينة.
في كثير من الأحيان ، يتم تخفيف الفرق مع المقاولين لتسريع التطوير. التوازن مهم أيضًا هنا ، نظرًا لأن عددًا كبيرًا من المقاولين يمكن أن يقلل أيضًا من الكود في المشروع. نادرًا ما يكون لدى المقاولين نفس الدافع والاهتمام بالمشروع مثل الموظفين الداخليين.
المجلس رقم 7. لا تخف من إطلاق النار
أخيرًا ، لا داعي للخوف من طرد الأشخاص من الفريق. الشخص الذي لا يتناسب مع الفريق من حيث المبادئ والروح أو في المهارات الفنية سوف يلحق ضررًا أكبر على المدى الطويل من فائدة الترميز قصير المدى.
يبدو من السهل إطلاق النار ، ولكن كيف يتم ذلك بدون ألم قدر الإمكان للموظف والفريق؟ يعمل المبدأ هنا: "لا يهم ما تفعله ، ولكن مدى أهميته ". إذا فعلت كل شيء مقدمًا - ناقش التوقعات من الوظيفة ، وقدم ملاحظات حول العمل في الوقت المحدد ، دون انتظار نهاية فترة الاختبار ، وقدم أسبابًا لتعليقاتك - لن يكون هذا مفاجئًا للموظف.
من المهم أيضًا السماح للفريق علنًا بفهم السببتم فصل الموظف. خلاف ذلك ، يمكنك زرع الخوف في الفريق وإفساد جو الفريق.
المجلس رقم 8. اجمع ردود الفعل من الموظفين الجدد
تتكون عملية التوظيف من مرحلتين - مقابلة وإعداد مبتدئ.
يجب أن يكون الإعداد مفيدًا ليس فقط للمبتدئين ، ولكن أيضًا للمشروع.
بعد الانغماس في المشروع ، يمكن للأشخاص الجدد رؤية مناطق المشكلات بمظهر مفتوح وتقديم أفكار جديدة. لذلك ، قمنا بتطوير قاعدة - للاستماع بوعي وتحليل آراءهم وتوصياتهم لتحسين الأساليب وقاعدة الكود. تم تنفيذ بعض هذه التوصيات بنجاح في المشروع.
على سبيل المثال ، بعد وصول أحد أعضاء فريق Android ، قمنا بمراجعة طريقة تخزين البيانات في ذاكرة التخزين المؤقت في الذاكرة بالكامل.
النتيجة
في الختام ، أود أن أقول إن فريقنا المتنقل قد نما إلى 26 شخصًا خلال عام ونصف تقريبًا. يقوم جميع المطورين بعمل جيد ، ولم يترك أحد الفريق بمحض إرادته. لقد أصدرنا المنتج بنجاح واجتازنا اختبار العمل عن بعد دون خسارة في الجودة وسرعة التطوير.
آمل أن تكون النصائح التي تم جمعها في هذه المقالة مفيدة لك أيضًا.
في الأجزاء التالية ، سأتحدث عن مناهجنا لاختيار مجموعة تكنولوجية وإعداد تفاعل الفريق.