Teknik inceleme: ürün, teknoloji ve hangi büyüklükte kırılacağı

Teknik inceleme, kodu denetlemek değildir. Melek turunda kimse size depoyu açmaz, açsa da bir öğleden sonrada okunmaz. Cevabı aranan şey daha dar ve daha yararlıdır: ürün gerçekten çalışıyor mu, bugünkü tasarım hangi sayıda kırılır, ve şirketin çalışması için gereken bilgi kaç kişinin elinde duruyor.

Ürün çalışıyor mu, gösteri mi yapıyor

İlk kontrol, ürünü kurucunun elinden almaktır. Demoyu izlemek yerine hesabı açtırıp kendiniz kullanın; hazırlanmış veriyle değil, kendi verinizle. Bir minimum geçerli ürünün eksik olması sorun değil — hangi kısmının eksik olduğu bilinçli seçilmiş mi, o önemli.

Semantica’da fotoğraftaki kıyafetleri tanıyan bir araç yaptık. Görsel tanıma tamamen tarayıcı tarafında çalışıyordu ve bir kıyafeti 10 saniyenin altında etiketlemek mümkündü. Bu, gösterilebilir bir şeydi; ekranda saniyeler içinde oluyordu. Bir demonun ikna edici olması ile ürünün ayakta durması arasındaki farkı, demoyu kendi telefonunuzdaki kötü ışıklı fotoğrafla denediğinizde görürsünüz.

Ürün yol haritası da aynı gözle okunur. Sıradaki üç işin ne olduğunu ve neden o sırayla yapıldığını soruyorum. Her isteği yol haritasına ekleyen bir ekip, ürün-pazar uyumunu henüz bulamamış ve arayışı özellik üreterek sürdürüyor demektir. Teknolojinin kendisinin bir rekabet hendeği olduğu durum erken aşamada seyrektir; hendek çoğu zaman veriden, dağıtımdan ya da birikmiş müşteri ilişkisinden gelir.

Bugünkü tasarım hangi sayıda kırılır

En işe yarar teknik soru budur ve tek cümledir: “Bu sistem kaç kullanıcıda, kaç işlemde ya da kaç kayıtta kırılır?” İyi bir teknik ekip rakam verir. Cevabı olmayan ekip henüz düşünmemiştir; bu, kötü mühendis oldukları anlamına gelmez, ama ölçek sorununun bir gün karşılarına çıkacağını bilmedikleri anlamına gelir.

Udemy’de kurs feed’ini kişiselleştirmeyle, kullanıcı başına kalıcı toplulaştırma yaparak kurduğumda platformun 100 bin kullanıcısı vardı. Aynı sistem, Udemy 4 milyon kullanıcıya ulaştığında ciddi bir değişiklik görmeden çalışıyordu. Bildirim sistemi de öyleydi: tek bir kurstaki tek bir duyuru yüz binlerce arka plan işi tetikleyebiliyordu ve kullanıcı tabanı 40 kat büyüdükten sonra sistem yerinde duruyordu. Bunlar erken alınmış birkaç tasarım kararının sonucudur, sonradan yapılan bir kurtarma operasyonunun değil.

Bunun tersi de doğrudur: her sistemin bugünden dört milyon kullanıcıya hazırlanması gerekmez. Ölçeğe hazırlanmak zaman ve para harcar; bu ikisi de erken aşamada ürünün kendisinden çalınır. Aradığınız şey hazır bir altyapı değil, ekibin hangi tarafı bilerek seçtiği.

Teknoloji kararı geri alınabilir, ama bedeli var

LeanScale için JavaScript ile yazılmış 35.000 satırlık bir sistemi Rust’a çevirdim; sonuç 60 kat daha bellek verimli bir sistem oldu. Cursor’dan yardım alarak 40–50 dosyayı çevirdim, sonra üretilen kodu üç büyük parçaya bölüp ayıkladım ve birleştirdim. Toplam altı yedi hafta sürdü.

Bunu bir yatırımcının aklında tutacağı biçimde söyleyeyim: teknoloji seçimi ölümcül değildir, ama “ileride yeniden yazarız” cümlesinin bir fiyatı vardır ve o fiyat aylarla ölçülür. Sunumda bir yeniden yazma planı varsa, kaç haftalık olduğunu ve o haftalarda ürüne ne olacağını sorun. Yeniden yazma sırasında yeni özellik çıkmaz.

Bilgi kaç kişinin elinde

Kivi Video’da video sunucusunu, önbellekleme sistemini ve video kodlama sistemini tek başıma yazdım. En kalabalık anımızda sekiz kişiydik. Böyle bir şirkette sistemin tamamı tek bir kişinin kafasında durur; o kişi ayrılırsa şirket birkaç ay geriye gider. Bu, erken aşamada normaldir. Anormal olan, kurucunun bunu bir risk olarak görmemesidir.

Sorulacak şey basit: ürünün en kritik parçasını ikinci bir kişi anlatabiliyor mu, dağıtım tek kişiye mi bağlı, ve sistem bugün çökse geri getirecek yazılı bir yordam var mı.

İyi bir teknik cevap neye benzer

Udemy’de yorumları sıralarken kullandığım yöntem, Bernoulli parametresi için Wilson skoru güven aralığının alt sınırıydı. Sorduğum soru şuydu: elimdeki oylara bakınca, gerçek olumlu oy oranının en az ne olduğundan %95 eminim? İyi bir teknik cevap böyle görünür — hangi soruyu sorduğunu bilir, yöntemin neden seçildiğini söyler, belirsizliği rakamla sınırlar.

Görüşmede aradığım şey terim listesi değil, bu tarz bir cümle. Kullandıkları teknolojiyi neden seçtiklerini soruyorum; “popüler” cevabı ile “şu üç seçeneği denedik, ikincisi şu yüzden düştü” cevabı arasındaki fark, iki yıl sonra ortaya çıkacak farkın kendisidir.

Son olarak veri: verinin nerede durduğu, kimlerin eriştiği ve müşteri verisinin ürün geliştirmede nasıl kullanıldığı sorulur. Sağlık, finans ve kişisel veriyle çalışan bir üründe bu soruların cevabı yoksa, teknik risk değil hukuki risk almış olursunuz.