Bir web projesine başlarken ilk konuşulan konular genellikle tasarım, kullanılacak teknoloji ve teslim tarihidir. Ana sayfanın nasıl görüneceği, yönetim panelinin hangi altyapıyla geliştirileceği veya projenin kaç haftada tamamlanacağı merak edilir.

Bunların hepsi önemli. Ancak projenin yönünü belirleyen asıl sorular çoğu zaman bunlardan önce gelir.

Web sitesi veya yazılım neden hazırlanıyor? Kim kullanacak? Kullanıcı hangi işlemleri yapacak? Hangi veriler tutulacak? İçerikleri kim yönetecek? Projenin tamamlandığına neye göre karar verilecek?

Bu sorular cevaplanmadan tasarıma veya kodlamaya başlandığında ekip kaçınılmaz olarak bazı varsayımlarda bulunur. Proje ilerledikçe gerçek ihtiyaçlar ortaya çıkar ve başlangıçta doğru görünen kararlar yeniden ele alınmak zorunda kalır.

Buradaki amaç, geliştirme başlamadan önce yüzlerce sayfalık bir doküman hazırlamak değil. Projenin temel çalışma biçimini ortak olarak anlamak ve önemli kararları tahminlere bırakmamaktır.

Aşağıdaki 12 soru, kurumsal bir web sitesinden kapsamlı bir yönetim yazılımına kadar farklı büyüklükteki projeler için kullanılabilir. Her sorunun cevabı aynı ayrıntıda olmak zorunda değildir. Ancak cevaplanmadan geçilen her önemli konu, projenin ilerleyen aşamalarında belirsizlik olarak geri dönebilir.

1. Bu proje hangi problemi çözecek?

Bir web projesi için sorulması gereken ilk soru, hangi sayfaların hazırlanacağı değil, projenin hangi problemi çözeceğidir.

“Yeni bir web sitesine ihtiyacımız var” tek başına yeterli bir cevap değildir. Yeni siteye neden ihtiyaç duyulduğu anlaşılmalıdır. Mevcut site güncel değil mi? Kullanıcılar aradıkları bilgiye ulaşamıyor mu? Mobil kullanım sorunlu mu? Site üzerinden teklif talebi alınamıyor mu? Ürünler yönetilemiyor mu? Yoksa işletmenin çalışma sürecindeki bazı işlemler dijital ortama mı taşınmak isteniyor?

Aynı sektörde faaliyet gösteren iki işletme dışarıdan bakıldığında benzer bir web sitesine ihtiyaç duyuyor gibi görünebilir. Ancak birinin amacı telefonla gelen talepleri artırmak, diğerinin amacı satış ekibine ulaşmadan önce müşteriyi bilgilendirmek olabilir. Bu iki hedef, benzer sayfalar içerse bile farklı içerik yapıları ve kullanıcı akışları gerektirir.

Sorun açık biçimde tanımlanmadığında proje kolayca özellik listesine dönüşür. Ana sayfa, hakkımızda, hizmetler, blog ve iletişim sayfaları hazırlanır. Fakat bu sayfaların hangi ihtiyaca hizmet edeceği bilinmediği için içerikler ve yönlendirmeler birbirinden kopuk kalır.

Problemin tanımlanması, hangi özelliklerin gerekli olmadığını anlamayı da sağlar. Amaç yalnızca işletmenin hizmetlerini açık biçimde anlatmak ve iletişim talebi toplamaksa kapsamlı bir üyelik sistemi gerekmeyebilir. Buna karşılık müşterilerin siparişlerini takip etmesi gerekiyorsa basit bir iletişim formu ihtiyacı karşılamaz.

İyi tanımlanmış bir proje amacı tek cümlede anlatılabilmelidir. Bu cümle bütün ayrıntıları kapsamak zorunda değildir. Ancak ekip, proje boyunca alınan kararların bu amaca hizmet edip etmediğini değerlendirebilmelidir.

2. Projeyi kimler kullanacak?

“Siteyi herkes kullanacak” pratikte pek açıklayıcı bir cevap değildir. Bir sistemi kullanabilecek herkes ile sistemin öncelikli olarak tasarlandığı kişiler aynı şey değildir.

Kullanıcıların kim olduğu; dil seçiminden navigasyona, form alanlarından yazı büyüklüğüne kadar birçok kararı etkiler. Teknik bilgiye sahip profesyoneller için hazırlanan bir arayüzle ilk kez çevrim içi işlem yapacak kullanıcılar için hazırlanan arayüz aynı şekilde kurulamaz.

Ayrıca projede yalnızca ziyaretçileri düşünmek yeterli değildir. Sistemin arka tarafını kullanacak kişiler de projenin kullanıcılarıdır. İçerik editörleri, satış çalışanları, yöneticiler, bayiler, müşteriler veya destek ekibi farklı ihtiyaçlara ve yetkilere sahip olabilir.

Örneğin bir araç listeleme sisteminde ziyaretçi ilanları inceler ve filtreler. Satış çalışanı ilan ekler, fiyat günceller ve gelen talepleri takip eder. Yönetici ise çalışanların işlemlerini görür, raporları inceler ve bazı kayıtları onaylar. Tek bir proje içinde üç farklı kullanım biçimi bulunur.

Kullanıcı grupları belirlenirken yalnızca kim oldukları değil, sistemle hangi koşullarda etkileşim kuracakları da düşünülmelidir. Kullanıcı ağırlıklı olarak telefondan mı erişecek? İşlem sırasında hızlı karar vermesi mi gerekiyor? Sistemi her gün mü kullanacak, yılda birkaç kez mi? Bir işlem için gerekli bilgileri önceden biliyor mu?

Bu cevaplar tasarımın yanı sıra içerik dilini ve teknik yapıyı da etkiler. Her gün kullanılan bir yönetim ekranında işlem hızı öne çıkarken, ilk kez kullanılan bir başvuru formunda açıklamalar ve yönlendirmeler daha önemli olabilir.

Projeye başlamadan önce bütün kullanıcı tiplerinin ayrıntılı kişilik profillerini hazırlamak şart değildir. Ancak temel kullanıcı grupları ve bu grupların sistemden beklentileri açıkça belirlenmelidir.

3. Kullanıcıların tamamlaması gereken temel işlemler nelerdir?

Sayfa listesi, kullanıcı akışı değildir.

Bir projede “ürünler”, “iletişim” veya “rezervasyon” sayfasının bulunacağını söylemek, kullanıcının bu sayfalarda ne yapacağını açıklamaz. Kullanıcının sisteme nereden gireceği, hangi adımları izleyeceği ve işlemin sonunda ne olacağı ayrıca belirlenmelidir.

Bir rezervasyon sistemi düşünelim. Kullanıcı tarih seçebilir, uygun saatleri görüntüleyebilir ve iletişim bilgilerini girebilir. Fakat bundan sonra ne olur? Rezervasyon doğrudan onaylanır mı? İşletmenin onayı mı beklenir? Ödeme alınır mı? Kullanıcıya e-posta veya SMS gönderilir mi? İşlem başka bir takvim sistemine aktarılır mı?

Bu soruların cevapları bilinmeden yalnızca rezervasyon ekranını tasarlamak, sistemin küçük bir bölümünü ele almak anlamına gelir.

Temel kullanıcı akışları basit adımlarla yazılabilir. Örneğin:

  1. Kullanıcı hizmeti seçer.

  2. Tarih ve saat seçer.

  3. İletişim bilgilerini girer.

  4. Ödemeyi tamamlar.

  5. Rezervasyon kaydı oluşturulur.

  6. Kullanıcıya ve işletmeye bildirim gönderilir.

Böyle bir akış yazıldığında belirsiz noktalar daha kolay görülür. Ödeme başarısız olursa rezervasyon süresi tutulacak mı? Kullanıcı işlemi iptal edebilecek mi? Aynı saat iki kişi tarafından seçilirse ne olacak? İşletme rezervasyonu değiştirebilecek mi?

Her ihtimalin ilk günden geliştirilmesi gerekmeyebilir. Fakat temel işlemin hangi aşamalardan oluştuğu anlaşılmadan veri modeli, arayüz ve iş kuralları sağlıklı biçimde hazırlanamaz.

Bu nedenle projeye başlamadan önce en önemli kullanıcı işlemleri baştan sona tarif edilmelidir. Sayfa sayısından çok bu işlemlerin niteliği, projenin gerçek kapsamını gösterir.

4. Sistemde hangi içerikler ve veriler tutulacak?

Birçok proje başlangıçta ekranlar üzerinden konuşulur. Oysa ekranların arkasında hangi verilerin bulunacağı, sistemin nasıl kurulacağını doğrudan belirler.

Bir ürünün yalnızca adı, açıklaması, fiyatı ve görseli mi olacak? Ürünün renk ve beden seçenekleri bulunacak mı? Her seçeneğin ayrı stok miktarı, kodu, fiyatı veya görseli olacak mı? Ürünler birden fazla kategoriye dahil edilebilecek mi? Fiyatlar kullanıcı tipine göre değişecek mi?

Dışarıdan bakıldığında bunların tamamı “ürün ekleme” özelliği gibi görünebilir. Teknik tarafta ise birbirinden oldukça farklı veri modelleri gerektirir.

Benzer durum kurumsal içeriklerde de görülür. Bir hizmet yalnızca başlık ve açıklamadan mı oluşacak? Hizmete bağlı sık sorulan sorular, referans projeler, belgeler, ekip üyeleri veya hizmet bölgeleri bulunacak mı? Aynı içerik farklı sayfalarda tekrar kullanılacak mı?

Veriler arasındaki ilişkilerin belirlenmesi, yönetim panelinin ve frontend yapısının nasıl kurulacağını etkiler. Projenin ilerleyen aşamasında yeni bir ilişkinin ortaya çıkması yalnızca veritabanına alan eklemek anlamına gelmeyebilir. Formlar, sorgular, filtreler, API cevapları ve sayfa düzenleri de değişebilir.

Bu aşamada her tablonun ve sütunun teknik olarak tanımlanması şart değildir. Öncelikle sistemde hangi varlıkların bulunacağı ve bunların birbirleriyle nasıl ilişki kuracağı anlaşılmalıdır.

Örneğin bir eğitim platformunda kullanıcılar, eğitimler, eğitmenler, dersler, kayıtlar, ödemeler ve sertifikalar bulunabilir. Bir eğitimin birden fazla eğitmeni olabilir mi? Kullanıcı aynı eğitime tekrar kayıt olabilir mi? Sertifika hangi koşulda oluşturulur? Bu ilişkiler projenin çalışma biçimidir.

Veri modeli teknik ekibin daha sonra kendi içinde çözebileceği bağımsız bir ayrıntı değildir. İşletmenin gerçek sürecinin yazılım içindeki karşılığıdır.

5. Hangi içerikler yönetim panelinden değiştirilecek?

“Bir yönetim paneli olsun” ifadesi de tek başına yeterli değildir. Panelden tam olarak nelerin yönetileceği belirlenmelidir.

Bazı projelerde yalnızca blog yazılarının ve sayfa metinlerinin düzenlenmesi yeterlidir. Bazılarında ürünler, siparişler, kullanıcılar, rezervasyonlar, fiyatlar, raporlar ve sistem ayarları aynı panelden yönetilir.

Her alanı yönetilebilir hâle getirmek esneklik sağlar gibi görünebilir. Ancak hiç değişmeyecek bölümlerin gereksiz biçimde dinamikleştirilmesi geliştirme süresini ve bakım yükünü artırır. Buna karşılık sık değişen bir alanın kod içine sabitlenmesi, her güncellemede geliştirici desteğine ihtiyaç duyulmasına neden olur.

Bu nedenle içerikler için şu sorular sorulmalıdır:

  • Bu bilgi ne sıklıkla değişecek?

  • Değişikliği kim yapacak?

  • Yeni kayıt eklenebilecek mi, yoksa yalnızca mevcut kayıt mı düzenlenecek?

  • Kayıtlar silinebilecek mi?

  • Taslak ve yayın durumu olacak mı?

  • Değişikliklerin geçmişi tutulacak mı?

  • Toplu düzenleme veya dışa aktarma gerekli mi?

Yönetim panelinin amacı, mümkün olan her şeyi kullanıcıya açmak değildir. Kullanıcının gerçekten yönetmesi gereken işlemleri güvenli ve anlaşılır hâle getirmektir.

Bir içerik editörünün her sayfadaki boşluk değerini veya renk kodunu değiştirebilmesi esneklik gibi görünebilir. Ancak bu durum kısa sürede tasarım bütünlüğünü bozabilir. Panelde yönetilebilir alanların sınırları, hem günlük kullanım hem de sistemin sürdürülebilirliği düşünülerek belirlenmelidir.

6. Kullanıcı rolleri ve yetkiler nasıl ayrılacak?

Bir sistemi kimin kullandığını belirledikten sonra, bu kişilerin hangi işlemleri yapabileceğini de netleştirmek gerekir.

“Yönetici” adı verilen tek bir rol başlangıçta yeterli görünebilir. Ancak proje kullanılmaya başladığında bazı çalışanların içerik düzenlemesi, bazılarının siparişlere erişmesi, bazılarının ise yalnızca raporları görüntülemesi gerekebilir.

Yetkilendirme yalnızca menü öğelerini gizlemek değildir. Kullanıcının hangi verileri görebileceği, hangi kayıtları değiştirebileceği ve hangi işlemleri onaylayabileceği sunucu tarafında da kontrol edilmelidir.

Örneğin farklı bayilerin kullandığı bir sistemde her bayi yalnızca kendi müşterilerini ve siparişlerini görebilir. Bölge yöneticisi kendi bölgesindeki bayilere erişebilir. Genel yönetici ise bütün kayıtları inceleyebilir. Bu yapı, standart bir yönetici panelinden farklı sorgular ve veri ilişkileri gerektirir.

Yetkiler belirlenirken yalnızca bugünkü çalışan sayısına bakmak da yeterli değildir. Sistemi şu anda tek bir kişi kullanıyor olabilir. Ancak yakın gelecekte görevlerin ayrılacağı biliniyorsa altyapının buna uygun kurulması daha sağlıklı olur.

Yine de olası her rolü ilk günden geliştirmek gerekmez. Önemli olan kullanıcı gruplarının ayrılabileceğini bilmek ve temel yapıyı tek bir sınırsız yönetici varsayımı üzerine kurmamaktır.

Rol ve yetkiler baştan konuşulmadığında, ileride çok kullanıcılı yapıya geçmek basit bir kullanıcı ekleme işleminden daha büyük bir değişikliğe dönüşebilir.

7. Harici servisler ve entegrasyonlar bulunacak mı?

Web projeleri çoğu zaman tek başına çalışmaz. Ödeme sistemleri, CRM uygulamaları, muhasebe yazılımları, kargo firmaları, harita servisleri, e-posta sağlayıcıları ve farklı API’lerle bağlantı kurulabilir.

“Ödeme entegrasyonu olacak” demek başlangıç için yeterli görünse de ayrıntılar önemlidir. Tek çekim mi yapılacak? Taksit olacak mı? İade işlemi panelden mi başlatılacak? Abonelik veya tekrarlayan ödeme bulunacak mı? Başarısız işlemler nasıl takip edilecek?

CRM bağlantısında da yalnızca form bilgilerinin gönderilmesi yeterli olmayabilir. Kayıt güncellemeleri geri alınacak mı? Müşteri durumu iki sistem arasında eşitlenecek mi? Bağlantı kesildiğinde veriler sıraya alınacak mı? Aynı kaydın birden fazla kez oluşturulması nasıl engellenecek?

Entegrasyonların teknik dokümantasyonu, erişim izinleri, test ortamları ve kullanım limitleri proje başlamadan önce incelenmelidir. Bazen dış servisin desteklemediği bir işlem, proje içinde kolayca yapılabilecekmiş gibi planlanabilir.

Harici servisin çalışma biçimi teslim süresini de etkileyebilir. API erişiminin açılması, kurumsal hesabın doğrulanması veya ödeme kuruluşunun canlı kullanım onayı günler sürebilir. Bu adımlar son haftaya bırakıldığında teknik geliştirme tamamlanmış olsa bile proje yayına alınamayabilir.

Ayrıca hiçbir harici servisin sürekli ve hatasız çalışacağı varsayılmamalıdır. Zaman aşımı, hatalı cevap, bağlantı kesintisi veya kota sınırı durumlarında sistemin nasıl davranacağı belirlenmelidir.

Entegrasyon, iki sistem arasında veri gönderen tek bir kod parçası değildir. Başarılı ve başarısız bütün olasılıklarıyla ayrı bir iş akışıdır.

8. İlk sürümde mutlaka neler yer alacak?

Bir projenin gelecekte sahip olabileceği bütün özelliklerle ilk sürümde ihtiyaç duyduğu özellikler aynı değildir.

Başlangıçta her ihtimali kapsamak güvenli bir yaklaşım gibi görünebilir. Ancak bu durum projenin gereksiz biçimde büyümesine, teslim süresinin uzamasına ve asıl ihtiyacın arka planda kalmasına neden olabilir.

Bu nedenle özellikleri en az üç gruba ayırmak faydalıdır:

  • İlk sürüm için zorunlu olanlar

  • İlk sürümden sonra geliştirilebilecek olanlar

  • Şimdilik yalnızca fikir aşamasında bulunanlar

Bu ayrım yapılırken “güzel olur” ile “olmadan sistem çalışmaz” arasındaki fark açıkça konuşulmalıdır.

Örneğin bir randevu sistemi için hizmet seçimi, uygun saatlerin gösterilmesi ve rezervasyon kaydı zorunlu olabilir. Kullanıcının geçmiş randevularını görebileceği kapsamlı bir profil ekranı ise ikinci sürüme bırakılabilir. Puan sistemi veya kampanya modülü ise gelecekte değerlendirilecek fikirler arasında yer alabilir.

İlk sürümün küçük tutulması, özensiz veya eksik bir ürün hazırlamak anlamına gelmez. Temel işlemi baştan sona doğru biçimde çalışan bir yapıyla yayına çıkmak anlamına gelir.

Burada dikkat edilmesi gereken nokta, ertelenen özelliklerin bugünkü yapıyı etkileyip etkilemediğidir. İkinci dil daha sonra eklenecek olabilir; ancak geleceği kesin olarak biliniyorsa içerik modeli ve URL yapısı baştan buna uygun hazırlanabilir.

İlk sürümün sınırı açıkça belirlenmediğinde proje boyunca yeni talepler eklenir ve bitiş noktası sürekli ileri taşınır. Kapsam yalnızca teklif hazırlamak için değil, projenin ne zaman tamamlandığını anlayabilmek için de gereklidir.

9. İçerikler ne zaman ve kim tarafından hazırlanacak?

İçerik, proje tamamlandıktan sonra boş alanlara eklenecek ayrı bir çalışma değildir. Tasarımın ve sayfa yapısının temel girdilerinden biridir.

Hazır metinler olmadan oluşturulan bir sayfa, kısa örnek başlıklar ve dengeli paragraflarla oldukça iyi görünebilir. Gerçek içerikler geldiğinde başlıklar uzar, açıklamalar farklı boyutlara ulaşır ve bazı bölümlerin beklenenden çok daha fazla bilgi taşıması gerektiği anlaşılır.

Benzer durum görseller için de geçerlidir. Tasarım geniş yatay fotoğraflara göre hazırlanırken işletmenin elinde yalnızca düşük çözünürlüklü dikey görseller bulunabilir. Bu durumda yalnızca görselleri değiştirmek değil, yerleşimi yeniden düşünmek gerekebilir.

Proje başında şu konular belirlenmelidir:

  • Sayfa metinlerini kim yazacak?

  • Ürün veya hizmet bilgilerini kim sağlayacak?

  • Görseller hazır mı?

  • İçerikler hangi formatta teslim edilecek?

  • Metinlerin kontrol ve onayını kim yapacak?

  • İçerik girişi proje kapsamına dahil mi?

  • Eksik içerikler teslim tarihini etkileyecek mi?

İçerik sorumluluğu açık olmadığında tasarım ve geliştirme tamamlanır, fakat site yayına alınamaz. Proje teknik olarak hazır görünürken haftalarca metin ve görsel bekleyebilir.

İçerik yapısının erken belirlenmesi SEO açısından da önemlidir. Hangi hizmetlerin ayrı sayfalarda anlatılacağı, kategori yapısının nasıl kurulacağı ve hangi konuların blog içeriği olacağı son aşamada rastgele kararlaştırılmamalıdır.

İyi tasarım, örnek metinlerin oluşturduğu yapay düzene değil, gerçek içeriğin ihtiyaçlarına göre şekillenir.

10. SEO, çoklu dil ve ölçümleme ihtiyaçları neler?

SEO çoğu projede site tamamlandıktan sonra yapılacak ayrı bir çalışma gibi düşünülür. Oysa sayfa yapısı, URL’ler, içerik ilişkileri ve teknik altyapı daha geliştirme aşamasında SEO’yu etkiler.

Hangi sayfaların arama sonuçlarında görünmesi gerektiği, benzer içeriklerin nasıl ayrılacağı, yönlendirmelerin nasıl yapılacağı ve yapılandırılmış verilerin kullanılıp kullanılmayacağı baştan değerlendirilmelidir.

Çoklu dil desteği de yalnızca metinleri çevirmekten ibaret değildir. Her dil için ayrı URL yapısı, slug, meta alanları, canonical ve hreflang etiketleri gerekebilir. İçeriklerin tamamı mı çevrilecek, bazı sayfalar yalnızca tek dilde mi kalacak ve kullanıcı dil değiştirdiğinde hangi sayfaya yönlendirilecek gibi kararlar sistemin temelini etkiler.

Ölçümleme tarafında ise “Analytics eklenecek” demek yeterli değildir. Projenin amacına göre hangi işlemlerin takip edileceği belirlenmelidir.

Bir iletişim formunun gönderilmesi, telefon bağlantısına tıklanması, teklif dosyasının indirilmesi, ödeme işleminin tamamlanması veya üyelik oluşturulması farklı dönüşüm noktalarıdır. Bu işlemler geliştirme sırasında doğru biçimde işaretlenmezse daha sonra yalnızca sayfa ziyaretlerini görmek mümkün olur.

Çerez onayı, reklam etiketleri ve kişisel veri işleme gereksinimleri de kullanılan ölçüm araçlarıyla birlikte düşünülmelidir. Her kodu sayfaya eklemek teknik olarak kolay olabilir; ancak kullanıcının hangi verisinin hangi amaçla işlendiği ayrıca değerlendirilmelidir.

SEO ve ölçümleme sonradan eklenebilir özellikler gibi görünse de çoğu zaman sayfa yapısını ve teknik kararları başlangıçtan itibaren etkiler.

11. Bütçe, teslim tarihi ve sorumluluklar gerçekçi mi?

Bir projenin kapsamı ile bütçesi ve teslim tarihi birbirinden bağımsız değildir.

Kapsam netleşmeden verilen kesin süreler çoğu zaman tahmine dayanır. “Bu site ne kadar sürer?” sorusuna yalnızca sayfa sayısına bakarak cevap vermek yanıltıcı olabilir. Beş sayfalık bir kurumsal site, içerikler hazırsa ve özel bir işlev içermiyorsa kısa sürede tamamlanabilir. Aynı sayıda ekrana sahip bir üyelik sistemi ise haftalar sürebilir.

Teslim süresi belirlenirken yalnızca geliştirme zamanı değil, içerik hazırlığı, geri bildirim, test, entegrasyon onayları ve düzeltmeler de hesaba katılmalıdır.

Sorumlulukların kimde olduğu ayrıca açıklanmalıdır. Alan adı ve sunucu erişimlerini kim sağlayacak? İçerikleri kim hazırlayacak? Tasarımları kim onaylayacak? Harici servis hesaplarını kim açacak? Test verilerini kim kontrol edecek? Son kararı verecek kişi kim?

Özellikle birden fazla kişinin onay verdiği projelerde geri bildirim süreci önemli bir zaman kaynağı olabilir. Herkesin farklı kanallardan parça parça yorum iletmesi, aynı ekranın tekrar tekrar ele alınmasına neden olur. Geri bildirimlerin kim tarafından toplanacağı ve hangi aşamada iletileceği baştan belirlenmelidir.

Bütçe konuşulurken de yalnızca ilk geliştirme maliyeti düşünülmemelidir. Sunucu, lisans, e-posta hizmeti, harici API, bakım ve destek gibi devam eden giderler bulunabilir.

Gerçekçi bir plan, yalnızca geliştiricinin ne kadar sürede kod yazacağını değil, projenin tamamlanması için bütün tarafların yapması gereken işleri içerir.

12. Projenin tamamlandığına ve başarılı olduğuna nasıl karar verilecek?

Bir projenin tamamlanması, bütün sayfaların açılması anlamına gelmez.

Kabul ölçütleri baştan belirlenmediğinde proje sonunda “çalışıyor ama beklediğimiz gibi değil” türünde belirsiz değerlendirmeler ortaya çıkar. Bu nedenle önemli işlevlerin hangi koşullarda tamamlanmış sayılacağı açıkça tanımlanmalıdır.

Örneğin bir iletişim formu için yalnızca gönder butonunun çalışması yeterli değildir. Zorunlu alanlar kontrol edilmeli, hatalı girişlerde anlaşılır mesajlar gösterilmeli, kayıt doğru yerde saklanmalı, bildirim ilgili kişiye ulaşmalı ve kullanıcı işlemin tamamlandığını görmelidir.

Bir e-ticaret projesinde ürünün sepete eklenmesi, ödemenin alınması, sipariş kaydının oluşması, stok miktarının güncellenmesi ve gerekli bildirimlerin gönderilmesi aynı işlemin parçalarıdır.

Teknik kabul ölçütlerinin yanında projenin iş hedefleri de bulunmalıdır. Yeni siteyle daha fazla nitelikli başvuru almak mı isteniyor? Müşteri hizmetlerine gelen tekrar eden soruları azaltmak mı amaçlanıyor? Çalışanların manuel olarak yaptığı bir işlemin süresi mi kısaltılacak?

Bu hedeflerin tamamı ilk günden kesin rakamlarla ifade edilemeyebilir. Yine de neyin iyileştirilmek istendiği bilinmelidir. Aksi hâlde proje yayına alındıktan sonra başarısı yalnızca kişisel beğeni üzerinden değerlendirilir.

Teslim sonrası süreç de bu sorunun bir parçasıdır. Hatalar hangi süre içinde düzeltilecek? Yeni talepler nasıl değerlendirilecek? Güncellemeleri kim yapacak? Yedekleme ve güvenlik kontrollerinden kim sorumlu olacak? Projenin kaynak kodu, erişimleri ve lisansları kime ait olacak?

Bir web projesi yayına alındığı gün tamamen sona ermez. Kullanıcılar sistemi kullanmaya başladıkça yeni ihtiyaçlar ortaya çıkabilir. Ancak bakım, destek ve yeni geliştirme arasındaki sınır açık olmalıdır.

İyi Proje, Doğru Sorularla Başlar

Bu 12 sorunun amacı projenin gelecekte karşılaşabileceği bütün ihtimalleri tahmin etmek değildir. Yazılım projeleri değişir. Kullanıcı davranışları yeni ihtiyaçlar ortaya çıkarabilir, işletmenin çalışma biçimi dönüşebilir ve başlangıçta önemli görünmeyen bir özellik zamanla gerekli hâle gelebilir.

Planlama, değişikliği ortadan kaldırmaz. Değişikliğin etkisini anlaşılır hâle getirir.

Projenin amacı, kullanıcıları, temel akışları, verileri ve kapsamı bilindiğinde yeni bir talebin mevcut yapıyı nasıl etkileyeceği daha doğru değerlendirilebilir. Bunun küçük bir düzenleme mi, yeni bir özellik mi yoksa kapsam değişikliği mi olduğu görülebilir.

Bu soruların cevapları için her zaman uzun toplantılara ve ağır dokümanlara ihtiyaç yoktur. Küçük bir projede birkaç sayfalık ihtiyaç listesi, temel kullanıcı akışları ve sorumlulukların yazıldığı bir çalışma yeterli olabilir. Daha büyük projelerde ise veri modeli, ekran akışları, entegrasyonlar ve kabul ölçütleri daha ayrıntılı hazırlanmalıdır.

Önemli olan belgenin uzunluğu değil, tarafların aynı projeyi konuştuğundan emin olmaktır.

Bir web projesinde en fazla zaman kaybettiren konular genellikle teknik olarak zor olan işlemler değildir. Başlangıçta farklı anlaşılan, cevaplanmadığı için varsayımla ilerlenen veya sorumlusu belirlenmeyen konulardır.

Koda ya da tasarıma başlamadan önce bu sorulara ayrılan zaman projeyi yavaşlatmaz. Tam tersine, yanlış kararların üzerine hızlı biçimde ilerlemeyi engeller.

Çünkü iyi bir web projesi ilk ekran çizildiğinde veya ilk kod yazıldığında başlamaz. Ne yapılacağının, neden yapılacağının ve ortaya çıkan sonucun nasıl değerlendirileceğinin anlaşıldığı anda başlar.