Di dunia saat ini, aplikasi sangat diminati yang mampu memenuhi kepentingan semua pihak secara efektif. Seringkali ini diterapkan dengan menggunakan berbagai jenis pembatasan. Misalnya, mereka tidak mengizinkan pengguna untuk melakukan tindakan yang akan merugikan dirinya sendiri atau pemilik sistem. Dalam hal ini, perlu untuk meminimalkan ketidaknyamanan yang disebabkan oleh pembatasan tersebut.
Misalnya, pemilik sistem memerlukan nomor telepon dalam formulir umpan balik dalam format +7 () -- untuk penggunaan otomatis lebih lanjut. Untuk kenyamanan pengguna, lebih baik menggunakan bukan hanya petunjuk atau validasi saat mengirimkan formulir, tetapi juga masker input yang mengecualikan memasukkan data dalam format yang salah. Ternyata, dan serigala penuh, dan domba-domba masih utuh.
Dalam beberapa kasus, sistem membatasi pengguna untuk melindungi dari kemungkinan kerugian. Jadi, misalnya, seperti mengenakan sabuk pengaman sebelum mengemudi, dalam layanan pembayaran online Anda tidak hanya perlu memasukkan data dari kartu, tetapi juga mengkonfirmasi pembayaran dengan kode dari pesan SMS, yang secara signifikan mengurangi kemungkinan pencurian uang. Dan harus dicatat bahwa kepedulian terhadap keselamatan pengguna seperti itu bermanfaat bagi pemilik layanan, karena mengurangi risiko reputasi, jika tidak maka akan muncul seperti dalam karya Alexei Apukhtin: "... apakah ia mencuri atau dicuri darinya ... Hal utama adalah bahwa ia terlibat dalam hal yang jahat ... ".
Jadi, ketika mengembangkan aplikasi, perlu untuk memikirkan fungsionalitas sedemikian rupa untuk menyenangkan pelanggan langsung dan pengguna rata-rata. Dengan mengingat hal ini, lima tingkat keterbatasan sistem dapat dibedakan:
- Tidak ada cara untuk membatasi pengguna , yaitu mengandalkannya untuk tidak melakukan kesalahan dan tidak membahayakan dirinya sendiri atau pemilik sistem.
- Batasi sebagian - pengguna dapat melakukan kesalahan, tetapi kecil kemungkinannya (atau kurang serius).
- Memperkenalkan pembatasan yang diperlukan , tetapi tidak berlebihan - pengguna sangat terbatas sehingga ia tidak dapat membuat kesalahan, tetapi pembatasan tidak menimbulkan masalah dalam menggunakan sistem. Ini adalah opsi yang ideal.
- Tidak perlu membatasi - pengguna dibatasi sehingga mencegahnya menggunakan sistem.
- Batasi pengguna sepenuhnya , mis. Memblokir fitur.
Pada tingkat pertama dan kelima, contoh yang akrab adalah situasi yang sudah dikenal ketika seorang kasir berteriak "Galya, batal!" Di toko dan Galya yang mahakuasa datang untuk menyelamatkan. Dalam hal ini, kasir telah sepenuhnya memblokir fungsi mengeluarkan barang berlubang dari cek, dan Gali tidak memiliki batasan pada operasi ini. Artinya, derajat pembatasan ini sering dapat digunakan sebagai bagian dari implementasi model peran.
Dan dalam kasus ketika kita tidak berbicara tentang ekstrem, salah satu opsi perantara dibuat dalam sistem. Dan kemudian tugas penting dari setiap proyek adalah untuk memperkenalkan semua pembatasan yang diperlukan, tetapi tidak berlebihan (tingkat ketiga). Jadi, misalnya, tidak pada setiap tahap mengisi aplikasi untuk mengisi captcha (tingkat keempat), tetapi hanya sebelum mengirim formulir lengkap. Atau agar bidang input ponsel tidak hanya berisi masker input (level kedua), tetapi juga tanda centang bahwa pengguna telah memasukkan 11 digit nomor.
Kami memberi contoh. Kami memiliki proyek untuk mengembangkan aplikasi untuk menemani proses pengumpulan (selanjutnya - perangkat lunak Kolektor). Sebagai bagian dari awal proyek, kami menyusun dan menyetujui persyaratan referensi, setelah itu sebagian besar pekerjaan analis selesai. Perlu dicatat bahwa pelanggan adalah perusahaan yang baru mulai menagih utang, yaitu, ternyata kemudian, prosesnya masih dalam tahap debugging.
Dan pada saat itu, ketika pengembangan proyek sudah sekitar enam bulan, informasi baru diterima tentang fitur pekerjaan pengguna potensial sistem, serta tentang perbaikan yang direncanakan. Harus segera dicatat bahwa pada saat itu, kami menerapkan tugas-tugas fungsional berikut, termasuk:
- menugaskan tugas untuk melakukan panggilan ke debitur;
- implementasi tugas yang ditugaskan;
- memperbaiki hasil interaksi (secara manual oleh pengguna);
- memastikan kepatuhan dengan persyaratan undang-undang Federasi Rusia tentang frekuensi interaksi dengan debitur 1 .
Mari kita perjelas bahwa fungsi terakhir yang tercantum adalah sebagai berikut: Perangkat lunak kolektor membatasi kemungkinan penugasan tugas yang berpotensi melanggar persyaratan hukum. Dalam hal ini, jika tidak mungkin untuk melewati (pengguna menetapkan hasil panggilan yang sesuai), tugas ditunda dan operator dapat kembali ke sana nanti. Artinya, upaya dial-up yang gagal tidak dapat dianggap sebagai interaksi, dan Anda dapat mencoba menyelesaikan tugas lagi.
Apa yang diketahui tentang fitur-fitur pengalaman pengguna? Ternyata dalam kasus upaya yang gagal untuk mencapai ponsel debitur, operator tidak hanya akan menunda tugas, tetapi juga, jika ada nomor lain yang diberikan kepada debitur, segera coba untuk menghubungi mereka.
Mengingat tenggat waktu yang ketat, tidak praktis untuk kembali membenamkan analis dalam proyek, sehingga spesialis QA kami mendapat tugas untuk mempertimbangkan apakah implementasi yang ada konsisten dengan bagaimana aplikasi direncanakan untuk digunakan di sisi pelanggan. Selama analisis, kami membangun rantai logis berikut:
- Debitur mungkin memiliki beberapa nomor (ponsel, rumah, kantor), tetapi Anda dapat menjadwalkan panggilan hanya ke satu nomor.
- Jika operator gagal mencapai pelanggan, tugas akan ditunda, tetapi masih tidak mungkin untuk memanggil nomor lain, karena tugas yang tertunda juga akan memblokir penunjukan panggilan ke nomor lain.
- Oleh karena itu, untuk mencoba mencapai nomor lain, pengguna harus secara manual membatalkan tugas yang tertunda dan menetapkan yang baru.
- Tetapi pada saat yang sama dan nomor lainnya mungkin tidak dapat melewati. Dan kemudian tugas-tugas yang ditunda karena kurangnya panggilan, ternyata, dibatalkan sia-sia. Anda harus menunjuk mereka lagi untuk menelepon lagi nanti.
Perlu dicatat bahwa menurut informasi dari pelanggan, upaya gagal untuk melakukan panggilan cukup sering terjadi.
Selain itu, direncanakan untuk mengembangkan fungsional untuk mengintegrasikan perangkat lunak Collector dengan sistem analitik untuk penunjukan otomatis acara (selanjutnya - ASANM), yang dibuat di sisi pelanggan. Intinya adalah sebagai berikut:
- setiap hari (sekali sehari) ASANM membentuk daftar tugas yang harus dilakukan berdasarkan kontrak, dan mengirimkan permintaan ke perangkat lunak Kolektor;
- Perangkat Lunak Kolektor dari daftar yang diterima menetapkan tugas-tugas yang tidak melebihi batas interaksi.
Menurut kesimpulan dari spesialis QA, dalam implementasi yang ada, baik operator dan ASANM tidak akan dapat menjadwalkan panggilan ke semua nomor debitur.
Secara umum, ada pemahaman bahwa pembatasan tingkat keempat diterapkan (pembatasan berlebihan): untuk melakukan panggilan ke nomor lain, Anda perlu secara manual membatalkan tugas yang tertunda. Bahkan, ternyata undang-undang itu tidak membatasi jumlah upaya untuk menghubungi debitur, tetapi jumlah upaya interaksi yang berhasil. Dan ini berarti bahwa batas interaksi harus dihitung berdasarkan hasil tugas.
Dalam hal ini, kami memprakarsai perubahan dalam format implementasi dan cara yang lebih bijaksana untuk memenuhi persyaratan dipilih:
- hitung jumlah interaksi berdasarkan hasil kegiatan;
- jika batas tidak tercapai, maka izinkan pengguna / ASANM untuk menjadwalkan acara tanpa batasan;
- jika batas tercapai, maka batalkan acara yang tidak perlu dan larang janji temu mereka.
Butuh seluruh sprint untuk melakukan perubahan, tetapi kita dapat mengatakan bahwa kali ini tidak sia-sia dan sekarang karena pengguna biasa tidak akan mengalami ketidaknyamanan saat bekerja dalam aplikasi, sehingga pemilik sistem akan dapat merencanakan pekerjaan operator menggunakan ASANM.
Kesimpulan
Semua orang yang, ketika menerapkan batasan, peduli tentang pengguna dan pelanggan, disarankan untuk mematuhi dua aturan sederhana:
- “Dengan jumlah pengasuh yang cukup, anak tidak akan kehilangan matanya” - yaitu, Anda perlu melindungi pengguna secara memadai dari membuat kesalahan yang dapat membahayakan dirinya atau pemilik sistem.
- "Untuk takut pada serigala, tetapi pergi ke hutan" - perlu untuk menghindari pembatasan yang tidak perlu, karena jika tidak nilai produk yang dikembangkan untuk pengguna akan hilang.
1 Persyaratan ditetapkan oleh Undang-Undang Federal No. 03.07.2016 N 230- “Tentang Perlindungan Hak dan Kepentingan Hukum Individu ketika Melakukan Kegiatan untuk Mengembalikan Utang yang Terlambat dan tentang Mengubah Hukum Federal“ Tentang Kegiatan Keuangan Mikro dan Organisasi Keuangan Mikro ”.