Sebuah Perahu Kecil di Tengah Ancaman Badai

M. Abdul Aziz
3 min readFeb 16, 2023

--

Saya bergabung di sebuah startup SAAS (Software as a Service) pada pertengahan 2019 sebagai Frontend Engineer, dan di awal tahun 2022 saya dipromosikan sebagai Technical Lead.

Kenapa Memutuskan untuk Membuat Tim Sendiri?

Selama kurang lebih 2 tahun sebagai Frontend Engineer saya selalu disibukkan dengan fitur fitur fitur dan fitur, ya karena pada saat itu banyak fitur dan produk baru yang lagi kita develop. Kurangnya waktu untuk melakukan tech debt atau improvement membuat kita selalu merasa was was dengan apa yang akan terjadi di masa yang akan datang.

Bug Free

Akhirnya masa itu datang, Banyak komplain dari end user, client dan product team. Mulai dari bug-bug yang muncul ke permukaan, web semakin lemot, produktivitas menurun, dll. Sehingga kita perlu awak awak perahu tambahan untuk bisa tetap survive ditengah badai.

Saling Berbagi Peran

Perahu ini terdiri dari 7 awak:

  • 4 awak sebagai Frontend Engineer termasuk saya.
  • 2 awak sebagai Quality Assurance (1 manual dan 1 automation).
  • 1 awak sebagai Backend Engineer (untuk men-support kebutuhan internal).

4 awak Frontend Engineer dibagi menjadi 2 fokus:

  • Sprint — 2 awak fokus untuk men-support kebutuhan tim produk dan bug fixing.
  • Improvement — 2 awak fokus untuk melakukan improvement, dan membuat rencana kedepan.

Ya, komposisi team diatas sudah cukup untuk kita tetap bertahan, memperbaiki yang rapuh dan mulai memikirkan apa yang akan dilakukan untuk kedepannya.

Berhenti Sejenak untuk Belari Lebih Jauh Lagi

Ini adalah saatnya untuk berhenti sejenak, memperbaiki dan bersiap untuk berlari lebih jauh lagi.

Setelah sekian lama berlari dan mulai tersadar, ada hal-hal yang mulai menjadi hambatan, ancaman, dan jika dibiarkan terus menerus perahu akan rusak dan kita tidak bisa melanjutkan untuk berlayar.

Beberapa hal yang menjadi ancaman:

  • Long build times — Waktu yang dibutuhan untuk build suatu project ≤ 20 menit, ini menandakan project kita sudah terlalu besar. Bayangkan ketika kita hanya melakukan update wording atau fixing dibagian kecil saja, kita harus menunggu 20 menit supaya code kita ter-deploy.
  • Performance Issues — Ada kalanya web kita menjadi lemot ketika suatu client sedang menjalankan campaign, apalagi mereka punya user ribuan bahkan puluhan ribu.
  • Slower development speed — Karena project kita sudah terlalu besar, complicated, dan tidak ada unit test, membuat kita harus extra hati” jika melakukan perubahan diantara ribuan code.
  • Lack of flexibility — Tren teknologi sangatlah cepat berubah, setiap bulan/tahun selalu ada yang baru, Sangatlah tidak mungkin untuk kita tetap up to date terhadap perubahan dan pada akhirnya kita terus melanjukan code yang dibuat dari 4–5 tahun lalu.

Untuk mengatasi masalah diatas, Kami memulai dengan pendekatan ini.

Terimakasih sudah membaca.

--

--