Ketika kami memulai KeepFlow, kami menghadapi pilihan yang dihadapi setiap tim teknis di awal: membangun perangkat lunak untuk klien, atau membangun perangkat lunak yang kami miliki. Jalur agensi adalah yang lebih aman. Klien membayar saat serah terima, pendapatannya dapat diprediksi, dan ketika sebuah proyek dirilis, ia menjadi masalah orang lain. Kami sengaja memilih jalur yang lebih sulit. Setiap produk yang dibuat KeepFlow, kami miliki dari hulu ke hilir — kami membangunnya, kami menjalankannya, dan kami hidup bersama setiap keputusan selama produk itu ada.

Ini bukan pernyataan branding. Ia mengubah bagaimana rekayasa itu sebenarnya bekerja, dengan cara-cara yang butuh waktu bagi kami untuk sepenuhnya menghargainya. Inilah yang dilakukan kepemilikan terhadap cara Anda membangun.

Ketika hubungan tidak berakhir saat serah terima

Ciri yang menentukan dari pekerjaan klien adalah bahwa ia memiliki akhir. Anda menentukan lingkup sebuah proyek, membangunnya, menyerahkannya, dan hubungannya pun tertutup. Apa pun yang terjadi pada perangkat lunak itu setelahnya — bug yang muncul di bawah beban nyata, jurang performa, tambalan keamanan yang tak pernah diterapkan — kini menjadi milik orang lain. Anda telah beralih ke kontrak berikutnya.

Memiliki produk Anda menghapus akhir itu. Tidak ada serah terima, tidak ada momen di mana kode berhenti menjadi masalah Anda. Kedengarannya seperti beban, dan pada beberapa hari memang begitu. Tetapi ia juga menghapus satu sumber terbesar dari jalan pintas dalam perangkat lunak: pengetahuan bahwa bukan Andalah yang akan berurusan dengan konsekuensinya. Ketika tidak ada jalan keluar, memangkas sebuah sudut bukanlah menghemat waktu — melainkan meminjamkan sebuah masalah kepada diri sendiri dengan bunga, dan Andalah yang melunasinya.

Setiap bug adalah bug Anda

Efek yang paling langsung adalah pada akuntabilitas, dan itu tidak abstrak. Setiap bug dalam produk KeepFlow adalah bug kami. Setiap regresi performa muncul dalam angka kami sendiri. Setiap pengguna yang frustrasi adalah putusan langsung atas pekerjaan yang kami lakukan. Tidak ada siapa pun untuk diserahi tiket itu.

Ini meruntuhkan sebuah tembok yang pemeliharaannya menyedot energi besar dari sebagian besar organisasi perangkat lunak — tembok antara orang yang menulis perangkat lunak dan orang yang mengoperasikannya. Di KeepFlow mereka adalah orang yang sama. Insinyur yang membangun sebuah fitur adalah orang yang mengawasinya di produksi, merespons ketika ia berdering pukul tiga dini hari, dan membaca apa yang dikatakan pengguna tentangnya.

Susunan itu tidak nyaman secara rancangan, dan itulah maksudnya. Ketika orang yang merilis kode adalah orang yang dibangunkan olehnya, insentif seputar kualitas berhenti menjadi sesuatu yang harus Anda paksakan dengan proses. Tidak ada yang mau men-debug jalan pintasnya sendiri pukul 3 dini hari. Tekanan untuk membangunnya dengan benar sejak awal datang dari struktur pekerjaannya, bukan dari sebuah dokumen kebijakan.

Membangun untuk masa pakai, bukan tenggat

Proyek klien terorganisasi di sekitar tenggat. Produk yang dimiliki terorganisasi di sekitar masa pakai, dan perbedaan itu menjangkau keputusan-keputusan teknis yang tampak identik di permukaan tetapi keluar dengan hasil yang berlawanan.

Ketika Anda membangun sesuatu yang akan Anda operasikan selama bertahun-tahun, perhitungan pada hampir setiap pilihan membalik:

  • Anda berinvestasi dalam observabilitas sejak awal, karena Andalah yang akan menatap dasbor pukul 2 dini hari, dan sebuah sistem yang tidak dapat Anda amati adalah sistem yang tidak dapat Anda jalankan.
  • Anda menulis pengujian yang tergoda Anda lewati di bawah tenggat, karena Andalah yang akan mengubah kode ini dua tahun lagi, jauh setelah Anda lupa cara kerjanya.
  • Anda memilih teknologi yang membosankan dan telah terbukti ketimbang kerangka kerja baru yang menarik, karena Anda mendaftarkan diri untuk memelihara keputusan ini dalam waktu yang sangat lama, dan kebaruan punya cara berubah menjadi liabilitas begitu hype-nya bergeser.

Tidak satu pun dari pilihan-pilihan ini membantu Anda merilis lebih cepat kuartal ini. Semuanya jelas benar begitu cakrawala waktu Anda diukur dalam tahun alih-alih minggu. Pekerjaan klien jarang menghargainya, karena orang yang membuat keputusan pertukaran itu bukanlah orang yang mewarisi biayanya. Kepemilikan menyelaraskan kedua orang itu menjadi satu.

Lingkar umpan balik menutup

Ada manfaat yang lebih halus yang butuh waktu lebih lama bagi kami untuk menyadarinya: ketika Anda memiliki produknya, lingkar antara masalah seorang pengguna dan perbaikannya menjadi jauh lebih pendek, karena tidak ada kontrak yang duduk di tengahnya.

Dalam pekerjaan agensi, mempelajari sesuatu tentang pengguna Anda sering kali merupakan awal sebuah negosiasi. Anda memperhatikan sebuah titik gesekan, tetapi bertindak atasnya berarti sebuah permintaan perubahan, sebuah percakapan penentuan lingkup, sebuah pernyataan kerja baru — dan pada saat semua itu selesai, wawasannya sudah basi. Ekonominya secara aktif mengecilkan hati untuk bertindak atas apa yang Anda pelajari, karena setiap perbaikan dapat ditagihkan dan karenanya diperdebatkan.

Ketika produknya milik Anda, memperhatikan dan memperbaiki adalah gerakan yang sama. Seorang insinyur membaca sebuah utas dukungan, mengenali pola di balik tiga keluhan, dan merilis perbaikannya sore itu juga — tanpa rantai persetujuan, tanpa faktur, tanpa perdebatan soal apakah itu dalam lingkup. Orang-orang yang paling dekat dengan masalah memiliki sekaligus konteks untuk memahaminya dan wewenang untuk menyelesaikannya. Selama berbulan-bulan, penggandaan perbaikan-perbaikan kecil yang tak terhambat itulah yang sebagian besar memisahkan produk yang orang toleransi dari produk yang orang andalkan.

Ia juga mengubah apa yang kami bangun sejak awal. Karena kami mengoperasikan segala yang kami buat, kami merasakan fitur kami sendiri yang hilang sebelum seorang pengguna pernah melaporkannya. Beberapa hal paling tajam dalam produk kami bermula sebagai gangguan yang salah satu dari kami temui sambil menjalankan produk lain di tim yang sama. Menjadi pelanggan Anda sendiri yang paling menuntut adalah sejenis riset yang tak dapat dibeli oleh brief klien mana pun.

Tidak mengejar tren

Ada godaan dalam industri ini untuk memperlakukan hal yang terbaru sebagai hal yang terbaik — untuk membangun ulang di atas kerangka kerja apa pun yang sedang menanjak, untuk mengejar pola arsitektur yang sedang ramai dibicarakan. Kami berusaha keras menahannya, dan kepemilikan membuat itu lebih mudah, karena kami merasakan seluruh biaya dari setiap tren yang kami kejar. Sebuah penulisan ulang yang sedang tren tahun ini adalah beban pemeliharaan yang kami pikul lima tahun berikutnya.

Yang kami bangun sebagai gantinya adalah infrastruktur yang diandalkan bisnis setiap hari: dukungan pelanggan yang harus menjawab, deteksi penipuan yang harus benar, moderasi yang harus cepat, alat-alat yang orang raih tanpa memikirkan apa yang ada di baliknya. Perangkat lunak semacam itu memperoleh kepercayaan secara perlahan, melalui kebajikan-kebajikan yang membosankan — keandalan, konsistensi, hadir dan berfungsi. Kebajikan-kebajikan itu tidak datang dari kebaruan. Mereka datang dari kepedulian terhadap sesuatu cukup lama untuk membuatnya benar, lalu tetap tinggal untuk menjaganya tetap demikian.

Itulah keseluruhan alasan kami membangun produk kami sendiri. Bukan karena itu lebih mudah — memang tidak — tetapi karena hidup bersama keputusan Anda adalah cara paling tepercaya yang kami tahu untuk membuat keputusan yang baik.