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