20 poin oleh GN⁺ 2025-10-02 | 3 komentar | Bagikan ke WhatsApp
  • Dalam lingkungan bisnis tahap awal yang sering berubah, bijak untuk menyelesaikan masalah dengan solusi paling mudah secepat mungkin, lalu mengevaluasi ulang kebutuhan dan mengganti atau melengkapinya saat batasannya mulai terlihat
  • Google Sheets adalah sarana pemecahan masalah yang efektif di lingkungan yang berubah cepat; dibanding membangun alat yang kompleks, ini lebih menguntungkan dari sisi kegunaan nyata dan pengurangan pemborosan
  • Penulis merefleksikan bahwa dalam praktik kerja, ia terburu-buru membuat sistem khusus alih-alih memakai alat serbaguna, sehingga mengabaikan ketidakpastian cakupan dan membuang waktu
  • Metode intinya adalah strategi mulai dari kecil dan berulang: mulai dengan solusi paling kecil dan paling mudah → pahami cakupan lewat pekerjaan nyata → tingkatkan secara bertahap bila perlu
  • Namun, tidak semua masalah bisa diselesaikan dengan spreadsheet; lebih tepat digunakan sementara sampai cakupannya terlihat, dan pemilihan yang bijak sesuai konteks organisasi itu penting

Pilihan termudah untuk memecahkan masalah

  • Untuk masalah apa pun, penting untuk terlebih dahulu memilih solusi yang paling mudah diterapkan
  • Ketika cara tersebut sudah tidak lagi sesuai dengan kebutuhan bisnis, perlu memperbaiki solusi yang ada atau mencari alternatif sesuai kebutuhan baru
  • Dalam lingkungan yang dialami penulis, dalam banyak kasus membuat Google Sheet baru adalah cara yang paling optimal

Lingkungan startup yang berubah cepat dan kegunaan alat

  • Sekitar 9 bulan lalu, penulis bergabung dengan tempat kerja barunya, dan ekspektasi untuk membuat alat dan layanan baru bagi perusahaan kecil yang masih tahap awal pun memudar
  • Di lingkungan tempat arah bisnis berubah setiap 2 bulan, banyak proyek dimulai lalu dihentikan
  • Dalam banyak kasus, meski sebenarnya bisa diselesaikan dengan mudah memakai Google Sheet, waktu dan tenaga justru dihabiskan untuk proyek yang tidak perlu rumit

Contoh pemborosan waktu

  • Panel admin manajemen kargo

    • Menghabiskan 2 bulan untuk merancang dan membuat panel admin guna mengelola serta melacak kargo masuk untuk bisnis
    • Tujuannya untuk membantu mengelompokkan paket dan data pelanggan serta mengelolanya dengan lebih baik
    • Panel admin ini dipakai dua kali lalu tidak pernah digunakan lagi
    • Ini sebenarnya bisa dengan mudah digantikan oleh Google Sheet, dan saat ini memang digunakan untuk pekerjaan tersebut
  • MVP perhitungan bea masuk otomatis

    • Menghabiskan 3 minggu untuk membuat MVP sistem estimasi yang otomatis menghitung bea masuk dan pajak saat produk tertentu dipesan
    • Pajak dan bea masuk di Zimbabwe sangat kompleks, sehingga jika pelanggan mengetahui jumlah pembayaran yang akurat, pengalaman pelanggan bisa menjadi lebih baik dan proses dapat dipercepat tanpa harus menunggu semua balasan pertanyaan pelanggan dari perusahaan pengurusan bea pihak ketiga
    • Pada akhirnya, penulis melihat tabel klasifikasi pajak dan bea masuk milik pesaing lalu menyalinnya ke Google Sheet untuk digunakan
  • Proses memilih CRM

    • Menghabiskan 2 bulan untuk riset, rapat (lebih dari 1 jam), dan pencarian demi menemukan CRM yang baik untuk bisnis
    • Duduk membandingkan dan menganalisis fitur serta harga dari berbagai CRM
    • Pada akhirnya diputuskan menggunakan versi gratis Oddo, tetapi tidak banyak dimanfaatkan di dalam bisnis
    • Yang mengejutkan, beberapa minggu lalu penulis menemukan bahwa template CRM sudah tertanam di Google Sheets

Prinsip pendekatan Google Sheets

  • Membuat Google Sheet bukanlah solusi terbaik untuk semua masalah, tetapi dalam situasi penulis hal ini sering kali demikian
  • Ia sering berada dalam situasi di mana cakupan penuh masalah tidak pernah bisa diketahui sampai pekerjaan nyata dimulai
  • Ini bukan berarti proyek tidak perlu direncanakan
  • Tim tetap harus mendiskusikan alur kerja dan informasi yang dibutuhkan, tetapi cakupan penuh masalah tidak bisa diketahui sampai pekerjaan nyata dimulai
  • Setelah cakupan penuh masalah dipahami, barulah dimungkinkan untuk mulai membangun atau memperbaiki solusi yang dimiliki
  • Dalam skenario terbaik, pendekatan ini membantu menghindari beban kerja tambahan akibat menambahkan semua fitur yang sebenarnya tidak dibutuhkan, dan dalam skenario terburuk mencegah waktu terbuang pada proyek yang akan gagal
  • Sebagai cara untuk memahami cakupan penuh masalah, sejauh ini yang paling baik adalah menjalankan solusi dasar yang paling kecil dan paling mudah, lalu mengulanginya bila diperlukan

Keterbatasan dan hal yang perlu diwaspadai

  • Pendekatan ini juga punya kekurangan; misalnya, di beberapa organisasi semua transaksi dan informasi dicatat dalam spreadsheet dengan ribuan baris
  • Google Sheets hanya berguna sebelum cakupan penuh masalah dipahami
  • Diperlukan pengalaman dan penilaian untuk menentukan masalah seperti apa yang bisa diselesaikan dengan Google Sheet
  • Yang penting adalah memprioritaskan pengembangan alat yang benar-benar bisa dipakai tanpa membuang waktu
  • Namun, karena ini bukan nasihat yang berlaku untuk semua orang, masing-masing perlu menilai dengan hati-hati sesuai situasinya

Kesimpulan

  • Memulai dari usaha paling kecil dan solusi paling sederhana, lalu memperluas atau meningkatkan hanya saat diperlukan, adalah strategi yang sangat cocok untuk startup atau lingkungan yang banyak berubah
  • Eksperimen pengembangan pribadi boleh dilakukan dengan bebas, tetapi dalam bisnis yang penting adalah hanya membuat hal yang benar-benar diperlukan dan tidak menghabiskan waktu serta energi pada pekerjaan yang tidak perlu

3 komentar

 
shalome7 2025-10-03

Saya pada dasarnya juga setuju, tetapi saat ini saya lebih memilih menggunakan Notion Database daripada Google Sheets sebagai baseline awal. Keduanya memang mirip, tetapi pada akhirnya yang menyiapkan template hanya 1 orang. Jika orang lain mengelola data di atas fondasi itu, situasi yang berantakan bisa dicegah. Kemampuan otomatisasinya memang tidak sebagus Apps Script, tetapi implementasinya lebih mudah. Tingkat kesulitan setup awal mungkin sedikit lebih tinggi, tetapi tidak terlalu besar, dan dari sisi fleksibilitas rasanya mirip. Ditambah lagi, belakangan ini sudah ada pengelolaan izin per baris, jadi bagus.

 
shakespeares 2025-10-07

Menurut saya Notion bagus karena kurva belajarnya rendah.

 
GN⁺ 2025-10-02
Komentar Hacker News
  • Ini selalu menjadi hal yang terlewat. Spreadsheet menyatukan database, UI yang cepat dan mudah dikustomisasi, serta lingkungan pemrosesan data yang iteratif dan mudah di-debug dalam satu tempat. Ini adalah alat yang sudah dipahami dan digunakan oleh para pekerja kantoran di seluruh dunia, dan juga memberi kebebasan bagi pembuatnya untuk mengimplementasikan apa pun yang mereka inginkan. Portabilitasnya juga sangat baik. Saya yakin ini adalah alat yang sangat kreatif dan kuat, terutama bagi orang-orang yang tidak bisa coding. Tentu kebebasan seperti ini juga punya kekurangan, tetapi terlepas dari perdebatan soal online atau tidak, atau vendor mana yang lebih baik, kecintaan saya yang mendalam pada spreadsheet tidak berkurang sedikit pun. Menurut saya ini adalah salah satu alat authoring terbaik yang pernah kita buat. Model yang mirip dengan spreadsheet adalah HyperCard. Itu adalah meja kerja yang fleksibel yang bisa merangkai berbagai aplikasi, data, UX, dan lain-lain. Saya berharap HyperCard akan terus dikenang selamanya

    • Betul, hambatan masuk spreadsheet memang sangat rendah. Saya bahkan memasukkan catatan pertumbuhan tanaman ke Google Sheets dari ponsel saat berada di tengah ladang. Meski sinyal lemah, saya tetap mencatatnya dalam mode offline lalu menyinkronkannya ketika pulang ke rumah. Walaupun catatannya berantakan, itu jauh lebih baik daripada tidak ada sama sekali. Pertanian membutuhkan banyak data, tetapi justru sering berada di lingkungan yang kekurangan data. Siklus belajarnya panjang, hitungannya per tahun, dan setiap tahun selalu berbeda

    • Bagi orang yang bisa coding, Appscript membuat spreadsheet nyaris seperti punya kekuatan super. Untuk yang belum tahu, di web IDE bawaan Google Sheets Anda tidak harus hanya menulis JS saja (meskipun itu sendiri cukup berguna). Dengan clasp, Anda bisa mengembangkan dalam Typescript di IDE lokal, lalu mengompilasinya menjadi JS dalam proses build dan langsung mendeploy-nya ke spreadsheet. Jika toolchain-nya sudah disiapkan, pengalaman pengembangnya (DX) juga cukup bagus

    • Sangat setuju. Nilai dari meja kerja terpadu yang menggabungkan database + UX + logika adalah inti dari aplikasi yang terus-menerus kita buat ulang. Itu juga sebabnya Visual Basic masih dipakai. Tentu ini bukan cara terbaik setelah arah sudah benar-benar pasti, tetapi untuk beriterasi cepat sambil memahami kebutuhan yang sebenarnya, ini nyaris tak tertandingi

    • Saya rasa akan bagus kalau ada cara yang lebih baik untuk memakai spreadsheet sebagai backend database. Sebagian besar hal yang dilakukan orang di spreadsheet sebenarnya akan lebih baik ditangani oleh database. Namun database membutuhkan lebih banyak edukasi, dan bila edukasinya kurang, hasilnya justru bisa lebih buruk daripada spreadsheet

    • Saya selalu bertanya-tanya kenapa tidak ada jalur transisi yang realistis untuk berpindah secara bertahap dari spreadsheet ke database penuh dengan UI kustom. Spreadsheet sudah berada tepat satu langkah sebelum peran itu, dan rasanya hanya butuh beberapa fitur penting saja (data terstruktur, SQL native, elemen UI kustom, integrasi IDE, dan sebagainya)

  • Ini mengingatkan saya pada tulisan "Ask HN: Is the world run by badly updated Excel sheets?". Untuk benar-benar mengalami batasan spreadsheet, Anda perlu pengalaman langsung. Tidak ada version control, tidak ada testing. Ini bagus untuk pekerjaan yang tidak berubah dan berumur pendek, tetapi jadi masalah jika harus terus berkembang. Lihat https://news.ycombinator.com/item?id=33611431. Ada komentar seperti ini di thread tersebut: pada akhirnya, di dalam perusahaan semua orang menyesuaikan diri dengan cara kerja pemilik Excel. Kalau tidak suka, orang tinggal membuat Excel baru sendiri lalu copy-paste, jadi semua orang mengelolanya sendiri. Seorang manajer proyek yang saya kenal sehari-harinya harus terus menyelaraskan versi spreadsheet dari banyak penulis

    • Saat saya mulai sebagai coder di AS pada era 2000-an, saya mengira pekerjaan saya adalah mengubah spreadsheet di network drive Windows yang selalu butuh seseorang untuk merawatnya menjadi webapp. Meski begitu, banyak perusahaan masih berjalan cukup baik dengan basis spreadsheet. Pada akhirnya masalah skalabilitas memang akan datang, dan saat itu harus dipindahkan ke aplikasi, tetapi lebih penting untuk benar-benar menyelesaikan sesuatu daripada terlalu mengejar kesempurnaan sampai tidak jadi apa-apa

    • Anda bilang "tidak ada version control", padahal sebenarnya Excel memang punya fitur version control. Jika memakai 'Track Changes', Anda bisa menyetujui atau menolak perubahan dari orang lain. Hanya saja, orang yang bekerja dengan otomatisasi spreadsheet ala Rube Goldberg hampir tidak pernah memakai fitur ini. Tapi kalau perlu, fitur itu ada

    • Saya sering melihat masalah muncul ketika informasi tersebar di banyak spreadsheet. Para peserta sering tidak tahu spreadsheet mana yang berisi informasi tertentu, atau mana yang menjadi sumber kebenaran. Akibatnya sering terjadi bentrok: seseorang hanya memperbarui file A tanpa diketahui, sementara orang lain hanya menyentuh B. Masalahnya lebih pada cara file dikelola dalam proyek daripada masalah program atau datanya sendiri. Ini menjadi labirin pengelolaan: shared folder yang rumit, file yang ditelantarkan di suatu tempat di jaringan, dan semacamnya

  • Saya setuju dengan saran "selalu gunakan cara termudah untuk menyelesaikan masalah, lalu ketika cara itu tidak lagi cocok untuk bisnis, tingkatkan atau cari solusi alternatif sesuai kebutuhan baru". Fokuslah pada penyelesaian masalah yang ada saat ini; sulit menebak masalah masa depan atau masalah yang hanya kita bayangkan akan datang. Solusi saat ini mungkin nanti jadi tidak cocok, tetapi sulit memprediksi dalam bentuk apa ketidakcocokan itu akan muncul

    • Sulit memprediksi bagaimana solusi akan menjadi tidak cocok di masa depan, tetapi kita tetap bisa memilih solusi saat ini dengan cara yang tidak memblokir atau menghambat solusi di masa depan. Ada baiknya menjaga opsi tetap terbuka dan menghindari situasi terkunci pada vendor sehingga tidak bisa keluar

    • Contoh ketidakcocokan yang cukup bisa diprediksi adalah ketika Anda sepenuhnya bergantung pada vendor tertentu lalu dipaksa keluar dari layanannya atau harus menerima biaya yang makin mahal. Ini masalah yang cukup dapat diperkirakan

    • Jika Anda menyelesaikan masalah dengan cara yang mencakup keseluruhan domain masalah tanpa harus melakukan jauh lebih banyak pekerjaan, solusi itu akan lebih tangguh karena dapat menyerap perubahan kebutuhan hanya dengan sedikit penyesuaian. Dengan begitu, secara alami ia juga mencakup masalah masa depan

  • Saya bekerja di perusahaan besar ternama di AS. Departemen kami sangat bergantung pada dua spreadsheet. Keduanya bertahan melewati tiga kali merger dan akuisisi yang melibatkan pabrik saya. Saat saya masuk 7 tahun lalu, format itu sudah tua. Dua tahun lalu manajer baru mencoba memindahkannya ke sistem perusahaan, tetapi gagal, dan sebentar lagi sistem itu sendiri juga akan digantikan oleh sistem baru. Namun saya rasa pada 2027 kami masih akan tetap memakai spreadsheet

  • Saya mantan karyawan Google. Selama 5 tahun saya menangani semua pekerjaan hanya dengan Sheets (secara internal disebut Trix): manajemen proyek, CRM, perencanaan kuartalan, pelaporan, wawancara, keuangan, semuanya. Bukan sekadar karena itu produk Google (produk pesaing juga kami pakai dengan cukup bebas). Kenyamanan terbesarnya adalah spreadsheet bisa dibuat cukup cepat untuk mencapai tujuan, sehingga kami bisa fokus pada inti pekerjaannya

    • Saya dengar kolaborasi di Google terutama dilakukan lewat lists (membuat google groups), gsheets, dan chat sederhana yang otomatis terhapus secara real-time. Saya penasaran apakah mereka benar-benar tidak memakai alat yang katanya keren seperti Slack atau Teams. Menarik
  • Menanggapi pendapat seseorang yang berkata "baru 9 bulan bekerja", saya merasa, benar atau salah, perlu nyali cukup besar untuk membuat penilaian setegas itu dengan pengalaman belum sampai setahun. Hal yang dilewatkan OP adalah kebenaran bahwa "tidak ada yang lebih permanen daripada solusi sementara". Memilih solusi yang cepat dan improvisasi untuk saat ini hanya bisa diterima jika Anda sepenuhnya mengendalikan siklus hidup solusi itu. Jika seseorang meminta Anda membuat sesuatu dengan cepat lalu menyerahkannya, dan setelah itu mereka terus menambahkan penggunaan baru di atasnya… saya akan sangat mendorong penggunaan alat yang biaya awalnya sedikit lebih tinggi

    • Saya hampir tertawa saat membaca bagian "sekali tiap beberapa bulan..." dari masalah itu. Penulis memang tepat bahwa prinsip utamanya adalah menyelesaikan pekerjaan dengan alat yang sederhana. Kalau bisa memakai alat yang sudah ada dan kebutuhan terpenuhi dengan baik, itu yang terbaik. Di lapangan nyata, tuntutan bisnis memang bisa berubah lagi setiap beberapa bulan, jadi ada kalanya fenomena "solusi sementara jadi permanen" tidak terjadi. Namun bagi kebanyakan orang, setelah bertahun-tahun mereka tetap harus membereskan akibatnya, dan skenario "nanti kalau perlu kita tulis ulang" hampir tidak pernah berjalan. Dan penulisnya sendiri belum pernah benar-benar mengalami setahun kemudian, apalagi lebih lama

    • Saya terutama terkesan pada bagian "setiap beberapa bulan..." itu. Saya penasaran apakah itu diucapkan setelah mengalaminya sekitar 4 kali

  • Bagi orang yang lelah dengan spreadsheet besar, MS Access dulu adalah solusi yang cukup berguna. Ia menambahkan struktur dan kemudahan pemeliharaan pada spreadsheet sambil tetap menjaga aksesibilitas dan tingkat kesulitan pengembangan. Anda bisa membuat UI yang bagus tanpa banyak pengetahuan coding. Sekarang, 20 tahun kemudian, saya sendiri tidak yakin solusi apa yang menggantikan Access

  • Saya sepenuhnya setuju dengan OP. Satu hal yang ingin saya tambahkan: ketika kebutuhan menjadi terlalu kompleks untuk ditangani di Google Sheets, Google Colab (atau Jupyter notebook) menjadi pilihan satu tingkat di atasnya. Sebelum benar-benar membangun aplikasi, saya selalu bertanya: 1. Bisakah ini cukup dengan spreadsheet biasa? 2. Kalau tidak, bisakah ini cukup dengan Jupyter notebook? Sebagai catatan, integrasi antara Sheets dan Colab juga sangat bagus

    • Menurut saya jupyter notebook justru tahap yang jauh lebih rumit daripada sekadar menulis python script. Anda juga bisa menambahkan komentar pada python script, jadi saya kurang suka pendekatan "menjalankan blok kode satu per satu sambil menyalakan webserver lokal hanya untuk melihat komentarnya"

    • Saya penasaran bagaimana cara meng-upgrade sesuatu yang tadinya ada di google sheet menjadi colab notebook. Dengan paket python gspread, data mentah dari sheet memang bisa dibaca, tetapi rasanya akan sulit membawa grafik atau elemen interaktif yang sudah ada langsung ke jupyter notebook. Sepertinya pada akhirnya harus dibuat ulang

    • Google Apps Script juga alternatif yang bagus. Dengan skrip sederhana seperti untuk mengambil data, Anda sudah bisa melakukan cukup banyak hal

  • Salah satu masalah terbesar dalam otomatisasi bisnis adalah jurang yang ada di antara shadow IT, platform low-code, dan proyek yang benar-benar "resmi". Jalur migrasi yang layak di antara "asal bikin dengan google form" dan "membangun aplikasi react lengkap dengan CI/CD, testing, CDN" terasa kosong. Yang ada hanya alternatif semacam walled garden yang tidak saling kompatibel

    • Menurut saya tahap tengah itu justru solusi SAAS seperti ERP atau CRM. Kebanyakan juga punya fitur ekspor data yang cukup masuk akal
  • Saya mengelola semua keuangan saya dengan Google Sheets. Saya juga membuat sendiri UI Expense Tracker dan sudah mengumpulkan lebih dari 5.000 catatan pengeluaran selama beberapa tahun. Belakangan saya juga membuat alat web UI dengan vibe coding menggunakan Google Service Account, lalu menjadikannya PWA agar bisa dipakai di ponsel. Untuk penggunaan sederhana (terutama aplikasi untuk satu orang), Google Sheets sudah cukup tanpa DB

    • Saya juga sudah lama memakai pendekatan yang sama. Saya sudah mencoba banyak aplikasi khusus, tetapi selalu kembali ke cara yang saya buat sendiri. (Lucunya, Microsoft Money 20 tahun lalu lebih mendekati apa yang saya inginkan dibanding aplikasi-aplikasi masa kini.) Saya ingin menambah fitur, tetapi setiap kali mencoba membuatnya sendiri saya selalu lelah di tengah jalan karena kode boilerplate yang terus berulang, lalu akhirnya kembali ke solusi lama yang sudah akrab bagi saya. (Ini cerita sebelum ada vibe coding, jadi mungkin sekarang saya bisa mencoba lagi)