عيد الهالوين هو الوقت للحديث عن المخاوف. أنا أعمل كمدير منتج في شركة تكنولوجيا معلومات ، لذا سيكون هذا عن كوابيس المطورين. ولكن ليس عاديًا ، ولكن تلك التي تظهر خلال أوقات التغيير.
عندما تتطور الشركة ، فإنها تغير نهجها في التنمية ، وتخلق منتجات جديدة وتوسع من قدرات المنتجات الحالية ، وتقبل الموظفين بعشرات ، والذين يواجهون بالطريقة القديمة قد يجدون صعوبة في إعادة البناء. نحن نفرح بالتغييرات ، ولكن في بعض الأحيان ، لماذا نختبئ ، نحن خائفون منها. لقد عملت كمدير منتجات لمدة عام ، وخلال هذا الوقت واجهت خمسة مخاوف رئيسية من فريقي. اليوم سأتحدث عن هذه المخاوف وكيف تمكنا من التغلب عليها.
1. الخوف من إسقاط كل شيء
الاختبار طريقة أكيدة لإطلاق منتج بدون أخطاء. ولكن في بعض الأحيان لا توجد معدات للتحقق من الرمز.
نصنع
DCImanager ، وهي لوحة لإدارة الخوادم ومراكز البيانات ، وغالبًا ما يكون من المستحيل تهيئة الظروف التي ستعمل فيها الشفرة في بيئة افتراضية. على سبيل المثال ، نضيف دعمًا للمفتاح الجديد أو جهاز التوجيه أو طراز PDU إلى لوحة التحكم ، ولكن لا توجد مثل هذه المعدات على منصة الاختبار.
في بعض الحالات ، يمكن تجاهل الاختبار ، ولكن ليس اختبارنا. الخطأ باهظ الثمن. لا تقوم بتهيئة متغير واحد فقط ، وفي نصف الحالات سيتوقف تثبيت نظام التشغيل. أنت مخطئ في سطرين من التعليمات البرمجية - وسوف "يستلقي" مركز البيانات. كما تعلم ، لا أحد يريد أن يكون مسؤولاً عن مركز البيانات "المنهار" ، لذا فإن هذا الخوف يأتي أولاً في فريقي (على الرغم من أنه لا يرتبط بالتحولات في الشركة).
كيف تتغلب على الخوف من إسقاط كل شيء- يقوم جميع مطوري الفريق بمراجعة التعليمات البرمجية لكل ميزة.
- نحتفظ بقوائم الأشياء التي بدونها لا يمكن تحرير المهمة.
- بعد إصدار التطوير ، نحلل أننا لم نأخذها بعين الاعتبار. نحن نصف بالتفصيل ما تم القيام به وما السلوك الذي تم ملاحظته بحيث يمكنك في أي لحظة العودة إلى المهمة واستعادة كل شيء في الذاكرة.
- تحديث قاعدة المعرفة باستمرار. نحن نكرس الوقت للتوثيق للمطورين ، وتبادل المعرفة فيما بيننا على هؤلاء. التدريب والوقوف.
- وأخيرا وليس آخرا. نقوم باختبار التطورات المخصصة للعملاء معهم على المعدات المقدمة.
بمجرد إضافة التحكم في تجميع المنافذ للمفاتيح الموجودة. في حالة حدوث خطأ ، سيتم إيقاف تشغيل معدات الشبكة في مركز البيانات تمامًا. وصل العميل إلى مركز البيانات الخاص به في الساعة الثالثة صباحًا وسيطر على الموقف بحيث ، في هذه الحالة ، سيعود بسرعة إلى النسخة القديمة ويستأنف تشغيل المعدات. قد نفقد الوصول عن بعد ، وسيكون مركز البيانات مشلولا.
2. الخوف من تركها دون اختبار
يكتب مطورونا اختبارات الوحدة ، ويشارك الأفراد في الاختبار اليدوي. ولكن بمجرد وجود ظروف قاهرة ، وترك الفريق بدون اختبار يدوي. لم نتمكن من إصدار الميزات ، لذلك كان على المطورين التحقق من بعضهم البعض.
كانت ضربة فخر. حدث ذلك أن جميع المبرمجين في فريقي غادروا المختبرين (يدوي وآلي). ارجع إلى الاختبار اليدوي لهم - تراجع خطوة للخلف. كان الرجال خائفين من أنهم إذا استطاعوا التأقلم من تلقاء أنفسهم ، فلن يتم إرجاع المختبرين إليهم. لكن تبين أن الخوف لا أساس له ، بعد بضع سباقات ، أخذ المختبر مكانه في الفريق ، ومن التجربة تعلمنا الكثير من الأشياء المفيدة.
ما فائدة الاختبار المتقاطع- تذكروا "الشباب" ونظروا مرة أخرى إلى التطور من جانب المختبر. في بعض الحالات ، تمت إضافة إجراءات إضافية لتسهيل الحياة على المختبر. على سبيل المثال ، إنشاء إحصاءات للتحقق.
- وأكدوا الحقيقة المعروفة منذ زمن طويل وهي أن المطور لا يمكنه اختبار رمزه ، لأنه يغض الطرف عن بعض الأشياء. لذلك ، اختبر الرجال رمز بعضهم البعض.
- مرة أخرى كنا مقتنعين بأن المختبرين هم جزء مهم من الفريق. هم مسؤولون عن جودة الميزات التي تظهر في الإصدار.
3. الخوف من الانضمام إلى فريق آخر
تم إصدار DCImanager في عام 2013. لمدة ست سنوات ، تغيرت التكنولوجيا ، حان الوقت لعمل نسخة جديدة ، قررنا القيام بذلك من الصفر. لقد رسمنا نماذج أولية ، وحددنا MVP ، وتم تحديد أولوياتنا. تم تجميد تطوير النسخة القديمة ، لكنهم لم يتمكنوا من بدء النسخة الجديدة - تم بالفعل إعداد منتجين جديدين للإصدار ، تم تكريس جميع القوى لهما ، كان علينا الانتظار قليلاً. خلال فترة الهدوء ، كان على مطوري بلادي أن يصبحوا فريق مشروع
BILLmanager ، وهو منتجنا الآخر لاستضافة الأتمتة.
ثم ظهر خوف آخر. كان مطورو الهندسة بكل معنى كلمة منتج خائفين من أخذ الفواتير. بدا لهم أن هذه ليست منطقتهم ، وأنه من غير المثير للاهتمام فهم كومة من الحسابات. كنت قلقة من أنها تحبط مطوري. على عكسنا ، ابتهج فريق الفوترة بالتفريغ.
لبضعة سباقات سريعة ، ذهبنا للعمل على BILLmanager ، وكانت هذه التجربة مفيدة أيضًا.
بإيجاز عن كيفية التنفيذ- لتقليل ضغوط التحول إلى منتج آخر ، ظل الفريق فريقًا ولم يعتمد على اللاعبين من BILLmanager.
- تم اختيار المهام وفقًا لمبدأ "يجب القيام بالأمس ، ولكن ليس الأيدي الكافية". ناقش علماء المنتجون المهام ، ثم عند التخطيط للسباق التالي ، قمت بترجمتها إلى الفريق.
- كان مطورو BILLmanager هم مرشدينا. أجاب رجل الاستقبال على جميع الأسئلة ، وقال قائد الفريق ماذا وكيف يجب أن يعمل
- كان لدينا موقفين. في البداية ذهبنا إلى الفوترة ، ثم ناقشنا النتائج داخل فريقنا.
ما الفوائد التي حققها المطورون من المقدمة إلى فريق آخر- منتج آخر هو رمز شخص آخر تحتاج إلى فهمه ؛ بالإضافة إلى منطق العمل الآخر لفهمه. بفضل التوجيه والإرشاد وصبر رجل التنفيذ ، اعتدنا على الفواتير وضخنا مهارات جديدة ورأينا التحسينات بسرعة كبيرة.
- بالطبع ، تجسسنا على كيفية عمل بعض الأشياء داخل فريق آخر. قد يبدو أن كل شيء هو نفسه للجميع ، ولكن بغض النظر عن الطريقة. تكمن الاختلافات في التفاصيل. أخذوا الأفضل والأكثر ملاءمة لأنفسهم كقاعدة (على سبيل المثال ، قاموا بالتجسس ، وبعد أن تغيروا قليلاً لأنفسهم ، بدأوا في استخدام لوحة سكروم ، واعتمدوا بعض النقاط في نمط الكود ، وما إلى ذلك).
4. الخوف من أن يصبح المرشد / البقاء بدون قائد الفريق
تحتاج الشركة إلى أكبر عدد ممكن من المبرمجين الأقوياء ، لذلك عندما يضخ المطور مهارات صعبة وينتقل إلى المستوى المتوسط ، يصبح تدريب المبتدئين هو مسؤوليته. لكن التوجيه العام عادة ما يقع على عاتق قائد الفريق. لذلك كان في فريقنا ، حتى كانت هناك حاجة ماسة إلى تجربة مطور رائد في منتج آخر. كان على المبرمجين الذين تركوا بدون فريق عمل تدريب المبتدئين وبعضهم البعض.
كونك مرشدًا أمر مخيف. أنت بحاجة إلى أن تشتت انتباهك عن مهامك ، وتواصل مع شخص آخر ، وتشرح ما تفهمه بنفسك أحيانًا على مستوى الحدس ، وتشرح بطريقة تفهمها. إذا لم يفهم البداوان ، فهذه مشكلتك. إذا أخطأ ولم تلاحظ ، فأجبت.
لن أقدم نصيحة حول كيفية أن تصبح مرشدًا جيدًا ، فهذا موضوع لمقال منفصل. لكننا تمكنا ، ومن هذه التجربة المجهدة إلى حد ما ، تعلمنا ما يلي:
- في شرح ، يجب إعطاء سياق أكثر. كل شيء جميل في الرأس ، وعندما تقول ذلك ، يتبين أنه ممزق وغير مفهوم.
- لا ينبغي للمرء أن ينظر فقط إلى رمز في مراجعة ، ولكن يجب أن يفهم ما حاول شخص ما حله باستخدام هذا الرمز. ثم يكون من الأسهل فهم منطقها والعثور على الأخطاء.
- تقاسم المعرفة مفيد: تعلم صياغة الأفكار ؛ ضع كل شيء على الرفوف في رأسك ؛ بينما تشرح ، تجد أفضل حل للمشكلة.
5. الخوف من عدم تعلم التقنيات الجديدة
عندما ينتهي التهدئة ، حان الوقت لبدء إصدار جديد من منتج DCImanager. يبدو أن هذه هي اللحظة التي طال انتظارها. الآن ، مع فريق مليء بالأشخاص الطموحين ، سنبدأ كل شيء من الصفر - دون النظر إلى الأخطاء القديمة والتبعيات الغريبة التي تم تطويرها تاريخيًا في الشفرة. ولكن كان هناك مكان للخوف.
لسنوات عديدة ، تقدمت التكنولوجيا إلى الأمام. كتبنا النسخة القديمة في C ++ 11 وباستخدام Make ، بالنسبة للإصدار الجديد الذي اخترناه C ++ 17 و CMake و Conan و Docker. يحتاج الفريق لتعلم كل هذا ومعرفة كيفية التقديم. طريقة أخرى للخروج من منطقة الراحة والتحدي والفكر "ماذا لو لم أستطع وستكون أسوأ من الآخرين" ، ثم فجأة سيكون هناك المزيد من المشاكل بالنسبة لي ، لن أحسبها وسوف أطردني. ما زلنا نتقن تقنيات جديدة ، ولا تزال المعركة ضد هذا الخوف مستمرة.
كيفية تعلم التقنيات الجديدة بشكل أسرع- لا تخجل من سؤال الزملاء الأكبر سنا وذوي الخبرة ، لا تخف من أن تبدو غبيا.
- للتوثيق ، من أجل تسريع عملية غمر الوافدين الجدد وعدم قول الشيء نفسه 10 آلاف مرة. الحفاظ على قاعدة المعرفة.
- حسنًا ، Google موجودة دائمًا لمساعدتك. إذا لم يفلح ذلك ، فراجع النقطة 1.
ليست مخاوف بل تحديات
أغتنم التجارب كفرصة لتعلم أشياء جديدة ، لأصبح أفضل ، وأحاول أن يقوم فريقي بإلقاء نظرة على مخاوفهم أيضًا. أعتقد أن مزاج الرجال يعتمد علي كثيرًا. عندما تؤمن بالمنتج والمطورين ، استمع إليهم عند الوقوف وحلل المشاكل في الماضي ، وادعمهم في ورطة وشرح الحاجة إلى التغيير ، فمن السهل عليهم التغلب على المخاوف.
لكن لنكن صادقين ، في المخزون لا يزال لدينا رهابين غير مهزومين. الخوف من المواعيد النهائية ، على سبيل المثال ، أو الخوف من عدم الانسجام مع المبتدئين. حتى الآن ، يبدو أنه لا يمكن فعل شيء حيالها - فقط طرحها. ولكن ربما بمرور الوقت ستتغير وجهة نظرنا.
لماذا تخافين؟
سكرتير خاص إذا كنت تريد أن تكون أول من يرى نسخة DCImanager التجريبية - أرسل جهات الاتصال إلى bizdev@ispsystem.com مع موضوع "أريد أن أرى DCImanager الجديد". عندما يصبح جاهزًا ، سنكتب إليك. أو إذا كنت بحاجة إلى منتج لإدارة الخادم ، لكن DCImanager الحالي لسبب ما لا يناسب ولا يوجد حل مناسب في السوق ، اكتب رغباتك لمثل هذه البرامج ، ربما سنقوم بإدراج شيء في خطة التطوير.