Dokter dateng ke meja lo, senyum manis, terus ngomong: "Bang, besok jadi ya fitur X-nya. Pasien udah nunggu, Pak Direktur juga minta." Lo cuma bisa tatap layar monitor yang masih penuh task setengah jadi. Dua kata yang bikin setiap IT RS deg-degan: "besok jadi". Artikel ini gue tulis dari pengalaman pahit-manis ngadepin momen kayak gitu, plus jurus jitu biar lo gak dijadiin pesulap dadakan.

Kenapa Permintaan "Besok Jadi" Itu Berbahaya

Permintaan mendadak itu kayak bom waktu. Bukan cuma soal bisa atau gak bisa dikerjain, tapi soal ekspektasi. Begitu lo bilang "iya", besoknya jadi preseden. Kalau fitur A bisa besok jadi, kenapa fitur B gak bisa? Ujung-ujungnya lo kaya tukang servis yang disuruh "pokoknya jadi besok" buat semua hal.

Masalah lain: fitur yang digeber semaleman biasanya nggak pernah diuji bener. Lo submit jam 4 pagi, esoknya pas dipake produksi, error di mana-mana. Pasien yang tadinya nunggu malah tambah nunggu gara-gara sistem lo error. Ironis banget, kan?

Langkah Pertama: Jangan Langsung Bilang "Bisa"

Refleks pertama yang harus lo lawan adalah bilang "iya" atau "gak bisa" secara impulsif. Yang bener: tunda jawaban, ambil waktu buat klarifikasi. Reaksi yang aman kira-kira gini:

"Oke, Pak/Bu Dokter. Sebelum saya pastikan, saya butuh detail dulu: alurnya gimana, outputnya di mana, dan siapa yang akan pakai? Biar saya cek dulu apa bisa besok atau perlu beberapa hari."

Kalimat itu bukan nolak, tapi ngasih ruang napas. Dokter biasanya butuh rasa "didengerin", bukan langsung dijawab "gak bisa". Begitu lo minta detail, dia sadar ini bukan hal sepele.

Teknik "Mengulang Permintaan" yang Sering Dilupain

Salah satu kesalahan terbesar IT RS: langsung mikir teknis tanpa mengulang permintaan dengan kata-kata sendiri. Padahal teknik ini ajaib. Coba lo bilang:

"Jadi kalau gak salah, yang Bapak/Ibu butuhin itu: pasien bisa lihat status antrian dari HP sebelum ke RS, dan dokter bisa ubah jadwal praktik dari aplikasi, gitu ya?"

Seringkali pas lo ulang, ternyata permintaannya beda dari yang lo kira. Atau lebih parah: dokter sendiri belum mikir detailnya. Dengan mengulang, lo udah "menyelesaikan" setengah masalah — klarifikasi kebutuhan, bukan cuma eksekusi.

Jurus "Kecilin Skop, Nailkan Deadline"

Kalau memang harus besok jadi, jangan terima skop besar. Pangkas jadi versi paling minimal yang tetap jalan. Contoh: dokter minta "dashboard pasien lengkap besok". Lo gak harus bikin dashboard penuh warna-warni. Cukup versi MVP:

  • Bisa lihat data dasar pasien (nama, RM, poli).
  • Bisa ubah status (draft → aktif).
  • Bisa cari pasien.

Sisanya (grafik, filter, ekspor) lo bilang "nanti menyusul, tahap kedua". Dokter dapat sesuatu besok, lo gak begadang bikin monumen yang rapuh. Ini yang disebut scope management — dan ini skill paling berharga di IT RS.

Contoh Nyata: Kasus "Cetak Label Besok"

Biar gak abstrak, gue kasih contoh yang gue alamin sendiri. Suatu hari dokter poli minta fitur cetak label obat baru buat besok — katanya karena besok ada pasien program khusus yang butuh label baru. Padahal modul farmasi kami masih manual banget.

Kalau gue bilang "gak bisa", dokter bakal kesel. Kalau gue bilang "bisa", gue harus bangun fitur lengkap: desain label, printer, integrasi data obat, semua dalam satu malam. Gila.

Yang gue lakuin: tanya dulu "labelnya bentuknya gimana, ada contohnya gak?" Ternyata labelnya cuma tempelan kecil berisi nama pasien, nama obat, dan dosis. Gue bilang: "Saya bisa bikin versi sederhana besok: input manual, cetak dari halaman resep. Tapi belum otomatis narik data dari master obat, itu nyusul minggu depan." Dokter setuju. Besoknya fitur jalan, dokter seneng, dan gue gak tidur di server room.

Poinnya: pangkas sampe ke esensi. Fitur yang "cukup" hari ini jauh lebih baik daripada fitur sempurna yang gak pernah kelar.

Jangan Lupa Tanya: "Siapa yang Ngecek Besok?"

Ini pertanyaan yang sering dilupain: setelah fitur jadi, siapa yang nerima dan ngecek? Kalau lo serahin fitur ke dokter tanpa siapa-siapa yang mau test, fitur itu bisa jadi bola liar. Jadi pastiin sebelum mulai:

  • Siapa user yang bakal ngecek (dokter, perawat, admin)?
  • Kapan dia available buat test?
  • Kalau ada masalah pas test, siapa yang gue hubungi?

Dengan jawaban ini, lo gak cuma bikin fitur, tapi bikin proses serah terima yang jelas. Dan kalau fiturnya ternyata ada bug besoknya, lo udah punya kontak yang tau konteks — bukan cari-cari orang yang gak ngerti apa-apa.

Dokumentasi Itu Tameng Lo

Setiap kali lo sepakat soal fitur, tulis. Gak perlu dokumen 10 halaman, cukup email atau chat singkat:

"Halo Dok, sesuai diskusi tadi, yang akan saya kerjakan besok: [fitur A]. Batasan: [yang gak termasuk]. Estimasi: [waktu]. Kalau ada koreksi, mohon kabari sebelum jam X."

Ini bukan birokrasi iseng. Ini bukti kalau ada yang "lupa" atau nambah permintaan di tengah jalan, lo punya pegangan. Percayalah, dokter yang tadi minta "fitur A besok" bisa berubah jadi "fitur A dan B besok" keesokan harinya. Dengan dokumentasi, lo bisa nunjukin: "Maaf, yang disepakati cuma A."

Kapan Harus Tegas Bilang "Gak Bisa"

Ada kalanya jawaban paling jujur adalah "gak bisa besok, tapi bisa tanggal X." Jangan takut nolak kalau memang risikonya gede. Contoh kasus di mana lo harus tegas:

  • Perubahan database yang menyentuh data pasien — risiko korup data.
  • Fitur yang butuh approval keamanan (akses data sensitif).
  • Perubahan yang bisa ganggu jam operasional RS (jangan update di jam sibuk).
  • Fitur yang belum jelas spesifikasinya — nanti malah bolak-balik.

Nolak itu gak enak, tapi mengiyakan lalu gagal itu lebih parah. Kredibilitas lo anjlok. Sekali lo bilang "bisa besok" terus meleset, dokter bakal mikir dua kali buat percaya lagi.

Trik Komunikasi Supaya Gak Bikin Dokter Tersinggung

Kunci komunikasi sama dokter: jangan bikin dia ngerasa disalahin. Pakai bahasa "kita" bukan "kamu":

  • "Kita coba rapikan dulu alurnya ya, Dok." — bukan "Ini alurnya gak jelas."
  • "Saya bantu prioritasin, mana yang paling urgent." — bukan "Gak bisa semua."
  • "Kalau kita kerjain ini dulu, besok yang lain nyusul." — bukan "Gak sempet."

Dokter itu orang sibuk, dan permintaan "besok jadi" biasanya lahir dari tekanan, bukan niat nyusahin. Kalau lo bisa jadi orang yang ngasih solusi sambil ngeredain paniknya, lo bakal jadi IT favorit di RS.

Yang Dilakuin Setelah Fitur Jadi

Fitur selesai besok itu baru setengah jalan. Setelah submit, lo wajib:

  1. Uji dulu di lingkungan test (kalau ada).
  2. Pantau beberapa hari pertama — jangan langsung lupa.
  3. Catat feedback pemakaian buat perbaikan tahap dua.
  4. Evaluasi sama dokter: "gimana, Dok? Ada yang perlu ditambah?"

Dengan evaluasi, lo gak cuma tukang bikin fitur, tapi mitra. Dan siklus "besok jadi" yang tadinya terasa musibah, lama-lama jadi kerjaan yang manageable.

Penutup: Bukan Tentang "Besok Jadi", Tapi Tentang "Jadi dengan Benar"

Di akhir hari, permintaan "besok jadi" itu gak akan pernah hilang dari dunia IT RS. Yang bisa lo ubah adalah cara lo ngelayaninnya: klarifikasi, kecilin skop, dokumentasi, dan komunikasi yang jujur. Dulu gue pikir kerjaan IT RS itu soal nyentuh server dan nulis kode. Ternyata setengahnya lagi soal seni ngomong — termasuk seni bilang "gak bisa" tanpa bikin orang sakit hati.

Jadi next time ada dokter bilang "besok jadi", tarik napas, senyum, dan mulai dengan pertanyaan: "Detailnya gimana, Dok?" Itu udah kemenangan pertama lo.

Salam nol drama,
MinTIRS