3.1 Pekerjaan Selesai, Tapi Apakah Ada Value?

Seorang kepala produk di perusahaan layanan digital bercerita kepada saya. Timnya menyelesaikan dua puluh fitur besar dalam satu kuartal. Sprint berjalan lancar. Tidak ada delay. Kode sudah di-production. Semua orang merasa produktif.

Tapi ketika angka bisnis keluar, tidak ada yang berubah. Jumlah kontrak baru tetap sama. Waktu penyelesaian layanan tidak berkurang. Retensi pelanggan tidak naik. Bahkan biaya operasional malah bertambah karena ada sistem baru yang harus dirawat.

Tim itu menyelesaikan banyak pekerjaan. Tapi tidak ada value yang lahir.

Situasi ini tidak unik. Banyak tim teknis bekerja keras, menyelesaikan task, menutup tiket, dan deliver tepat waktu. Tapi ketika ditanya apa yang berubah untuk bisnis, jawabannya sering kabur. Output-nya banyak. Outcome-nya nol.

Masalahnya terletak pada cara kita menilai kelayakan pekerjaan. Selama ini kita terbiasa mengukur dari volume: berapa fitur selesai, berapa story point, berapa persen coverage. Ukuran-ukuran itu nyaman karena mudah dihitung. Tapi mereka tidak menjawab satu pertanyaan fundamental: apakah pekerjaan ini menghasilkan sesuatu yang berharga?

Diagram berikut menggambarkan dua jalur yang sering terjadi dalam pengambilan keputusan teknis.

flowchart TD A[Mulai] --> B{Pertanyaan awal?} B -->|Fokus Output| C[Banyak fitur selesai] C --> D[Tidak ada perubahan bisnis] D --> E[Lingkaran Merah: Nol Value] B -->|Fokus Value| F[Untuk siapa? Masalah apa? Ukuran apa?] F --> G[Perubahan positif terukur] G --> H[Lingkaran Hijau: Value Nyata]

Value adalah ukuran utama kelayakan pekerjaan teknis. Bukan seberapa banyak yang dikerjakan, tapi seberapa besar perubahan positif yang terjadi. Value bisa muncul dalam berbagai bentuk: waktu proses yang lebih cepat, jumlah kesalahan yang turun, layanan yang lebih baik, keputusan yang lebih akurat, kemampuan baru yang sebelumnya tidak ada, atau biaya per transaksi yang menurun.

Di tim layanan digital tadi, mereka membangun fitur-fitur yang menarik secara teknis. Tapi tidak ada yang bertanya: fitur ini untuk siapa, masalah apa yang diselesaikan, dan bagaimana mengukurnya. Mereka hanya menerima request, memperkirakan effort, lalu mengerjakan. Tidak ada tahap evaluasi value.

Inilah yang membedakan arsitek dari programmer biasa. Programmer biasa melihat pekerjaan sebagai daftar task yang harus diselesaikan. Arsitek melihat pekerjaan sebagai investasi yang harus menghasilkan return. Sebelum memutuskan mengerjakan sesuatu, arsitek bertanya: apa valuenya, dan bagaimana kita tahu value itu tercapai?

Di zaman AI, pertanyaan ini menjadi semakin penting. AI menurunkan effort dan biaya per inisiatif. Dengan kata lain, lebih banyak hal menjadi feasible. Tapi kemudahan ini juga jebakan. Jika kita tetap memakai ukuran volume, kita akan mengerjakan lebih banyak hal yang tidak bernilai. AI hanya mempercepat produksi output yang tidak menghasilkan outcome.

Maka langkah pertama yang harus dibangun adalah kebiasaan bertanya tentang value sebelum memulai pekerjaan. Bukan setelah selesai. Bukan saat retrospektif. Tapi di awal, saat ide masih bisa diubah, saat effort belum dikeluarkan, saat tim belum komit.

Bab ini akan membahas bagaimana mengukur value secara praktis, bagaimana menghitung effort dan biaya termasuk setelah AI masuk, bagaimana memanfaatkan AI leverage, dan bagaimana menghitung return agar keputusan investasi teknis menjadi lebih tajam. Semua dimulai dari satu pertanyaan sederhana yang jarang ditanyakan: pekerjaan ini selesai, tapi apakah ada value?