Cara Menjalankan Build Software Tanpa Menjadi Project Manager

Pemilik UKM manufaktur Surabaya pernah menggambarkan apa yang dia pikir salah di build software kustomnya: “Saya menghabiskan separuh minggu saya menjadi wasit meeting antara staf saya dan vendor. Saya tidak daftar jadi project manager.”

Dia benar. Dia seharusnya tidak harus jadi satu. Build-nya distrukturisasi dengan buruk, dan dia membayarnya dengan waktunya.

Berikut cara menjalankan proyek software kustom sebagai pemilik bisnis tanpa berakhir sebagai PM de facto.

Apa yang seharusnya Anda lakukan

Tiga hal, dengan baik:

1. Mendefinisikan sukses seperti apa. Bukan fitur — hasil bisnis. “Kurangi waktu pemrosesan order di bawah 60 detik.” “Kurangi pekerjaan laporan bulanan ke di bawah 4 jam.” Tanpa ini, setiap keputusan jadi tentang preferensi alih-alih hasil.
2. Menyetujui perubahan scope. Saat vendor atau tim Anda ingin menambah atau menghapus sesuatu, Anda putuskan berdasarkan apakah itu melayani metrik sukses. Ini keputusan 5 menit per perubahan, bukan meeting.
3. Penerimaan di milestone. Setiap 2–4 minggu, tim demo progres. Anda verifikasi itu melacak ke metrik sukses dan menyetujui pindah ke fase berikutnya.

Itu saja. Masing-masing butuh beberapa jam per bulan, total. Kalau investasi waktu Anda lebih besar dari itu, proyeknya distrukturisasi salah.

Apa yang seharusnya tidak Anda lakukan

Lima hal pemilik umumnya tersedot dan seharusnya tidak:

• Standup harian. Anda tidak perlu hadir. Tim memakainya; mereka tidak butuh penonton.
• Memediasi antara staf dan vendor. Itu pekerjaan siapa pun yang menjalankan proyek di kedua sisi. Kalau mereka tidak bisa bicara langsung, itu masalah untuk diperbaiki, bukan meeting untuk dihadiri.
• Review desain atau wireframe detail. User utama (orang yang sebenarnya melakukan pekerjaan yang software dukung) review ini. Penilaian mereka mengalahkan Anda di spesifik alur kerja.
• Mentriase bug. Itu pekerjaan tim. Anda lihat laporan bug sebagai angka ringkasan, bukan tiket individual.
• Memilih implementasi teknis. “Harus pakai library X atau Y” bukan keputusan Anda.

Kalau Anda menemukan diri Anda melakukan apapun ini secara reguler, struktur proyek rusak.

Struktur yang melindungi waktu Anda

Apa yang harus ada dari minggu pertama:

Satu owner di setiap sisi

Satu orang di sisi vendor memiliki proyek. Satu orang di sisi Anda juga. Orang kedua ini tidak harus PM — mereka sering lead user atau kepala operasi. Tapi mereka punya otoritas untuk membuat keputusan harian dan mewakili bisnis dalam percakapan.

Kedua owner bicara langsung satu sama lain. Anda hanya dikonsultasi saat keputusan melebihi otoritas mereka.

Kriteria eskalasi yang jelas

Definisikan apa yang datang ke Anda vs yang tidak:

• Datang ke Anda: perubahan scope bernilai lebih dari X jam pekerjaan, overrun budget, keputusan hire/fire tentang anggota tim, keputusan yang mempengaruhi strategi bisnis.
• Tidak datang ke Anda: pilihan implementasi teknis, prioritisasi harian, detail desain, triase bug.

Saat sesuatu tidak jelas, default-nya harus “owner memutuskan dan menginformasikan Anda”, bukan “eskalasi.”

Update tertulis mingguan, bukan meeting

Tulisan 15 menit sekali seminggu. Tiga bagian: apa yang ship, apa yang blocked, apa keputusan yang dibutuhkan dari Anda. Anda baca dalam 5 menit. Kalau semuanya on track, Anda tidak balas. Kalau ada yang butuh perhatian, Anda balas.

Praktik tunggal ini menggantikan 80% meeting yang owner ditarik ke dalamnya.

Cadence demo, bukan cadence deadline

Setiap 2–4 minggu tim demo software yang bekerja, bukan slide. Anda verifikasi demo terhadap metrik sukses, menyetujui atau course-correct.

Cadence demo membuat semua orang jujur. Sulit memalsukan progress saat Anda harus menunjukkan software bekerja setiap dua minggu.

Red flag selama build

Hal yang berarti strukturnya rusak:

• Anda diminta membuat keputusan kecil beberapa kali seminggu. Berarti struktur owner-di-setiap-sisi tidak bekerja. Perbaiki sebelum melanjutkan.
• Update status adalah slide deck alih-alih software bekerja. Berarti belum ada yang bekerja. Minta demo.
• Tim menghindari menulis hal. Berarti akuntabilitas dihindari. Tegaskan update tertulis.
• Keputusan dibuat di meeting di-litigasi ulang minggu depan. Berarti otoritas pengambil keputusan tidak jelas. Eja.

Mindset owner yang bekerja

Dua pergeseran mental yang membantu:

• Perlakukan tim seperti kontraktor membangun rumah. Anda tidak memberi tahu mereka cara mencampur beton atau urutan memasang perabot. Anda inspeksi di milestone dan terima atau tolak.
• Pekerjaan Anda “kenapa”, bukan “bagaimana”. Saat Anda menemukan diri Anda di percakapan “bagaimana”, tanya “hasil bisnis apa yang ini layani?” Kalau Anda tidak bisa jawab, Anda di meeting yang salah.

Kalau Anda mendekati proyek software kustom dan ingin set up sehingga Anda tetap di jalur Anda, satu jam percakapan biasanya menjernihkan struktur yang tepat untuk situasi spesifik Anda. Kami melakukannya tanpa biaya.