Menangani pengecualian dunia nyata saat Anda membangun aplikasi

Mengapa alur aplikasi yang bersih gagal dalam praktik

Diagram alur yang rapi terlihat bagus karena berasumsi orang melakukan semuanya dengan urutan yang benar, data yang lengkap, dan pada waktu yang tepat. Kerja nyata jarang seperti itu. Seseorang mengirim formulir terlambat, manajer sedang sakit, pelanggan lupa detail penting, atau pembayaran memerlukan persetujuan khusus yang tidak disebutkan di awal.

Itulah mengapa versi pertama sebuah aplikasi terasa selesai saat demo, lalu mulai bermasalah ketika orang nyata menggunakannya. Jalur yang ideal berfungsi. Pekerjaan sehari-hari tidak bertahan lama di jalur itu.

Mulai dari asumsi bahwa versi rapi itu tidak lengkap adalah langkah paling aman. Sebuah permintaan sederhana bisa berubah cepat ketika satu detail kecil tidak ada. Satu field yang hilang, satu pelanggan tidak biasa, atau satu persetujuan yang terlambat bisa menghentikan seluruh proses dan membuat orang tidak tahu harus berbuat apa.

Kegagalan umum biasanya sederhana:

• Sebuah permintaan bergerak maju, lalu tersendat karena penentu persetujuan tidak tersedia.
• Sebuah catatan tidak bisa disimpan karena detail wajib belum diketahui.
• Kasus khusus diperlakukan seperti kasus normal dan harus diperbaiki secara manual kemudian.

Ini lebih dari sekadar gangguan kecil. Satu kasus aneh bisa memblokir semuanya di belakangnya. Staf mulai menggunakan jalan pintas lewat chat, spreadsheet, atau email, dan aplikasi berhenti menjadi tempat tunggal untuk bekerja.

Tujuan yang lebih baik sederhana: kumpulkan pengecualian sebelum Anda menulis aturan. Tanyakan apa yang terjadi ketika data hilang, ketika waktu tidak sesuai, dan ketika sebuah permintaan tidak cocok dengan jalur standar. Contoh berantakan itu bukan detail sampingan. Mereka yang menentukan apakah aplikasi Anda berfungsi di dunia nyata.

Pengecualian mana yang harus ditemukan terlebih dahulu

Masalah pertama yang perlu ditangkap bukanlah kasus langka. Mereka adalah kejadian berantakan yang terjadi setiap minggu dan diam-diam merusak alur kerja yang rapi. Jika Anda ingin versi pertama yang lebih kuat, cari tempat-tempat di mana pekerjaan tertunda, terblokir, atau diserahkan ke orang karena sistem tidak bisa memutuskan.

Persetujuan terlambat biasanya ada di puncak daftar. Seorang manajer menyetujui permintaan setelah tenggat, setelah penutupan penggajian, atau setelah stok sudah dipesan ulang. Aplikasi perlu aturan untuk momen itu. Haruskah aplikasi membuka kembali permintaan, membuat permintaan baru, memberi tahu keuangan, atau mengirimnya untuk review alih-alih berpura-pura persetujuan datang tepat waktu?

Data yang hilang adalah penghambat umum lainnya. Sebuah formulir bisa dikirim tanpa nomor pajak, tanda terima, tanggal pengiriman, atau kontak pelanggan. Jika langkah berikutnya bergantung pada field itu, alur seharusnya tidak gagal dengan error yang samar. Alur harus berhenti sementara, menunjukkan apa yang hilang, dan mempermudah perbaikan.

Kasus khusus penting karena mereka menunjukkan batas jalur normal. Mungkin sebagian besar pengembalian dana sederhana, tetapi pengembalian di atas jumlah tertentu memerlukan bukti tambahan. Mungkin satu departemen mengikuti aturan persetujuan yang berbeda. Kasus-kasus ini tidak perlu aplikasi baru, tetapi mereka perlu percabangan yang jelas.

Langkah awal yang berguna adalah mencari empat pola: persetujuan yang datang terlambat sehingga tidak mengikuti rute awal, detail yang hilang yang menghalangi aksi berikutnya, permintaan tidak biasa yang memerlukan aturan berbeda, dan momen ketika sistem harus berhenti dan meminta orang.

Tinjauan manusia bukanlah kegagalan. Seringkali itu pilihan paling aman ketika aplikasi melihat data yang bertentangan, pengecualian kebijakan, atau tindakan bernilai tinggi. Antrian review yang dijeda biasanya lebih baik daripada kesalahan yang diam-diam terjadi.

Jika Anda menemukan pengecualian ini sejak awal, versi pertama akan terasa jauh lebih nyata dan jauh lebih tidak rapuh.

Di mana mengumpulkan contoh nyata

Cara tercepat melewatkan pengecualian buruk adalah hanya bertanya pada manajer yang merancang proses. Masalah nyata biasanya ada pada orang yang melakukan pekerjaan setiap hari. Mereka tahu langkah mana yang sering dilewati, field mana yang sering kosong, dan persetujuan mana yang sering terlambat, tidak berurutan, atau di luar sistem.

Mulailah dengan percakapan singkat. Minta orang-orang itu menjelaskan kasus normal, lalu tanyakan apa yang berubah terakhir kali saat semuanya berantakan. Jangan minta pendapat luas tentang proses. Minta cerita nyata: apa yang terjadi, apa yang hilang, siapa yang memperbaikinya, dan apa yang mereka lakukan secara manual.

Pekerjaan lama adalah sumber yang baik. Email lama, tiket dukungan, pesan chat, dan catatan serah terima sering menunjukkan momen tepat ketika alur rapi rusak. Catatan ini berguna karena menangkap bahasa yang dipakai orang saat sesuatu salah, bukan versi yang dipoles dari dokumen proses.

Periksa juga alat yang digunakan orang di samping sistem utama. Jika seseorang menyimpan spreadsheet, daftar sticky-note, atau dokumen pribadi untuk melacak pengecualian, itu sinyal kuat. Jalan pintas ada dengan alasan. Mereka sering mengungkap aturan yang aplikasi Anda perlukan sejak hari pertama.

Sumber terbaik untuk ditinjau dulu biasanya sistem bayangan seperti spreadsheet dan checklist pribadi, thread email di mana orang meminta detail yang hilang atau persetujuan manual, percakapan chat tentang perbaikan mendesak, tiket dukungan yang menyebut keterlambatan atau entri ditolak, dan beberapa kasus terakhir yang gagal dengan garis waktu lengkap.

Sumber terakhir ini lebih berharga daripada kelihatannya. Kasus gagal yang baru biasanya lebih baik daripada ringkasan lama karena mereka menunjukkan rantai kejadian secara tepat. Anda mungkin menemukan pola seperti persetujuan tiba setelah tenggat, pelanggan tidak pernah mengirim file yang diperlukan, atau seseorang memakai aturan khusus yang tidak terdokumentasi.

Jika Anda sedang membuat versi awal di pembuat berbasis chat, kumpulkan contoh-contoh ini sebelum menghasilkan logika. Jauh lebih mudah membangun alur yang aman ketika kasus berantakan terlihat sejak awal.

Cara mengubah cerita berantakan menjadi logika aplikasi

Mulailah dengan satu kasus nyata, bukan teori. Tulis seperti cara orang menjelaskannya ke rekan: apa yang mereka coba lakukan, apa yang salah, siapa yang turun tangan, dan bagaimana akhirnya.

Cerita berantakan seperti "permintaan tersendat karena manajer sedang cuti, lalu keuangan menyetujuinya kemudian dengan satu field yang hilang" lebih berguna daripada diagram alur yang rapi. Itu menunjukkan titik-titik di mana aplikasi biasanya rusak.

Dari cerita ke aturan

Untuk setiap kasus, ambil empat fakta: apa yang terjadi, siapa yang membuat keputusan, mengapa mereka melakukannya, dan apa yang harus dilakukan aplikasi selanjutnya.

Itu menjaga fokus pada perilaku, bukan hanya tampilan. Tujuannya bukan menutupi setiap kasus aneh pada hari pertama. Tujuannya adalah menemukan pola yang bisa diulang.

Setelah Anda memiliki beberapa cerita, kelompokkan yang terasa mirip. Ember sederhana biasanya muncul sendiri: persetujuan terlambat, informasi hilang, orang yang salah diminta, permintaan duplikat, atau persetujuan khusus di atas batas tertentu.

Lalu ubah setiap kelompok menjadi aturan paling ringan yang bekerja. Aturan itu tidak selalu perlu otomatisasi penuh. Kadang pilihan terbaik adalah peringatan, jeda, atau langkah review manual.

Contohnya, jika persetujuan terlambat karena penentu sedang tidak ada, aplikasi mungkin mengirim pengingat setelah 24 jam, menugaskan ulang setelah 48 jam, atau meminta peninjau cadangan. Jika field penting hilang, opsi terbaik bisa berupa fitur simpan-dan-kembali sebagai draft daripada menghentikan paksa. Itu membuat proses tetap berjalan tanpa menyembunyikan masalah.

Jika Anda membangun di alat berbasis chat seperti Koder.ai, kasus berbahasa biasa sangat membantu. Mereka memberi sistem sesuatu yang konkret untuk dikerjakan, sehingga alur pertama didasarkan pada keputusan nyata, bukan tebakan yang rapi tapi tidak realistis.

Uji dengan kasus nyata

Sebelum mengunci logika, jalankan dua atau tiga cerita nyata melaluinya. Tanyakan beberapa pertanyaan dasar. Apakah alur mencapai hasil yang sama seperti kasus nyata? Apakah alur gagal dengan aman ketika informasi hilang? Apakah alur tahu kapan harus berhenti dan meminta manusia?

Jika jawabannya tidak, jangan menambah kompleksitas langsung. Tulis ulang aturannya dengan kata-kata yang lebih sederhana terlebih dahulu. Aturan yang jelas biasanya menghasilkan alur kerja yang lebih baik daripada aturan cerdas yang tidak bisa dijelaskan.

Contoh sederhana: persetujuan pengeluaran

Mulai dengan versi rapi. Seorang karyawan mengajukan pengeluaran taksi $42 setelah menemui klien. Mereka menambahkan tanggal, jumlah, nama proyek, dan tanda terima. Manajer menyetujuinya sebelum cutoff penggajian, dan bagian keuangan memasukkannya ke pembayaran berikutnya.

Jalur itu mudah dimodelkan, tetapi itu bukan keseluruhan tugas.

Sekarang tambahkan pengecualian pertama. Karyawan mengirim tepat waktu, tetapi manajer menyetujuinya sehari setelah penggajian ditutup. Aplikasi tidak boleh diam-diam memprosesnya seolah tidak terjadi apa-apa, dan juga tidak harus langsung menolak klaim.

Respons yang lebih baik adalah memindahkan permintaan ke status jelas seperti "disetujui setelah cutoff." Dari sana, aplikasi bisa menahan pembayaran untuk siklus penggajian berikutnya, memberi tahu karyawan tentang tanggal pembayaran baru, dan mengarahkan kasus ke keuangan hanya jika kebijakan perusahaan mengizinkan pembayaran di luar siklus.

Itu berarti aplikasi perlu menyimpan lebih dari satu tanggal. Aplikasi harus melacak kapan pengeluaran diajukan, kapan disetujui, dan cutoff mana yang terlewat.

Sekarang tambahkan pengecualian kedua. Karyawan lupa tanda terima, sehingga manajer menyetujui berdasarkan penjelasan saja. Dua hari kemudian, tanda terima datang.

Jika aplikasi dibangun dengan baik, kasus tidak hilang atau mulai dari nol lagi. Kasus pindah ke status "menunggu tanda terima", mengirim pengingat, dan tetap terbuka. Saat tanda terima diunggah nanti, aplikasi membuka kembali kasus dan hanya mengirimkannya ke langkah yang masih perlu tindakan.

Alur seperti ini mungkin lewat beberapa status sederhana: diajukan, menunggu persetujuan manajer, disetujui setelah cutoff, ditahan karena tanda terima hilang, dan dibuka kembali untuk review keuangan.

Itulah tampilan penanganan pengecualian nyata dalam praktik. Aplikasi bukan hanya memutuskan ya atau tidak. Aplikasi memutuskan apakah menahan, meroute, atau membuka kembali kasus tanpa kehilangan konteks, tanggal, atau tanggung jawab.

Cara menangani data yang hilang tanpa merusak alur

Informasi yang hilang itu normal, bukan kasus pinggiran yang jarang. Jika aplikasi Anda mengasumsikan setiap formulir akan lengkap pada percobaan pertama, alur akan macet begitu pengguna nyata menemui kekosongan. Aturan yang lebih baik sederhana: hanya minta apa yang diperlukan untuk langkah berikutnya.

Rencanakan langkah demi langkah. Tanyakan apa yang harus diketahui aplikasi sekarang, dan apa yang bisa menunggu. Sebuah permintaan pengeluaran mungkin memerlukan jumlah dan nama karyawan sebelum bisa diajukan, tetapi tanda terima akhir mungkin hanya diperlukan sebelum pembayaran. Itu membuat pekerjaan tetap bergerak tanpa menurunkan kontrol.

Buat pekerjaan tidak lengkap terlihat

Pengguna harus bisa menyimpan progres meskipun beberapa detail hilang. Draft yang bisa dibuka kembali jauh lebih baik daripada formulir yang memaksa orang mulai dari awal. Ini lebih penting ketika informasi yang hilang tergantung pada orang lain, seperti manajer, vendor, atau tim keuangan.

Status yang jelas membantu semua orang memahami apa yang terjadi. Buat singkat dan mudah dipindai: menunggu info, terblokir karena dokumen hilang, butuh review, siap untuk persetujuan, dikirim kembali untuk pembaruan.

Label-label ini melakukan dua pekerjaan sekaligus. Mereka menunjukkan status saat ini, dan memberi tahu pengguna jenis masalah yang perlu diatasi.

Setiap item yang hilang juga perlu pemilik. Jika nomor pajak hilang, siapa yang menambahkannya? Jika tanda terima buram, siapa yang menggantinya? Jika catatan persetujuan absen, siapa yang dapat menyediakannya? Ketika tidak ada pemilik untuk perbaikan, catatan terjebak di limbo.

Contoh sederhana membuatnya jelas. Bayangkan karyawan mengajukan biaya perjalanan tanpa tanda terima karena hotel belum mengirimkannya. Aplikasi tetap harus memungkinkan mereka menyimpan dan mengajukan permintaan dengan status seperti "menunggu tanda terima." Keuangan dapat meninjau sisanya, karyawan tahu apa yang hilang, dan permintaan tidak hilang ke dalam error yang diam-diam.

Kapan otomatisasi dan kapan minta manusia

Otomatisasi bekerja terbaik ketika input yang sama hampir selalu menghasilkan hasil yang sama. Jika sebuah permintaan mengikuti pola jelas, buatkan aturannya. Jika jawabannya bergantung pada konteks yang hilang, waktu yang tidak biasa, atau penilaian, kirim ke orang.

Pemisahan ini penting. Aplikasi yang baik harus bergerak cepat pada kasus normal dan melambat pada yang tidak jelas. Keputusan otomatis yang salah bisa menciptakan lebih banyak pekerjaan daripada review manual singkat.

Tes sederhana membantu: apakah dua anggota tim berbeda akan membuat pilihan yang sama dari data yang sama? Jika ya, otomatisasikan. Jika tidak, pertahankan manusia dalam loop.

Kandidat bagus untuk otomatisasi adalah formulir lengkap dengan semua field wajib, permintaan yang sesuai batas kebijakan, tindakan berulang dengan tenggat yang jelas, dan persetujuan yang selalu mengikuti jalur yang sama.

Beberapa situasi sebaiknya tidak ditebak sama sekali: detail kunci hilang, permintaan memecah pola normal, dua aturan bertentangan, biaya atau risikonya tinggi, atau seseorang perlu menjelaskan pengecualian.

Bayangkan permintaan perjalanan tanpa tujuan, tanggal mendesak, dan biaya di atas batas biasa. Aplikasi tidak seharusnya mencoba pintar-pintar. Aplikasi harus menandai kasus, menghentikan alur, dan mengarahkannya ke orang yang tepat.

Sama pentingnya, simpan alasan setiap pengecualian terlihat. Tunjukkan mengapa aplikasi berhenti, aturan mana yang dipicu, dan informasi apa yang hilang. Itu mempercepat review dan membantu tim memperbaiki alur kerja kemudian.

Kesalahan umum yang harus dihindari

Banyak proyek aplikasi salah sebelum ada logika yang ditulis. Tim menggambar jalur rapi, berasumsi orang akan mengikutinya, dan mengabaikan kasus aneh yang terjadi setiap minggu. Begitulah alur sederhana berubah menjadi tiket dukungan, perbaikan manual, dan pengguna yang bingung.

Kesalahan pertama adalah merancang hanya dari asumsi. Jika Anda menebak bagaimana persetujuan, field yang hilang, atau pengecualian biasanya bekerja, Anda akan melewatkan kasus yang paling penting. Seorang manajer menyetujui terlambat, catatan pelanggan datang setengah lengkap, atau pembayaran perlu review ekstra karena jumlahnya tidak biasa.

Kesalahan lain adalah menyembunyikan banyak situasi berbeda dalam satu aturan samar. Aturan seperti "kirim ke admin jika sesuatu terlihat salah" terdengar fleksibel, tetapi menciptakan masalah baru. Siapa admin? Apa yang dihitung sebagai salah? Apa yang terjadi jika tidak ada yang merespons selama dua hari?

Ini juga merugikan pengguna ketika aplikasi memaksa restart total. Jika satu dokumen hilang atau seorang penentu menolak sebuah langkah, orang seharusnya tidak perlu memasukkan semua data dari awal. Alur yang lebih baik menyimpan progres, menandai masalah, dan membiarkan pengguna memperbaiki hanya bagian yang terblokir.

Masalah lain mudah terlewatkan karena terdengar sekunder: waktu, kepemilikan, dan histori. Mereka bukan sekunder. Jika persetujuan datang setelah tenggat, aplikasi perlu tahu apakah menerima, mengeksekusi eskalasi, atau membuka kembali permintaan. Jika sebuah kasus terblokir, seseorang harus menanggung tindakan berikutnya. Jika status berubah, orang perlu melihat siapa yang mengubah dan mengapa.

Riwayat audit penting untuk alasan sederhana. Orang perlu tahu siapa yang mengubah nilai, siapa yang menyetujui pengecualian, dan kapan status berpindah.

Pemeriksaan cepat sebelum Anda menghasilkan logika

Sebelum Anda mengubah alur menjadi aturan, berhenti dan periksa apakah input Anda sesuai dengan kerja nyata. Diagram rapi sering melewatkan kasus aneh yang menyebabkan keterlambatan, kebingungan, atau perbaikan manual kemudian.

Tinjauan singkat membantu:

• Mulai dengan contoh nyata, bukan tebakan.
• Namai setiap pengecualian dalam satu kalimat singkat.
• Tentukan siapa yang memegang kasus yang terblokir.
• Periksa bagaimana pengguna pulih dari informasi yang hilang.
• Uji satu skenario realistis dari awal sampai akhir.

Kasus uji sederhana sering cukup untuk mengekspos logika lemah. Bayangkan permintaan pembelian diajukan tanpa nama pemasok, lalu disetujui terlambat oleh pimpinan departemen. Bisakah pemohon memperbaiki field yang hilang? Apakah aplikasi tahu untuk membuka kembali permintaan, melanjutkan, atau meminta keuangan meninjau?

Itulah tingkat detail yang Anda inginkan sebelum menghasilkan logika. Cerita singkat dan nyata menghasilkan versi pertama yang lebih aman dan lebih sedikit kejutan ketika orang mulai memakai aplikasi.

Langkah berikutnya untuk versi pertama yang lebih aman

Mulai kecil. Pilih satu alur kerja, bukan seluruh bisnis. Kumpulkan lima kasus pengecualian nyata dari orang yang melakukan pekerjaan setiap hari, misalnya persetujuan terlambat, tanda terima hilang, manajer cuti, permintaan duplikat, atau kasus yang perlu campur tangan keuangan.

Bangun versi pertama di sekitar alur sempit itu dan kelima kasus tersebut. Buat aturannya mudah dibaca. Jika permintaan tidak lengkap, tunjukkan apa yang hilang. Jika persetujuan terlambat, tentukan kapan mengingatkan, kapan eskalasi, dan kapan jeda. Jika kasus tidak cocok dengan jalur normal, jelaskan siapa yang perlu meninjaunya.

Lalu uji dengan orang yang terlibat: pengaju, penyetuju pertama, orang yang memperbaiki pengecualian, manajer yang menerima eskalasi, dan siapa saja yang melihat hasil akhir.

Perhatikan di mana mereka berhenti, menebak, atau meminta bantuan. Momen-momen itu lebih penting daripada yang berjalan mulus. Jika tiga orang terhenti di langkah yang sama, aturan atau layar perlu diubah.

Aplikasi pengeluaran mungkin bekerja baik sampai seseorang mengirim tanda terima taksi tanpa kode proyek atau mengirimnya setelah cutoff bulanan. Versi pertama Anda tidak perlu menyelesaikan setiap kasus langka. Ia perlu menangkap pengecualian umum, menjelaskan langkah selanjutnya, dan meninggalkan jalur jelas untuk review manusia.

Kemudian ubah aturan dalam putaran kecil. Hapus langkah yang menciptakan kebingungan. Tambah field hanya saat mereka mencegah masalah berulang. Ubah timing persetujuan jika pengingat terlalu awal atau terlambat. Perubahan kecil setelah pengujian nyata biasanya lebih baik daripada menambahkan logika kasus khusus yang kompleks terlalu cepat.

Jika Anda ingin prototipe cepat, pembuat berbasis chat seperti Koder.ai bisa membantu mengubah contoh-contoh nyata ini menjadi aplikasi bekerja langkah demi langkah. Kuncinya tetap sama: mulai dari cerita berantakan dulu, lalu bangun aturan di sekitarnya.