Sekitar 500 peserta terdaftar. Sistem multi-track (hackathon + seminar), submission dua tahap, dan QR absensi. Event selesai — tapi tidak tanpa empat insiden yang ngajarin aku banyak hal.
Riset dulu, baru bangun. Di BTNG, aku riset belakangan — dan itu nyebabin banyak request dadakan saat live. Di Dinacom, aku mulai dari nanya-nanya ke administrasi dulu. Permintaan mendadak jauh lebih sedikit, dan delivery ke tim lebih lancar.
Delivery task yang detail = tim yang nggak nebak-nebak. Tiap task aku kasih poin capaian + hint teknis. Hasilnya: revisi lebih sedikit, dan tim lebih mandiri. Lead yang baik itu spesifik, bukan asal bagi.
"Berhasil di dev" belum tentu "berhasil di production." Empat insiden di Dinacom ngajarin itu dengan cara yang nggak akan aku lupa: SMTP throttling yang nggak ke-test, timezone countdown yang salah, traffic spike di submission final, dan QR yang gagal di cahaya rendah.
BTNG (project sebelumnya) ngajarin aku satu hal: kalau nggak riset kebutuhan panitia dari awal, yang bayar nanti adalah pas event udah jalan. Di Dinacom — hackathon tahunan DNCC — aku mau benerin itu. Aku mulai dengan nanya ke administrasi, ke LO, ke panitia lapangan: data apa yang perlu di-rekap, workflow apa yang ribet dan bisa di-automate. Hasilnya: kebutuhan yang sebelumnya nyusul di BTNG, sekarang udah masuk backlog dari hari pertama.
Aku juga benerin cara lead tim. Di BTNG, task yang aku bagi kadang terlalu umum — "bikin form submission" — dan tim balik nanya: submit apa? validasinya gimana? Di Dinacom, tiap task ada poin capaian dan hint teknis. Contoh: "Bikin form submission dengan validasi: 1) file size max X MB, 2) format PDF/ZIP only, 3) field judul minimal 5 karakter." Itu ngehemat banyak waktu review, dan tim jalan lebih cepet. Dokumentasi juga aku bikin lebih lengkap: ERD, flow user, dan list fitur dengan acceptance criteria. Lumayan males di awal, tapi berguna banget pas development.
Scope Dinacom jauh lebih besar dari BTNG. Bukan cuma landing page, tapi ada pendaftaran multi-track (lomba + seminar), email verification, submission system dua tahap (penyisihan + final), QR absensi, countdown timer, dan dashboard admin untuk analitik. Tim web juga lebih besar. Lebih banyak moving parts = lebih banyak yang bisa salah, dan akhirnya banyak yang salah juga.
Empat insiden di production yang nggak akan aku lupa:
Satu: email verifikasi-nya flaky. Ada yang terkirim, ada yang nggak. Non-deterministic, dan itu jenis bug yang paling nyebelin — pas kamu test jalan, pas production error. Dugaanku SMTP throttling, karena kami pakai shared service. Peserta yang nggak dapet email verifikasi bingung, dan ada yang komplain. Kami akhirnya fallback ke notifikasi manual via WA admin.
Dua: countdown tanggal babak penyisihan nggak sesuai. Salah set di dashboard admin, dan baru ketauan pas ada peserta yang nanya di grup. Itu bug yang nggak ke-test karena di development semua tanggal aku isi manual, dan yang aku test juga manual. Production beda — orang ngisi seenaknya, dan nggak ada validasi.
Tiga: yang paling parah. Pas pengumpulan submission final — momen paling kritis di hackathon, semua orang nge-submit bareng di detik-detik akhir countdown — website lemot dan form sempat error. Traffic spike yang nggak ke-load test. Untungnya panitia extend deadline 30 menit, jadi nggak ada yang kehilangan submission. Tapi UX-nya hancur di momen yang harusnya jadi highlight.
Empat: QR absensi nggak kebaca di cahaya rendah. Di dev lancar — ruangan terang, kamera hapek bagus. Di production — ruangan hackathon lebih gelap dari yang aku kira, cahaya nggak ideal, QR scanner gagal terus. Panitia fallback ke absensi manual. Event tetep jalan, tapi LO harus ngecatet satu-satu.
Aku tulis di catatan sendiri waktu itu: testing emang penting sih, testing di segala kondisi untuk handle semua kondisi perlu sebelum launching website. Itu bukan kalimat motivasi — itu hasil dari empat insiden yang nge-hit di empat kondisi yang berbeda: SMTP throttling, human error di admin panel, traffic spike, dan hardware environment. Sekarang setiap aku nge-test sesuatu, pertanyaannya bukan "bisakah ini jalan" — tapi "jalan di kondisi apa?"
Hasilnya: sekitar 500 peserta terdaftar, event selesai, hackathon dan seminar running. Tapi pelajaran yang aku bawa lebih berharga dari sekedar event yang sukses. Berkaca dari BTNG, aku udah naikin kualitas lead dan perencanaan. Insiden di Dinacom ngajarin aku satu hal yang BTNG belum: kalau hardware atau environment produksi beda dari dev, test ulang. Titik.