في هذه المقالة ، سوف أشارك تجربتي في اختيار الأفكار لتطوير وظائف منتجاتنا وأخبرك بكيفية الحفاظ على نواقل التطوير الرئيسية.
نحن نعمل على تطوير نظام التسوية الآلي (ACS) - الفواتير. شرط
عمر منتجاتنا 14 سنة. خلال هذا الوقت ، انتقل النظام من الإصدارات الأولى من المقيِّم الصناعي إلى مجمع معياري يتكون من 18 منتجًا يكمل كل منهما الآخر. يعد التطوير المستمر أحد أهم جوانب طول العمر للبرامج. والأفكار مطلوبة من أجل التنمية.
الأفكار
مصادر
هناك 5 مصادر:
- الصديق الرئيسي لمطور نظم معلومات الشركات هو زبون. والعميل هو صورة جماعية لصناع القرار ورعاة المشروع وأصحاب ومنفذي العمليات ومتخصصي تكنولوجيا المعلومات الداخليين والمستخدمين العاديين وعدد كبير من الأشخاص المهتمين بدرجات متفاوتة. من المهم بالنسبة لنا أن يكون كل ممثل عن العميل مزودًا للأفكار. في أسوأ الحالات ، نحصل فقط على ردود فعل سلبية حول المشاكل في النظام. في أحسن الأحوال ، هناك شخص من جانب العميل يمثل مصدرًا دائمًا لأفكار التحسين ، ويوفر معلومات منظمة حول احتياجات العميل.
- لنا البائعين ومديري الحسابات هي ثاني أهم مصدر لأفكار التحسين. يتواصلون كثيرًا وبنشاط مع ممثلي الصناعة ، ويتلقون طلبات مباشرة لوظيفة الفوترة من العملاء المحتملين. يجب أن يكون التجار والحسابات على دراية بجميع التغييرات المهمة في وظائفهم وآخر تحديثات البرامج للمنافسين ، وأن يكونوا قادرين على تبرير إيجابيات وسلبيات الحلول المختلفة. هؤلاء الموظفون هم أول من يشعر إذا أصبحت بعض ميزات الفوترة معيارًا واقعيًا ، والتي بدونها لا يمكن اعتبار البرنامج مكتملاً.
- مالك المنتج هو أحد كبار المديرين لدينا أو مدير مشروع ذو خبرة كبيرة. يحافظ على الأهداف الإستراتيجية للشركة في الاعتبار ويضبط خطط تطوير المنتج وفقًا لها.
- مهندس معماري، الشخص الذي يفهم إمكانيات وقيود الحلول التكنولوجية المختارة / المستخدمة وتأثيرها على تطوير المنتج.
فرق التطوير والاختبار. الأشخاص الذين يشاركون بشكل مباشر في تطوير المنتجات.
تصنيف الزيارات
نتلقى البيانات الأولية من المصادر - الرسائل والتذاكر والطلبات الشفوية. الجميع
الطعون مصنفة:
- المشاورات بالمعنى "كيف أفعل ذلك؟" ، "كيف يعمل؟" ، "لماذا لا يعمل؟" ، "أنا لا أفهم ...". المكالمات من هذا النوع تذهب إلى خط الدعم من المستوى 1. من الممكن إعادة تدريب الاستشارة في أنواع أخرى من الاستئناف.
- الحوادث بمعنى "لا يعمل" و "خطأ". يتم التعامل معها بواسطة خطوط دعم 2 و 3. إذا كان من الضروري إصلاح التصحيح وتحريره بسرعة ، فيمكن نقله من الدعم مباشرةً إلى التطوير. من الممكن إعادة تصنيفها إلى طلب تغيير وإرسالها إلى السجل المتأخر.
- طلبات التغيير والتطوير. ادخل إلى تراكم المنتج ، متجاوزًا خطوط الدعم. ولكن بالنسبة لهم هناك إجراء معالجة منفصل.
توجد مثل هذه الإحصائيات حول الزيارات - فورًا بعد الإصدار ، يزداد عدد الزيارات بنسبة 10-15٪ لفترة قصيرة. هناك أيضًا دفعات من المكالمات عندما يأتي عميل جديد به عدد كبير من المستخدمين إلى خدماتنا السحابية. يتعلم الناس استخدام ميزات البرامج الجديدة ، فهم بحاجة إلى المشورة. حتى العميل الصغير ، عند بدء العمل في النظام ، يحرق بسهولة أكثر من 100 ساعة من الاستشارات شهريًا. لذلك ، عند الاتصال بعميل جديد ، فإننا نحتفظ دائمًا بالوقت للاستشارات الأولية. في كثير من الأحيان نفرد متخصصًا معينًا. تكلفة الإيجار ، بالطبع ، لا تسدد تكاليف العمالة هذه ، ولكن بمرور الوقت تتراجع الأوضاع. تستغرق فترة التكيف ، كقاعدة عامة ، من 1 إلى 3 أشهر ، وبعد ذلك تقل الحاجة إلى الاستشارة بشكل كبير.
في السابق ، استخدمنا حلولًا مكتوبة ذاتيًا لتخزين المكالمات. لكنها تحولت تدريجياً إلى منتجات Atlassian. أولاً ، تم نقل التطوير لتسهيل العمل على Agile ، ثم الدعم. الآن جميع العمليات الحرجة تعيش في Jira SD ، بالإضافة إلى أنها مزودة بمكونات إضافية مختلفة لـ Jira ، بالإضافة إلى Confluence. ظلت الحلول المكتوبة ذاتيًا فقط على العمليات غير الحرجة لأنشطة الشركة. اتضح أن مهامنا أصبحت الآن شاملة ، ويمكن نقلها بين الدعم والتطوير دون القفز من نظام إلى آخر.
من هذه الحزمة ، يمكننا الحصول على بيانات حول جميع المهام ، وتكاليف العمالة المخططة والفعلية ، واستخدام خيارات الفوترة المتنوعة للعملاء وإنشاء وثائق للاحتياجات الداخلية وتقرير للعملاء.
معالجة طلبات التغيير
عادةً ما تأتي هذه الطلبات في شكل متطلبات الميزة. يقوم محللنا بدراسة الطلب ، وإنشاء المواصفات والاختصاصات ذات المستوى الأعلى. نقل المواصفات والاختصاصات إلى الشخص الذي أرسل هذا الطلب للموافقة - يجب أن نتأكد من أننا نتحدث نفس اللغة مع العميل.
بعد تلقي تأكيد من العميل بأننا فهمنا بعضنا البعض بشكل صحيح ، يقوم المحلل بإدخال الطلب في تراكم المنتج.
إدارة ميزات المنتج
تراكم الطلبات المتراكمة للتغيير والتطوير. يجتمع مرة كل ستة أشهر المجلس الفني المكون من المدير ورؤساء الصيانة والتطوير والمبيعات ومهندس النظام. في تنسيق المناقشة ، يقوم المجلس بتحليل الطلبات المتراكمة وتحديد أولوياتها ويوافق على 5 مهام تطوير للتنفيذ في الإصدار التالي.
في الواقع ، يستجيب المجلس الفني لمتطلبات الصناعة والسوق ، مع مراعاة الاحتياجات المسجلة في التطبيقات. كل ما هو قليل الأهمية يبقى في التراكم ولا يصل إلى التنمية.
تصنيف طلبات التغيير والتمويل
التنمية مكلفة. لذلك ، سنخبرك على الفور بالخيارات التي قد تكون لدينا إذا جاء طلب التغيير من عميل وليس موظفًا.
يتم تصنيف طلبات التغيير على النحو التالي: الاحتياجات الخاصة بالصناعة أو الخصائص الفردية للمؤسسة ؛ قدرًا كبيرًا من الوظائف الجديدة أو إصلاحًا بسيطًا. تتم معالجة الإصلاحات الصغيرة والطلبات الفردية دون أي زخرفة. يتم احتساب الطلبات الفردية وتنفيذها لعميل معين كجزء من مشروع العمل معه.
إذا لم تكن هذه حاجة صناعية ضخمة وكان حجم الوظائف كبيرًا ، فيمكن عندئذٍ اتخاذ قرار لتطوير وحدة منفصلة جديدة سيتم بيعها بالإضافة إلى الوظيفة الرئيسية. في حالة وجود مثل هذا الطلب من العميل ، يمكننا تحمل تكاليف تطوير الوحدة ، وتزويد العميل بالوحدة مجانًا أو بدفع جزئي ، ووضع الوحدة في المجال العام للبيع. في مثل هذه الحالة ، يتحمل العميل جزءًا من العبء المنهجي ، وفي الواقع ، يجري تنفيذًا تجريبيًا للوحدة.
إذا كانت هذه حاجة صناعة ضخمة ، فيمكن اتخاذ قرار لتضمين وظائف جديدة في المنتج الأساسي. نتحمل التكاليف في هذه الحالة بالكامل ، وتظهر الوظيفة الجديدة في الإصدار الحالي من البرامج.
يتم تزويد العملاء القدامى بتحديث.
قد يكون أيضًا أن العديد من العملاء لديهم حاجة مماثلة ، لكنه لا يسحب منتجًا ضخمًا. في هذه الحالة ، يمكننا إرسال المواصفات إلى هؤلاء العملاء وعرض مشاركة تكاليف التطوير بينهم. في النهاية ، يربح الجميع: يحصل العملاء على تنفيذ الوظيفة بتكلفة منخفضة ، ونثري المنتج ، وبعد فترة يمكن للمشاركين الآخرين في السوق أيضًا الحصول على الوظيفة لاستخدامهم.
DevOps
يعد التطوير إصدارين رئيسيين كل عام. في كل إصدار ، يتم حجز الوقت لتنفيذ 5 مهام وردت من المجلس الفني. وبالتالي ، وراء معدل الدوران ، لا ننسى أبدًا تطوير المنتج.
يخضع كل إصدار لمجموعة مناسبة من الاختبارات والتوثيق. علاوة على ذلك ، يتم تثبيت هذا الإصدار في بيئة الاختبار للعميل المقابل ، والذي بدوره يقوم بفحص كل شيء بدقة ، وبعد ذلك يتم نقل الإصدار إلى الإنتاج.
بالإضافة إلى نظام الإصدار ، هناك تنسيق لإصلاحات الأخطاء السريعة بحيث لا يعيش العملاء مع الأخطاء لمدة ستة أشهر. سيسمح لك هذا التنسيق الوسيط بالاستجابة بسرعة لحوادث الأولويات الأولى والوفاء باتفاقية مستوى الخدمة المحددة.
كل ما سبق صحيح في المقام الأول لقطاع الشركات والحلول داخل الشركة. بالنسبة للخدمات السحابية التي تركز على قطاع الشركات الصغيرة والمتوسطة ، لا توجد فرص واسعة للعملاء للمشاركة في تطوير المنتجات. تنسيق عقد الإيجار للشركات الصغيرة والمتوسطة الحجم لا يقترح هذا حتى. بدلاً من طلب التغيير في شكل متطلبات واضحة من طرف شركة ، لا يوجد سوى التعليقات والرغبات المعتادة للخدمة. نحاول الاستماع ، لكن المنتج ضخم وقد تتعارض رغبة عميل واحد في إحضار شيء مألوف من نظامه التاريخي القديم مع استراتيجية تطوير النظام ككل.
المصدر: www.habr.com