الإصدار 3.0: تفعل أفضل

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

مستشفى التطبيقات

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

وضعنا العميل مهمة تطوير نسخة جديدة من التطبيق للعرض على المستثمرين.

تفاصيل المشروع

سمعي

كيفية تسجيل الصوت في الإصدار 2.0:

1. فتح التطبيق.
2. النقر على زر إضافة سجل.
3. في النافذة التي ظهرت ، اخترنا الإصدار المطلوب من جهاز التسجيل.
4. تملي تسجيل صوتي.
5. تم إدخال رقم المريض وتاريخ الزيارة ورقم الزيارة (الزيارة = موعد الطبيب).
6. لقد قاموا بالنقر فوق الزر "اكتمال" لتحميل الصوت وزيارة البيانات إلى الخادم.

الآن ، في الإصدار 3.0 ، مطلوب جهد أقل للكتابة:

1. يفتح الطبيب التطبيق.
2. لتحديد موعد (حسب التاريخ أو الوقت أو الرقم أو اسم المريض) من القائمة والنقر مرة واحدة لفتح بطاقة الزيارة.
3. سجلات الصوت.
4. يضغط على الزر "اكتمال" لإرسال الصوت إلى الخادم.

في الإصدار 3.0 ، عمل الطبيب مؤتمن قدر الإمكان. انخفض عدد العمليات ، في حين أن البرنامج نفسه يضيف بيانات عن المرضى.

العمل مع الحروف

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

• قم بعمل نقرة للحصول على قائمة برسائلك ؛
• اذهب الى نافذة اخرى
• انقر نقرًا مزدوجًا فوق الرسالة لفتحه ؛
• بعد معالجة الحروف من القائمة ، انقر مرة أخرى لتلقي الحروف التالية في القائمة.

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

السطح البيني

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

عمل خبراؤنا مع الواجهة وأبرزوا زر الصوت حتى يتمكن المستخدمون من إكمال مهمتهم بأقل عدد من النقرات.

بعد ذلك ، سنقدم تفاصيل حول كيفية قيامنا بتطوير الإصدار الجديد.

احتياجات جديدة

عندما اتصل بنا عميل لترقية الإصدار 2.0 ، كان التطبيق يعمل لمدة ثلاث سنوات تقريبًا. كانت مألوفة لدى المستخدمين وكانت لها مزايا معينة:

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

ومع ذلك ، عند تحليل تشغيل التطبيق ، وجدنا مثل هذه المشاكل:

• استغرق تطوير واختبار ميزات جديدة المزيد والمزيد من الوقت.
• عند إضافة وظائف جديدة ، ظهرت أخطاء في النظام ؛
• نتيجة لذلك ، تم إيقاف ما يصل إلى 30٪ من التحسينات المعقدة على الرف ، مما يهدد بتجاوز التطبيق. على سبيل المثال ، في المستشفيات ، ظهرت قوالب أكثر وأكثر تعقيدًا ، كان من الضروري إضافة أدوار جديدة في سير العمل ؛
• لا يمكن أن تدعم بنية التطبيق حلول جديدة ؛
• 40٪ من وقت التطوير تم إنفاقه على الدعم ؛
• كانت هناك صعوبات عند تثبيت إصدارات جديدة وتحديثات لمنتج سطح المكتب ؛
• واجهة مرهقة من 2000s يخيف عملاء جدد.
• منع نظام إعدادات غير مريح النظام من البدء بسرعة ، وكذلك زاد من مخاطر الأخطاء.

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

متطلبات الإصدار

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

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

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

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

فريق المشروع

كقاعدة عامة ، في بداية كل مشروع ، نحن في SimbirSoft نتواصل مع فريق من الخبراء من مختلف الملفات - المحللين وأخصائيي ضمان الجودة (QA) وغيرهم. عند العمل على طلب طبي ، قمنا بتكوين الفريق التالي:

• المطورين الذين كتبوا الكود والميزات المعدلة للإصدار 2.0 ؛
• أخصائي ضمان الجودة (QA). كانوا ، مع المطورين ، على دراية بالكود القديم ، والحلول المعمارية والأخطاء في الإصدار 2.0 ، وكذلك اختبار وظائف جديدة ؛
• Test Automation Engineer (SDET) ، الذي قام بإعداد التحقق التلقائي لحالة الاختبار في إصدارات سطح المكتب وإصدارات الويب ؛
• ذكاء الأعمال. تحدثوا مع العملاء والأطباء ، واكتشفوا كيف تم بناء العمليات التجارية ، وما هي متطلبات ورغبات التطبيق. بعد ذلك ، قاموا بصياغة مخططات عملية تجارية مفهومة للفريق بأكمله ؛
• مصمم وخبير سهولة الاستخدام. كانوا مسؤولين عن تطوير واجهة سهلة الاستخدام.
• مدير المشروع الذي شارك في إدارة وجدولة الوقت.

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

التحديات والحلول

عند ترقية التطبيق ، واجهنا عدة مراحل صعبة ، والتي سنناقشها أدناه.

تصميم التطبيق

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

تطوير البرنامج المساعد لمختلف المتصفحات

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

فرضيات العمل غير صالحة

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

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

التكامل مع النظم الخارجية

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

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

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

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

الاختبار والتحليلات

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

• فرق مختلفة عملت في المشروع ؛
• كان هناك كمية كبيرة من المهام المتوازية ؛
• أثناء العدو ، غالبًا ما تغيرت المتطلبات والمهام ؛
• كان من الضروري مراعاة تفاعل الميزات الجديدة مع الميزات المعتمدة بالفعل.

للعمل على الإصدار الجديد من المنتج ، نحتاج إلى تحويل مهام سير العمل الفردية ، على سبيل المثال:

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

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

النتائج

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

الآن نواصل تطوير المنتج وتقديم ميزات جديدة. نحن ننظر إلى كيفية عمل المستخدمين الحقيقيين مع النظام ، وجمع الحالات التي لم يتم حصرها ، وقصص المستخدمين ، وتحديد القيم التجارية الجديدة.

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

• فرضيات غير صحيحة من جانب العمل ممكنة ؛
• هناك تناقضات في رغبات المستخدمين (اترك كل شيء كما كان أو أعد صنعه بطريقة جديدة) ؛
• في بعض الأحيان يكون من الضروري إعادة هيكلة عمل الفريق من أجل تحقيق نتيجة أفضل.

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

شكرا لاهتمامكم! نأمل أن تجد هذه المقالة مفيدة.