Yapmadan Önce Dikkate Alınması Gereken 3 Kısıt
(jordanlord.co.uk)- Ürün fikrinde önce kısıtlar belirlemek, keşif alanını daraltır ve sonucun aşırı karmaşık ya da kimliği belirsiz bir ürüne dönüşmesini engeller
- Tüm fikirler tek sayfalık bir one pager içinde özetlenmelidir; buna sığmıyorsa araştırma, planlama ve prototipleme açısından daha yapılacak iş var demektir
- Üründen bağımsız olarak ayakta kalabilecek bir core tech de birlikte inşa edilmelidir; yön değişse bile birikmeye devam eden kümülatif bir varlık olarak kalmalıdır
- Kullanıcıya sürekli görünen tek bir defining constraint, ürünün merkezinde yer almalıdır; bu kısıt, ürünün hissini ve kimliğini doğal biçimde tanımlar
- Üç ölçütten biri bile karşılanmıyorsa, onu yapmama yaklaşımı kapsam kontrolü ve uzun vadeli kaldıraç elde etmek için önemlidir
Yapmadan Önce Konan Üç Kısıt
- Ürün yapmadan önce kısıtlar koymak, keşif alanını daraltır ve ortaya karmaşık ya da kimliği belirsiz bir ürün çıkmasını engeller
- 10 yıl boyunca farklı ürünler geliştirirken, aşırı karmaşık veya kimliği belirsiz ürünlerin başarısızlığa yol açtığı görüldü; bu deneme-yanılmaların sonunda yaklaşım üç ölçüte indirgendi
-
Bir sayfayı aşıyorsa yapılmaz
- Her fikir bir one pager ile özetlenmelidir ve bu belge bir north star işlevi görür
- one pager taviz verilemez, doğru, iddialı ama gereksiz ayrıntılardan arınmış olmalıdır
- Yatırımcılar, katkı sunanlar, ekip arkadaşları, arkadaşlar ve aile dahil farklı kitlelerle iletişimde aynı belge kullanılabilir
- İş birliği sırasında anlaşmazlık çıkarsa, one pager'da olmayan şey için kavga etmeye değmez; gerçekten önemliyse belge güncellenip eklenmelidir
- Bir sayfayı dolduramıyorsanız, metni zorlayarak uzatmak gerekmez; bu, henüz yapmaya hazır olunmadığı anlamına gelir
- Bu durumda önce araştırma, planlama ve prototipleme yapılıp ardından one pager yeniden yazılmalıdır
- Bir sayfayı aşacak kadar uzunsa fazla karmaşıktır; bu yüzden yapılmaz
-
Temel teknoloji üründen ayrılabilmelidir
- Ürünün kendisinden ayrı olarak, onu taşıyan bir core tech oluşturulmalıdır
- core tech bir metodoloji, teknoloji, araç ya da ayrı bir ürün olabilir; mevcut ürün ortadan kalksa bile yaşamaya devam etmelidir
- Bu ayrım, sizi tek bir ürüne hapsolmaktan kurtarır ve yön değişse bile birikimin sürmesini sağlar
- Ürünlerin yönü sık değişir ama core tech kalıcı ve kümülatif bir varlık olarak kalır
- Uzun vadede bu tür birikimli çaba doğrusal olmayan kazançlar üretebilir
- Örnek olarak Linus Torvalds'ın git'i, HashiCorp'un HCL'si ve Google'ın Kubernetes'i verilir
- Bunun için mutlaka büyük şirket düzeyinde kaynak gerekmez; kod tabanından ayrıştırılmış bir kütüphane veya sürekli geliştirilen bir metodoloji de olabilir
- core tech, ürün yönünden bağımsız olmalı; ancak kişinin ya da şirketin uzun vadeli vizyonuyla uyumlu kalmalıdır
- Bir fikir core tech üretmeyi mümkün kılmıyorsa, yeterli kaldıraç sağlamıyordur
-
Tek bir belirleyici kısıt ürünü tanımlamalıdır
- Ürünün merkezinde, kullanıcının her zaman gördüğü bir defining constraint bulunmalıdır
- Bu kısıt, kullanıcının sürekli karşılaşıp etkileşime girdiği bir unsur olmalı ve ürünün kimliğini oluşturmalıdır
- İyi bir kısıt, ürünün feel'ini yaratır ve tüm kullanıcı deneyimine nüfuz eder
- Minecraft'ın yalnızca bloklardan oluşması ya da IKEA'nın flat-pack kendi kendine montajlı mobilya anlayışı gibi, kimlik doğrudan kısıttan görünür hale gelir
- Bu tür kısıtlar karar alanını daraltarak kapsamı sınırlar ve gerçekten önemli sorunlara odaklanmayı sağlar
- Kısıt seçilmezse ya da yanlış seçilirse, ürün her şeyi yapmaya çalışan şişkin bir yapıya dönüşür
- İyi tasarlanmış bir kısıt varsa, ürün tasarımı bu kısıttan doğal olarak türemeye başlar
- Bu kısıt da one pager'ın en görünür kısmında yer almalıdır
Son ölçüt
- Üç kısıttan biri bile karşılanmıyorsa, yapılmaz
1 yorum
Hacker News görüşleri
Ben buna product primitives diyordum
Notion'un blocks'ları, Telegram'ın messages/conversations yapısı, Figma'nın frames/layers'ı, Twitter'ın tweets'i, Excel'in cells/sheets'i, Photoshop'un tools/layers'ı, CLI'ın commands'ları gibi şeyler
İyi ürün tasarımının, bu primitive'lerin sayısı çok az olduğunda ortaya çıktığını düşünüyorum
Kötü ürünler ya kendi primitive'lerinin ne olduğunu bilmez ya da o kadar çok primitive'e sahiptir ki ürün içindeki her unsur birbirinden kopukmuş gibi durur
O zaman kullanıcı, birbirinden farklı bir sürü üst düzey kavram öğrenmek zorunda kalır; bu da kafa karıştırır, göz korkutur ve öğretmeyi zorlaştırır
İdeal durumda bir, iki ya da üç temel primitive yeterlidir
Uygulamanın karmaşıklığı ve gücü, birleştirilebilir ve derin primitive'ler seçmekten gelir
Notion block'u, Excel cell'i, CLI command'i, Minecraft block'u gibi küçük birimlerle çok şey yapılabilmelidir
Bu, Alexandrian Pattern Language'e benziyor gibi görünse de aslında pattern'den çok, Alexander'ın daha sonra sözünü ettiği Centers kavramına daha yakın gibi
Benim anladığım kadarıyla yazılım sektörü onun pattern'lerini büyük ölçüde benimsedi, ama Alexander hayatının sonlarında sistemin nihai yapı taşını Center olarak görüyordu
Aydınlık bir avlu, pencere kenarı bir oturma yeri, şömine gibi; yerel fayda ve bütünlüğün odak noktası olan şeyler
Güçlü bir center doğal olarak birleştirilebilir olur, yerel gerilimleri çözer, daha küçük center'lardan oluşur ve daha büyük center'lar oluşturan bir yapı taşı görevi görür
Bir ürünün kafa karıştırıcı ve şişkin hale gelmesi çoğu zaman kötü niyetten kaynaklanmaz
Kullanıcı ihtiyaçları deneysel olarak görece bulunabilir, ama o ihtiyaçları zarif biçimde içine alacak gerçek merkez yapıyı bulmak çok incelikli olduğu için zordur
Bu yüzden gözümüzün önündeki her ihtiyaç için benzersiz ve katı bir arayüz eklemek her zaman en kolay yol olur
Bu tür ihtiyaçları doğal biçimde içine alacak temel primitive'i bulmak için derin bir mimari çalışma gerekir
O yüzden belki de sonunda sürekli faster horses yapıp duruyoruzdur
Eskiden buna concept count diyordum
Bir ürünü oluşturan temel kavramların sayısını genelde mümkün olduğunca azaltmak iyidir; buna ürünün nouns and verbs'ü de denirdi
Bu felsefe biraz aşırı basitleştirilmiş görünüyor
Tana'da primitive'ler fiilen yalnızca bullets ve supertags'ten ibaret olsa da, çok basit bir işi bile yapmak için saatler süren eğitim videoları izlemeyi gerektirecek kadar kullanımı karmaşık
Buna karşılık Google Maps'te primitive sayısı epey fazla olsa da, kullanım senaryolarının %90'ında UX oldukça sağlam duruyor
Programlama dillerine bakarken de benzer bir ölçüt kullanıyordum
Dil büyük olsa bile kavramsal olarak küçükse, öğrendikten sonra geri kalan şeyler deneyim biriktikçe yerine oturuyordu; kavramsal olarak büyük dillerde ise giriş eşiği yüksekti
Bunu en güçlü hissettiğim örnek perl olmuştu
Küçük olmalı ama fazla da küçük olmamalı
Örneğin shell script'ler (POSIX shell, bash), scripting'i bile command olarak modelleyip yeni kavramlar getirmemeye çalıştı; sonuç da herkesin bildiği gibi sıcak, yavaş ve karmakarışık bir karışım oldu
Üç kısıtı da beğeniyorum ama 1 sayfalık dokümanın proje karmaşıklığına göre değişmesi gerektiğini düşünüyorum
Küçük ve orta ölçekli projelerde bir sayfa yeterli olabilir, ama Mars uçuş kontrol yazılımı için implementasyona başlamadan önce pek çok alt spesifikasyona hyperlink veren bir one-pager gerekebilir
Teknoloji ile ürünü ayırmak gerçekten akıllıca
Örneğin Skype'ta arka planda P2P iletişim teknolojisi ve ön tarafta çağrı uygulaması vardı; zeki kurucular bu ikisini ayrı şirketlere koymuştu
Bu sayede ön uç uygulaması olan Skype Microsoft'a satıldıktan sonra bile, çekirdek IP ile P2P backend teknolojisini elinde tutan şirket ayrı olarak varlığını sürdürebildi
Tek bir kısıtı merkeze almak da mantıklı, ama bence bazen birden fazla kısıt ya da öncelikli bir liste bulundurmak daha iyi olabilir
En üstteki ilke ticarileştirmesi zor bir şeyse, onu değişmez bir dogma gibi ele aldığınız anda şirket iflasa doğru sürüklenebilir
Ekip içinde, satılması çok daha kolay bir yöne büyük bir pivot yapma fikri varsa, ilk halinden epey farklı olsa bile çıkış yolu açılabilir
Twitter da başlangıçta başka bir şey yapmaya çalışırken public status update fikrini yan projeden çıkardı
Bu yazı, yıllar önce araştırma danışmanımla birlikte iş kurarken izlediğimiz yöntemi gerçekten çok iyi özetlemiş
Biz önce son iki şeyi, yani çekirdek teknoloji ile kısıtları belirledik
Çekirdek teknoloji, sparse data için rastgele bir hierarchical Bayesian graph model'ini mümkün kılan bir sampler'dı; kısıt ise bunun CPU-bound olarak hesaplanabilir olmasıydı
En uzun süren şey, nihai ürünün alttaki teknolojiden ayrılması gerektiğini fark etmek oldu
Başlamadan önce birçok kişiden benzer tavsiyeler duymuştum ama bazı dersler ancak bizzat yaşanınca kalıcı oluyor
one-pager fikri gerçekten çok iyi
Kısıtları bir sayfalık bir metne bile net biçimde yazmaya zaman ayıramıyorsanız, sonunda ilerlerken telaş içinde o kısıtları sonradan keşfedersiniz
Ve bu bir bug değil, doğrudan yanlış şeyi inşa ediyor olmamız düzeyinde bir kusur olur
Bunu verilerle kanıtlayamam ama benim deneyimime göre herkesi kavramsal olarak aynı sayfada tutan projeler çok daha sık başarılı oldu
Ne yaptığımızı ve ne yapmadığımızı açıkça belirten tek sayfalık üst düzey bir belge bile büyük fark yaratıyor
Buna karşılık doğaçlama biçimde itilen projelerde, düşüncesini baştan net söylemeyen insanlar bile sonunda hayal kırıklığına uğruyor
Yazarın kısıtların gerçekten nasıl çalıştığına dair eksiksiz bir örnek göstermesini isterdim
Özellikle üçüncü maddenin pratikte nasıl göründüğünü pek gözümde canlandıramadım
Sonunda insanın kendisinin bir şey bulması gerekiyor gibi
Linux'taki everything's a file fikrini iyi buluyorum
Böyle güçlü tek bir kavramla bile epey yol alınabiliyor
Kısıtlar yeterince değer görmüyor
En zarif çözümler genelde sonsuz özgürlükten değil, açık kısıtlar altında tasarlamaktan çıkıyor
Ve bu, 1. maddeyle de bağlantılı
one-pager yazma sürecinin kendisi bu kısıtları tanımlamaya yardımcı oluyor
Google'ın Kubernetes'e sahip olmasının en büyük sebebi, her şeyden önce rakipleri etkisizleştirmek gibi görünüyor
solo SaaS için benim ekleyeceğim kısıt, bu hafta bir beta kullanıcısı bulabilir miyim olurdu
Zaman, kapsam ve teknoloji one-pager üzerinde kusursuz görünse bile kimse gelmiyorsa proje zaten ölüdür
Bu yüzden en baştan dağıtım/edinim kısıtı koyunca, özelliklere derinlemesine girmeden önce talebi doğrulamaya yöneldim
Çekirdek teknoloji ürünün kendisinden ayrılabilir olmalı sözü, acaba çok erken soyutlama yapmaya ve design pattern'leri fazla kullanmaya mı iter diye düşünüyorum
Elbette ilgi alanlarını ayırmak, business domain layer'ını persistence/network/UI gibi şeylerden temiz biçimde ayırmak doğru
Yine de domain layer sonuçta ürünle çok güçlü biçimde bağlı olmak zorunda
Bunun önüne geçmenin bir yolu olduğunu sanmıyorum
Sanırım burada kastedilen, alıcıyı cezbeden bir dış yüz olduğu ve içeride sistemi gerçekten çalıştıran şeyin alıcının asıl ilgilendiği konu olmadığı olabilir
İki katman arasında arayüz oluşturan birkaç kavram olabilir, ama içerinin nasıl evrileceği dıştaki ürün katmanından ayrılabilmeli denmek isteniyor gibi
Şu sıralar mutfak tadilatı tasarlıyorum ve bu üç kısıtın, yazılımdan daha genel tasarım işleri için de oldukça faydalı olabileceğini düşündüm
Bunu ben de hemen denemek istiyorum
Biraz fazla basit olabilir ama mekân ve akış açısından bakınca daha ilginç hale geliyor
İnsan akışı, ışık akışı, yiyecek akışı, geçişler gibi şeyleri düşünmek mümkün; bu da oldukça eğlenceli