Perangkat Lunak Berbasis Pendapatan: Dinilai berdasarkan Penggunaan, Bukan Fitur

Cara standar untuk menilai suatu proyek perangkat lunak adalah penyelesaian fitur: apakah kita membangun apa yang ada dalam spesifikasi? Pengembangan perangkat lunak yang berorientasi pada pendapatan mengajukan pertanyaan berbeda: enam bulan setelah peluncuran, apakah bisnis berjalan lebih baik karena sistem ini?

Kedua pertanyaan tersebut menghasilkan proyek yang sangat berbeda.

# Ketika Proyek yang Berfokus pada Fitur Menjadi Salah

Sistem dengan fitur lengkap yang tidak digunakan oleh siapa pun merupakan kegagalan menurut ukuran bisnis apa pun, namun sistem ini lolos uji keberhasilan proyek tradisional. Spesifikasi telah disampaikan. Vendor mendapat bayaran. Sistem tidak digunakan sementara staf kembali ke spreadsheet.

Hal ini terjadi karena alasan yang dapat diprediksi:

• Sistem dirancang untuk spesifikasinya, bukan untuk orang yang akan menggunakannya setiap hari
• Pelatihan dilakukan dalam satu sesi, bukan tertanam dalam orientasi
• Antarmuka memerlukan sepuluh langkah untuk tugas yang membutuhkan dua langkah dengan cara lama
• Staf tidak terlibat dalam proses desain dan tidak mempercayai hasilnya

Tak satu pun dari hal ini merupakan kegagalan pengguna. Itu adalah kegagalan desain.

# Pendekatan Result Marketing

Jared Loo pertama kali datang ke pengembangan perangkat lunak sebagai klien. Dia menjalankan logistik kapal tanker air Terasek dan bisnis e-commerce, menghabiskan biaya sebesar tujuh digit untuk teknologi, dan hidup dengan konsekuensi dari sistem yang dibangun namun tidak digunakan. Pengalaman itu adalah fondasi cara kami membangun.

Jacob Ng, yang merancang sistem kami, memiliki fokus khusus pada antarmuka untuk pekerja garis depan dan pekerja migran – orang-orang yang menganggap sistem yang rumit berarti sistem yang akan mereka hindari. Disiplin desain adalah: jika diperlukan sesi pelatihan untuk mempelajarinya, desain tidak selesai.

Kombinasi tersebut menghasilkan perangkat lunak yang dinilai berdasarkan apakah orang yang perlu menggunakannya benar-benar melakukannya.

# Seperti Apa Pembangunan Berbasis Pendapatan

Peninjauan selama 30 hari dan 90 hari tidak bersifat komersial — peninjauan ini merupakan pemeriksaan bahwa penggunaan sudah sesuai dengan kebutuhan dan bahwa setiap titik hambatan telah teratasi.

# Masalah Adopsi Adalah Masalah Desain

Ketika kita melakukan proyek penyelamatan – sebuah sistem yang dibangun tetapi tidak digunakan – masalahnya hampir tidak pernah bersifat teknis. Sistem bekerja. Datanya ada di sana. Masalahnya adalah penggunaannya dengan benar membutuhkan lebih banyak upaya daripada solusi yang dikembangkan tim.

Pekerjaan pengembangan perangkat lunak khusus kami dimulai dengan alur kerja, bukan daftar fitur. Apa yang perlu dilakukan petugas gudang dalam 30 detik? Apa yang perlu dilihat oleh manajer keuangan tanpa masuk ke tiga sistem? Pertanyaan-pertanyaan tersebut menentukan antarmuka sebelum pengembangan dimulai.

# Pemilik Bisnis sebagai Pengguna Sebenarnya

Salah satu pengguna sistem bisnis yang kurang dihargai adalah pemiliknya. Sebuah sistem yang memberikan alur kerja yang lebih baik kepada staf namun membiarkan pemiliknya tanpa visibilitas bukanlah sistem yang didorong oleh pendapatan. Setiap sistem yang kami bangun mencakup lapisan pelaporan dan peringatan yang memberi tahu pemilik apa yang terjadi — tanpa mengharuskan mereka masuk dan bernavigasi.

Ini terhubung ke halaman about kami: Hasil didirikan oleh seseorang yang merupakan klien perangkat lunak yang frustrasi sebelum ia menjadi pembuat perangkat lunak. Perspektifnya tidak berubah.

# Pertanyaan Umum

# Bagaimana Anda mengukur apakah suatu sistem telah diadopsi?

Log penggunaan adalah ukuran paling langsung — berapa banyak staf yang login, berapa banyak transaksi yang diproses melalui sistem versus di luar sistem, dan apakah penyelesaian manual telah dihilangkan. Kami menentukan metrik adopsi selama pelingkupan.

# Bagaimana jika staf kami menolak sistem baru?

Resistensi biasanya merupakan sinyal bahwa sistem tersebut lebih sulit digunakan dibandingkan alternatifnya. Responsnya adalah iterasi desain, bukan dorongan pelatihan. Jika sistem baru ini benar-benar lebih mudah dibandingkan spreadsheet, penerapannya akan dilakukan tanpa paksaan.

# Bagaimana struktur harga Anda untuk perangkat lunak khusus?

Proyek memiliki cakupan dengan hasil yang ditentukan dan harga tetap untuk cakupan tersebut. Kami tidak mengenakan biaya per jam untuk pekerjaan yang tidak ditentukan. Cakupannya mencakup peninjauan pasca peluncuran, sehingga risiko adopsi ditanggung bersama, bukan ditransfer ke klien.

• Pesan Audit Sistem*