Beni üründe şekillendiren iki kitabım var: Marty Cagan’ın Inspired’ı ve Joca Torres’in Gestão de Produtos’u, ki Joca’nın kendisinden mentorluk alma şansını da yakaladım. Yıllarca bu ikisi benim haritam oldu: PM nedir, ürün tasarımcısı nedir, mühendis nedir, kim ne yapar. Her rolün net bir sınırı vardı.
Geçen yıl boyunca, ekibimin Prolog’da yapay zekayla çalışmasını izlerken, bu sınırların kaymaya başladığını hissettim. Kitaplar yanlış çıktığından değil: her rolün gerçekleştiği katman yükseldi.
Serinin ilk yazısında beni Prolog’da tech’i yeniden kurmaya iten rahatsızlığı anlatmıştım, ikincisinde ise harness’ın ne olduğunu, yani yapay zekanın gerçekten iş görmesini sağlayan altyapıyı. İlkinin sonunda belirli bir parçayı açmaya söz vermiştim: yapay zeka inşa eden taraf olduğunda her pozisyonun işi nasıl değişiyor. Konu bu.
İş yok olmuyor, bir katman yukarı çıkıyor
Yapay zeka her mesleğin rolünü silmiyor, o rolün gerçekleştiği katmanı değiştiriyor.
Kolay okuma, yani korku satan okuma, “yapay zeka X pozisyonunun yerini alacak” oluyor, ve gördüğüm bu olmadı. Gördüğüm şey işin içeriğinin yer değiştirmesiydi: eskiden yapmak olan şey, yapanı yönetmek ve eleştirmek haline geldi.
Kodu yazan mühendis artık agent’ın yazdığını gözden geçiriyor. Spec yazan PM artık ondan çıkan prototipi saatler içinde değerlendiriyor. Kişi aynı, elindeki alet değişti.
Bunu kafamda tutarak Cagan’a ve Joca’ya geri döndüğümde jeton başka türlü düştü. İkisi de her rolün icrasını özenle anlatıyor (somut görev, teslim edilen çıktı, günün sonunda ellerinizden çıkan şey), ve yapay zekanın devraldığı tam olarak bu. İnsana kalan şey diğer yarısı: neyin inşa edilmeye değer olduğuna karar vermek, inşa edilenin içindeki deliği bulmak, neyin iyi olduğunu bilecek taste’e sahip olmak. Muhakeme, icra değil.
O yüzden kendime yaptığımı yapacağım: her rolün tanımını kitaplardan alıp, yapay zeka bundan neyi yiyor ve geriye ne kalıyor (ve daha pahalı hale geliyor) diye soracağım.
Kitaplara göre üçlü ekip
Rol rol ayırmadan önce, kitapların ekibi nasıl kurduğunu hatırlamakta fayda var. Joca dobra: başarılı bir ürünün arzu edilir, uygulanabilir ve inşa edilebilir olması gerekir, ve bu da “başarılı bir ürün yaratmak için gereken üç temel işlevi” tanımlar (böl. 2): UX tasarımcısı, ürün yönetimi ve geliştirici, onun core team dediği üçlü. Cagan, Inspired’da açılış bölümünde aynı rolleri anlatıyor, “Key Roles and Responsibilities”.
İkisi de sona sakladığım bir noktada ısrar ediyor: bu bir patron ve ast ilişkisi değil. Joca’nın sözleriyle, “ürün mühendisliği, ürün yönetimi ve UX bir ekiptir, bu grupların hiçbiri arasında astlık ilişkisi yoktur” (böl. 31), Cagan’da ise aynı fikir PM ve mühendisliğin “eşitler olması, hiçbir konumun diğerine bağlı olmaması” şeklinde çıkıyor (böl. 5, benim çevirimle). Ve yapay zeka üçlünün ortasına girdiğinde, biçim olarak en çok değişen bu ortaklık oluyor.
Tablo: teknolojideki her meslek bir katman yukarı çıkar. Mühendislik kod üreticisinden agent eleştirmenine, ürün spec yazarından iterasyon mimarına, tasarım ekran üreticisinden deney orkestra şefine, kalite test edenden doğrulama kurucusuna.
Teknolojide her mesleğin rolü
Aynı rol, bir katman yukarıda
icra agent'a geçer · muhakeme sizde kalır: karar vermek, eleştirmek, taste sahibi olmak
Mühendis: kod üreticisinden agent eleştirmenine
Mühendislik için önemli olan şey artık ne kadar kod ürettiğiniz olmaktan çıktı: agent’ın ürettiğini ne kadar iyi eleştirdiğiniz oldu.
Joca’nın tanımı şu an gözden geçirmesi acıtacak kadar net: “ürün mühendisliği, ürünü geliştirmekten ve çalışır tutmaktan sorumludur”, ve daha ileride mühendislik “ürünü inşa eder” (böl. 31). İnşa etmek fiildi. Cagan öbür taraftan tamamlıyor, ürünle olan ilişkiyi anlatarak: “product manager çözümü tanımlamaktan sorumludur, ama neyin mümkün olduğunu en iyi mühendislik ekibi bilir, ve sonunda bu çözümü teslim eden de odur” (böl. 5, benim çevirimle). Bir tarafta tanımlamak, öbür tarafta teslim etmek.
Şimdi ilk sürümün teslimi agent’ın işi. Değişmeyen ve daha pahalı hale gelen şey, Cagan’ın mühendise inovasyon kaynağı olarak yapıştırdığı her şey: “mühendisler neyin mümkün olduğunu herkesten iyi bilir” (böl. 5). Neyin mümkün olduğunu bilmek, agent’ın önerdiği plandaki deliği bulmak, onun göremediği performans ya da güvenlik trade-off’unu görmek, ne zaman müdahale edip ne zaman bırakacağına karar vermek. Bunlar her ay daha çok ağırlık kazanıyor. Sözdizimini ezberden bilmek, boilerplate’i elle yazmak, Stack Overflow taramak, kişisel kupa olarak kod hacmi: bunlar daha az ağırlık taşıyor.
Prolog’da bunu ekibe açık açık söyledim: kimse kod satırıyla değerlendirilmeyecek. “Delik bulmakta” hep iyi olan daha değerli hale geliyor, “hızlı çok kod üretmekle” özdeşleşen ise nereye yatırım yaptığını yeniden ayarlamak zorunda kalacak. Ve bu mühendisliği küçültmüyor. Değeri hep hızlı üretmekten çok neyin sağlam olduğunu bilmekteydi, ve şimdi bu sadece açık hale geliyor.
PM: spec yazarından iterasyon mimarına
PM bunu prototip ucuzladığında hissediyor: işi belge yazmak olmaktan çıkıp, hangi fikrin ekibin zamanına değdiğini seçmek haline geliyor.
Cagan işin kalbi konusunda kesin: “birinin çözümün, ürünün ne olduğunu keşfetmesi gerekir, özellikleri, kullanıcı deneyimini ve lansman kriterlerini dahil ederek. O biri product manager’dır, ve bu görev onun işinin kalbidir” (böl. 1, benim çevirimle). Joca geniş sınırı çiziyor: ürün yönetimi “bir yazılım ürününün tüm yönlerinden, o ürünün tüm yaşam döngüsü boyunca, tasarımından yaşamının sonuna kadar sorumlu olan işlevdir” (böl. 2).
Dikkat et, ikisinde de anahtar sözcük keşfetmek, spec yazmak değil. Cagan’ın bütün bir bölümü işin discovery olduğunu, “gereksinim” olmadığını savunmaya ayrılmış: yazılımın iki aşaması vardır, “neyi inşa edeceğini keşfetmek (doğru ürün) ve inşa etmek (ürünü doğru şekilde). İlkine discovery hakimdir, ikincisi icradır” (böl. 12, benim çevirimle). Bu hep onun mesajıydı, ve yapay zeka bunu sadece harfi harfine gerçek kıldı.
Çünkü build haftalardan saatlere çöktüğünde, darboğaz inşa etmek olmaktan çıkıp neyi inşa etmeye değeceğine karar vermek oluyor. Komitede gözden geçirilen uzun spec, kapalı üç aylık planlama, teslim edilecek çıktı olarak status report, mühendislik ile tasarım arasındaki trafik kontrolü: bunların hepsi daha az ağırlık taşıyor. Daha çok ağırlık taşıyan şey hızlı discovery (inşa etmek için spec değil, anlamak için prototip), hipotez küratörlüğü (hangi fikir ekibin zamanına değer) ve daha sık olarak neyi yapmayacağına karar vermek. Bazı şirketler bu PM’e şimdiden “Editör” ya da “Mimar” demeye başladı. Bu daha az PM değil: başka bir PM, küratörlük yapan, taste’le karar veren, yön veren. Eskisinde merkezî olan, spec yazmak, işte hafifleyen şey o oldu.
Ürün tasarımcısı: ekran üreticisinden deney orkestra şefine
Tasarımda iş birimi ekrandan çıkıp ekran üreten sisteme geçiyor, ve ürün tasarımcısı hangi varyasyonun hayatta kalacağını seçen kişi oluyor.
Joca’da UX’in tanımı, tasarlamak için anlamak: “UX, kullanıcıyı ve o kullanıcı için çözülmek istenen problemi derinlemesine anlamaktan sorumludur” (böl. 32). Ve anlattığı akış herkesin bildiği ritüel: kağıt prototip, sonra wireframe, sonra “görsel UX tasarımcısı bu ekranlara renk ve biçim koymaya başlar”. Cagan rolü aynı mantıkla ikiye kesiyor: interaction designer “kullanıcılara dair derin bir anlayış geliştirir ve görevleri, navigasyonu ve akışı yaratır”, bunu wireframe’lere döker ve visual designer’a devreder, o da “wireframe’e et giydirir” (böl. 4, benim çevirimle).
Bu zincir, yani anlamak, taslak çıkarmak, ekran ekran rafine etmek, tam olarak yapay zekanın kısalttığı şey. İş birimi “ekran” olmaktan çıkıp “ekran üreten sistem” oluyor. Aynı varyasyonu Figma’da beş kez baştan yapmak, bileşen bileşen spec çıkarmak, ritüel olarak pixel-perfect handoff: daha az ağırlık taşıyor. İterasyon hızında prototip yapmak (paralelde birçok seçenek, kötüleri at), her bir ayrı ekran yerine görsel sistemi tanımlamak, ve hızlı görsel eleştiri (yapay zekanın bir şey önerdiğini görüp, kullanıcı fark etmeden önce yanlış olduğunu gözle yakalamak): daha çok ağırlık taşıyor.
Ve burada Cagan, ta 2008’de, ürün tasarımcısını düğmeye basan biri olduğunu sanmaktan koruyan bir şey söylüyor: onun işi asla sadece güzel çizmek olmadı. “İyi bir ürün iyi bir kullanıcı deneyimi ister. Ve iyi bir deneyim, ürün ile tasarım arasında yakın iş birliği ister” (böl. 4, benim çevirimle). Yapay zeka varyasyonu üretiyor, ve hangisinin kullanıcıya ulaşmaya değer olduğuna karar veren hâlâ taste’i olan insan.
QA: test edenden doğrulama kurucusuna
QA en ilginç durum, çünkü kitapların neredeyse hiç izole etmediği rol, ve yapay zekanın en çok kımıldattığı rol.
Dikkat et: Joca’nın üçlüsünde (tasarımcı, PM, geliştirici) ve Cagan’ın rollerinde kalite dağınık halde çıkıyor, ekibin sorumluluğu olarak, kendi yöntemi olan ayrı bir koltuk olarak değil. Uzun süre bu mantıklıydı, ama artık değil, ve nedeni basit: agent hızlı inşa eder ve doğrulama elle kalırsa, sadece yüksek hızda teknik borç ürettin.
O yüzden QA, test senaryosunu elle çalıştıran kişi olmaktan çıkıp testing harness’ı, yani sistemi test eden sistemi tasarlayan kişi oluyor: başka bir yapay zekanın yazdığı kod için test yazacak yapay zekayı ayarlamak, regresyonu kullanıcıdan önce yakalamak, kusurun nerede çıkma eğiliminde olduğunu düşünmek. Pratikte, benimsediğimiz operasyonel bir soruya dönüştü: kaçan her bug “bunu bir dahaki sefere otomatik olarak nasıl yakalarız?” haline geliyor. Bilinen bir akışın kapsamlı elle testi, her sürümde elle çalıştırılan regresyon, yayına almadan önce tek kapı olarak QA: daha az ağırlık taşıyor. Sistem olarak doğrulama, bant sonunda pas atmak olarak değil.
En çok katman yükselten rol tam da en az tanımlı olduğu için bu. Kitapların bir sınır oymadığı yerde, yapay zeka yeni bir tane çiziyor.
Sabit olan: kitapların zaten en önemli dediği şey
Değişmeyen bir şey var, ve ikisinin de kitaplarında göz önünde saklıydı: en önemli özellik olarak koydukları şey, tam da yapay zekanın yapmadığı şey.
Joca, iyi bir PM’in özelliklerini anlatan bölümü lafı dolandırmadan açıyor: “hepsinin en önemlisi, hiç şüphesiz, empatidir” (böl. 4). Bir işlev tablosu ya da teslim edilecek çıktı değil: kullananın yerine kendini koyabilme yeteneği. Cagan ise bütün kitabı discovery’yi, taste’i ve muhakemeyi sürecin üstünde tutmaya harcıyor, ve ikisi de, her biri kendi tarzıyla, aynı şeyi söylüyordu: iyiyi ortalamadan ayıran şey asla işin mekanik kısmı olmadı.
Ve mekanik kısım tam da agent’a giden kısım. Spec yazmak, ekranı çizmek, kodu yazmak, testi çalıştırmak. Kalan ve daha pahalı hale gelen şey eleştirel düşünme, taste (neyin iyi olduğunu bilmek), belirsizlik altında muhakeme, merak, yaptığın şeyi kullanana özen. Ekibe kullandığım cümleyle özetlersem: işin içeriği değişir, işi yapan kişi değişmez.
İki katmanlı diyagram. Üstte, bizde kalan ve daha pahalı olan: taste (neyin iyi olduğunu bilmek), belirsizlik altında muhakeme, kullananla empati, neyi yapmayacağına karar vermek, kitapların zaten en önemli dediği şey. İş bir katman yukarı çıktı. Altta, agent'a giden: spec yazmak, ekran çizmek, kod yazmak, elle test çalıştırmak.
Bizde kaldı · ve daha pahalı oldu
kitapların zaten en önemli dediği şey
iş bir katman yukarı çıktı
Agent'a gitti
Bunun bedeli ne olacak (klişe olmadan)
Bunu fazla güzel kapatmak istemiyorum, çünkü öyle değil. Bu değişim somut şeyler istiyor, ve hiçbiri konforlu değil.
İlki, on yıllık alışkanlığı geride bırakmak. Beş, on yıldır eski usulde olan kişi, buraya gelmesine yardım etmiş kalıplar taşıyor, ve değişmeye direnen tam da o kalıplar oluyor. Kısa yolu yok, ve rahatsızlık beklenen bir şey.
Sonra, yapay zekayla yaratmak kadar onu eleştirmek: çıkan öneriyi kabul etmek iş değil; önerdiği plandaki deliği bulmak, o iş. Hep pahalı olan şey (eleştirel düşünme, taste, muhakeme) daha pahalı hale geliyor.
Bir de takım olarak hata yapmak var, kişi olarak değil. Production’daki bug yüzünden mühendisi kovmayız, review’ı iyileştiririz, ve yapay zeka hata yapınca güçlendirdiğimiz şey harness olur. Agent’ın bug’ı süreçtir, kişi değil: bir slogan değil, bir taahhüt.
Ve en rahatsız edeni: bazı işlevlerin diğerlerinden daha çok değiştiğini kabul etmek. Bu, şu ana kadar az değişen kişide huzursuzluk yaratıyor, ve her şey aynıymış gibi davranmak mümkün değil. Yapılabilecek şey bunu açık konuşmaya taşımak.
Ve varış noktasına gelmiş biri gibi görünmemek için: Prolog bunda hâlâ başlangıçta. Hâlâ AI-assisted’ız, yüzde 10 ila 20 kazançla, 5x ya da 10x’lik AI-first değil. İnşa ettiğimiz bir yönü anlatıyorum, isabetleriyle ve hatalarıyla, bir zafer değil.
Bundan ne çıkarıyorum
Kitaplar yanlış çıkmadı. Her rolün icrasını, ancak şimdi gerçekten anladığım bir kesinlikle anlatıyorlardı (spec yazmak, ekranı çizmek, ürünü inşa etmek, testi çalıştırmak), ve bu icra artık agent’ın. İnsana kalan ise öbür kısım, muhakeme etmek, eleştirmek, taste sahibi olmak, kullanana özen göstermek, ki Cagan’a ve Joca’ya dönersek, ilk sayfadan beri en önemli dedikleri şey buydu.
Belki de iyi kısmı bu: yapay zekanın elimizden aldığı iş en tekrarlı olandı, bıraktığı ise hep en zor, ve en ilginç olandı. Nasıl gittiğini anlatmaya devam edeceğim.
Kaynaklar
- Marty Cagan, Inspired: How to Create Products Customers Love (1. baskı, 2008). Rol tanımları 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) ve 12 (Product Discovery) bölümlerinden geliyor. Alıntıların çevirileri bana ait.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Tanımlar 2 (Yazılım ürün yönetimi nedir?), 4 (Bir ürün yöneticisinin başlıca özellikleri), 31 (Ürün mühendisliği ve ürün yönetimi) ve 32 (UX ve ürün yönetimi) bölümlerinden geliyor.
- Rolün bir katman yükseldiği okuması seriyi destekliyor: OpenAI, Harness Engineering, ve Peter Pang, CREAO CTO’su.