Investasi di tools

Dapatkah produktivitas di startup tercapai dengan cara yang efektif namun sekaligus efisien?

Investasi di tools

Pengalaman gue bekerja masih relatif sedikit, apalagi di dunia per-start-up-an.

Tapi gue ada beberapa teman yang tersebar di berbagai perusahaan rintisan, dan sebagaimana yang kita tau, pengalaman adalah tentang menghubungkan pengetahuan-pengetahuan yang didapat.

Sebagai sangkalan, perusahaan rintisan disini mengacu ke perusahaan yang skala menengah kebawah, yang bukan merupakan seekor kuda ber-tanduk yaa yang meskipun beberapa ada juga yang bekerja disana.

Oke kembali ke pembahasan, dari cerita-cerita yang didapat, ada satu masalah yang sama-sama dimiliki hampir oleh setiap organisasi—selain tentang sumber daya—yakni tentang produktivitas.

Perusahaan-perusahaan digital tersebut pada dasarnya membuat dan mengembangkan sebuah produk. Produk sederhananya adalah barang/jasa yang dapat diperjual belikan, intinya adalah sesuatu yang di produksi.

Untuk memproduksi sesuatu, kita membutuhkan seseorang yang dapat memproduksinya.

Sederhana.

Maka dari itu banyak organisasi yang membutuhkan bantuan untuk dapat melakukan produksi tersebut salah satunya dengan melakukan proses pencarian pekerja.

Dan itu umum.

Semakin banyak produsen, dapat diasumsikan berarti semakin banyak yang bisa diproduksi.

Yang berarti semakin efisien.

Tapi kita sedang berbicara tentang perusahaan rintisan, efisiensi lebih utama daripada efektif mengingat kas yang dimiliki perusahaan rintisan relatif terbatas.

Sebelum berbicara lebih lanjut tentang topik utama, izinkan gue membahas sedikit tentang ke-sok-tahuan gue.

Product Market Fit™

Sebenernya gue udah muak mendengar kata ini.

Biasanya kata tersebut keluar dari orang-orang yang terobsesi membuat perusahaan rintisan, membaca buku Lean Startup & Zero to One, lalu mengikuti seminar-seminar dan kompetisi terkait membuat produk digital.

Silahkan bisa ganti kata 'orang-orang' diatas menjadi 'teman gue'.

Gue bukan pemilik perusahaan rintisan, dan bukan orang bisnis. Namun sebagai seseorang yang juga ikut andil didalam nya, berikut beberapa pendapat gue tentang Product Market Fit.

Anggap lo memproduksi kopi dengan nama Unibucks, tidak ada yang spesial dari kopi lo kecuali ada logo kuda terbang bertanduk disetiap cangkir kopi lo dan interior tempat lo yang faultable 500pxable.

Yang jual kopi bukan cuma lo, misal dari 100 brand yang jualan kopi juga, mengapa orang-orang harus membeli dari brand lo?

  • Mahal
  • Mendukung Go Green
  • Ada logo kuda terbang bertanduk

3 poin diatas bisa jadi representasi dari pasar yang lo target: Mahasiswa/i UPH, pekerja korporat scbd, masyarakat pengguna sedotan besi & tumbler, serta orang-orang yang peduli dengan logo kuda terbang bertanduk.

Itu untuk produk yang sudah ada, pertanyaannya, bagaimana untuk yang ternyata belum ada?

Yang sederhananya, target pasar nya belum diketahui keberadaannya.

...meskipun asumsi kita selalu bilang pasti ada pasarnya.

Yang berarti, kita sendiri yang membuat pasar tersebut.

Pasar adalah tentang pertemuan penawaran dan permintaan, yang sayangnya, pemilihan selalu tentang waktu dan kondisi yang tepat.

Seperti, kita makan ketika sudah lapar (waktu) dan kondisi nya sudah yoi untuk makan (jam makan siang, duit ada, kagak mager), benar?

Ketika membuat penawaran, apakah waktunya sudah pas?

Ketika ada permintaan, apakah kondisi nya sudah tercukupi?

Gue sengaja membahas ini—yang diluar dari topik utama—karena ini terkait dengan subjudul yang gue pilih.

Karena banyak teman gue yang mengira kalau PMF === MVP, yang padahal PMF itu tentang a good product in a good market.

Yang sedangkan kita bahkan belum tau apakah market tersebut good or bad or even nothing.

Lalu dilanjutkan dengan membuat MVP, sebuah sebutan untuk menggambarkan produk minimum yang layak

Yang dengan harapan, produk tersebut, memenuhi keinginan pasar secara minimal.

Namun ada yang menarik disini.

Sebenarnya yang di butuhkan oleh perusahaan rintisan bukanlah produk minimum yang layak, melainkan perusahaan minimum yang layak.

Lalu, apakah perusahaan rintisan bisa membuat perusahaan minimum yang layak yang singkatnya menggunakan pekerja seminimum mungkin?

Inilah salah satu alasan mengapa gue menulis tulisan ini.

Namun sekali lagi, sebelum melanjutkan ke topik utama, mari kita bahas kata lain yang gue udah muak juga dengarnya.

Growth

Gue setuju dengan essai Startup = Growth nya orang YCombinator, yang garis besarnya adalah perusahaan startup™ dirancang untuk bertumbuh dengan cepat.

Bahkan sangat cepat.

Amazon hanya butuh waktu 2 tahun untuk perusahaan tersebut dapat diperjual-belikan kepemilikannya oleh publik.

Growth ini dapat beragam bentuknya.

Bisa dalam bentuk sebuah kondisi dimana pengguna nya semakin banyak, pemasukan & pengeluaran semakin besar, atau baru saja mendapatkan suntikan dana dari penanam modal.

Dan banyak yang menggambarkan bahwa berkembang berarti waktunya melebarkan sayap, mempekerjakan lebih banyak orang, agar bisa membuat sayap menjadi lebih lebar lagi dengan bergerak lebih cepat lagi.

Yang padahal, kita sudah mengetahui lelucon klasik yang berbunyi "You can't produce a baby in one month by getting nine women pregnant" yang dikatakan oleh orang random bernama Warren Buffett.

Yang bila mengutip seutuhnya, kutipan lengkapnya adalah No matter how great the talent or efforts, some things just take time dilanjutan dengan kutipan di paragraf sebelumnya.

Mari kita cherry pick, dan ambil kutipan yang "You can't produce..." nya saja.

Ini tidak kontekstual, tapi sebuah fakta.

Beberapa orang percaya jika mempekerjakan lebih banyak tukang bangunan, dapat membuat proses pembuatan bangunan menjadi lebih cepat.

Namun ada beberapa yang percaya bahwa kuncinya bukanlah di jumlah pekerja bangunannya, melainkan di efektivitas dalam proses pengerjaannya.

10 orang tentu saja dapat mengaduk semen dengan cepat, namun bukankah akan lebih efektif ketika pengadukannya dilakukan oleh mesin molen?

Oke oke, mungkin sudah terlihat sedikit arah pembahasan utama gue ya.

Gue bukan mau mendiskreditkan untuk hire more or something, tapi sebenarnya lebih ke ingin berbagi tentang membuat sesuatu yang efektif namun juga efisien yang dalam konteks ini berarti perusahaan rintisan.

...yang ironis nya ditulis oleh seseorang yang bahkan tidak pernah membuat perusahaan rintisan satupun.

Berbicara tentang produktivitas

Sekarang, mari kita mulai masuk topik utama.

Anggap kita sedang membuat produk yang sudah setengah jadi dan dikembangkan oleh 5 pengembang utama yang sudah familiar dari ujung-ke-ujung tingkah laku produk tersebut, berikut dengan nilai bisnisnya juga.

Produk tersebut selesai selama 15 bulan, oleh 5 pengembang dengan total komponen berjumlah 75.

Yang bila menggunakan pengetahuan kalkulus gue yang mendapatkan nilai T, perhitungan kasarnya bila proses pengembangan produk digambarkan seperti menyusun lego, 5 pengembang tersebut dapat membuat 5 komponen dalam 1 bulan, benar?

Anggap kita ingin memangkas waktunya menjadi 6 bulan. Dengan kapasitas 5 pengembang, kasarnya, 5 pengembang tersebut harus dapat membuat 13 komponen dalam 1 bulan, yang setiap pengembang memiliki beban untuk membuat 2.6 komponen setiap bulannya.

Yang tentu saja terlihat berat.

Agar tidak terlihat berat, kita tambah pengembang menjadi 13.

Dengan total 13 pengembang, kasarnya 1 bulan dapat membuat 13 komponen dengan beban setiap orang bertanggung jawab terhadap 1 komponen setiap bulannya.

Sekarang sudah tidak terlihat terlalu berat, subsistem apa yang menghabiskan waktu 168 jam (8 jam*21 hari kerja) dalam pengerjaannya bila tidak terpotong oleh meeting?

Mungkin pertimbangan tersebut yang menjadi keputusan untuk mempekerjakan lebih banyak.

Pertanyaannya, apakah kondisi diatas relevan dengan kutipan orang random bernama Warren Buffett yang sudah di cherry pick tersebut?

Apakah proses kelahiran sama dengan proses pengembangan produk?

Atau, bagaimana bila apakah proses kelahiran sama dengan proses perilisan produk?

Jika menjawab pertanyaan pertama, tentu tidak. Kecuali yang kedua, kemungkinan besar sama.

Lalu, bila kita mencintai yang lain setuju dengan jawaban akan pertanyaan kedua, mengapa kita memilih mempekerjakan lebih banyak?

Jawabannya adalah efektivitas, benar?

Namun ingatkah anda dengan perumpamaan si mesin molen sebelumnya?

On rockstar-only club

Ada beberapa organisasi yang hanya mempekerjakan senior-level dan bahkan rela membajak seseorang sekalipun dia seorang "brilliant jerk".

Jawabannya beragam, namun pastinya memiliki satu kesamaan: Memiliki ekspektasi yang tinggi.

Lo bikin produk baru, pasti lo membutuhkan orang yang sudah berpengalaman di bidang tersebut. Gak mungkin kan Unibucks kita mempekerjakan orang yang bahkan belum pernah bikin kopi sama sekali?

Terlebih kita sedang berkembang-kembangnya, tidak ada waktu untuk melatih karyawan agar sesuai dengan skala organisasi kita saat ini.

Dengan modal dana lebih dari cukup, kita ingin mempekerjakan orang-orang yang sudah berpengalaman lama dengan janji kompensasi yang lebih tinggi dan mungkin skop pekerjaan yang lebih menantang.

Sekilas terlihat efektif, beban pekerjaan 2.5 tersebut mungkin terasa 1.25 bagi yang sudah berpengalaman lama pada bidang tersebut.

Namun sayangnya, proses rekruitmen pekerja bukanlah hal yang mudah, apalagi membuat pekerja tersebut tetap berada di organisasi kita sehingga apa yang kita investasikan kepada orang tersebut tidak hanya menguntungkan sebelah pihak.

Apakah sudah mendapatkan poin dari bagian ini?

Mungkin bila yang sudah familiar dengan sebutan "brilliant jerk" akan mengerti, yang singkatnya (tentang poin ini), mempekerjakan "hanya senior" di organisasi kita bukanlah sesuatu yang sangat efektif.

Lalu adakah yang benar-benar efektif?

Mendefinisikan efektivitas

Sebelum menyelam lebih dalam tentang efektivitas, kita harus bisa mendefinisikan makna efektif itu sendiri khususnya terhadap organisasi kita.

Mari kita ambil contoh umum untuk organisasi di divisi engineering untuk perusahaan informasi teknologi.

Efektivitas singkatnya adalah suatu keberhasilan yang didapat oleh siapapun itu dengan cara tertentu yang sesuai dengan tujuan yang ingin dicapai.

Sebagai contoh, bila hanya mempekerjakan senior dalam organisasi dapat mencapai proses rilis produk menjadi lebih cepat dan stabil, mungkin cara tersebut efektif untuk organisasimu.

Berbicara secara umum, kira-kira apa saja yang biasanya ingin dicapai dalam membuat & mengembangkan sebuah produk khususnya produk berbentuk perangkat lunak?

  • Kualitas kode (internal)
  • Kemudahan dalam memelihara program
  • Kehandalan program
  • Keamanan program
  • Kestabilan program

Agar lebih mudah memahaminya (dan tidak bermaksud untuk mendiskreditkan senior engineers™), apakah senior engineers dapat mencapai poin-poin diatas?

Singkatnya, tentu saja.

Mereka sudah terbiasa dengan 5 poin diatas.

Lalu apakah untuk yang non-senior (kebawah) tidak dapat mencapai poin-poin diatas?

Tentu dapat.

Sekarang, mari kita masuk ke topik inti!

Introducing: The molen machine

Maish ingat kan tentang mesin molen yang pernah kita singgung di atas?

Mari kita lihat apakah si mesin ini dapat membantu pekerjaan kita agar menjadi lebih efektif dalam mencapai:

  • Kualitas kode (internal)
  • Kemudahan dalam memelihara program
  • Kehandalan program
  • Keamanan program
  • Kestabilan program

Kita coba bahas satu-satu.

Kualitas kode.

Kualitas kode biasanya mengarah ke kode yang mudah dibaca & dipahami. Tentu kira lebih mudah membaca dan memahami if (userLevel < USER_LEVEL.ADMIN) daripada if (userLevel < 2).

Dan tentu kita lebih mudah memahami fetchUserData daripada fetchUser.

Dan ya, membuat komentar pun sangat membantu dalam proses memahami kode.

Namun kualitas kode bukan hanya tentang penamaan, melainkan juga tentang bagaimana format penulisan dan berbagai aturan dalam menulis kode.

Format penulisan misal seperti harus menambahkan whitespace di sebelum dan setelah kata kunci tidak (e.g: if, while, for, dkk), harus menggunakan curly braces untuk setiap statement, dll.

Aturan dalam menulis kode misal seperti harus menggunakan Error ketika membuat Promise, tidak boleh membuat variable yang tidak digunakan, harus menggunakan isNaN untuk mengecek NaN, dll.

Nah hal-hal terkait diatas bisa dibantu dengan tools, misal untuk bahasa pemrograman JavaScript ada Prettier; ESLint, atau StandardJS.

Kemudahan dalam memelihara program.

Ini pastinya bergantung juga dengan Kualitas kode.

Kode yang mudah dipelihara menurut gue adalah kode yang memiliki dokumentasi yang terstruktur dan jelas serta terlacak rapih dengan menggunakan kontrol versi.

Dokumentasi ini bisa menggunakan beragam cara, tapi gue benci dengan yang auto-generated namun tidak jelas yang hanya mengandalkan parameter (dan tipe datanya) serta nilai keluaran (dan tipe datanya).

It's okay pakai JSDoc, Swagger, Sphinx, Docsify atau bahkan wiki biasa untuk mendokumentasikan kode, asalkan jelas dan ter-struktur.

Dan It's okay untuk mengguakan copy of copy.tgz (1) git, mercurial, subversion, dsb untuk melakukan kontrol versi, selagi memiliki "pesan perubahan" yang jelas dan proses rilis yang rapih (termasuk membuat tag, changelog, dll).

Kehandalan program

Program dapat di katakan handal ketika... Handal?

Oke, ketika dapat diandalkan.

Yang singkatnya berarti memiliki tidak ada sedikit bug, sedikit galat fatal yang menyebabkan crash; hang, kernel panic? dsb, dan yang di luar lingkungan pengembang adalah dapat beroperasi dengan baik di level infrastruktur.

Bagaimana cara mencapainya?

Membuat tests.

Pada dasarnya semua poin tersebut jawabannya adalah dengan membuat tests, tapi sengaja gue ribetin biar tulisan ini terlihat panjang.

Dengan membuat test, kualitas kode menjadi lebih jelas (angka code coverage), pemeliharaan kode menjadi lebih mudah (snapshot test, BDD), dan kehandalan program menjadi lebih terjamin juga (smoke test, ehm monkey test, dll).

Keamanan program.

Ini paling esensial, karena dapat menyebabkan kerugian baik di sisi bisnis maupun pengguna.

Selain menulis tests, jawaban terhadap poin-poin diatas tersebut adalah dengan melakukan pemantauan.

Memantau perubahan angka code coverage, hasil automated test, perkembangan terkait perubahan kode & perilisan program, serta operasional akan program itu sendiri.

Sama seperti mengembangkan program, keamanan adalah tentang pola juga.

Jika mengembangkan program adalah tentang membuat pintu, keamanan program adalah tentang mencari celah untuk membobol pintu tersebut.

Celahnya pun memiliki pola, jika menggunakan basis data SQL berarti ada kemungkinan untuk SQLi; Jika menggunakan JavaScript di XSS, jika berinteraksi dengan file system di LFI/RFI, dsb.

Prinsip dari proses automasi adalah apa yang bisa dilakukan secara manual, berarti bisa dilakukan juga secara otomatis.

Dan kabar baiknya, untuk melakukan hal-hal diatas, bisa menggunakan tools seperti Havij, accunetix, metaspolit, dsb.

Dan juga karena dapat diautomasi tersebut, kita bisa melakukan pemantauan/monitoring, sehingga kita dapat tertidur nyenyak sambil menemukan bug CSRF yang dapat melakukan reset password tanpa harus melakukan proses verifikasi.

Kestabilan program.

Dan ini yang terakhir.

Beda dengan kehandalan program, kestabilan program berarti program tersebut dapat berjalan secara... stabil?

Oke oke, misal program tersebut dapat berjalan di berbagai peramban; Di berbagai sistem operasi, dan di berbagai perangkat termasuk di tamagoci jam tangan tanpa ada kendala.

Gue paling males menemukan program yang hanya berjalan di peramban keluarga Chromium, atau hanya berjalan di Mac OS dan Windows, atau cuma ada di Android.

Dan juga gue paling males menemukan program yang ketika ada perubahan major, maka tidak bisa di downgrade setelah di upgrade. Atau program yang hanya berjalan di RAM sebesar ~2GB, di perangkat yang non-jailbreak/non-root, dsb.

Jika kehandalan adalah tentang di lingkungan yang sedang berjalan, kestabilan adalah tentang di linkungan yang akan berjalan.

Ya, stabilitas sekilas serupa dengan kompatibilitas, namun menurut gue lebih luas dari itu.

Seperti, mungkin program A dapat dijalankan di berbagai peramban, namun bila menggunakan perangkat X, maka ada beberapa fitur yang tidak dapat digunakan.

Oke, jadi bagaimana untuk menjawab poin ini?

Dengan melakukan test dan pemantauan!

Yang biasanya menggunakan server CI untuk dapat melakukan test di berbagai sistem operasi, peramban, perangkat, dan bahkan berbagai lokasi geografis serta kondisi jaringan internet.

Korelasi

Faktor apa yang menyebabkan produktivitas menurun?

Tentunya beragam, namun 5 poin diatas juga ikut berperan.

Kualitas kode yang kurang bagus dan sulitnya memelihara program tersebut membuat proses pengembangan menjadi lebih lambat, program yang tidak handal menghambat pengembangan fitur, program yang kurang aman membuat terlalu banyak di fixing bug, dan program yang tidak stabil menghambat proses peningkatan terhadap yang sudah ada (fitur, housekeeping, dsb).

Segala sesuatu pasti ada biayanya, dan berdasarkan kondisi yang dimiliki saat ini, silahkan tentukan sendiri biaya mana yang membuat proses tersebut menjadi lebih efektif tanpa menghiraukan faktor efisiensi.

Mengapa menulis ini?

Menurut gue, kebanyakan dari kita terlalu sibuk terhadap apa yang sudah ada dan lebih memilih jalur aman daripada mencoba untuk membuat peningkatan.

Pernah melihat gambar tentang "Are you too busy to improve?" yang jika belum berikut gambarnya:

Sumber terlampir di gambar

Tapi itu menurut gue, dan semoga tidak benar.

Jika terus-terusan mengambil langkah hire more atau hire senior-only daripada investasi di tools untuk meningkatkan produktivitas (yang efektif) yaa mau sampai kapan?

Sepengetahuan gue, udah ada beberapa perusahaan yang memberikan posisi khusus untuk memelihara "internal tooling" mereka, posisi tersebut ada Product Infrastructure, Software Engineer (Internal tooling), Software Engineer (Productivity), Software Engineer (Infrastructure) dan berbagai macam judul lain yang too good to be true.

Hal yang lumayan familiar di dunia startup adalah Buy vs Build, yang kabar baiknya kamu tidak perlu membuat solusi "in-house" kamu sendiri bagi yang memiliki sindrom NIH, melainkan dapat membeli/menyewa yang sudah ada.

Tentu kamu yang menentukan apakah menyewa layanan 20jt IDR per-tahun lebih efektif dan efisien dari mempekerjakan 3 pengembang dengan total 108jt per-tahun untuk membuat internal tool kamu sendiri berikut dengan biaya pemeliharaan & operasionalnya.

Sekilas mempekerjakan pengembang 4jt/bulan dengan total 3 pengembang untuk membuat e-commerce lebih murah daripada menyewa program yang sudah ada sebesar 1,2jt yang sudah memiliki hampir semua fitur untuk membuat sebuah situs e-commerce.

Yang padahal sudah termasuk biaya pemeliharan dan operasional juga.

Tapi tentu saja tidak terlihat seksi, kan lucu klo ngisi talk How we handle 100k/hour traffic with... Shopify like what the fuck

Kan kalau judulnya How we handle 100k/hour traffic with Envoy and Kubernetes akan terlihat sangar, paling komentar gue dipojokan konferensi cuma siap bang jaeger.

Kesimpulan

Oke bos, kita sudahi ngalor-ngidul ini.

Sebagai kesimpulan, di untuk level perusahaan yang baru/masih mencari jati diri, menurut gue tidak perlu ngelakuin hal aneh-aneh dulu lah yang tidak sesuai dengan apa yang sedang dibangun dan ingin dicapai.

Seperti bikin-bikin CRUD boring yang sebenernya tinggal rails g scaffold, pake hexagonal architecture segala yang padahal mvc juga cukup, pake basis data mongodb karena webscale dan relational sucks fuck sql, dsb.

Dan untuk yang sedang tumbuh dan berkembang, gue rasa mending fokus ke hal-hal yang membuat produktif dengan biaya yang efisien.

Jika engineer lo terlalu sibuk ngurusin peningkatan performa dan mencari bug, coba pertimbangkan menggunakan layanan seperti new relic dan sentry, mengingat sebelum melakukan optimasi itu harusnya melakukan profiling dulu.

Dan jika maksud dari Invest (more) in tools ini kurang jelas, coba perhatikan apa yang dilakukan secara manual dan bisa diperbaiki dengan ter-otomasi melalui tools untuk membuat sesuatu tersebut menjadi lebih efektif dan efisien.

Tidak perlu yang waw dan kompleks terlebih dahulu, sesederhana otomatis formatting ketika git commit dengan pretty-quick daripada harus manual atau lupa ke format pas bikin PR, memberikan pemberitahuan untuk npm/yarn install ketika ada perubahan di lock file via dangerjs daripada "debugging" lama-lama yang ternyata masalahnya ada di private module yang belum di upgrade, konfigurasi CI untuk melakukan e2e testing dan yang menghasilkan rekaman video daripada harus melakukannya manual, dsb.

Hal-hal tersebut sekilas sederhana, dan terlihat hanya menghemat beberapa menit saja. Jika melakukan hal diatas dapat menghemat waktu kita 1 menit per-hari saja, dalam satu tahun sekitar 24 menit kalau perhitungan gue kagak salah.

Silahkan kalikan dengan total pengembang lain yang merasa terhematkan waktunya juga.

Jadi, untuk teman-teman—khususnya teman kampusku—yang sedang terobsesi untuk membuat perusahaan rintisan, silahkan pertimbangkan untuk investasi terhadap tools terlebih dahulu, baru ke manusia.

Kerena bagaimanapun proses pengembangan adalah sebuah proses yang berulang-ulang, No matter how great the talent or efforts, some things just take time.

Dan minta maaf sebelumnya bila menyinggung ke bagian senior developer, gue cuma kesel aja sih sama organisasi yang cuma hire senior, berasa yang non-senior menjadi terpinggirkan.

Terakhir, sebagai penutup, jangan pernah percaya dengan apa yang dikatakan oleh orang random yang ada di internet, termasuk si faultable.

Terima kasih!