Anda mengikuti demo. Semuanya berhasil. Pesanan mengalir, laporan terkirim, invoice tercetak dengan indah. Anda keluar. Tiga minggu kemudian sistem tersebut aktif, dan tidak ada yang berfungsi seperti demo. Jika cerita tersebut terdengar familier, artikel ini adalah lingkungan pementasan yang dijelaskan dalam istilah bisnis sederhana, karena konsep yang hilang di balik sebagian besar bencana "berhasil dalam demo" adalah: tidak ada yang menguji lingkungan pementasan dengan data yang berbentuk seperti milik Anda.
Saya telah menghabiskan lima belas tahun membangun perangkat lunak untuk perusahaan mulai dari startup hingga bank, dan saya dapat memberitahu Anda bahwa demo tersebut tidak berbohong kepada Anda. Itu hanya menjawab pertanyaan yang berbeda. Demo tersebut menjawab "apakah software ini dapat berfungsi?" Yang perlu Anda jawab adalah "akankah perangkat lunak ini berfungsi dengan data saya, volume saya, dan orang-orang saya?" Itu dipisahkan oleh lingkungan yang mungkin belum pernah Anda dengar.
Ini adalah kosakata yang harus dimiliki setiap pembeli perangkat lunak, jadi izinkan saya memberikannya kepada Anda.
Tiga lingkungan: pengembangan, pementasan, produksi
Tim perangkat lunak yang serius menjalankan setidaknya tiga salinan sistem:
| Lingkungan | Siapa yang menggunakannya | Data apa yang dimilikinya | Untuk apa |
|---|---|---|---|
| Pengembangan (pengembangan) | Pemrogram | Palsu, minimal | Membangun dan menghancurkan sesuatu setiap hari |
| Pementasan | Penguji, dan Anda | Realistis, berbentuk produksi | Verifikasi akhir sebelum rilis |
| Produksi | Bisnis Anda | Nyata, hidup | Menjalankan operasi sebenarnya |
Dev adalah bengkelnya. Itu berubah setiap jam, seringkali setengah rusak, dan itu tidak masalah. Produksi adalah bisnis langsung Anda; perubahan di sana harus membosankan dan dilatih. Staging adalah tahap gladi bersih di antaranya: salinan sistem, dikonfigurasikan seperti produksi, diisi dengan data yang terlihat seperti produksi, tempat perubahan dibuktikan sebelum pelanggan sebenarnya menyentuhnya.
Demo yang Anda tonton hampir pasti dijalankan di mesin pengembang atau lingkungan demo khusus. Itu penting karena apa yang ada di dalamnya.
Mengapa demo berjalan pada data palsu yang bersih, dan mengapa hal itu menyembunyikan masalah
Data demo dikurasi. Sepuluh produk rapi, lima pelanggan bernama "PT Contoh Jaya", setiap kolom diisi dengan benar, setiap harga berupa angka bulat. Realitas produksi Anda tidak seperti itu:
- 8.000 SKU, 900 di antaranya memiliki nama duplikat dan 200 tidak memiliki barcode
- Catatan pelanggan dengan nomor telepon dalam empat format berbeda
- Pesanan dari tahun 2019 dengan jumlah negatif yang dimasukkan seseorang untuk memperbaiki pengembalian
- Nama produk mengandung emoji, karena ada staf yang copy-paste dari WhatsApp
- Volume akhir bulan dua belas kali lipat dari hari Selasa biasa
Perangkat lunak yang menangani sepuluh produk bersih dengan sempurna dapat menghambat 900 duplikat, salah mengurutkan nomor telepon, crash pada kuantitas negatif, atau lambat merangkak pada volume akhir bulan. Tidak ada satupun yang terlihat dalam demo, dan tidak ada satupun yang menunjukkan bahwa vendornya tidak jujur. Data yang bersih hanyalah habitat alami dari demo.
Kegagalan hanya muncul ketika kenyataan hidup berantakan. Tugas Anda sebagai pembeli adalah memastikan kenyataan muncul dalam pementasan, sebelum ditayangkan, bukan dalam produksi, setelahnya.
Lingkungan pementasan dijelaskan sebagai alat pembeli
Inilah gambaran ulangnya: pementasan bukan hanya praktik teknik, ini adalah tempat pengujian penerimaan Anda. Sebelum Anda keluar dari sistem apa pun, baik yang dibuat khusus atau dikonfigurasikan secara siap pakai, Anda harus meminta izin pementasan yang terlihat seperti ini:1. Data berbentuk nyata dimuat. Idealnya salinan anonim atau ekspor produk aktual, pelanggan, dan transaksi beberapa bulan Anda. Jika aturan privasi mencegah penyalinan data nyata, mintalah data dengan kekacauan yang sama: volume yang sama, duplikat yang sama, catatan warisan aneh yang sama. 2. Orang-orang Anda yang menjalankan skenario Anda. Bukan vendor yang mengklik skrip. Admin Anda memproses daftar pesanan aktual Senin pagi. Staf keuangan Anda menutup bulan sampel. Proses Anda yang paling lambat diatur waktunya. 3. Kasus jelek sengaja diuji. Pengembalian, pesanan dibatalkan, pelanggan dengan saldo belum dibayar, perubahan harga di tengah pesanan, formulir pengiriman ganda. Tuliskan sepuluh di antaranya. Mereka berasal dari tim Anda; mereka tahu di mana mayat-mayat itu dikuburkan. 4. Penandatanganan dilakukan secara tertulis, terhadap daftar tersebut. "Demo terlihat bagus" bukanlah penerimaan. "25 skenario ini diteruskan berdasarkan pementasan dengan data kami" adalah.
Kebiasaan ini menghabiskan beberapa hari waktu staf per rilis. Sistem ini secara rutin menangkap permasalahan yang mungkin akan membuat Anda harus menghadapi pemadaman kebakaran selama berminggu-minggu dan, yang lebih buruk lagi, kepercayaan tim Anda terhadap sistem yang baru. Saya melihat ini terbayar langsung pada proyek portal B2B di mana kami memuat katalog nyata dan saldo dealer nyata ke dalam pementasan dan membiarkan admin mencoba memecahkannya sebelum diluncurkan; detailnya ada di studi kasus pemasok agri.
Pertanyaan untuk ditanyakan pada vendor perangkat lunak mana pun
Anda tidak perlu ahli teknis untuk menjalankan daftar periksa ini. Ajukan lima pertanyaan berikut dan dengarkan jawaban yang percaya diri dan spesifik:
- "Apakah Anda memelihara lingkungan pementasan untuk sistem kami?" Satu-satunya jawaban yang dapat diterima adalah ya. Jika perubahan langsung terjadi dari laptop pengembang ke sistem live Anda, setiap pembaruan adalah pertaruhan pada operasional Anda.
- "Dapatkah kami melakukan pengujian penerimaan pada pementasan dengan data kami sendiri sebelum ditayangkan?" Vendor yang baik akan menjawab ya dan membantu Anda memuatnya. Vendor yang menolak memberi tahu Anda sesuatu.
- "Bagaimana Anda menerapkan perubahan setelah go-live?" Anda ingin mendengar: diuji pada staging terlebih dahulu, dirilis pada waktu dengan lalu lintas rendah, dengan cara melakukan roll back. Anda tidak ingin mendengar: "kami hanya memperbaruinya."
- "Apa yang terjadi jika rilis merusak sesuatu?" Dengarkan kata rollback, dan waktu respons yang ditentukan. Hal ini berhubungan langsung dengan perencanaan kesinambungan Anda, yang saya bahas di kesinambungan bisnis untuk UKM.
- "Apakah pementasan sudah termasuk dalam harga, atau tambahan?" Beberapa vendor mengutip biaya hosting yang sangat rendah dengan secara diam-diam menghilangkan pementasan. Biaya tambahan bulanan yang kecil, seringkali sebesar 20 hingga 40 persen dari tagihan hosting produksi, adalah hal yang normal dan bernilai setiap rupiah.
Berapa biayanya, sejujurnya
Pementasan ini tidak gratis, dan saya lebih suka Anda mendengarnya dari saya daripada menganggapnya sebagai item baris kejutan. Lingkungan pementasan biasanya berarti salinan infrastruktur server kedua yang lebih kecil ditambah beberapa waktu teknis untuk menjaganya tetap sinkron. Untuk sistem UKM pada umumnya yang dihosting di cloud, biayanya berkisar antara 500 ribu hingga 3 juta rupiah per bulan, tergantung pada ukuran sistemnya.Bandingkan dengan satu rilis buruk dalam produksi: satu hari downtime selama operasi, staf secara manual mengatasi fitur yang rusak, pelanggan melihat kesalahan. Bagi sebagian besar bisnis, satu insiden yang dapat dicegah akan menghasilkan kerugian selama bertahun-tahun. Jika tagihan bulanan masih terasa berat, ada cara untuk membuatnya tetap ramping, staging server bisa lebih kecil dari produksi dan bahkan dimatikan di luar periode pengujian, sebuah trik yang serupa dengan [memotong biaya infrastruktur cloud tanpa merusak banyak hal] (/blog/cutting-cloud-infrastructure-costs).
Kesimpulannya
"Ini berhasil dalam demo" dan "berhasil dalam produksi" dipisahkan oleh satu hal: lingkungan pementasan yang sarat dengan data yang berbentuk seperti bisnis nyata Anda yang berantakan, dan tes penerimaan yang dijalankan oleh orang-orang Anda sendiri. Mulai hari ini, jadikan itu standar Anda. Jangan pernah menandatangani demo. Tanda tangani tiket pementasan, berdasarkan daftar skenario tertulis, dengan data Anda. Vendor mana pun yang layak untuk dipekerjakan akan lebih menghormati Anda karena menuntutnya.