Revizyon, onaylı işi düzeltir; kapsam değişikliği yeni ihtiyaç ekler. Geliştirmeden önce bu ayrımı yapın ve devirde alınacakları listeleyin. Onaylı sayfada başlık değişikliği revizyondur. Rezervasyon motoru eklenmesi yeni özellik talebidir. Kod teslimi üçüncü taraf font, stok fotoğraf veya yazılım lisanslarının mülkiyetini devretmez.
Revizyonu hedefi değiştirmeden iyileştirme olarak tanımlayın
Revizyon, onaylanan kapsam içinde tasarım veya içeriğin gözden geçirilmesidir. Yeni bir hizmet eklemek, farklı hedef kitleye geçmek veya başvuru formunu üyelik sistemine dönüştürmek aynı türden değişiklik değildir. Proje başında bu ayrımı örneklerle konuşmak, sonradan her geri bildirimin tartışmaya dönüşmesini önler. Tur sayısının yanında hangi değişikliklerin o turda ele alınacağı da anlaşılır olmalıdır.
Bir toplu revizyon turunda aynı sürüm üzerine hazırlanmış tek bir geri bildirim listesi paylaşılır. Başlık hiyerarşisi, görsel seçimi ve metin düzeltmeleri bu listede birlikte bulunabilir. Birer gün arayla gelen, birbirini geçersiz kılan farklı mesajlar ise hangi sürümün onaylandığını belirsizleştirir. İşletme içinde yorumları toplayan bir kişinin bulunması bu yüzden yararlıdır.
Geri bildirimi yalnız beğeniyle değil, amaçla ilişkilendirin. “Burası içime sinmedi” yerine “Hizmet verdiğimiz bölge ilk ekranda anlaşılmıyor” demek çözüm üretmeyi kolaylaştırır. Tasarım kararı için birden fazla yöntem olabilir; müşterinin asıl sorunu açıklaması geliştiricinin uygun çözümü önermesine alan bırakır. Küçük ayrıntılar da önemli olabilir, fakat öncelik sırası açık olmalıdır.
Teslimi dosya yüklemesiyle sınırlamayın
Bir sitenin internette görünmesi, teslim sürecinin bütününün tamamlandığı anlamına gelmez. Kaynak dosyaları, son içerikler, kullanılan lisanslar, hesap sahipliği ve işletme için gerekli kısa kullanım notları teslimin parçalarıdır. Hangi dosyaların hangi biçimde paylaşılacağını teklif aşamasında belirlemek gerekir. Özellikle başka geliştiricinin ileride projeyi devralabilmesi için kurulum bilgisi erişilebilir olmalıdır.
Yayın öncesi kabul listesinde gerçek sayfa ve işlevler yer almalıdır. Telefon genişliğinde menü, formun zorunlu alanları, başarı ve hata mesajları, kırık bağlantılar, favicon ve bilinmeyen URL davranışı kontrol edilir. İçerik doğruluğu için müşterinin de sorumluluğu vardır: çalışma saatini veya hizmet bölgesini en iyi işletme sahibi doğrulayabilir. Teknik kontrol, ticari bilginin doğruluğunu kendiliğinden garanti etmez.
Takvim içeriklerin hazır olmasına bağlıysa bunu görünür tutun. Son gün gelen yeni sayfalar veya henüz onaylanmamış çeviriler teslim planını değiştirebilir. Böyle bir durumda güncellenmiş kapsam ve tarih konuşulmalıdır. Tahmini iş günü aralığını koşulsuz garanti gibi değerlendirmek yerine, başlama koşullarını ve müşteri bekleme sürelerini kayda alın.
Kod sahipliği ile üçüncü taraf haklarını ayırın
Kaynak kodunun teslim edilmesi, kullanılan her fotoğrafın veya kütüphanenin sınırsız haklarının devri anlamına gelmez. Üçüncü taraf bileşenler kendi lisans koşullarına bağlı olabilir. Teslim listesinde proje dosyalarıyla birlikte bu bağımlılıkların kısa kaydı bulunmalıdır. Lisans şartı bulunan bir varlığın sonradan başka projeye taşınması ayrıca değerlendirilir.
Alan adı ve barındırma hesaplarının işletmenin kontrolünde olması devamlılığı kolaylaştırır. Geliştiriciye çalışma için uygun erişim verilebilir; bu erişimin kalıcı hesap sahipliğiyle karıştırılmaması gerekir. Kimin ödeme ve yenileme bildirimlerini alacağı, gerektiğinde erişimin nasıl kaldırılacağı ve güvenli devir yöntemi belirlenmelidir. Şifreleri herkese açık bir belgeye koymak teslim kolaylığı değildir.
Son olarak teslim sonrası hata düzeltmesiyle yeni geliştirmeyi ayırın. Onaylanan formun çalışmaması ile yeni bir form akışı istemek farklı durumdur. Destek süresi, kapsamı ve talep kanalı yazılı olursa iki taraf da ne bekleyeceğini bilir. Revizyon, teslim ve kod sahipliği aynı konuşmanın parçasıdır: amaç yalnız güzel görünen bir siteyi değil, sorumlulukları anlaşılmış bir işi devretmektir.
Bir revizyon listesini nasıl yazabilirsiniz? Her maddeye sayfa adı, ilgili bölüm, görülen sorun ve beklenen sonucu ekleyin. “Hizmetler sayfasındaki paket açıklamasında dil sınırı anlaşılmıyor; tek dil kapsamını daha görünür yapalım” gibi bir ifade çözüm üretmeye uygundur. Gerekirse ekran görüntüsüyle yeri gösterin. Ekran görüntüsünü tek başına bırakmayın; neden değişiklik istediğinizi kısa cümleyle anlatın.
Son kontrol turunda yeni fikirleri de kaydedebilirsiniz, fakat bunları mevcut hatalarla karıştırmayın. Çalışmayan bir düğme teslim sorunudur; yeni bir hesaplama aracı isteği yeni iş olabilir. Önce mevcut kapsamın kabul koşullarını tamamlamak, sonraki geliştirmeleri ayrı sürümde planlamak mümkündür. Bu ayrım teslimi gereksiz yere açık uçlu tutmaz.
Kod devrinde sadece sıkıştırılmış dosya almakla yetinmeyin. Projeyi çalıştırmak için gerekli komutlar, kullanılan sürümler, public ayarlar ve secret isimleri açıklanmalıdır. Secret değerleri güvenli kanaldan yönetilir; kaynak dosyalarının içinde tutulmaz. Alan adı ve barındırma hesabının gerçek sahibini, geliştirici erişiminin nasıl kaldırılacağını ve yedeklerin yerini de kaydedin. Başka bir geliştiricinin belgeleri okuyarak projeyi anlayabilmesi, teslimin pratik niteliğini gösteren yararlı bir kontroldür. Bunun yapılmış olduğunu ancak gerçekten deneyip gördüğünüzde doğrulanmış sayın.
Onay mesajında hangi sürümün kabul edildiğini belirtin. Dosya adı, önizleme adresi veya sürüm tarihi bunun için kullanılabilir. Belirsiz bir “tamamdır” yanıtı farklı kişilerin farklı ekranı onaylamış olmasına yol açabilir. Son teslim kontrolünü aynı sürüm üzerinden tamamlayın.
Devir kontrolünü başka bir kişinin projeyi açabilmesi üzerinden düşünün. Teslim dosyası yalnızca kaynak kodu içeriyorsa yayın ortamı, gerekli değişken adları ve kurulum adımları bilinmeyebilir. Gizli anahtarları belgede açıkça paylaşmadan hangi sırların nerede yönetildiği açıklanmalıdır. Böylece yeni uzman dosyaları okuyabilir ve erişim talebini doğru hesaba yöneltebilir.
Revizyon değerlendirmesinde hata düzeltmesi ile yeni isteği ayırmak için onaylı kapsamı kullanın. Mobil menünün çalışmaması teslim hatasıdır; sonradan üyelik sistemi eklenmesi yeni iş olabilir. Görsel tercihin değişmesi ise neyin onaylandığına bağlıdır. Bu ayrımı kişi yorumuna bırakmak yerine kısa kabul ölçütleriyle açıklamak daha sağlıklı bir görüşme sağlar.
Mülkiyet için hesap listesini ayrıca kontrol edin. Alan adı kayıt hesabı, barındırma hesabı, kaynak deposu ve varsa görsel lisansları aynı kurala tabi olmayabilir. İşletme adına açılan hesapların kurtarma yöntemleri de işletmenin erişiminde olmalıdır. Teslimden sonra geliştiricinin kişisel hesabına bağımlı kalan bir alan adı, kod dosyaları eksiksiz olsa bile devir sorununa dönüşür. Son toplantıda bir örnek güncellemeyi ve yayın adımını birlikte gözden geçirmek, belgenin uygulanabilir olduğunu göstermenin pratik bir yoludur.
Uygulama kontrolü
- Geri bildirimi turlarda toplayın
- Kaynak dosya ve lisansları yazın
- Hesap erişimini doğrulayın
Somut örnek: Onaylı sayfada başlık değişikliği revizyondur. Rezervasyon motoru eklenmesi yeni özellik talebidir.
Dikkat edilmesi gereken sınır: Kod teslimi üçüncü taraf font, stok fotoğraf veya yazılım lisanslarının mülkiyetini devretmez.
