# Peran Klien dalam Proyek Aplikasi: dari Kickoff sampai Dipakai Tim

Sumber: https://digipro.id/blog/peran-klien-proyek-aplikasi
Penulis: Tim Digipro (Digipro)
Kategori: Aplikasi Custom
Terbit: 31 Oktober 2026

> Peran klien dalam proyek aplikasi dan manajemen proyek aplikasi dari sisi pemesan: siapa yang harus terlibat, apa yang dilakukan saat kickoff, demo, revisi, UAT, serah terima, dan pelatihan pengguna.

## Ringkasan singkat

- Peran klien dalam proyek aplikasi ada tiga: memberi keputusan dengan cepat, menyediakan bahan kerja (contoh alur, dokumen, dan data), dan menguji dengan pengguna sungguhan. Penyedia membangun; Andalah yang tahu apa yang benar untuk pekerjaan Anda.
- Tunjuk satu penanggung jawab proses di sisi Anda yang bisa memutuskan. Pertanyaan yang menunggu berhari-hari adalah penyebab keterlambatan yang paling sering, bukan kerumitan teknis.
- Libatkan pengguna harian sejak demo pertama. Masukan yang spesifik ('kolom ini harus bisa diisi dari ponsel') jauh lebih berguna daripada kesan umum ('kurang bagus').
- Bedakan tiga hal: perbaikan kesalahan, penyesuaian dalam lingkup yang disepakati, dan permintaan baru. Ketiganya diperlakukan berbeda dalam waktu dan biaya.
- Aplikasi baru berhasil bila dipakai. Rencanakan UAT, pelatihan, tanggal berhenti memakai cara lama, dan serah terima akses sebelum aplikasi dinyatakan selesai.

Peran klien dalam proyek aplikasi adalah menyediakan tiga hal tepat waktu: keputusan, bahan kerja, dan pengujian oleh pengguna sungguhan. Software house membangun aplikasinya, tetapi hanya Anda dan tim yang tahu apa yang benar untuk pekerjaan sehari-hari. Proyek aplikasi yang tersendat jarang disebabkan kode yang sulit. Lebih sering penyebabnya pertanyaan yang menunggu jawaban berhari-hari, data contoh yang belum siap, atau pengguna yang baru melihat aplikasinya di hari terakhir.

Artikel ini ditulis oleh Digipro, agensi digital di Malang yang membuat aplikasi web custom untuk perusahaan. Kami membahas manajemen proyek aplikasi dari sisi pemesan, bukan dari sisi pengembang: pembagian tugas antara Anda dan penyedia, tiga peran yang perlu ada di sisi Anda, apa yang terjadi saat kickoff, cara memberi masukan yang berguna di demo, cara membedakan revisi dan permintaan baru, pengujian penerimaan pengguna (UAT), serah terima dan pelatihan, sampai kesalahan yang paling sering membuat proyek molor.

## Kenapa keterlibatan klien menentukan hasil proyek aplikasi

Aplikasi internal dibuat untuk pekerjaan yang hanya dipahami penuh oleh orang yang menjalankannya. Penyedia yang baik bertanya, mengamati, dan mengusulkan, tetapi tidak bisa menebak aturan tak tertulis di perusahaan Anda: kenapa pesanan tertentu harus disetujui dua orang, kenapa satu pelanggan ditagih berbeda, atau kenapa laporan harus keluar sebelum pukul tertentu. Aturan seperti ini hanya muncul bila orang yang tepat hadir saat aplikasi dibahas.

Keterlibatan yang kurang biasanya tidak langsung terlihat. Gejalanya muncul belakangan, dan biayanya lebih mahal karena sudah banyak yang dibangun di atas asumsi yang keliru.

- Keputusan yang lambat membuat pekerjaan berikutnya berhenti. Satu pertanyaan kecil yang menunggu seminggu bisa menggeser seluruh jadwal demo.
- Bahan yang tidak lengkap membuat aplikasi diuji dengan data buatan. Aplikasi tampak berjalan sampai bertemu data asli yang tidak serapi contoh.
- Pengguna yang tidak dilibatkan menemukan masalah di hari pertama pemakaian, saat memperbaikinya paling mahal dan paling mengganggu.
- Tidak ada yang merasa memiliki aplikasi. Setelah selesai, tidak ada yang mendorong tim memakainya, dan kebiasaan lama kembali.

Kabar baiknya, waktu yang diminta dari tim Anda tidak banyak. Yang dibutuhkan adalah ketepatan: orang yang tepat, pada waktu yang tepat, dengan bahan yang tepat. Gambaran urutan kerja dari konsultasi sampai dukungan berkelanjutan ada di artikel [tahapan pembuatan aplikasi custom](https://digipro.id/blog/tahapan-pembuatan-aplikasi-custom); artikel ini mengisi sisi yang jarang dibahas di sana, yaitu apa persisnya bagian Anda di setiap tahap.

## Manajemen proyek aplikasi: pembagian tugas klien dan penyedia

Manajemen proyek aplikasi yang sehat membuat pembagian tanggung jawab terlihat jelas sejak awal. Tabel berikut merangkum siapa memimpin apa di setiap kegiatan utama. Pembagian ini saran praktis, bukan standar baku, dan bisa bergeser sesuai ukuran perusahaan dan proyek.

| Kegiatan | Bagian Anda (klien) | Bagian penyedia |
| --- | --- | --- |
| Menetapkan tujuan | Menjelaskan masalah, siapa yang terdampak, dan tanda bahwa aplikasi berhasil | Menggali lebih dalam dan memastikan tujuannya bisa dicapai dengan aplikasi |
| Alur kerja | Menceritakan alur sebenarnya, termasuk jalan pintas dan pekerjaan di luar sistem | Memetakan, merapikan, dan mengusulkan bentuk aplikasinya |
| Prioritas fitur | Memutuskan mana yang harus ada di versi pertama dan mana yang menyusul | Menjelaskan konsekuensi waktu dan biaya dari setiap pilihan |
| Data dan akses | Menyediakan contoh data, dokumen, dan akses ke sistem lain yang harus tersambung | Menyiapkan cara memindahkan data dan menyambung sistem |
| Pembangunan | Menjawab pertanyaan dengan cepat dan menyetujui keputusan yang tertunda | Membangun, menguji secara teknis, dan memperlihatkan hasil di demo |
| Demo dan masukan | Menghadirkan pengguna harian dan memberi masukan yang spesifik | Mencatat masukan, menjelaskan dampaknya, dan memperbaiki |
| Pengujian penerimaan (UAT) | Menguji dengan skenario kerja nyata dan menyatakan layak atau belum | Memperbaiki temuan dan menyiapkan lingkungan uji |
| Peluncuran dan pelatihan | Menetapkan tanggal mulai dipakai dan mengumpulkan tim | Menyiapkan bahan panduan dan membantu di minggu pertama |
| Setelah dipakai | Melaporkan kendala dan menentukan prioritas pengembangan berikutnya | Merawat aplikasi dan mengerjakan pengembangan sesuai prioritas |

Perhatikan polanya: di kolom klien, hampir semua berbentuk keputusan, bahan, dan penilaian. Tidak ada yang meminta Anda memahami teknologi. Tugas Anda adalah menjadi sumber kebenaran tentang pekerjaan; tugas penyedia adalah menerjemahkannya.

## Tiga peran yang perlu ada di sisi Anda

Di perusahaan kecil, satu orang bisa memegang dua atau bahkan ketiga peran sekaligus. Yang penting bukan jumlah orangnya, melainkan setiap peran ada pemiliknya dan pemiliknya tahu bahwa itu tugasnya.

### Pengambil keputusan

Orang yang berwenang menyetujui proposal, memilih prioritas, dan memutuskan ketika dua pendapat bertentangan, misalnya pemilik atau direktur. Perannya tidak menuntut kehadiran sepanjang hari, tetapi menuntut jawaban yang cepat. Bila pengambil keputusan sulit dijangkau, delegasikan secara tertulis kepada satu orang yang dipercaya agar proyek tidak berhenti menunggu.

### Penanggung jawab proses

Orang yang paling paham alur kerja yang akan diaplikasikan dan menjadi kontak harian penyedia: menjawab pertanyaan, mengumpulkan bahan, mengatur jadwal demo, dan menilai hasil. Ini peran yang paling menentukan kelancaran proyek. Idealnya ia bukan orang yang paling sibuk di perusahaan, dan diberi waktu yang nyata untuk peran ini, bukan hanya tambahan tugas di sela pekerjaan lain.

### Pengguna harian dan penjaga data

Staf yang kelak memakai aplikasi setiap hari, serta orang yang memegang data dan dokumen yang dipakai sekarang. Pengguna harian menunjukkan alur yang sebenarnya dan menemukan kejanggalan lebih cepat daripada siapa pun. Penjaga data memastikan contoh data yang diberikan mewakili kenyataan, termasuk data yang tidak rapi.

| Peran | Kontribusi utama | Tanda bahwa peran ini kosong |
| --- | --- | --- |
| Pengambil keputusan | Menyetujui proposal, memilih prioritas, menyelesaikan perbedaan pendapat | Pertanyaan penting menggantung berhari-hari; keputusan berubah-ubah antar-demo |
| Penanggung jawab proses | Kontak harian, menjawab pertanyaan, mengumpulkan bahan, menilai hasil demo | Penyedia harus bertanya ke banyak orang dan mendapat jawaban yang berbeda-beda |
| Pengguna harian | Mencoba demo, menunjukkan alur sebenarnya, melakukan UAT | Demo hanya dihadiri pemilik atau manajer; keluhan baru muncul setelah aplikasi dipakai |
| Penjaga data | Menyediakan contoh data dan dokumen, memeriksa hasil pemindahan data | Data awal bermasalah baru diketahui menjelang peluncuran |

## Kickoff: bahan yang perlu disiapkan sebelum pembangunan dimulai

Kickoff adalah pertemuan pertama setelah proposal disetujui, saat kedua pihak menyamakan pemahaman sebelum pekerjaan berjalan. Pertemuannya sendiri singkat. Nilainya ada pada bahan yang Anda bawa dan keputusan yang diambil di sana. Bila Anda sudah menyusun brief seperti di artikel [cara menyusun kebutuhan aplikasi](https://digipro.id/blog/cara-menyusun-kebutuhan-aplikasi), sebagian besar bahan ini sudah ada.

1. **Sepakati siapa memegang tiga peran di atas** — Catat nama pengambil keputusan, penanggung jawab proses, dan pengguna harian yang ikut demo. Sebut juga pengganti bila salah satunya berhalangan.
2. **Konfirmasi isi versi pertama dan yang di luar lingkup** — Baca ulang bagian lingkup dan bagian 'di luar lingkup' di proposal bersama-sama. Perbedaan harapan paling murah diluruskan di titik ini.
3. **Serahkan bahan contoh** — Spreadsheet yang dipakai sekarang, contoh formulir, nota, atau laporan, termasuk yang berantakan. Tutupi data pribadi pelanggan, pasien, atau karyawan bila belum perlu dibagikan.
4. **Tentukan akses ke sistem lain** — Bila aplikasi harus tersambung ke aplikasi atau layanan lain, tentukan siapa yang memberi akses dan kapan. Keterlambatan akses adalah penyebab umum jadwal bergeser.
5. **Sepakati jadwal demo dan cara komunikasi** — Tanggal demo, kanal komunikasi harian (misalnya WhatsApp), dan batas waktu respons yang wajar untuk kedua pihak. Tulis, jangan hanya diucapkan.
6. **Tetapkan tanggal mulai dipakai sebagai target** — Tanggal ini bisa disesuaikan, tetapi punya tanggal sejak awal membuat semua keputusan terasa nyata. Pertimbangkan musim sibuk usaha Anda saat memilihnya.

## Demo rutin: cara memberi masukan yang berguna

Aplikasi dibangun bertahap dengan demo rutin supaya perubahan arah masih murah. Tetapi demo hanya berguna bila masukannya bisa ditindaklanjuti. Pengguna yang baru pertama melihat aplikasi sering berkomentar dalam kesan umum, padahal yang dibutuhkan penyedia adalah kejadian dan alasan yang spesifik.

| Masukan yang sulit ditindaklanjuti | Masukan yang berguna (ilustrasi) |
| --- | --- |
| Tampilannya kurang enak. | Tombol 'Simpan' tertutup keyboard di ponsel, jadi staf lapangan sulit menyimpan laporan. |
| Kayaknya kurang lengkap. | Saat membuat jadwal, kami juga harus mencatat nama pelanggan cabang. Kolom itu belum ada. |
| Alurnya aneh. | Kami selalu mengisi nomor pesanan sebelum nama pelanggan; urutan di layar terbalik dan sering salah isi. |
| Bisa ditambah fitur lain? | Setiap Jumat pemilik meminta rekap mingguan. Bisa dibuat otomatis? Kalau ini menyusul, tidak apa-apa. |
| Sudah oke. | Alur membuat jadwal sudah cocok. Dua hal yang masih kami kerjakan manual: mencetak surat tugas dan menghubungi pelanggan. |

Beberapa kebiasaan membuat demo lebih produktif. Hadirkan minimal satu pengguna harian, bukan hanya manajer. Minta pengguna mencoba sendiri dengan layar dibagikan, jangan hanya menonton. Catat setiap masukan beserta alasannya, lalu tandai mana yang menghalangi pemakaian dan mana yang bisa menunggu. Dan setelah demo, kirim ringkasan tertulis keputusan yang diambil, sehingga tidak ada yang bergantung pada ingatan.

## Revisi atau permintaan baru? Cara membedakannya

Sumber salah paham paling umum dalam proyek aplikasi adalah kata 'revisi' yang dipakai untuk segala hal. Tiga jenis permintaan berikut berdampak berbeda pada waktu dan biaya, dan sebaiknya dibedakan sejak awal. Bagaimana tiap jenis ditangani secara resmi harus tertulis di proposal; tanyakan sebelum menyetujuinya.

| Jenis | Ciri-cirinya | Perlakuan yang wajar |
| --- | --- | --- |
| Perbaikan kesalahan | Aplikasi tidak berfungsi sesuai yang disepakati, misalnya angka salah hitung atau tombol tidak bekerja | Diperbaiki oleh penyedia sesuai ketentuan di proposal |
| Penyesuaian dalam lingkup | Fitur yang sudah disepakati perlu diubah bentuknya setelah dicoba, misalnya urutan kolom atau label | Dikerjakan di sela demo selama tidak mengubah lingkup yang tertulis |
| Permintaan baru | Kemampuan yang belum ada di lingkup, misalnya laporan tambahan atau integrasi baru | Dicatat, dinilai waktu dan biayanya, lalu dijadwalkan di tahap berikutnya |

> **Permintaan baru yang diselipkan ke versi pertama membuatnya molor:** Setiap tambahan kecil terasa murah, tetapi jumlahnya yang membuat versi pertama tidak pernah selesai. Cara paling sehat adalah menampung semua ide baru dalam satu daftar 'tahap berikutnya' dan menilainya setelah aplikasi dipakai. Cara penyedia menghitung biaya dari jumlah fitur dan integrasi dibahas di artikel [biaya pembuatan aplikasi](https://digipro.id/blog/biaya-pembuatan-aplikasi).

## UAT (user acceptance testing): menguji sebelum aplikasi dipakai

UAT adalah singkatan dari user acceptance testing, yaitu pengujian akhir oleh pengguna untuk memastikan aplikasi benar-benar menyelesaikan pekerjaan yang dimaksud sebelum dipakai sungguhan. Berbeda dengan pengujian teknis yang dilakukan penyedia untuk memastikan aplikasi tidak rusak, UAT menjawab pertanyaan yang hanya bisa dijawab klien: apakah aplikasi ini cocok untuk cara kerja kami? Karena itu UAT adalah tanggung jawab klien, dengan dukungan penyedia.

Untuk aplikasi internal, UAT tidak perlu rumit. Pakai kejadian nyata dari beberapa hari terakhir sebagai skenario, jalankan di aplikasi, dan lihat apakah hasilnya sama dengan cara lama atau lebih baik.

1. **Susun skenario dari pekerjaan nyata** — Ambil 5 sampai 10 kejadian nyata, termasuk yang tidak biasa: pesanan yang dibatalkan, pelanggan yang datanya salah ketik, atau tagihan yang sebagian dibayar. Kejadian tidak biasa paling sering membuka celah.
2. **Jalankan oleh pengguna sungguhan** — Minta staf yang kelak memakainya untuk menjalankan skenario sendiri, tanpa dibantu penyedia. Catat di mana mereka ragu atau salah klik; itu tanda alur belum jelas.
3. **Periksa hasilnya, bukan hanya prosesnya** — Bandingkan angka, laporan, dan pesan yang dihasilkan dengan hasil cara lama untuk kejadian yang sama. Bila ada notifikasi WhatsApp, cek isi dan waktunya, serta siapa penerimanya.
4. **Kelompokkan temuan** — Pisahkan temuan yang menghalangi pemakaian dari yang bisa menunggu, lalu sepakati mana yang diperbaiki sebelum mulai dipakai.
5. **Nyatakan layak atau belum** — Pengambil keputusan menyatakan, tertulis, bahwa aplikasi layak dipakai atau perlu perbaikan lebih lanjut. Keputusan ini menjadi titik acuan untuk tanggal mulai dipakai.

Jika aplikasi mengirim pesan otomatis lewat WhatsApp, uji juga aturan pengirimannya bersama penyedia. Gambaran aturannya ada di artikel [integrasi WhatsApp dengan aplikasi internal](https://digipro.id/blog/integrasi-whatsapp-aplikasi-internal) dan [notifikasi WhatsApp otomatis](https://digipro.id/blog/notifikasi-whatsapp-otomatis).

## Serah terima dan pelatihan pengguna

Aplikasi yang lolos UAT belum tentu dipakai. Dua hal yang sering diabaikan menentukan apakah ia hidup atau ditinggalkan: apakah tim tahu cara memakainya, dan apakah perusahaan memegang kendali atas aplikasinya. Hal yang sebaiknya Anda pastikan dengan penyedia mana pun:

- Akses dan kepemilikan. Siapa pemegang akun utama aplikasi, tempat penyimpanan data, dan domain, dan apakah Anda bisa mengaksesnya tanpa bergantung pada penyedia.
- Data Anda bisa diekspor. Tanyakan sejak proposal bagaimana data bisa diambil bila suatu hari Anda berganti penyedia.
- Panduan pemakaian singkat. Cukup halaman-halaman pendek berisi langkah untuk pekerjaan yang paling sering dilakukan, lengkap dengan tangkapan layar.
- Pelatihan berbasis tugas. Latih berdasarkan pekerjaan ('membuat jadwal', 'mengisi laporan'), bukan berdasarkan menu aplikasi. Mulai dengan pengguna yang paling sering memakai.
- Satu orang rujukan di sisi Anda untuk pertanyaan minggu pertama, dengan jalur cepat ke penyedia untuk hal yang tidak terjawab.
- Tanggal berhenti memakai cara lama. Tanpa tanggal ini, spreadsheet lama tetap diisi dan data terbelah dua.

## Minggu-minggu pertama setelah aplikasi dipakai

Peluncuran bukan garis akhir. Minggu-minggu pertama adalah masa tim menyesuaikan diri, dan di masa inilah aplikasi diuji oleh pekerjaan yang sebenarnya. Beberapa kebiasaan membantu: kumpulkan kendala dalam satu tempat, bukan lewat pesan terpisah ke banyak orang; tinjau bersama penyedia setelah satu atau dua minggu; dan tandai mana yang perbaikan, mana yang penyesuaian, mana yang permintaan baru, seperti dibahas di atas.

Pertanyaan sederhana untuk menilai keberhasilan awal: apakah tim masih mencatat hal yang sama di tempat lain, pekerjaan apa yang kini selesai lebih cepat, dan bagian mana yang membuat pengguna sering bertanya. Jawabannya menjadi bahan prioritas dukungan bulanan dan pengembangan fitur berikutnya.

## Contoh irama keterlibatan klien selama versi pertama (ilustrasi)

Versi pertama di Digipro umumnya siap dalam 2–3 minggu, tergantung fitur. Tabel berikut menggambarkan irama keterlibatan klien bila proyek berjalan dalam tiga minggu. Ini ilustrasi, bukan jadwal tetap; durasi sebenarnya mengikuti lingkup yang disepakati di proposal.

| Waktu | Yang dikerjakan penyedia | Yang diminta dari Anda |
| --- | --- | --- |
| Sebelum minggu 1 (kickoff) | Membahas proposal, menyamakan lingkup, menyiapkan lingkungan kerja | Menyebut tiga peran, menyerahkan bahan contoh, memberi akses sistem lain, menetapkan tanggal target |
| Minggu 1 | Membangun fondasi dan alur utama | Menjawab pertanyaan dengan cepat; memastikan data contoh lengkap |
| Minggu 2 | Membangun fitur inti dan memperlihatkan demo pertama | Menghadirkan pengguna harian di demo; memberi masukan spesifik; memutuskan prioritas |
| Minggu 3 | Memperbaiki dari masukan dan menyiapkan pemakaian | Menjalankan UAT dengan skenario nyata; menyatakan layak atau belum |
| Setelah versi pertama | Membantu transisi dan merawat aplikasi | Menjalankan pelatihan, berhenti memakai cara lama di tanggal yang disepakati, mengumpulkan kendala |

## Kesalahan umum klien dalam proyek aplikasi

- Menyerahkan seluruh proyek lalu menunggu hasil akhir. Tanpa demo yang diuji pengguna, arah proyek tidak terkoreksi.
- Tidak menunjuk satu penanggung jawab. Penyedia menerima jawaban yang berbeda dari orang yang berbeda dan tidak tahu mana yang berlaku.
- Mengundang hanya pemilik ke demo. Staf yang memakai alur setiap hari adalah yang paling tahu celahnya, dan penolakan sering muncul bila mereka dilibatkan terlambat.
- Memberi masukan dalam kesan umum, bukan kejadian spesifik, sehingga penyedia menebak maksudnya.
- Mencampur revisi dengan permintaan baru, sehingga lingkup melebar tanpa terasa dan versi pertama tidak pernah selesai.
- Melewatkan UAT karena ingin cepat. Masalah yang ditemukan pengguna di hari pertama pemakaian jauh lebih mahal dan lebih mengganggu.
- Tidak menetapkan tanggal berhenti memakai cara lama, sehingga dua sistem berjalan paralel tanpa batas dan data tidak pernah menyatu.
- Lupa menanyakan akses, kepemilikan, dan cara ekspor data sampai muncul alasan untuk berganti penyedia. Kesalahan lain yang sering menggagalkan proyek dari sisi pemesan dibahas di [7 kesalahan yang membuat proyek aplikasi gagal](https://digipro.id/blog/kesalahan-proyek-aplikasi).

## Cara Digipro bekerja dengan klien

Digipro adalah agensi digital berbasis di Malang, aktif sejak 2023, dan melayani klien di seluruh Indonesia secara online. Alur kami mengikuti empat tahap: konsultasi gratis, proposal tertulis berisi ruang lingkup, timeline, dan biaya, pembangunan bertahap dengan demo rutin, lalu dukungan berkelanjutan. Versi pertama yang bisa dipakai tim umumnya siap dalam 2–3 minggu, tergantung fitur. Pembuatan aplikasi custom berbasis proyek, tanpa kontrak minimal.

Dalam praktiknya, kami meminta tiga hal dari klien: satu orang yang bisa memutuskan dengan cepat, contoh dokumen dan data yang dipakai sekarang, dan kehadiran pengguna harian di demo. Selebihnya kami yang mengerjakan dan menjelaskan dengan bahasa kerja, bukan istilah teknis. Pilihan aplikasi custom sendiri dibandingkan dengan aplikasi jadi di artikel [aplikasi custom vs aplikasi jadi](https://digipro.id/blog/aplikasi-custom-vs-aplikasi-jadi), dan alasan memilih software house dibanding freelancer ada di [software house vs freelancer](https://digipro.id/blog/software-house-vs-freelancer).

## Langkah berikutnya

Sebelum menghubungi penyedia mana pun, tentukan tiga nama di sisi Anda: pengambil keputusan, penanggung jawab proses, dan satu pengguna harian yang akan ikut demo. Tiga nama itu sudah menjawab sebagian besar risiko keterlambatan. Bila Anda ingin membahasnya bersama, [konsultasi gratis](https://digipro.id/#kontak) bisa dipakai untuk memetakan peran, lingkup versi pertama, dan estimasi tertulis. Layanan pembuatan aplikasi kami dijelaskan di halaman [jasa pembuatan aplikasi Digipro](https://digipro.id/jasa-pembuatan-aplikasi). Bila Anda masih menimbang jalur yang tepat, mulai dari [jasa pembuatan aplikasi untuk perusahaan](https://digipro.id/blog/jasa-pembuatan-aplikasi-perusahaan).

## Pertanyaan yang sering diajukan

### Berapa banyak waktu yang harus saya sediakan sebagai klien dalam proyek aplikasi?

Tidak sebanyak yang dibayangkan banyak orang, tetapi harus tepat waktu. Yang paling penting adalah menjawab pertanyaan dengan cepat, menyediakan contoh data dan dokumen di awal, menghadirkan pengguna harian di setiap demo, dan meluangkan waktu untuk UAT menjelang selesai. Besarnya waktu bergantung pada ukuran lingkup, jadi dibahas saat konsultasi dan proposal, bukan angka baku.

### Siapa yang sebaiknya menjadi penanggung jawab proyek di sisi perusahaan?

Orang yang paling memahami alur kerja yang akan diaplikasikan, yang bisa mengambil atau meneruskan keputusan dengan cepat, dan diberi waktu nyata untuk peran ini. Ia bukan harus orang teknis. Di perusahaan kecil, penanggung jawab proses bisa pemilik sendiri atau kepala administrasi, asalkan satu orang yang jelas, bukan banyak orang dengan jawaban berbeda.

### Apa itu UAT dan apakah perlu untuk aplikasi internal kecil?

UAT (user acceptance testing) adalah pengujian akhir oleh pengguna dengan skenario kerja nyata untuk memastikan aplikasi layak dipakai. Untuk aplikasi internal, perlu, tetapi bisa sederhana: jalankan 5 sampai 10 kejadian nyata, termasuk yang tidak biasa, lalu bandingkan hasilnya dengan cara lama. Melewatkannya berarti menemukan masalah di hari pertama pemakaian, saat paling mengganggu dan paling mahal diperbaiki.

### Bagaimana membedakan revisi dengan permintaan fitur baru?

Perbaikan kesalahan berarti aplikasi tidak bekerja sesuai yang disepakati. Penyesuaian dalam lingkup berarti fitur yang sudah disepakati diubah bentuknya setelah dicoba. Permintaan baru berarti kemampuan yang belum ada di lingkup. Ketiganya berdampak berbeda pada waktu dan biaya, dan cara penanganannya harus tertulis di proposal. Tanyakan sebelum menyetujui, dan tampung ide baru dalam daftar tahap berikutnya.

### Apa yang harus saya minta saat serah terima aplikasi?

Pastikan Anda tahu siapa pemegang akun utama, tempat penyimpanan data, dan domain, serta bagaimana data bisa diekspor. Minta panduan pemakaian singkat untuk pekerjaan yang paling sering dilakukan, pelatihan berbasis tugas untuk pengguna, satu jalur cepat ke penyedia untuk minggu pertama, dan tanggal berhenti memakai cara lama. Rincian yang berlaku untuk proyek Anda dicantumkan di proposal.