Yeni Bir Dijital Ürüne Başlarken Teknoloji Nasıl Seçilmeli?

Yeni bir ürüne başlarken teknoloji seçimi, gereğinden fazla enerji harcanan tartışmalardan biridir.

Bunun sebebi kararın önemsiz olması değil. Sebep, tüm kararların aynı ağırlıkta ele alınmasıdır: veri modeliyle bir arayüz kütüphanesi aynı toplantıda, aynı ciddiyetle konuşulur. Oysa biri yıllarca yaşayacak, diğeri bir hafta sonunda değiştirilebilir.

Daha işe yarar bir çerçeve, seçimleri geri alınabilirliklerine göre ayırmaktır. Karar maliyeti, kararın geri alınabilirliğiyle ters orantılı dağıtılmalıdır.

Geri alınması zor olanlar

Bazı kararlar zamanla sisteme yayılır ve sonradan çıkarmak neredeyse yeniden yazmak anlamına gelir. Enerjinin çoğu buraya harcanmalıdır.

Veri modeli. Verinin nasıl yapılandırıldığı, ürünün gelecekte ne yapabileceğini belirler. Yanlış modellenmiş bir ilişki, uygulama katmanında sonsuz sayıda geçici çözümle telafi edilmeye çalışılır. Veritabanı ürününü değiştirmek zordur; veri modelini değiştirmek daha zordur.

Barındırma ve çalışma modeli. Sistemin nerede ve nasıl çalıştığı — kendi sunucunuz, yönetilen bir platform veya sunucusuz bir yapı — dağıtımdan izlemeye kadar her şeyi etkiler. Bu karar teknik olduğu kadar operasyoneldir: kim, hangi saatte, hangi yetkiyle müdahale edecek?

Kimlik ve yetkilendirme. Kullanıcıların kim olduğu ve neye erişebildiği, ürünün her katmanına dokunur. Sonradan değiştirmek genellikle veri taşımayı da beraberinde getirir.

Bağımlılığın derinliği. Bir sağlayıcıyı kullanmak ile ürünün o sağlayıcının kavramları etrafında şekillenmesi farklı şeylerdir. İkincisi, çıkış maliyetini sessizce büyütür.

Bu dört başlıkta karar verirken sorulacak soru "hangisi daha modern" değil, "yanılırsak çıkış nasıl görünür" olmalıdır.

Geri alınması kolay olanlar

Buna karşılık bazı seçimler yereldir ve maliyeti sınırlıdır: arayüz bileşen kütüphanesi, stil yaklaşımı, test aracı, biçimlendirme kuralları, hatta çoğu durumda uygulama çatısının kendisi.

Bunlar önemsiz değildir; ancak yanlış çıktıklarında bedeli bir modül veya bir ekran düzeyinde kalır. Bu kategoride uzun tartışma yapmak, tasarrufun kendisinden pahalıya gelir.

Pratik kural sadedir: geri alınması kolay kararlarda hızlı seçim yapıp ilerlemek, doğru seçimi uzun süre aramaktan daha iyi sonuç verir.

Zor kararlarda ise tartışmayı uzatmak yerine küçük bir deneme yapmak genellikle daha hızlı sonuç verir. Birkaç günlük bir prototip — gerçek veri şeklinizle, en zor sorgunuzla veya en kritik entegrasyonunuzla — toplantıda haftalarca konuşulan soruların çoğunu kapatır. Amaç kod üretmek değil, varsayımı sınamaktır; prototip sonrasında atılabilir.

Ekip yetkinliği bir kısıt değil, girdi

Teknoloji tartışmalarında en sık göz ardı edilen değişken, o teknolojiyi kullanacak insanlardır.

Ekibin bildiği bir araç, kâğıt üzerinde daha zayıf olsa bile genellikle daha iyi sonuç verir. Bilinen araçta ekip yalnızca ürünü çözer; bilinmeyen araçta hem ürünü hem aracı aynı anda öğrenir ve ilk aylarda verilen kararların çoğu sonradan geri alınır.

Bu, hiç yeni bir şey öğrenilmemesi gerektiği anlamına gelmez. Anlamı şudur: yeni teknoloji öğrenmenin maliyeti proje planına yazılmalıdır. Yazılmadığında gecikme olarak görünür ve genellikle yanlış sebebe bağlanır.

İkinci soru işe alımdır. Bu araçla çalışacak insanları bulmak ne kadar kolay? Bu, küçük ekipler için birkaç yıl sonra ortaya çıkan ama o noktada çözmesi pahalı olan bir kısıttır.

Gereksinim, trendin önünde gelir

Bir teknolojinin popüler olması, sizin probleminize uygun olduğu anlamına gelmez. Ancak popülerlik tamamen anlamsız da değildir — daha çok kullanıcı, daha çok çözülmüş sorun, daha çok dokümantasyon demektir.

Doğru sıra, gereksinimi önce yazmaktır. Ürün gerçek zamanlı mı çalışacak, çok sayıda eşzamanlı yazma mı olacak, ağır raporlama mı gerekecek, çevrimdışı çalışması mı gerekiyor? Bu soruların cevabı seçenekleri hızla daraltır.

Gereksinim yazılmadığında tartışma zorunlu olarak zevke kayar, çünkü elde karşılaştırılacak bir ölçüt yoktur.

Ürünü çalıştırmak da bir seçim kriteri

Teknoloji değerlendirmeleri genellikle geliştirme deneyimi üzerinden yapılır: yazması ne kadar rahat, ekosistemi ne kadar zengin. Ürün yayına girdikten sonra ise günlerin çoğu yazmakla değil çalıştırmakla geçer.

Bu tarafta sorulacak sorular farklıdır. Yeni bir sürüm nasıl yayına alınıyor ve geri alınması ne kadar sürüyor? Bir şey bozulduğunda nereye bakılıyor — log, metrik ve hata takibi kutudan çıkıyor mu, yoksa ayrıca mı kuruluyor? Yedekler alınıyor mu ve geri yükleme hiç denendi mi?

Bu soruların cevabı, seçilen teknolojiden çok çalıştırma modeline bağlıdır. Yönetilen bir platform bu yükün büyük kısmını üstlenir ve karşılığında esneklikten bir miktar alır. Kendi altyapınızı işletmek tersini yapar: kontrol artar, sorumluluk da artar.

Küçük ekipler için belirleyici olan genellikle şudur: gece 03.00'te bir şey bozulduğunda müdahale edebilecek kaç kişi var? Cevap birse, operasyonel yükü azaltan her seçim teknik olarak daha zayıf görünse bile daha doğrudur.

Ölçek varsayımını yazmak

Ölçek konusunda iki yönlü hata yapılır ve ikisi de pahalıdır.

Birincisi, hiç gelmeyecek bir yük için baştan karmaşık bir mimari kurmaktır. Bu, ürünün ilk sürümünü geciktirir ve ekibin enerjisini gerçek olmayan bir problemin çözümüne harcatır.

İkincisi, bilinen bir kısıtı görmezden gelmektir. Ürünün belirli bir tarihte belirli bir hacimde çalışacağı biliniyorsa — bir kampanya, bir sezon, bir kurumsal müşteri devreye alması — bunu sonradan öğrenmek pahalıdır.

Ayrımı yapmanın yolu, ölçeği tahmin etmek yerine yazmaktır: ilk yıl hangi büyüklük bekleniyor, bu sayı nereden geliyor ve hangi eşikte mimari yeniden değerlendirilecek. Bu üç cümle, hem gereksiz karmaşıklığı hem de gereksiz sürprizi büyük ölçüde engeller.

Ekosistem ve süreklilik

Bir aracı seçerken yalnızca bugünkü yeteneklerine değil, arkasındaki sürekliliğe de bakmak gerekir.

Bakılabilecek işaretler sadedir: düzenli sürüm çıkıyor mu, güvenlik güncellemeleri zamanında geliyor mu, sorular cevaplanıyor mu, birden fazla kurum tarafından mı destekleniyor. Tek bir şirkete veya tek bir kişiye bağlı araçlar kötü değildir; yalnızca farklı bir risk taşırlar ve bu riskin bilinerek alınması gerekir.

Ticari ürünlerde aynı soru fiyatlandırma ve veri çıkışı üzerinden sorulur. Bu tarafı özel geliştirme ile hazır platform karşılaştırmasında ayrıca ele almıştık.

Kararı ve gerekçesini yazmak

Teknoloji seçiminin en çok atlanan adımı, kararın kendisi değil kaydıdır.

Bir yıl sonra ekipte kimse "bunu neden böyle seçmiştik" sorusunu cevaplayamadığında iki şey olur: ya karar dokunulmaz sayılır ve gereksiz yere korunur, ya da bağlamı bilinmediği için yanlış zamanda değiştirilir.

Kayıt uzun olmak zorunda değil. Hangi seçenekler değerlendirildi, hangi gereksinim belirleyici oldu, hangi ödünler kabul edildi ve bu kararın hangi koşulda yeniden gözden geçirilmesi gerekir — birkaç paragraf yeterlidir.

Bu alışkanlık ayrıca tartışmayı bitirir: aynı konu altı ay sonra tekrar açıldığında, konuşma sıfırdan değil kayıttan devam eder.

Kaydın en değerli kısmı da genellikle reddedilen seçeneklerdir; çünkü bir yıl sonra akla gelen "şunu neden kullanmadık" sorusunun cevabı orada durur.

Sonuç

Teknoloji seçimi nadiren tek bir doğru cevabı olan bir sınavdır. Çoğu ürün, birden fazla makul seçenekle başarıyla yapılabilir.

Ayrımı yaratan şey seçimin kendisi değil, seçimin nasıl yapıldığıdır: hangi kararın kalıcı olduğunu bilmek, geri alınabilir olanlarda hızlı ilerlemek ve gerekçeyi yazılı bırakmak.

Yazılım danışmanlığı çalışmalarımızda bu tartışmayı genellikle araç listesiyle değil, hangi kararların iki yıl sonra hâlâ yerinde olacağı sorusuyla açıyoruz.