Teknik İşlerin Başarısız Metalaştırılması
(ludic.mataroa.blog)- Teknik işleri bir fabrika gibi standartlaştırıp yeniden üretilebilir çıktılara dönüştürmeye yönelik yönetim ve tedarikçi beklentisi büyük olsa da, pek çok saha hâlâ bu şekilde istikrarlı biçimde ürünleştirilebilmiş değil
- McDonald's tarzı operasyon, kalitenin kendisinden çok farklı yerlerdeki ve farklı çalışanların aynı sonucu üretmesini sağlayan bir disipline daha yakın; birçok yönetim kitabı da BT operasyonlarını bu tür bir üretim akışı olarak ele alıyor
- Kurumsal yazılım satışları, SQL, veri ve geliştirme işlerini sürükle-bırak ve tutarlı arayüzlerle değiştirip çalışanları ikame edilebilir hâle getirme vaadine yakın
- Gerçek organizasyonlarda kötü yazılım lisansları ve hatalı soyutlamalar teknik sorunları çözmüyor; sonunda çoğu zaman çok iyi mühendislerin kötü veri modellerini ve teknik kararları bizzat düzeltmesi gerekiyor
- Yaratıcılık, zevk, uzmanlık ve insanlar arası bağlantı gerektiren işler Jira panolarına ya da Agile puanlarına tamamen indirgenemiyor; büyük ölçekli üretim altyapısının içinde bile sistemi tek tek insanlar hareket ettiriyor
McDonald's'ın gösterdiği standartlaştırma zorluğu
- Çok iyi bir veri mühendisi olan ilk yöneticim, yemek yapmaya derinden meraklı biriydi ve McDonald's operasyonlarının karmaşıklığını birçok kez yüksek takdirle anlatmıştı
- McDonald's'ın değeri, çıktının kalitesinden çok, eğitim düzeyi ve bölgesi farklı çalışanların aynı burgeri yapmasını sağlayan optimizasyon ve disiplinde yatıyor
- Farklı konumlardaki vasıfsız iş gücünün tutarlı sonuçlar üretmesini sağlamak basit değil; bu örnek teknik işlerin metalaştırılması tartışmasına uzanıyor
Yönetim kitapları BT'yi fabrika gibi ele alıyor
- The Phoenix Project, BT operasyonlarını imalat fabrikasındaki işlere benzer bir sorun olarak konumlandırıyor ve organizasyon içindeki iş akışı ile iletişim yönetimini merkeze alıyor
- Benzer bir duyguya sahip kitaplar olarak The Unicorn Project, Investments Unlimited ve The Goal geliyor
- The Goal, gerçek bir fabrikanın operasyonlarını değiştirme hikâyesi; diğer kitaplara ilham veren eser olarak ele alınıyor
- High Output Management da bir restoranda işlerin akış biçimini örnek veriyor; yumurtayı yanlış zamanda haşlarsanız müşteriye ulaştığında tostun soğumuş olacağı gibi örneklerle iş akışını açıklıyor
- Bu düşünce çizgisinde ölçek ekonomisi, verim/iş hacmi ve iş akışı gibi konular tekrar tekrar karşımıza çıkıyor
Tedarikçi sunumlarının özü teknolojiden çok ikame edilebilirlik
- Bir tedarikçi konferansındaki çeşitli ürün sunumları, teknik ayrıntılardan çok yeterince iyi iş çıktılarının yeniden üretilebilir şekilde teslim edileceği vaadine odaklanıyor
- Belirli bir ürün, doğrudan SQL yazmadan sürükle-bırak editörüyle bağımlılıkların ayarlanabileceğini öne çıkarıyor
- Gerçekte uygulama Postgres'e bağlandığı için SQL ortadan kalkmıyor; lisanslı bir soyutlama katmanı SQL'i onun yerine yazıyor
- Bu tür sunumlar yöneticilere, “yavaş ve sorunlu SQL”i tutarlı bir arayüz ve piyasadaki araç uzmanlarıyla değiştirerek organizasyon içinde veri teslimini sorunsuz hâle getirebilecekleri mesajı gibi gelebilir
- Agile'ın ortalama derecede işlev bozukluğu olan organizasyonlarda uygulanma biçimi de benzer bir sorunu açığa çıkarıyor
- Mühendisleri makine, çıktıları parça, story point'leri üretim birimi gibi sayıp gelecek haftanın hedefe ulaşma oranını kontrol eden bir yaklaşım
Pek çok teknik işin hâlâ metalaştırılamamasının nedeni
- McDonald's genelde 5 dakika içinde belirli kalitede patates kızartması sunar, ancak birçok teknoloji organizasyonu değerli bir şey dağıtamadan kötü yazılım lisansları satın alır
- Teknik sorunları ve kötü veri modellerini parayla çözmenin yolu, sorunu çözmeye odaklanan çok iyi mühendisleri elde tutmaya daha yakındır
- Metalaştırmanın mümkün göründüğü alanlar çoktur; ama pratikte bu çoğu zaman çalışmayan ürünler satan şirketlerle bunları satın alan bilgisiz karar vericilerin birleşiminden ibarettir
- Bazı karar vericiler, yasal uyumu karşılama adına düşük ücretli bölgelerdeki telefon desteğini kullanabilir ve iptal etmek isteyen müşterileri umursamayan bir yolu da seçebilir
- Destek görevlisine ulaşmak gerektiğinde önce satış hattını arayıp yetkili yerel bir kişiye hızlıca bağlanmayı denemek gibi bir deneyim de aktarılıyor
Yaratıcı teknik işlerde insan unsuru kalır
- Rich Hickey'nin Hammock Driven Development konuşması, araştırmayı bilinçdışına yerleştirip meditasyon yapmak, uyumak ve tasarım yanıtını bu şekilde elde etmek gibi bir iş akışını ele alıyor
- Programcılar çoğu zaman sorundan uzaklaştıklarında yanıtın akıllarına geldiğini deneyimler; bu, yalnızca widget'ları daha hızlı üretme işinden farklıdır
- Toplumda daha hızlı üretmeye dayalı birçok iş vardır; ancak değerli pek çok çıktı, tanımlaması zor yaratıcılığın üretim gerçekliğiyle buluştuğu noktadan çıkar
- Kitap, yemek ve restoran işletmeciliği gibi örneklerde de seri üretim ya da teslimat sistemleri rafine edilebilir; ancak güzel sonuçlar zevk ve özen gerektirir
- Özellik geliştirmeyi Jira panolarına ve Agile hikâyelerine indirgemeye çalışsanız da, insanlarla bağlantı kurulmadığında değerli sonuçlar elde etmek zordur
- iPhone'a giren çipleri tasarlayan bir tanıdığın örneğinde olduğu gibi, test ve seri üretim altyapısı olsa bile belirli bir kişi hastalandığında bir sonraki sürüm gecikebilecek kadar tek tek insanlar önemli rol oynar
- Toplumun metalaştırma üzerinde işlediği bir gerçek; ancak belirli bir zanaata dair anlayışı ve insanların karmaşıklıklarını, ihtiyaçlarını ve kırılganlıklarını yok sayan saf metalaştırma ile teknik işleri yürütmek mümkün değildir
1 yorum
Hacker News yorumları
Yazarın, eskiden teknik iş olarak adlandırılan şeylerin önemli bir kısmının artık genel amaçlı metalaşmış olduğunu gözden kaçırdığını düşünüyorum.
Eskiden mail merge gerçekten de bir sürü adres etiketi basıp bunları mektuplara ve zarflara elle yapıştırmak demekti; Word 2.0 civarı 1990'larda bu sorunu çözdü, MailChimp de 21. yüzyılda bunu ürünleştirdi.
Çift taraflı muhasebe de yüksek eğitimli birinin yaptığı teknik bir işti; şimdi ise dükkân sahibi barkod okutuyor, müşteri de temassız ödeme yapıyor.
Scratch'ten daha karmaşık şeyler için kullanılabilecek bir sürükle-bırak arayüzü henüz yok, ama zor kısım kütüphaneleri birbirine bağlama şeklindeki teknik iş değil, gereksinim toplama.
Yüksek kaliteli bir şifreleme kütüphanesi eklemek, bir web sitesine etkileşimli harita getirmek ya da bir web sitesini WYSIWYG olarak düzenlemek her zamankinden daha kolay.
Sıkılmış 18 yaşındaki birini IDE'nin başına oturtup ERP yaptırmak mümkün değil; bu açıdan yazar haklı, ama IT'deki pek çok angarya artık kesinlikle ürünleşmiş durumda.
Teknoloji sektöründeki angaryanın azalmaktan çok arttığını düşünüyorum: Şu anda X kadar angarya var, yeni bir Z teknolojisi çıkıp X'i 0,1X'e indiriyor; ama aynı anda Z yeni çalışma biçimlerini mümkün kılıyor ve bunun yan ürünü olarak başka angaryalar doğuyor. Böylece mevcut angarya Y oluyor ve Y kabaca X'e yakın kalıyor.
2000'lerde teknolojik ilerleme dursaydı, 90'lardan gelen angarya bugün neredeyse 0'a inmiş olurdu; ama yeni teknoloji otomasyonu da angaryayı da birlikte getiriyor.
Yakın tarihli örnek yapay zeka araçları. Ses, görüntü, video ve metin üreten araçlar var; ama farklılaşmış bir ürün ya da deneyim yaratmak için ChatGPT, Stable Diffusion gibi araçları bir araya getirme angaryası gerekiyor.
Ne kadar çok ürünleştirirseniz, sorunlar o kadar üst düzeye taşınıyor; işe alınan uzman mühendisler de stack'in daha üst katmanlarına kayıyor.
Son dönemde SaaS'e dönüşmüş startup ürünleri arasında, hâlâ istenen işi gerçekten yapamayanların oranı yüksek görünüyor. Para alıp hizmeti kullandırdıktan sonra müşterinin kullanım senaryolarını uygulanacak şeyler olarak toplayıp başka müşterilere ürünleştirmeye çalışıyorlar; bu da lead time'ı uzatıyor ve fikrî mülkiyetin de sızmasına yol açıyor.
SQL'i şablonlaştırma, yöneticilerin sürekli yanlış anladığı bir konu. SQL sektörde şaşırtıcı derecede uzun süre hayatta kaldı ve aslında oldukça iyi iş görüyor. Üzerine konan wrapper'ların ya da DSL'lerin %99'u bunu çok daha kötü hâle getiriyor; azıcık bile sıradan olmayan bir işte sonunda SQL'e inmek gerekiyor. SQL uzmanı işe almak yerine, aslında var olmayan SaaS tarzı DSL SQL wrapper X uzmanı yetiştirmek zorunda kalıyorsunuz.
Temel sorun, bu ürünlerin o alanda çalışmayan satın almacılara “satın alıp prize takınca sorunu çözen bir ev aleti” gibi görünecek şekilde tasarlanması olabilir.
Pek çok ürün aslında sorunu çözmüyor; sadece başkaları satın aldığı için çözüyormuş gibi görünüyor. Üstelik terfi edebilmek için uygulamanın başarılı olduğu yalanını söylemek gerekiyor. Mail merge gibi şeyler gerçekten de su ısıtıcısı gibi, artık çözülmüş sorunlar; bu tür sorunlar denenerek çözülebilir.
Daha büyük sorun, işverenimin Workday'i su ısıtıcısı gibi bir şey sanıp satın almasıydı; ama örgüt yapımız o kadar berbat ki modellenemiyor bile, bunu düzeltemedi.
Bu yıl ilk kez, büyük bir şirkette yeterince kötü bir organizasyon yapısının bir tür teknik borç olduğunu fark ettim. Kimin kimin altında çalıştığını, bu kullanıcının bu veritabanında neyi görebileceğini anlamak için türlü tuhaf işler yapmak zorunda kalıyorsunuz.
1994'e ya da 2004'e kıyasla bugün bir işletmeyi yürütmek, web sitesi yapmak, seyahat planlamak, fatura ödemek ne kadar basitleşti?
Bazen önceki nesillerin hayat temposu daha sakindi ve bu yüzden daha dolu dolu yaşadıkları hissine kapılıyorum. Şimdi zaman çok hızlı akıp gidiyor ve stres de yüksek.
Kısa süre önce bankada, 60 yaşın üzerinde en az üç kişinin basit bir işi halledemeyip bocaladığını ve personelden yardım istediğini gördüm. İnternet bankacılığıyla kolayca yapılabilmesi gereken bir işti; ama istisnai durumlar yüzünden sistem desteklemiyordu, sonunda randevu almak zorunda kaldılar ve en erken tarih 3-4 ay sonraydı.
İçlerinden biri evini ısıtmak için odun almak üzere bloke edilmiş hesabından para çekmek zorundaydı, ama banka görevlisi sadece 3 ay beklemesini söyledi.
İki yıl önce babam Sicilya'dan eve basit bir telefon araması yapmanın yolunu bulamadı. 1970'lerde olsaydı yakındaki bir bara girip birkaç bozuk para atması yeterli olurdu.
Eskiden sıradan biri lambayı, arabayı, ısıtmayı, otomatik olmayan bir kapıyı kendi başına tamir edebilirdi; şimdi ise uzman çağırmak gerekiyor.
Teknik işi tamamen metalaştırmaya çalışma fikri kötü; umarım bundan sonra da başarısız olur
Yine de The Phoenix Project’i iki kez okumuş ve Scrum’ın çoğundan hoşlanmayan biri olarak, o kitabın böyle bir şeyi savunduğunu düşünmüyorum
Benim çıkardığım ana fikir şuydu: tekrarlanabilir işleri yapmak ve yönetmek için net bir sistem kurmak, mümkün olan yerlerde otomasyon yapmak; devam eden iş miktarını azaltarak insanların sayısız göreve bağlanmasını önlemek; bilgiyi genişçe paylaşmak ve birden fazla ekip üyesinin aynı işi yapabilmesini sağlamak; gerçekten işin ihtiyaç duyduğu şeyleri yaptığımızdan emin olmak; gürültüyü ve plansız işleri azaltarak çalışanların düzensiz bir bataklıkta debelenmek yerine keyif alabilecekleri yüksek değerli işlere odaklanmasını sağlamak
The Phoenix Project’in özü, insanları birbirinin yerine geçebilen otomatlara dönüştürmek değil; otomatikleştirilemeyen ya da sistemleştirilemeyen gerçekten değerli işleri yapmaları için onlara alan ve zaman sağlayan bir sistem kurmak
Hem fabrika işletmiş hem de geliştirici olarak çalışmış biri olarak iki tarafı da görüyorum: geliştiricileri üretim fabrikası işçilerine dönüştürmek mantıksız, ama bilinen işler ve tekrarlanabilir adımlar gibi fabrika işine benzeyen işler de benzer şekilde ele alınmalı
s/manufacturing/IT/guygulamak ve modern referanslarla güncellemek gibi bir şeyKitabı sevmediğim anlamına gelmiyor. Yarısını okudum ve ekiplerin düşünme biçimini sistem merkezli hâle getirmek için okutmaya çalıştım. Ama The Goal’dan çok daha derin ya da içgörülü olduğunu da söyleyemem
Üslubuyla dalga geçtim ama gerçekten okumaya değerdi. Bilinen işler ya da tekrarlanabilir adımlarda insanların yaptığı birçok hatayı Phoenix Project tarzı düşünceye yükleyemeyiz
Ancak programlamada bilinen işleri tekrar eden adımlar hâlinde yapmak nadirdir. Böyle bir şey oluyorsa, çoğu zaman paydaş yönetiminde taktiksel bir hata yapılmış ve otomasyon için zaman kalmamış demektir
Düşünerek okunduğunda son paragraftaki gibi bir sonuca varılır; ama karşılaştığım yöneticilerin çoğunun widget üretimi ile sistem tasarımı arasındaki farkı anlamadığını kesin olarak biliyorum
Sürekli öğrenme, otomasyon ve ölçümleme yukarıdaki 1–5’i mümkün kılan araçlar
The Phoenix Project’ten “daha çok çalışın, daha fazla işi daha hızlı yapın” mesajını almadım
https://scrumguides.org/scrum-guide.html
Genelde berbat olan şey, insanların Scrum dediği şeyin üstüne eklediği türlü türlü eklentiler. Kötü Scrum’a karşı en iyi yöntem kavga etmek değil, gerçek öğretiye püristçe sadıkmış gibi davranmaktı. Hem daha az muhalif görünüyorsun hem de etki etmek daha kolay oluyor
Başlık kafamı karıştırdı. “commodify” “satılabilir hâle getirmek”, yani ticarileştirmek demek değil mi? Teknoloji zaten milyarlarca dolar kazandırmadı mı?
Yazarın kastettiği şey commoditization, yani teknik işi herhangi bir ikame edilebilir çalışanın yapabileceği sıradan bir işe dönüştürmek gibi görünüyor
https://en.wikipedia.org/wiki/Commoditization sayfasına göre commoditization, tekel niteliğindeki bir şeyin genel mala dönüşmesi; commodification ise daha önce satılamayan bir şeyin satılabilir hâle gelmesi diye özetlenebilir
Fazla mı ince eleyip sık dokuyorum? İkisinin farklı anlamları olduğunu sanıyordum
Düzenleme: Wiktionary’ye bakınca https://en.wiktionary.org/wiki/commodification sayfasında birbirinin yerine de kullanılabildikleri yazıyor. Sanırım yaygın bir karışıklık
https://www.merriam-webster.com/dictionary/commodify
“İçsel değeri olan bir şeyi ya da sanat eseri gibi bir şeyi metaya dönüştürmek” anlamına geliyor; dolayısıyla commodify daha çok commoditization ile ilgili bir sözcük
Petrolün meta olmasının nedeni, çok sayıda üreticinin olması ve hepsinin aynı şeyi üretmesi; bu yüzden hangisinden aldığın fark etmiyor
McDonald’s benzetmesinde geliştirici, makinenin başında çalışan bir ergen değil, makineyi tasarlayan mühendistir. O benzetmede bilgisayar ergendir.
Programlama iş değil, meta iştir. Bir kez komut listesini oluşturduğunuzda bilgisayar o işi 24 saat boyunca yapmaya devam eder; ben de başka bir iş için yeni bir komut listesi yazmaya giderim.
Aynı komut listesini iki kez yazıyorsanız, temelde yanlış yapıyorsunuz demektir. Bu yüzden sürekli yeni işler yaparsınız; aynı işi iki kez yapmadığınız için ne kadar süreceğini bilmek zordur.
BT bir fabrika değil, fabrika yapma işidir.
Birçok geliştirici-yönetici çatışmasının, “yönetici” kelimesinin fazla genelleyici olmasından kaynaklandığını düşünüyorum. McDonald’s yöneticisi, çalışanların ürünleri ortaya çıkaran süreci izleyip izlemediğini denetler. Sürece uyulup uyulmadığı nettir; sürecin geçerli olduğu varsayılır ve çıktının ortaya çıkıp çıkmadığı da nettir.
Buna karşılık programcı, makinenin izleyeceği süreci geliştirmek için işe alınır. Bu çalışanı yöneten kişinin de programcının izleyeceği bir süreci olabilir ve buna uyulup uyulmadığı net olabilir; ancak o sürecin geçerli olup olmadığı, belirli bir davranışın belirli bir sonuca yol açıp açmayacağı ve sonucun kendisinin net olup olmadığı belirsizdir.
Buna rağmen iki role de “yönetici” denir.
Bu makine benzetmesinde programcı, insanları yöneten değil, makineleri yönlendiren başka türden bir yöneticidir. Sadece o makineler dünyaya salınır ve programcı onları sürekli gözetlemez.
Elbette diğer yorumlarda söylendiği gibi bu kavramın tamamen saçmalık olma ihtimali de var. Yine de birkaç yıl sonra bunun aptalca bir fikir olduğunu fark etsem bile, tek başıma utanmaktansa birlikte utanacak birilerinin olması daha iyi.
Yaklaşık 10 yıl önce makine mühendisi birkaç arkadaşım, yazılım geliştirme okuduğumu görünce şaşırmıştı.
“Hâlâ yapılacak çok iş mi kaldı? Gereken her şey mevcut sistemlerle yapılamıyor mu?” gibi şeyler söylemişlerdi.
Yanılgı, yeni sorunları çözen sistemler kurmanın kolay ve zaten metalaşmış olduğu, bu yüzden artık kod yazmaya gerek kalmadığı düşüncesidir.
Gerçekte yazılım inşa etmek nadiren UI ayarlamak kadar kolaydır. Mantık kurallarını ve akışları ifade eden metne ihtiyaç vardır; sistem değişikliklerini izlemek ve geri almak için sürüm kontrolüne ihtiyaç vardır; sonuçta programcılara ihtiyaç vardır.
Kodlama ortadan kaybolmaz, yalnızca soyutlama düzeyi yükselir.
Teknoloji sektörü uzun süredir geliştiricileri metalaştırmaya çalışıyor; COBOL ya da Java’nın da bu akımın içinde olduğunu düşünüyorum.
Ancak neyi soyutlarsanız soyutlayın, yeniden ortaya çıkan özsel nitelikler var. Gereksinimler basit görünse ve yüksek seviyeli framework’ler olsa bile, yazılımlarımızın önemli bir kısmı hâlâ düzgün çalışmıyor.
Yazarın dediği gibi gerçek çözüm, yetkin ve işini önemseyen geliştiricilerdir. Bununla bir kariyer inşa edebilirsiniz.
Aynı alanda uzun süre çalışırsanız kalıplar benzer biçimde tekrarlanır, ama her birinin iş gereksinimleri biraz farklıdır. Stack’in her katmanında bu fark büyür ve toplamda metalaşmamış, özel uyarlama gerektiren işlerin miktarı muazzam hâle gelir.
Bu yüzden iki ürün tam olarak aynı değildir ve her şeyi üreten tek bir dev küresel şirket yoktur.
İnsanların kendilerini Taylorcu biçimde parçalara ayırdığı öz metalaştırma fırsatı çıktığında geliştiricilerin heyecanlandığını sayısız kez gördüm.
Sağlık sektörü, otomatik metalaştırma tartışmaları açıldığında verdiğim karşı örnektir. Duygusal olarak iki tür çekiciliği var. Hastalar doktorlar arasında oradan oraya dolaştırılmaktan hoşlanmaz. Metalaştırmanın bir ölçüde uzmanlaşma artışını beraberinde getirdiğini ve her ek devir teslimin bir başarısızlık noktası daha eklediğini anlarlar.
İkincisi, statüyü ve çalışma biçimini daha yüksek statülüymüş gibi gösterebilme imkânıdır. İlki öne çıkarılıp ikincisi alt metin olarak bırakılırsa genelde işe yarar. Çalışanlar daha genel yetkinliklerini korur ve işi devretmekten çok birbirine danışmaya dayanır.
Montaj hattı, sıralı uzmanlaşmadır; tıp asistanlarının çalışma saatleriyle ilgili devir teslim hatalarına bakmak yeterli.
Operasyon, inovasyon, bakım. Üçünden istediğiniz üçünü seçin.
Bunları aynı ekibin ya da birbirine çok yakın ekiplerin yapması daha iyidir.
İdeal olarak ekipteki herkes üç işlevi de farklı derecelerde yerine getirmelidir. Çünkü iyileştirme ilhamı buradan gelir.
Bu üç işlevi üç gruba ve üç yönetim katmanına bölebilirsiniz, ama sonuç genellikle vasat olur ve insanlar mutsuzlaşır. Özellikle bakım ekibine sıkışıp kalanlar takdir görmez, ama kritik işi onlar yapar.
Ekibin üç işlevin tamamından sorumlu olmasını da sağlayabilirsiniz, fakat çoğu zaman bu işlevlerden özellikle birine aşırı uyumlu yöneticiler seçilir. Tesadüfe bakın ki o bir işlev, bir sonraki çeyrekte daha iyi ödüllere götüren işlevdir.
Tek bir kültür içinde operasyonel mükemmelliği, özenli bakımı ve derinlemesine düşünmeye ayrılan zamanı aynı anda savunmak zordur. Zor olması doğaldır.
İş zekâsı/analist rolüne bakınca, sektör SQL kullanan kişiyi Tableau gibi araçlar kullanan kişiyle değiştirmeye çalışıyor
Mantık şu: “Herhangi bir veri deposuna bağlanırsan teknik olmayan çalışanlar sürükle-bırakla yapabilir”
Burada birkaç sorun var. Birincisi, çıktının yalnızca doğrusal arttığını, dolayısıyla daha fazla düşük ücretli çalışan işe almak gerektiğini unutuyorlar. Her şey UI tabanlı iş olduğu için birinin elle kolu çevirmesi gerekiyor
İkincisi, çok karmaşık ve düzenlenmemiş iş mantığı dönüşüm kodu hâlâ ortaya çıkıyor; sadece artık UI’ın içine gömülü. O mantığın ne olduğunu bilenler de yalnızca PM ya da iş ekipleri oluyor
Mühendislik organizasyonu, iş sorularını yanıtlamak için oldukça ilkel ama yüksek kaliteli ve test edilmiş veri kümeleri sağlıyor. Zor kısım, kaynak veriden tuhaf yollarla iş çıktıları elde etme problemini çözmekti
Şimdi bu çözüm Tableau çalışma kitaplarında saklanıyor ve başka bir girdide kullanılamıyor. Yeni bir Tableau çalışma kitabına UI üzerinden kopyalayıp yapıştırmak gerekiyor
Tableau bulut hizmeti satın alındığına göre BI ekibi SQL çıkarımlarını daha sıkı hâle getirip sürdürebilir. Tableau, Databricks’in işinin bir kısmını almaya çalışıyor gibi görünüyor; ama artık bu işi mühendislik dışı ekip yapıyor. İyi sonuçlanır mı bilmiyorum
Örneğin “Kullanıcılarımız hangi ülkeden?” gibi tipik bir soru var. Kayıt formuna yazdıkları ülkeden mi bahsediyoruz, şu anda hizmete bağlandıkları ülkeden mi, ödeme yönteminin ülkesinden mi, doğdukları ülkeden mi, vatandaşlık ülkesinden mi, şu an yaşadıkları ülkeden mi, teslimat adresinden mi, fatura adresinden mi? Bunların hepsi farklı
Veri kümesi yeterince büyükse her biri farklı yanıt verir. “Küresel fintech” alanında bu tür tuhaf durumlar normal hâle gelir
Tipik düşük ücretli Tableau kullanıcısı, görünen ülke kodunu bulup count çalıştıracak ve bunu gerçek ilan edecek gibi görünüyor
Biraz daha akıllı Tableau kullanıcısı ise bir mühendisten SQL yazmasını isteyecektir
Veri kümesini ve kaynak sistemleri bilen biri olmalı ki iş tarafına karşı soru sorabilsin, doğru soruyu ve bağlamı dayatabilsin
Tableau türü araçlar, her gün aynı SQL sorgusunu pgAdmin’e yapıştırıp CSV’yi e-postayla göndermek gibi “teknik işleri” ikame etmek için iyidir; ama UI odaklı düşük becerili çalışanın daha iyi düşünmesini sağlamaz
Maliyete karşı çıktının doğrusal ölçeklenmesi elektronik tablolarla modellenebilir ve müşteriye yansıtılabilir ya da faturalandırılabilir. İş katmanındaki herkes bu dinamiği rahat bulur
Buna karşılık, özel uzmanların az çabayla 1000 kat çıktı üretebildiği ama bunun bir gün mü yoksa bir hafta mı süreceğinden emin olunamayan durum herkesi belirsizliğe iter ve liderleri huzursuz eder. Herkesin rahat ettiği sıradanlığı istiyorsanız bunu satmak zordur
2 numara ise ironik biçimde daha fazla uzmana, sadece farklı türde uzmanlara ihtiyaç doğurur. Çünkü tüm o mantığın bakımının yapılması gerekir
Sonunda bir istihdam programı gibi işleyecek ve daha pahalı hâle gelecek; ama politik olarak etkili derebeyliklere oranlı değer dağıtacağı için başarılı olacaktır
Önce backend insanlarının işi bilmediğini söyleyip hepsini kovarsınız ve Tableau’yu yeni backend yaparsınız. Backend insanlarının iş gereksinimlerini içine çekip rafine ettiği gerçeği göz ardı edilir
Sonra iş tarafındaki insanlar kendi yarattıkları karmakarışık örümcek ağına dolanınca Tableau danışmanlarını çağırır; onlar da parayı emerken değerli hiçbir şey üretmez
Yapı mühendisliği tarafından geldim; yazılım bana diğer mühendislik dallarından çok şehir planlamasına daha yakın görünüyor
Fazla geniş bir alan. Zamanla backend, frontend, firmware, makine öğrenimi mühendisi, veri bilimci, güvenlik analisti, kernel geliştiricisi gibi belirli iş türlerini tarif eden çeşitli pozisyonların artması şaşırtıcı değil
Standartlar geliştikçe, bir noktada bu tür pozisyonlarda çalışmak için çok spesifik sertifikalar gerekebilir diye düşünüyorum. Başka bir biçime de dönüşebilir, ama kristalleşme etkisi açıkça görünüyor
Yazılımı bir fabrika olarak düşünmek de mümkün ve faydalı olabilir. Ama her şey bu benzetmeye uymaz. Örneğin ürün entegrasyonunu düşündüğünüzde ya da söz konusu şey bir uygulama değil de hizmet olduğunda böyledir
Fabrika, bir şeyin üretildiği anlamını ima eder; oysa çoğu durumda yazılım nihai sonuç değil, bizzat mümkün kılan araçtır
Yazılımda işlerin çoğu asimptotik olarak otomatikleştirildi. Bu yüzden o işin bir zamanlar emek olduğunu unutuyoruz
Basit dosya kopyalamayı düşünmek yeterli. Bir anlamda “otomatik kâtip”
Kopyalama öyle otomatikleşti ki sistemlerimizin gerçekleştirdiği muazzam miktardaki kopyalama görünmez hâle geldi; ekonomik farklılaşma noktası olarak da ortadan kayboldu
Üstelik meta düzeyde de faydalı. Kopyalama programının kendisi de aynı algoritmayla kolayca kopyalanır
Mesele şu: Yazılım yazmak, matematik gibi, zamanını her zaman bilinen ile bilinmeyen arasındaki sınırda geçirir. Çünkü tamamen bilinen ve karakterize edilmiş her alan, herkes için problemi çözen ama aynı zamanda o faaliyetin ekonomik zeminini yakıp kül eden bir şekilde otomatikleştirilir
Yazılım işinin herhangi bir alanında her zaman bilinmeyene girip servet arama anlamında bir keşif, yani araştırma unsuru vardır. O yeni alan ister görkemli olsun ister trajik biçimde sıradan, fark etmez
Yazılım uzmanlığı olmayan bir yöneticinin otomatik olarak yapılabileceğini düşündüğü alan, meyveleri kolayca toplanacak şekilde evcilleştirilmiş bir meyve ağacı gibidir. Ama o ağaçta artık meyve yoktur
O yöneticinin problem tanımı yeniden can sıkıcı yaratıcılık ve uzmanlık gerektiren, otomatikleştirilmesi zor bir alana yükselmiyorsa artık farklılaştırıcı ya da değerli bir iş yapmıyor demektir