Özel yazılım projesi nasıl yönetilir? Müşteri tarafı için el kitabı

Projeye başlayalı yedi ay oldu. Her toplantıda "yüzde doksan bitti" cümlesini duyuyorsunuz, kalan yüzde onun neden üç aydır bitmediğini ise kimse açıklayamıyor. Elinizde tıklayabileceğiniz çalışan bir ekran yok, test edebileceğiniz bir adres yok, sözleşmede neyin "bitti" sayılacağı da yazmıyor. Bu tablo çoğu zaman yazılım ekibinin kötülüğünden değil, müşteri tarafının projeyi yönetecek araçlardan yoksun kalmasından doğar.

Bu yazı, özel yazılım yaptıran tarafın el kitabı. Kod yazmayı bilmeniz gerekmiyor; neyi istemeniz, neyi ne zaman görmeniz ve hangi cümleleri sözleşmeye yazdırmanız gerektiğini bilmeniz yetiyor. Keşiften başlayıp MVP'ye, kullanıcı hikâyelerine, sözleşme modellerine, demo ritmine, teste, kaynak koda ve yayından sonraki bakıma kadar sırayla gidiyoruz.

Keşif ve kapsam: önce problemi yazın, ekranları değil

Çoğu proje bir ekran listesiyle başlar: "Bir giriş sayfası, bir sipariş ekranı, bir de rapor sayfası olsun." Ekran listesi aslında bir çözüm önerisidir; asıl ihtiyaç arkasındaki problemdir. "Bayilerimiz siparişi telefonla veriyor, yanlış ürün kodu yüzünden her hafta iade yaşıyoruz" cümlesi, on ekranlık bir listeden daha çok iş görür.

Keşif aşaması, yazılım ekibiyle birlikte bu problemi, kullanıcıları ve kısıtları netleştirdiğiniz kısa bir dönemdir. Birkaç atölye, mevcut süreci yerinde izleme ve teknik bir ön inceleme içerir. İyi bir keşfin sonunda elinizde şunlar olmalıdır:

• Problemin ve başarının tanımı: proje bittiğinde neyin değişmiş olmasını bekliyorsunuz, bunu nasıl ölçeceksiniz?
• Kullanıcı rolleri: bayi, satış temsilcisi, depo sorumlusu, muhasebe, sistem yöneticisi.
• Bugünkü sürecin akış şeması, kimin hangi adımda neyi elle yaptığıyla birlikte.
• Bağlanılacak sistemler: ERP, muhasebe, e-Fatura entegratörü, ödeme kuruluşu, kargo firması.
• Kısıtlar: KVKK, sektör düzenlemeleri, kurum içi BT güvenlik kuralları, kullanıcıların cihazları.
• Önceliklendirilmiş bir iş listesi (backlog) ve kaba bir mimari önerisi.
• Risk listesi; yani en az bilinen ve en pahalıya patlayabilecek konular.

Keşfi ayrı ve küçük bir sözleşmeyle yaptırmak iki taraf için de sağlıklıdır. Siz büyük bütçeyi bağlamadan önce ekibin çalışma biçimini görürsünüz; ekip de tahmin vermeden önce gerçekten ne yapacağını öğrenir. Keşif çıktıları size ait olmalıdır, başka bir ekiple devam etmeye karar verseniz bile işe yarar. İyi bir brief'in nasıl hazırlanacağını ayrı bir yazımızda anlattık.

MVP'yi doğru küçültmek

MVP, yani "minimum uygulanabilir ürün", yarım yapılmış bir tam ürün değildir. En riskli varsayımınızı gerçek kullanıcılarla sınayabileceğiniz en küçük çalışan sürümdür. Tanımdaki kilit kelime "çalışan": kullanıcının işini baştan sona yapabildiği dar bir yol, her şeye biraz dokunan geniş bir vitrinden daha değerlidir.

Örneğin iki yüz bayisi olan bir yedek parça distribütörü düşünün. İlk sürüm için cazip görünen liste uzundur: sipariş, stok, kampanyalar, cari hesap, iade, mobil uygulama, gelişmiş raporlar. Doğru küçültülmüş bir MVP ise şunu söyler: on bayilik bir pilot grup, ürün kodu ya da araç modeliyle parça arayabilsin, stoğu görsün, sipariş versin ve sipariş ERP'ye kendiliğinden düşsün. Kampanyalar, iade ve mobil uygulama ikinci aşamaya kalır.

Kesmeyi teknik katmanlara göre değil, kullanıcı akışına göre yapın. "Önce bütün veritabanını, sonra bütün ekranları yapalım" yaklaşımı, aylarca kullanıcıya gösterilecek hiçbir şey üretmez. MoSCoW gibi basit bir sınıflandırma işe yarar: Must (mutlaka), Should (olmalı), Could (olabilir), Won't (bu sefer yok). Dördüncü sütunu boş bırakan bir liste, aslında hiçbir şeyi kesmemiştir.

MVP'de en sık unutulan üç şey var:

• Yönetim paneli. Ürünleri, kullanıcıları ve yetkileri kim, nereden düzenleyecek?
• Veri taşıma: eski sistemdeki cari kartlar ve fiyat listeleri yeni sisteme nasıl girecek?
• Raporlar, çünkü yönetim ilk hafta "kaç sipariş geldi?" diye soracak.

Bu üçü listede yoksa, MVP'niz kâğıt üzerinde küçük, gerçekte eksiktir.

Kullanıcı hikâyeleri ve kabul kriterleri

Gereksinimleri yazmanın en kullanışlı biçimlerinden biri kullanıcı hikâyesidir: "Bir [rol] olarak [bir şey yapmak] istiyorum, böylece [bir fayda elde ederim]." Örnek: "Bir bayi olarak araç modeline göre parça aramak istiyorum, böylece ürün kodunu bilmeden doğru parçayı sipariş edebilirim." Hikâye kısa olmalı, tek bir ihtiyacı anlatmalı ve tek bir sprintte bitirilebilecek boyutta kalmalıdır.

Hikâyeyi işe yarar kılan, altına yazılan kabul kriterleridir. Bunlar "bu hikâye ne zaman bitmiş sayılır?" sorusunun ölçülebilir cevabıdır. Yaygın bir kalıp "şu koşulda, şu yapıldığında, şu olmalı" biçimidir:

• Bayinin kredi limiti dolmuşsa, sipariş onaylanmak istendiğinde sistem siparişi durdurmalı ve kalan limiti göstermeli.
• Stokta olmayan bir ürün sepete eklenirse, tahmini tedarik tarihi ürün satırında görünmeli.
• Sipariş onaylandığında, sipariş birkaç dakika içinde ERP'de açılmalı ve bayiye onay e-postası gitmeli.

Bir de proje düzeyinde bir "bitti tanımı" (Definition of Done) yazılmalıdır. Scrum Rehberi'nden gelen bu kavram, her iş için geçerli ortak kalite çıtasıdır: kod incelemesinden geçti, otomatik testleri yazıldı, test ortamına yüklendi, belgeleri güncellendi. Bu tanım yoksa "bitti" kelimesinin anlamı kişiden kişiye değişir.

Sabit kapsam mı, zaman-malzeme mi? Sözleşme modelleri

Teklif aşamasında en çok tartışılan konu budur ve doğru cevap, projenin ne kadar bilindiğine bağlıdır. Kapsam ne kadar netse sabit bedel o kadar anlamlıdır; belirsizlik arttıkça zaman-malzeme modeli daha dürüst hâle gelir.

Sabit bedel kâğıt üzerinde en güvenli modeldir, ama iki gizli maliyeti vardır. Birincisi, yazılım ekibi bilinmeyenleri fiyata risk payı olarak ekler. İkincisi, proje boyunca öğrendiğiniz her şey bir "değişiklik talebi" olarak masaya gelir ve ilişki, ürünü iyileştirmekten çok sözleşmeyi yorumlamaya döner.

Zaman-malzeme modeli ise güven ve görünürlük ister. Haftalık harcanan saat raporu, iş listesindeki ilerleme ve kalan iş tahmini bu modelde lüks değil, şarttır. Sahada sık gördüğümüz sağlıklı düzen şu: keşif sabit bedelle, geliştirme tavanlı zaman-malzemeyle, yayından sonrası da aylık bir bakım anlaşmasıyla yürür.

Tahminleri nasıl okumalı?

Bir yazılım tahmini söz değil, belirli bir bilgi düzeyinde yapılmış bir öngörüdür. Keşiften önce verilen tahminler doğal olarak geniş bir aralıkta oynar; keşif bittikçe ve ilk sprintler tamamlandıkça daralır. Bu yüzden tek bir rakam yerine aralık isteyin ve aralığın neden geniş olduğunu sorun: hangi entegrasyon, hangi bilinmeyen? Ekibin işlere verdiği puanlar (story point) zaman birimi değil, işlerin birbirine göre büyüklüğüdür; anlamlı olan, birkaç sprint sonra ortaya çıkan ortalama hızdır. İlk iki sprintten sonra tahmini yeniden konuşmak, sözleşmeye yazılabilecek kadar olağan bir adımdır.

Sprint ve demo ritmi: ilerlemeyi nasıl görürsünüz?

Çevik yöntemlerle çalışan ekipler işi sprint denen kısa dönemlere böler. Scrum Rehberi'ne göre bir sprint en fazla bir ay sürer; pratikte çoğu ekip bir ya da iki haftayı seçer. Sprint sonundaki gözden geçirme (sprint review) sizin için en önemli toplantıdır, çünkü o dönemde biten işler test ortamında çalışırken gösterilir.

Ölçüt basit: slayt değil, çalışan yazılım. "Ekran tasarımları hazır" ya da "arka uç yüzde seksen" gibi cümleler ilerleme değildir. Demo sırasında farenin sizde olmasını isteyin; kendiniz tıklayın, yanlış veri girin, geri tuşuna basın.

Müşteri tarafında bir ürün sahibi (product owner) olmalıdır. Bu kişi önceliklere karar verir, ekibin sorularını birkaç gün içinde yanıtlar ve demolara katılır. Kararlar beş kişilik bir kurulda dolaşıyorsa ekip bekler; beklemek de zaman-malzeme modelinde doğrudan faturaya yansır. Haftada birkaç saati bile olmayan bir yöneticiyi bu role atamak, projeyi baştan yavaşlatır.

İş listesini görebilmeniz de şarttır. Jira, Linear ya da GitHub Projects gibi araçlarda okuma yetkisi isteyin. Kapsamın ne kadarının bittiğini ve kalan tahminin nasıl değiştiğini gösteren basit bir burn-up grafiği, aylık raporlardan daha dürüst bir göstergedir.

Kapsam kayması nasıl yönetilir?

Kapsam kayması nadiren büyük bir kararla gelir. "Küçük bir ekleme", "madem bu ekran yapılıyor şunu da koyalım", projenin ortasında katılıp kendi isteklerini getiren finans ya da BT güvenlik ekibi. Her biri tek başına makul; toplamı ise teslim tarihini aylarca öteleyen bir yük.

Basit bir kural çoğu zaman yeter: içeri bir şey giriyorsa dışarı bir şey çıkar. Yeni istek iş listesine yazılır, tahmin edilir, ürün sahibi onu mevcut işlerle karşılaştırır ve neyin erteleneceğine karar verir. Bu kararların hepsi, tarihi ve gerekçesiyle bir karar günlüğüne işlenir. Altı ay sonra "bunu kim, neden istemişti?" sorusunun cevabı orada durur.

Kayma yalnızca müşteriden gelmez. Yazılım ekibinin kimsenin istemediği bir animasyon ya da "her ihtimale karşı" bir modül eklemesi de kapsam kaymasıdır. Demoda böyle bir şey görürseniz sorun: bu hangi hikâyeye ait?

Test ve kalite: staging, otomatik testler ve kabul

Profesyonel bir projede en az üç ortam olur: geliştiricilerin çalıştığı geliştirme ortamı, canlıya olabildiğince benzeyen test ortamı (staging) ve canlı ortam. Demolar ve sizin testleriniz staging'de yapılır; canlı ortamda deneme yapılmaz.

Test ortamına gerçek müşteri verisini olduğu gibi kopyalamak yaygın ve tehlikeli bir kısa yoldur. Kişisel veriler anonimleştirilmeli ya da gerçekçi sahte verilerle değiştirilmelidir. KVKK açısından test ortamı da canlı ortam kadar özen ister.

Kalite yalnızca elle denemekle sağlanmaz. İyi bir ekip şu katmanlarda otomatik test yazar ve her kod birleştirmesinde bunları GitHub Actions ya da GitLab CI gibi bir sürekli entegrasyon hattında çalıştırır:

• Birim testleri, tek tek fonksiyonların doğru hesap yaptığını sınar; örneğin iskonto ve KDV hesabı.
• Entegrasyon testleri: veritabanı, ERP ya da ödeme kuruluşu gibi dış sistemlerle konuşan kodun doğru çalıştığını gösterir.
• Uçtan uca testler, Playwright ya da Cypress gibi araçlarla gerçek bir tarayıcıda "bayi giriş yapar, parça arar, sipariş verir" akışını kendiliğinden oynatır.
• Kod incelemesi. Her değişikliği, yazanından başka bir geliştirici okur.

Bunlara güvenlik, performans ve erişilebilirlik kontrolleri eklenir. Güvenlik için OWASP'ın yayımladığı ASVS ve Top 10 iyi bir başlangıç listesidir; erişilebilirlik için WCAG 2.2 ölçütleri esas alınır. Kişisel veri ya da ödeme işleyen sistemlerde yayından önce bağımsız bir sızma testi yaptırmak makul bir masraftır.

Son adım sizin kullanıcı kabul testinizdir. Kabul kriterlerini tek tek dener, bulduğunuz hataları önem derecesiyle bildirirsiniz: sistem kullanılamıyor, önemli bir işlev çalışmıyor ya da kozmetik bir sorun var. Hangi dereceden kaç açık hata varken yayına çıkılabileceğini baştan kararlaştırmak, son haftanın tartışmasını önler.

Yayın gününü de planlayın. Hangi saatte geçileceği, eski sistemin ne kadar süre paralel çalışacağı, bir şey ters giderse nasıl geri dönüleceği ve ilk hafta hataları kimin izleyeceği yazılı olsun. Cuma akşamı yapılan bir yayın, hafta sonu kimsenin telefonu açmadığı bir krize dönüşebilir.

Kaynak kod, fikri mülkiyet ve devir teslim

Kaynak kodun şirketinize ait bir GitHub ya da GitLab hesabında tutulması, ilk günden kurulması gereken bir düzendir. Yazılım ekibi bu depoya erişim alır; depo onların hesabında durup proje sonunda size "teslim edilmez". Aynı kural bulut hesabı, alan adı, uygulama mağazası hesapları, e-posta servisi ve üçüncü taraf API anahtarları için de geçerlidir: hepsi şirketinizin adına açılır, ekip yetkilendirilir.

Fikri mülkiyet tarafında bilinmesi gereken temel nokta şu. Fikir ve Sanat Eserleri Kanunu'na göre bilgisayar programları eser olarak korunur ve bir ajans ya da serbest yazılımcı sizin çalışanınız değildir. Mali hakların size geçmesi için yazılı bir sözleşme ve devredilen hakların (çoğaltma, işleme, yayma gibi) tek tek gösterilmesi gerekir. "Kod müşteriye aittir" gibi tek bir cümle yetmeyebilir.

İki ayrıntı daha var. Ekibin projeden önce de var olan kendi kütüphaneleri ve araçları olabilir; bunlarda söz konusu olan devir değil lisanstır ve lisansın kapsamı yazılmalıdır. Ayrıca neredeyse her proje açık kaynak bileşenler kullanır. MIT gibi serbest lisanslar genellikle sorun çıkarmaz, ama GPL ya da AGPL gibi "copyleft" lisanslar dağıtım ya da ağ üzerinden sunum durumunda kendi kaynak kodunuzu açma yükümlülüğü doğurabilir. Teslimde bir lisans envanteri isteyin.

Dokümantasyon ve devir teslim

Belgeler, sistemin tek bir kişinin hafızasında kalmamasını sağlar. Proje sonunda en azından şunları teslim alın:

• Kurulum ve çalıştırma talimatı (README): yeni bir geliştirici sistemi kendi bilgisayarında nasıl ayağa kaldırır?
• Mimari özet ve önemli teknik kararların gerekçeleri.
• API belgeleri, tercihen OpenAPI biçiminde.
• Veri modeli ve dış sistemlerle hangi verinin ne sıklıkla alınıp verildiği.
• Yayın adımları, ortam değişkenlerinin listesi ve gizli anahtarların nerede, kimde saklandığı.
• Yedekleme ve geri yükleme prosedürü, en az bir kez denenmiş hâliyle.
• Bilinen sorunlar ve ertelenen işler listesi.

İyi bir devir teslimin testi basittir: ekipten bağımsız bir geliştirici yalnızca bu belgelerle sistemi kurup küçük bir değişikliği yayına alabiliyor mu? Bunu gerçekten denetmek, sözleşmedeki kabul adımlarından biri olabilir. Devirle birlikte erişimleri de toparlayın: projeden ayrılan kişilerin hesapları kapatılır, paylaşılmış parolalar ve API anahtarları yenilenir.

Yayından sonra: bakım, SLA ve projeleri batıran nedenler

Bakım ve SLA

Yazılım yayına girdiği gün bitmez, o gün yaşamaya başlar. İşletim sistemi, çatı ve kütüphane güncellemeleri, güvenlik yamaları, kullanıcılardan gelen hata bildirimleri ve küçük iyileştirmeler için bir bakım anlaşması gerekir. Bu anlaşmanın merkezinde hizmet seviyesi taahhüdü (SLA) durur.

İyi bir SLA önce hataları sınıflandırır: sistemin tamamen durduğu kritik durum, önemli bir işlevin aksadığı yüksek öncelik, iş akışını durdurmayan normal hatalar. Her sınıf için iki ayrı süre yazılır: ilk yanıt süresi ve çözüm ya da geçici çözüm süresi. Bu ikisini karıştırmayın; "iki saatte dönüş" ile "iki saatte çözüm" çok farklı taahhütlerdir. Destek saatleri, izleme ve alarm düzeni, yedeklerin sıklığı ve barındırmanın kimin sorumluluğunda olduğu da aynı belgede yer almalıdır.

Bakım yalnızca arıza beklemek değildir. Kütüphanelerin güvenlik güncellemeleri, çatının ve sunucu yazılımının sürüm yükseltmeleri, süresi dolan sertifikalar ve küçük iyileştirmeler için aylık ya da yıllık bir saat havuzu ayırmak, sistemi iki yıl sonra baştan yazmak zorunda kalmaktan çok daha az yorar.

Projeleri en sık batıran nedenler

Kod kalitesi nadiren tek başına bir projeyi batırır. Sahada en sık gördüğümüz nedenler yönetimle ilgilidir:

• Müşteri tarafında karar verebilecek tek bir kişinin olmaması.
• Gerçek kullanıcıların ürünü ilk kez yayından bir hafta önce görmesi.
• Veri taşımanın ve entegrasyonların "sonra hallederiz" denilerek küçümsenmesi.
• Pilot grup ve aşamalı geçiş yerine her şeyin aynı gün açıldığı büyük patlama yayınları.
• En düşük teklifin, kapsam anlaşılmadan seçilmesi.
• Sistemi yalnızca bir geliştiricinin bilmesi.
• Yayından sonrası için hiç bütçe ayrılmaması.

Nereden başlamalı?

1. Problemi, kullanıcıları ve başarı ölçüsünü bir sayfaya yazın; ekran listesini sonraya bırakın.
2. Keşfi ayrı ve küçük bir işle başlatın, çıktılarının size ait olacağını yazdırın.
3. MVP'yi tek bir kullanıcı akışına indirin; yönetim panelini, veri taşımayı ve raporları listeye ekleyin.
4. Her hikâyeye ölçülebilir kabul kriterleri, projeye de bir bitti tanımı yazdırın.
5. Projenin belirsizliğine uygun sözleşme modelini seçin ve metni hukuk danışmanınızla gözden geçirin.
6. Ürün sahibinizi atayın ve ona bu işe gerçekten ayırabileceği bir takvim verin.
7. Kod deposunu, bulut hesaplarını ve alan adlarını ilk günden şirketiniz adına açın.
8. Bakım ve SLA anlaşmasını yayından önce imzalayın; yayından sonra pazarlık gücünüz azalır.

AYTE Digital olarak özel yazılım projelerinde keşfi ayrı bir aşama olarak yürütüyor, kaynak kodu ve hesapları ilk günden müşterinin adına açıyoruz. Elinizde yürüyen ya da tıkanmış bir proje varsa, iş listenizi ve süreç belgelerinizi birlikte okuyup yukarıdaki maddelerden hangilerinin eksik kaldığını konuşabiliriz.