Yazılımcı mı Ürün Geliştirici mi? Ashby'nin Farklı Vizyonu

Selamlar, ben Alper. Bugün sizlerle yazılım dünyasında son zamanlarda sıkça duymaya başladığımız ama içini doldurmakta bazen zorlandığımız bir konuyu konuşmak istiyorum. Konumuz; Y Combinator’ın 2019 kış döneminden (YC W19) mezun olan ve işe alım süreçlerini baştan aşağı değiştirmeyi hedefleyen Ashby. Ancak bugün Ashby’nin sunduğu üründen ziyade, onların mühendislik kültüründen ve neden "ürün kararı veren mühendisler" (Product Engineers) aradıklarından bahsedeceğiz.

Yazılım Mühendisi mi, Ürün Geliştirici mi?

Geleneksel yazılım geliştirme süreçlerinde genellikle keskin çizgiler vardır. Ürün yöneticileri (Product Managers) kullanıcıyı dinler, pazar analizini yapar ve neyin yapılacağına karar verir. Tasarımcılar bunu görselleştirir. Biz yazılımcılar ise önümüze gelen o meşhur Jira kartlarını alıp, en temiz kodu yazarak işi teslim ederiz. Ancak Ashby bu yapıyı biraz sarsıyor. Onlara göre bir mühendis, sadece "nasıl" (how) sorusuna değil, aynı zamanda "neden" (why) ve "ne" (what) sorularına da yanıt aramalıdır.

Ashby’nin işe alım ilanlarında ve kültür dökümanlarında vurguladığı "Product Engineer" kavramı, aslında teknik beceriler ile ürün vizyonunun birleştiği noktayı temsil ediyor. Burada kastedilen şey, mühendisin sabah akşam toplantılara girmesi değil; yazdığı kodun kullanıcıda nasıl bir karşılık bulacağını, hangi problemi çözeceğini ve iş hedeflerine nasıl hizmet edeceğini sahiplenmesidir (ownership).

Neden Ürün Kararı Veren Mühendis?

Peki, bir şirket neden mühendislerinin ürün kararlarına karışmasını ister? Bunun birkaç temel sebebi var ve Ashby bu konuda oldukça şeffaf:

• Hız ve Çeviklik (Agility): Karar mekanizması ne kadar merkezileşirse, süreç o kadar yavaşlar. Mühendis, teknik kısıtları ve imkanları en iyi bilen kişidir. Ürün kararını verirken teknik borç (technical debt) ile kullanıcı deneyimi arasındaki dengeyi anlık olarak kurabilir.
• Kullanıcı Empatisi (User Empathy): Sadece kendisine verilen görevi yapan bir yazılımcı, bazen kullanıcıyı unutabilir. Ancak ürün kararı veren bir mühendis, "Bu özellik gerçekten gerekli mi?" veya "Kullanıcı burada zorlanır mı?" diye sormaya başlar.
• Yaratıcılık ve İnovasyon: En iyi çözümler bazen teknik bir imkansızlığın etrafından dolanırken veya yeni bir teknolojinin sunduğu fırsatları fark ederken ortaya çıkar. Ürün vizyonuna sahip bir mühendis, kimsenin aklına gelmeyen bir özelliği teknik bir avantajla birleştirebilir.

Ashby’nin Beklentileri: Sadece Kod Yetmez

Ashby ekibi, işe alım süreçlerinde adayların sadece algoritma çözme yeteneğine bakmıyor. Onlar için adayın "ürün sezgisi" (product intuition) çok kritik. Bir mühendis olarak Ashby'de çalışıyorsanız, size sadece "şu butonu şuraya koy" denmiyor. Aksine, "Kullanıcılarımızın aday takip sisteminde (Applicant Tracking System - ATS) yaşadığı şu darboğazı nasıl çözebiliriz?" deniliyor.

Bu noktada devreye özerklik (autonomy) giriyor. Kendi kararını verebilen mühendis, prototipini hazırlar, kullanıcı verilerini analiz eder ve gerekirse tasarımda revizyon yapar. Bu, aslında yazılımcının bir "kod yazma makinesi" olmaktan çıkıp, gerçek bir çözüm mimarına dönüşmesi demektir.

Teknik Mükemmeliyet ve Ürün Odaklılık Dengesi

Tabii ki bu durum, teknik kaliteden ödün verileceği anlamına gelmiyor. Aksine, Ashby gibi yüksek ölçekli (high-scale) işler yapan şirketlerde, yanlış bir ürün kararı kadar kötü yazılmış bir kod da felakete yol açabilir. Önemli olan, mühendisin yazdığı her satır kodun iş değerini (business value) bilmesidir.

Örneğin, yeni bir özellik geliştirirken bu özelliğin sistemin genel performansına etkisini düşünmek teknik bir iştir. Ama bu özelliğin kullanıcıların işe alım süresini (time-to-hire) kısaltıp kısaltmayacağını düşünmek ürün odaklı bir yaklaşımdır. Ashby, bu iki yeteneği aynı potada eritebilen kişileri arıyor.

Kariyeriniz İçin Ne Anlama Geliyor?

Eğer siz de kendinizi sadece kod yazarken değil, "Bu özellik gerçekten işe yarar mı?" diye düşünürken buluyorsanız, Ashby’nin bu yaklaşımı aslında sektörün nereye evrildiğinin bir göstergesi. Artık sadece "full-stack" olmak yetmiyor; ürünün kalbinde yer alan, metriklere bakan ve kullanıcıyla bağ kuran mühendisler çok daha değerli hale geliyor.

Sonuç olarak Ashby (YC W19), mühendisliği sadece bir uygulama katmanı olarak değil, ürünün mutfağı olarak görüyor. Bu kültürde yetişen mühendisler, ileride kendi girişimlerini kurarken veya büyük projeleri yönetirken çok daha geniş bir perspektife sahip oluyorlar. Eğer siz de kariyerinizde bir sonraki adımı sadece daha karmaşık algoritmalar yazmak değil, daha anlamlı ürünler inşa etmek olarak görüyorsanız, Ashby’nin bu vizyonunu yakından takip etmenizi öneririm.

Bir sonraki yazıda görüşmek üzere, kodunuz temiz, ürününüz kullanıcı dostu olsun!