كيف تتعامل مع التغيرات السريعة في مواصفات المشروع في سيناريو الموعد النهائي الضيق؟[مغلق]

Question

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

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

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

كيف يمكنني التعامل مع مثل هذا الموقف؟إنه أمر محبط حقًا وقد ترك أحد الزملاء الفريق بالفعل.

Answer 1

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

بعض التصميم مقدما؟

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

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

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

هل يمكن أن تساعد Agile؟

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

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

أنت لست وحدك، بالمناسبة.تواجه الكثير من المتاجر (وربما جميعها) هذه التحديات.

Answer 2

لا تدعهم يفرضون الموعد النهائي في المقام الأول.

لديك خياران

• يمنحك مدير المشروع قائمة بالميزات وتخبرهم عندما تصبح جاهزة.
• يمنحك PM قائمة الميزات والموعد النهائي.ثم تخبرهم بالميزات التي ستنفذها في الوقت المحدد.

إذا كان مدير المشروع هو مديرك أو لديه سلطة فرض مواعيد نهائية + عدد من الميزات، فسأبحث عن وظيفة جديدة. careers.stackoverflow.com

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

Answer 3

وهذه الاشياء هو التحدي حقا للتعامل معها. المشكلة الحقيقية هنا هي أن لم يكن لديك actualy عملية.

والجواب يعتمد حقا على الوضع السياسي في المؤسسة الخاصة بك، وكم eneergy لديك لدفع عملية التغيير.

في الماضي لقد حاولت أن إحداث التغيير عملية لعدد من المنظمات وأنه كان دائما صراع. ومن الممكن، ولكن.

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

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

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

Answer 4

وهذا هو واحد من أهم التحديات التي سوف تواجهها كمطور.

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

تأكد من أن مدير المشروع الخاص بك يعرف المخاطر التي ينطوي عليها تنفيذ التغييرات في وقت متأخر لمشروع.

Answer 5

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

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

وبدلا من ذلك، يمكن أن يكون مدير أعماله في جميع أنحاء له. وهذه مشكلة.

إذا لا شيء يعمل بها، كما اقترح بالفعل، وتغيير المهمة هو شيء عادل للقيام به.