Aplikasi sudah berjalan, tetapi staf gagal menyelesaikan penjualan dan kontrak hanya menyebut termasuk maintenance. Kalimat itu belum menjelaskan siapa yang memeriksa, kapan ada jawaban, atau biaya mana yang perlu disetujui terpisah. Biaya maintenance aplikasi lebih mudah dinilai ketika pekerjaan serta tanggung jawabnya terlihat. Mulailah dari kebutuhan agar bisnis tetap berjalan, lalu periksa apakah kontrak menjawab kondisi yang mungkin dihadapi tim.
Keputusan ini berbeda dari menentukan cakupan pembangunan awal. Sekarang ada pengguna yang mengandalkan sistem, termasuk catatan dan hubungan antaraplikasi yang mungkin sudah berubah setelah rilis. Gunakan keadaan aplikasi saat ini sebagai dasar pembahasan. Minta cakupan tertulis dengan jelas. Jangan menganggap seluruh masalah otomatis menjadi tanggung jawab pengembang awal tanpa memeriksa pekerjaan dan akses yang memang berada dalam kendalinya.
Daftar bagian yang membutuhkan dukungan
Tulis website pelanggan, aplikasi staf, halaman admin, layanan terhubung, dan akun hosting yang terlibat. Periksa bagian yang benar-benar dapat diakses serta dirawat oleh calon mitra. Pihak yang merawat kode aplikasi belum tentu menguasai penyedia pembayaran atau koneksi internet kantor. Kontrak perlu menjelaskan pihak yang membantu mencari sumber gangguan serta cara meneruskan pekerjaan ketika penyelesaiannya membutuhkan penyedia lain.
Daftar juga alur bisnis yang paling penting. Halaman booking yang tidak bisa dibuka berbeda dampaknya dengan kesalahan kecil pada tulisan. Jelaskan akibatnya dalam bahasa usaha: pelanggan tidak bisa memesan, staf tidak bisa mencatat pembayaran, atau label laporan membingungkan. Cara ini membantu menentukan prioritas tanpa meminta Anda menebak penyebab teknisnya. Sertakan contoh kondisi normal agar petugas dukungan memahami hasil yang seharusnya terjadi.
Pisahkan jenis pekerjaan setelah rilis
Minta penjelasan cara kontrak menangani kerusakan fungsi, pemeriksaan rutin, penyesuaian terhadap layanan lain, serta permintaan baru. Kerusakan bisa membuat fungsi yang disepakati tidak berjalan. Tahap persetujuan baru mengubah perilaku yang diminta dari aplikasi. Batas keduanya bisa diperdebatkan. Gunakan contoh dari aplikasi Anda dan sepakati cara menilai permintaan yang belum jelas sebelum pekerjaan dimulai atau biaya tambahan ditagihkan.
- Pemeriksaan dan pembaruan terjadwal apa yang termasuk?
- Kesalahan apa yang masih masuk garansi atau kesepakatan lain?
- Bagaimana perubahan dari penyedia terhubung diperiksa?
- Pekerjaan apa yang membutuhkan penawaran dan persetujuan terpisah?
- Siapa yang memeriksa pembaruan sebelum dipakai pengguna sehari-hari?
Pisahkan tagihan hosting dari pekerjaan perawatan
Hosting menyediakan tempat aplikasi berjalan. Maintenance mencakup pekerjaan yang disepakati untuk aplikasi dan lingkungan operasionalnya. Penawaran boleh menggabungkan keduanya, tetapi tanggung jawabnya tetap perlu dijelaskan. Tanyakan tagihan yang langsung dibayar kepada pihak lain serta tindakan ketika pemakaian berubah. Perpanjangan hosting saja belum membuktikan ada orang yang memeriksa kesalahan atau memastikan alur penting tetap berfungsi setelah perubahan dilakukan.
Baca batas waktu respons dengan jelas
Kesepakatan waktu respons berarti komunikasi mulai dilakukan dalam kondisi yang ditentukan. Itu belum otomatis menjadi batas waktu layanan kembali normal. Tanyakan arti setiap target, kapan waktu mulai dihitung, jam yang termasuk, dan cara melaporkan gangguan mendesak. Pesan dalam percakapan informal belum tentu masuk ke antrean dukungan yang digunakan untuk mencatat kejadian. Jalur pelaporan perlu diketahui staf sebelum ada masalah.
Gunakan contoh yang dekat dengan kegiatan Anda: halaman pesanan berhenti bekerja di luar jam kantor. Siapa yang menerima pemberitahuan, siapa yang dapat memilih cara kerja sementara, dan kapan pemilik mendapat kabar lanjutan? Tanyakan bagian yang bergantung pada penyedia lain. Catat cakupan yang dijanjikan secara tertulis. Jangan menganggap dukungan sepanjang waktu sudah termasuk hanya karena penawaran menyebut layanan prioritas.
Sepakati tanggung jawab pemulihan
Jika pembaruan menimbulkan masalah, tentukan pihak yang boleh menghentikannya atau kembali ke versi sebelumnya. Tanyakan penanganan perubahan data selama keputusan tersebut diambil. Mengembalikan kode aplikasi belum menjelaskan nasib pesanan yang dibuat setelah rilis. Rencana dukungan perlu melibatkan orang yang bertanggung jawab atas catatan usaha. Jangan sampai keputusan teknis memulihkan tampilan tetapi meninggalkan transaksi baru tanpa pemeriksaan dan tindak lanjut.
Bahas cadangan data dengan pertanyaan yang sama praktisnya. Catatan apa yang termasuk, siapa yang boleh meminta pemulihan, dan di mana bukti pemeriksaan pemulihan disimpan? Tentukan cara staf bekerja saat akses terhenti serta cara mencocokkan catatan sementara sesudahnya. Semua itu adalah pertanyaan cakupan kontrak. Pernyataan bahwa cadangan tersedia belum cukup menjelaskan tindakan yang harus dijalankan ketika bisnis benar-benar kehilangan akses.
Minta bukti pekerjaan yang dilakukan
Sepakati laporan singkat yang bisa Anda pahami. Isinya dapat berupa pemeriksaan selesai, pembaruan diterapkan, gangguan ditangani, risiko yang belum selesai, dan keputusan yang menunggu persetujuan Anda. Minta hasil serta bukti yang relevan, bukan daftar istilah teknis. Jika pembaruan ditunda, laporan perlu menjelaskan alasan dan keputusan berikutnya. Dengan begitu Anda dapat menilai pekerjaan tanpa harus memahami seluruh rincian kode aplikasi.
Catat gangguan berulang secara terpisah dari permintaan satu kali. Jika staf terus melaporkan kegagalan yang sama, tanyakan apakah dukungan hanya mengembalikan layanan atau juga menangani penyebabnya. Perbaikan lebih lanjut mungkin perlu persetujuan terpisah. Perbedaan ini perlu terlihat agar biaya rutin tidak menyembunyikan daftar masalah yang terus bertambah tanpa keputusan pendanaan atau prioritas. Tentukan siapa yang membawa masalah berulang ke pembahasan berikutnya.
Sesuaikan kontrak dengan kebutuhan operasional
Bandingkan penawaran berdasarkan daftar aplikasi, jam kerja, dan contoh gangguan yang sama. Cakupan terbatas mungkin cukup untuk alat yang bisa menunggu, sedangkan alur penjualan penting membutuhkan pengaturan berbeda. Tidak ada persentase biaya pembangunan yang cocok untuk semua aplikasi. Minta mitra menjelaskan pekerjaan dan dasar perkiraan dalam penawarannya. Gunakan kebutuhan nyata, bukan angka umum yang belum diperiksa terhadap sistem Anda.
Sebelum memperpanjang kontrak, periksa kepemilikan akun, dokumentasi, dan cara menyerahkan pekerjaan kepada tim lain. Tetapkan kontak bisnis yang dapat menyetujui perubahan serta menjelaskan dampak operasional. Bawa kontrak dan gangguan terbaru saat membahas layanan pengembangan aplikasi. Bicarakan dengan Loomora batas dukungan yang perlu diperjelas untuk bisnis Anda.
