هذه المقالة الرائعة التي كتبها جون أولسبو بعنوان
"أن تكون مهندسًا رائدًا
" . في المرة الأولى التي قرأتها قبل حوالي أربع سنوات ، عندما انتقلت للتو إلى وظيفتي الحالية ، وأثرت حقًا على أفكار حول هذا المجال من مسيرتي.
بعد إعادة قراءته الآن ، يبدو شيء واحد مثيرًا للاهتمام حقًا هناك ، وهو أن التعاطف ومساعدة الفريق هو جزء مهم من عمل الأقدم. وهو بالطبع صحيح!
لكني الآن أرى أن معظم أو جميع المهندسين الرائدين الذين أعرفهم يتلقون مساعدة كبيرة للموظفين الآخرين بالإضافة إلى عملهم البرمجي الشخصي. الآن يبدو لي أن زملائي لا نواجه مشكلة "ماذا ؟؟ بحاجة إلى التحدث مع الناس ؟؟ لا تصدق "، إلى أي مدى مع مشكلة أخرى:" كيف نوازن بين كل هذه القيادة والعمل مع المدخلات / البرمجة الفردية الخاصة بك؟ كم وأي نوع من العمل يجب أن أقوم به؟ " لذلك ، فبدلاً من الحديث عن
علامات الضابط من مقالة Olspau (التي أوافق عليها تمامًا) ، أود أن أتحدث عن
العمل الذي نقوم به.
عن ماذا تتحدث هذه المقالة
"ما يفعله المهندس الرئيسي" هو موضوع ضخم ، ولكن هنا مجرد مقال صغير ، لذلك يجب أن تضع في اعتبارك:
- لا يوجد سوى وصف واحد محتمل لما يمكن أن يفعله مهندس رائد. هناك العديد من الطرق للعمل ، وهذا لا ينبغي أن يكون عقيدة.
- لقد عملت بشكل أساسي في شركة واحدة فقط ، لذا من الواضح أن خبرتي وآرائي محدودة للغاية.
- من الواضح أن هناك العديد من المستويات "العليا". يتعلق الأمر بمستوى P3 / P4 في التسلسل الهرمي لموزيلا (مهندس أول / مهندس موظفين) ، ربما أقرب قليلاً إلى مستوى "الموظفين".
ما هي المسؤوليات
هذه هي الأشياء التي أرى أنها أكثر من عمل مهندس رئيسي وأقل من عمل مدير (على الرغم من أن المديرين يقومون بالتأكيد ببعض ما سبق ، خاصة إنشاء مشاريع جديدة وربط المشاريع بأولويات الأعمال).
كل هذا العمل تقريبًا
فني بشكل أساسي: من الواضح أن مساعدة شخص ما على التعامل مع مشروع معقد هو تفاعل بشري ، ولكن المشاكل التي سنعمل معها معًا ستكون عادة تقنية! ("ربما ، إذا قمنا بتبسيط التصميم ، يمكننا التعامل بشكل أسرع!").
- اكتب الرمز (من الواضح).
- قم بمراجعة الكود (من الواضح).
- كتابة ومراجعة وثائق التصميم . كما هو الحال مع المراجعات الأخرى ، من المرجح أن يساعد مظهر الطرف الثالث في تحسين التصميم.
- ساعد الزملاء إذا كانوا عالقين . في بعض الأحيان يعلق الناس في مشروع ، ومن المهم مساعدتهم! لا أفكر في هذا كثيرًا حول "القفز بالمظلات من السماء وتقديم معرفتك السحرية للناس" ، ولكن حول "العمل معًا لفهم المشكلة ومعرفة ما إذا كان بإمكان دماغين التعامل مع أسرع من واحد" :). وهذا يعني أيضًا العمل معًا ، وليس حل مشكلة بدلاً من شخص آخر.
- حافظ على ارتفاع زملائك . بالنسبة لأشخاص مختلفين ، فإن "المستوى" له معان مختلفة (يعني هذا بالنسبة لفريقي موثوقية / سلامة / راحة المنتج). إذا اتخذ شخص ما قرارًا لا يعجبني ، فهذا يعني إما أنني أعرف شيئًا لا يعرفه ، أو أنه يعرف شيئًا لا أعرفه! لذلك ، لا داعي لقول: "مرحبًا ، لقد أخطأت ، تحتاج إلى إجراء X بدلاً من ذلك" ، ولكن من الأفضل تزويدهم بمعلومات إضافية لم يكن لديهم ، وغالبًا ما يحل هذا المشكلة. وكثيراً ما اتضح أن شيئًا ما كان مفقودًا بالنسبة لي ، وفي الواقع كان حلهم معقولًا جدًا! في الماضي ، رأيت أحيانًا مهندسين رائدين يحاولون الحفاظ على معايير الجودة من خلال تكرار آرائهم بصوت أعلى لأنهم يعتقدون أن رأيهم صحيح. أنا شخصياً لم أجد هذا النهج مفيداً.
- إنشاء مشاريع جديدة . فريق تطوير البرمجيات ليس مكانًا محصلته صفر! أفضل المهندسين الذين أعرفهم لا يتركون العمل الأكثر إثارة للاهتمام لأنفسهم ، إنهم ينشئون مشاريع جديدة مثيرة للاهتمام / مهمة ويخلقون مساحة للآخرين للقيام بهذا العمل. على سبيل المثال ، بدأ شخص من فريقي في إعادة كتابة نظام النشر الخاص بنا. تبين أن المشروع كان ناجحًا للغاية ، والآن يعمل الفريق بأكمله على ميزات جديدة أصبحت أسهل في التنفيذ!
- خطط لعمل مشاريعك . يتعلق الأمر بكتابة / الإبلاغ عن خريطة طريق للمشاريع التي تعمل عليها والتأكد من فهم الأشخاص للخطة.
- تقرير مخاطر المشروع مقدما . من المهم جدًا معرفة متى لا يكون هناك شيء يسير على ما يرام ، وإخطار المهندسين / المديرين الآخرين بهذا الأمر وتحديد ما يجب فعله.
- تقرير النجاح!
- للقيام بمشاريع طرف ثالث تفيد الفريق / الشركة . أرى أن العديد من كبار السن يقومون أحيانًا بمشاريع صغيرة ولكنها مهمة (على سبيل المثال ، إنشاء أدوات التطوير / المساعدة في وضع السياسات) ، والتي تساعد في النهاية العديد من الأشخاص على أداء عملهم بشكل أفضل.
- كن على علم بكيفية ارتباط المشاريع بأولويات العمل.
- قرر متى توقف المشروع . اتضح أنه من الصعب بشكل مدهش أن تفهم متى تحتاج إلى التوقف / عدم البدء في العمل على شيء ما. :)
لقد وضعت "كتابة التعليمات البرمجية" في المقام الأول ، لأن هذه المهمة في الواقع تنزلق بسهولة إلى قائمة الأولويات. :)
لا يوجد عنصر "عمل تقديرات / توقعات" في القائمة. لست جيدًا هنا حتى الآن ، ولكن أعتقد أنه يستحق يومًا ما قضاء المزيد من الوقت في ذلك.
تبدو القائمة كبيرة. يبدو أنك إذا فعلت كل هذه الأشياء ، فستستوعب جميع مواردك الفكرية. أعتقد أنه بشكل عام من المنطقي عزل جزء ما واتخاذ قرار: "الآن سأركز على X و Y و Z ، أعتقد أن دماغي سينفجر إذا حاولت صنع B و C".
ما ليس واجبا
هذا أكثر تعقيدًا بعض الشيء. أنا لا أقول أنه لا يمكنك التعامل بشكل قاطع مع مثل هذه الأشياء. معظم المهندسين الرائدين الذين أعرفهم يقضون الكثير من الوقت في التفكير في هذه المشاكل ، ويعملون قليلاً في هذا الاتجاه.
ولكن يبدو لي أنه من المفيد رسم حدود معينة ، لأن بعض الناس لديهم شعور كبير بالمسؤولية تجاه الفريق والشركة - وهم على استعداد لتحمل كل شيء ، ونتيجة لذلك سيكونون مثقلين بالعمل ولن يكونوا قادرين على تقديم مساهمة فنية ، وهو في الواقع العمل الرئيسي. لذلك ، يساعد إنشاء حدود معينة على تحديد القضايا التي يكون من المنطقي طلب المساعدة عندما يصبح الوضع مضطربًا. حدودك الفعلية متروك لك / لفريقك. :)
معظم ما يلي عمل إداري. إخلاء المسؤولية: يفعل المديرون أكثر بكثير مما هو مدرج هنا (على سبيل المثال ، "إنشاء مشاريع جديدة") ، وفي بعض الشركات ، قد يكون بعض ما سبق عمل مهندس رئيسي (على سبيل المثال ، إدارة العدو).
- التأكد من أن كل موظف يكافأ حسب ميزاته على عمله.
- تأكد من توزيع العمل إلى حد ما.
- تأكد من أن الأشخاص يعملون جيدًا معًا.
- ضمان تماسك الفريق.
- تحدث بشكل خاص مع كل موظف.
- تدريب المديرين الجدد ، ومساعدتهم على فهم ما هو متوقع منهم (على الرغم من أنني أعتقد أن المبرمجين الرائدين يأتون غالبًا إلى مثل هذا النشاط؟).
- إدارة مشاريع الطرف الثالث (في عملي هذه وظيفة أي مهندس يقود هذا المشروع).
- كن مدير منتج.
- قيادة سباق العدو السريع / تحديد مراحل العمل لكل / إجراء اجتماعات أسبوعية.
من المفيد تحديد الحدود بشكل صريح.
لقد واجهت مؤخرًا موقفًا مثيرًا للاهتمام عندما ناقشت مسؤولياتي مع المدير - وأدركنا أننا ننظر إليها بشكل مختلف تمامًا! لقد أوضحنا الموقف ، والآن كل شيء على ما يرام ، ولكن جعلني أدرك أنه من المهم للغاية الاتفاق على التوقعات. :)
عندما بدأت كمهندس ، كان العمل بسيطًا جدًا - كتبت رمزًا ، وحاولت التوصل إلى مشاريع منطقية ، وكان كل شيء مثاليًا. كان لدي مديري فكرة واضحة عن عملي ، ولا شيء معقد للغاية. الآن تغير الوضع! لذلك ، أعتقد الآن أنني يجب أن أحدد العمل الذي:
- يمكنني القيام به / يناسبني على المدى الطويل.
- أريد أن أفعل / وهو ممتع بشكل عام ومتسق مع أهدافي الشخصية.
- ذات قيمة للفريق / المنظمة.
ستختلف الصياغة الدقيقة باختلاف الأشخاص (ليس لكل شخص نفس الاهتمامات ونقاط القوة ، على سبيل المثال ، لست جيدًا جدًا في مراجعة الشفرة!). أعتقد لهذا السبب أنه من الأهم مناقشة هذا الموضوع والاتفاق على التوقعات.
لا تستقر على عمل لا يمكنك / لا تريد القيام به
أعتقد أنه من المهم جدًا التخلي عن العمل الذي لا يمكنني القيام به أو الذي لن يجلب الفرح على المدى الطويل! يبدو من المغري القيام بالكثير من العمل ، حتى لو لم تعجبك حقًا ("أوه ، هذا جيد للفريق!" ، "حسنًا ، على
شخص ما القيام بذلك!"). بالطبع ، أحيانًا أتولى المهام فقط لأنه يجب إكمالها ، ولكن أعتقد أنه من أجل صحة الفريق ، من المهم حقًا أن يقوم الموظفون بما يحلو لهم بشكل عام وما يمكنهم القيام به على المدى الطويل.
لذلك ، سأقوم بمهام صغيرة تحتاج فقط إلى القيام بها ، ولكن من المهم ألا أقول في نفس الوقت: "أوه ، بالطبع ، سأقضي معظم وقتي على ما أقوم به بشكل سيئ وما لا يعجبني ، لا توجد مشاكل" :). وإذا كان "شخص ما" بحاجة إلى القيام بذلك ، فربما يعني ذلك أننا بحاجة إلى توظيف / تدريب شخص جديد لسد الفجوة. :)
لا يزال لدي الكثير لأتعلمه!
على الرغم من أنني أشعر بأنني بدأت أفهم ما هو "المهندس الرئيسي" (بالفعل 7 سنوات في حياتي المهنية) ، لكنني ما زلت أشعر أنني ما زلت بحاجة إلى معرفة المزيد عن هذا ، وسأكون مهتمًا بمعرفة كيف يحدد الآخرون الحدود عملك!