Geekly articles weekly

Versi 3.0: lakukan lebih baik

Bisnis ini terus mengembangkan produk-produk IT-nya. Tidak ada cara untuk "menghentikan momen", jika tidak, bahkan program terbaik pun akan menjadi usang. Kami memberi tahu bagaimana kami membuat versi baru aplikasi medis untuk Eropa dan masalah apa yang dipecahkan secara bersamaan.



Aplikasi Rumah Sakit


Kami bekerja dengan aplikasi medis untuk rumah sakit di Eropa. Ini membantu dokter menghabiskan lebih banyak waktu dengan pasien dengan mengurangi dokumen. Dokter mendikte informasi tentang pasien dan pemeriksaan, aplikasi menerjemahkan rekaman audio ke dalam format teks, mengisi templat dan menghasilkan dokumen untuk pekerja medis dan pasien. Pada setiap tahap pekerjaan, logika bisnisnya sendiri dan integrasi dengan beberapa sistem eksternal diletakkan.

Klien memberi kami tugas untuk mengembangkan versi baru aplikasi untuk didemonstrasikan kepada investor.



Detail proyek


Audio


Cara merekam audio dalam versi 2.0:

  1. Membuka aplikasi.
  2. Klik pada tombol add record.
  3. Di jendela yang muncul, kami memilih versi perangkat rekaman yang diinginkan.
  4. Rekaman audio yang didikte.
  5. Nomor pasien, tanggal kunjungan, nomor kunjungan (kunjungan = janji dokter) dimasukkan.
  6. Mereka mengklik tombol Lengkap untuk mengunggah audio dan mengunjungi data ke server.

Sekarang, dalam versi 3.0, lebih sedikit usaha diperlukan untuk menulis:

  1. Dokter membuka aplikasi.
  2. Pilih janji temu (berdasarkan tanggal, waktu, nomor atau nama pasien) dari daftar dan klik 1 kali untuk membuka kartu kunjungan.
  3. Merekam audio.
  4. Tekan tombol Lengkap untuk mengirim audio ke server.

Dalam versi 3.0, pekerjaan dokter adalah seotomatis mungkin. Jumlah operasi telah menurun, sementara program itu sendiri menambahkan data tentang pasien.

Bekerja dengan huruf


Bekerja dengan huruf juga menjadi lebih mudah. Di versi 2.0, ada antrian yang sulit untuk diproses. Dokter tidak dapat langsung menerima daftar surat lengkap - hanya sebagian dan dalam urutan tertentu. Untuk memulai, Anda harus:

  • klik untuk mendapatkan daftar surat Anda;
  • pergi ke jendela lain;
  • klik dua kali pada surat untuk membukanya;
  • setelah memproses surat-surat dari daftar, klik lagi untuk menerima surat-surat berikut dalam daftar.

Dalam versi 3.0, dokter melihat semua huruf yang tersedia untuk diproses. Ia dapat memilih dokumen dengan dua cara - baik secara manual dalam daftar, atau menggunakan filter dan jenis (Anda dapat menyimpannya untuk membuka surat lebih jauh dengan satu klik). Untuk membuka surat itu, cukup klik sekali.

Antarmuka


Secara umum, antarmuka versi 2.0 rumit dan tidak nyaman. Tugas awal aplikasi adalah menghemat waktu spesialis medis dengan mengurangi alur kerja kertas dan bekerja dengan rekaman audio. Dalam praktiknya, aplikasi tidak mengatasi tugas ini sebaik yang kita inginkan. Untuk membuat catatan, dokter harus memilih banyak pengaturan dari daftar drop-down yang panjang.

Pakar kami bekerja dengan antarmuka dan mengedepankan tombol audio sehingga pengguna dapat menyelesaikan tugas mereka dalam jumlah klik paling sedikit.

Selanjutnya, kami akan memberikan detail tentang bagaimana kami mengembangkan versi baru.

Kebutuhan baru


Ketika klien menghubungi kami untuk memutakhirkan versi 2.0, aplikasi telah bekerja selama sekitar tiga tahun. Itu akrab bagi pengguna dan memiliki keunggulan tertentu:

  • Ada serangkaian fungsi untuk melakukan logika bisnis yang kompleks, integrasi dengan sistem pihak ketiga;
  • klien terbiasa dengan program dan tidak ingin meninggalkannya;
  • Staf dukungan teknis mengetahui aplikasi dan dengan cepat membantu pengguna;
  • Ada pengaturan yang fleksibel untuk mengkonfigurasi sistem untuk keinginan bisnis apa pun;
  • pelacakan kemungkinan masalah di bagian server sistem dibuat, solusi untuk menyelesaikannya diketahui.

Namun, ketika menganalisis operasi aplikasi, kami menemukan masalah seperti:

  • mengembangkan dan menguji fitur-fitur baru membutuhkan lebih banyak waktu;
  • saat menambahkan fungsi baru, kesalahan muncul di sistem;
  • sebagai hasilnya, hingga 30% dari perbaikan kompleks ditunda, yang mengancam untuk membatalkan aplikasi. Misalnya, di rumah sakit, semakin banyak template kompleks muncul, perlu untuk menambahkan peran baru dalam Workflow;
  • arsitektur aplikasi tidak dapat mendukung solusi baru;
  • 40% dari waktu pengembangan dihabiskan untuk dukungan;
  • ada kesulitan ketika menginstal versi baru dan pembaruan produk desktop;
  • antarmuka rumit dari tahun 2000-an menakuti pelanggan baru;
  • sistem pengaturan yang tidak nyaman mencegah sistem untuk memulai dengan cepat, dan juga meningkatkan risiko kesalahan.

Ketika menilai kekuatan dan tantangan, kami sampai pada kesimpulan bahwa aplikasi perlu dibuat lebih mobile (versi web daripada desktop) dan nyaman, kompetitif, mudah beradaptasi dengan tugas bisnis.

Persyaratan Versi


Kami menganalisis fungsi aplikasi dan mengidentifikasi yang paling penting yang membuat produk berharga bagi bisnis. Berdasarkan data ini, kami menentukan program apa yang seharusnya dalam versi baru:

  • Diperlukan fungsi kunci dari aplikasi intuitif untuk dokter dan pengguna lain;
  • Seharusnya mudah bagi pengguna - penyedia layanan kesehatan dan staf pendukung - untuk mempelajari cara menggunakan program;
  • menghilangkan kehilangan data bahkan dalam kondisi ekstrem (pemadaman listrik, akses Internet yang tidak stabil, dll.);
  • dokumen yang dihasilkan oleh sistem harus mematuhi norma dan persyaratan hukum;
  • selama pembaruan sistem, kemungkinan ketidaknyamanan bagi pengguna dan layanan dukungan harus diminimalkan;
  • perlu untuk membuat arsitektur modular berorientasi layanan yang didasarkan pada komponen yang terdistribusi secara longgar, yang akan memungkinkannya digunakan untuk membangun sistem perangkat lunak yang kompleks;
  • Gunakan Active Directory untuk mengonfigurasi lingkungan kerja Anda secara seragam.

Selain itu, tidak mungkin untuk membiarkan versi baru menjadi "klon yang rumit" dari yang lama. Karena itu, fungsi-fungsi utama harus disimpan, tetapi tanpa membebani aplikasi. Kami dengan kejam meninggalkan pengaturan rumit yang berlebihan.

Analis bisnis yang bekerja dengan versi 2.0 tidak segera menerima perubahan. Dalam kerangka acuan, frasa sering ditemukan: "Seharusnya ada di sini seperti pada versi 2.0", "Ambil skema kerja dalam versi 2.0". Hal yang paling sulit pada tahap ini adalah penolakan terhadap godaan untuk mengambil segalanya, seperti pada versi sebelumnya.

Tim proyek


Sebagai aturan, pada awal setiap proyek, kami di SimbirSoft terhubung ke tim ahli dari berbagai profil - analis, spesialis jaminan kualitas (QA) dan lainnya. Saat mengerjakan aplikasi medis, kami mengumpulkan tim berikut:

  • pengembang yang menulis kode dan mengadaptasi fitur versi 2.0;
  • Spesialis Jaminan Kualitas (QA). Mereka, bersama-sama dengan pengembang, terbiasa dengan kode warisan, solusi arsitektur dan kesalahan versi 2.0, dan juga menguji fungsi-fungsi baru;
  • Test Automation Engineer (SDET), yang mengatur verifikasi kasus uji otomatis di versi desktop dan web;
  • Kecerdasan Bisnis. Mereka berbicara dengan pelanggan dan dokter, menemukan bagaimana proses bisnis dibangun, apa persyaratan dan keinginan untuk aplikasi tersebut. Setelah itu, mereka membuat diagram proses bisnis yang dapat dimengerti oleh seluruh tim;
  • Desainer dan ahli kegunaan. Mereka bertanggung jawab untuk mengembangkan antarmuka yang ramah pengguna.
  • Manajer proyek yang terlibat dalam pengelolaan dan penjadwalan waktu.

Dalam prosesnya, kami terus-menerus memelihara tabel dugaan risiko dalam versi baru. Untuk mencegahnya, kami memikirkan sistem pengaturan aplikasi yang fleksibel dan mengotomatiskan pengujiannya untuk melindungi pengguna dari kesalahan. Secara khusus, spesialis SDET kami menulis kerangka kerja yang membantu untuk dengan cepat memeriksa semua perubahan dalam kode dan menghabiskan lebih sedikit waktu untuk pengujian regresi.

Tantangan dan Solusi


Saat memutakhirkan aplikasi, kami menghadapi beberapa tahap sulit, yang akan kami bahas di bawah ini.

Desain aplikasi


Karena versi sebelumnya memiliki antarmuka yang rumit, kami mendesain ulang desain aplikasi. Kami mengusulkan lima opsi awal dan menunjukkannya kepada kelompok fokus dari kalangan pengguna aplikasi, melakukan tes kegunaan. Akibatnya, spesialis medis memilih satu opsi, yang, menurut mereka, ternyata menjadi yang paling nyaman, menarik dan mudah digunakan.

Pengembangan plugin untuk berbagai browser


Kami telah memberikan berbagai risiko teknis yang terkait dengan aplikasi. Misalnya, plugin yang dipilih untuk implementasi mungkin tidak cocok untuk beberapa browser Internet. Untuk mengurangi risiko ini, pertama-tama kami mengembangkan plug-in untuk perangkat lunak yang digunakan di sebagian besar lembaga medis mitra. Di masa depan, kami dengan tenang mengembangkan plugin untuk browser lain.

Hipotesis bisnis tidak valid


Tugas kami adalah mengembangkan versi produk yang terbatas untuk dipresentasikan kepada investor. Untuk alasan ini, kami berusaha menerapkan dalam aplikasi hanya fungsi yang paling diperlukan. Kami menganalisis beberapa hipotesis pelanggan dan menolak untuk menerapkannya.

Misalnya, pelanggan menyarankan membuat kalender untuk merencanakan pekerjaan spesialis medis. Menurut hipotesis, kalender dapat membuat pekerjaan dokter lebih nyaman. Namun, dalam kondisi nyata, fungsi ini tidak berhasil, sehingga pada akhirnya dimatikan. Kemudian, kalender disesuaikan dengan kebutuhan kelompok pengguna lain ─ pasien, bukan pekerja medis. Hipotesis yang tidak valid ─ ini adalah bagian integral dari bisnis, dan Anda harus siap untuk itu.

Integrasi dengan sistem eksternal


Butuh banyak waktu untuk setuju dengan mitra kami tentang prosedur untuk mengintegrasikan aplikasi dengan sistem eksternal untuk mengirim dan menyimpan surat.

Pengguna aplikasi ─ fasilitas medis ─ ingin menggunakan sistem integrasi lama yang familier untuk versi 3.0, mereka tidak dapat diubah. Mitra kami berasumsi bahwa dalam hal ini integrasi akan cepat. Namun, pada kenyataannya, banyak tugas dikaitkan dengan integrasi:

  • Kumpulkan informasi umum tentang cara kerja sistem pengiriman surat;
  • membuat daftar bug penting yang ada di 2.0;
  • pertimbangkan kasus-kasus ini pada tahap analitik dan pengembangan untuk memperhitungkannya dan tidak menginjak rake yang sama;
  • menganalisis apakah fungsi versi 2.0 cocok untuk proses versi 3.0 atau apakah ada sesuatu yang perlu diubah. Jika terjadi perubahan, tentukan setiap kali mengapa fungsi spesifik diperlukan dan berkomunikasi dengan spesialis teknis pelanggan, dan bukan hanya analis.

Dalam proses negosiasi dengan pelanggan, kami dapat membuktikan bahwa bekerja dengan integrasi membutuhkan waktu. Mitra kami setuju dengan kami: Anda tidak bisa hanya mengambil dan mentransfer kode dari satu versi ke versi lain.

Pengujian dan analitik


Versi sebelumnya dari proyek ini dibuat tanpa partisipasi analis. Pengembang dan spesialis QA menentukan persyaratan dalam proses pembuatan aplikasi. Versi ketiga sudah didasarkan pada persyaratan analis, namun, masih ada kesulitan dengan pengujian:

  • tim yang berbeda bekerja pada proyek;
  • ada banyak tugas paralel;
  • selama sprint, persyaratan dan tugas sering berubah;
  • Itu perlu untuk mempertimbangkan interaksi fitur baru dengan yang sudah disetujui.

Untuk mengerjakan versi produk yang baru, kami perlu mengubah alur kerja individual, misalnya:

  • Kami telah memperkuat analitik dari sisi pengembangan dan QA dan telah menyediakan waktu tambahan untuk ini.
  • Itu adalah aturan untuk menunjukkan tujuan fungsi yang diuji dalam persyaratan untuk peninjauan. Ini meningkatkan pemahaman tugas untuk analis dan memberikan kesempatan untuk mengusulkan solusi optimal.
  • Untuk memperjelas ketentuan kerja, kami mengubah terminologi: alih-alih perkiraan kasar dalam hitungan jam, kami mulai mengklasifikasikan tugas sebagai "besar" atau "kecil". Kami mulai menghitung waktu tunggu hanya setelah peninjauan penuh tugas dari sisi pengembangan, QA dan persetujuan versi final dari persyaratan oleh pelanggan. Jika tugas diperluas, maka kami menghitung ulang perkiraan biaya waktu.
  • Kami mulai merencanakan fungsi apa yang harus diimplementasikan di kuartal mendatang ─ untuk 2-3 rilis berikutnya. Agar dapat memprediksi perkembangan dengan lebih akurat, kami tidak lagi memasukkan rencana rilis tugas-tugas yang tidak lulus penilaian.
  • Untuk kenyamanan analis dan pemahaman yang lebih baik tentang sistem, kami menunjukkan dalam daftar periksa interaksi mana yang harus dipertimbangkan ketika membuat persyaratan. Kami juga mengembangkan aturan umum untuk menulis artikel dalam Pertemuan dan dokumentasi di JIRA dan mulai mematuhinya.

Demonstrasi online reguler dengan pelanggan membantu kami meningkatkan pemahaman kami tentang proses bisnisnya. Selama percakapan, mitra kami memberi tahu detail cara kerja dokter, dan menjelaskan tujuan bisnis. Kami, pada gilirannya, menjelaskan nuansa teknis dan menunjukkan berbagai kasus yang tidak jelas. Ini memungkinkan kami untuk merumuskan persyaratan produk yang memenuhi kebutuhan lembaga medis dan optimal dalam hal biaya implementasi.

Ringkasan


Fleksibilitas dalam proses kerja dan perhatian pada kebutuhan bisnis memungkinkan kami untuk mengatasi semua kesulitan yang muncul selama proses pengembangan. Kami telah berhasil membuat dan meluncurkan versi baru aplikasi untuk institusi medis di Eropa.

Sekarang kami terus mengembangkan produk dan memperkenalkan fitur-fitur baru. Kami melihat bagaimana pengguna nyata bekerja dengan sistem, mengumpulkan kasus dan kisah pengguna yang tidak terhitung, dan mengidentifikasi nilai bisnis baru.

Saat membuat versi baru suatu produk, pengembang, sebagai suatu peraturan, menghadapi masalah yang sama seperti yang kita lakukan, misalnya:

  • hipotesis yang salah dari sisi bisnis adalah mungkin;
  • ada kontradiksi dalam keinginan pengguna (biarkan semuanya seperti apa adanya atau remake dengan cara baru);
  • kadang-kadang perlu untuk merestrukturisasi pekerjaan tim untuk mencapai hasil yang lebih baik.

Hal utama adalah bahwa rilis versi baru dari produk IT bukan salinan dari kode "Ctrl + C", "Ctrl + V" dari versi sebelumnya, tetapi pengembangan penuh, dari awal. Ini karena proses bisnis, kebutuhan pengguna, serta situasi di pasar solusi TI, sedang berubah.

Terima kasih atas perhatian anda! Kami harap artikel ini bermanfaat bagi Anda.

Source: https://habr.com/ru/post/id472024/

More articles:


All Articles