Memilih Proyek sebagai Konsultan/Freelancer Paruh Waktu

Sebagai orang IT yang juga punya pekerjaan tetap, saya cukup sering ditawari proyek sampingan — mulai dari bikin sistem kecil untuk klinik, benerin aplikasi yang "tinggal dikit lagi", sampai jadi konsultan lepas untuk migrasi infrastruktur. Godaannya besar: tambahan penghasilan, portofolio baru, atau sekadar validasi bahwa skill kita masih dicari pasar. Tapi waktu dan energi itu terbatas, apalagi kalau siang hari sudah habis untuk tanggung jawab sebagai Kepala IT. Masalahnya bukan "apakah saya bisa mengerjakan ini", tapi "apakah proyek ini sepadan dengan yang harus saya korbankan". Berikut kriteria yang biasa saya pakai untuk menyaring tawaran proyek paruh waktu.

Kecocokan dengan Stack dan Konteks yang Sudah Dikuasai

Proyek paling efisien buat dikerjakan paruh waktu adalah yang berada di jalur kompetensi yang sudah kuat, misalnya Laravel, Vue, Filament, atau setup Docker yang sudah biasa saya pakai sehari-hari. Bukan berarti tidak boleh ambil hal baru, tapi kalau waktu kerja hanya beberapa jam per hari di luar jam kantor, kurva belajar yang curam akan memakan jatah waktu yang seharusnya dipakai untuk mengeksekusi. Saya biasanya bertanya: kalau saya kerjakan ini, apakah saya akan lebih cepat karena sudah pernah menghadapi masalah serupa, atau saya justru akan menghabiskan separuh waktu untuk riset dari nol? Proyek yang jawabannya "lebih cepat" jauh lebih realistis untuk paruh waktu dibanding proyek yang menuntut stack atau domain yang benar-benar asing.

Kejelasan Scope dan Ekspektasi Waktu

Proyek sampingan yang paling menguras energi bukan yang sulit secara teknis, tapi yang scope-nya cair. Kalau brief-nya masih berupa satu paragraf samar seperti "bikin sistem yang bisa handle semua kebutuhan operasional", itu tanda bahaya. Sebelum menyanggupi, saya minta gambaran fitur inti, batas waktu, dan siapa yang akan memutuskan "sudah selesai". Kalau klien belum bisa menjawab tiga hal itu, saya anggap proyeknya belum siap dikerjakan, meski secara teknis saya sanggup. Sebagai ilustrasi, kalau dalam sepekan saya hanya punya waktu efektif sekitar 8-10 jam di luar pekerjaan utama, saya akan memecah scope proyek menjadi milestone kecil yang muat di jatah waktu itu, supaya progres tetap terlihat tanpa mengorbankan kualitas kerja utama saya.

Rasio Nilai terhadap Beban, Bukan Sekadar Nominal

Bayaran yang menarik gampang membuat kita lupa menghitung beban tersembunyi: revisi berulang, komunikasi yang lambat, atau maintenance jangka panjang yang tidak dibayar terpisah. Saya mulai membiasakan diri melihat proyek dari tiga lensa: nilai finansial, nilai pembelajaran (apakah ini memperkuat skill yang mau saya dalami), dan nilai relasi (apakah klien atau kontaknya berpotensi jadi sumber proyek lain ke depan). Kalau sebuah proyek lemah di ketiga lensa itu — bayaran pas-pasan, tidak ada hal baru yang dipelajari, dan relasinya tidak akan berlanjut — biasanya saya tolak, seberapa pun kelihatannya "gampang dikerjakan". Sebaliknya, proyek dengan bayaran sedang tapi membuka pintu ke domain baru, misalnya integrasi AI/LLM ke sistem yang sudah ada, sering saya prioritaskan karena nilai jangka panjangnya.

Sinyal Klien Sejak Awal Komunikasi

Cara calon klien berkomunikasi di tahap awal biasanya jadi indikator kuat bagaimana proyek akan berjalan. Respons yang jelas, pertanyaan yang terarah, dan kesediaan menuliskan kesepakatan di awal — meski hanya lewat email atau dokumen singkat — biasanya berbanding lurus dengan proyek yang lancar. Sebaliknya, permintaan untuk "mulai kerja dulu, detail nanti dibicarakan" adalah pola yang sering berujung pada scope creep. Untuk proyek paruh waktu, saya tidak punya buffer waktu untuk menangani ketidakjelasan semacam itu, jadi saya jadikan ini salah satu filter paling awal, bahkan sebelum membahas soal teknis atau harga.

Takeaway

Intinya, menyaring proyek sampingan itu soal melindungi waktu yang sudah sempit, bukan soal menolak peluang. Empat pertanyaan yang saya pakai: apakah ini di jalur kompetensi saya, apakah scope dan waktunya jelas, apakah rasio nilai-terhadap-bebannya masuk akal, dan apakah sinyal komunikasi klien di awal sudah baik. Kalau minimal tiga dari empat itu terpenuhi, biasanya proyek tersebut layak diambil.