Web Yazılım Nedir? İşletmeye Özel Sistemler

Web yazılım nedir, tanıtım sitesinden farkı nedir?

Web yazılım, tarayıcı üzerinden çalışan ve iş yapan bir sistemdir. Tanıtım sitesi bilgiyi gösterir; web yazılım ise veri alır, saklar, işler ve geri verir. Sipariş kaydeden bir panel, servis takibi yapan bir program, öğrenci notu tutan bir sistem veya randevu dağıtan bir takvim bu sınıfa girer. Ayrımı anlamanın kolay yolu şu soruyu sormaktır: bu sayfada kullanıcı bir şey yapıyor mu, yoksa sadece okuyor mu. Bir şey yapıyorsa arkasında mutlaka bir yazılım vardır. Aynı ayrım kullanıcı hesabı, yetki, kayıt geçmişi ve raporlama gibi ihtiyaçları da beraberinde getirir; bunların hiçbiri tanıtım sitesinde bulunmaz.

Bu ayrım süreyi ve maliyeti de belirler. Tanıtım sitesinde işin çoğu tasarım ve içerikten oluşur, sayfa sayısı arttıkça iş doğrusal biçimde büyür. Yazılımda ise asıl yük görünmeyen kısımdadır: kuralları tanımlamak, istisnaları düşünmek, hatalı girişleri karşılamak, yetkileri ayırmak ve aynı anda çalışan iki kişinin birbirinin verisini bozmasını engellemek. Ekranı çizmek genellikle en kısa aşamadır. İşletme sahiplerinin en çok şaşırdığı nokta budur; birkaç ekrandan ibaret görünen bir talep, arkasındaki kural sayısı yüzünden beklenenden uzun sürebilir. Bu nedenle kapsamı ekran sayısıyla değil, kural sayısıyla ölçmek daha gerçekçi bir yöntemdir. Kuralların yazıya dökülmesi tahmini de kolaylaştırır, çünkü konuşulmayan istisnalar genellikle en çok zaman yiyen kısımdır.

Kurumsal sitelerde ikisi çoğunlukla iç içedir. Tanıtım sayfalarının yanına içerik yönetim paneli, teklif formu, üye girişi veya bayi ekranı eklenir. Bu durumda site tek parça görünse de arkada iki farklı sorumluluk vardır ve bakım ihtiyaçları da birbirinden ayrılır. İçerik güncellemesi ile iş kuralı değişikliğini aynı torbaya koymamak, sonradan çıkacak karışıklığın önüne geçer. Kimin neyi değiştirebileceğini baştan yazmak da bu ayrımın doğal bir parçasıdır. Pratikte içerik tarafı işletmenin kendi ekibine bırakılabilirken, kural tarafı geliştirme gerektirir ve bu beklentiyi baştan netleştirmek sonradan yaşanan hayal kırıklıklarını önler. Aynı ayrım bütçe planlamasını da kolaylaştırır, çünkü iki tarafın bakım ihtiyacı birbirine benzemez.

Hazır paket mi, özel yazılım mı?

Hazır paket, çok sayıda işletmenin ortak ihtiyacına göre yazılmış ve kiralık ya da lisanslı biçimde sunulan bir üründür. En büyük avantajı hızdır: kurulum kısadır, belgeler hazırdır, bir sorunla karşılaştığınızda aynı sorunu daha önce yaşayan biri vardır. Güncellemeler de sizin dışınızda ilerler, yani bakım yükü büyük ölçüde üreticinin üzerindedir. Dezavantajı ise işinizin kendine özgü yönlerini karşılamamasıdır. Süreciniz pakete uymadığında iki seçenek kalır; ya süreci değiştirirsiniz ya da paketin etrafında elle tutulan tablolar birikmeye başlar. İkinci durum genellikle sessizce büyür ve kimse ne zaman başladığını hatırlamaz. Paketi seçmeden önce hangi süreçlerin dışarıda kalacağını yazılı olarak listelemek bu riski görünür kılar.

Özel yazılım bunun tersini yapar: süreci olduğu gibi alır ve sisteme çevirir. Bedeli süre ve sorumluluktur. Yazılan her özellik sizin bakımınıza kalır; hata çıkarsa düzeltilecek, mevzuat değişirse güncellenecektir. Buna karşılık ekibin gerçekten kullandığı, gereksiz alanlarla dolu olmayan ve iş akışınıza birebir oturan bir sistem elde edersiniz. Verinin kendi sisteminizde kalması ve dilediğiniz zaman dışarı aktarılabilmesi de uzun vadede ayrı bir kazançtır. Eğitim süresi kısalır, çünkü ekran isimleri ve adımlar zaten şirket içinde kullanılan dile göre kurulur; bu ayrıntı benimseme açısından sanıldığından daha belirleyicidir. Buna karşılık özel yazılım, kararların ve önceliklerin sizin tarafınızdan verilmesini de gerektirir.

Karar için sade bir ölçüt kullanıyoruz: sürecinizin ne kadarı sektörde standart, ne kadarı size özgü. Muhasebe, faturalama ve bordro gibi mevzuata bağlı, herkeste aynı işleyen konularda hazır çözüm mantıklıdır. Siparişin atölyede hangi sırayla ilerlediği, hangi müşteriye hangi kuralla fiyat verildiği gibi size özgü kısımlar ise özel yazılıma değer. Çoğu işletme için doğru cevap ikisinin karışımıdır ve bu karışımın sınırını baştan çizmek gerekir. Sınır çizilirken hangi sistemin hangi bilgide doğru kabul edileceğini de yazmak gerekir; aksi halde iki sistem arasında sürekli düzeltilen bir gri alan oluşur. Gri alanları en aza indirmek için her verinin tek bir ana kaynağı olduğunu baştan kabul etmek gerekir.

Ön yüz ve arka yüz: bir isteğin yolculuğu

Ön yüz, tarayıcıda çalışan ve kullanıcının gördüğü kısımdır. Arka yüz ise sunucuda çalışan, kuralları uygulayan ve veriyi yöneten kısımdır. Bir düğmeye bastığınızda ön yüz isteği hazırlar, ağ üzerinden arka yüze gönderir, arka yüz gerekli kontrolleri yapar, veri tabanına yazar ve bir cevap döner. Bu yolculuk çoğunlukla göz açıp kapayana kadar tamamlanır, ama her adımı ayrı ayrı yavaşlayabilir veya hata verebilir. Sorunun hangi adımda çıktığını bilmek çözümün yarısıdır. Bu yüzden hataların nerede oluştuğunu kaydeden bir günlük tutmak, kullanıcı sadece çalışmıyor dediğinde elinizde tek somut veri olur. Kayıtların ne kadar süre saklanacağını ve kimin bakacağını da baştan belirlemek işi kolaylaştırır.

İş kurallarının nerede duracağı önemli bir karardır. İndirim hesabı yalnızca ön yüzde yapılırsa, isteği doğrudan gönderen biri o hesabı atlayabilir. Bu yüzden doğrulamayı iki tarafta da yapmak gerekir: ön yüzde kullanıcıya hızlı geri bildirim vermek için, arka yüzde ise gerçek karar noktası olarak. Ön yüz kolaylık sağlar, arka yüz güvenceyi sağlar. İkisinin görevini karıştırmak, sonradan fark edilen açıkların en yaygın kaynağıdır ve düzeltmesi genelde zahmetli olur. Aynı ilke stok kontrolü, fiyat hesabı ve yetki denetimi için de geçerlidir; kullanıcıdan gelen hiçbir bilgi olduğu gibi doğru kabul edilmez. Bu ilkeyi bir kez benimsemek, sonradan tek tek yamanacak çok sayıda açığı en baştan kapatır.

Bu ayrımın pratik bir sonucu daha vardır: aynı arka yüz birden fazla ön yüze hizmet edebilir. Web sitesi, mobil uygulama ve iç panel aynı kuralları paylaşabilir. Sistemi baştan bu şekilde kurmak, ileride mobil tarafa geçmek istediğinizde her şeyi yeniden yazma ihtiyacını ortadan kaldırır. Kurulum öncesinde bu ihtimali sormak, sonradan verilecek en pahalı kararlardan birini ucuza almak anlamına gelir ve genellikle ek bir maliyet de getirmez. Kuralların tek yerde toplanması ayrıca tutarlılık sağlar; aynı hesabın iki farklı ekranda farklı sonuç vermesi gibi açıklaması zor durumlar da böylece ortadan kalkar. Kuralların tek noktadan yönetilmesi değişiklik yapmayı da hızlandırır, çünkü aynı düzenleme iki yerde tekrarlanmaz.

Veri tabanı: sistemin hafızası

Veri tabanı, bilgilerin düzenli biçimde saklandığı yerdir. Müşteriler, siparişler, ürünler ve kayıtlar burada tablolar halinde tutulur ve birbirleriyle ilişkilendirilir. İyi kurulmuş bir veri yapısı aynı bilgiyi iki ayrı yerde tutmaz. Müşterinin telefon numarası hem sipariş kaydında hem müşteri kartında ayrı ayrı duruyorsa, biri güncellendiğinde diğeri eskir ve zamanla hangisinin doğru olduğu bilinemez hale gelir. Bu tür küçük kopyalar, ileride en çok baş ağrıtan sorunları üretir. Bazı durumlarda kopya bilerek tutulur, örneğin faturaya yazılan adres o günkü haliyle saklanır; önemli olan bu tercihin bilinçli yapılmış olmasıdır. Bilinçli tutulan kopyalar belgelenmezse, bir süre sonra hangisinin güncellenmesi gerektiğini kimse bilemez.

Veri yapısı sonradan değiştirmesi en zahmetli katmandır, bu yüzden başta zaman ayırmaya değer. Hangi alan zorunlu, hangisi boş kalabilir, silinen kayıt gerçekten silinsin mi yoksa pasife mi çekilsin, geçmiş fiyat saklanacak mı gibi sorular ilk toplantıda konuşulmalıdır. Ayrıca yedeğin nasıl ve hangi sıklıkla alınacağı, yedekten geri dönüşün gerçekten denenip denenmediği de bu başlığın ayrılmaz parçasıdır. Denenmemiş bir yedek, olmayan yedekle aynı güveni verir. Yedeğin sistemden ayrı bir yerde durması ve eski kopyaların bir süre saklanması, fark edilmesi geciken veri bozulmalarına karşı tek gerçek korumadır. Yedeğin ne kadar sürede geri yüklenebildiğini ölçmek de kriz anında verilecek sözleri gerçekçi kılar.

API ve entegrasyon: sistemlerin birbiriyle konuşması

API, iki yazılımın anlaşarak veri alışverişi yapmasını sağlayan tanımlı bir arayüzdür. İnsan için ekran ne ise, yazılım için API odur. Kargo firmasının takip bilgisini çekmek, sanal pos ile ödeme almak, muhasebe programına fatura göndermek veya kısa mesaj sağlayıcısına doğrulama kodu ilettirmek hep bu yolla yapılır. Bu bağlantılar sayesinde aynı veriyi iki ayrı yere elle girme zorunluluğu ortadan kalkar ve insan kaynaklı hata payı belirgin biçimde düşer. Bağlantı kurmadan önce karşı tarafın belgelerini okumak ve test ortamı sunup sunmadığını sormak, sonradan yaşanacak sürprizlerin çoğunu baştan eler. Bağlantı için gereken izinlerin ve sözleşmelerin de geliştirmeye başlamadan önce tamamlanması gerekir.

Entegrasyonun görünmeyen tarafı hata yönetimidir. Karşı taraf yanıt vermezse ne olacak, aynı istek iki kez gönderilirse çift kayıt oluşur mu, cevap geç gelirse kullanıcı bekletilecek mi. Bu soruların cevabı yazılmazsa entegrasyon iyi günlerde çalışır, kötü günlerde veri karışıklığı üretir. Tekrar denenebilen ve tekrarlandığında aynı sonucu veren bir yapı kurmak, uzun vadede en çok işe yarayan alışkanlıklardan biridir. Hataların bir yerde kayıt altına alınması da şarttır. Ayrıca karşı tarafın kurallarını tek taraflı değiştirebileceğini hesaba katmak ve bağlantıyı düzenli aralıklarla denemek gerekir, çünkü sessizce bozulan bir entegrasyon aylarca fark edilmeyebilir. Bu yüzden başarısız isteklerin bir yerde toplanması ve belirli bir eşiği aştığında haber verilmesi faydalıdır.

Kendi sisteminiz de API sunabilir. Bayilerin stok sorgulaması, tedarikçinin fiyat göndermesi veya bir mobil uygulamanın veri çekmesi bu şekilde çözülür. Dışarıya açılan her kapının kimlik doğrulaması, hız sınırı ve kayıt tutması olmalıdır. Kim ne zaman neyi istedi sorusunun cevabı tutulmuyorsa, bir sorun çıktığında nedenini bulmak neredeyse imkansız hale gelir. Erişim anahtarlarının değiştirilebilir olması da unutulmaması gereken bir ayrıntıdır; anahtarını kaybeden bir iş ortağı için tüm sistemin durdurulması gerekmemelidir. Dışarıya yalnızca gerçekten gereken alanları açmak ise hem güvenlik hem de performans açısından iyi bir alışkanlıktır. Sunduğunuz arayüzün nasıl kullanılacağını kısa bir belgeyle anlatmak ise destek yükünü belirgin biçimde azaltır.

Yetkilendirme ve güvenlik

Kimlik doğrulama kullanıcının kim olduğunu belirler; yetkilendirme ise o kişinin neyi yapabileceğini belirler. İkisi ayrı konudur ve güvenlik sorunlarının çoğu ikincisinde yaşanır. Sisteme girmiş bir kullanıcı, adres satırındaki kayıt numarasını değiştirerek başkasının verisine ulaşabiliyorsa ortada bir yetki denetimi eksikliği vardır. Her istekte, o kullanıcının o kayda erişme hakkı olup olmadığını arka yüzün ayrıca sorması gerekir. Menüden bağlantıyı gizlemek bir koruma yöntemi değildir. Rolleri az sayıda ve net tutmak da işi kolaylaştırır; her kullanıcıya ayrı ayrı yetki tanımlamak zamanla kimsenin takip edemediği bir tabloya dönüşür. Yetkilerin belirli aralıklarla gözden geçirilmesi de görev değişikliklerinden kalan gereksiz erişimleri temizler.

Temel korumalar bugün büyük ölçüde standarttır: parolaları geri döndürülemez biçimde saklamak, oturumları belirli süre sonra sonlandırmak, form girdilerini süzmek, veri tabanı sorgularını parametreli yazmak, dosya yüklemelerini tür ve boyut açısından denetlemek ve yönetim ekranlarını arama motorlarına kapatmak. Bunlar yapılmadığında sorun genellikle hedefli bir saldırıyla değil, siteleri otomatik olarak tarayan botlarla ortaya çıkar. Küçük siteler de bu taramaların dışında kalmaz; tarayan taraf sitenin ne kadar bilindiğine bakmaz, yalnızca açık arar. Yönetici girişine ek doğrulama koymak ise bu tür denemelerin büyük kısmını en baştan sonuçsuz bırakır. Başarısız giriş denemelerini sınırlamak da parola tahmin etmeye dayalı saldırıları pratikte kullanışsız hale getirir.

Güvenliği bir kerelik iş gibi görmemek gerekir. Kullanılan kütüphaneler zamanla açık verir ve güncelleme ister, ekipten ayrılan kişinin erişimi kapatılmalıdır, günlük kayıtları düzenli olarak gözden geçirilmelidir. Ayrıca yedeğin sistemle aynı yerde durması gerçek bir yedek sayılmaz. Bu maddeler sıkıcıdır ve genellikle ertelenir; ancak bir olay yaşandığında işletmeyi ayakta tutan tek şey tam olarak bunlardır. Küçük ve düzenli kontroller, telaşlı müdahalelerden çok daha ucuzdur. Bir sorun yaşandığında kimin neyi yapacağını önceden yazmak da faydalıdır, çünkü kriz anında en çok kaybedilen şey karar verme süresidir. Bir olay yaşandığında kimin bilgilendirileceğini de listeye eklemek, iletişim karmaşasını en aza indirir.

Ölçeklenme: yük arttığında ne oluyor

Ölçeklenme, kullanıcı ve veri arttıkça sistemin ayakta kalabilmesidir. İlk günlerde sorunsuz çalışan bir sorgu, kayıt sayısı büyüdüğünde belirgin biçimde yavaşlayabilir. Genellikle çare sunucuyu büyütmek değil, sorguları ve veri yapısını düzeltmektir. Doğru dizinleri tanımlamak, gereksiz tekrarlanan sorguları toplamak, sık istenen sonuçları geçici olarak saklamak ve uzun listeleri sayfalara bölmek çoğu darboğazı ortadan kaldırır. Bunların çoğu sonradan uygulanabilir düzeltmelerdir. Görsellerin ve dosyaların uygulama sunucusu yerine ayrı bir yerden sunulması da yükü hissedilir biçimde azaltan, uygulaması görece kolay bir adımdır. Raporların yoğun saatler dışında hazırlanması da gündüz yaşanan yavaşlamaların bir kısmını ortadan kaldırır. Ölçüm yapmadan verilen kararlar ise genellikle yanlış yere yatırım yapılmasına yol açar.

Ölçeklenmede aşırıya kaçmamak da bir denge işidir. Günde birkaç yüz işlem yapacak bir sistemi çok daha büyük bir yük varsayımıyla kurmak, gereksiz karmaşıklık üretir ve bakımı zorlaştırır. Doğru yaklaşım, ölçüm noktalarını en baştan yerleştirmek ve gerçek yük görünmeye başladığında müdahale etmektir. Neyin yavaşladığını bilmeden yapılan iyileştirme, çoğunlukla yanlış yere harcanan emektir; üstelik asıl sorunun üstünü örttüğü için tespiti de geciktirir. Yavaşlama şikayetlerinde ilk bakılacak yer genellikle en çok çağrılan birkaç sorgudur, çünkü darboğaz nadiren her yere dağılmış durumdadır. Sistemin yavaşladığı anları kaydeden basit bir izleme aracı kurmak, bu tespitleri tahmin olmaktan çıkarır ve düzeltmeyi hedefli hale getirir.

Test, yayın ve geri dönüş planı

Test, yazılımın beklendiği gibi çalıştığını kanıtlama işidir. Küçük projelerde bile en azından kritik akışların elle denenmesi gerekir: kayıt açma, sipariş verme, ödeme alma, iptal etme. Otomatik testler ise aynı kontrolleri her değişiklikten sonra tekrarlar ve eskiden çalışan bir yerin bozulduğunu erken haber verir. Her satırı test etmek şart değildir; parayla, yetkiyle ve veri bütünlüğüyle ilgili kısımları test etmek ise gerçekten şarttır. Bir hata ortaya çıktığında o hatayı yakalayan bir test yazmak da iyi bir alışkanlıktır, çünkü aynı hatanın ileride tekrar etmesini kalıcı biçimde engeller. Test verisinin gerçekçi olması da önemlidir, çünkü yalnızca ideal girdilerle yapılan denemeler sahadaki durumları temsil etmez.

Yayın öncesinde canlıya benzeyen ayrı bir ortamda deneme yapmak alışkanlık haline gelmelidir. Doğrudan canlı sistemde geliştirme yapmak, kullanıcıların yarım kalmış bir özellikle karşılaşmasına yol açar. Ortamlar arasında ayarların ayrı tutulması da önemlidir. Test ortamının gerçek müşterilere e-posta göndermesi veya gerçek tahsilat denemesi yapması sık rastlanan ve utandırıcı bir hatadır; bu tür ayarların yayın kontrol listesinde yer alması gerekir. Test ortamındaki verinin gerçek müşteri bilgilerinden arındırılması da hem gizlilik hem de yanlış bir işlemi yanlış kişiye uygulama riski açısından önemlidir. Bu ortamın canlı sistemle aynı sürümleri kullanması ise test sonuçlarının güvenilir olmasını sağlar.

Yayının bir geri dönüş planı olmalıdır. Değişiklik beklenmedik bir sonuç doğurduğunda önceki sürüme dönebilmek, sorunu telaş içinde çözmeye çalışmaktan çok daha güvenlidir. Bunun için sürüm takibi tutulur, veri tabanı değişiklikleri sıralı adımlar halinde yazılır ve yayın öncesinde yedek alınır. Yayın saatini yoğun olmayan bir zamana koymak da basit ama etkili bir önlemdir. Kimin hangi adımdan sorumlu olduğunu önceden belirlemek karmaşayı azaltır. Yayından sonraki ilk saatlerde sistemi izlemek ve hata kayıtlarına bakmak ise sorunları kullanıcı bildirmeden önce yakalamanın en pratik yoludur. Yayın sonrası ilk günlerde büyük değişiklik yapmamak da sorunun kaynağını ayırt edebilmek açısından yararlıdır.

Bakım ve teknik borç

Teknik borç, hızlı ilerlemek için bilerek veya farkında olmadan bırakılan geçici çözümlerin birikmesidir. Yarın düzeltiriz denilerek yazılan kod, aylar sonra sistemin en kırılgan yeri haline gelir. Borcun kendisi kötü değildir, ödenmemesi kötüdür. Her yeni özellik turunda küçük bir payı düzeltmeye ayırmak, bir gün her şeyi baştan yazma ihtiyacının doğmasını engeller. Bu payı görünür kılmak için birikmiş düzeltmeleri de bir liste halinde tutmak gerekir. Listeyi tutmak aynı zamanda bir tahmin aracıdır; aynı dosyada tekrar tekrar sorun çıkıyorsa, orada yapılacak düzenlemenin sırası gelmiş demektir. Düzeltmeleri özellik geliştirmesiyle aynı takvimde planlamak, bu işin sürekli ertelenmesini de engeller.

Bakım yalnızca hata düzeltmek değildir. Dil ve kütüphane sürümleri eskir, güvenlik yamaları çıkar, sunucu ayarları değişir, tarayıcılar davranışlarını günceller. Bakım anlaşması olmayan sistemler bir süre sorunsuz görünür, sonra hepsi aynı anda güncelleme ister ve iş küçük bir dokunuş olmaktan çıkıp projeye dönüşür. Küçük ve düzenli bakım, seyrek ve büyük müdahaleden hem daha ucuz hem daha az risklidir; ayrıca planlanabilir olduğu için işi aksatmaz. Alan adı, sertifika ve dış servis aboneliklerinin bitiş tarihlerini takip etmek de bakımın sıkıcı ama sonuçları en görünür parçasıdır. Süresi dolan bir sertifika yüzünden erişilemeyen bir site, çoğu yazılım hatasından daha fazla güven kaybettirir.

Ne zaman özel yazılım gerekir, ne zaman gerekmez

Özel yazılıma geçmek için birkaç somut işaret vardır. Ekip aynı veriyi birden fazla yere elle giriyorsa, işin kritik kısmı tek bir kişinin hazırladığı tablolarda duruyorsa, müşteriye verilen sözler takip edilemediği için unutuluyorsa veya hazır programın etrafında sürekli elle düzeltme yapılıyorsa yazılım konuşulabilir. Bu durumlarda asıl kazanç hız değil, hatanın azalması ve bilginin kişilere bağımlı olmaktan çıkmasıdır. Ekip değişikliklerinde bunun değeri hemen görülür. Bir başka işaret de raporların elle hazırlanmasıdır; her ay tekrarlanan bir derleme işi genellikle otomatikleştirilmeye hazır demektir. Bu işaretleri tek tek yazmak, yazılım ihtiyacını duygusal bir tercih olmaktan çıkarıp ölçülebilir bir karara dönüştürür.

Gerekmediği durumlar da nettir. Süreç henüz oturmamışsa, yöntem her ay değişiyorsa veya işlem sayısı çok düşükse yazılım erken kalır. Böyle bir dönemde en iyisi süreci basit araçlarla yürütüp yazıya dökmektir, çünkü yazılım belirsiz bir süreci netleştirmez, sadece onu kalıcı hale getirir. Yanlış tanımlanmış bir akışı koda çevirmek, hatayı daha hızlı ve daha düzenli biçimde tekrarlamaktan başka bir işe yaramaz. Aynı şekilde, sadece rakipte var diye istenen özellikler de genellikle kullanılmadan kalır; talebin arkasında somut bir iş sorunu olup olmadığını sormak en sağlıklı filtredir. Bu soru yöneltilmediğinde kapsam sessizce büyür ve asıl ihtiyaç geri planda kalır.

İşe küçük başlamak çoğu zaman doğru yoldur. Tüm ihtiyaçları kapsayan büyük bir sistem yerine, en çok acıtan tek bir süreci çözen bir modülle başlamak hem bütçeyi hem riski böler. Ekip o modülü gerçekten kullanıyorsa ikinci adıma geçilir. Kullanmıyorsa sebebini anlamak, üzerine yeni özellik eklemekten çok daha değerlidir; çünkü kullanılmayan yazılım, hiç yazılmamış yazılımdan daha maliyetlidir ve ekibin güvenini de yıpratır. İlk modül seçilirken görünür sonuç veren bir alan tercih edilirse, sonraki adımlar için gereken desteği bulmak da kolaylaşır. İlk sürümü kısa tutmak ayrıca gerçek kullanımdan öğrenip ikinci sürümü daha isabetli planlamanızı sağlar.