حافظ على الهدوء والانتقال إلى فريق تطوير جديد

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

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

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

تمرير الشعلة: إعداد فريق تطوير جديد

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

لكن ماذا لو لم تستبدل الفريق بأكمله؟ هل يجب أن تهتم بقراءة هذا؟

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

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

لذلك دون مزيد من اللغط ، دعنا نتعمق!

اجمع الوثائق

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

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

يجب أن يغطي التوثيق الجيد الموضوعات التالية على الأقل:

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

يجب كتابة الوثائق من قبل مطور لديه خبرة مباشرة في إعداد التطبيق والمساهمة في قاعدة التعليمات البرمجية.

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

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

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

افهم منتجك

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

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

• ما هي مجموعة التكنولوجيا التي يستخدمها تطبيقك؟ - هناك العديد من أطر عمل التطبيقات الشائعة للواجهة الخلفية والواجهة الأمامية ، وأي فريق تطوير جديد يجب أن يكون على دراية بتلك التي يستخدمها تطبيقك. بعض الأمثلة على تقنيات الويب الخلفية هي Ruby on Rails و Node.js و Django. بعض الأمثلة على تقنيات الويب الأمامية هي React.js و Angular.js و Ember.js.
• أين هو مستضاف؟ - لدى مضيفي الويب المختلفين عمليات نشر مختلفة ، والتي تتطلب مستويات مختلفة من الخبرة. في السنوات الأخيرة ، أنشأت التقنيات السحابية عددًا من خيارات الاستضافة الجديدة ، وستحتاج إلى تحديد الخيار الذي تستخدمه ووصف سبب اختياره على الخيارات الأخرى.
• ما هي عملية التطوير؟ - هل يستخدم فريقك أداة معينة لإدارة التحكم بالمصادر مثل Git؟ إذا كان الأمر كذلك ، فما هي العملية التي يتم من خلالها تطوير ميزة جديدة واختبارها واعتمادها ونشرها؟ يجب أن تكون العملية موحدة ، وموثقة بشكل صحيح ، ويسهل تكرارها من قبل الوافدين الجدد.
• ما هي خدمات الطرف الثالث التي يستخدمها تطبيقك؟ - بعض التطبيقات مبنية على خدمات الطرف الثالث مثل Shopify. يرجى أن تضع في اعتبارك أن الاعتماد على خدمات الجهات الخارجية يتزايد تدريجيًا ، وحتى إذا كنت لا تستخدم حاليًا أي خدمة إضافية ، فقد يقرر مشروعك استخدام خدمة تابعة لجهة خارجية في وقت لاحق.
• ما المنصات التي يمكن تشغيل تطبيقك عليها؟ - هل تطبيقك تطبيق سطح مكتب أم تطبيق ويب أم موقع ويب سريع الاستجابة أم تطبيق iOS أصلي أم تطبيق Android أصلي أم أي شيء آخر؟ هل يعمل على عدة منصات مختلفة؟ أي منصة هي أولويتك في أي وقت؟ ما هي منصة منتجك الأقوى والأضعف؟ تأكد من معرفة جميع تفاصيل الأنظمة الأساسية الحالية لتطبيقك ، وحتى الأنظمة الأساسية التي يمكن التوسع فيها.

ألحصول على الملكية

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

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

فيما يلي قائمة بالأدوات أو الخدمات الخارجية المختلفة التي قد يستخدمها تطبيقك:

• إدارة التحكم في المصدر - GitHub و Bitbucket و Gitlab
• استضافة الويب - Heroku و EngineYard و Digital Ocean و Bluehost و Amazon Web Services
• استضافة الملفات - Amazon Web Services (S3)
• مزود DNS - GoDaddy ، DNSimple ، Hover
• خدمات التطوير - NewRelic و FileStack و Segment و Bugsnag (وعدد لا يحصى من الخدمات الأخرى)
• خدمات الدفع - Stripe و Braintree و PayPal
• خدمات التدوين - WordPress ، Tumblr ، Ghost
• حلول التجارة الإلكترونية - Shopify ، Squarespace
• التحليلات / التتبع - Google Analytics ، Mixpanel ، Kissmetrics
• التسويق عبر البريد الإلكتروني: MailChimp، Constant Contact

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

وغني عن القول ، تأكد من أن كل عقد تطوير يحمي مصالحك من اليوم الأول ويضمن انتقالًا سلسًا ، بغض النظر عن السبب.

منح حق الوصول

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

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

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

إدارة Handoff

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

فريق وارد

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

الفريق المنتهية ولايته

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

خاتمة

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

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

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

لذلك دعونا نراجع النقاط الرئيسية التي يجب أن تسبق أي نقل ملكية لمنتج البرنامج الخاص بك:

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