تنفيذ تغييرات كبيرة في النظام [مغلق]

Question

إذا كنت على دراية بعبارة "قم ببناء واحدة لرميها بعيدًا"، حسنًا، يبدو أننا فعلنا ذلك؛لقد وصلنا إلى حدود الإصدار 1 من تطبيقنا عبر الإنترنت.لقد حان الوقت لتنظيف الأمور عن طريق:

• إعادة تنظيم التعليمات البرمجية وواجهة المستخدم
• توحيد عمليات واجهة المستخدم
• إضافة المزيد من الوظائف
• البناء للمستقبل
• تعديل هيكل قاعدة البيانات لدينا للتعامل مع كل ما سبق

ما هي أفضل طريقة لتحقيق هذا التحول؟

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

هل يجب أن نبدأ "تثبيتًا" جديدًا لنظامنا وننقل المستخدمين إليه تدريجيًا بعد أن نتأكد من أن هذا التصميم الجديد يحل بشكل كافٍ مشاكل الإصدار 1؟

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

هل من الشائع أن يكون لديك مجموعة من عملاء "مختبري الإصدار التجريبي" الموثوق بهم والصبورين الذين يستخدمون إصدارًا متطورًا من التطبيق؟(الهدف هنا هو الحصول على تعليقات واختبار الأخطاء في النظام الجديد)

أي نصيحة أخرى؟التجربة الاولية؟

Answer 1

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

ومع ذلك، هناك بعض القواعد الأساسية.

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

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

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

وهذا يعني أنه إذا اخترت ترحيل المستخدمين ببطء من نظام إلى آخر، أنت مسؤولون عن التأكد من ترحيل كافة البيانات والإعدادات الخاصة بهم.على سبيل المثال، لا تفعل أي شيء غبي مثل إخبار المستخدم بأنه يجب عليه استخدام V1 لجميع السجلات قبل 12/09/2008 وV2 لجميع السجلات بعد ذلك.

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

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

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

Answer 2

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

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

امل ان يساعد!

Answer 3

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

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

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

Answer 4

هذا يبدو وكأنه إعادة الهيكلة التدريجية ينبغي أن تكون العبارة الطنانة الرشيقة التي تختارها.

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