post-image

Kerja di Software House vs Product-Based Company

29 Oktober 2022

Explicit

Read in English
Share on Twitter

Daftar Isi

Introduction

Ini sekedar testimoni saya selama bekerja di software-house company selama setahun lebih kemudian pindah ke company product-based sejak awal 2022. Mungkin tidak 100% valid dan terlihat “opiniated”, ini sekedar cerita pengalaman saja.

Seperti yang beberapa teman-teman tahu, saya pernah bekerja di sebuah software house, kemudian pindah ke company sekarang yang tergolong sebagai product-based company. Seperti yang saya tweet di Twitter saya sebelumnya, saya akan coba jelaskan perbedaan bekerja di software house company vs product-based company dari perspektif pengalaman pribadi.

Task Management

Seperti yang kita sama-sama tahu, software house company ini secara umum adalah perusahaan yang menyediakan layanan atau membuatkan project untuk client yang ingin menggunakan jasanya. Dengan kata lain, ini seperti third party yang membuatkan atau men-deliver request client. Sementara product-based company ini adalah perusahaan yang punya produknya sendiri yang dijual kepada user. Biasanya mereka sudah punya tim sendiri untuk mengembangkan produknya.

Nah, noticesesuatu di sini?

Saya sempat bekerja di sebuah software house sejak September 2020 - November 2021. Cukup banyak project dari client yang telah didevelop di perusahaan tersebut. Seperti yang beberapa teman tahu, saat itu saya di-assign kepada satu client BUMN untuk mengembangkan aplikasi perkeretaapian, yaitu KAI. Saat itu saya bersama seorang senior mengembangkan aplikasi mobile KAI Access.

Singkatnya, dari KAI sendiri telah menyediakan semua dokumentasi dan requirement yang diperlukan, lalu kami tinggal mengerjakannya saja. Ketika dari mereka berkata A, maka kami pun harus men-deliver itu sesuai permintaan mereka. Mustahil untuk menginterfensi. Dengan kata lain, saya hanya boleh deliver project-nya sesuai dengan request. Sebenarnya bisa saja menyampaikan concern tertentu bila ada, tetapi birokrasinya sangat rumit dan memakan waktu, bahkan bisa berpotensi membuat sang client kehilangan kepercayaan, apalagi software house ini sangat bergantung kepada client untuk menghasilkan profit.

Sulit untuk menerapkan Agile di sini. Seringnya, kami bekerja secara Waterfall yang mana request datang dari client dan kami harus men-delivernya. Saya sempat mencoba mengimplementasikan metode Agile seperti Scrum atau Kanban, tetapi ujungnya gagal karena project harus di-deliver dengan tepat, bukan dengan iterasi. Dengan kata lain, saya bekerja berdasarkan request dan harus deliver itu secara akurat.

Singkat cerita saya resign dari tempat tersebut lalu mendapatkan pekerjaan di tempat yang sekarang sejak Januari 2022. Kali ini saya bekerja di sebuah tech hospitality company yang menyediakan layanan booking hotel kapsul atau cabin. User juga bisa menggunakan smartphone mereka sebagai kunci untuk masuk ke kamar hotel mereka menggunakan QR Code.

Kali ini, saya di-assign untuk mengerjakan product utamanya di bagian website. Sebenarnya sih tugas utama saya sekarang ini rewrite semua code base yang ada di website sekarang dari Nuxt.js ke Next.js🤣.

Fokus utama sekarang adalah mengambangkan website utama dari perusahaan tempat saya bekerja saat ini. Request atau inisiatif biasanya datang dari Product Manager/Owner kemudian design mockupnya akan dibuatkan oleh Product Designer hingga akhirnya diserahkan kepada saya untuk dikerjakan. Tapi sebelum handover, kami biasanya mendiskusikan hal tersebut dahulu dan membicarakan concern bila ada sehingga semua saling tahu apa yang jadi blocker dan pengaruhnya terhadap timeline produk. Terkadang, kalau saya ada concerntertentu terhadap design web-nya, Product Designer akan mengubahnya sesuai feedback yang diberikan, sehingga proses developmentbisa lebih dipermudah dan cepat. Terasa lebih demokratis ya🤣.

Kali ini, tempat yang sekarang lebih Agile terutama untuk development cycle-nya. Kebanyakan kita menggunakan Kanban untuk setiap task, tetapi kami selalu rutin mengadakan sprint planningtiap minggunya di hari Senin untuk menentukan taskapa saja yang akan dikerjakan selama seminggu. Sisa task minggu lalu akan di-assign kembali di sprint berikutnya (minggu berikutnya).

Berdasarkan teori Agile, kami biasa mengembangkan sebuah fitur atau request menggunakan teknik iterasi di setiap sprint-nya. Tim product akan mengerjakan riset terhadap behavior user atau complain dari user, kemudian hasilnya akan dipertimbangkan menjadi task di sesi sprint planning Dengan kata lain, akan ada update secara konstan setiap minggunya (setiap sprint cycle). Tetapi tenang saja, sang manager telah menentukan batas maksimal sprint point yang bisa diambil oleh tiap engineer agar menghindari overwork.

Struktur Tim

Untuk struktur tim, saya bisa katakan bahwa software house memiliki tim yang lebih beragam atau diverse. Setiap timnya akan dikelompokan berdasarkan client yang di-assign yang pastinya punya konteks tersendiri sesuai requirement-nya. Contohnya, saat itu saya tergabung dalam tim yang mengembangkan aplikasi perkeretaapian dari client BUMN. Simpelnya, saya bersama senior saya fokus untuk deliver project dari client BUMN tersebut (walaupun terkadang kami juga berpindah ke tim lain untuk membantu menyelesaikan project-nya). Berganti tim di sini seperti berganti perusahaan tetapi dengan gaji dan benefit yang sama🤣.

Di tempat yang sekarang, sama sih ada squad-nya juga. Tetapi kali ini, karena product-based, setiap squad sebenarnya punya kemiripan topik, karena perusahaan memiliki product-nya sendiri, yaitu capsule/cabin hotel booking app. Timnya akan di-assign berdasarkan fokus utama dari sub-product atau fitur yang dikembangkan. Misalnya, sekarang squad saya fokus untuk mengembangkan service yang berkaitan dengan customer-facing, seperti website utama yang dipakai oleh user. Ada juga tim lain yang fokusnya mengembangkan internal-tools atau internal platform.

Kultur Kerja

Sepanjang saya bekerja di software house, saya bisa katakan bahwa deliver project itu adalah fokus utama. Yang berarti, setiap project harus di-deliver tepat waktu dan sesuai dengan keinginan client. Dengan kata lain, biasanya ketika ada request tertentu, itulah saat-saat di mana para programmer jadi hectic. Tapi sekalinya request sedang sedikit atau bahkan tidak ada, kami pun seperti pengangguran yang datang ke kantor🤣. Seperti yang sempat saya singgung di section pertama, sangat sulit untuk menerapkan Agile di sini, karena kebanyakan Waterfall based.

Ada juga beberapa waktu yang mana saya dan senior saya harus bertemu dengan client untuk diskusi requirement, timeline project, dan kontrak dokumentasi lainnya. Jujur, di sinilah kemampuan komunikasi saya tertantang. Dan ya, omong-omong saya WFO saat itu setiap hari bahkan saat Covid-19 masih ramai-ramainya, jadi cukup terasa lelahnya karena ada waktu commuting dan sulit menemukan waktu senggang, apalagi ketika sedang hectic-nya.

Di tempat sekarang gimana?

Jujur, ketika pindah ke yang sekarang, agak culture shock😅. Kali ini saya malah harus Agile di sini. Seperti yang sempat saya singgung di section pertama, kulturnya lebih demokratis. Setiap engineer bahkan punya hak berkata “tidak” pada suatu task atau inisiatif yang tidak memiliki korelasi dengan role utama mereka, atau kadang bisa meminta adjustment terhadap request atau inisiatif yang diberikan apabila ada concern tertentu. Dengan kata lain, untuk mengubah suatu product initiative menjadi sebuah task, itu harus melewati tahap riset yang cukup panjang dan kemudian harus didiskusikan dahulu dengan anggota tim terkait, sehingga sama-sama saling tahu konteksnya.

Kalau kultur meeting? Sebenarnya itu tergantung squad. Di kasus saya, karena saya mengerjakan service yang berkaitan dengan customer-facing, itu berarti saya kebanyakan harus align dengan tim product dan marketing karena itu merupakan platform utama yang dipakai user dan merupakan platform operasional utama. Jadi, tetap skill komunikasi dan negosiasi saya harus diasah lagi di sini😀.

Tetapi perbedaan utamanya, saya lebih fokus mengembangkan product-nya, sekalipun terkadang masih harus switching context karena ada saja alignment yang harus saya ikuti karena terkait web yang saya kembangkan😅. Dan yang paling saya sukai di sini adalah previledge bisa WFH atau WFA. Saya hanya perlu ke kantor sebulan sekali untuk meetup bulanan bersama para kolega setelah sebulan bekerja jarak jauh.

Kalau kultur coding-nya gimana?

Nah ini mungkin agak “opiniated”, tapi saya coba jelaskan secara umum ya. Waktu di software house, mentalnya adalah mental proyek yang berarti harus deliver project tepat waktu dan akurat sesuai request client. Jujur, sangat dilematis ketika ingin menerapkan clean code pattern di sini, karena deadline yang mepet dan request yang “ngadi-ngadi”. Fokusnya di sini adalah menyelesaikan dan deliver project-nya.

Di tempat sekarang, saya menyadari bahwa develop suatu product sangat berbeda dari sekedar mengerjakan project. Product punya lifetime yang lebih panjang, dan tidak bisa dikembangkan secara bar bar. Setiap inisiatif produk harus diriset dahulu oleh tim product, untuk kemudian diserahkan kepada engineer terkait untuk dikerjakan. Saya bisa katakan, saya pun juga harus membuat kodingan yang lebih clean sehingga product-nya bisa lebih sustain dan maintainable dalam jangka panjang. Code review di sini adalah kewajiban dan pastinya untuk memastikan kodingan saya sudah efektif atau belum🤣.

Penutup

Nah itulah cerita saya sepanjang bekerja di software house kemudian pindah ke company yang product-based. Saya tidak bermaksud memojokan pihak manapun, hanya menceritakan pengalaman saja😁. Semuanya bagus kok, hanya tergantung preferensi masing-masing mau kerja di mana.

Kalau ada yang tanya, lebih baik kerja di mana, software house atau product-based company? Tergantung. Kalau menurut saya pribadi, apalagi jika masih fresh graduate, lebih baik mulai bekerja di software house dulu sebagai batu pijakan karir. Kenapa? Karena kamu bisa dapat banyak pengalaman dari project-project yang di-handle. Bahkan kamu juga bisa belajar banyak dari client-client di perusahaanmu.

Tapi di kasus saya sih, setelah bekerja setahunan di software house, agak burnout karena terlalu banyak project dan client yang harus dihandle. Itulah yang membuat saya memutuskan untuk pindah ke company yang product-based untuk bisa fokus mengembangkan satu product dalam jangka panjang, sekaligus melatih diri untuk bisa membuat kodingan yang lebih clean. Juga, bekerja di product-based company ini sangat melatih saya untuk menjadi product-minded software engineer, sehingga saya pun harus memastikan setiap kodingan saya harus align dengan kebutuhan user dalam jangka panjang.

Sulit untuk bercerita panjang lebar di sini sebanarnya🤣. Tak apa apabila mau berdiskusi lebih lanjut di kolom komentar atau DM Twitter saya. Saya akan mencoba balas di kala senggang. Semoga membantu, terima kasih.

Back To Articles Page
Home
Projects
Articles
About Me