Seorang pengguna Whatsify meminta satu fitur, dan saya langsung membuatnya. Di Sejoli LMS, fitur kuis diminta oleh banyak sekali orang, dan saya menundanya cukup lama.
Kalau ukurannya jumlah peminta, dua keputusan itu terbalik. Ukuran yang saya pakai memang lain. Saya bertanya: apakah ini bagian dari bagaimana sistem seperti ini seharusnya bekerja? Lalu, kalau fiturnya ditambahkan, siapa yang menanggung bebannya?
Satu permintaan yang langsung saya buat
Whatsify mengirim kode OTP lewat WhatsApp. Pengguna yang meminta fitur itu ingin OTP bisa dikirim dari beberapa nomor WhatsApp secara bergantian.
Alasannya masuk akal begitu saya pikirkan. WhatsApp makin ketat. Kalau semua OTP dikirim dari satu nomor, sementara websitenya ramai, nomor itu mengirim pesan terlalu sering ke nomor yang tidak dikenalnya. Polanya terlihat mencurigakan, dan nomornya rentan kena ban. Saya pernah merasakan sendiri nomor pengirim kena ban karena pola yang mirip, dan ceritanya ada di tulisan Akun dibuat ketika ada sesuatu yang dimiliki.
Plugin OTP punya satu tugas dasar: kodenya harus sampai. Kalau nomornya kena ban, pengguna website tidak bisa login sama sekali. Jadi permintaan itu sebenarnya mengingatkan saya pada fitur dasar yang terlewat. Untuk hal seperti ini, satu permintaan sudah cukup.
Permintaan yang lama saya tunda
Kuis berbeda. Hampir semua orang yang membuat kelas online ingin bisa menguji muridnya, jadi permintaannya terus datang.
Masalahnya ada di cara plugin kuis WordPress bekerja. Plugin-plugin yang ada sangat boros sumber daya, terutama saat menyimpan attempt, yaitu catatan setiap kali murid mengerjakan kuis. Jumlah catatan itu tumbuh mengikuti jumlah murid, jumlah percobaan, dan jumlah soal. Kalau fitur seperti itu saya masukkan begitu saja, semua website yang memakai Sejoli LMS ikut menanggung bebannya, termasuk yang tidak pernah membuat kuis.
Selama belum ada cara yang lebih ringan, saya mengarahkan peminta untuk memakai plugin kuis yang sudah ada. Rata-rata plugin kuis menyediakan shortcode, dan shortcode itu bisa ditampilkan di halaman lesson Sejoli LMS. Kebutuhan mereka tetap terpenuhi tanpa menunggu saya.
Setelah banyak riset, akhirnya saya bisa menyederhanakan fungsinya, dan fitur kuis pun hadir. Lingkupnya sengaja dibuat sempit: mengevaluasi hasil belajar di lesson-lesson dari course yang sedang diikuti murid. Kompleksitasnya dijaga seminimal mungkin.
Fitur kuis hanya tertunda sampai saya bisa membuatnya tanpa membebani pengguna lain.
Yang terlalu spesifik punya jalannya sendiri
Ada juga kuis yang jauh lebih berat: tryout. Satu klien membutuhkannya, dan kebutuhannya lengkap dengan alur bisnis lembaganya sendiri.
Kebutuhan itu saya buatkan sebagai plugin custom, terpisah dari plugin yang didistribusikan untuk umum. Harganya belasan juta. Kemudian datang klien lain yang juga butuh tryout. Saya menjualnya dengan harga yang sama, lalu menyesuaikannya dengan kebutuhan bisnis lembaga itu.
Ibaratnya membangun perumahan. Ruang yang dipakai semua penghuni, seperti dapur dan kamar mandi, harus ada di setiap rumah. Kalau satu calon pembeli ingin ruang rapat untuk usahanya, ruang itu dibangun di rumahnya saja, dan ia yang membayarnya.
Kebutuhan yang sangat spesifik tetap bisa dilayani. Biayanya ditanggung oleh orang yang membutuhkannya, sehingga pengguna lain tidak ikut menanggung kode yang tidak pernah mereka pakai.
Tiga pertanyaan sebelum menambah fitur
Setiap kali ada permintaan, saya menimbangnya dengan tiga pertanyaan:
- Apakah ini bagian dari standar? Kalau sistem sejenis memang seharusnya punya fitur ini, satu permintaan sudah cukup. Permintaan itu menunjukkan ada yang terlewat.
- Siapa yang menanggung bebannya? Fitur di plugin umum ikut terpasang di setiap website pemakainya. Kalau hanya sedikit yang memakai, sisanya cuma menanggung beban.
- Apa jalan sementara bagi yang meminta? Plugin lain, shortcode, snippet, atau pekerjaan custom. Peminta tetap punya solusi selama fiturnya ditunda.
Di luar WordPress
Saya belajar ini dari plugin WordPress, tapi pertanyaannya sama untuk produk apa pun.
| Di plugin WordPress | Prinsipnya | Di produk lain |
|---|---|---|
| Multi nomor pengirim OTP | Satu permintaan bisa menunjukkan fitur dasar yang terlewat | Laporan bug atau keluhan pertama tentang hal yang seharusnya sudah berjalan |
| Kuis yang boros penyimpanan | Fitur umum dibayar oleh semua pemakai, termasuk yang tidak memakainya | Fitur yang memperlambat aplikasi untuk semua pengguna demi segelintir pengguna |
| Kuis lewat shortcode plugin lain | Peminta tetap punya jalan sementara | Integrasi, ekspor data, atau API untuk kebutuhan di luar produk |
| Plugin tryout custom | Kebutuhan spesifik dibiayai oleh yang membutuhkan | Paket enterprise atau pekerjaan kustom yang terpisah dari produk inti |
Ringkasnya
Jumlah peminta menunjukkan seberapa keras sebuah kebutuhan terdengar. Standar menunjukkan apakah kebutuhan itu memang tempatnya di produk. Satu permintaan bisa cukup untuk membuat fitur, dan banyak permintaan bisa tetap menunggu, selama yang meminta tahu jalan apa yang bisa mereka tempuh sementara itu.
