سؤال

يقول والدي دائمًا: "المسؤولية بدون سلطة لا معنى لها".

ومع ذلك، أجد أننا كمطورين، نتعثر في مواقف طوال الوقت:

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

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

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


*** مثال - يأتي الرئيس إليك ويقول "لماذا هناك الكثير من الأخطاء !!؟!؟" - قد يقول معظمنا "ليس لدينا نظام جيد لتتبعهم!" ، ولكن هذا عادة ما يُنظر إليه كذريعة في تجربتي.فماذا لو كان بإمكانك الإشارة إلى بعض التقارير (المديرون يحبون التقارير) والقول "انظر، هذا هو السبب"؟

هل كانت مفيدة؟

المحلول

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

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

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

يمكنك العثور على مزيد من النصائح حول هذا الأمر في بي إس بي و ملعقة شاي مقالات ويكيبيديا

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

نصائح أخرى

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

الإجابة البسيطة هي - يمكنك البدء في استخدام الأدوات بنفسك.

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

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

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

إذا لم يحصلوا عليها، يمكنك الاستمرار في أن تكون الوحيد مطور محترف في شركتك أو مجموعتك.أو على الأقل سوف يساعد في حشو سيرتك الذاتية: "تجربة إعداد وتوجيه الآخرين في CVS وFogBugs لتحسين جودة المنتج" وما شابه ذلك.

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

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

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

للحصول على نظرة أوسع حول كيفية القيادة من منتصف أو أسفل المؤسسة، راجع كتاب جون ماكسويل قائد 360 درجة.

إذا كنت تريد تقريرًا عن الجودة وتأثيرها على الإنتاجية - فإليك الأفضل:http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html لدى Caper Jones عدد قليل من الكتب ولا يزال يظهر في المؤتمرات.خارج بيئة التطوير المتكاملة (IDE) الجيدة، يحتاج المطور/مجموعة تكنولوجيا المعلومات إلى التحكم في كود المصدر (VSS، SubVersion، إلخ) وتتبع المشكلات

إذا طُلب من المحاسب إنتاج مجموعة من الحسابات دون استخدام القيد المزدوج وعدم الموازنة، فلن يتوقع أحد من المحاسب أن يفعل ذلك.

ومع ذلك، فقد تم استخدام القيد المزدوج بشكل قياسي من قبل المحاسبين منذ القرن الثالث عشر تقريبًا.

سوف يستغرق الأمر وقتًا طويلاً قبل أن يكون لدينا، كمهنة، ممارسات معيارية متأصلة لدرجة أن الفرد سيعمل بدونها.

لذا، آسف، أتوقع أننا سنضطر إلى مواجهة هذا النوع من المشاكل كثير العام القادم.

آسف لعدم الإجابة على سؤالك مباشرة، ولكن...

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

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

إذا كان هناك أي شيء، فقد تسببت التكنولوجيا في استنزاف التواصل المباشر وجهًا لوجه.

آسف، لقد خرجت عن الظل مرة أخرى - لا تتردد في downmod.

البرمجة أنت فقط من يستطيع الاحتفاظ بملفاتك المصدرية مرتبة، ومعلقة بشكل جيد، والحفاظ على عدد الأخطاء منخفضًا من خلال الاختبارات.لكنك ستحتاج إلى أدوات خارجية لتتبع التقدم والأخطاء (bugzilla، وyoxel، وtrac، وأدوات مخطط جانت، وMylyn for Eclipse، ومدونة، أو أي شيء آخر).في هذه الحالات، يكون الأشخاص والانضباط والعادات الجيدة والقيادة هي القوة الساحقة، ولا يمكن لأي أدوات برمجية أو عرض من الفرد أن يفوز بمفرده.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top