- Hızlı değişen erken aşama iş ortamlarında, sorunları en kolay çözümle hızlıca çözmek ve sınırlar görünür olduğunda gereksinimleri yeniden değerlendirip yerine başka bir şey koymak ya da güçlendirmek akıllıcadır
- Google Sheets, hızla değişen ortamlarda etkili bir problem çözme aracıdır; karmaşık araçlar geliştirmektense gerçek kullanılabilirlik ve israfın azaltılması açısından daha avantajlıdır
- Yazar, iş pratiğinde genel amaçlı araçlar yerine özel sistemleri aceleyle kurarken kapsam belirsizliğini göz ardı edip zaman kaybettiğini geriye dönüp değerlendiriyor
- Temel yöntem, en küçük ve en kolay çözümle başlamak → gerçek iş üzerinden kapsamı görmek → gerekirse kademeli iyileştirmek şeklindeki küçük başla, yinele stratejisidir
- Ancak her problem bir e-tabloyla çözülemez; kapsam netleşene kadar geçici olarak kullanmak uygundur ve organizasyon bağlamına uygun akıllı bir seçim yapmak önemlidir
Sorun çözmek için en kolay seçim
- Hangi sorun olursa olsun, önce uygulaması en kolay çözümü seçmek önemlidir
- Bu yöntem artık işin ihtiyaçlarına uymadığında, yeni gereksinimlere göre mevcut çözümü iyileştirmek veya alternatif aramak gerekir
- Yazarın deneyimlediği ortamda çoğu durumda yeni bir Google Sheet oluşturmak en iyi yöntemdi
Hızla değişen startup ortamı ve araçların faydası
- Yaklaşık 9 ay önce işe girdikten sonra, küçük ve başlangıç aşamasındaki bir şirket için yeni araçlar ve servisler üretme heyecanı kayboldu
- İş yönünün her 2 ayda bir değiştiği bir ortamda birçok proje başlatıldı ve sonra bırakıldı
- Pek çok durumda, Google Sheet ile kolayca çözülebilecek şeyler için gereksiz derecede karmaşık projelere zaman ve emek harcandı
Zaman kaybı örnekleri
-
Kargo yönetimi admin paneli
- İş için gelen kargoları yönetmek ve takip etmek amacıyla bir admin paneli tasarlayıp geliştirmek 2 ay sürdü
- Amaç, paketleri ve müşteri verilerini sınıflandırmak ve daha iyi yönetmeye yardımcı olmaktı
- Bu admin paneli iki kez kullanıldı ve bir daha hiç kullanılmadı
- Google Sheet ile kolayca değiştirilebilirdi ve şu anda bu iş için o kullanılıyor
-
Gümrük vergisi otomatik hesaplama MVP’si
- Belirli ürünler sipariş edildiğinde gümrük vergisi ve harçları otomatik hesaplayan bir teklif sistemi MVP’si geliştirmek 3 hafta sürdü
- Zimbabve’de vergi ve gümrükler çok karmaşık olduğu için, müşterinin tam olarak ne ödeyeceğini bilmesi daha iyi bir müşteri deneyimi sağlıyor ve üçüncü taraf gümrük işleme şirketinin tüm müşteri sorularını yanıtlamasını beklemeye gerek kalmadan süreci hızlandırıyor
- Sonunda rakibin vergi ve gümrük sınıflandırma tablosuna bakıp bunu Google Sheet’e kopyalayarak kullandılar
-
CRM seçimi süreci
- İşte kullanılacak iyi bir CRM bulmak için araştırma, toplantılar (1 saatten uzun) ve aramalara 2 ay harcandı
- Çeşitli CRM’lerin özellikleri ve fiyatları oturulup karşılaştırmalı olarak analiz edildi
- Sonunda Oddo’nun ücretsiz sürümünü kullanmaya karar verildi, ancak iş içinde çok fazla kullanılmadı
- Şaşırtıcı şekilde birkaç hafta önce Google Sheets içinde yerleşik bir CRM şablonu olduğu fark edildi
Google Sheets yaklaşımının ilkeleri
- Google Sheet oluşturmak her sorunun en iyi çözümü değildir, ancak yazarın durumunda çoğu zaman öyledir
- Sık sık, gerçek işe başlamadan önce sorunun tam kapsamını asla bilemediğiniz durumlarla karşılaşılır
- Bu, projeleri planlamamak gerektiği anlamına gelmez
- Ekip, iş akışını ve hangi bilgilere ihtiyaç duyulduğunu konuşmalıdır; ancak gerçek işe başlamadan önce sorunun tam kapsamı bilinemez
- Sorunun tam kapsamı anlaşıldığında, eldeki çözümü kurmaya veya iyileştirmeye başlanabilir
- Bu yaklaşım, en iyi durumda gerekmeyen tüm özellikleri ekleme yükünden kaçınmaya, en kötü durumda ise başarısız olacak projelere zaman harcamamaya yardımcı olur
- Sorunun tam kapsamını anlamanın yolu olarak, en küçük ve en kolay temel çözümü uygulayıp gerekirse sonrasında yinelemek şimdiye kadar en iyi yöntem oldu
Sınırlamalar ve dikkat edilmesi gerekenler
- Bu yaklaşımın dezavantajları da vardır; örneğin bazı organizasyonlarda tüm işlemler ve bilgiler binlerce satırlık e-tablolara kaydedilir
- Google Sheets yalnızca sorunun tam kapsamı anlaşılmadan önce faydalıdır
- Hangi problemin Google Sheet ile çözülebileceğine dair deneyim ve muhakeme gerekir
- Zaman kaybetmeden gerçekten kullanılabilecek araçlar geliştirmeye öncelik verilmelidir
- Ancak bu, herkes için geçerli bir tavsiye değildir; herkesin kendi durumuna göre dikkatle karar vermesi gerekir
Sonuç
- En az çabayla, en basit çözümden başlamak ve yalnızca gerektiğinde genişletmek ya da geliştirmek, startup’lar veya sık değişen ortamlar için çok uygun bir stratejidir
- Kişisel geliştirme denemeleri özgürce yapılabilir; ancak iş tarafında yalnızca gerçekten gerekli olanı üretmek ve gereksiz işlere zamanla enerji harcamamak önemlidir
3 yorum
Ben de temelde katılıyorum; ancak
Google Sheetsyerine artık başlangıç baseline’ı içinNotion Databasekullanmayı tercih ediyorum. Benzerler ama sonuçta şablon ayarını yapan kişi 1 kişi oluyor. Diğerleri de bunun üzerine veriyi yönetirse dağınık bir durumun önüne geçilebiliyor.App Scriptkadar iyi olmasa da otomasyonu daha kolay kurmak da mümkün. İlk kurulum zorluğu azıcık daha yüksek denebilirse de büyük bir fark yok ve esneklik gibi konularda da benzer olduklarını düşünüyorum. Üstelik son dönemde satır bazlı yetki yönetimi de geldi, bu da iyi.Bence Notion, öğrenme eğrisi düşük olduğu için iyi.
Hacker News görüşü
Bu her zaman gözden kaçan bir nokta. E-tablolar; veritabanını, hızlı ve kolay özelleştirilebilen bir UI'ı ve yinelenebilir, hata ayıklaması kolay bir veri işleme ortamını tek bir yerde topluyor. Dünyadaki tüm beyaz yaka çalışanların zaten anlayıp kullandığı bir araç ve üreticisine de istediğini özgürce hayata geçirebileceği bir esneklik sağlıyor. Taşınabilirliği de çok iyi. Özellikle kod yazamayan insanlar için yaratıcı ve güçlü bir araç olduğuna eminim. Elbette bu özgürlüğün dezavantajları da var ama çevrimiçi olup olmaması ya da hangi vendor'un daha iyi olduğu tartışmalarına rağmen, e-tablolara duyduğum derin sevgi hiç azalmıyor. Yaptığımız araçlar içinde en iyi yazarlık aracı olduğunu düşünüyorum. E-tabloya benzer model olarak HyperCard'ı örnek verirdim. Çeşitli uygulamaları, verileri, UX'leri birbirine bağlayabilen esnek bir çalışma tezgâhıydı. HyperCard'ın sonsuza dek hatırlanmasını isterim
Evet, e-tabloların giriş eşiği gerçekten çok düşük. Hatta tarlanın ortasında telefondan Google Sheets'e ürün gelişim kayıtları giriyorum. Sinyal zayıf olsa bile çevrimdışı modda kaydedip eve dönünce senkronize ediyorum. Kayıtlar dağınık olsa bile hiç olmamasından çok daha iyi. Tarım çok fazla veri gerektiriyor ama şaşırtıcı biçimde veri açısından yoksul bir alan. Öğrenme döngüsü 1 yıllık olduğu için uzun ve her yıl da birbirinden farklı geçiyor
Kod yazabilen biri için Appscript, e-tabloları neredeyse bir süper güce dönüştürüyor. Bilmeyenler için söyleyeyim, Google Sheets'e gömülü web IDE'sinde sadece JS yazmak zorunda değilsiniz (aslında o da gayet kullanışlı).
claspkullanırsanız yerel IDE'de Typescript ile geliştirip, build sürecinde JS'ye derleyerek doğrudan e-tabloya dağıtabilirsiniz. Toolchain'i kurduğunuzda geliştirici deneyimi (DX) de oldukça iyi oluyorBuna güçlü biçimde katılıyorum. Veritabanı + UX + mantığın tek bir çalışma tezgâhında birleşmesinin değeri, tekrar tekrar inşa ettiğimiz uygulamaların özü gibi görünüyor. Bu yüzden Visual Basic hâlâ kullanılıyor. Elbette yön netleştikten sonra en iyi yöntem bu olmayabilir ama hızlı yinelemelerle gerçek ihtiyaçları keşfetmek için bundan iyisi yok
E-tabloları veritabanı backend'i olarak daha iyi kullanmanın bir yolu olsa harika olurdu diye düşünüyorum. İnsanların e-tablolarla yaptığı işlerin önemli bir kısmı veritabanında daha iyi çözülebilir. Ama veritabanları daha fazla eğitim gerektiriyor ve eğitim eksik olduğunda sonuçlar e-tablodan bile daha kötü olabilir
E-tablodan özel UI'a sahip tam bir veritabanına neden kademeli ve gerçekçi bir geçiş yolu olmadığını hep merak etmişimdir. E-tablo zaten bu rolün hemen bir önceki aşaması gibi; birkaç temel özellik daha olsa (yapısal veri, yerel SQL, özel UI bileşenleri, IDE entegrasyonu vb.) yeterli olurmuş gibi geliyor
Bana "Ask HN: Is the world run by badly updated Excel sheets?" başlığını hatırlatıyor. E-tabloların sınırlarını bizzat yaşamak için deneyim gerekiyor. Sürüm kontrolü yok, test de yok. Değişmeyen ve kısa ömürlü işler için iyiler ama sürekli evrilmesi gereken şeylerde sorun oluyorlar. Bkz. https://news.ycombinator.com/item?id=33611431. O başlıkta şöyle bir yorum vardı: Sonuçta şirket içinde herkes Excel sahibinin çalışma şekline uyum sağlıyor. Beğenmezse gidip yeni bir Excel oluşturup kopyala-yapıştır yapabildiği için herkes kendi başına yönetiyor. Tanıdığım bir proje yöneticisinin günlük işi, birden fazla yazarın hazırladığı e-tablo sürümlerini sürekli uzlaştırmaktı
2000'lerde ABD'de yazılımcı olarak başladığımda işimin, Windows ağ sürücüsünde duran ve sürekli birilerinin özenle bakması gereken e-tabloları web uygulamasına dönüştürmek olduğunu sanıyordum. Ama hâlâ birçok şirket e-tablo temelli şekilde gayet iyi çalışıyor. Sonunda ölçeklenebilirlik sorunu patlıyor ve o zaman uygulamaya taşımak gerekiyor ama mükemmel olmaya çalışıp hiçbir şey yapamamaktansa önce işi görmek daha önemli
"Sürüm kontrolü yok" denmiş ama aslında Excel'de sürüm kontrolü işlevleri var. 'Değişiklikleri izle' ile başkalarının yaptığı değişiklikleri onaylayabilir veya reddedebilirsiniz. Tabii bu özelliği, Rube Goldberg tarzı e-tablo otomasyonlarıyla iş yürüten insanlar neredeyse hiç kullanmıyor. Gerekirse kullanılabilir
Bilginin birden fazla e-tabloya dağılması yüzünden çok sorun gördüm. İnsanlar çoğu zaman hangi bilgilerin hangi e-tabloda olduğunu ve hangisinin esas kaynak olduğunu bilmiyor. Bu yüzden biri yalnızca A dosyasını güncellediğinden habersizken diğeri sadece B'ye dokunuyor ve sık sık çakışma yaşanıyor. Sorun genelde programın ya da verinin kendisinden çok, dosyaların proje içinde nasıl yönetildiğiydi. Karmaşık paylaşımlı klasörler, ağın bir yerinde unutulmuş dosyalar derken tam bir yönetim labirentine dönüşüyor
"Bir problemi çözmek için her zaman en kolay yolu kullan; o yol artık işine uymadığında yeni gereksinimlere göre iyileştir ya da alternatif çözüm bul" tavsiyesine katılıyorum. Elinizdeki problemi çözmeye odaklanmak gerekir; ileride belki çıkacak ya da çıkmasını umduğunuz problemleri önceden düşünerek doğru hedefi tutturmak zordur. Mevcut çözüm gelecekte yetersiz kalabilir ama nasıl yetersiz kalacağını tahmin etmek zordur
Bir çözümün gelecekte hangi açıdan yetersiz kalacağını öngörmek zor olsa da, yine de gelecekteki çözümleri engellemeyen ya da zorlaştırmayan biçimde bugünkü çözümü seçebilirsiniz. Seçenekleri açık tutmak ve vendor lock-in'e düşüp çıkılamaz hâle gelmekten kaçınmak iyi olur
Öngörülebilir en tipik yetersizlik örneği, belirli bir vendor'a tamamen bağımlı kalıp ya hizmetten zorla çıkarılmak ya da giderek artan ücretleri kabullenmek zorunda kalmaktır. Bu gayet öngörülebilir bir problemdir
Çok daha fazla iş yapmadan, problemi alanın genelini kapsayacak şekilde çözerseniz, küçük değişimlerle dalgalanan gereksinimleri emebildiği için çözümün sağlamlığını artırabilirsiniz. Böylece doğal olarak gelecekteki problemleri de kapsar
ABD'de tanınmış büyük bir şirkette çalışıyorum. Bölümümüz iki e-tabloya ciddi biçimde bağımlı. Kendi fabrikamla ilgili üç birleşme ve satın alma sürecinden sağ çıktılar. 7 yıl önce işe başladığımda bile zaten eski bir formattı. 2 yıl önce yeni bir yönetici bunu şirket genelindeki bir sisteme taşımaya çalıştı ama başarısız oldu ve yakında o sistem de yeni bir sistemle değiştirilecek. Ama 2027'de bile hâlâ e-tabloları kullanıyor olacağız gibi görünüyor
Eski bir Google çalışanıyım. 5 yıl boyunca yalnızca Sheets'i (içeride Trix deniyordu) kullanarak proje yönetimi, CRM, çeyreklik planlama, raporlama, mülakatlar, finans ve diğer tüm işleri yürüttüm. Sırf Google ürünü olduğu için kullanmıyorduk (rakip ürünler de gayet kullanılıyordu). E-tabloları hedefe ulaşmak için yeterince hızlı oluşturabilmenin ezici rahatlığı sayesinde işin özüne odaklanabiliyorduk
Birinin "işe başlayalı 9 ay oldu" yorumuna bakınca, doğru da olsa yanlış da olsa henüz bir yılı bile dolmamış bir deneyimle bu kadar kesin konuşmanın epey cesurca olduğunu düşündüm. OP'nin kaçırdığı nokta şu: "Geçici çözüm kadar kalıcı bir şey yoktur." Kısa vadede hızlı ve doğaçlama bir çözüm seçmek ancak o çözümün yaşam döngüsünü tamamen kontrol edebiliyorsanız kabul edilebilir. Biri sizden bir şey yapmanızı isteyip siz de hızlıca teslim ettiğinizde, sonra onun üzerine sürekli yeni kullanım alanları eklenmeye başlanıyorsa… başlangıç maliyeti biraz daha yüksek olan bir aracı güçlü şekilde savunmaya başlarsınız
O sorundaki "birkaç ayda bir..." ifadesi beni neredeyse güldürecekti. Yazar, işi basit araçlarla halletmenin temel ilke olduğunu doğru yakalamış. Mevcut araçları olduğu gibi kullanabilmek ve ihtiyaçları yeterince karşılaması en iyi durum. Gerçek hayatta iş gereksinimleri birkaç ayda bir değiştiği için bazen "geçici çözüm kalıcı olur" durumuyla karşılaşmayabilirsiniz. Ama çoğu insan için yıllar sonra bile artıkları toplama işi sürer ve "gerektiğinde baştan yazarız" senaryosu neredeyse hiç işlemez. Yazar da henüz bir yıl sonrasını ve ötesini bizzat yaşamış değil
Benim özellikle dikkatimi çeken de o "birkaç ayda bir..." kısmıydı. Acaba bunu söylemeden önce bunu dört kez falan gerçekten yaşadı mı diye düşündüm
Büyük e-tablolardan bıkan insanlar için MS Access oldukça işe yarar bir çözümdü. E-tabolara yapı ve bakım kolaylığı eklerken erişilebilirlik ve geliştirme zorluğu dengesini koruyordu. Çok fazla kod bilgisi olmadan da harika UI'lar yapılabiliyordu. Aradan 20 yıl geçti; bugün Access'in yerini alan çözümün ne olduğunu ben de pek bilmiyorum
OP'ye tamamen katılıyorum. Bir ekleme yapayım: Google Sheets'te yönetilemeyecek kadar karmaşık gereksinimler çıktığında, Google Colab (veya Jupyter notebook) bir üst seviye seçenek oluyor. Gerçek bir uygulama inşa etmeye başlamadan önce hep kendime şunu soruyorum: 1. Bu sadece bir e-tablo ile olur mu? 2. Olmazsa Jupyter notebook ile olur mu? Ayrıca Sheets ile Colab arasındaki entegrasyon da harika
Bence jupyter notebook, sadece bir python script yazmaktan çok daha karmaşık bir aşama. Python script'e de yorum eklenebilir; sırf yorum görmek için "yerel bir web sunucusu çalıştırıp kod bloklarını parça parça yürütmek" bana çok cazip gelmiyor
Mevcut bir google sheet'tekileri colab notebook'a yükseltmek nasıl yapılıyor merak ediyorum.
gspreadPython paketiyle sheet'in ham verisini okuyabilirsiniz ama mevcut grafik ve etkileşimli öğeleri doğrudan jupyter notebook'a taşımak zor görünür. Sonunda muhtemelen yeniden yapmak gerekirGoogle Apps Script de iyi bir alternatif. Veri çekme gibi basit script'lerle bile oldukça fazla şey yapılabiliyor
İş otomasyonundaki en büyük sorunlardan biri, sözde 'shadow' IT, low-code platformlar ve tam anlamıyla 'resmî' projeler arasındaki boşluk. "Google Form ile hızlıca bir şey yapmak" ile "CI/CD, test ve CDN'li bir React uygulaması kurmak" arasında makul bir geçiş yolu eksik. İki taraf da birbiriyle uyumsuz, duvarlarla çevrili bahçeler gibi alternatifler sunuyor
Tüm finans yönetimimi Google Sheets ile yapıyorum. Expense Tracker UI'ını da kendim yaptım ve yıllar içinde 5.000'den fazla harcama kaydı biriktirdim. Son dönemde vibe coding ile Google Service Account kullanan bir web UI aracı da yaptım, sonra bunu PWA'ya çevirip telefonda da kullanmaya başladım. Basit kullanım senaryoları için (özellikle tek kullanıcılı uygulamalarda) veritabanı yerine Google Sheets fazlasıyla yeterli