Fitur Besar bikin Pusing? Begini Cara Manage-nya

“Duh ini fitur gede banget, aku harus mulai darimana ya?” — sering terjadi bagi para fresh grad maupun anak internship.

Masalah ini sering muncul saat menganggap sebuah fitur terlalu besar, terlalu ruwet. Padahal sebenernya nggak gitu. Tenang, saya bisa kasih insight dan tips untuk manage hal tersebut.

Poin Pertama: Fokus Saat Meeting

Tarik garis lurus kebelakang—yaitu saat meeting development. Pastikan kamu bener-bener fokus terhadap apa yang akan dikerjakan, terutama bagian kamu.

Jangan pas meeting:

• ❌ Raga kamu ada di zoom meeting
• ❌ Jiwa kamu ada di rumah pacar (kalo punya)
• ❌ Lagi sibuk mikirin pengen makan apa nanti malem

Itu memang bukan hal yang mudah, tapi segalanya dimulai dari situ. Kalo kamu aja nggak bisa fokus terhadap sesuatu—terutama saat pembahasan fitur yang kamu harus kerjakan—kamu akan kehilangan banyak hal.

CATAT!

Catat poin-poin penting saat meeting. Saya biasanya mencatat di notepad bawaan laptop untuk poin-poin apa sekiranya dari fitur yang harus didevelop.

Sebagai lead engineer, saya juga mencatat poin-poin dari fitur yang related sama backend—termasuk:

• Apa yang harus dilakukan oleh team backend
• Ngaruh ke siapa?
• Blocker di bagian mana?
• Poin apa yang harus didahulukan?
• Migration mana yang paling priority?

Sampe cukup detail saya pikirin saat meeting. Kalo emang perlu mencatat ya catat—jangan simpan di kepala. Kepala kamu bukan harddisk, kamu bisa lupa tiba-tiba.

Poin Kedua: TANYA!

Pepatah “malu bertanya sesat dijalan” emang jelas-jelas terbukti.

Kalo lagi meeting dan masih bingung sama FLOW dari fitur itu—tanya.

INGET: Tanya flow, bukan teknis. Ngga semua orang di meeting paham pendekatan teknis.

Bedanya Tanya Flow vs Teknis

Flow (Boleh ditanyakan di meeting):

• “Ooh berarti ntar user kalo klik tombol itu, nanti muncul pesan x gitu?”
• “Data tersebut bisa dihapus kan?”
• “Nanti kalo diklik itu ngirim email ngga?”

Teknis (Simpan untuk diskusi setelah meeting):

• “Cara ngirimnya gimana ya mas?” — Yaelah bro, belom dibaca docsnya aja udah panik.

Contoh tanya teknis yang singkat & oke:

“Mas andi, nanti SMS-nya pake provider apa ya? Saya kurang tau nih mas.”

Jawaban singkat:

“Oh nanti pake Twilio aja, kamu baca docsnya aja dulu, cobain dulu.”

Singkat padat jelas kan? Kamu langsung tau nama provider API-nya, tinggal kesediaanmu untuk membaca dan mencoba.

Kenapa Meeting Harus Efektif?

Meeting itu SANGAT melelahkan. Di tempat saya, meeting sprint sangat dibatasi dan diusahakan maksimal 1 jam. Karena setelah 1 jam, biasanya fokus udah hilang dan buyar.

Bayangin: lo duduk empat jam meeting, apa ngga meledak kepala lo berpikir?

Hasilnya sangat efektif: tim jadi tau secara flow apa yang harus dikerjakan, dan gambarannya kaya apa. Meeting jadi nggak ngabisin waktu dan bisa mulai kick off rencana development.

Rencana Development ≠ Meeting

“Loh rencanain development emang ngga termasuk meeting?”

Ngga brow, ini tuh sesi yang berbeda. Biasanya rencana development itu jatohnya jadi tim ad hoc untuk diskusi ringan—bahkan sambil nyender di sofa juga gapapa.

Beda sama meeting keseluruhan yang literally harus fokus memperhatikan:

• Sprint besok mau ngapain?
• Fitur apa aja?
• Apa goalnya?
• Apa yang bisa diimprove?

Pas rencana development, ngomonginnya udah teknis—fitur x yang melibatkan Andi, Budi, Charlie, ya bertiga aja ngomongin. Boleh di ruang santai, di meja masing-masing, di pantry, bebas yang penting nyaman.

Poin Ketiga: Jangan Pilih-Pilih

Ngga semua team IT mempersilahkan anggotanya untuk pilih-pilih fitur. Umumnya yang dipersilahkan memilih adalah kalo teamnya udah capable dan bisa saling backup.

Biasanya kalo anak baru, umumnya didorong atau dipilihin sama lead eng atau seniornya. Selain karena lead engnya tau beban itu seberat apa, gunanya untuk menguji kamu—seberapa kuat mentalitas kamu ngerjain itu?

Jangan Takut

Jangan berpikir: “Ah aku ngga mau ambil fitur itu karena gede banget, aku takut.”

Lho kalo kamu takut terus kapan beraninya? Justru kamu diceburin biar sekalian berjuang untuk ngga tenggelem. Kan sifat alami manusia itu bertahan hidup. Kalo diceburin, kamu pasti bakalan berjuang keras untuk tidak tenggelam.

Mungkin Itu Ujian

Kadang lead engineer atau senior ngasih task ke kamu nggak serta merta karena “dia mau.” Bisa jadi itu:

• Titipan CTO
• Titipan level C lainnya
• Atau bahkan titipan foundernya

Tujuannya untuk menguji kamu lagi: kamu bener-bener layak ngga sebenernya?

Kesimpulan

Manage fitur besar itu nggak seseram yang dibayangkan:

1. Fokus saat meeting — Catat poin-poin penting
2. Tanya flow, bukan teknis — Jangan malu bertanya
3. Jangan pilih-pilih task — Terima tantangan sebagai ujian
4. Bertahan hidup — Berjuang untuk ngga “tenggelem”

Kadang lead engineer atau senior ngasih task itu ke kamu bukan karena “dia mau”, bisa jadi itu titipan CTO, titipan level C lainnya, atau bahkan titipan foundernya, tujuannya untuk menguji kamu lagi, kamu bener-bener layak ngga sebenernya?

Jadi, siap menerima tantangan fitur besarmu? 🚀