“Bisa tambahkan satu tombol di sini? Sepertinya sebentar.”
Kalimat seperti ini mudah muncul saat membuat website atau aplikasi. Dari luar, permintaannya memang terlihat sederhana. Tinggal menambahkan tombol, memberi warna, lalu menulis keterangannya.
Namun, tombol itu harus melakukan sesuatu.
Kalau tombolnya untuk membatalkan pesanan, misalnya, ada banyak pertanyaan yang perlu dijawab. Apakah semua pesanan boleh dibatalkan? Bagaimana jika sudah dibayar? Apakah uangnya langsung dikembalikan? Apa yang muncul kalau pembatalan gagal?
Yang terlihat hanya satu tombol. Pekerjaan di belakangnya bisa jauh lebih banyak.
Di sinilah kolaborasi designer dan developer sering menghadapi masalah yang tidak langsung terlihat.
Designer merancang tampilan dan alur penggunaan. Developer menulis kode agar rancangan tersebut bisa digunakan. Keduanya perlu bekerja sama untuk memastikan website atau aplikasi berjalan dengan baik.
Namun, meskipun hubungan mereka akrab dan komunikasinya lancar, pekerjaan tetap bisa terhambat jika tambahan tugas dan keputusan yang belum selesai tidak diperhitungkan.
Kenapa Revisi Kecil Bisa Membutuhkan Banyak Pekerjaan?
Revisi yang terlihat kecil di layar belum tentu kecil dari sisi pekerjaan. Satu perubahan pada website atau aplikasi dapat memengaruhi desain, business logic, data, integrasi, testing, dokumentasi, hingga timeline development.
Karena itu, ukuran sebuah revisi sebaiknya tidak hanya dilihat dari seberapa banyak tampilan yang berubah, tetapi juga dari dampak perubahan terhadap sistem, keputusan yang perlu dibuat, dan pekerjaan tambahan yang harus dilakukan oleh designer maupun developer.
Revisi Kecil Menurut Siapa?
Kata “kecil” bisa memiliki arti berbeda bagi setiap orang.
Bagi orang yang meminta perubahan, kecil mungkin berarti hanya satu bagian layar yang berubah. Bagi orang yang mengerjakannya, perubahan itu bisa menyentuh banyak bagian sistem.
Bayangkan sebuah website pemesanan memiliki pilihan tambahan “termasuk sarapan”. Di layar, bentuknya mungkin hanya satu kotak centang.
Namun, tim perlu memastikan apakah pilihan tersebut mengubah harga, muncul di bukti pemesanan, dan diteruskan kepada staf yang menyiapkan sarapan.
Contoh ini menunjukkan tiga hal yang perlu dilihat secara terpisah:
- Perubahan tampilannya: seberapa banyak yang berubah di layar?
- Pekerjaan di baliknya: bagian apa saja yang perlu disesuaikan?
- Manfaatnya: masalah pengguna apa yang akan terbantu?
Perubahan tampilan yang sedikit belum tentu mudah dikerjakan. Sebaliknya, perubahan yang mudah dikerjakan bisa saja memberi manfaat besar.
Karena itu, sebelum menyebut sebuah revisi “kecil”, ajak orang yang mengerjakannya untuk memeriksa dampaknya.
Kadang, yang Membuat Lama Adalah Pertanyaan yang Belum Terjawab
Tidak semua waktu pengerjaan digunakan untuk membuat desain atau menulis kode.
Sebagian waktu bisa habis untuk mencari jawaban.
Misalnya, designer sudah membuat tampilan tombol “Batalkan Pesanan”. Namun, tim belum menentukan sampai kapan pelanggan boleh membatalkan pesanan.
Developer kemudian harus bertanya. Jika jawabannya belum tersedia, pekerjaan bisa tertunda atau dilanjutkan berdasarkan perkiraan.
Kalau perkiraannya ternyata salah, hasilnya perlu diubah lagi.
Designer juga bisa mengalami hal serupa. Permintaan seperti “buat halaman yang lebih menarik” masih menyisakan banyak pertanyaan. Menarik bagi siapa? Apa yang perlu ditonjolkan? Apa yang diharapkan dilakukan pengunjung?
Saat pertanyaan penting belum dijawab, orang berikutnya harus ikut menanggung pekerjaan untuk mencari jawabannya.
Pekerjaan semacam ini mudah luput karena tidak selalu menghasilkan sesuatu yang terlihat di layar. Padahal, tetap membutuhkan waktu dan tenaga.
Tidak semua pertanyaan bisa dijawab sejak awal. Beberapa memang baru muncul saat pekerjaan berjalan. Namun, pertanyaan yang sudah diketahui sebaiknya dicatat dan ditentukan siapa yang akan menjawabnya.
Proyek Tepat Waktu Bisa Menyembunyikan Beban Tambahan
Bayangkan sebuah fitur dijadwalkan selesai dalam lima hari.
Di tengah pengerjaan, ada tambahan permintaan. Jadwalnya tetap sama. Agar selesai tepat waktu, anggota tim bekerja lebih lama dari biasanya.
Pada laporan, proyek terlihat berjalan sesuai rencana.
Namun, ada hal yang tidak terlihat: jadwal itu berhasil dipenuhi karena seseorang menambah jam kerja.
Jika tambahan usaha ini tidak tercatat, proyek berikutnya bisa diberi waktu yang sama. Tim dianggap mampu menyelesaikan pekerjaan sebanyak itu dalam lima hari, meskipun sebelumnya harus lembur.
Lama-kelamaan, usaha ekstra bisa dianggap sebagai kemampuan kerja yang biasa.
Itulah sebabnya proyek yang selesai tepat waktu belum cukup untuk menilai apakah perencanaannya sudah baik. Tim juga perlu melihat apa yang terjadi selama pengerjaan.
Apakah ada tugas tambahan? Apakah ada pekerjaan yang harus diulang? Apakah seseorang terus-menerus bekerja lebih lama?
Jawaban atas pertanyaan tersebut membantu membuat jadwal berikutnya lebih masuk akal.
Pekerjaan yang Tidak Terlihat Tetap Membutuhkan Waktu
Dalam pembuatan website atau aplikasi, ada pekerjaan yang hasilnya tidak langsung tampak.
Contohnya:
- Memastikan formulir tetap bisa digunakan ketika pengguna salah mengisi data.
- Memeriksa tampilan saat judul atau nama produk sangat panjang.
- Menguji apa yang terjadi ketika koneksi internet terputus.
- Memastikan fitur bisa digunakan dengan keyboard.
- Mencatat alasan sebuah keputusan agar tidak perlu dibahas ulang.
Pekerjaan ini sering disebut invisible work, atau pekerjaan yang tidak terlihat.
Hasilnya mungkin tidak membuat tampilan terlihat lebih menarik. Namun, pekerjaan tersebut membantu mencegah masalah saat produk digunakan.
Mengucapkan terima kasih kepada orang yang mengerjakannya tentu baik. Penghargaan itu perlu disertai waktu yang cukup.
Jika pengujian diperlukan sebelum fitur digunakan pelanggan, masukkan pengujian ke jadwal. Jangan hanya berharap ada waktu tersisa setelah pekerjaan lain selesai.
Pekerjaan yang dianggap penting perlu mendapat tempat dalam rencana.
Alasan “Supaya Pengguna Lebih Nyaman” Perlu Diperjelas
Hampir semua orang ingin website atau aplikasinya nyaman digunakan. Namun, alasan tersebut masih terlalu umum untuk menentukan apakah sebuah revisi perlu segera dikerjakan.
Misalnya, seseorang berkata:
“Form ini perlu diubah supaya lebih nyaman.”
Tim masih harus menebak bagian mana yang bermasalah.
Penjelasannya akan lebih mudah ditindaklanjuti jika dibuat konkret:
“Pengguna diminta mengisi nomor telepon dua kali. Apakah isian kedua bisa memakai data yang sudah dimasukkan?”
Sekarang masalahnya lebih jelas. Tim bisa membahas cara menyelesaikannya dan memperkirakan pekerjaannya.
Jika masalahnya belum terbukti, sampaikan sebagai dugaan. Contohnya:
“Kita menduga pengguna bingung membedakan dua pilihan ini. Perlu kita periksa dulu.”
Hal yang sama berlaku ketika developer mengatakan “tidak bisa”.
Apakah fitur tersebut memang tidak didukung sistem? Apakah bisa dibuat, tetapi membutuhkan waktu lebih lama? Atau ada risiko yang perlu diselesaikan lebih dulu?
Alasan yang jelas membantu tim mencari jalan keluar.
Saat Menyerahkan Desain, Sertakan Alasan di Baliknya
Ketika designer menyerahkan rancangan kepada developer, gambar saja terkadang belum cukup.
Developer juga perlu memahami apa yang ingin dicapai.
Misalnya, desain memakai dua tampilan berbeda untuk status “Pembayaran Diproses” dan “Pembayaran Gagal”. Tujuannya agar pengguna tahu apakah perlu menunggu atau melakukan pembayaran ulang.
Jika tujuan tersebut dijelaskan, developer punya pegangan saat menghadapi kendala. Tim dapat mencari bentuk tampilan lain yang tetap membantu pengguna membedakan kedua kondisi itu.
Penjelasannya tidak harus panjang. Cukup jawab beberapa pertanyaan:
- Pengguna sedang ingin melakukan apa?
- Masalah apa yang ingin diselesaikan desain ini?
- Bagian mana yang penting untuk dipertahankan?
- Apa yang belum diputuskan, dan siapa yang akan menjawabnya?
Dengan begitu, developer tidak perlu menebak alasan di balik setiap tampilan.
Empat Pertanyaan Sebelum Menyetujui Revisi
Tim tidak perlu membuat proses yang rumit untuk mulai memperbaiki cara kerja. Saat ada permintaan perubahan, gunakan empat pertanyaan berikut.
1. Apa yang ingin diperbaiki?
Jelaskan masalahnya. Apakah pengguna kesulitan, ada kebutuhan baru, atau seseorang lebih menyukai tampilan lain?
Ketiganya boleh dibahas, tetapi belum tentu perlu didahulukan dengan alasan yang sama.
2. Pekerjaan apa saja yang ikut berubah?
Minta designer dan developer memeriksa dampaknya. Perubahan mungkin memengaruhi tampilan, data, perhitungan harga, atau pengujian.
Jangan memperkirakan waktu hanya dari bagian yang terlihat di layar.
3. Siapa yang mengambil keputusan?
Jika ada perbedaan pendapat, tentukan siapa yang bertanggung jawab memilih langkah berikutnya setelah mendengar masukan tim.
Ini membantu mencegah pembahasan berulang tanpa keputusan.
4. Kalau perubahan dikerjakan, apa yang perlu disesuaikan?
Tambahan pekerjaan membutuhkan waktu. Tim bisa menggeser jadwal, menunda bagian lain, atau membagi tugas sesuai kemampuan anggota tim.
Pastikan penyesuaiannya disepakati, sehingga pekerjaan tidak otomatis dibebankan kepada orang yang paling sering mengatakan “bisa”.
Sebelum Mengatakan “Tinggal Diubah Sedikit”
Kolaborasi designer dan developer akan lebih mudah ketika keduanya saling percaya dan terbuka terhadap masukan. Hubungan yang baik juga perlu didukung pembagian pekerjaan yang jelas.
Setelah fitur selesai, luangkan waktu untuk membahas hal yang sebelumnya tidak diperkirakan. Pertanyaan apa yang terlambat dijawab? Pekerjaan apa yang harus diulang? Tambahan tugas apa yang belum masuk jadwal?
Gunakan jawabannya untuk memperbaiki rencana berikutnya.
Saat ada permintaan “cuma revisi kecil”, tanyakan:
“Kalau kita ubah bagian ini, apa saja yang ikut dikerjakan dan berapa waktu yang dibutuhkan?”
Pertanyaan sederhana itu memberi tim kesempatan untuk menjelaskan pekerjaannya sebelum menyanggupi perubahan.